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.
Why This Matters for Security Teams
iso 27001 Annex A is often treated like a fixed controls checklist, but that approach breaks down quickly in real environments. The applicability of each control depends on risk, legal obligations, business model, supplier exposure, and the identity types in scope, especially service accounts, API keys, privileged access, and logging. For NHI-heavy environments, that distinction matters because compromised machine identities routinely become the shortest path to lateral movement and data access.
Security teams also need to distinguish between “in scope” and “implemented well.” A control can be applicable but weakly evidenced, or excluded with a clear rationale that still aligns to risk treatment. That is why the Statement of Applicability must read like a defensible decision record, not a compliance form. Guidance from the NIST Cybersecurity Framework 2.0 reinforces risk-based control selection, while NHIMG research shows why the identity layer cannot be ignored: the Ultimate Guide to NHIs — Standards notes that 90% of IT leaders say properly managing NHIs is essential for successful zero-trust implementation. In practice, many security teams discover weak control selection only after a service account, token, or third-party integration has already been abused.
How It Works in Practice
The right way to determine Annex A applicability is to start with the organisation’s actual attack surface, then map controls to the way identities, data, and suppliers are used. A useful approach is to group assets and workflows first, then ask what can realistically go wrong, what the legal or contractual obligations are, and which controls reduce the residual risk to an acceptable level.
For example, if the environment uses cloud automation, CI/CD pipelines, or API-driven services, controls around identity lifecycle, secrets handling, logging, segregation of duties, and supplier access become far more relevant than in a low-complexity environment. If there are privileged operators, just-in-time access, or delegated administration, stronger evidence is needed for approval, monitoring, and revocation. Annex A decisions should also reflect how NHIs are issued, rotated, stored, and retired, not just how human users authenticate. NHIMG’s JetBrains GitHub plugin token exposure case illustrates how a seemingly narrow identity weakness can turn into broad compromise when secrets are embedded in developer workflows.
- Identify the identity classes in scope: humans, privileged users, service accounts, workloads, suppliers, and API keys.
- Map each identity class to the processes it can affect: deployment, production support, data access, and logging.
- Decide whether a control is required, partially required, or not relevant, and record the rationale.
- Define evidence up front: configuration, access review records, logs, approval trails, or rotation reports.
For machine identities, controls are often most effective when they are tied to lifecycle events such as provisioning, rotation, and offboarding rather than annual review cycles. The Ultimate Guide to NHIs highlights that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that Annex A applicability should cover more than traditional user access. These controls tend to break down when identity ownership is unclear across engineering, platform, and security teams because no one can produce timely evidence or enforce revocation.
Common Variations and Edge Cases
Tighter control selection often increases operational overhead, so organisations have to balance auditability against engineering speed and delivery friction. That tradeoff becomes especially visible in hybrid environments, acquisitions, and supplier-heavy operating models, where one control may apply to one business unit but not another.
Current guidance suggests treating exceptions as risk decisions, not convenience decisions. If a control is excluded, the SoA should explain why the risk is already reduced by another mechanism, such as compensating monitoring, platform enforcement, or contractual constraints. This is particularly important for secrets management, third-party integrations, and logging retention, where an “inapplicable” label is often really a sign that ownership is fragmented.
One useful rule is to test edge cases against actual abuse paths: could a supplier token access production, could a dormant service account be reused, could logs reveal credentials, or could a compromised workload move laterally? If the answer is yes, the control is usually applicable even if the workflow is automated. In other words, applicability follows exposure and impact, not whether a person is directly clicking through a system. Organisations that ignore that distinction usually end up with a SoA that passes review on paper but fails when incident responders need evidence most.
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-01 | Annex A selection should follow risk management and business context. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity scope includes service accounts, API keys, and other NHIs. |
| NIST AI RMF | Decision-making should be documented, repeatable, and accountable. |
Map machine identities to applicable controls and require lifecycle evidence for each one.
