Privacy Policy

Last updated: 2026-05-18 · Effective date: Date of installation · Publisher: WebCorrect Pro

This policy describes what data RunbookGuard processes when you install it in Confluence Cloud, where that data is stored, the lawful basis on which we process it, how long it is retained, who else processes it on our behalf, and how you can access or delete it. RunbookGuard is published by WebCorrect Pro ("we", "us") and distributed via the Atlassian Marketplace. It runs entirely on Atlassian's Forge platform; we operate no separate database, no analytics back-end, and no cross-tenant infrastructure.

1. Data we process

1.1 Confluence content

When you trigger a scan, RunbookGuard reads the body of every Confluence page in the spaces you have granted it access to (via the read:confluence-content.all and read:page:confluence scopes). The text is processed in memory — the full page body is not stored to disk.

Each indexed page is tagged with its Confluence space ID so the dashboard can enforce per-space permission filtering: a user with read access only to space SRE sees only findings on SRE-space pages. The permission check happens on every dashboard read by calling the Confluence permission API as the calling user; cached only for the duration of the current request.

What we do persist after extraction:

• Extracted entities — IPs, hostnames, URLs, AWS resource IDs (e.g. i-0abc123), and ARNs detected on the page.
• Page metadata — page ID, page title, space key, last-modified timestamp, page URL.
• A SHA-256 hash of the page body — used to skip re-extraction on subsequent scans when content hasn't changed.
• Findings — the cross-product of an extracted entity and the matching/missing AWS resource, with severity and confidence.

1.2 AWS inventory

When you connect an AWS account, RunbookGuard fetches a read-only inventory of 12 AWS resource types (EC2, RDS, S3, Route53, ELB, ElastiCache, Security Groups, Subnets, VPCs, ECS, EKS, Lambda). Stored fields per resource: resource ID, ARN, region, name/tag values, and resource-type-specific public identifiers (DNS name, hostname, public IP if assigned).

We never store secrets, environment variables, snapshot contents, object data, or anything else from the resources themselves — only the metadata returned by the AWS Describe* / List* / Get* calls.

1.3 Credentials

• IAM Role (recommended). We store only the role ARN and a per-tenant External ID. No long-lived keys. Each scan, RunbookGuard calls sts:AssumeRole with the External ID and receives short-lived credentials (1-hour TTL).
• Access keys (legacy). If you provide an access key + secret, the secret is stored in Forge's encrypted secret KVS (storage:app scope, written via kvs.setSecret) and never logged.

The role's IAM policy is a custom least-privilege policy with 16 explicit read actions across EC2, RDS, ELB, Route53, ElastiCache, ECS, EKS, Lambda, and S3 metadata. RunbookGuard does not use the AWS-managed ReadOnlyAccess policy; that policy includes s3:GetObject, secretsmanager:GetSecret*, and other actions RunbookGuard never calls.

1.4 User-supplied configuration

