Privacy and Data
Copyright 2026 Matify. All Rights Reserved.
This page is the customer-facing explanation of what Access Auditor for Jira reads, what it stores, where, for how long, and how to remove it. It is written directly from the app's internal security and data manifest and must not claim anything beyond it. The full public version of that detail, including hosting, egress, retention and subprocessors, is the data security and privacy statement.
For the draft privacy policy intended for your legal review before publication, see Privacy_Policy.md.
Where everything lives
Access Auditor is a Forge app. All of its compute and all of its storage are hosted by Atlassian, inside your own Jira Cloud installation. The app sends no data outside Atlassian — see Permissions_and_Security.md for the authorisation and scope detail.
What is read
| Category | Contains personal data | Read from |
|---|---|---|
| Permission scheme configuration | Only where a grant names an individual account | Jira Cloud |
| Project metadata | Only the project lead's account identifier | Jira Cloud |
| Group membership | Yes — account identifier and display name | Jira Cloud |
| Account status (active or deactivated) | Yes — account identifier, display name, active flag, account type | Jira Cloud |
| Shared filter and dashboard ownership and sharing | Yes — the owner's account identifier and display name | Jira Cloud |
Group membership is only read for groups that actually carry access — a group referenced by a permission grant, a project role, a shared filter or an application role. Membership of an unrelated group is never read. Collection is capped per group and site-wide; when a cap is reached the app records Jira's own membership total for that group rather than reading every row, so the count you see stays accurate even when the member list is not complete. See Known_Limitations.md for the exact caps.
What is stored, and where
| What | Storage location | Retention | Removed |
|---|---|---|---|
| Permission scheme and project snapshot | Forge custom entity store (maa-snapshot-data) | Most recent scan only; the previous generation is pruned | Overwritten by the next scan; removed on uninstall |
| Group membership snapshot | Forge custom entity store (maa-snapshot-data) | Most recent scan only | Overwritten by the next scan; removed on uninstall |
| Findings, change history and snapshots | Forge custom entity store (maa-snapshot, maa-finding-chunk, maa-drift-chunk, maa-fingerprint) | Your configured retention period, default 90 days; change comparisons only ever look one scan back, so drift data older than two generations is kept for no purpose and pruned | Pruned automatically after each successful scan; removed on uninstall |
| Acknowledgement, resolution or reopen decisions, and any note you attach | Forge custom entity store (maa-finding-state) | Until you change it, or until your configured acknowledgement expiry elapses | Removed on uninstall |
| Settings | Forge key-value store (maa:settings) | Until you change it | Removed on uninstall |
| For projects Jira refuses to the app's own account only: their permission scheme, issue security scheme and role members, read with an administrator's access | Forge key-value store (maa:assisted-reads) | Until the app can read those projects itself again; pruned after every scan | Erased with all app data; removed on uninstall |
All storage is Atlassian-hosted Forge storage and inherits your Jira site's own data residency. No data is moved to a region other than the one your Jira site is already pinned to, because the app never leaves Atlassian's platform to move it anywhere.
Retention you control
Set History retention on the Settings tab to 30, 90, 180 or 365 days. The default is 90 days. Findings, the change list and snapshots older than this are pruned automatically after each successful scan; a failed scan never triggers deletion, so a bad scan cannot silently wipe your history.
Set Acknowledgement expiry on the Settings tab to control how long an acknowledged finding stays acknowledged before it reopens for review. The default is 0, meaning an acknowledgement never expires on its own.
Keeping stored account data current
Because Access Auditor stores Atlassian account identifiers, it takes part in Atlassian's personal data reporting cycle. Once a week the app reports every account identifier it holds to Atlassian and acts on the answer:
- The account changed — the app queues a scan, so the display name it shows
you is refreshed from Jira rather than left stale.
- The account was closed — the app deletes that account’s finding history
and then purges its stored audit data before rebuilding it by scanning, so a closed account does not survive inside an old snapshot. Your settings and exclusion lists are kept.
This runs whether or not your licence is active. Erasing data about someone who has left is an obligation, not a paid feature, so the weekly report is deliberately not gated behind a subscription.
Nothing leaves Atlassian to make this happen: the report is an Atlassian platform call, not an external service.
Deleting your data
- A specific acknowledgement or note: reopen the finding from the
Findings tab, or overwrite the note when you change its status.
- Everything the app has stored, without uninstalling: open the Settings
tab and use Danger zone → Delete all Access Auditor data. It shows you a count of exactly what is stored before you confirm, and requires you to type the confirmation it asks for. This removes every scan, finding, change record and acknowledgement. The app stays installed and will scan again.
- Everything the app has stored, by removing the app: uninstall it. Forge removes all
of the app's storage for your site as part of uninstallation — the snapshot data, findings, change history, acknowledgements and settings are all deleted, not merely hidden.
What is never read
Issue content. Attachments. Comments. Worklogs. Email addresses. Avatars. A filter's JQL body. A dashboard's gadgets. Any user profile attribute beyond display name, account type, and whether the account is active.
None of the above is read, stored or displayed by any part of the app, under any setting.
Administrator-entered notes
When you acknowledge or resolve a finding you may add a free-text note, up to 500 characters. This note is stored as part of the finding's state. Because it is free text, do not put confidential information in it — treat it the way you would a comment in any shared admin tool.
App accounts are not treated as people
Atlassian app accounts (including Access Auditor's own account) can appear in project roles and groups like any other principal. They are excluded from every human-facing count and reported separately where relevant, so an installed Marketplace app is never counted as a risky user or inflates an administrator group's headcount.
Logging
Operational logs record counts, durations, HTTP statuses and error codes. They deliberately exclude project keys, project names, group names, account identifiers, display names and permission holders, and error messages written to logs are truncated. A support investigation into this app never requires reading your data out of a log line.
Questions
mira.maty@web.de