How to Write a Statement of Applicability (SoA)

Learn how to create a clear, compliant ISO 27001 Statement of Applicability with steps, structure, examples, and best practices for effective ISMS implementation.

How to Write a Statement of Applicability (SoA)

The ISO 27001 Statement of Applicability (SoA) is one of the most important parts of any Information Security Management System (ISMS). It is the official record of which Annex A controls your organization has chosen, why you chose them, why you didn’t choose some, and how far along each control is in its implementation. It is almost impossible to get certified without a full and correct SoA.

This guide tells you everything you need to know about the SoA, including what it is, why it matters, how to write it step by step, common mistakes to avoid, what auditors look for, and how to keep it up to date.

What Is the Statement of Applicability (SoA)?

ISO 27001:2022 requires a structured document called the Statement of Applicability. It lists all of the Annex A controls and says whether each one is:

• Included,
• not included, or
• only partially implemented,

and a written explanation for each choice.

It shows how mature the organization’s security is and how it deals with risks. It also connects the risk treatment plan and the Annex A controls in a very important way.

What the SoA is for in ISO 27001

The main goal is to give you a clear, traceable picture of all the controls that are important to your ISMS. It makes sure that auditors and internal stakeholders can see everything clearly and that control selection is based on risk, not chance.

How the SoA Fits Into the ISMS System

The SoA is not a document on its own. It works with:

• Results of the risk assessment
• Plan for treating risk
• Annex A list of controls
• Rules and regulations
• Documents for the audit

They all work together to make an ISMS work well.

Why the SoA Is Important for Following ISO 27001

For certification, it is legally required to have the ISO 27001 Statement of Applicability. An auditor can’t give a positive recommendation without a full SoA that matches Annex A.

Showing how to choose and justify controls

The SoA explains to auditors why certain controls were chosen based on the risks that were found. This makes sure that security is strong enough to stand up in court.

Connecting Risks to Controls in Annex A

Every control that is included must have a link that can be traced back to a decision about how to treat a risk. There must be a good and logical reason for leaving out a control.

Helping with audits and certification

Auditors look over the SoA to get a sense of its scope, check that controls match up with real security practices, and make sure that ISMS documents are consistent with each other.

Important Parts of a Effective SoA

The following are the most important parts of a good ISO 27001 Statement of Applicability:

1. Control Identifier (Reference to Annex A)

The official ISO/IEC 27001:2022 structure must be used to list controls.

2. Decision to Include or Exclude

It is important to clearly mark each control as:

• Included
• Not included
• Partially put into action

3. The Reason for Each Choice

This is usually the longest part of the document because every choice needs to be explained in writing in terms of risks, legal requirements, or business needs.

4. Status of Implementation

Usually, there are these options:

• Put into action
• In progress
• Planned
• Not relevant

5. Evidence that backs it up

You can refer to:

• Policies
• Steps
• Settings for technology
• Logs
• Documenting processes

How to Write a Statement of Applicability (Step-by-Step)

If you take a systematic approach, it’s easier to make an ISO 27001 Statement of Applicability that meets the standards.

Step 1: Review Your Risk Assessment

A full risk assessment must be the basis for your SoA.

Find and assess information security risks that have to do with privacy, integrity, and availability.

Please ask:

• What kinds of threats affect operations?
• What are the weaknesses?
• What kinds of controls do you need to deal with each risk?

Step 2: Map Risks to Annex A Controls

There should be one or more Annex A controls for each risk that has been found.

As an example:

This makes it possible to trace things.

Step 3: Choose whether to include or exclude

For each Annex A control, find out:

• Is it necessary to deal with a risk?
• Is it against the law?
• Does it help the business reach its goals?

If the following conditions are met, controls may be left out:

• They don’t matter to the organization’s environment,
• They don’t deal with any risks.
• Third-party services offer similar controls.

Step 4: Give clear reasons

The justification needs to be short, clear, and able to be checked.

Example of a weak reason:

“This control doesn’t apply.”

A good example of a strong justification is:

“This control is not allowed because there are no software development activities going on inside the company; all development is done by outside contractors with security requirements.”

Step 5: Status of Document Implementation

The status of implementation should be based on what is actually happening, not what you want to happen. Auditors will check your statements..

Step 6: Keep the SoA up to date and in good shape

Whenever you need to, update the ISO 27001 Statement of Applicability.

• Find new risks
• Change in systems or processes
• Changes to the scope of certification
• Adding or taking away controls

It’s important to have version control.

Common Mistakes When Preparing the SoA

Knowing what mistakes people often make can help you make sure your SoA is ready for an audit.

1. Unclear Reasons

Every justification must be clear and based on facts.

2. Too Many Controls

Adding controls that aren’t needed makes work harder and audits harder.

3. Not Including Controls without Proof

Exclusions should not be based on convenience, but on real risks.

4. Information About The Control Status That is No Longer Accurate

Auditors will look at real implementation details, so it’s important that they are correct.

Best Practices for Maintaining the SoA

1. Keep up with ongoing risk assessments

The SoA needs to be updated whenever risks change.

2. Make it easy for the auditor to understand

Use the same words and structure every time. Unless you have to, don’t use technical language.

3. Keep a strict version control system

Every change should have a time stamp, the name of the editor, and a note about the change.

What Auditors Look for in the SoA

Auditors check the following during certification audits:

• Following the risk treatment plan
• Justifications that make sense and can be traced
• Proof that it can be done
• Correctness and completeness
• Being in line with how the organization works

The ISO 27001 Statement of Applicability is usually the first thing that auditors ask for.

Sample SoA Template (ISO 27001:2022)

This layout makes it easy to keep track of things and get ready for an audit.

Updating the SoA After ISMS Changes

An SoA review is needed for every big change in the organization, like

• Adding new cloud services
• Building more infrastructure
• Adding departments to the list of things that need to be certified
• Using new technologies
• Changing rules about security

The main idea behind ISO 27001 is to keep getting better.

Final Thought

The ISO 27001 Statement of Applicability is an important ISMS document that shows how you chose, justified, and implemented your controls. When done right, it makes you more ready for certification, makes audits easier, improves risk treatment, and makes your organization’s security posture stronger.

Following the structured approach in this guide will turn your SoA from just a requirement for compliance into a strategic asset for your ISMS.