They treat it as a static compliance document instead of the control map that links risk decisions to ongoing operations. The SoA should explain why a control exists, who owns it, and how its performance is evidenced over time. Without that, the ISO 27001 programme becomes documentation without governance.
Why This Matters for Security Teams
The statement of applicability is not meant to be a filing cabinet for controls. It is the decision record that ties ISO 27001 risk treatment to operating reality: which controls are in scope, why they matter, and how their effectiveness is checked. Teams get into trouble when the SoA is written for auditors alone, then left untouched while systems, suppliers, and attack paths change.
That gap is especially visible when identity sprawl, secrets handling, and third-party access are already creating exposure. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks, which is exactly the kind of operational risk a living SoA should reflect. A static document cannot explain why controls remain relevant when the environment changes.
Good teams align the SoA with governance, ownership, and evidence, not just clause mapping. That is consistent with the intent of NIST Cybersecurity Framework 2.0, which treats security as a managed, iterative function rather than a one-time documentation exercise. In practice, many security teams encounter SoA drift only after an audit failure or incident review, rather than through intentional control governance.
How It Works in Practice
A useful SoA starts with risk, not control catalogues. Each included or excluded control should answer three questions: what risk it addresses, who owns it, and what evidence proves it still works. That means the SoA should sit alongside change management, access review, and exception handling, so control decisions stay current as the estate evolves.
Practitioners often make the SoA more effective by linking each control to a small set of operational signals. For example, access controls may be evidenced through quarterly reviews, automated entitlement reports, and exception approvals. Secrets controls may be evidenced through rotation logs, vault configuration checks, and offboarding records. This is where NHI governance becomes practical, because service accounts, API keys, and machine credentials are often the hidden dependency behind larger control failures. The same Ultimate Guide to NHIs shows how broadly those risks are distributed across modern environments.
- Map each control to a specific risk scenario, not just an ISO clause.
- Assign a business or technical owner who can attest to operation, not only policy wording.
- Define evidence that is continuous or periodic, depending on the control’s criticality.
- Track exceptions separately so temporary acceptance does not become silent deferral.
- Review the SoA whenever architecture, suppliers, or identity patterns materially change.
The best practice is evolving toward control governance that is measurable and reviewable, which is also consistent with NIST’s emphasis on repeatable cybersecurity outcomes. These controls tend to break down when evidence is manual, ownership is unclear, and the organisation has a large undocumented set of machine identities and secrets.
Common Variations and Edge Cases
Tighter SoA governance often increases maintenance overhead, requiring organisations to balance audit simplicity against operational freshness. That tradeoff becomes sharper in large estates, regulated environments, and hybrid cloud programmes where control ownership is distributed across infrastructure, application, and security teams.
One common mistake is treating excluded controls as permanent exclusions instead of risk decisions that need revalidation. Another is assuming a single evidence pattern works for every control. Some controls are best evidenced by logs and system settings, while others require human sign-off, incident data, or supplier attestations. There is no universal standard for this yet, so current guidance suggests tailoring evidence to the control’s risk impact and operating cadence.
For NHI-heavy environments, the SoA should be especially explicit about secrets rotation, service account governance, and offboarding. If those elements are missing, the document can still look compliant while the operational control plane remains weak. NHI Mgmt Group’s research shows how often long-lived credentials and poor visibility persist in practice, which is why a control map must remain connected to live operations rather than static policy text.
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.OV-01 | SoA should stay tied to governance and oversight as risk changes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | SoA often misses how rotation and lifecycle evidence supports machine identity controls. |
| NIST AI RMF | Risk management for AI and automated systems reinforces living control decisions. |
Document NHI control rationale, assign owners, and prove rotation or revocation with operational evidence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
