ZCybersecurity

Compliance › ISO 27001 › Statement of Applicability

ISO 27001 Statement of Applicability

ISO 27001 Statement of Applicability (SoA): what it is and how to write one

The Statement of Applicability is the one ISO 27001 document that every auditor reads closely. This guide explains what clause 6.1.3(d) requires, how the SoA connects to your risk assessment, how to write justifications that hold up and the mistakes that cause findings.

Tell Us What You NeedSee the 7 steps

Free for buyers · provider-funded introductions · Updated October 2026

The SoA at a glance
Required byClause 6.1.3(d) of ISO/IEC 27001
ListsThe controls you have determined are necessary
ExplainsWhy each is included and whether it is implemented
Also explainsWhy any Annex A control is excluded
Built fromYour risk assessment and treatment decisions
NotA promise to implement all 93 Annex A controls
The short answer

What is a Statement of Applicability in ISO 27001?

The Statement of Applicability (SoA) is a mandatory ISMS document. It lists the information security controls you have determined are necessary, gives the justification for including them, states whether each is implemented, and gives the justification for excluding any Annex A control. It is the bridge between your risk assessment and the controls an auditor will test.

  • Annex A is a reference list of 93 controls, not a list you must all implement. The SoA is where you record which apply and why.
  • Every exclusion needs a reason. A blank or vague reason is a common audit finding.
  • The SoA must follow from your risk assessment. See the requirements guide and the Annex A controls list.
Where it fits

How the SoA is produced from your risk work

You do not start with the SoA. You finish it last, from decisions already made.

How the Statement of Applicability is producedHow the Statement of Applicability is produced, in six steps. One, assess information security risks. Two, choose how to treat each risk. Three, determine every necessary control from any source. Four, compare those controls with Annex A so nothing needed is missed. Five, write the Statement of Applicability, listing controls, reasons, implementation status and the reasons for any Annex A exclusions. Six, risk owners approve the treatment plan and accept the residual risk. The cycle is reviewed when risks, scope or controls change. The risk assessment is the input and the SoA is the output.1Risk assessmentFind and rateinformationsecurity risks2TreatmentChoose how totreat each risk3Needed controlsDetermine everycontrol needed,from any source4Annex A checkCompare withAnnex A so nothingneeded is missed5Write the SoAList controls,reasons, statusand exclusions6ApproveRisk owners acceptthe plan and theresidual riskReview when risks, scope or controls changeThe risk assessment is the input. The SoA is the output.
The SoA is the last of six steps, not the first.

Clause 6.1.3 also asks you to compare your determined controls with Annex A to verify that no necessary control has been omitted. Annex A is not exhaustive, so you may add controls from other sources.

The requirement

What clause 6.1.3(d) requires, in plain terms

What clause 6.1.3(d) asks the Statement of Applicability to contain
Clause 6.1.3(d) asks forIn plain termsWhat an auditor tends to look for
The necessary controlsEvery control your risk treatment needs, from Annex A or anywhere elseA traceable link from risks to controls
Justification for including themWhy each control is inA reason tied to a risk, contract or legal duty, not just that the standard lists it
Whether they are implementedAn honest status for each controlA status that matches what they see in practice
Justification for excluding any Annex A controlWhy each Annex A control you left out is not neededA specific, risk-based reason that holds up under questioning

ISO/IEC 27001:2022 still requires the SoA. What changed in 2022 is the Annex A list it refers to: 93 controls in four themes. The 2013 transition has ended, so check that your SoA refers to the 2022 list. See the Annex A guide.

Anatomy

What a Statement of Applicability looks like

The standard sets what it must contain, not its layout. A spreadsheet or a table in a tool both work.

Anatomy of a Statement of Applicability rowThree illustrative Statement of Applicability rows with columns control, applies, why, status and owner. A.5.15 Access control applies, because of a named access risk, and is implemented. A.5.30 ICT readiness for business continuity applies, because customer contracts require tested recovery, and is in progress. A.8.28 Secure coding does not apply, because the company does not develop software and the scope covers hosted services it buys. These are examples, not a template for your company. Each row answers what clause 6.1.3(d) asks: which control, why, and whether it is implemented.ControlApplies?Why (inclusion or exclusion)StatusOwnerA.5.15 Access controlYesRisk R-04: unauthorised access to customerdata. Role-based access is requiredImplementedIT leadA.5.30 ICT readinessYesCustomer contracts require tested recovery.Plan exists and testing is scheduledIn progressOps leadA.8.28 Secure codingNoWe do not develop software. The scope covershosted services we buy, not code we writeNot applicableHead of eng.Illustrative rows. Each answers what clause 6.1.3(d) asks: which, why, implemented or not.
Three illustrative rows. Your reasons will differ.
Columns in a Statement of Applicability
ColumnWhy it is thereSource
Control reference and nameIdentifies the control, usually from Annex AFrom the standard
Applies or notRecords the include or exclude decisionFrom the standard
JustificationGives the reason for inclusion or exclusionFrom the standard
Implementation statusSays whether the control is implementedFrom the standard
Control ownerNames who is accountableGood practice
Linked risk or requirementShows why the control existsGood practice
Evidence referencePoints the auditor to proofGood practice
Version and review dateShows the document is controlled and currentGood practice
How to write it

