How to Audit User Roles and Software Permissions

Start by listing every account across every system in scope — not just named user logins, but service accounts, shared logins, and anything with admin or elevated privileges. Privileged accounts deserve particular attention: they're usually few in number but carry disproportionate risk, and they're the ones most likely to have been created for a one-off task years ago and never revisited.

Cross-check this list against your HR records or org chart. Accounts that don't map to a current employee — a contractor from a finished project, a vendor's temporary login, an account under a name nobody in the room recognises — are exactly the kind of thing this step is designed to surface.

For each account, list what it can actually do — not what its job title implies, but the specific permissions granted. Then compare that against what the person's current responsibilities genuinely require. Access accumulates over time as people move between roles or take on temporary projects, and it's rarely removed again once the reason for it has passed.

This is where over-provisioning usually turns up: someone who moved from finance to operations two years ago but still has finance system access nobody thought to revoke, or a manager with admin rights across a system they only ever use for one report.

Look at your actual joiner-mover-leaver process, not the documented one. Is there a checklist that reliably grants new access on day one and removes old access the day someone's role changes or they exit? Or does it happen informally, when someone remembers to email IT, with no consistent trigger?

Imagine a multi-branch salon chain where a branch manager left eight months ago, and their login — with full access to that branch's point-of-sale and customer database — was never deactivated, because deactivation depended on someone remembering to flag it manually. That's the exact pattern this check is meant to catch before it becomes a real incident rather than a near miss.

Where systems keep access logs, review them for accounts that are provisioned but never used — a strong sign the access was unnecessary in the first place — and for unusual activity patterns worth a direct conversation, not an accusation.

Also check for segregation-of-duty conflicts: the same person able to both create a vendor and approve payment to that vendor, for example, or both process a refund and approve it. These aren't usually evidence of wrongdoing, but they're a structural risk worth closing regardless, and they're the kind of finding an external auditor or a customer's due-diligence process will specifically look for.

Route every proposed correction — revoke this, downgrade that, split this shared login into named accounts — through a named approver before it's actioned, so changes are documented and reversible rather than made ad hoc by whoever happens to be doing the review.

Then schedule the next review before you close this one out. A one-time cleanup fixes today's drift; a recurring review (quarterly for higher-risk systems, twice yearly otherwise) is what keeps the same problems from quietly re-accumulating. If your business is working toward a compliance certification, a documented, recurring access review is typically one of the specific controls an external auditor will ask to see evidence of — worth raising with your compliance advisor if that's on your roadmap.