ISO 27001 Statement of Applicability Explained

• What Is a Statement of Applicability?
• Why Is the Statement of Applicability Important?
• Is a Statement of Applicability Required by ISO 27001?
• What Should an ISO 27001 Statement of Applicability Include?
• How the Statement of Applicability Relates to Annex A Controls
• How to Create a Statement of Applicability
• ISO 27001 Statement of Applicability Example
• Common Mistakes When Creating a Statement of Applicability
• What Auditors Look For in a Statement of Applicability
• ISO 27001:2013 vs ISO 27001:2022 Statement of Applicability Changes
• How Training Can Help With ISO 27001 Documentation
• Frequently Asked Questions

The Statement of Applicability is a controlled document that sets out the information security controls an organisation has judged necessary to treat its identified risks, together with the reasoning behind each decision. It is produced as part of the information security risk treatment process and sits at the centre of the ISMS documentation set.

Its purpose is to make security decisions visible and defensible. Rather than simply asserting that an organisation is secure, the SoA shows the chain of reasoning: these are the risks we identified, these are the controls we chose to address them, this is why, and this is how far we have got with implementation.

That makes the document a bridge between three things that would otherwise sit in isolation:

• The risk assessment, which identifies and evaluates information security risks
• Risk treatment, which decides how those risks will be managed
• Annex A, the reference set of controls used to check that nothing necessary has been overlooked

Because it connects all three, the SoA is often the quickest way for an auditor, a customer, or a new member of staff to understand how an ISMS actually works.

The standard does not prescribe a fixed set of controls for every organisation. It expects each organisation to decide what is necessary based on its own risks. The SoA is the evidence that this thinking has taken place rather than a generic control set being adopted without scrutiny.

Certification bodies review the SoA early, typically during the Stage 1 audit, and use it to plan the Stage 2 assessment. A vague or incomplete document at this point tends to generate findings and can delay the audit.

During audits the SoA functions as a route map. An auditor will select controls from it and trace them through to policies, records, and operational practice to confirm that what is claimed matches what happens.

Security decisions made informally tend to be forgotten. Documenting them means that when a risk changes, when staff move on, or when a customer asks why a particular control is not in place, the answer already exists in writing.

Yes. It is mandatory, not optional. Clause 6.1.3 d) of ISO/IEC 27001:2022 requires the organisation to produce a Statement of Applicability, and an ISMS cannot be certified without one.

Specifically, the standard requires the organisation to:

• Determine all controls necessary to implement the chosen risk treatment options
• Record the justification for including each of those controls
• State whether each necessary control is implemented or not
• Record the justification for excluding any of the Annex A controls

That third point is frequently missed. Implementation status is a stated requirement of the clause, not a helpful extra. An SoA that lists controls and justifications but says nothing about whether they are actually in place does not meet the requirement.

Most organisations build the document as a table with one row per control. The standard does not mandate a format, so the structure below reflects common practice rather than a prescribed template, but it captures everything clause 6.1.3 d) calls for.

Element	Description
Control Reference	The identifier, for example 5.15 or 8.24, so the control can be traced to Annex A or to another source
Control Name	The title of the control, kept consistent with the wording used elsewhere in the ISMS
Applicable?	A clear yes or no. Ambiguous entries such as “partial” cause problems at audit
Justification	The reason for inclusion or exclusion, referenced to a specific risk, legal requirement, or contractual obligation
Implementation Status	Whether the control is implemented, partially implemented, or planned, with target dates where relevant
Supporting Evidence	A pointer to the policy, procedure, or record that demonstrates the control is operating

The justification column is where most of the value sits. A single well-written sentence tying the control to a specific risk is worth more than a paragraph of generic text repeated across every row.

Annex A of ISO/IEC 27001:2022 contains 93 controls, derived from and aligned with ISO/IEC 27002:2022, arranged under four themes:

Theme	Clause range	Number of controls
Organisational controls	5.1 to 5.37	37
People controls	6.1 to 6.8	8
Physical controls	7.1 to 7.14	14
Technological controls	8.1 to 8.34	34

Two points about Annex A are widely misunderstood, and both matter when writing an SoA.

First, not every control will apply. A software house and a haulage firm face different risks and will reasonably reach different conclusions. Exclusions are legitimate provided they are justified.

Second, Annex A is not a menu to choose from and it is not exhaustive. The standard notes that controls can be designed as required or identified from any source, and that additional controls beyond Annex A can be included where they are needed. An SoA that contains a control drawn from another framework, properly justified, is entirely acceptable.

The order of these steps matters. Building an ISO 27001 Statement of Applicability before the risk work is finished is the single most common cause of a weak document.

Identify the risks to the confidentiality, integrity, and availability of information within the scope of the ISMS. Assign risk owners, assess consequence and likelihood, determine risk levels, and prioritise the results against your risk criteria. Everything downstream depends on this being done properly.

For each prioritised risk, decide how it will be managed. The available options include modifying the risk through controls, avoiding the activity that gives rise to it, sharing it with another party, or accepting it. Only risks being modified through controls will generate entries requiring implementation.

This step is routinely performed backwards, and getting it right is what separates a credible SoA from a tick-box exercise. The standard asks you to first determine all controls necessary to implement your chosen treatment options, drawing them from any suitable source, and then compare that set against Annex A to verify that nothing necessary has been omitted.

