keelapps/Guides

Jira permission audit: who can access what in Jira Cloud

Jira Cloud · Updated 7 October 2026

A Jira permission audit has to answer three questions: who could reach each project on the review date, what changed since the last review, and who checked it. Jira Cloud answers none of them directly. This guide covers what auditors ask for, what the built-in screens can show, two ways to fill the gap, and a checklist for running the review every quarter.

We make AccessLens, one of the options below, so we are not neutral. The native and scripted routes come first and work without any app.

What an auditor asks for

Whether the driver is SOX IT general controls, SOC 2 (the CC6 logical access criteria) or ISO 27001:2022 (control 5.18, access rights), a user access review comes down to the same evidence:

1. A dated list of who could reach what. For each project, every person and group with access, and at what level, as it stood on the review date.
2. The change since the last review. What was granted and what was revoked between the two dates, so the reviewer can check each change had a reason.
3. A decision on the record. Who reviewed each project, when, and whether the access was confirmed or sent for removal.
4. Follow-through. Proof that anything flagged was actually removed, usually a ticket linked to the review.

Two details trip teams up. The list must be the one the reviewer actually looked at, not one regenerated weeks later. And “access” means effective access: a contractor who reaches a finance project through a group inside a project role counts, even though their name appears in no scheme.

Why Jira Cloud makes it hard

Access to a Jira project is assembled from layers. A permission scheme grants each permission to holders such as a group, a project role, a single user, or broad holders like “any logged-in user”. Each project then fills its roles with people and groups. And each group has members, which can change without anyone touching Jira at all.

Jira’s screens are organised by project, so you can look at one project and see its scheme and its roles. There is no screen that starts from a group or a user and lists every project they can reach. The request for one, JRACLOUD-71967, has been open since 2019 with more than a thousand votes.

History is the other gap. Jira’s audit log keeps 180 days of events, and it is a stream of changes, not a record of state. It cannot tell you who held access on 30 June unless someone captured the answer on 30 June.

Option 1: Jira’s own screens

Jira Cloud has four places that each answer part of the question.

• Project settings → Permissions (company-managed projects) shows the scheme a project uses and its grants. Project settings → People or Access shows who is in each role. One project at a time.
• The Permission helper, in Jira’s admin settings, explains why one user can or cannot do one thing on one issue. Useful for a support ticket, not for a site-wide review.
• Atlassian Administration (admin.atlassian.com) can export your users to CSV with their groups and product access. It says who has Jira, not which projects they can reach.
• The audit log lists permission and role changes for the last 180 days, which helps explain a change you already know about.

For a site with a handful of projects, walking each project’s permissions and roles into a spreadsheet on the review date is a workable review. Past twenty or so projects, or with groups nested inside roles, the hand count gets slow and easy to get wrong.

Option 2: a REST API script

The REST API exposes every layer, so a script can build the full answer: read each permission scheme with its grants, map schemes to projects, read each project’s role actors, then expand the groups. The step-by-step version, with the endpoints and the four traps that make scripts quietly wrong, is in our guide Which Jira projects can a group access?

To turn a script into audit evidence, add three things:

1. Save every run with its date, unedited, somewhere the reviewer cannot overwrite. That is your point-in-time record.
2. Diff two runs to get the changes since the last review. Compare by project and holder, not by line, or a renamed group shows up as one group losing access and another gaining it.
3. Record decisions next to the run they judged: reviewer, date, confirm or remove, and the ticket for each removal.

The script costs nothing but upkeep. Watch for broad holders such as “any logged-in user” and “Public”, which grant access without naming anyone, and for groups whose members your token cannot read, which leave per-user answers incomplete.

Option 3: an audit app

An app from the Atlassian Marketplace does the same reads from inside Jira, on a schedule, and keeps the results. When you compare apps for an audit, check:

• Effective access. Does it expand project roles and group membership, or only list what schemes literally say?
• Point-in-time snapshots that are kept until you delete them, and a diff between any two.
• A sign-off record with the reviewer’s account and a server-side timestamp, which an auditor can trust more than a spreadsheet column.
• Where the data goes. Permission data is sensitive. An app that runs on Atlassian Forge with no external network access, which is what the Runs on Atlassian badge certifies, keeps it inside your tenant.
• Write scopes. An audit tool should not be able to change what it audits. Check the scopes on the listing.

The options side by side

Jira’s screens are enough for a small site with a simple scheme. A script suits a team with an engineer who will maintain it. An app pays off when the review repeats every quarter and the evidence has to hold up without anyone defending the script.

A quarterly review checklist

Whichever option you choose, the review itself runs the same way.

1. Capture on the date. Take the snapshot or run the script on the last day of the quarter, before anyone asks for it.
2. Start with broad grants. List projects open to “any logged-in user” or to the public. These usually matter more than any single group.
3. Review the changes. Walk every grant and revocation since the last review and confirm each one had a reason.
4. Walk the sensitive projects. Finance, HR, security and customer data first. Confirm each holder or flag it for removal.
5. Check leavers and contractors. Cross-check the user export from Atlassian Administration against HR’s list of people who left.
6. Remove, then re-capture. Raise a ticket per removal, make the change, and take a fresh snapshot to show it landed.
7. File the evidence together: the dated list, the diff, the decisions and the tickets.

Questions

Does Jira Cloud have a permissions report?

Not one that starts from a group or a user. Jira Cloud shows the permission scheme and roles of one project at a time, and the Permission helper explains one permission for one user on one issue. A report of every project a group or user can reach has been an open request (JRACLOUD-71967) since 2019.

How do I see which projects a user can access in Jira Cloud?

Natively, you check each project’s permission scheme and roles for the user and for every group the user is in. With the REST API you can script that across all projects. An app such as AccessLens does it for the whole site and expands roles and group membership for you.

How long does Jira Cloud keep its audit log?

Jira’s own audit log keeps 180 days of events. It records changes as they happen; it does not record who held access on a given date, so a point-in-time answer has to be captured on that date.

How often should we review Jira access?

Your own policy sets the interval. Teams under SOX commonly review quarterly, and SOC 2 and ISO 27001 programs expect a defined, regular cadence with evidence that each review happened.

Can an audit app change our Jira permissions?

AccessLens cannot. It issues no write requests. It holds the classic manage:jira-configuration scope only because that is the scope Jira accepts for reading group members; the documentation lists every scope and why.

Where AccessLens fits

AccessLens for Jira is option 3 for the whole site. It takes snapshots of every live project’s permissions on a schedule (weekly, or monthly on a day from the 1st to the 28th) and keeps them until you delete them. Explore answers by group, by user or by project with roles and group membership expanded. Compare two snapshots lists each real change once. Reviews walks the project list, riskiest first, and exports a sign-off record with each reviewer’s account and a UTC timestamp. Everything exports to CSV.

What it does not do: it reads project permission schemes and roles, so product access, global permissions, filter and dashboard shares and issue security levels are still yours to check, and archived projects are not scanned. Where a site does not permit reading group members, it says so on every answer rather than under-reporting. It runs on Atlassian Forge with no external calls, and it is free for sites of up to 10 users.

Try AccessLens free

Auditing Confluence too? The same review covers spaces and restricted pages with AccessLens for Confluence.