• The email address you configure for the weekly digest.
• An optional reply-to address.
• Jira project key and the auto-create flag.
• Coverage- and finding-dismissal records (the dismissing user's Atlassian accountId and an optional free-text reason).

1.5 Operational telemetry

• Scan run metadata — start/end timestamp, pages indexed, findings created.
• Error snapshots — when an unexpected error occurs, a redacted snapshot of the failing request context is stored for diagnostic purposes (no page bodies, no credentials, no raw Atlassian accountIds or email addresses in log payloads — the application enforces an allowlist on log payload fields).
• Audit log — every Jira ticket RunbookGuard creates on your behalf is logged with timestamp + finding ID + the accountId of the creator. Retained for 730 days by default (configurable via retention_audit_days in Settings → Storage).

2. Where data is stored

All persisted data lives in Forge's per-tenant data stores inside your Atlassian Cloud instance:

• Forge SQL (1 GiB per install, isolated to your tenant) — extracted entities, findings, AWS inventory snapshots, configuration, audit log.
• Forge KVS (storage:app scope, isolated to your tenant) — secrets only (AWS access key secret if used; HMAC pepper). All secrets are written via kvs.setSecret, which Atlassian encrypts at rest with per-tenant keys.

We do not operate a separate database. Atlassian is the data processor for everything stored in Forge SQL/KVS, governed by the Atlassian Data Processing Addendum and the Forge Data Processing Addendum.

2.1 Data residency (including EU, US, AU, CA)

Forge data follows your Atlassian Cloud region setting. If your Confluence Cloud instance is configured for EU data residency, RunbookGuard's Forge SQL data is stored on EU infrastructure. The same applies to US, Australia, Canada, and other Atlassian Cloud regions. RunbookGuard inherits this from Atlassian; we do not run a separate region tier and do not move data outside your Atlassian region. Reference: Atlassian Cloud data residency and Forge data residency.

3. Outbound data transfer

The app makes outbound network calls only to the following destinations, enforced at the platform level by the Forge manifest's external.fetch.backend allowlist (no other domain is reachable, even by accident):

• AWS APIs (per-region: e.g. ec2.us-east-1.amazonaws.com, sts.amazonaws.com, route53.amazonaws.com, s3.amazonaws.com, and bucket-virtualhost addresses) — read-only inventory fetches, signed with the credentials you configured.
• Resend (api.resend.com) — to deliver the weekly digest email to the address you configured.

The Forge manifest also lists *.ingest.sentry.io in the egress allowlist so that error-event forwarding can be enabled in our internal development and staging environments. In production this destination is unreachable: a code-level guard (src/lib/sentry.ts) hard-refuses to send any payload when FORGE_ENVIRONMENT_TYPE === 'PRODUCTION', regardless of whether the DSN environment variable is set. No customer-install data is forwarded to Sentry. If we ever change this posture, we will add Sentry to the sub-processor table in §7 and follow the 30-day change-notice in §7.1 before the change takes effect.

3.1 Data residency for outbound transfers

Forge's automatic site-pinning (described in §2.1) does not cover external services. Specifically:

• Resend. Resend's email-rendering and deliverability infrastructure runs primarily in AWS us-east-1 (US), with edge nodes in EU. The data sent to Resend per digest send: the recipient email address, the rendered HTML/text email body (which contains Confluence page titles, finding evidence values, and AWS resource identifiers from the install's scan), and a Reply-To address if you configured one. No Atlassian-side site secrets, OAuth tokens, or workspace identifiers are sent. Customers with strict EU-only data-residency requirements who cannot use a US-region email provider should disable the digest in Settings → Weekly Digest. The dashboard remains fully functional without it.
• AWS APIs. The AWS API endpoints we call live in whichever AWS region holds the resource (e.g. an i-xyz EC2 instance in eu-west-1 is reached via ec2.eu-west-1.amazonaws.com). Customers control which regions are scanned via the AWS Connection tab's region selector.

3.2 Digest email contents

The digest email contains: scan summary, findings count by severity, the first ~20 new findings (with finding type, severity, page title, page URL, and the matched AWS resource ID), and the documentation-coverage block (counts + total monthly cost of undocumented resources). It does not include AWS credentials or the full page body.

Per-recipient filtering. The digest aggregates only findings and coverage from spaces the recipient's Atlassian account can read. If the configured digest address does not resolve to a known Atlassian user (e.g. a shared inbox like ops@company.com), the install must explicitly opt in via the digest_email_unfiltered flag to send install-wide aggregation; otherwise the digest is skipped.

4. Data retention

All retention windows below match the schema defaults shipped in src/migrations.ts (v034). Customers can adjust each window in Settings → Storage; the displayed numbers are the as-shipped defaults. Per GDPR's data-minimization principle (Article 5(1)(c)) and CCPA §1798.100(c), we retain personal data only as long as needed for the disclosed purpose.

When you uninstall the app, Atlassian deletes all Forge SQL + KVS data within 30 days, per Forge platform policy (Forge privacy API reference). We retain no copies.

5. Data sharing

• We do not sell, rent, or share customer data with third parties.
• We do not use customer data to train AI/ML models.
• We do not maintain analytics that aggregate across tenants.

The only data egress is described in §3.

6. Your rights

Because all data lives in your Atlassian tenant:

• Access (GDPR Art. 15 / CCPA §1798.100). Every entity, finding, snapshot, and audit row is queryable from the dashboard.
• Deletion (GDPR Art. 17 / CCPA §1798.105 — "Right to be Forgotten"). Uninstalling the app removes all data within 30 days, per Forge platform policy. For selective deletion (e.g. one page's findings), use the Coverage tab's dismissal flow or contact us.
• Rectification (GDPR Art. 16). Re-running a scan refreshes all derived data from the current Confluence + AWS state.
• Portability (GDPR Art. 20). JSON export available on request from service@webcorrect.pro.
• Restriction / objection (GDPR Art. 18 / 21). Contact us at the address above.

6.1 Statutory response windows

We acknowledge data-subject requests promptly and respond within the following statutory windows:

• GDPR (EU/UK) — within 30 days of receiving a verified request (Article 12(3)). A one-time 60-day extension is possible for complex requests, with explanation provided to the requester within the initial 30-day window.
• CCPA / CPRA (California) — within 45 days of receiving a verified request. A one-time 45-day extension is possible with prior written notice to the requester.

Atlassian-initiated requests via the Forge reportPersonalData API are answered within Atlassian's own polling window (currently 90 days per Atlassian's contract). When an Atlassian account is closed or deleted, RunbookGuard's daily privacy-report cron iterates every persisted accountId column and runs the erasure cascade described in §6.2.

