ISO 27001 scope and Statement of Applicability: how to write them

In ISO 27001, the scope is the written boundary of what your management system covers, and the Statement of Applicability (SoA) is a table of all 93 Annex A controls saying which apply and why. The scope decides how much work you sign up for, and it appears on your certificate. The SoA decides what the auditor holds you to.

This guide covers the scope, the three common scoping mistakes, the SoA, justification wording, the 2022 controls that catch people out, and keeping both current.

	Scope statement	Statement of Applicability
What it is	The written boundary of the management system	A table of all 93 Annex A controls
What it records	Organisation, services, systems, locations and people covered	Applies or not, why, implemented or not, where the evidence lives
Who reads it	Your customer’s procurement team, on the certificate	The auditor, as the basis of the audit
Usual mistake	A boundary too narrow, too broad, or indefensible	An exclusion that fails one follow-up question

Almost every ISO 27001 project that goes badly went wrong in the first fortnight, in these two documents. Get them wrong and you either do twice the work you needed, or finish with a certificate that does not answer your customer’s question.

What is the ISO 27001 scope?

The scope is the written boundary of what your management system covers: which parts of the organisation, which services, which systems, which locations and which people.

It appears on the certificate. That is the detail everyone forgets. Your enterprise customer’s procurement team does not read your risk register. They read the scope line on the certificate and check whether it contains the service they are buying. A technically perfect certificate with the wrong scope is worth very little commercially.

What are the most common ISO 27001 scoping mistakes?

1. Scoping to make the audit easy

Narrow the boundary to one team, one product, one office, and the workload collapses. So does the value. We have seen certificates scoped to an internal IT function while the company sells a hosted product, which answers nobody’s question.

2. Scoping to the whole company because it feels honest

A 40 person company that puts every system, every office and every side project in scope has multiplied the evidence burden for no commercial gain. Broad scope is a decision to be paid for, not a moral position.

3. Drawing a boundary you cannot defend

Suppose your in-scope product runs on shared infrastructure, uses the same identity provider and is built by the same engineers as the out-of-scope one. An auditor will ask how the boundary is enforced. If it is not, the boundary is fiction and the finding is real.

The practical test: could you explain to an auditor exactly where the boundary runs, what crosses it, and how the crossings are controlled? If you hesitate, redraw it.

How do you define an ISO 27001 scope that saves work?

Scope by service, not by department.

Departments are political and porous. Services have interfaces, infrastructure and owners you can point at. Scoping to “the SaaS platform and the teams and systems that build, run and support it” gives you a boundary an auditor can walk. It is also exactly what your customer wants named on the certificate.

The decision that most often backfires is excluding a shared dependency: the identity provider, the CI pipeline, the ticketing system, the laptops. Anything shared between in-scope and out-of-scope work ends up in scope in practice, so include it deliberately and control it once.

The same reasoning decides whether an entity falls inside a regulatory perimeter. If you are also working through NIS2, the parallel is in our guide to NIS2 scope and applicability.

What is the Statement of Applicability?

The SoA is a single table listing every control in Annex A of the standard: all 93 of them in the 2022 edition. For each one you record four things:

1. Whether it applies to you.
2. Why, in a sentence. This justification is required for both applicable and not applicable.
3. Whether it is currently implemented.
4. Where the evidence lives.

That is it: 93 rows and four useful columns.

Its importance is out of proportion to its complexity, because the SoA is what you get audited against. Not the standard in the abstract, not what a similar company does. It is your workplan, your audit checklist and, if you write it carelessly, the rope you hand the auditor.

How do you justify excluding an Annex A control?

Marking a control not applicable is legitimate, and the standard expects it. A company with no physical server room does not need server room access controls. A company that writes no software does not need secure coding controls. The failure is exclusion with a justification that does not survive one follow-up question.

Justifications that fail:

