[Episode 9] One Simple Question That Gets Surprisingly Complicated for Every Jira Admins!

[#1]

A few weeks ago, I was speaking with a Jira administrator who got what sounded like a simple request from their security team:

"Can you tell us who has access to our critical Jira projects?"

It seemed like a five-minute task. Instead, they spent the next hour jumping between project roles, groups, permission schemes, and user directories trying to piece everything together.

The interesting thing is that this doesn’t happen because Jira is difficult to use. They happen because Jira environments evolve and that’s the beauty of it!

People had changed teams, contractors had come and gone, projects had multiplied, and temporary permissions had quietly become permanent. Nothing looked obviously wrong, but some inactive users still had access, more Jira admins than anyone expected, and no quick way to answer a simple question: who has access to what, and why?

I've started noticing this pattern quite often. Most teams don't review access until an audit is around the corner or someone from security asks for a report. By then, everyone is manually checking projects, exporting users, and trying to remember whether certain permissions are still needed.

Jira already gives administrators solid building blocks with project roles, groups, permission schemes, and audit logs. For many teams, that's more than enough. But as the number of users and projects grows, reviewing access can become much more time-consuming than anyone expects.

That's what got us thinking about this problem more seriously. We've been working on Access Reviewer360 to help simplify access reviews and give administrators a clearer picture of who has access, where they have it, and whether that access still makes sense.

I'm curious, has anyone else run into this? What's been the biggest challenge when reviewing access in your Jira instance?

[Jason Krewson]

I don't typically run into this issue because we use roles within our permission schemes to grant read access and the Space Admins/Leads are responsible for managing user edit access within their Spaces. I assist when needed but ownership generally sits with them.

Basically it works like this:

1. SSO provisions the user account.
2. I grant Jira access based on approved domains.
3. Users receive read access to nearly all Jira spaces by default, with exceptions for restricted areas such as HR spaces and vendor accounts, which are handled separately.
4. Space Admins/Leads grant edit access within their Spaces by assigning the appropriate role.

We don't currently perform access audits so lucky enough I don't have to deal with this. But for most Spaces it's straightforward to explain who has access since almost everyone has read access. The more challenging part is identifying who has edit access. For a single Space that would be a pretty simple answer, but if someone needs that information across multiple Spaces I could see it becoming more time consuming.