Privacy Policy
- App: Access Auditor for Jira
- Vendor: Matify
- Contact: mira.maty@web.de
- Version: 1.1, 13 September 2026
Matify provides Access Auditor for Jira, an app that runs on Atlassian Forge inside a customer's own Jira Cloud site. This policy explains what the app reads, what it stores, where it stores it, and for how long.
The short version: the app is read-only, everything it stores stays inside the customer's own Atlassian tenant, and Matify has no access to it.
1. Scope
This policy covers the Access Auditor for Jira app only. It does not cover Atlassian's own processing of data on its platform, which is governed by Atlassian's privacy policy and by the customer's agreement with Atlassian.
2. How the app runs, and what that means for your data
Access Auditor is a Forge app. It executes inside Atlassian's infrastructure, on the customer's own Jira Cloud site, and it stores its results in that site's own Forge storage.
Matify operates no server, database or storage of its own for this app, and has no ability to read, export or receive customer data through it. There is no Matify-side copy of anything the app processes, because there is no Matify side.
The customer's organisation decides to install the app and determines what it is used for. The underlying account records the app reads belong to the customer's Jira site.
3. What the app reads and stores
| Category | Contains personal data | Why |
|---|---|---|
| Permission scheme configuration and grants | Only where a grant names an individual account | To identify who is granted which Jira permission |
| Projects and their scheme bindings | Only the project lead's account identifier | To scope findings and the access matrix to a project |
| Groups and their membership | Account identifier and display name | To resolve a group-based grant to the people who hold it |
| Account status | Account identifier, display name, active flag, account type | To detect a deactivated account that still holds access |
| Shared filters and dashboards: owner and sharing settings | Owner's account identifier and display name | To detect objects shared beyond their team |
| Administrator decisions — acknowledge, resolve, reopen, and any note entered | The acting administrator's account identifier, and the text they enter | To keep a reviewed finding marked as reviewed across later scans |
Yes, the app stores personal data: Atlassian account identifiers and display names, for the accounts that hold access. That is unavoidable for a tool whose purpose is to answer "who can do what".
The app does not read issue content, attachments, comments, worklogs, email addresses, avatars, a filter's JQL body, a dashboard's gadgets, or any profile attribute beyond display name, account type and active status. It holds no Jira write, administration or management permission of any kind.
4. Purpose
Data is processed for one purpose: producing an access-configuration audit of the customer's own Jira site, for that customer's own administrators, and keeping the audit history so changes can be compared between scans.
The app performs no profiling, no behavioural tracking and no automated decision-making. It produces findings for a human administrator to read; it never acts on an account, group or project by itself.
5. Where data is stored
In Atlassian Forge storage, inside the customer's own Jira Cloud installation. Storage follows whatever data residency the customer's Jira site is already configured for.
No data is transmitted outside Atlassian's platform. The app declares no external network egress and makes no request to any third-party service.
6. Recipients
None. The app shares data with no third party. It contains no analytics, no error-reporting service, no advertising or marketing technology, and no third-party runtime dependency in its backend beyond Atlassian's own Forge packages.
7. Retention
| Data | Default | Can the customer change it? |
|---|---|---|
| The configuration snapshot the audit is built from | The most recent scan only | No — always the latest |
| Findings and change history | 90 days | Yes: 30, 90, 180 or 365 days |
| Administrator decisions | Until changed, or until the configured acknowledgement expiry elapses | Yes |
| Settings | Until changed | Not applicable |
8. Deletion
Three ways, all under the customer's control:
- Any individual acknowledgement or note can be reopened or overwritten from
inside the app at any time.
- Settings → Danger zone permanently deletes every scan, finding, change
record and acknowledgement the app has stored for the site, and resets settings to their defaults. It requires the administrator to type a confirmation.
- Uninstalling the app removes all of its stored data through Atlassian's standard
uninstallation process.
Because Matify holds no copy, no request to Matify is needed for any of this, and none is possible.
9. Keeping stored account data current
Because the app stores Atlassian account identifiers and display names, it takes part in Atlassian's personal data reporting cycle, as Atlassian requires of any app that stores personal data.
Once a week the app reports to Atlassian the list of accounts it holds data about, together with when it last refreshed each one. Atlassian replies with the accounts that have since changed or been deleted. This exchange happens entirely inside Atlassian's platform; the list goes to Atlassian's own endpoint and to nobody else.
What the app then does depends on the answer:
- The account changed — for example the person's display name was edited. The
app runs a fresh scan, which re-reads every account from Jira and replaces the stored copy. Nothing is deleted.
- The account was deleted — the app erases. A deleted person can still be
named in a finding from an earlier scan, in a change record, or in an acknowledgement, and none of those would be rewritten by a scan. So the stored audit history is discarded and rebuilt from Jira as it stands now, which no longer contains that person. Your settings are kept; the history is not.
Erasing part of a person's record and leaving the rest would not be an erasure, which is why a deletion costs the audit history rather than being patched around.
10. Security
- The app is read-only against Jira. It declares 20 Jira read scopes and one
storage scope; it declares no write, manage: or delete scope of any kind.
- Every request is authorised against the calling administrator's own Jira
permissions before any data is read.
- The app holds no secret, API token or external credential.
- Nothing is retained in memory between invocations, so no data can leak between
installations through a reused compute container.
- The app runs on Atlassian Forge and is confirmed by Atlassian's tooling as
eligible for the Runs on Atlassian programme.
11. Children's data
Access Auditor is a business administration tool for licensed Jira users inside an organisation. It is not directed at children and is not knowingly used to process a child's data.
12. Your rights
Requests concerning personal data processed through this app — access, correction, deletion, restriction or objection — should be directed to the organisation whose Jira site the app is installed on. That organisation holds the data and controls it; Matify cannot access it and therefore cannot act on such a request directly.
Matify will support a customer organisation handling such a request. Contact: mira.maty@web.de
13. Changes to this policy
Material changes are published on this page with a new version number and date, and noted in the app's release notes on the Atlassian Marketplace. The version and date of the current policy appear at the top of this page.
14. Contact
Matify mira.maty@web.de
Registered entity and address: to be completed by the vendor.