Access Review logo: an open padlock Access Review for Jira

Who can reach which projects?

An access review is a recurring obligation — ISO 27001 A.9.2.5, SOC 2 CC6.1, SOX ITGC. Today a Jira admin answers it by opening every permission scheme one at a time, reading its grants, cross-referencing project roles, and repeating per project.

Access Review answers it in one screen, from the permission schemes already in your site:

3 of 5 projects grant Browse projects to everyone — 40% restricted.

That sentence is the finding an auditor writes up, and it is invisible in Jira's own UI without opening every scheme by hand.

What it does

Read-only, and that is the point

The app requests read:jira-work and nothing else. It cannot grant, revoke or edit a permission — the platform would reject the attempt, because the access was never granted. An access-review tool that can also change permissions is one an auditor has to treat as part of the control surface. This one cannot alter what it reports.

What it deliberately does not do yet

Being straight about this, because an auditor will find out anyway: it reports group and role names, not the people inside them — expanding membership needs an administrative scope the app refuses to request. Project roles are named, not expanded. There is no scheduling, no history and no diff between two review dates. On a site with several hundred projects the report takes a while, because Jira needs one call per project to resolve its scheme.

Built on Atlassian Forge

The app runs entirely inside Atlassian's cloud. No external servers, no third-party services, no network egress. Your permission configuration never reaches Bobook Limited, because there is nowhere for it to go. See the privacy policy and the data processing agreement.

Not a compliance certification

Access Review produces evidence your own access-review process can use. It does not certify your organisation against ISO 27001, SOC 2, SOX or any other standard, and no such claim is made.

Read the documentation →