The Statement of Applicability (SoA) is one of the most important documents in an ISO 27001 Information Security Management System (ISMS).
It explains which information security controls the organization has determined are necessary, why those controls are included, whether they have been implemented, and why any Annex A reference controls have been excluded.
But the Statement of Applicability is frequently misunderstood.
It is not simply a spreadsheet containing the 93 Annex A controls with “Applicable” or “Not Applicable” beside each one.
A useful SoA tells a much more important story:
Risk and requirements → treatment decisions → necessary controls → Annex A comparison → Statement of Applicability → implementation
The Statement of Applicability sits near the end of that decision chain.
It should reflect decisions the organization has already made through its risk treatment process, not become the process used to make those decisions.
This guide explains what a Statement of Applicability is, what it should contain, how it connects to risk assessment and Annex A, and how to build one that is useful beyond certification.
What Is a Statement of Applicability?
The Statement of Applicability is documented information produced as part of the ISO 27001 information security risk treatment process.
It identifies the controls the organization has determined are necessary for treating information security risk.
The SoA also addresses the Annex A reference controls so the organization can demonstrate that it considered the complete reference set when determining its control environment.
At a practical level, the document helps answer four important questions:
- Which controls do we need? The SoA identifies the controls determined to be necessary.
- Why do we need them? The organization provides justification for including those controls.
- Have we implemented them? The SoA indicates their implementation status.
- Why have we excluded particular Annex A controls? Exclusions from the Annex A reference set need justification.
This makes the SoA one of the clearest connections between risk management and the organization’s information security controls.
Is a Statement of Applicability Required for ISO 27001?
Yes.
Organizations implementing ISO 27001 need to produce a Statement of Applicability as part of the information security risk treatment process.
This is not simply a certification body preference or a document commonly used by consultants.
The SoA is part of the ISO 27001 requirements.
However, ISO 27001 does not require every organization to use an identical spreadsheet or template.
The important issue is the information the SoA contains and whether it accurately reflects the organization’s risk treatment and control decisions.
Where the Statement of Applicability Fits
The SoA makes more sense when viewed as part of the larger risk management process.
A practical sequence looks like this:
- Understand the organization and its requirements.
- Define the ISMS scope.
- Establish the risk assessment methodology.
- Identify and evaluate information security risks.
- Determine how those risks will be treated.
- Determine the controls necessary to implement those treatment decisions.
- Compare the necessary controls with Annex A.
- Produce the Statement of Applicability.
- Implement and operate the controls.
- Monitor, evaluate, and improve the control environment.
Notice that the process does not start with the Statement of Applicability.
It starts with the organization and its risks.
For more on the preceding step, see ISO 27001 Risk Assessment: A Practical Guide.
What Should a Statement of Applicability Include?
At minimum, the SoA needs to communicate the organization’s control decisions clearly.
It should identify:
- the necessary controls;
- justification for including those controls;
- whether the necessary controls are implemented;
- justification for excluding Annex A reference controls.
Organizations often include additional information because it makes the document more useful operationally.
For example, a practical SoA might include:
| Field | Purpose |
|---|---|
| Control ID | Provides a consistent control reference |
| Control name | Identifies the control |
| Applicability | Shows whether an Annex A reference control is applicable |
| Justification | Explains the control decision |
| Implementation status | Indicates whether the necessary control is implemented |
| Control owner | Identifies responsibility |
| Related risk | Connects the control to risk treatment |
| Related policy or procedure | Points to supporting documentation |
| Evidence reference | Identifies how operation may be demonstrated |
Not every organization needs all of these columns.
The SoA should remain manageable.
If adding a field does not help the organization understand, operate, or evaluate its control environment, it may not need to be there.
Does the SoA Need to Include All 93 Annex A Controls?
The organization needs to address the Annex A reference controls as part of its risk treatment process.
That does not mean all 93 controls must be implemented.
This distinction is critical.
The organization first determines the controls necessary to treat its information security risks and meet relevant requirements.
It then compares those controls with Annex A to verify that necessary controls have not been omitted.
The resulting Statement of Applicability shows the relationship between the organization’s necessary controls and the Annex A reference set.
Some Annex A controls may be included.
Others may be excluded with appropriate justification.
The goal is not:
93 controls = 93 mandatory implementations
The goal is:
A justified control environment appropriate to the organization’s risks and requirements
Our ISO 27001 Controls: A Practical Guide to Annex A explains this distinction in more detail.
What Does “Applicable” Mean?
When an Annex A control is marked applicable, the organization has determined that the control is necessary within its ISMS.
There may be several reasons.
For example, a control could be necessary because it:
- treats an identified information security risk;
- supports a legal or regulatory requirement;
- satisfies a contractual requirement;
- supports another organizational security requirement;
- forms part of the organization’s chosen risk treatment.
The justification should explain the actual reason.
Avoid generic statements that merely restate the decision.
For example:
Weak justification:
Applicable because the control is required.
That tells the reader almost nothing.
A stronger justification might be:
Applicable because the organization relies on third-party service providers that process or store information within the ISMS scope, requiring supplier security risks to be managed.
Or:
Applicable because privileged accounts can access sensitive production systems and require additional controls to reduce the risk of unauthorized administrative access.
The justification does not need to become an essay.
It needs to communicate why the control belongs in the organization’s ISMS.
What Does “Not Applicable” Mean?
An Annex A control may be excluded when the organization determines that it is not necessary.
The exclusion needs to be justified.
For example, suppose an Annex A reference control addresses a type of activity that does not occur within the organization’s ISMS environment.
The organization may determine that the control is not necessary.
A useful exclusion might explain:
Not applicable because the organization does not perform software development within the ISMS scope.
The exact justification depends on the control and organization.
What matters is that the decision is defensible.
A control should not be excluded simply because:
- implementation would be difficult;
- implementation would be expensive;
- nobody currently owns it;
- the organization has not gotten around to it;
- the audit is approaching.
Those situations may indicate an implementation gap rather than a legitimate exclusion.
Applicable Does Not Necessarily Mean Fully Implemented
This distinction is especially important during implementation.
A control can be:
Applicable but not yet implemented.
Suppose an organization determines that formal supplier security assessments are necessary.
The control belongs in the SoA because the organization has determined that it is needed.
But perhaps the supplier assessment process is still being developed.
The SoA might therefore reflect:
Applicable: Yes
Implementation status: In Progress
That is different from declaring the control not applicable.
Applicability answers:
Do we need this control?
Implementation status answers:
Have we put it into operation?
Do not use “Not Applicable” to hide controls that are necessary but incomplete.
How to Build a Statement of Applicability
A useful SoA can be developed systematically.
Step 1: Complete the Risk Assessment
The risk assessment identifies the information security risks the organization needs to manage.
Without meaningful risks, control decisions can become disconnected from business reality.
Step 2: Determine Risk Treatment
Decide what should happen with each risk requiring action.
Some risks may be accepted.
Others may require modification, avoidance, sharing, or another appropriate response.
Step 3: Determine Necessary Controls
Identify the controls needed to implement the treatment decisions and address other relevant requirements.
These controls do not have to originate from Annex A.
They might come from:
- internal security requirements;
- regulatory obligations;
- contractual requirements;
- customer requirements;
- another framework;
- industry practices;
- organization-specific control designs.
Step 4: Compare Necessary Controls With Annex A
Compare the organization’s necessary controls with the Annex A reference controls.
This comparison helps verify that necessary controls have not been inadvertently omitted.
Do not turn this into an exercise where Annex A automatically becomes the control environment.
Step 5: Determine Annex A Applicability
For each Annex A reference control, determine whether it is necessary within the ISMS.
The decision should follow the organization’s actual risks and requirements.
Step 6: Document the Justification
Explain why included controls are necessary and why excluded Annex A controls are not necessary.
Keep the reasoning specific enough to be meaningful.
Step 7: Record Implementation Status
Indicate whether necessary controls have been implemented.
Possible statuses might include:
- implemented;
- partially implemented;
- in progress;
- planned;
- not implemented.
The organization should define its terminology consistently.
Step 8: Review the SoA Against Reality
Do not assume the spreadsheet is correct simply because every row has been completed.
Sample controls and ask:
- Does the stated justification still make sense?
- Is the implementation status accurate?
- Does the control actually operate?
- Can the owner explain it?
- Does supporting documentation align with the SoA?
- Is there evidence?
- Have relevant risks changed?
The SoA should describe the actual control environment, not the control environment the organization wishes it had.
Example Statement of Applicability Entries
A simplified SoA might look like this:
| Control | Applicable? | Example Justification | Status |
|---|---|---|---|
| Supplier security control | Yes | Critical service providers process or support information within the ISMS scope and create information security dependencies | Implemented |
| Security awareness control | Yes | Personnel actions can affect the confidentiality, integrity, and availability of organizational information | Implemented |
| Secure development control | No | Software development is not performed within the defined ISMS scope | Not Applicable |
| Privileged access control | Yes | Administrative accounts can access sensitive systems and require additional restriction and oversight | In Progress |
These examples are deliberately simplified.
Actual justifications should reflect the organization’s environment and the specific control being evaluated.
Do not copy generic applicability statements into the SoA without determining whether they are true for your organization.
How Detailed Should SoA Justifications Be?
There is no benefit in writing a paragraph for every control if a clear sentence will do.
But one-word justifications are often too weak.
Consider:
Applicable: Risk
Technically, that may point toward a reason.
Operationally, it provides little useful information.
A better justification might be:
Applicable because unauthorized disclosure of customer information has been identified as an information security risk requiring controls over information transfer.
The reader can now understand the relationship.
The right level of detail is enough to answer:
Why did the organization make this control decision?
Should the SoA Map Controls to Risks?
Risk mapping can make the Statement of Applicability more useful, particularly when an organization wants stronger traceability.
For example:
| Control | Related Risks |
|---|---|
| Privileged access management | R-003, R-011 |
| Supplier security assessment | R-007 |
| Backup controls | R-004, R-016 |
This can help answer questions such as:
- Which risks depend on this control?
- Which controls are being used to treat this risk?
- What happens to residual risk if this control fails?
- Are several high risks dependent on the same control?
However, risk mapping should remain manageable.
If every control is connected to dozens of risks through an overly complex spreadsheet that nobody maintains, the theoretical traceability may provide little practical value.
Should the SoA Include Control Owners?
ISO 27001 does not require every organization to use the same SoA columns, but adding ownership can be useful.
A control without clear ownership is difficult to operate reliably.
Including the owner can make the SoA more operational by showing who is responsible for ensuring the control is managed.
For example:
| Control Area | Owner |
|---|---|
| Security awareness | Human Resources / Information Security |
| Vulnerability management | Information Technology |
| Supplier security | Procurement / Information Security |
| Physical access | Facilities |
| Secure development | Engineering |
| Risk management | Information Security / GRC |
The exact allocation will depend on the organization.
Central ISMS coordination does not mean every control needs to be owned by the GRC team.
Should the SoA Include Evidence?
Evidence references can be useful, but there is a tradeoff.
Adding an evidence column may help an organization quickly understand how a control’s operation can be demonstrated.
For example:
| Control | Example Evidence |
|---|---|
| Access review | Completed quarterly access review |
| Awareness | Training completion report |
| Supplier assessment | Completed supplier security assessment |
| Backup | Backup monitoring and restoration test records |
| Incident management | Incident records and investigation documentation |
But avoid turning the SoA into a giant evidence repository.
The Statement of Applicability should remain usable.
Evidence can be maintained elsewhere and referenced where appropriate.
Statement of Applicability vs. Risk Treatment Plan
The SoA and risk treatment plan are related, but they serve different purposes.
The risk treatment plan focuses on what the organization intends to do about identified risks.
It may include:
- treatment actions;
- responsible owners;
- deadlines;
- implementation activities;
- progress;
- residual risk.
The Statement of Applicability focuses on the organization’s necessary controls and its decisions regarding the Annex A reference controls.
A simple distinction is:
Risk Treatment Plan: What are we doing about our risks?
Statement of Applicability: Which controls are necessary, why, and what is their implementation status?
The documents should align.
If the treatment plan says a particular control is necessary while the SoA says the control is not applicable, something needs to be reconciled.
Statement of Applicability vs. Control Register
Organizations may also maintain a broader control register or control library.
This can contain more operational information than the SoA, such as:
- detailed control descriptions;
- owners;
- frequency;
- systems;
- procedures;
- evidence requirements;
- testing results;
- exceptions;
- framework mappings.
The SoA does not necessarily need to replace that system.
For some organizations, the SoA is one view of a larger control framework.
The important thing is consistency.
If the SoA says a control is implemented while the control register says implementation is incomplete, the organization should resolve the discrepancy.
How Auditors Use the Statement of Applicability
The SoA can become an important reference during an ISO 27001 audit because it provides a view of the organization’s control decisions.
An auditor may use it to understand:
- which controls the organization determined are necessary;
- why controls were included;
- which Annex A controls were excluded;
- why exclusions were made;
- whether implementation status appears accurate;
- how controls connect to risk treatment;
- whether the organization’s control environment matches its documented decisions.
The auditor can then follow individual controls into actual operation.
For example:
SoA says control is implemented → auditor identifies owner → auditor reviews procedure → auditor samples evidence → auditor evaluates operation
This is why accuracy matters.
Marking every control “Implemented” may make the spreadsheet look complete, but it creates problems if the organization cannot demonstrate that those controls actually operate.
For more on what happens during certification, see ISO 27001 Audit: What to Expect and How to Prepare.
Keep the Statement of Applicability Current
The SoA should not be created once and forgotten.
Control applicability can change.
For example:
- the organization begins developing software internally;
- a new cloud service is introduced;
- operations expand into another location;
- a new regulatory requirement applies;
- significant suppliers change;
- new information security risks emerge;
- existing controls are redesigned;
- the ISMS scope changes.
Those changes may affect which controls are necessary.
The Statement of Applicability should continue to reflect the actual ISMS.
A useful review question is:
If we rebuilt the SoA today based on our current risks and requirements, would we reach the same conclusions?
If not, it may be time for an update.
Common Statement of Applicability Mistakes
- Starting with the 93 controls instead of risk treatment: Annex A should be used to verify the organization’s necessary controls, not replace the risk treatment process.
- Marking all 93 controls applicable by default: Implementing every control may feel safer, but it can create unnecessary work and undermine the risk-based nature of the ISMS.
- Using “Not Applicable” for controls that simply aren’t finished: If a control is necessary but incomplete, that is an implementation issue, not necessarily an applicability decision.
- Using generic justifications: Statements such as “required by ISO” do not explain why a control is necessary for the organization.
- Copying another organization’s SoA: Applicability depends on your scope, risks, requirements, technologies, and operating environment.
- Ignoring controls outside Annex A: Necessary controls can come from sources beyond the Annex A reference set.
- Allowing the SoA to disagree with the risk treatment plan: The documents should reflect the same underlying decisions.
- Marking controls implemented without verifying operation: Implementation status should reflect reality.
- Giving every control to the security team: Control ownership should reflect how processes actually operate across the organization.
- Creating the SoA once and never updating it: Changes to risks, requirements, scope, technology, and operations can affect control decisions.
Statement of Applicability Readiness Check
Before considering your SoA complete, select several controls and ask:
- Can we explain why this control is necessary?
- Can we identify the risk, requirement, or treatment decision behind it?
- Is its applicability decision still accurate?
- Is the implementation status accurate?
- Can the control owner explain how it operates?
- Can we demonstrate its operation where appropriate?
- If the control is excluded, can we explain why it is not necessary?
- Does the decision align with our risk assessment?
- Does it align with the risk treatment plan?
- Does it align with our actual control environment?
Then reverse the process.
Choose an important information security risk and ask:
- What treatment decision was made?
- Which controls are necessary because of that decision?
- Where are those controls represented in the SoA?
- Are they implemented?
- Who owns them?
- What evidence demonstrates their operation?
That two-way traceability is much more valuable than a spreadsheet with 93 completed rows.
Statement of Applicability Frequently Asked Questions
What does SoA stand for in ISO 27001?
SoA stands for Statement of Applicability.
Is a Statement of Applicability mandatory for ISO 27001?
Yes. The Statement of Applicability is required as part of the ISO 27001 information security risk treatment process.
Does the Statement of Applicability include all 93 controls?
The SoA addresses the Annex A reference controls as part of documenting the organization’s control decisions. This does not mean all 93 controls must be implemented.
Do all 93 Annex A controls have to be applicable?
No. Annex A controls can be excluded when the organization determines they are not necessary and can justify that decision.
Can a control be applicable but not implemented?
Yes. Applicability and implementation are different concepts. A necessary control may be applicable while its implementation is still planned or in progress.
What is a Statement of Applicability justification?
A justification explains why a control is necessary or why an Annex A reference control has been excluded. It should reflect the organization’s actual risks, requirements, scope, and treatment decisions.
Can controls outside Annex A appear in the Statement of Applicability?
Yes. The organization first determines its necessary controls, which can include controls beyond Annex A.
Who should create the Statement of Applicability?
The exact responsibilities vary by organization. The process commonly involves information security or GRC personnel working with risk owners, control owners, technical teams, business functions, and appropriate management.
How often should the Statement of Applicability be updated?
The SoA should remain aligned with the organization’s current risk treatment and control decisions. Changes to risks, requirements, scope, technology, controls, or operations may require it to be reviewed and updated.
Will an ISO 27001 auditor review the Statement of Applicability?
Yes. The SoA is an important part of demonstrating how the organization’s risk treatment and control decisions relate to ISO 27001 and Annex A.
The SoA Should Explain Your Control Environment
A good Statement of Applicability is not impressive because every row is filled in.
It is useful because the decisions make sense.
For any important control, the organization should be able to trace:
Risk or requirement → treatment decision → necessary control → applicability decision → implementation → operation
And for an excluded Annex A control, the organization should be able to explain:
- why the control was considered;
- why it is not necessary;
- how that conclusion fits the organization’s scope and environment;
- why the exclusion does not leave a necessary control unaddressed.
That is what makes the Statement of Applicability more than an ISO spreadsheet.
It becomes a concise explanation of the organization’s information security control environment.
If you’re building the risk process that feeds your SoA, start with ISO 27001 Risk Assessment: A Practical Guide.
For the broader control selection process, see ISO 27001 Controls: A Practical Guide to Annex A.
And to track your overall certification readiness, use ISO 27001 Checklist: What You Need Before Certification.