How to write a Statement of Applicability in 7 steps

1

Finish the risk assessment

Identify and rate your information security risks within your scope. The SoA needs these as its input.

2

Choose treatment options

Decide for each risk whether to modify, retain, avoid or share it. Controls follow from the ones you modify.

3

Determine the controls you need

List every control needed to treat your risks. They can come from Annex A, from another framework or from your own design.

4

Check against Annex A

Walk through all 93 Annex A controls. Confirm none you need has been missed, and note the ones you will not use.

5

Record each decision

For every control, write applies or does not apply, with a specific reason tied to a risk, a contract, a law or your scope.

6

Add status and owner

State whether each applicable control is implemented, in progress or planned, and name an owner and where the evidence lives.

7

Approve and version it

Get the risk treatment plan approved and residual risk accepted by risk owners, and put the SoA under document control. Ask your certification body who it expects to approve the SoA.

Justifications

Weak and strong justifications

The reasons are where most SoAs fail. A reason should name something real.

Weak and strong SoA justifications
SituationWeak entryStronger entry
Control includedRequired by ISO 27001Treats risk R-04, unauthorised access to customer data
Control excludedNot relevantWe do not develop software, and our scope covers only services we buy
Risk accepted insteadToo costlyRisk assessed as low and formally accepted by the named risk owner
Control implementedDoneImplemented. Evidence: quarterly access review records
Control not yet in placeLeft blankIn progress, in the treatment plan, owner named
Avoid findings

Common Statement of Applicability mistakes

  • Copying a template unchanged: generic reasons do not match your risks.
  • Vague exclusions: “not applicable” with no reason.
  • Deleting excluded controls: keep them listed with the reason.
  • No link to risk: controls that trace to nothing.
  • Claiming implemented too early: the status must be true at audit.
  • Scope mismatch: excluding something your scope clearly includes.
  • Forgetting the 2022 list: still using the 2013 numbering.
  • Never updating it: the SoA drifts away from the real ISMS.
Keeping it live

Keeping the Statement of Applicability current

Keep reading

Related ISO 27001 guides

Controls
All 93 Annex A controls
Requirements
Clauses 4 to 10 explained
Checklist
The ISO 27001 checklist and tracker
Process
The certification process step by step
Providers
How to choose a certification body
Hub
ISO 27001 overview
FAQ

ISO 27001 Statement of Applicability: questions answered

What is a Statement of Applicability in ISO 27001?
A mandatory ISMS document required by clause 6.1.3(d). It lists the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control.
Is the Statement of Applicability mandatory?
Yes. It is a requirement of the standard, and certification bodies expect it. Without it you cannot show how your risk assessment led to your controls.
Do I have to implement all 93 Annex A controls?
No. You implement the controls your risk treatment needs. You may exclude Annex A controls that do not apply, but each exclusion needs a justification that stands up under audit. See the Annex A controls list.
Can I use controls that are not in Annex A?
Yes. Annex A is a reference list, not a ceiling. Controls from other sources or your own design can be included if your risks need them.
What is the difference between the SoA and the risk treatment plan?
The risk treatment plan covers how each risk is treated, who owns it and when. The SoA lists which controls apply, why and whether they are implemented. They should agree with each other.
Who approves the Statement of Applicability?
Clause 6.1.3 requires risk owners to approve the risk treatment plan and accept residual risks. Many organisations also have top management approve the SoA. Ask your certification body what it expects.
How often should I update the SoA?
The standard sets no interval. Update it when your risks, scope or controls change, and review it as part of management review. Many organisations review it at least once a year.
Do I have to show the SoA to customers?
The standard does not oblige you to. Auditors will see it, and some customers ask for it. Decide what you are willing to share and whether to do so under an agreement.
Can I mark a control as applicable before it is implemented?
Yes, with an honest status such as planned or in progress and a place in your treatment plan. Certification bodies differ in how much must be in place at audit, so ask yours. See the certification process guide.
Is there an ISO 27001 SoA template?
Many exist, but the standard does not prescribe one. Use a layout that captures the control, the decision, the reason, the status, the owner and the evidence, as shown above, and tailor every reason to your own risks.
What changed in the SoA for ISO 27001:2022?
The requirement to produce a SoA stayed. The Annex A list it refers to changed to 93 controls in four themes, with 11 new controls. Check that yours uses the 2022 list.
Do auditors check the SoA against reality?
Auditors commonly use it to plan what to test, and may sample controls to see that the stated status is true. A status that does not match practice is likely to be a finding.
Start here

Know what goes in your SoA? Get matched with the right provider.

Your scope→Controls→Budget→Matched provider
Tell Us What You Need

Free for buyers · provider-funded introductions · Reviewed October 2026 by the ZCyberSecurity compliance team

Scroll to Top