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.
Community moderators have prevented the ability to post new answers.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @James Anderson ,
Yes, we implemented in several client. You can implement:
Hope it helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.