The scope is the shortest passage in the whole ISMS and the most expensive one. One sentence, usually two lines long. It decides the effort, and it decides whether the certificate ends up answering the question you are doing all this for.
Most companies treat it as a formality at the start of the project. You write down something that sounds plausible, tick off clause 4.3 and move on to the interesting part, the controls. Nine months later somebody is explaining to an auditor why manufacturing is not included after all.
The ISO 27001 scope reads like a technical boundary. It works like a promise. It sits on the certificate, and your customer reads it.
What is the scope in ISO 27001?
The scope describes the boundaries and applicability of the ISMS: which sites, which organisational units, which services and which systems it covers. ISO/IEC 27001 requires it in clause 4.3 as documented information, and it explicitly requires you to account for the interfaces and dependencies with activities that other organisations perform for you.
That is the formal answer. The more useful one: the scope is the decision about which part of your operation you place under a managed system, and for which part you explicitly make no such claim.
Both are statements. The second one tends to get overlooked.
Why one sentence decides months
Everything inside the scope has to come along. Risks recorded, controls decided, evidence produced, people trained, nonconformities handled. And on an ongoing basis, because an auditor wants to see that the system runs rather than merely exists.
That makes the cut the single biggest lever on cost and schedule. We have described elsewhere why the timeline of an ISO 27001 certification cannot be bought and what the cost for an SME is made of. In both cases the same driver sits in the background: how wide you drew the boundary.
Put two variants of the same company side by side. In the first, the ISMS covers the entire group, two foreign sites and manufacturing included. In the second, it covers the development and operation of the platform at one site, because that is exactly what customers ask about. Same standard, same certification body. Two projects that differ by a multiple, and what set that difference was a meeting at the very beginning.
That meeting feels unimportant. It has no technology and no budget, it has only one question that hardly anyone likes to answer in a binding way.
The two ways to cut it wrong
Too large
The more common mistake, and it comes from an honourable impulse. If we are doing this at all, let us do it properly, so all of it.
What follows is predictable. Every additional unit brings its own systems, its own responsibilities and people who did not order the extra work. The foreign site has different employment contracts. Manufacturing has machines nobody may patch without asking the vendor. Sales has a CRM that somebody else has been running for years. Every one of these is solvable, and every one costs weeks.
The result is rarely a failed project. It is a project that does not end. After twelve months the budget is spent and the certificate is still not there. In our experience that is the most common reason ISMS efforts stall in an SME, not a lack of technology.
Too small
The rarer mistake, and the more expensive one. You cut the scope so tightly that it is comfortable to operate but no longer answers the question the customer asked.
The classic case: a supplier certifies its internal IT department. Done cleanly, certificate hanging in reception. Then the major customer comes along and wants to know whether the machine he ordered and its remote maintenance fall under the ISMS. They do not. The certificate is valid, correct and worthless for this purpose.
What follows is the extension, and it costs more than the wider cut would have cost at the start. The audit is the smaller item here. The expensive part is carrying the build through the organisation a second time, this time against the expectation that you were surely finished already.
Who sets the cut, if not you
There is no optimum between those two mistakes that you could calculate. There is only one source for the right boundary: the requirement you are doing this for.
For most SMEs that is a customer or a tender. Then the boundary is what the customer relies on, plus everything that carries that service. No more and no less.
Anyone falling under the Swiss Information Security Act has less room. There the cut follows from the service the obligation applies to. What would be convenient internally plays no part. Whether your company is affected at all is something we worked through in our assessment of the ISG ISMS obligation, and the answer is no more often than the market tells you.
You can always extend later. A scope is allowed to grow, that is intended and for most companies it is the realistic path. It should just be a planned second stage rather than a repair that became necessary because nobody asked the first time what the certificate was actually needed for.
Scope and Statement of Applicability are not the same thing
In conversation most people confuse these two documents, and the confusion produces false expectations about the effort involved.
The scope from clause 4.3 answers the question: which part of the company do we mean? The Statement of Applicability from clause 6.1.3 answers a different question: which controls are you applying inside that part? It lists the necessary controls, records whether they are implemented, and justifies why individual controls from Annex A are not applicable in your case.
The difference matters in practice because it fixes the order of work. The Statement of Applicability cannot be written sensibly while the boundary is still moving. Anyone still debating whether manufacturing belongs in the scope cannot seriously judge which controls are necessary. That is exactly why projects that work on both documents in parallel tip over.
And one distinction that regularly causes discussion in the audit: justifying a control from Annex A as not applicable is permitted and normal. Quietly making an entire part of the company disappear from the scope because it is inconvenient is something else. The first is a documented decision. The second gets noticed at the latest by the customer reading the certificate.
The hard part is the interfaces
Clause 4.3 explicitly requires you to account for the interfaces and dependencies with what other organisations do for you. That is the point where most drafts fall apart.
You can draw a small boundary. You cannot draw away a dependency. If your core system runs at a provider, somebody else operates your data centre and a service provider manages the clients, then those services sit outside your boundary and still carry your scope. So you have to describe how you steer them: what is contractually agreed and who is allowed to do what at the provider.
This is the unglamorous work behind the topic. No certification software solves it. It consists of the question of who in your company actually knows which providers hang off which data. Anyone without that overview is guessing the scope. That is why in many engagements the asset inventory comes first and the boundary second.
And yes, at this point a project slows down for a while. In return, the renegotiating stops later on.
What goes on the certificate is not your text
Certification bodies work to ISO/IEC 17021-1, and many people meet that rule for the first time in the audit. Its clause 8.2 requires certification documents to identify the scope of certification with respect to the type of activities, products and services at each site, without being misleading or ambiguous.
In plain terms: an elegant formulation that leaves a lot open will not survive the process. The certification body will keep asking until the line is unambiguous. That is precisely what the certificate is worth to your customer. A document whose scope can be read any way you like tells him nothing.
In practice that means you are better off writing the line early in the form it should finally take. How the process around it runs is something we described in our article on the ISO 27001 certification process.
The test that takes an hour
Take the line that would appear on the certificate. One sentence, not a presentation.
Then put it in front of two people. First the person in the company who owns the part described: can you run this, on an ongoing basis, with the people you have? And then the person who takes your largest customer through the procurement process: does this sentence answer what gets asked there?
Two clear yeses mean the cut is right. Hesitation on the first means you cut too large. Hesitation on the second means you are building something that will have to be extended later.
This test does not replace a risk assessment. It only prevents the mistake that costs the most, and it costs you an hour.
If that is where you are and the answer is not clear, this is exactly the moment for a conversation. We do this as support for building an ISMS to ISO 27001, often starting with this one meeting. A first conversation is without obligation.
Where the boundary belongs
In the end the scope states which part of your company you take written responsibility for, on an ongoing and verifiable basis, in front of an auditor and in front of a customer. Everything else in the project follows from it. That is why this decision belongs at the start and at the table where customers are discussed. It does not belong in the document somebody finishes off quickly on a Friday afternoon.
If your largest customer asks about your certificate tomorrow and somebody reads the line on it out loud, does it answer his question?
Frequently asked questions
Does the scope have to cover the whole company?
No. You may certify one site, one business unit or a single service, and for many SMEs that is the sensible sequence. The boundary has to be justified and described. It should just cover what the customer asking for the certificate actually relies on.
What belongs in the scope of an ISMS?
ISO/IEC 27001 requires in clause 4.3 the boundaries and applicability of the ISMS: sites, organisational units, services and systems. That explicitly includes the interfaces and dependencies with what other organisations deliver for you, such as cloud providers, the data centre or the provider managing your clients.
What is the difference between the scope and the Statement of Applicability?
The scope from clause 4.3 says which part of the company is meant. The Statement of Applicability from clause 6.1.3 says which controls apply inside that part, whether they are implemented, and why individual Annex A controls are not applicable. The scope comes first.
