ISO 27001 Statement of Applicability

The Statement of Applicability (SoA) is the document in an ISO/IEC 27001 information security management system (ISMS) that records which security controls the organisation has decided apply to it, whether each one is implemented, and why. It is usually the document an auditor reads first, because it shows how the organisation’s risk decisions turned into a list of controls.

ISO/IEC 27001 is the international standard for information security management systems, published by ISO and the International Electrotechnical Commission (IEC). The standard itself is sold, not published free of charge, so this guide describes the SoA in general terms and does not reproduce its text. If you are building an SoA for a client, work from a licensed copy of the current edition, which is commonly cited as ISO/IEC 27001:2022. ISO’s own page for the standard is the place to confirm the current edition and any amendments.

What the SoA does

The SoA sits at the end of the risk work. In general terms, an ISMS asks the organisation to:

1. Define the scope of the system.
2. Assess its information security risks.
3. Decide how to treat each risk.
4. Determine the controls needed to carry out that treatment.
5. Record the result, including which controls were chosen and which were left out, with reasons.

That last step is the SoA. Practitioners commonly describe the SoA as having four things for every control: whether it applies, the reason it was included or excluded, whether it is implemented, and where the evidence lives. The standard’s controls reference list is known as Annex A. The SoA is where an organisation shows that it has considered that list, and also any controls it has taken from elsewhere, against its own risks.

An exclusion is not a weakness. An organisation that does not develop software does not need to claim a control on secure coding, and a clear written reason is better than a vague “not applicable”.

Why it matters

The SoA connects two things that are otherwise easy to separate: the risk assessment and the controls in operation. If the register says that a supplier outage is a high risk, the SoA should show which controls reduce it. If an auditor picks a control from the SoA, the client should be able to point to the policy, the owner and the evidence.

Risk assessment is not unique to ISO. NIST’s guide to conducting risk assessments, Special Publication 800-30, was published in September 2012 and gives guidance for running risk assessments at all levels of an organisation. The UK National Cyber Security Centre says that improving business outcomes should be the primary driver for cyber security risk management, and favours meaningful assessment over box-ticking. Both ideas apply to the SoA: it should be a record of real decisions, not a checklist that was ticked to look complete.

How an MSP or vCISO delivers it

For a practice that supports several ISO clients, a reliable approach looks like this.

• Start from the risk register, not the control list. Work with the client on the risk register first. Controls chosen without a risk behind them are hard to justify later.
• Set the scope in plain words. Name the business units, sites, systems and services covered. The SoA only makes sense against a clear scope.
• Use one row per control. Include the control reference, applicable yes or no, the reason, the implementation status, the owner and the evidence link.
• Link each row to a policy or procedure. The policies, standards and procedures guide explains how those documents fit together.
• Review it on a schedule. Re-open the SoA when the scope changes, when a new risk is accepted, or after an incident. Review it at least before each surveillance audit.
• Keep the version history. Auditors often ask what changed since last time and why.

For wider delivery planning, read our ISO 27001 service line guide and the comparison with SOC 2.

Common mistakes

• Copying a template unchanged. A downloaded SoA with every control marked “applicable” and no reasons shows that no one decided anything.
• Excluding controls without a reason. “Not applicable” on its own invites a question.
• Marking controls as implemented without evidence. The status should be one the client can demonstrate on the day.
• Letting the SoA drift away from the risk register. If a risk is accepted or a new one is added, the SoA may need to change.
• Treating the SoA as the whole ISMS. It is one document in a system that also includes scope, policy, risk method, internal audit and management review.
• Quoting the standard in client documents. The standard is copyright material. Describe the requirement in your own words and cite the clause.

Where GetCybr fits

If you maintain SoAs for several clients, GetCybr is a platform for holding the control list, owners, evidence and policy links for each client in one place, so that the SoA stays connected to the rest of the programme. It does not replace the client’s decisions or the certification body’s audit. You can see how ISO 27001 is handled on the ISO 27001 compliance platform page.

Sources

• ISO, ISO/IEC 27001 information security management systems. The standard’s catalogue page, linked so you can confirm the current edition and amendments. This guide does not quote the standard, and the description of the SoA above is a general one to check against your licensed copy.
• NIST Computer Security Resource Center, SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, September 2012. Source for the risk assessment guidance.
• UK National Cyber Security Centre, Risk management guidance. Source for the statements on business outcomes and meaningful risk management.