The scope question gets asked too late in most ISMS projects, and answered too broadly. The project is approved, the auditor has a date, and at some point the group sits in front of the line that holds the scope statement. Someone says: let us take the whole company, then we have no gaps. Everyone nods, because it sounds like diligence.
That one sentence turns the work into a much bigger project, without a single customer, auditor or attacker noticing. The ISMS scope is not a formality in the header of a document. It settles which parts of the company now work to rules that did not apply to them before. That is a budget and headcount decision, and it does not belong in IT.
The ISMS scope decides what your ISMS costs and how credible it looks from the outside. The more common mistake in an SME is not a scope that is too small, it is one that is too large: it pulls in sites, subsidiaries and departments no customer wants to hear about, and it produces rules nobody follows. The boundary holds when it follows the service your customers buy, plus the IT that carries that service. The executive team has to sign it off.
The scope decides the effort, not the security
The scope governs things you can count: how many processes you describe, how many people you train, how many systems land in the asset and risk register, how many interviews the auditor runs, how many pieces of evidence you collect again every year. That is the bill.
On top of that, the bill arrives every year. A certificate is not the end of a project, it is a subscription: surveillance audits come at fixed intervals, and each one asks for the same evidence, only a year fresher. Draw the scope generously in June and you pay for that generosity in every audit and with every staff change in the departments concerned. That is why we put this decision before the fixed price rather than after it.
What the scope does not govern is the level of protection. Security measures and the boundary of a certificate are two different things. You can switch on multi-factor sign-in across the whole company and still certify only one part. You can test backups for every site even when only one of them sits inside the scope. In most SMEs the measures that work run through the same two or three platforms anyway, and those platforms know nothing about an org chart.
A broad scope does not make an SME safer. It makes the ISMS more expensive and slower. It is the same logic as with tools: more protection comes from right-sizing, not from volume. Your business only carries the rules it actually follows day to day. Everything above that is documentation.
How do you spot an ISMS scope that is too broad?
By the fact that you are writing policies for departments nobody had spoken to before the project. Or that the risk register lists applications nobody in the room can explain. A scope is too broad when you have to name owners who know nothing about their role.
The signs show up early, long before the auditor arrives:
- IT is listed as the owner of business processes, because nobody else volunteered.
- The inventory holds systems that exist there and nowhere else.
- A subsidiary is asked to sit awareness training although its business has nothing to do with what triggered the project.
- Collecting the evidence takes longer than the measure it is meant to prove.
- Nobody can say in two sentences what is in and what is out.
A scope that your executive team cannot explain without an org chart will not hold up in a customer conversation either.
Who decides the ISMS scope?
The executive team. The scope hands work to departments that do not report to IT, and it defines what the company stands behind in public. An IT lead cannot settle either of those, they can calculate, prepare and recommend. Signing it off takes someone with budget and authority to direct.
In practice this fails on the proposal, not on the will. Put a finished scope document in front of the executive team for information and you get an acknowledgement. It becomes decidable once each option comes with what customer requirement it answers, who inside the company it affects and what it costs in time. That preparation is the difference between a decision that holds and one that gets reopened in month three.
It is also why a fixed price for an ISMS programme can only be quoted after scoping. In our fixed-price packages the ISMS implementation is priced on request for that reason: before the scope decision, any number is a guess. What else drives effort, duration and cost in an SME is written up in ISO 27001 in an SME.
How customers and regulators set the scope
The answer usually sits in the requirement that triggered the project. Somebody outside wants to see something, and that wish almost always has a boundary: a contract for a particular delivery, a questionnaire about a particular service, an obligation for a particular part of the business.
In regulated industries the boundary is partly set by law. The ICT minimum standard issued by the BACS, the Swiss federal office for cybersecurity, has been mandatory for the electricity sector since 1 July 2024 and for gas suppliers since 1 July 2025, and is a recommendation for the remaining sectors. Operators of critical infrastructure also have to report cyberattacks to the BACS within 24 hours, in force since 1 April 2025. Supply those companies and you get the same duties passed down through the contract, for the part of the supply chain they touch.
The order of work is unspectacular and still gets reversed often. A scope settled before the requirement is read rarely answers the question somebody actually asked. And when nobody outside is asking, the company does not need a certificate, it needs an ISMS that is lived day to day. That is cheaper and it works sooner.
An example from practice
A mechanical engineering supplier with 340 employees, two plants and a sales company abroad. The trigger was a large customer from the energy sector who required an ISO 27001 certificate in the framework agreement, with a deadline. The first draft of the scope covered the group: both plants, sales, engineering, finance, HR, all of IT.
Reading the requirement showed something else. The customer bought components from one plant and pulled design data through a portal. It wanted to know how that data is protected and who has access to it. The second plant produced for other markets, the sales company sold spare parts, HR did not appear in the delivery at all.
The scope ended up covering the supplying plant, engineering and the shared IT, including identities, Microsoft 365 and the portal. The parts left outside were not left unprotected: multi-factor sign-in, patch levels and backup carried on for everyone, because they are configured through the same platforms. What fell away was the evidence duty, the ISMS training obligation and the audit interviews for three areas.
What remained was the uncomfortable part, and it remains in every SME: the shared IT. It carries the service that was bought, so it sits inside the scope, and the auditor treats it that way. Hoping to keep IT out of the certificate through a clever boundary only postpones the conversation by a year.
When is a broad scope worth it?
When the boundary creates more work than inclusion. In a company with one site, one IT function and one business model, that is usually the case. Maintaining two sets of rules for forty people costs more than treating all forty the same, and in the end nobody knows which rule applies to them.
The same holds when the demand comes from several business lines. A certificate that sales has to explain in every second conversation is worth little there. And an exclusion that exists only on paper, because the same people work on both sides of the boundary, will surface in the audit. Broad is then the more honest and ultimately the cheaper option.
So the decision comes down to a different question: where does a boundary exist in the business at all? Where none exists, an invented one will not help. Where one does exist, ignoring it costs money.
How to recognise a scope that holds
From our engagements there are four marks, and none of them is written in the standard:
- It can be explained in two sentences, without an org chart and without caveats in brackets.
- Every boundary follows an accountability, not a cost centre. Where responsibility ends, the scope ends.
- The interfaces to the outside are named, including the providers who run something inside the scope.
- The people inside the scope know they are in it. That is the hardest test, and it can be run during a coffee break.
Anyone facing this decision usually already has a deadline and a customer behind them. The most useful hour is then not the one in which somebody drafts a scope document, but the one in which somebody reads the requirement with you and says what it asks for and what it does not.
Frequently asked questions
Does the scope appear on the certificate?
Yes. It is part of the certificate and therefore the first thing a professional buyer looks at. A certificate whose scope does not cover the service being bought raises more questions in procurement than no certificate at all. Which makes the wording of those two lines a sales matter rather than a documentation matter.
Can we extend the scope later?
Yes, and that is the more common route. The certification body treats an extension as a change to the certificate and assesses it in an audit. That costs preparation, but far less than building everything at once from the start. The expensive case is the opposite one: a first scope drawn so tightly that it misses the main service and has to be patched afterwards.
Does our scope cover the IT provider as well?
Your provider does not get certified through your scope. Whatever sits inside the scope stays your responsibility, even when an external party runs it. In the audit that means you supply the contracts, access rights and evidence for externally operated systems, not them. A certificate held by your provider helps, but it does not replace your own evidence.