Confidence starts with clear safeguards.

Guardian provides read-only Jira configuration review. It stores its own findings, settings and history on Atlassian Forge.

Architecture and access#

The UI, scheduled and queued work, compute and app storage run on Atlassian Forge. The app has no runtime remotes, external database, third-party analytics, AI service or outbound-notification service.

Every UI resolver checks the caller's current Jira ADMINISTER permission. Scans and ordinary changes to Guardian-owned state also require a trusted active or trial license. Administrator JSON export, privacy-request handling and history deletion remain available without renewing a paid license.

The masking-enabled manifest requests 30 scopes: storage:app, report:personal-data, and 28 Jira/Jira Software read or JQL-validation scopes. The added read:screen:jira and read:screen-tab:jira scopes support an existing field-screen lookup; they do not introduce an advertised Field Screen Evidence feature. The reporting scope enables Atlassian privacy reporting; it does not allow Jira configuration changes. See installation and permissions.

What Guardian stores#

Records can include configuration metadata, asset identifiers, findings and evidence, Coverage, history, settings, administrator decisions and privacy-maintenance state. In the masking-enabled build, supported account fields and membership keys use stable installation-specific references. Forge secret storage holds the installation key and one original identifier per account for authorized Jira calls, privacy reporting, export and erasure. Masking is enabled in the qualified Development build; other installations require a separately approved compatible upgrade.

This is pseudonymization, not anonymization. Existing derived hashes can remain linkable. Authorized display/export responses can contain decoded originals, and masking does not promise removal of platform IP/request logs or backups. Missing or inconsistent keys/mappings block the affected operation rather than silently creating replacements.

Runtime records do not intentionally persist names, email addresses, raw Jira API payloads, raw JQL, Jira/API authentication tokens or issue content. Temporary API processing and administrator display responses are distinct from storage. Support correspondence is handled separately.

Security controls#

• Installation- and environment-scoped Forge storage.
• Live administrator checks, bounded inputs and controlled Guardian-state changes.
• Resumable background work and coordination between scanning and deletion.
• Restricted operational logs without raw Jira payloads or credentials.
• Dependency review, secret checks, controlled releases and documented incident handling.

Forge provides hosted-storage encryption. In a written response reviewed on 25 October 2026, Atlassian support relayed confirmation from the relevant Forge team that Atlassian-managed disaster-recovery backup copies of Key-Value Store and Custom Entity Store are encrypted at rest using AES-256. This confirmation concerns those provider-managed backup copies; exported files and other systems have separate safeguards. The Forge control mapping describes platform storage encryption and backup responsibilities. Guardian does not claim its own security certification or absolute security.

Data location and recipients#

Forge hosted-storage residency follows the host product's applicable settings. Compute, platform logs and provider support access can follow different rules. No EU-only processing guarantee is made.

Atlassian receives personal-data reports for the platform's privacy process. An administrator JSON download goes to the chosen device. Support messages are processed separately through Atlassian Jira Service Management or Google Workspace. These paths must not be described as all information always staying inside Atlassian.

See the Privacy Policy and DPA for the processing details, roles and applicable transfer safeguards.

Retention, export and deletion#

Eligible resolved findings and historical data enter scheduled, batched cleanup after 90 days. This is not a promise of physical erasure at exactly 90 days. Active findings and current/previous baselines can remain while needed.

Administrators can download JSON containing stored customer records, account identifiers and evidence. It reads over an interval, has a 256 MiB browser-content limit and is not a Jira backup or restore format. Larger returns require scoped assistance.

Delete Guardian history removes supported history in background batches. Settings, schema/capability configuration, a limited receipt and necessary privacy-restriction markers remain. The masking-enabled build also retains its installation identity key/control; unused account mappings are removed in bounded passes after retained references and pending work are checked. Deletion does not change Jira, cancel billing or stop future enabled scans. Use app-level deletion before uninstall where practicable; Atlassian controls the subsequent Forge storage lifecycle.

See data controls for practical steps.

Report a vulnerability#

Email [email protected] privately. Include the affected version, impact and sanitized reproduction steps. Do not send credentials, production Jira exports or unnecessary personal data. Good-faith reporting does not authorize access to other customers' data or disruptive testing.