Statement of Applicability

Expanded Definition

A Statement of Applicability, often called an SoA, is the controlled register that records which security controls an organisation has selected, excluded, or adapted within its ISMS. Its purpose is not simply documentation. It is the decision record that ties control selection to risk treatment, scope, and policy intent.

In practice, the SoA sits at the intersection of governance and auditability. Under ISO 27001 style programs, it shows why a control is relevant, why it may be omitted, and what compensating measure exists when a control is adapted. That makes it different from a generic control catalog or a policy matrix. The SoA is also a useful bridge to NHI governance because service accounts, API keys, and automation workflows often fall outside human-centric assumptions and still need explicit control coverage. For broader identity context, the Ultimate Guide to NHIs shows why visibility and lifecycle discipline matter when control decisions are being justified. For a standards lens, the NIST Cybersecurity Framework 2.0 reinforces the need to map controls to risk outcomes rather than treat them as paperwork.

The most common misapplication is treating the SoA as a static audit artifact, which occurs when control choices change in operations but the documented justification is not updated.

Examples and Use Cases

Implementing a Statement of Applicability rigorously often introduces governance overhead, requiring organisations to weigh clearer accountability against the time needed to review control decisions whenever scope or risk changes.

• An organisation excludes a control for a low-risk subsidiary but documents the business rationale, compensating safeguards, and review date in the SoA.
• A cloud platform team maps secrets management, privileged access, and logging controls to systems that host NHIs, using the SoA to show where coverage is direct versus inherited.
• An auditor asks why a control was adapted rather than fully implemented, and the SoA provides the risk acceptance trail and approving authority.
• A merger introduces new service accounts and API integrations, and the SoA is updated to reflect whether existing controls still cover the expanded ISMS scope.
• Security leaders use the SoA to compare the control set in policy with actual operational practice, especially where automation and machine identities create hidden gaps.

For organisations dealing with hidden identity sprawl, the Ultimate Guide to NHIs is a useful reference point for control mapping, while the NIST Cybersecurity Framework 2.0 helps align those choices to governance outcomes.

Why It Matters in NHI Security

An SoA becomes especially important in NHI security because service accounts, workload identities, CI/CD secrets, and agentic tooling are frequently deployed faster than governance can keep up. Without a current SoA, teams may assume a control exists when it was never selected, or assume an exclusion is harmless when the risk has changed. That gap matters because NHIs are often over-privileged, difficult to inventory, and spread across tooling that was not built for human access reviews.

NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which makes a documented control rationale even more valuable when defenders need to prove coverage across opaque identity estates. The SoA also helps teams justify decisions around rotation, offboarding, logging, and least privilege in ways that auditors and operators can both verify. It is not a substitute for implementation, but it is the record that prevents silent drift between policy and reality. The most common operational failure appears after an incident review, when the organisation discovers that a control was believed to be in scope but was never formally selected or maintained.