How much auditing is actually needed for access management?

Question

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.

SPHIOR · Answer

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.

Matteo Vecchiato · Answer

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

James Anderson · Answer

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.