The question usually arrives from an auditor or a security lead: "Who can see the PAY space, and why?" In Jira the answer is spread across permission schemes, space roles, groups and application access. Below are the four questions an access review has to answer, how to answer each one natively, and where that gets slow.
I'm Marcin, founder of Radrly, which builds AccessRadar, an access review app for Jira Cloud. The first four sections need no app.
Question 1: Which grants apply to this space?
For a company-managed space:
- Open the space and go to Space settings > Permissions. You see the permission scheme and every grant in it, for example "Browse spaces: Space role Developers".
- Go to Space settings > People to see who holds each space role.
- For every group that appears, open Directory > Groups in Atlassian Administration and check its members.
For a team-managed space, go to Space settings > Access. The access level (Open, Limited or Private) and the role of each person or group are listed there. Atlassian explains the options in Manage how people and agents access your team-managed space.
The slow part is the chain. A grant points to a role, the role contains a group, and the group contains 300 people. You resolve that by hand, per space. Atlassian's public tracker has a long-standing request for a list of the space permissions each group grants: JRACLOUD-71967.
Question 2: Why does this person have access?
Jira has a tool for this: Settings > System > Admin helper > Permission helper. Pick a user, a work item and a permission, and Jira tells you whether the user has it and explains the result. See Check a user's access from a work item.
It answers one user, one work item and one permission at a time. For "what can Alex reach across all 200 spaces" there is no native screen. Two partial workarounds:
- JQL.
space in spacesWhereUserHasPermission("Browse spaces") returns work items in spaces where a permission applies, but it always evaluates the logged-in user. You can't run it for someone else. Reference: JQL functions. - REST API.
GET /rest/api/3/user/permission/search?permissions=BROWSE_PROJECTS&projectKey=PAY lists users holding a permission in one space. It returns the users without the path that grants access, and each call only checks the first 1,000 users, so large sites need a script.
Question 3: What changed since the last review?
Jira keeps no point-in-time record of effective access. The audit log (Settings > System > Audit log) records many group and permission changes, but retention is six months at most, and Atlassian notes that the author is not always shown for user management changes (Audit activities in Jira applications).
The common workaround: export the access list every quarter and diff it in a spreadsheet. It works as long as someone remembers to do it.
Question 4: How do you show an auditor that a review happened?
Natively, this ends up as a spreadsheet plus an approval in email or a ticket. Auditors usually accept that, but nobody can later check that the file is the one that was approved.
How AccessRadar covers the four questions
AccessRadar is a Forge app that reads permissions, groups and roles. It requests only read scopes (plus the personal-data reporting scope) and never writes to Jira. It runs on Atlassian with zero egress, so there are no email, Slack or webhook integrations; reminders and alerts appear inside the app.
Effective access with the path. Explore by space, group or person. For each grant you see the path: group membership, space role, application role and permission scheme grant, for both company-managed and team-managed spaces.
Explore view for one space: each grant shows the path that gives the person access.
Snapshots and comparison. Take snapshots manually or on the weekly schedule, then compare any two to see new grants, removed members, role changes and broader access. Every snapshot carries a coverage statement: for example, work item security levels are not evaluated, and conditional grants are listed without being expanded.
Comparing two snapshots: new grants, removed members and role changes.
Reviews. Each grant gets Keep, Revoke or Exception. Revoke and Exception require a written justification. Exceptions expire after 1 to 366 days and are tracked in an exceptions register. Revoke is a to-do: you remove the access in Jira yourself. Reviews export to CSV and PDF
Risk rules. Eleven rules flag patterns such as anonymous access, inactive users who still have access, and spaces without a space admin.
Signed reviews and campaigns (Advanced). Sign-off creates a SHA-256 signature chained to earlier reviews, which you can verify in the app. The evidence pack PDF maps to SOC 2 CC6.1, CC6.2 and CC6.3 and ISO/IEC 27001:2022 A.5.15, A.5.18 and A.8.2. It is audit evidence and does not certify anything. Advanced also adds recurring campaigns, delegated reviews by space admins, real-time in-app alerts and remediation checks against the next snapshot.
A signed quarterly review with its evidence pack (Advanced edition).
Rovo agent and skills (Advanced). A read-only AccessRadar agent in Rovo answers questions such as "why does this person have access?" and "what changed since the last snapshot?". It needs Rovo enabled on the site.
| Standard | Advanced |
|---|
Effective access with the path | Yes | Yes |
Snapshots | Manual and weekly, 90-day history | Adds daily and custom schedules, history configurable from 30 to 3,650 days |
Keep, Revoke, Exception and CSV/PDF export | Yes | Yes |
Signed reviews, evidence pack, campaigns | No | Yes |
Rovo agent and skills | No | Yes |
The listing is here: AccessRadar on the Atlassian Marketplace.
If you run access reviews another way, for example with scripts against the REST API, tell me how in the comments.