• “Not applicable, we are a small company.” Size is not a reason. The standard already scales by risk.
• “Not applicable, we use a cloud provider.” Using a provider transfers operation, not accountability. You still have to show you selected and oversee them.
• “Not applicable, not relevant to our business.” That is a restatement, not a reason.

Justifications that hold:

• “Not applicable. The organisation operates no on-premise data centre. All production infrastructure is hosted by [provider], covered by supplier controls 5.19 to 5.22.”
• “Not applicable. The organisation develops no software. All applications are commercial off the shelf and covered under 8.30 outsourced development, which is marked applicable.”
• “Applicable, not yet implemented. Data leakage prevention is scheduled for Q1 with the endpoint rollout. Risk accepted in the interim by the CTO, recorded as R-014.”

The good ones name the reason, point at the compensating control or the risk decision, and give the auditor somewhere to go next.

Admitting a control is applicable and not yet implemented is not a failure. It is a legitimate state, as long as a plan and an accepted risk sit behind it. Companies get into trouble by marking aspirational controls as implemented, which turns a planning conversation into a nonconformity.

The supplier controls have the longest tail of work, so start them early. See supply chain risk assessment.

Which Annex A controls catch people out?

The 2022 edition added eleven controls that did not exist in the old muscle memory: threat intelligence, cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding.

These are the rows where SoAs go vague, because there is no legacy template answer to copy. If your SoA has thin justifications, they are almost certainly here.

Check the template too. The transition from the 2013 edition closed on 31 October 2025, so any template still using the old 114 control numbering is obsolete. Auditors now work exclusively from the 2022 set.

How often should you update the scope and SoA?

Scope and SoA are the two documents most likely to quietly become false.

You launch a product, move a workload, start using a new provider, or acquire a team. Each changes the boundary or which controls apply. If neither document moves, your management system describes a company that no longer exists.

The 2022 edition addresses this through the clause requiring you to plan changes to the management system rather than let it drift. The workable habit:

1. Review scope and SoA at every management review.
2. Ask of every significant technical or organisational change: does this move the boundary, or change an applicability decision?

Tooling earns its place here, not by writing the documents but by keeping controls, risks, owners and evidence connected, so a change in one shows up in the others. That is what the risk and compliance module in our platform is for. It is the difference between a system that stays true and one that is accurate for a quarter.

For the wider picture at a company with no security function, read ISO 27001 for a company without a security team. On budget, see is €50k for ISO 27001 worth it. The full route is on our ISO 27001 solutions page.

Does a tight scope make the company more secure?

No. A tight scope protects the certificate, not the company.

Scope defines the boundary of what gets audited, not of what gets attacked. An attacker does not read your scope statement. Your out-of-scope marketing site may share an identity provider with your in-scope platform. Your excluded internal tooling may hold production credentials. Then the certified boundary and the real attack surface are different shapes, and no document you have produced shows it.

The same applies to the SoA. A control marked not applicable with a flawless justification is still a control you are not running. That can be a defensible audit position and a poor security position at once, and the SoA is not designed to tell you when they diverge.

So keep two lists. The SoA, which is what you owe the auditor. And a shorter, blunter list of what you excluded or deferred that would hurt if exploited: the shared identity path, the deferred detection work, the accepted patch window, the untested restore. Nobody asks for that second list. It is the one worth reading at the management review.

Scope your certificate to answer your customer’s question. Then look at what fell outside it, and be honest about which of those things an attacker would reach first.

Scope and SoA checklist

• Scope by service, not by department, and name the service your customers buy.
• Check you can explain where the boundary runs, what crosses it and how the crossings are controlled.
• Bring shared dependencies into scope deliberately: identity provider, CI pipeline, ticketing, laptops.
• Build the SoA on the 2022 edition’s 93 controls, not the old 114 numbering.
• Give every control a one-sentence justification that survives one follow-up question.
• Mark a control implemented only when it is running; record the plan and accepted risk for the rest.
• Review scope and SoA at every management review and every significant change.
• Keep a separate list of exclusions and deferrals an attacker would reach first.

Frequently asked questions