Access auditing is the review of who can reach systems, data, and privileges, and whether those permissions are justified. In IAM and NHI governance, it examines identities, roles, entitlements, secrets, and activity logs to detect excess access, dormant accounts, policy drift, and control failures across human and non-human identities.
What access auditing examines
Access auditing is not just a snapshot of permissions, it is a governance check on whether access still matches job function, system role, business need, and approved delegation. That makes it useful across human and non-human identities, because both can accumulate unused rights, inherited entitlements, and exceptions that were valid once but no longer are.
In practice, the review spans identity records, role assignments, group membership, privileged entitlements, and the activity evidence that shows whether access is actually being used. The point is to compare authorization on paper with authorization in reality, then identify drift before it becomes routine.
Why access auditing matters in identity governance
Access auditing is one of the clearest ways to test whether least privilege is still being maintained. When audits are weak or infrequent, organisations tend to keep outdated access because it is easier than re-justifying it, especially in environments with frequent team changes, outsourced operations, and automated service connections.
It is also a control for accountability. If no one can explain why an account, role, or token still exists, then ownership has already become unclear. The value of the audit is not only removal of excess access, but also forcing a named business or technical owner to confirm that access remains justified.
For broader governance context, the access review function is closely tied to audit trail expectations in Ultimate Guide to NHIs — Regulatory and Audit Perspectives, which frames how access evidence supports governance and recertification.
What auditors and reviewers look for
A strong review does more than count accounts. It checks whether each identity has a valid owner, a current purpose, the right level of privilege, and a defensible path to access. That includes shared accounts, dormant accounts, service accounts, long-lived credentials, admin roles, inherited group access, and exceptions that have quietly become permanent.
Reviewers also look for mismatches between entitlement and behaviour. If an identity has powerful access but no corresponding business activity, or if a workload keeps using a privilege set that is broader than its current function, that is a signal that the access model has drifted away from actual need.
Where access is governed under formal control frameworks, auditors often expect evidence that reviews are systematic rather than ad hoc. SOC 2 Trust Services Criteria (AICPA) is relevant here because access review evidence supports the Security, Confidentiality, and related trust criteria used in assurance contexts.
Typical failure patterns and control gaps
The most common failure is stale access, where a change in role, vendor relationship, or system design leaves permissions behind. Another is review blindness, where the process confirms a list without checking whether the access is still required, or where owners approve items they do not truly understand.
Access auditing also fails when organisations cannot see the full inventory of identities and entitlements. Shadow accounts, undocumented integrations, and untracked privileges create gaps that make the audit look complete while still missing material exposure.
In cloud and hybrid environments, the same weakness appears when service accounts, API clients, and delegated credentials are treated as operational plumbing rather than governable access. That is where access auditing becomes a practical control against entitlement creep, not just a compliance exercise.
How access auditing supports detection and remediation
Access auditing is most effective when it connects permission review with log review. A permission may be formally approved yet still suspicious if the activity record shows no legitimate use, repeated failed use, or unexpected use outside the normal pattern for that identity.
It also helps separate cleanup from compromise response. If the audit finds access that should never have existed, that may indicate weak provisioning or ownership failure. If it finds activity inconsistent with expected use, the issue may be active abuse, not just poor housekeeping. In either case, the review gives defenders a concrete starting point for revocation, investigation, and recertification.
Risk and Threat Considerations
Access auditing reduces the chance that excess rights, forgotten accounts, or unreviewed service credentials become an open path for misuse. It matters because attackers often prefer standing access that already looks legitimate, especially when privileges were inherited, over-granted, or left behind after a role change.
Failure mechanism: If audits are incomplete or superficial, excessive access remains in place long enough for privilege misuse, lateral movement, or unauthorized data access to occur without immediate challenge.
Impact: The result can be account takeover, unauthorized administrative action, silent data exposure, and a much harder post-incident reconstruction of who had access, when, and why.
Framework alignment
Access governance: CIS Controls v8 supports account management, access control, and audit logging as practical safeguards for recurring review.
Audit and accountability: NIST SP 800-53 Rev 5 Security and Privacy Controls directly aligns through AC and AU controls that govern access decisions and evidence.
Access control governance: ISO/IEC 27001:2022 Information Security Management supports structured review of access rights, privileged access, and related Annex A controls.
Detection and abuse mapping: MITRE ATT&CK Enterprise Matrix helps map suspicious access use to credential access, privilege escalation, and lateral movement patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access auditing reviews who has access and whether it is still justified. |
| Recommendation — Review account and access assignments regularly and remove unnecessary permissions. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access auditing verifies account purpose, ownership, and ongoing authorization. |
| AU-6 — Audit Review, Analysis, and Reporting | Access auditing depends on log review to validate use and detect anomalies. | |
| Recommendation — Periodically review accounts and disable those no longer needed. Analyze audit records for unusual or unauthorized access activity. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access auditing tests whether access rights are governed and justified. |
| Recommendation — Establish and review access control rules against business need. | ||
Practitioner Guidance
Why practitioners should care: Treat access auditing as an evidence-based control, not a checkbox review. The most useful audits test ownership, business need, and actual use together, so that stale privilege and undocumented delegation are visible before they become systemic.
What to watch for: Pay close attention to high-privilege accounts, dormant identities, shared credentials, and access that has been repeatedly approved without any real change in the underlying need. Those are the places where review quality usually fails first.
Practitioner takeaway: The best access audit is the one that can explain every retained permission in plain language, with evidence to match.
Related resources from NHI Mgmt Group
- Non-Human Identity Access Management
- Why do vulnerability scanners not replace access auditing?
- What breaks when privileged access auditing remains fragmented across multiple systems instead of being centralised?
- What breaks when file share auditing does not capture both access and permission changes?