The Statement of Applicability (SoA) is the document ISO 27001 clause 6.1.3 requires: for each of the 93 Annex A controls, whether it is applicable, why, and whether it is implemented, plus any controls you apply from outside Annex A. It is the bridge between your risk treatment plan and the controls you run, and usually the first document a certification auditor opens, because it tells them what to test. A control is included because a risk treatment, a legal or contractual obligation or a business requirement needs it, and excluded with a stated reason when nothing does. The SoA has an owner, a version and an approval, and it changes whenever the risk picture does.
The Statement of Applicability has a reputation as paperwork. It is better understood as the audit plan you write for the certification body: it says which controls exist, why, and whether they run, and the Stage 2 auditor works down it row by row. A good SoA takes a day to produce once the risk assessment exists and saves weeks of questions; a bad one is the most common source of Stage 1 concerns.
What clause 6.1.3 requires
Clause 6.1.3 describes the risk treatment process, and the SoA is its output. For each risk you choose a treatment; for each treatment that needs controls you determine the controls; you compare those with Annex A to check nothing necessary has been missed; and you produce a Statement of Applicability that contains:
- The necessary controls, from Annex A or elsewhere, and the justification for including each one.
- Whether each necessary control is implemented or not.
- The justification for excluding any Annex A control.
The standard does not prescribe a format. A table with one row per control is universal, because the auditor wants to find any control in seconds. The risk assessment guide covers the process that feeds it, and the Annex A guide lists all 93 controls.
Where the SoA sits
The order matters, and the auditor checks it. The risk assessment identifies risks against what is in scope. The risk treatment plan records, per risk, the chosen option and the controls that modify it. The SoA records, per control, the risks and obligations that make it necessary. The policies and procedures then describe how each applicable control works, and the evidence shows that it ran. An SoA written before the risk assessment, by ticking everything that sounded sensible, breaks the chain at the first link.
Writing a justification
- Inclusion: name the risk or risks the control treats (by identifier), or the obligation that requires it (a law, a customer contract, a regulator). One sentence is enough; a list of risk IDs is better than prose.
- Exclusion: state the fact that removes the risk. No premises in scope, no software development, no removable media, no outsourced development. Write it so the next auditor can check whether it is still true.
- Implementation status: implemented, partly implemented or planned, with a date for anything not yet in place. Planned controls are allowed; undated ones are a finding waiting to happen.
- Controls from outside Annex A: list them in the same table with the same fields. Customers' contractual controls and sector rules often belong here.
A worked example
Five rows from the SoA of a cloud-hosted software company with a serviced office and no outsourced development:
| Control | Applicable | Justification | Status | Implemented by |
|---|---|---|---|---|
| A.5.7 Threat intelligence | Yes | Treats R-04 (unpatched exposure to known exploits); needed to prioritise A.8.8 | Planned, Q1 | Vendor advisories and CERT feeds reviewed weekly by the platform team |
| A.5.18 Access rights | Yes | Treats R-12 (leaver keeps access) and R-13 (privilege creep); required by customer DPAs | Implemented | Joiner/mover/leaver process in the identity provider; quarterly access review |
| A.7.4 Physical security monitoring | No | No premises of our own in scope: the office is serviced and monitored by the landlord, and all systems are cloud-hosted (see A.5.23) | Excluded | |
| A.8.4 Access to source code | Yes | Treats R-21 (unauthorised change to production code) | Implemented | Repository permissions by team; branch protection; review required to merge |
| A.8.30 Outsourced development | No | All development is done by employees; revisit if contractors are engaged | Excluded |
Keeping it current
The SoA carries a version, a date and the approval of the risk owners, because the certificate commonly references the SoA version the audit was based on and surveillance audits check it has moved with the business. Review it whenever the risk assessment is repeated, at the planned interval or after a significant change, and whenever a control changes status. A new cloud provider, a first office, a first contractor or a new product each touch several rows.
Mistakes auditors find first
- Every control marked applicable with no justification, which shows the risk assessment did not drive selection.
- Exclusions with no reason, or with a reason that is no longer true.
- Controls marked implemented that have no evidence of operation, which becomes a nonconformity at Stage 2.
- An SoA that lists controls the risk treatment plan does not, or the other way round.
- An SoA still at version 1.0 three years in, while the company has doubled and moved providers.
- Copying ISO 27002's guidance text into the implementation column instead of describing what you actually do.
How Noru produces the Statement of Applicability
Noru generates the SoA from the control records rather than keeping it as a separate spreadsheet: one row for each of the 93 Annex A controls, with applicability, implementation status and the justification drawn from the status reasons, implementation notes and the linked risks, policies and evidence. An Annex A control is marked not applicable only when every control mapped to it has been marked not applicable with a reason, and a row whose status cannot be determined says so rather than guessing. The same statement goes into the audit package for the certification body. The product documentation describes the export.