6.2 Erasure cascade for closed Atlassian accounts

When Atlassian notifies us that an account has been closed, we follow a redact-not-delete pattern: the accountId reference is set to NULL in every audit-bearing row, but the row itself is preserved. Per GDPR Recital 26, a row that no longer identifies a natural person is anonymous data and is no longer subject to the regulation. This preserves security forensics and regulator-mandated audit history (Art. 6(1)(f) legitimate interest) while still honouring the erasure right.

Columns covered by the erasure cascade today:

• dismissals.dismissed_by · dismissals.reason (free text — also nulled)
• coverage_dismissals.dismissed_by · coverage_dismissals.reason
• ticket_snapshots.created_by
• coverage_ticket_audit.created_by
• app_settings.digest_email · app_settings.digest_email_account_id
• admin_audit.account_id (after the configured retention_audit_days window)

7. Sub-processors

RunbookGuard uses the following sub-processors. This list is the exhaustive set of external destinations the application can reach — it is enforced at the Forge platform level by the manifest egress allowlist, so a new destination cannot be added without a code change and an update to this list.

We do not employ additional sub-processors.

7.1 Change-notice commitment

We will notify customers at least 30 days before adding, replacing, or materially changing a sub-processor. Notification is sent to the digest recipient address on file and posted to the release notes for the same period. Customers who object in writing within the notice window may terminate the subscription per their order form. (This mirrors Atlassian's own 30-day subprocessor notice, Atlassian Customer Agreement §6.3.)

8. Security

• Encryption at rest. Atlassian encrypts Forge SQL and Forge KVS at rest (platform guarantee). All application-layer secrets (AWS access-key secret if used; HMAC pepper for webtrigger authentication) are written via kvs.setSecret, which Atlassian encrypts separately.
• Encryption in transit. All inbound and outbound traffic uses TLS 1.2+; this is enforced by the Forge platform.
• Credential hygiene. AWS credentials never appear in application logs. The application enforces a static-analysis allowlist on log payload fields (src/lib/log.ts); raw Atlassian accountIds and email addresses are also off-allowlist and cannot reach logs.
• Support-tooling endpoints. All inbound webtrigger endpoints used for support tooling are HMAC-authenticated with a 60-second replay window and write a support_access_log audit row.
• Data minimization at read time. Resolvers exposed to the UI SELECT only the columns the UI actually renders; no SELECT * over tables that contain personal data.
• Least-privilege AWS. See §1.3 — RunbookGuard requires a custom 16-action read-only IAM policy, not AWSReadOnlyAccess.

For our security posture in detail, including CAIQ v4.0.3 responses, see the Security page.

8.1 Cryptographic key rotation

RunbookGuard uses a single HMAC pepper (stored in Forge KVS via kvs.setSecret) to fingerprint user-provided identifiers. The pepper is established once at install time and is not rotated under normal operation. Rotation is a deliberate, customer-supportable event with a 30-day overlap window; previously stored fingerprints remain valid through the overlap. There is no scheduled rotation cadence — the application's threat model does not require continuous rotation per ENISA's Cryptographic Mechanisms — Recommendations and Key Sizes (v2.0, 2014, §3.5).

9. Breach notification

Per GDPR Article 33, where a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, the controller must notify the supervisory authority within 72 hours of becoming aware of it. RunbookGuard's role is processor; we will notify the controller (you) without undue delay and, where reasonably possible, within 24 hours of confirmed breach detection, so that you retain a working 72-hour window for any onward notification you need to make.

Detection pipeline: application-level error snapshots feed an alerting tier that fires on anomaly classes correlated with credential or data exposure (e.g. unexpected cross-tenant queries, spike in 5xx on credential-bearing webtriggers, Sentry alert rules). On confirmed breach, the breach-response runbook (docs/breach-response.md) governs containment, notification, and the preservation of forensic evidence.

10. Lawful basis for processing (GDPR Article 6)

Each category of personal data we process maps to exactly one of the GDPR Article 6(1) lawful bases. We do not rely on consent (Art. 6(1)(a)), legal obligation (c), vital interests (d), or public task (e).

11. Children

RunbookGuard is a developer tool sold B2B and is not directed at children under 16. We do not knowingly process personal data of children.

12. Changes to this policy

We will post any updates to this page and update the Last updated date above. For material changes that reduce your privacy protections, we will additionally notify the digest recipient address on file at least 30 days before the change takes effect.

13. Contact

• Email: service@webcorrect.pro
• Web: https://runbookguard.com
• Publisher: WebCorrect Pro

RunbookGuard is a Confluence Cloud Forge app. The Forge platform's own privacy and security model is described at developer.atlassian.com/platform/forge/runtime-security/.