Annex A is the control catalogue associated with ISO 27001. It provides the recommended control set organisations can use to support their ISMS, along with the requirement to justify whether each control is applied, excluded, or out of scope.
Expanded Definition
Annex A is the control catalogue that accompanies ISO 27001 and is used to select, justify, and govern information security controls within an ISMS. It is not a separate certification in itself; rather, it is the reference set organisations evaluate when deciding which controls are applicable, excluded, or outside scope. In practice, Annex A supports the statement of applicability, which records how each control decision was reached and why.
For NHI and agentic AI governance, Annex A becomes relevant wherever service accounts, API keys, certificates, secrets, and automated workflows are part of the security boundary. The control set is broad enough to inform access management, logging, cryptography, supplier oversight, and incident handling, but it does not prescribe a single implementation model. Definitions vary across vendors and auditors on how deeply Annex A should be mapped to machine identities, so organisations should treat it as a governance baseline rather than a complete technical design.
The most common misapplication is treating Annex A as a checklist with automatic applicability, which occurs when teams copy control decisions from another organisation without testing them against their own NHI architecture and risk profile.
Examples and Use Cases
Implementing Annex A rigorously often introduces documentation and review overhead, requiring organisations to weigh auditability against the speed of security change.
- Mapping service account lifecycle controls to ISO 27001 expectations, then documenting why each control is applied, excluded, or out of scope in the statement of applicability.
- Using the control catalogue to justify secret storage, rotation, and access review requirements for API keys, with reference material from Ultimate Guide to NHIs.
- Evaluating logging and monitoring controls for workload identities against NIST Cybersecurity Framework 2.0 functions to keep Annex A decisions aligned with operational detection needs.
- Reviewing supplier and cloud integration controls when third-party automation can create or use non-human credentials inside the ISMS boundary.
- Creating a control-gap matrix that shows where machine identity risks are fully covered, partially covered, or deferred to compensating controls.
In NHI-heavy environments, Annex A is most useful when it translates abstract governance into specific control ownership, evidence expectations, and exception handling.
Why It Matters in NHI Security
Annex A matters because machine identities often expand faster than governance processes can track them. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, and that 97% of NHIs carry excessive privileges, which means a weak control mapping exercise can leave the most common attack paths largely unmanaged. The result is not just audit friction but real exposure across secrets, access paths, and automated trust chains.
For NHI security teams, Annex A helps convert scattered identity controls into an auditable structure that supports ownership, review cadence, and compensating controls. It also forces the question of scope: if a workload credential can reach production data, it belongs in the control discussion even when it is not a human user. That is why Annex A is often a practical bridge between ISO governance and NHI operations, especially when organisations need to prove that service accounts, tokens, and certificates are handled deliberately rather than by convention.
Organisations typically encounter Annex A as an operational requirement only after a failed audit, a breach review, or a scope dispute exposes that machine identities were never formally mapped into the ISMS.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Annex A supports governance oversight by tying control selection to risk and scope decisions. |
| NIST CSF 2.0 | PR.AA-01 | Annex A often maps to identity and access controls for human and non-human identities. |
| NIST CSF 2.0 | DE.CM-01 | Annex A also informs monitoring controls that detect misuse of NHI credentials. |
Document control applicability and review it against enterprise risk and oversight expectations.
