The ISO 27001 statement of applicability matters because it is the document auditors read first, and the one teams most often get wrong. Clause 6.1.3(d) requires it, and ISO 27001 compliance depends on it: it records which Annex A controls the organization needs, whether each one is implemented, and why any control was left out. Since the 2022 revision, Annex A holds 93 controls in four themes instead of 114 in fourteen clauses, and 11 of them are new. A statement of applicability that still follows the 2013 numbering, or that skips those 11 controls, is a finding waiting to happen. This article covers why the SoA matters, what it must contain, the requirements teams miss, and how to keep the document current.
What the ISO 27001 Statement of Applicability Must Contain
The Four Elements Clause 6.1.3(d) Requires
The standard asks for a Statement of Applicability that contains the necessary controls, the justification for including them, whether each one is implemented or not, and the justification for excluding any Annex A control. Those are four elements, and a document missing one of them does not meet the clause. The controls come from your risk treatment decisions, not from a template. Organizations must have this document to be certified, and it is among the first records an auditor reviews.
Where the SoA Sits in the Risk Treatment Process
Clause 6.1.3 sets out a sequence. First, the organization determines all the controls necessary to carry out the risk treatment options it chose. Second, it compares those controls with Annex A to check that no necessary control was left out. Third, it produces the SoA. Fourth, it writes a risk treatment plan, and fifth, it obtains the risk owners’ approval of that plan and their acceptance of the residual risk. The SoA is therefore the middle of a chain, and if the information security risk assessment is weak, the SoA inherits the weakness.
ISO 27001 SoA Requirements Teams Miss
These are the requirements worth checking first, before an auditor does.
A Legacy SoA Still Follows the 2013 Numbering
The transition to ISO/IEC 27001:2022 ended on October 31, 2025, and ISO/IEC 27001:2013 certificates are no longer valid. An SoA that lists 114 controls across 14 clauses has to be mapped to the 2022 structure: A.5 organizational (37 controls), A.6 people (8), A.7 physical (14), and A.8 technological (34). The mapping is not a renumbering exercise, because some 2013 controls were merged and others were renamed, so each decision needs to be reviewed against the current wording. The Elevate guide to Annex A controls explains the 2022 structure.
The 11 New Controls Have No Recorded Decision
Every 2022 control with no 2013 equivalent needs an explicit decision in the SoA: included with a status, or excluded with a justification. The table lists the 11 and the question each one forces the SoA to answer.
| Control | Name | Question the SoA should answer |
|---|---|---|
| A.5.7 | Threat intelligence | Who collects and reviews threat information, and how often? |
| A.5.23 | Information security for use of cloud services | Which cloud services are in scope, and who owns the controls at the provider? |
| A.5.30 | ICT readiness for business continuity | Which ICT services have continuity requirements, and how are they tested? |
| A.7.4 | Physical security monitoring | How are premises monitored, and who reviews the alerts? |
| A.8.9 | Configuration management | Where are secure baselines defined, and how are changes tracked? |
| A.8.10 | Information deletion | When is data deleted, and what record shows it? |
| A.8.11 | Data masking | Which data is masked, and in which environments? |
| A.8.12 | Data leakage prevention | Which channels are monitored for leaks? |
| A.8.16 | Monitoring activities | What is monitored for anomalous behavior, and who responds? |
| A.8.23 | Web filtering | Which categories are blocked, and for which users? |
| A.8.28 | Secure coding | Which coding standard applies, and how is it checked? |
An exclusion is allowed when the scope supports it. An organization that develops no software, for example, can justify excluding A.8.28 by pointing to its scope. What it cannot do is leave the control without any decision.
“Applicable” Is Not the Same as “Implemented”
Clause 6.1.3(d) asks for a statement on whether each included control is implemented. An included control can be planned, partly implemented, or fully implemented, and the SoA should say which. Marking a control as applicable without a status hides the gap an auditor is looking for, and marking a planned control as implemented is worse. Record the status, the owner, and the target date for every control that is not yet in place, and keep the risk treatment plan consistent with those dates.
Exclusions Need a Reason That Ties to Scope and Risk
A reason such as “we have not implemented it yet” or “it is too expensive” is not a justification for exclusion, because an excluded control is one the organization does not need. If the risk exists, the answer is to treat it, avoid it, transfer it, or have the risk owner accept it, and that decision belongs in the treatment plan. Valid exclusions point to the ISMS scope or to the absence of a relevant risk or requirement, for example a premises control when no premises are in scope. The Elevate example of scoping an ISMS across multiple entities shows how scope drives these decisions.
Controls From Outside Annex A Are Missing
Annex A is a reference list, not a ceiling. The standard allows organizations to design controls or take them from any source, and the comparison with Annex A exists to confirm that nothing necessary was omitted. If a customer contract, a regulation, or another framework requires a control that Annex A does not cover, add it to the SoA with the same status and justification as any other control. Teams that already work to other frameworks can reuse the controls they have in place.
Legal and Contractual Drivers Are Not Recorded
Control A.5.31, legal, statutory, regulatory and contractual requirements, belongs in the SoA with the specific requirements it covers. Those requirements can make a control necessary even when the risk assessment rated the related risk low, so record them as the justification for inclusion. A line such as “required by customer contract” or “required by regulation” is easier for an auditor to verify than a general statement about compliance.
Third-Party and Cloud Controls Are Left Blank
Controls that a cloud provider or supplier operates for you still belong in the SoA. Record the control as included, name who operates it, and reference the supplier agreement and the evidence the supplier provides. Controls A.5.19 to A.5.23 cover supplier relationships, supplier agreements, the ICT supply chain, supplier monitoring, and cloud services, and they are the natural anchors for these entries.
Version Control and Approval Are Informal
The SoA is documented information, so it needs an identifier, a version, a date, an author, and an approver. Auditors compare the SoA with the risk treatment plan and the records, and mismatched versions raise questions quickly. Keep a version for each audit cycle, for example SoA v3.0 (2026), and keep the earlier versions, which shows how the document changed after each risk assessment.
Evidence References Are Missing
For each included control, the SoA should point to the policy, procedure, or record that shows it operating. These references turn the SoA into an index of the ISMS and let an auditor move from a control to its evidence in one step. Without them, the auditor has to ask, and every question lengthens the audit. Reference the record itself, such as the policy version or the review report, and not only the name of a folder.
How the SoA Connects to Risk Assessment and Treatment
Every control in the SoA should trace to a risk treatment decision. The SoA shows which Annex A controls you selected for the risks you chose to treat, and it explains why you included or excluded each one. ISO 27001 describes four ways to treat a risk:
- Mitigate: apply controls to reduce the risk, for example multi-factor authentication.
- Avoid: change the process so the risk no longer exists.
- Transfer: share the risk with a third party through insurance or outsourcing.
- Accept: accept a risk that is low or not worth treating, with the risk owner’s approval.
The connection works in both directions. A new service provider that handles sensitive data changes the risk assessment, and the SoA shows which controls need to change with it.
Example: Controls Selected for Unauthorized Access Risk
Take an organization whose assessment found a risk of unauthorized access to customer data, from outside attackers and from internal mistakes. It could select A.5.15, access control, to limit access to those who need it under the principle of least privilege, together with A.5.18, access rights, and A.8.5, secure authentication. For mistakes in email and data handling, it could select A.5.14, information transfer, and A.6.3, awareness, education and training. For malware, it could select A.8.7, protection against malware. Each control then appears in the SoA with its status and justification. The extract below is illustrative, not a template.
| Control | Status | Justification | Evidence |
|---|---|---|---|
| A.5.15 Access control | Implemented | Unauthorized access to customer data rated high in the risk assessment | Access control policy, quarterly access review records |
| A.8.7 Protection against malware | Implemented | Malware risk to endpoints rated high | Endpoint protection configuration, console reports |
| A.8.11 Data masking | Planned (owner: CISO, target date set) | Test environments use customer data | Draft masking standard |
What Auditors Read in the SoA
The SoA has to be ready for the Stage 1 audit, where the auditor reviews the documented information, and the auditor tests it in Stage 2 by checking that the controls operate as the SoA says. The final version is what the certification body works from. The Elevate guide to Stage 1 and Stage 2 audits covers what each stage examines.
After certification, surveillance audits take place during the three-year cycle, and they sample the ISMS rather than repeat the full audit. The SoA is the map auditors use to decide what to test, so every status and justification in it can be tested. A control marked as implemented without evidence will not survive that test, which is why the surveillance audit is a good moment to review the SoA against the records. Aligning the status and the records before the audit avoids findings that are easy to prevent.
How to Keep the SoA Current
A yearly review aligned with the risk assessment is a common minimum. Several events should trigger an earlier review:
- Major business changes such as expansion, mergers, or cloud migration
- New risks, or changes to the impact of existing ones
- Incidents that expose control weaknesses
- Internal or external audit findings
- Changes in organizational structure or operations
- New legal, regulatory, or contractual requirements
A spreadsheet template gives the SoA a consistent structure and lists all 93 controls, and an ISMS or GRC platform can link each control to its evidence and keep the version history. Neither one writes the justifications, which have to come from your own risk decisions. Want to know if your SoA is audit-ready? Book a Readiness Call with Elevate’s ISO 27001 specialists, who review the document against the risk treatment plan and the evidence before the certification audit.
Where the SoA Fits in ISO 27001 Compliance
The SoA is one step in a sequence: define the scope, assess the risks, decide the treatment, produce the SoA and the treatment plan, run the internal audit and the management review, and then go through the certification audit. The clauses 4 to 10 requirements and the step-by-step path to compliance show where each step sits, and Elevate’s ISO 27001 service covers the full path. Organizations that also work toward ISO 42001 can reuse much of this structure, as the comparisons of ISO 27001 and ISO 42001 and of ISO 42001 with ISO 27001 and ISO 9001 explain. For a view across frameworks, see how ISO 27001 compares with other IT compliance certifications.
Conclusion
The statement of applicability is where an ISO 27001 program shows its reasoning. A document that follows the 2022 structure, records a decision on all 11 new controls, separates applicable from implemented, and justifies every exclusion gives an auditor little to question. A document that does not turns a routine review into a list of findings.
Teams that want a second pair of eyes before the audit can Book a Readiness Call with Elevate. Elevate prepares organizations for audits performed by accredited certification bodies and does not issue certifications.
Key Takeaways
The SoA is the record of your reasoning, and the requirements below are the ones teams miss.
- Move to the 2022 structure. The 2013 transition ended on October 31, 2025, so the SoA must use the 93 controls in four themes.
- Decide on the 11 new controls. Each one needs an inclusion with a status or an exclusion with a justification.
- Separate applicable from implemented. Record the status, owner, and target date for every control not yet in place.
- Justify exclusions with scope and risk. Cost and “not yet” are not valid reasons.
- Record drivers, suppliers, and versions. Legal and contractual requirements, third-party controls, and the approved version belong in the document.
FAQs
What is the ISO 27001 statement of applicability?
It is the mandatory document, required by clause 6.1.3(d) of ISO/IEC 27001, that lists the controls an organization has determined are necessary, states whether each is implemented, and justifies every inclusion and every exclusion of an Annex A control. It links the risk treatment decisions to the controls in place. Auditors use it as a map of the information security management system.
What must an ISO 27001 SoA contain?
It must contain the necessary controls, the justification for including them, whether each one is implemented or not, and the justification for excluding any Annex A control. In practice, teams also record the control owner, the supporting evidence, and the document version. The Annex A reference list holds 93 controls in four themes.
Does the SoA have to cover all 93 Annex A controls?
Yes, in the sense that every Annex A control needs a decision: included with a status and a justification, or excluded with a justification. The organization can also add controls from other sources. The 11 controls that are new in 2022 need the same explicit decision as the rest.
Can a control be excluded because it is too expensive or not yet implemented?
No. Exclusion means the organization does not need the control, so the reason must relate to scope, risk, or the absence of a requirement. A control that is needed but not yet in place stays in the SoA with a status of planned, and a risk the organization chooses not to treat is accepted by the risk owner in the treatment plan.
How often should the SoA be updated?
A yearly review aligned with the risk assessment is a common minimum. The SoA should also be updated after major business changes, new risks, incidents, audit findings, or new legal and contractual requirements. Each update should produce a new version with a date and an approver.