Who should read this: anyone about to start ISO 27001 at a company without a dedicated security team, and anyone whose project has stalled because the first two documents were never properly settled.
Almost every ISO 27001 project that goes badly went wrong in the first fortnight, in two documents that look like admin. The scope statement decides how much work you have signed up for. The Statement of Applicability decides what an auditor will hold you to. Get them right and the rest of the project is grind. Get them wrong and you will either do twice the work you needed, or finish and discover the certificate does not answer the question your customer asked.
Neither document is complicated. They are just badly explained.
Scope: what it is, in one sentence
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. When your enterprise customer asks for proof, their 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.
The three ways smaller companies get scope wrong
Scoping to make the audit easy. The temptation is obvious. Narrow the boundary to one team, one product, one office, and the workload collapses. It also collapses the value. We have seen certificates scoped to an internal IT function while the company sells a hosted product, which answers nobody’s question.
Scoping to the whole company because it feels honest. The opposite failure. 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.
Drawing a boundary you cannot actually defend. Scope must be defensible at the edges. If 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 the answer is that it is not, the boundary is fiction and the finding is real.
The practical test: read your draft scope statement, then ask whether you could explain to an auditor exactly where the boundary runs, what crosses it, and how the crossings are controlled. If you hesitate, redraw it.
The scoping decision that saves the most 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, and it happens to be exactly what your customer wants named on the certificate.
The scoping 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 will end up in scope in practice, so you may as well include it deliberately and control it once.
This is the same reasoning that decides whether an entity falls inside a regulatory perimeter, and if you are also working through NIS2 the parallel is worth reading in our guide to NIS2 scope and applicability.
The Statement of Applicability: what it actually is
The Statement of Applicability, universally shortened to 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:
- Whether it applies to you.
- Why, in a sentence. This is the justification, and it is required for both applicable and not applicable.
- Whether it is currently implemented.
- Where the evidence lives.
That is it. It is a table with 93 rows and four useful columns.
Its importance is out of proportion to its complexity, for one reason: the SoA is what you get audited against. Not the standard in the abstract, not what a similar company does. The document in which you told the auditor what you were going to do. It is simultaneously your workplan, your audit checklist and, if you write it carelessly, the rope you hand the auditor.
Where audits are won and lost: the word “applicable”
Marking a control not applicable is completely legitimate. The standard expects it. A company with no physical server room does not need controls about server room access. A company that writes no software does not need secure coding controls.
The failure is not exclusion. 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.”
Notice the shape of the good ones. They name the reason, point at the compensating control or the risk decision, and give the auditor somewhere to go next. That last example is worth copying: admitting a control is applicable and not yet implemented is not a failure. It is a legitimate state, as long as there is a plan and an accepted risk behind it. Companies get into trouble by marking things implemented when they are aspirational, which turns a planning conversation into a nonconformity.
The eleven controls that 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 in that list. Also worth checking: the transition from the 2013 edition closed on 31 October 2025, so any SoA template still using the old 114 control numbering is obsolete. Auditors now work exclusively from the 2022 set.
Keeping both documents alive
Scope and SoA are not one-off deliverables. They are the two documents most likely to quietly become false.
You launch a new product. You move a workload. You start using a new provider. You acquire a team. Each of those changes the boundary or changes which controls apply, and if neither document moves, your management system is now describing a company that no longer exists.
The 2022 edition addresses this directly through the clause requiring you to plan changes to the management system rather than let it drift. In practice, the workable habit is to review scope and SoA at every management review, and to add a single question to any significant technical or organisational change: does this move the boundary, or change an applicability decision?
This is also where tooling earns its place, not by writing the documents for you but by keeping the controls, the risks, the owners and the evidence connected so that a change in one shows up in the others. That is what the risk and compliance module in our platform is for, and it is the difference between a system that stays true and one that is accurate for a quarter.
For the wider picture of what a first certification involves at a company with no security function, start with ISO 27001 for a company without a security team, and on the budget question specifically, is €50k for ISO 27001 worth it. Suppliers deserve their own attention early, since the supplier controls in the SoA are the ones with the longest tail of work, covered in supply chain risk assessment. The full route is laid out on our ISO 27001 solutions page.
The technical reality: a tight scope protects the certificate, not the company
Here is what the standard leaves open, and it follows directly from everything above.
Scope defines the boundary of what gets audited. It does not define the boundary of what gets attacked. An attacker does not read your scope statement. If your out-of-scope marketing site shares an identity provider with your in-scope platform, or your excluded internal tooling holds production credentials, then the certified boundary and the real attack surface are different shapes, and the difference is invisible in every document you have produced.
The same applies to the SoA. A control marked not applicable with a flawless justification is still a control you are not running. That is a defensible audit position and it may be a poor security position. Both statements can be true at once, and the SoA is not designed to tell you when they diverge.
So the useful discipline is to keep two lists. The SoA, which is what you owe the auditor. And a shorter, blunter list of the things you excluded or deferred that would actually hurt you 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.
