How should organisations implement ISO 27001 access reviews across human and machine identities?

Why This Matters for Security Teams

iso 27001 access reviews fail when organisations treat them as a checkbox exercise instead of a control validation exercise across all identities that can actually do work. Human users are only part of the picture. Service accounts, API keys, tokens, certificates, and application bindings often hold broader access, longer lifetimes, and weaker ownership. That creates a blind spot if the review only tracks named employees and contractors.

This matters because modern environments routinely accumulate dormant access, over-privileged machine identities, and undocumented application dependencies. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which makes a traditional user-centric review incomplete. The broader risk landscape is well covered in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10, both of which highlight entitlement drift and weak lifecycle control as recurring failure patterns.

In practice, many security teams discover the real access footprint only after an audit exception, a service outage, or a secrets incident has already exposed the gap.

How It Works in Practice

The cleanest approach is to build one review population from the identity inventory, then group it by risk and ownership rather than by technology silo. That means pulling human users, privileged administrators, service accounts, workload identities, application-to-application tokens, and externally managed access into a single evidence set. For each entry, the reviewer should confirm who owns it, what business process depends on it, whether the privilege scope still matches the role or workload, and when the access should expire or be removed.

For human identities, the review usually checks role alignment, manager attestation, joiner-mover-leaver status, and privileged escalation. For machine identities, the better question is whether the credential or binding is still required for a live workload, whether its TTL is appropriate, and whether a secret can be rotated or replaced without breaking service. This is where the NHI Lifecycle Management Guide is useful, because access review and lifecycle management need to be linked rather than treated as separate processes.

• Inventory all identities that can authenticate or authorize actions, including embedded credentials and third-party integrations.
• Assign a named business or technical owner to each identity before the review begins.
• Review entitlement scope against actual usage, not just intended design.
• Record a removal date, rotation date, or recertification date for every exception.
• Evidence the decision trail so the review can support ISO 27001 auditors and operational follow-up.

Automation helps, but current guidance suggests it should support reviewer decisions rather than replace them. Tools can surface last-used data, effective permissions, and stale credentials, while policy teams still need a human accountable for the attestation outcome. These controls tend to break down in federated cloud environments with dozens of ephemeral workloads because ownership, usage telemetry, and removal authority are fragmented across teams and platforms.

Common Variations and Edge Cases

Tighter access reviews often increase operational overhead, so organisations must balance stronger assurance against the risk of slowing delivery or breaking production systems. That tradeoff becomes sharper for machine identities, where a credential may be embedded in CI/CD, tied to a vendor integration, or required only during a narrow batch window.

There is no universal standard for exact review frequency across all identity types yet. For high-risk human access, periodic recertification remains common. For non-human identities, best practice is evolving toward event-driven review triggers, such as credential creation, privilege change, workload retirement, failed rotation, or unusual usage. The Ultimate Guide to NHIs — Key Challenges and Risks shows why this matters: secrets often persist in code and pipelines long after teams believe they have been removed, which makes simple annual attestations too blunt for high-churn environments.

Where organisations run shared service accounts, legacy on-prem systems, or vendor-operated platforms, the review may need compensating controls such as stronger logging, shorter rotation windows, and explicit exception approval. The key is to avoid a false equivalence between a person’s access and a workload’s access: the control objective is the same, but the evidence, ownership model, and remediation path are different.

Related resources from NHI Mgmt Group

• How can organisations reduce standing access across human and non-human identities?
• How should security teams implement centralized IAM across human and machine identities?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities for ISO 27001?