ISO 27001 Annex A controls still hinge on access governance

At a glance

What this is: A guide to ISO 27001 Annex A that explains the 114 controls and how organisations choose and implement the ones that fit their risk and operating model.

Why it matters: It matters because Annex A control selection turns into access governance, lifecycle discipline, and third-party oversight across human, NHI, and infrastructure identities.

By the numbers:

• ISO/IEC 27001 identifies 114 unique Annex A controls or safeguards in its framework.

👉 Read StrongDM's guide to ISO 27001 Annex A controls and implementation

Context

ISO 27001 Annex A is the control catalogue organisations use to prove that identity, access, operations, and supplier risk are governed in a repeatable way. For IAM teams, the important question is not how many controls exist, but which controls map to privileged access, workload identity, and lifecycle processes in the real environment.

The article is useful because it ties certification to practical control selection, especially around access control, operational security, human resource security, supplier relationships, and compliance. That makes it relevant to NHI governance as well as human IAM, since the same control families govern service accounts, credentials, offboarding, and periodic access review.

Key questions

Q: How should organisations decide which ISO 27001 Annex A controls apply?

A: Start with risk, legal obligations, operating model, and identity scope. Annex A is not a universal checklist, so the right controls depend on how your organisation actually uses human access, privileged accounts, service identities, suppliers, and logging. A good Statement of Applicability explains why each control is included, how it is implemented, and what evidence proves it is working.

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. If registration, review, credential protection, and deregistration are not all governed together, service accounts and privileged users can retain access long after the business need has ended. That creates audit gaps and real exposure across both human IAM and NHI estates.

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. Supplier relationships are only governed if the organisation can show who approved access, what systems or data were reachable, how activity was logged, and when access was removed. Without that trail, supplier access becomes a compliance blind spot.

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.

Technical breakdown

How ISO 27001 Annex A turns risk into control scope

Annex A is a control framework, not a checklist. Organisations build a Statement of Applicability that says which controls apply, why they apply, and which risks or obligations justify them. That matters because ISO 27001 certification is evidence-based: auditors look for a documented logic chain from risk assessment to implemented control to operational proof. In practice, teams often over-focus on control count and under-focus on whether the control actually matches the identity type being governed, especially when service accounts, shared credentials, or supplier access are involved.

Practical implication: map each control to a specific identity type and risk scenario before you treat it as in-scope.

Access control, least privilege, and periodic review in Annex A.9

Annex A.9 is the most identity-heavy part of the standard. It covers least privilege, user registration and deregistration, privileged account management, secure storage of credentials, and ongoing review of access rights. The control logic assumes that identities can be registered, monitored, adjusted, and removed on a governance cadence. That works only if access is visible and lifecycle ownership is clear. When organisations cannot tell who owns a service account or why a credential still exists, Annex A.9 becomes a policy statement instead of an operational control.

Practical implication: align privileged access, credential storage, and access review evidence to one accountable owner per identity.

Supplier relationships and operational security as identity controls

Annex A.15 and A.12 extend identity governance beyond employee access. Supplier relationships introduce externally managed access paths, while operational security demands logging, change control, vulnerability handling, and separation of duties. Together, they show that certification is not just about internal account hygiene. It is about whether the organisation can prove control over access that originates in third-party tools, shared infrastructure, scripts, and admin workflows. For modern environments, that is where NHI exposure often becomes audit exposure.

Practical implication: include third-party access paths and machine identities in the same evidence model as human administrative access.

NHI Mgmt Group analysis

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.

Access control becomes weak when organisations cannot govern non-human identities with the same discipline as people. Annex A.9 assumes identities have clear registration, review, and removal processes, yet service accounts and API credentials are frequently created outside HR-style lifecycle controls. That creates a governance gap between policy and execution. Practitioners should recognise that unmanaged machine identity breaks the same control family used for human access.

Supplier access is the control family most likely to expose hidden identity risk. Annex A.15 and A.12 reveal that third-party access, logging, and change control are inseparable in real audits. If supplier credentials, scripts, or hosted workloads are not visible in the same governance process as internal admin accounts, the organisation cannot prove control consistency. The practitioner takeaway is to align third-party access evidence with the same review and offboarding expectations used for internal identities.

Identity blast radius: Annex A exposes how much risk remains when access is granted faster than it is reviewed or removed. ISO 27001 assumes access can be periodically certified, but modern identity estates now include human users, contractors, services, and automation that move at different speeds. That makes broad control families like A.9 and A.15 dependent on lifecycle discipline across all identity types. The implication is that certification readiness increasingly depends on reducing privilege spread, not just writing better policies.

From our research:

• 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.
• For the lifecycle detail behind that control gap, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity control scope is widening faster than most ISO programmes are built to handle. When privileged access, third-party connectivity, and machine identities all sit inside the same certification envelope, organisations need one evidence model that can survive audit across multiple identity types. The programme signal is clear: ISO work is becoming identity architecture work, not just compliance documentation.

The strongest programmes will stop treating access review as a human-only control and start extending it to service accounts, API credentials, and supplier access paths. That shift will matter more as auditors ask for proof that control ownership, review cadence, and removal evidence are consistent across the entire identity estate.

For practitioners

• 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.
• Use operational logs as certification evidence Retain admin activity, change records, and access decision logs in a form that auditors can trace back to the control objective and the responsible owner.

Key takeaways

• ISO 27001 Annex A is best understood as an identity governance framework in disguise, because its most important controls depend on ownership, lifecycle, and evidence.
• The biggest practical failure mode is not missing policies but incomplete control coverage across human access, privileged accounts, supplier access, and non-human identities.
• Teams preparing for certification should map every relevant identity type to a control owner, review cadence, and audit trail before they rely on the Statement of Applicability.

Key terms

• Statement of Applicability: The Statement of Applicability is the document that explains which ISO 27001 controls an organisation has chosen to implement and why. It connects risk, legal obligations, and business context to a defensible control scope, which makes it central to audit readiness and governance clarity.
• Annex A Control: An Annex A control is a specific safeguard in ISO 27001 that addresses a security risk through policy, process, or technology. Annex A controls are not meant to be used blindly as a checklist. They are selected and justified based on how the organisation actually operates and what identities it must govern.
• Access Review: An access review is a recurring check that confirms an identity still needs the permissions it has been given. In mature programmes, it covers human users, privileged accounts, service identities, and supplier access, with evidence showing who approved the access and when it was removed or changed.
• Supplier Access: Supplier access is any external party's ability to reach systems, data, or administrative functions inside an organisation. It is a governance problem as much as a technical one, because access often persists across contracts, integrations, and hosted services unless ownership and offboarding are explicitly controlled.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by StrongDM: Understanding ISO 27001 Controls [Guide to Annex A]. Read the original.