Tomislav's answer is the honest one. At 800+ projects almost everyone lands on scripts plus a manual pass. The part that made it painful for me was a gap the script itself creates: it can tell you a user has Browse on a project, but not why. Was it one of their twelve group memberships? A project role? A permission scheme grant? Without the "why", revocation turns into guesswork: you pull someone from a group, and they still have access by another path.
Two things that made the review tractable at that scale:
-
Invert the question. Instead of walking 800 projects, walk the groups. A handful of over-permissioned groups usually explains most of the excess access, and fixing one group grant is worth auditing fifty projects.
-
Record the grant path, not just the outcome. Your review artifact wants to read "user X to Browse on PROJ, via group jira-software-users, via the Developers role", so the revocation step is one unambiguous action instead of trial and error.
Disclosure: I work at Katabarwa Labs, and we packaged exactly this as a Forge app, Access Governance Reporter. Per user it lists every project they can reach, the permission level, and the specific group or role granting it. There is a group-usage view across all projects for the inversion pass above, and CSV export so the results drop straight into your access-review tickets. It runs entirely on Forge inside your own tenant with read-only scopes and no data egress, which tends to matter when the output is a compliance artifact.
One honest limit for your case: company-managed Jira Cloud projects only. Team-managed projects aren't in scope yet.
Access Governance Reporter
If the shape doesn't match how your reviews actually run, say what would. That feedback is more useful to us than an install.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.