Accountability sits with the control owner and the organisation’s governance function, because ISO 27001 expects documented controls to reflect real operations. If access behaviour differs from policy, the issue is not only technical. It is a governance failure that auditors will surface through sampling, interviews, and recertification evidence.
Why This Matters for Security Teams
When iso 27001 controls describe one access model but systems behave differently, the gap is not cosmetic. It means the control set is no longer a reliable statement of operational reality. That creates audit exposure, weakens risk treatment, and leaves control owners unable to prove that access is limited, reviewed, and removed as documented. The issue is especially visible in non-human access, where service accounts, API keys, and automation often drift faster than human-reviewed policy.
NHI Management Group research shows how common that drift can be: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That matters because if the control owner cannot see what actually has access, they cannot defend the control design. For a standards lens, the OWASP Non-Human Identity Top 10 is useful for understanding how identity sprawl and weak lifecycle management create the exact conditions auditors later question.
In practice, many security teams encounter this only after recertification evidence, an incident review, or a sample access test has already exposed the mismatch.
How It Works in Practice
ISO 27001 does not assign accountability to a tool alone. It expects the organisation to define ownership for controls, maintain evidence, and ensure the control works as intended in daily operations. When actual access behaviour diverges from policy, accountability normally sits with the control owner, but the governance function is responsible for making sure the control framework, exceptions, and evidence chain are coherent.
That means three things must line up:
- the documented control objective,
- the real access paths used by people, services, and automation, and
- the evidence used to show the control is operating effectively.
For non-human access, the operational test is simple: can the organisation show who or what has access, why it has access, who approved it, and when it will be removed or rotated? If the answer depends on tribal knowledge or a few engineers remembering old exceptions, the control is already misaligned. The NHI Management Group Ultimate Guide to NHIs — Key Challenges and Risks highlights how often secrets and service-account governance fail when inventories are incomplete or rotation is inconsistent.
Practically, teams should map each access path to a named owner, then reconcile policy, entitlement records, and observed behaviour during recertification. If the observed behaviour is broader than the control text, the control owner must either tighten implementation or formally update the control description and risk treatment record. Current guidance suggests that governance should treat this as a control design problem, not just an IAM cleanup task. These controls tend to break down when legacy service accounts, CI/CD secrets, and manual exceptions are spread across multiple teams because no single owner can reconcile them quickly.
Common Variations and Edge Cases
Tighter control mapping often increases review overhead, requiring organisations to balance auditability against operational speed. That tradeoff is real, especially where production automation cannot wait for slow approval cycles.
There is no universal standard for this yet, but best practice is evolving around stronger evidence of actual behaviour rather than paper entitlement alone. In mature environments, governance teams use periodic sampling, privileged access reviews, and secrets inventory reconciliation to spot drift before an audit does. The 52 NHI Breaches Analysis is a practical reminder that hidden access paths often become visible only after incident response, not during routine control review.
Edge cases usually appear in shared platforms, outsourced operations, or SaaS integrations where the business owner assumes the provider is accountable. In ISO 27001 terms, that assumption is not enough. Accountability still requires an internal owner who can explain scope, exceptions, and residual risk. Where technical teams rely on long-lived credentials or undocumented API access, the control may be formally approved yet operationally false. That is the point at which auditors question not only the implementation gap, but whether the governance model itself is working.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 | Governance accountability covers mismatches between policy and actual access behavior. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity inventory and lifecycle gaps often drive access-control drift for NHIs. |
| NIST AI RMF | Governance and accountability are required when autonomous systems exceed documented access scope. |
Define ownership, monitoring, and escalation for any system whose access differs from policy.
Related resources from NHI Mgmt Group
- How should organisations run ISO 27001 user access reviews without creating audit noise?
- Who is accountable when a small business breach spreads through weak access controls?
- Why do access governance gaps increase ISO 27001 certification costs?
- How should teams prepare identity controls for an ISO 27001 audit?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
