Security and data handling — Permission Audit for Jira

This page is written to be forwarded to whoever reviews apps at your organisation. If it does not answer their question, ask us and we will answer in writing. The security page covers what holds for every QuinTek app, including the Marketplace Privacy & Security tab answered question by question; this page is what is specific to Permission Audit.

The short version

Permission Audit is a pure Forge app. Its code runs on Atlassian-operated infrastructure, its data lives in Atlassian-operated storage inside your own tenant, and it makes no outbound network calls. QuinTek operates no backend that could receive your data — not because we promise not to look, but because there is nothing to look at.

What it can read

Read-only access to the Jira configuration it has to resolve:

projects and project settings
permission schemes
project roles and role actors
groups and group membership
the user directory

It never writes. It does not create, modify, or delete a scheme, a role, a group, a grant, an issue, or an account, and it calls no endpoint that could.

Every scope it requests, and why

These are the scopes on the consent screen, in the order Jira shows them. There are six, and one of them deserves a paragraph.

Scope	What it is for
`read:jira-work`	Listing projects and reading each project’s settings — the project type and the schemes it uses.
`read:permission-scheme:jira`	Reading permission schemes: which permission is granted to which role, group, or user.
`read:permission:jira`	Reading the permission vocabulary, and checking the app’s own resolution against Jira’s answer at the end of every scan.
`read:jira-user`	Enumerating the user directory, including deactivated accounts — which is what makes “who has no access” answerable.
`manage:jira-configuration`	Reading group membership. See below.
`storage:app`	Atlassian’s key-value store, used for one flag that lets the report paint instantly on open.

About manage:jira-configuration. The name says manage, and it is a write-capable scope. The app declares it for a reason that is a property of Jira rather than of the app: reading who is in a group is governed by the Browse users and groups product permission, and Atlassian grants that permission to an app only by placing it in the site’s admin group at install, which it does only for apps that declare an admin-level scope. No read-only scope confers it. We measured this: without the scope, every group membership read is refused, the scan reports partial coverage on every project, and a real finding — a deactivated account that still had access — silently disappears.

So the scope is there to make the report correct, not to change anything. The app calls no endpoint that writes, and we would drop the scope the day Atlassian offers a read-only route to the same permission.

The app requests no impersonation of users: it acts as itself, never as the person using it.

What it stores, and where

The resolved report — the output of the scan, not a copy of your configuration — plus the scan’s metadata, the app’s settings and, on Advanced, the record of changes between scans.

That is stored in Forge SQL, Atlassian’s managed database, with one flag in Atlassian’s key-value store, and it is isolated per installation by construction rather than by a filter in application code. Another customer’s installation cannot address your data; there is no shared store for it to address.

The current report is overwritten on each scan rather than accumulated. History records changes rather than snapshots, so a site where nothing moves accumulates almost nothing.

An earlier design stored nothing at all. It was changed deliberately: forcing a complete rescan every time the report is opened is a real cost on a large estate, and persisting derived results inside the same boundary the data already lives in is not the trust decision that shipping it to a vendor cloud would be.

Data residency

Forge hosted storage is pinned to the same Atlassian location as the site the app is installed on, in every location Atlassian offers, and if you move the site Atlassian moves the app’s data with it. Residency is inherited rather than implemented, and QuinTek cannot choose otherwise.

For a residency review, what is in and out of scope:

In scope, pinned with your site: the report, scan metadata, settings, and permission history — everything in Forge SQL and the key-value store.
Out of scope: the diagnostic log described below, which lives in Atlassian’s logging infrastructure rather than in the pinned storage; and anything you choose to email us.

Zero external egress

The app makes no outbound calls to any third party. There is no analytics SDK, no error reporting service, no feature-flag service, and no telemetry pipeline. Nothing about your site, your usage, or your permissions is transmitted out of Atlassian’s infrastructure.

This is verifiable rather than merely asserted: it is the architectural condition for Atlassian’s Runs on Atlassian programme, which is granted on how an app is built rather than on a questionnaire it fills in.

What QuinTek can see

One thing, and you control it.

Every Forge app writes a diagnostic log, Atlassian stores it, and by default Atlassian lets the app’s developer read it for the sites the app is installed on. Permission Audit’s log carries scan identifiers, timings, counts, group names, and error text. It does not carry the report, and it is written to avoid names and email addresses. We read it when diagnosing a fault you have reported, and for nothing else.

To switch it off: in Atlassian Administration, go to Apps → Connected apps, open Permission Audit, and turn off Logs access under Details. The app works exactly the same; from then on, support works from what you choose to send us.

Beyond that log: nothing. We have no console into your installation, no database to query, and no access to your data. If you ask us to help diagnose something, we will ask you for specific information, and you decide what to send.

No API tokens

The app never asks anyone to paste a personal access token, and it never will. Atlassian’s Marketplace Security Enforcement Policy prohibits the pattern outright.

This is worth generalising: any Marketplace app that asks an administrator for an API token is asking you to hand a vendor standing credentials to your site. That is grounds to decline it, whatever the app does.

What the app itself holds

Stated plainly, because an access-review tool that hid this would be self-defeating.

At install, Atlassian places app principals that request admin-level scopes into an administrator group on the site. The practical consequence is that such apps hold Administer Jira. This applies to many apps already installed on your site, and it applies to Permission Audit — for the reason given under the scopes above.

The report surfaces it. Permission Audit appears in its own Apps tab with the access it actually holds, and the group membership behind it is visible and editable by you.

Sub-processors

None. There is no third party in the path, because there is no path out of Atlassian.

Atlassian itself is not a sub-processor of QuinTek in this arrangement — your agreement for the underlying infrastructure is with Atlassian directly, as it already was before you installed anything. For the same reason QuinTek is neither a controller nor a processor of the data the app handles, and there is no Data Processing Agreement to sign; the Privacy Policy sets that out, and we will confirm it in writing on request.

The export is your responsibility once it lands

Inside Atlassian the report is protected by your site’s own access controls. A CSV export is a complete map of who can do what across your estate, and from the moment it reaches a download folder it is protected by whatever protects that folder. Handle it as the access-control document it is.

Reporting a security issue

Email support@quintek.com with “security” in the subject. We acknowledge within two business days, fix within the timeframes Atlassian sets for Marketplace apps, and notify Atlassian and any affected customer if an issue turns out to be an incident. The full commitments, and what we ask of you in return, are on the vulnerability disclosure section of the security page.