Data Security and Privacy Statement
Product: Access Auditor for Jira Publisher: Matify Platform: Atlassian Forge, Jira Cloud Last updated: 2026-09-13
Every statement below describes the app as it ships. Nothing here describes a planned feature, and no security certification is claimed. Where a claim can be checked against the app's own published manifest, this document says how.
1. Overview
Access Auditor for Jira is a read-only auditing app for Jira Cloud. It reads your site's permission configuration — permission schemes, project roles, groups, shared filters and shared dashboards — resolves each grant to the people and groups who actually hold it, and reports configurations that are likely to be a risk.
Three properties define its security posture, and each is enforced by the Atlassian Forge platform rather than by the app's own discipline:
- It runs entirely inside Atlassian's infrastructure.
- It declares no ability to send data anywhere outside Atlassian.
- It declares no ability to write anything to Jira.
It does store personal data, in the form of Atlassian account identifiers and display names. Section 4 says exactly what and why.
2. Hosting and architecture
Access Auditor is an Atlassian Forge app. Both its compute and its storage are hosted by Atlassian, inside your own Jira Cloud installation. Matify operates no server, no database and no endpoint that this app talks to.
| Component | Where it runs |
|---|---|
| Backend functions and triggers | Atlassian Forge, nodejs22.x runtime |
| Administration interface | Forge Custom UI, served from the app's own bundled resources |
| All app storage | Forge custom entity store and Forge key-value store |
The Forge CLI reported the app eligible for Atlassian's Runs on Atlassian programme on each deployment, including the production deployment. That is Atlassian's tooling making the determination, not a self-assessment. The programme badge itself is granted by Atlassian on the listing, not by this document.
3. Data we process
Read from Jira Cloud, using read-only scopes:
| Category | What it contains |
|---|---|
| Permission scheme configuration | Schemes and their permission grants — the object being audited |
| Project metadata | Project key, name, type, archived state, and the project lead |
| Project roles and role actors | Which users and groups hold which role in which project |
| Groups and group membership | Group names, and the members of groups that carry access |
| Application roles | Which groups grant Jira product access |
| Account status | Whether an account is active or deactivated, and its account type |
| Issue security schemes and levels | Whether a project has issue security configured |
| Shared filters and dashboards | Name, owner and share permissions only |
| Custom field definitions | The name of a field used as a permission holder |
Derived by the app and stored as audit results:
| Category | What it contains |
|---|---|
| Access relationships | Each resolved holder of each permission, with the chain of configuration that granted it |
| Findings | Rule identifier, severity, the affected object, evidence and a suggested remedy |
| Change history | What differs between two consecutive scans |
| Acknowledgement metadata | Whether a finding is open, acknowledged or resolved, when, and by which administrator account |
| Administrator-entered notes | Free text an administrator optionally attaches when acknowledging or resolving a finding, capped at 500 characters |
What is never read
Issue content. Attachments. Comments. Worklogs. Email addresses. Avatars. The JQL body of a filter. The gadgets on a dashboard. Any user profile attribute beyond display name, account type and whether the account is active.
4. Personal data
Access Auditor stores personal data. Saying otherwise would be false.
An Atlassian account identifier (accountId) is personal data under Atlassian's own definition, and the app cannot do its job without one: an access review that cannot name who holds a permission is not an access review.
| Personal data stored | Why it is necessary |
|---|---|
| Atlassian account identifier | Identifies the holder of a permission, and links a finding to the account it concerns |
| Display name | So an administrator reading the audit sees a person rather than an opaque identifier |
| Active or deactivated flag | The core of the "deactivated account still holds access" finding |
| Account type | So Atlassian app accounts can be excluded from human-facing figures |
| The acting administrator's account identifier | Recorded against an acknowledgement or resolution, so a review has an author |
| Administrator-entered note text | Free text, whatever the administrator chooses to write |
Personal data appears in the app's stored audit results because it appears in the Jira configuration being audited. It is not enriched, not profiled, not combined with any other source, and not used for any purpose other than presenting the audit to the administrator who requested it.
Administrator-entered notes are free text. The documentation tells customers not to put confidential information in them, because they are stored as part of a finding's state and are visible to any Jira administrator on the site.
5. Data storage
All storage is Atlassian-hosted Forge storage. Matify operates no external database, no object store and no backup of customer data.
| Store | Holds |
|---|---|
maa-snapshot | Scan metadata |
maa-snapshot-data | The permission, project and group membership snapshot |
maa-finding-chunk | Findings, stored in chunks |
maa-drift-chunk | The change list between scans |
maa-fingerprint | Comparison fingerprints used to detect change |
maa-finding-state | Acknowledgement and resolution decisions, and notes |
maa:settings (key-value) | The site's configuration for the app |
maa:assisted-reads (key-value) | For projects Jira refuses to the app's own account only: their permission scheme, issue security scheme and role members, as last read with an administrator's access |
Tenant isolation
Forge storage is scoped to the installation, so one site's data is not addressable from another site's installation of the app.
The app adds a second guarantee on top of the platform's: nothing is cached in module scope. Forge may reuse a running container between invocations, so a tenant-derived value held outside a single request would risk crossing installations. Every read goes to storage on every request instead.
6. Data residency
Access Auditor stores data only in Atlassian-hosted Forge storage, which follows the data residency configuration of the Jira Cloud site it is installed in.
Because the app never moves data out of Atlassian's platform, there is no second location for residency to apply to and no mechanism by which data could be moved to another region. Residency is therefore inherited from your site rather than configured separately in the app.
7. External data egress
No app data is transmitted to Matify, to any analytics provider, or to any other external service.
This is enforced by the platform, not merely intended:
| Control | Evidence in the shipped app |
|---|---|
| No egress permission declared | manifest.yml contains no permissions.external block — no fetch, images, scripts, styles or frames. Forge blocks any outbound request that is not declared, so an undeclared request cannot occur at runtime even by accident. |
| No remotes | The manifest declares no remotes entry, so there is no external service the app is permitted to address. |
| No web triggers | The app exposes no webTrigger module, so there is no unauthenticated inbound URL either. |
| No third-party backend dependencies | The backend's runtime dependencies are @forge/api, @forge/events, @forge/kvs and @forge/resolver — all first-party Atlassian packages. No analytics SDK, no error-reporting service, no telemetry library. |
| No external assets in the interface | The Custom UI is bundled and served from the app's own resources. It loads no font, script, stylesheet or image from a third-party host, so no administrator's browser contacts a non-Atlassian domain on the app's behalf. |
| No outbound email | The app sends no mail. The support address appears only as text for an administrator to use. |
There is no telemetry, no usage analytics, no crash reporting and no product instrumentation of any kind.
8. Permissions and scopes
Read-only by construction
The app declares zero write scopes, zero administration scopes and zero manage:* scopes, and issues only HTTP GET requests against the Jira Cloud REST API. It never creates, edits or deletes a permission scheme, project, group, user, filter or dashboard. The only things it writes are its own audit results, to Forge storage.
Authorisation
Every screen and every action proves the caller holds the Jira ADMINISTER global permission before anything is read or returned. The app asks Jira with the caller's own credentials (asUser() against GET /rest/api/3/mypermissions). Jira, not the app, makes that decision. Only afterwards does the app read configuration with its own app-level credentials.
Background paths — the scheduled trigger, the install lifecycle trigger and the asynchronous scan worker — have no user context at all; on the Forge platform asUser() fails there with AUTH_TYPE_UNAVAILABLE. Those paths therefore never attempt a per-user check and do only what the installation itself consented to.
One read uses the administrator's credentials instead of the app's. A project whose permission scheme does not grant the app's account Administer projects answers 403 to the app. When a Jira administrator opens the Overview or starts a scan, the app reads that project's permission scheme, issue security scheme and role members with the administrator's own access (asUser()), which their Administer Jira permission already allows. It reads nothing else this way and writes nothing. The result is kept in maa:assisted-reads so that scheduled scans can audit the project too; it is dropped once the app's own account can read the project again, it is included in personal data reporting, and it is erased with all other app data.
Every declared scope
Twenty-two in total, and none of them is withheld from this list. Jira Cloud's granular scopes are cumulative rather than alternatives, so some are required only because Jira bundles them into an operation the audit needs.
Read data through these:
| Scope | Purpose |
|---|---|
read:permission-scheme:jira | Permission schemes and their grants — the core of the audit |
read:permission:jira | Grants, and the administrator check via /mypermissions |
read:project:jira | Every project-scoped read |
read:project-role:jira | Resolving a project-role grant to the people who hold it |
read:group:jira | Groups, and the members of groups that carry access |
read:user:jira | Telling an active account from a deactivated one |
read:application-role:jira | Which groups grant Jira product access |
read:field:jira | Naming the custom field behind a custom-field grant |
read:issue-security-scheme:jira | Whether a project has issue security configured |
read:issue-security-level:jira | Required alongside the scheme scope for the same check |
read:filter:jira | Shared filters that expose issue data beyond the team |
read:jql:jira | Required by Jira to list filters at all; a filter's JQL body is never read |
read:dashboard:jira | Shared dashboards that expose data beyond the team |
read:project-category:jira | Required as part of the cumulative set for project, scheme and role reads |
storage:app | Storing audit results in Atlassian-hosted app storage |
Required only because Jira bundles them into an operation the audit needs. Removing any one of these causes the operation the app depends on to fail with HTTP 401. None lets the app read anything beyond configuration metadata.
| Scope | Bundled into |
|---|---|
read:avatar:jira | /group/member, /user/bulk — no avatar is ever read, stored or displayed |
read:issue-type-hierarchy:jira | /project/search, /filter/search, /dashboard/search |
read:issue-type:jira | /project/search, /dashboard/search |
read:project-version:jira | /project/search |
read:project.component:jira | /project/search |
read:project.property:jira | /project/search |
Required by Atlassian of any app that stores personal data:
| Scope | Purpose |
|---|---|
report:personal-data | Reporting stored account identifiers to Atlassian on the schedule described in section 10. Nothing is read through this scope, and nothing leaves Atlassian. |
Not requested
The app does not request manage:jira-configuration or any other administration scope. Reading Jira's audit log was considered during design and rejected; that scope is not requested either.
9. Data retention
| What | Retention |
|---|---|
| Permission, project and group membership snapshot | The most recent scan only. The previous generation is pruned. |
| Findings, change history and scan history | The configured retention period. Default 90 days; selectable as 30, 90, 180 or 365. |
| Comparison fingerprints | Two generations, because only the previous scan is ever compared against |
| Acknowledgement and resolution decisions, and notes | Until an administrator changes them, or until the configured acknowledgement expiry elapses |
| Settings | Until an administrator changes them |
Pruning runs automatically after each successful scan. A failed scan never triggers deletion, so a bad scan cannot silently destroy audit history.
Deleting everything
Two routes, both complete:
- Settings → Danger zone → Delete all Access Auditor data. Removes every
scan, finding, change record and acknowledgement stored for the site. The screen shows a count of exactly what is stored before the administrator confirms, and the request is rejected unless it carries a literal DELETE confirmation, so a mis-wired interface or a replayed request cannot trigger it. The app stays installed and scans again afterwards. Nothing in Jira is touched.
- Uninstalling the app. Forge removes all of the app's storage for the site
as part of uninstallation — snapshot data, findings, change history, acknowledgements and settings are deleted, not hidden.
10. Personal data requests
Because Access Auditor stores Atlassian account identifiers, it implements Atlassian's Personal Data Reporting API.
Once a week the app reports every account identifier it holds to Atlassian, in batches, and acts on Atlassian's answer for each account:
| Atlassian's answer | What the app does |
|---|---|
| The account was updated | Queues a scan, so the stored display name is refreshed from Jira rather than left stale |
| The account was closed | Deletes that account's finding-state records individually, then purges the stored audit data and rebuilds it by scanning, so a closed account does not survive inside an old snapshot. The site's settings and exclusion lists are kept. |
This cycle runs whether or not the site's licence is active. The scheduled trigger deliberately carries no licence filter: erasing data about someone who has left is an obligation that does not lapse with a subscription.
The report is a call between the app and the Atlassian platform. No data reaches Matify or any third party through it.
A customer who needs data removed sooner than the weekly cycle can use either deletion route in section 9, both of which are immediate.
11. Logging
The app writes operational log lines to the Forge platform log. They record counts, durations, HTTP status codes, error codes and reasons — and nothing that identifies a person, a project or a group.
Concretely, the complete set of logged events is: a scan starting, being skipped with a reason, completing with its counts and duration, or failing; expired acknowledgements as a count; a scan being queued; an install lifecycle event as a type; the personal data report with its counts; and app data being deleted with its counts.
Never written to a log: account identifiers, display names, project keys, project names, group names, permission holders, note text, or any Jira content. Error messages that reach a log are truncated before they are written.
A support investigation into this app never requires reading customer data out of a log line. The diagnostic report an administrator can copy from the Diagnostics tab is built to the same rule.
12. Encryption and transport security
Access Auditor adds no transport of its own, so it inherits Atlassian's:
- The administration interface is served by Atlassian over HTTPS.
- All communication with the Jira Cloud REST API goes through the Forge platform
over HTTPS.
- All data at rest is held in Atlassian-hosted Forge storage and is subject to
Atlassian's encryption-at-rest controls for that storage.
Because there is no external egress, no self-hosted endpoint and no Matify-held credential, the app introduces no additional transport path that would need to be secured separately. Atlassian's own platform documentation is the authority for the specifics of its encryption implementation; Matify does not restate them here as though they were its own controls.
Secrets
The app holds no secrets. No API token, no OAuth client secret, no external credential of any kind, because it talks to no external service. Nothing is stored using Forge's secret storage. No credential appears in the source, the manifest, the interface bundle, the logs, the documentation or the Marketplace listing.
13. External services and subprocessors
None.
Access Auditor uses no external service, and Matify engages no subprocessor for customer data, because no customer data ever reaches Matify. There is no analytics provider, no error-reporting service, no hosting provider besides Atlassian, no content delivery network and no third-party API.
The only party that processes data on the customer's behalf in connection with this app is Atlassian, as the operator of the Jira Cloud site and of the Forge platform on which the app runs. The customer's existing agreement with Atlassian governs that relationship.
14. Compliance posture, stated plainly
Matify holds no SOC 2 report, no ISO 27001 certificate and no other third-party security certification, and this document does not claim one. What it offers instead is a set of properties that can be checked rather than taken on trust:
- The read-only claim is checkable in the manifest: count the write scopes.
- The no-egress claim is checkable in the manifest: there is no
externalblock,
and Forge enforces its absence.
- The storage claim is checkable in the manifest: every entity store is declared
there.
- Data residency is inherited from your own Jira site, which you control.
Access Auditor is a tool that supports an access review. It is not itself a compliance guarantee, and it is described that way in its documentation.
15. Security contact
| Publisher | Matify |
| Security and support contact | mira.maty@web.de |
Report a suspected vulnerability to that address. Please include enough detail to reproduce the issue. A diagnostic report from the app's Diagnostics tab is helpful and contains no personal data and no credentials.
16. Related documents
- Privacy policy — the formal policy covering the app and this site
- Documentation — setup, every screen, every scope, and the known limits
- Privacy and data — the same subject as this page, written for the administrator using the app rather than for the person approving it
- Support — how to reach Matify
17. Last updated
2026-09-13.
This statement is revised whenever the app's scopes, storage, retention or data handling change. The Marketplace listing links to the published version, so the listing always points at the current text.