Almost every ISO 27001 project produces a Statement of Applicability, and a surprising number of them are wrong in the same way. The spreadsheet lists all 93 Annex A controls, marks nearly all of them as applicable, and gives the same one line reason for each: "required by ISO 27001" or "applicable to the business". It looks complete. It tells an auditor almost nothing.
The Statement of Applicability is not a checklist of the standard. It is the record of decisions your organisation made about its own security: which controls it needs, why it needs them, which it does not need and why not, and how far it has got in putting them in place. Written that way, it becomes one of the most useful documents in the management system. Written as a checklist, it becomes the first place an auditor finds a gap.
What is a Statement of Applicability?
The Statement of Applicability, usually shortened to SoA, is a mandatory document in ISO 27001. It lists every control in Annex A of the standard and, for each one, records whether it applies to the organisation, why, and whether it is implemented. It is the link between the risk assessment, where you decide what could go wrong, and the controls you actually operate to prevent or limit it.
In practice, the SoA is the document that turns an abstract risk analysis into a concrete list of commitments. A risk register might say that the loss of customer data through a compromised laptop is a high risk. The SoA is where that risk becomes specific controls: endpoint devices (8.1), use of cryptography (8.24), information deletion (8.10), and the reason each one is there.
It also serves people outside the security team. Certification bodies use it to plan the audit. Enterprise customers sometimes ask to see it, or a summary of it, during due diligence. New staff in IT or compliance read it to understand what the organisation has committed to. For all of them, the quality of the justifications is what makes it useful.
What does clause 6.1.3 d require it to contain?
The requirement sits in clause 6.1.3 of ISO 27001:2022, which covers information security risk treatment. The clause asks the organisation to determine all the controls needed to implement its chosen risk treatment options (6.1.3 b), compare them with Annex A to check that no necessary control has been overlooked (6.1.3 c), and then produce a Statement of Applicability (6.1.3 d).
The SoA must contain four things: the necessary controls; the justification for including them; whether those controls are implemented or not; and the justification for excluding any Annex A control. Those four elements are the minimum. An SoA that lists controls without justifications, or marks exclusions without saying why, does not meet the clause, however tidy the spreadsheet looks.
Two details are easy to miss. First, the necessary controls do not have to come only from Annex A. If your risk treatment requires a control the annex does not describe, for example a specific contractual check on a critical customer's data, it belongs in the SoA too. Second, the standard asks whether controls are implemented, which means the SoA has to be kept honest over time. A control marked as implemented when it is still in progress is one of the most common audit findings in a first certification.
How is Annex A organised in ISO 27001:2022?
The 2022 revision reorganised Annex A completely. The 114 controls of the 2013 version, spread across 14 domains, became 93 controls grouped into four themes. Many old controls were merged, and 11 new ones were added, including threat intelligence, information security for the use of cloud services, ICT readiness for business continuity, data leakage prevention and secure coding.
The four themes are organisational controls (37, numbered 5.1 to 5.37), people controls (8, numbered 6.1 to 6.8), physical controls (14, numbered 7.1 to 7.14) and technological controls (34, numbered 8.1 to 8.34). The themes are a way of grouping, not a hierarchy: a physical control is not less important than a technological one, and an SoA should be read control by control rather than theme by theme.
The transition period from the 2013 version ended on 31 October 2025, so any certificate in force today is issued against ISO 27001:2022. If your SoA still uses the old numbering or the 14 domains, it needs to be rebuilt rather than relabelled, because several controls changed scope when they were merged. Annex A only gives each control a short statement. ISO 27002 explains each one in detail and is the reference most teams use when deciding what implementation looks like.
How do you decide which Annex A controls apply?
Applicability is a decision, and the standard expects that decision to come from specific sources. A control applies because a risk requires it, because a law or a contract requires it, or because the scope of the management system makes it relevant. "It seemed sensible" is not a source, and neither is "the consultant included it".
Start from the risk treatment plan
The risk treatment plan is the primary input. For each risk you decided to treat, the plan names the controls that reduce it. Each of those controls is applicable, and the justification in the SoA should point back to the risk or risks it addresses. A good justification reads like "Treats R07 (unauthorised access to production through shared admin accounts) and R12 (inability to trace changes to customer data)", not like "Access control is important".
Working from the plan also exposes gaps in the risk assessment. If you find yourself wanting to include a control that no risk points to, either the control is not needed or the risk assessment missed something. Both answers are useful. The second one is more common than teams expect, especially for supplier and cloud risks that were never written down because "the provider handles it".
Add legal, regulatory and contractual obligations
Some controls apply regardless of your own risk appetite, because someone else requires them. Data protection law brings in privacy and protection of personal information (5.34). Sector regulation may bring in logging, retention or incident notification. Customer contracts often require specific controls, such as background checks for staff with access to their data (6.1) or encryption of data at rest (8.24). Control 5.31 asks you to identify these legal, statutory, regulatory and contractual requirements in the first place.
Write these obligations into the justification explicitly. "Required by the master services agreement with our largest customer, clause 14.2" is precise and auditable. It also helps later: when that contract ends or changes, you know which SoA lines to revisit.
Check scope boundaries
The scope of the management system decides which controls can apply at all. A company whose scope covers a SaaS platform hosted entirely with a cloud provider, with no offices in scope, will treat physical controls very differently from one that runs its own data centre. That does not mean physical controls disappear: offices where staff work with customer data, or home working arrangements, still raise physical risks.
Scope is also where many exclusions are won or lost. If the scope statement says the company develops software, an exclusion of secure development controls (8.25 to 8.28) will not survive the audit. Read the scope document and the SoA side by side before you finalise either.
How do you justify excluding a control?
Excluding a control is allowed, and sometimes necessary. What the standard asks for is a justification, and what auditors test is whether the justification holds against your scope, your risks and the evidence they find on site. A weak exclusion is worse than an honest inclusion with a partial implementation, because it signals that the organisation did not understand its own environment.
Consider three common cases. For 8.28, secure coding, a company that buys all its software and develops nothing may exclude it. A weak justification says "Not applicable". A strong one says "The organisation does not develop or modify software within the scope; all applications are commercial SaaS, assessed through supplier controls 5.19 to 5.22". The strong version tells the auditor what to check: that there really is no development, and that the supplier controls exist.
For 7.4, physical security monitoring, a fully remote company may argue it has no premises to monitor. A weak justification says "We are remote". A strong one says "No premises are within scope; staff work from home under the remote working policy (6.7), and equipment off premises is covered by 7.9. Data centre monitoring is provided by the cloud provider and verified through its ISO 27001 certificate and SOC 2 report". This shows the risk was considered and moved elsewhere, not ignored.
For 5.23, information security for the use of cloud services, an exclusion is almost never credible today. Even a company with no cloud infrastructure of its own uses cloud email, file storage and collaboration tools. An exclusion here usually means the cloud services were never inventoried, which is a finding in itself. The test for every exclusion is the same: could an auditor walk around the company and find something that contradicts it?
Template: the columns every SoA needs
A Statement of Applicability can be a spreadsheet, a table in a document or a view in a compliance platform. The format matters less than the columns. These are the ones an SoA needs to meet the clause and to be useful afterwards.
- Control reference and name. The Annex A number and title, for example 5.15 Access control, plus any additional controls that do not come from Annex A.
- Applicable: yes or no. A clear decision for every control, with no blanks and no "partially".
- Justification for inclusion or exclusion. The specific risk identifiers, legal or contractual obligations, or scope reasons behind the decision.
- Implementation status. Implemented, partially implemented or planned, with a target date for anything not yet in place.
- How the control is implemented. A short description or a reference to the policy, procedure or system that delivers it.
- Owner. The person or role responsible for operating the control.
- Evidence. Where an auditor can see the control working: a log, a report, a ticket, a review record.
The last three columns are not strictly required by clause 6.1.3 d, but they are what turns the SoA from a declaration into a working document. Without an owner, nobody maintains the control. Without a pointer to evidence, every audit starts with a search.
What do auditors look for in the SoA?
Certification auditors use the SoA as their map of the management system. In the stage 1 audit, they review it alongside the scope, the risk assessment and the risk treatment plan, and check that the three are consistent. Controls in the treatment plan should appear as applicable in the SoA; exclusions should not contradict the scope or the risks. Inconsistencies at this stage often lead to findings before the main audit has begun.
In the stage 2 audit, they sample. They pick controls marked as applicable and implemented and ask to see them working: the access review that control 5.18 says happens quarterly, the backup restore test behind 8.13, the supplier assessment behind 5.21. They also pick exclusions and check them against what they see. An excluded control that turns out to be relevant is a nonconformity, and it raises questions about the rest of the document. Our article on what a certification audit actually tests describes this sampling in more detail.
Finally, auditors look at dates and versions. An SoA last updated a year ago, in a company that has since changed cloud provider or added a product, tells them the document is not part of how the organisation works. That observation tends to colour the rest of the audit.
Keeping the SoA current between audits
The SoA should change whenever the inputs that produced it change. A new risk in the register, a new supplier that processes sensitive data, a new contract with specific security clauses, a change in scope, a new system or a retired one: each of these can make a control applicable, change its justification or move its implementation status. Waiting for the next audit to catch up turns a small update into a reconstruction.
The simplest way to keep it current is to link it to the processes that already exist. When the risk register is reviewed, review the affected SoA lines in the same meeting. When a supplier is onboarded, check whether supplier controls need updating. When the management review takes place, as clause 9.3 requires, include the SoA in the inputs and record any decisions. Each SoA version should have a date, an owner and a short note of what changed.
This is also where an information security management system differs from a set of documents. In a working ISMS, the SoA, the risk register and the evidence are connected, so a change in one shows up in the others. Companies that run ISO 27001 alongside the ENS can keep a single control set for both and map it to each framework, as we explain in running ISO 27001 and the ENS as one programme. On the Qalea platform, the SoA and the risk register live in the same place as the evidence, so applicability decisions and implementation status stay linked to the controls they describe. For more on the standard, see the ISO 27001 articles.
