Frequently Asked Questions

Is anything written back to Jira?

No. Access Auditor declares zero write 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 history and your acknowledgement notes, and those are written to Atlassian-hosted app storage, not to Jira. See Permissions_and_Security.md.

Does any data leave Atlassian?

No. The app is a Forge app: all compute and storage are Atlassian-hosted. It declares no external egress, no remotes and no web triggers, and its backend has no third-party runtime dependency. See Privacy_and_Data.md.

Does it work with team-managed projects?

Partially. Team-managed (next-gen) projects are listed and labelled clearly, but they control access inside the project itself rather than through a permission scheme, so Access Auditor shows no permission matrix and raises no findings for them. Company-managed projects are fully covered. See Known_Limitations.md.

Can it tell me who my site administrators are?

No. Jira Cloud's REST API exposes no endpoint for global permission grants, so no app — including this one — can read that list directly. What Access Auditor does instead is mark a group as privileged when it grants product access through an application role, holds project administration in a permission scheme, or matches an Atlassian default admin group naming convention (a labelled heuristic). If you have renamed your administrator groups, they will not be recognised by name; review them directly in Jira's own global permissions screen. See Known_Limitations.md.

Does it tell me who made a change?

No. The Changes tab compares two scans and reports what is different between them — it does not identify who made the change or exactly when, because that would require reading Jira's audit log, which this app does not request. A change that happened and was reverted between two scans leaves no trace either. See Known_Limitations.md.

How often does it scan?

Daily by default. You can set it to weekly or manual on the Settings tab. The underlying platform trigger fires once a day; a weekly setting simply skips days, and you cannot choose the hour it runs. A first scan is queued automatically the moment the app is installed, and you can start one by hand from the Overview tab at any time, subject to only one scan running at once.

What does it cost to run, beyond the licence fee?

Nothing separate. The app calls Jira's own REST API from inside Atlassian's platform; it does not draw on any API budget you manage yourself, and it makes no calls to any metered external service. Your Access Auditor licence cost is set on the Marketplace listing.

What happens to my data when I uninstall?

All of the app's storage — snapshots, findings, change history, acknowledgements and settings — is removed by the platform as part of uninstallation. You do not have to uninstall to clear it: Settings → Danger zone → Delete all Access Auditor data removes the same thing while leaving the app in place. See Privacy_and_Data.md.

Does the app tell Atlassian whose accounts it has stored?

Yes, and it has to. Because Access Auditor stores Atlassian account identifiers, it takes part in Atlassian's personal data reporting cycle: once a week it reports the identifiers it holds to Atlassian, and Atlassian answers which of them have changed or been closed. A changed account triggers a rescan so the name you see is current. A closed account has its finding history deleted and the app's stored audit data purged and rebuilt, so someone who has left does not survive inside an old snapshot. Your settings and exclusion lists are kept.

This is a call between the app and the Atlassian platform — no data goes to Matify or to any third party — and it runs whether or not your licence is active, because erasing data about someone who has left is an obligation rather than a paid feature. See Privacy_and_Data.md.

Can non-admins use it?

No. Every screen checks, on every request and using your own credentials, whether you hold the Jira Administer Jira global permission. Without it you see an explanation, not data. There is no separate read-only or viewer role.

Does it support data residency?

Yes, by inheritance. Access Auditor stores everything in Atlassian-hosted Forge storage, which follows your Jira site's own data residency setting. The app never moves data to a different region, because it never leaves Atlassian's platform to do so.

How large a site does it handle?

Collection is bounded so a scan cannot exhaust your site's API budget: 2,000 projects, 2,000 groups, 2,000 members read per group, 40,000 members read per scan site-wide, 4,000 shared filters and 4,000 dashboards. If a cap is reached, the scan still completes; it is marked incomplete and the Overview tab tells you which part was truncated. See Known_Limitations.md.

What is a symbolic holder?

A permission holder that does not resolve to a fixed list of people from configuration alone: current assignee, reporter, project lead (which changes with the project's own configuration), and a user or group custom field value (which depends on what is set on each issue). Access Auditor labels these resolves per issue rather than guessing, and flags a sensitive permission granted this way as its own finding (R11).

Why does an app account appear in a group or project role?

Atlassian Marketplace apps, including Access Auditor itself, have their own accounts, and those accounts can appear in project roles and groups like any other principal. The app excludes accounts of type "app" from every human-facing figure and reports them separately where relevant, so an installed app is never counted as a risky user or inflates an administrator group's headcount.

What is the difference between the standard and strict sensitivity profiles?

Both profiles run all twelve rules. The difference is which permissions count as "sensitive" for rule R2 (sensitive permission granted to every logged-in user). The strict profile treats a wider set of permissions as sensitive — for example editing, transitioning, assigning, resolving and closing issues, and managing watchers — in addition to the permissions the standard profile already covers. Expect more R2 findings under strict on the same site. Set this on the Settings tab.

How do I prove an access review to an auditor?

Use the Findings tab to acknowledge or resolve each finding with a note explaining your decision — that record persists across scans. Then use the Exports tab to export the findings list, the full permission matrix, or the change list as CSV or JSON, each reflecting the scan it was taken from, as your evidence for the review.

Does it need my own Jira API token or a separate OAuth app?

No. Access Auditor is a Forge app; it authenticates to Jira using Forge's own built-in mechanisms. You never create or paste an API token, and the app never asks for one.

Does it work on Jira Service Management projects?

The distinction Access Auditor makes is company-managed versus team-managed, not one product versus another. A company-managed project of any type, including Jira Service Management, uses a permission scheme and is fully covered. A team-managed project of any type is out of scope, for the reasons given above.

Where do I ask something not covered here?

mira.maty@web.de