The Atlassian Community Forums are currently in read-only mode. We will be relaunching on a new platform on September 22 (read more here). We apologize for the extended downtime. For concerns or questions, please email communitymanagers@atlassian.com. See you on the other side, on the new Atlassian Community Forums! :)

×

Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How much auditing is actually needed for access management?

James Anderson
Contributor
August 24, 2026

I’ve been thinking about access governance and one question keeps coming up:

How much audit information do teams actually need?

For example, should an access audit record only capture major events like:

  • Access requested

  • Access approved/rejected

  • Access provisioned

  • Access revoked

Or should it go deeper and capture:

  • Who requested it?

  • Who approved it?

  • What access was granted or removed?

  • Which application, group or role changed?

  • Why was it requested?

  • When did it happen?

  • Was the access temporary?

  • When was it last reviewed?

  • What happened during the review?

But there’s another part of auditing that I find even more interesting:

What about access that was granted but is never actually used?

Someone may have access to an application or group for 6 months, but perhaps they haven't used it once.

Should that automatically trigger a review?

For example:

User has Salesforce access → hasn't used Salesforce for 90 days → should the system flag it for review?

Or is usage alone not enough to make that decision? Maybe the access is intentionally kept for occasional or emergency use.

So I'm curious how others handle this:

Do you track unused/dormant access as part of your access governance strategy?

And if you do, what would you consider a reasonable threshold: 30, 60, 90, 180 days, or something else?

Also, what should happen after it's flagged, notify the manager/lead, start an access review, or automatically revoke it?

Would be interested to hear how teams are approaching this in JSM, Okta, or other IAM setups.

2 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

0 votes
SPHIOR
Contributor
September 5, 2026

Matteo's answer is good advice but it's answering a slightly different question — deactivating dormant accounts is licence hygiene, and you asked about auditing. Those overlap less than people expect.

The thing that catches most teams out: an access review's evidence is not the list of who had access. It's the record that somebody looked at the list and made a decision.

Auditors under SOC 2 CC6 or ISO 27001 A.5.18 are generally not asking "who has admin rights today" — you can produce that in thirty seconds and they know it. They are asking: at what interval do you review it, who performed the last review, what did they decide about each person, and can you show me the one before that. A current-state export answers none of those. Plenty of teams do the review properly, conversationally, in a meeting, and then have nothing to hand over because nobody wrote down that it happened.

So the practical minimum I would aim for, roughly in order of how much auditors care:

A defined cadence, written down somewhere. Quarterly is the common answer; annual is defensible for smaller scopes. The number matters less than that it is stated and then actually followed.

A record of each review that names who did it, when, and what they decided per person or per group — approve, revoke, flag. Even a dated Confluence page beats a perfect export with no signature.

The changes between reviews. This is the one people skip, and it is where the native audit log runs out: it tells you a user was added to a group, but the retention window is finite and the before/after of a permission scheme is not there at all. If your review cadence is longer than your audit log retention, you have a gap you cannot close after the fact.

Deactivation of dormant accounts, which is Matteo's point and is genuinely worth doing — but it is a control you would describe in the review, not the review itself.

If you only do one thing: pick the cadence and start writing down that you did it, starting with the next one. That part is free and it is the part you cannot reconstruct later.

Disclosure: I build a Jira app in this space, so I have read more control frameworks than is good for anyone. Nothing to pitch here — the cadence-and-signature part costs nothing and is where most of the audit value is.

0 votes
Matteo Vecchiato
Community Champion
August 25, 2026

Hi @James Anderson 

Thank you for the interesting question.

About dormant account, In my opinion the policy should be:

- Setting a specific group for those users that don't use the tools but are required to have access (supervisors, someone like this ....)

- Set an automatic/manual deactivation after 6 month for standard users

Hope it helps

James Anderson
Contributor
August 25, 2026

Hi @Matteo Vecchiato 

Have you implemented this yourself or seen anyone implement it? If so, could you please share how it was achieved and what you consider the best approach? That would be really helpful.

Matteo Vecchiato
Community Champion
August 25, 2026

Hi @James Anderson ,

Yes, we implemented in several client. You can implement:

  • Developing a custom script that propose a list of users to deactivate, through Scriptrunner (a dev plug-in in Jira/Confluence). This approach allows to customize a lot the logic and rules.
    It could be done also using an external script tools, like Python, using Atlassian API.
  • Using a marketplace app, less customizable but doesn't require a developer. You can find apps in the marketplace: https://marketplace.atlassian.com/search?query=license%20optimizer 

Hope it helps

DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin Site Admin
TAGS
AUG Leaders

Atlassian Community Events