Annex A is a cross-check, not a shopping list. Starting with the list of 93 and working out which ones you fancy inverts the logic of the clause, and experienced auditors can spot the difference immediately: control selection that starts from Annex A tends to produce justifications that describe the control rather than the risk it addresses.

Record why each control is included, referencing the specific risk, legal requirement, or contractual obligation that drives it. Record why each excluded Annex A control does not apply. Exclusions need the same rigour as inclusions.

State honestly whether each control is implemented, partially implemented, or planned. Partial implementation is not a failure at initial certification provided there is a credible plan with dates. Claiming full implementation that evidence does not support is a far more serious problem.

The simplified extract below shows the level of specificity to aim for. A real document would cover all 93 Annex A controls plus any additional controls identified.

Control	Applicable	Reason
5.15 Access control	Yes	Required to address the risk of unauthorised access to customer data held in the CRM. Implemented through the Access Control Policy and quarterly access reviews.
8.24 Use of cryptography	Yes	Personal data is transmitted across public networks and stored on portable devices. Required to meet UK GDPR obligations and customer contract terms.
7.14 Secure disposal or re-use of equipment	Yes	End-user devices hold cached client information. Addresses the risk of data recovery from decommissioned hardware.
8.25 Secure development life cycle	No	The organisation does not develop software or systems in-house. All applications are commercial off-the-shelf products procured from third parties, which are addressed through supplier controls under 5.19 to 5.23.

Note how the exclusion in the final row does not simply state “not applicable”. It explains the operating reality that makes the control unnecessary and points to where the underlying concern is handled instead. That is the standard an auditor will expect.

Mistake	Why it causes problems
Treating every control as applicable	Marking all 93 controls as applicable to avoid difficult conversations creates an obligation to evidence all 93. It also signals that no genuine risk-based analysis took place, which is the opposite of what the SoA exists to demonstrate.
Failing to justify exclusions	Entries reading “not applicable” with no supporting reasoning are among the most frequently raised findings. The justification for exclusion is an explicit requirement of clause 6.1.3 d).
Copying generic templates	Downloaded templates produce justifications that could describe any organisation. Auditors read a great many of these and recognise them instantly. Templates are a reasonable starting structure but the reasoning has to be your own.
Not updating the document	An ISO 27001 SoA that has not changed in three years while the business has adopted cloud services, changed suppliers, and doubled in headcount is no longer describing the organisation being audited.
Missing evidence links	Controls marked as implemented with nothing to point to force the auditor to go looking. Linking each control to its supporting policy or record shortens audits and reduces findings.

Auditors typically test five things:

• Risk assessment alignment. Do the controls in the SoA correspond to the risks identified in the risk assessment, and can each be traced back to one?
• Control selection rationale. Is the reasoning specific to this organisation, or is it interchangeable boilerplate?
• Justification of exclusions. Is every excluded Annex A control accounted for, and does the reason stand up against how the business actually operates?
• Evidence of implementation. Where a control is marked as implemented, does the operational evidence support that claim?
• Consistency across ISMS documentation. Does the SoA agree with the scope statement, the risk treatment plan, the policies, and the internal audit records?

Inconsistency is the most damaging of the five. Where the SoA contradicts other documents, an auditor’s confidence in the whole management system drops, and the audit tends to widen in scope as a result.

This comparison is now historical. The transition period set by the accreditation bodies closed on 31 October 2025, after which ISO 27001:2013 certificates ceased to be valid, so all current certification is against the 2022 edition. It remains useful context when reading older documentation or inheriting an ISMS that has not been fully reworked.

	ISO 27001:2013	ISO 27001:2022
Number of Annex A controls	114	93
Structure	14 control domains (A.5 to A.18)	4 themes: organisational, people, physical, technological
Control attributes	None	Attributes introduced in ISO/IEC 27002:2022 to support filtering and reporting

The reduction from 114 to 93 did not mean controls were dropped wholesale. Many were merged, several were restructured, and a number of new controls were introduced covering areas such as threat intelligence, cloud services, and secure coding. For organisations that transitioned, the practical effect on the SoA was a renumbering exercise combined with genuine reassessment of the new and consolidated controls.

One point worth noting when reviewing an older document: an SoA still using the 2013 numbering has almost certainly not been reviewed since the transition, which raises questions well beyond the numbering itself.

Producing a defensible SoA depends less on document templates than on understanding what the standard is asking for. Formal training addresses that directly, and no ISO 27001 implementation guide substitutes for structured learning when the document has to withstand external audit.

SEQM Training offers CQI and IRCA certified ISO 27001 training courses at Foundation, Internal Auditor and Lead Auditor level, all delivered online. Each addresses the Statement of Applicability from a different angle.

The ISO 27001 Foundation Course covers the structure and intent of the standard, including how clause 6.1 links risk assessment, risk treatment, and control selection. It suits anyone contributing to ISMS documentation without a background in management systems.

The ISO 27001 Internal Auditor Course develops the ability to review an SoA critically: testing whether justifications hold, whether exclusions are sound, and whether implementation claims are supported by evidence. Finding these issues internally is considerably cheaper than having a certification body find them.

The ISO 27001 Lead Auditor Course covers evaluating the SoA during third-party audits, including how to sample controls, trace them to evidence, and assess consistency across the ISMS.