Notifications
Clear all
Topic starter
12/06/2026 9:26 pm
TL;DR: The 114 ISO 27001 Annex A controls are broken down in a guide that shows how organisations use a Statement of Applicability to decide which controls fit their risks, operations, and compliance scope, according to StrongDM. The real issue is not certification paperwork but whether access, lifecycle, and supplier governance actually map to how identities operate.
NHIMG editorial — based on content published by StrongDM: Understanding ISO 27001 Controls [Guide to Annex A]
By the numbers:
- ISO/IEC 27001 identifies 114 unique Annex A controls or safeguards in its framework.
Questions worth separating out
Q: How should organisations decide which ISO 27001 Annex A controls apply?
A: Start with risk, legal obligations, operating model, and identity scope.
Q: Why do ISO 27001 access controls often fail in practice?
A: They fail when organisations treat access as a one-time approval instead of a lifecycle process.
Q: How can teams prove that supplier access is actually controlled under ISO 27001?
A: They need evidence for onboarding, scope, review, logging, and offboarding.
Practitioner guidance
- Build the Statement of Applicability from identity risk, not generic control lists Tie each Annex A control to a specific human, NHI, or supplier access scenario, then document why it is in scope and what evidence proves it is operating.
- Map Annex A.9 to every privileged identity type Include service accounts, API keys, and admin credentials in the same access review, provisioning, and deregistration process used for human privileged access.
- Treat supplier access as a first-class lifecycle problem Track third-party credentials, hosted access, and outsourced administration through onboarding, review, renewal, and removal so offboarding evidence is available during audit.
What's in the full article
StrongDM's full guide covers the operational detail this post intentionally leaves for the source:
- The full breakdown of all 14 Annex A categories and how StrongDM maps them to real implementation areas.
- Examples of which control families matter most in remote, cloud-based, or supplier-heavy operating models.
- The article's walkthrough of who should be involved in implementation, from HR and legal to IT and DevOps.
- StrongDM's discussion of how its access platform aligns with Annex A.9 and Annex A.12 in its own view.
👉 Read StrongDM's guide to ISO 27001 Annex A controls and implementation →
ISO 27001 Annex A controls: where IAM teams still get stuck?
Explore further
12/06/2026 11:30 pm
ISO 27001 succeeds only when identity governance is translated into ownership, lifecycle, and evidence. The standard is often treated as documentation work, but Annex A actually tests whether access is controlled in a way auditors can verify. That makes identity governance the practical core of certification, not a side effect. The implication is that teams should treat Annex A as an operating model for human, NHI, and supplier access rather than a compliance checklist.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own ISO 27001 control implementation across identity and access?
A: Ownership should sit across security, IT, legal, HR, supplier management, and operations, with one accountable lead coordinating the control model. ISO 27001 spans policies, technology, and evidence, so no single team can implement it alone. The practical test is whether each identity type has a named owner for approval, review, and removal.
👉 Read our full editorial: ISO 27001 Annex A controls still hinge on access governance
