ISO 27001 scope statement: you do not have to certify the whole company
The first draft says "all information systems and processes of the company". It was written in an afternoon because it seemed uncontroversial, and it has just committed you to certifying the finance team's spreadsheets, the office door locks, the marketing agency's access to your CMS, and a legacy application two people use that nobody has patched since 2021.
An iso 27001 scope statement is the highest-consequence paragraph in the whole project, and it is usually written before anyone understands what it costs.
What clause 4.3 asks for
The requirement is short. Determine the boundaries and applicability of the information security management system, and consider the interfaces and dependencies between what you do and what other organisations do.
Three things follow from that wording.
Boundaries can be narrower than the company. You may certify a product, a platform, a business unit, or a set of services. You do not have to certify everything, and nothing in the standard suggests you should.
Exclusions must be justifiable, not merely stated. "Excludes the marketing department" is fine if marketing genuinely does not touch the information the ISMS protects. It is not fine if they have access to the customer database.
Interfaces and dependencies must be identified. This is the part people skip. If a service in scope depends on a supplier, a shared identity provider, or a team outside the scope, those relationships have to be named, because they are where the risk crosses the boundary.
Why over-broad scope is self-inflicted
Every additional thing in scope multiplies through four documents.
It appears in the risk assessment, because in-scope assets need risks identified. It appears in the Statement of Applicability, because the controls you select have to cover it. It generates evidence obligations for every applicable control, monthly or quarterly, forever. And it becomes something an auditor can sample at Stage 2 and at every surveillance audit thereafter.
So a scope that includes the office building means physical security controls, which means visitor logs, which means an evidence stream you now maintain indefinitely. A scope that includes a legacy application means that application's vulnerabilities are in the register and the auditor will ask what you are doing about them.
None of that is wrong. It is just work you chose, frequently without realising you were choosing it, in a paragraph written before the gap analysis.
What a workable iso 27001 scope statement looks like
For a SaaS company, the pattern that holds up:
The ISMS covers the design, development, operation and support of the
[product name] platform, including the cloud infrastructure it runs on,
the corporate systems used by personnel with access to that platform,
and the supporting functions of engineering, technical support and
information security.
Delivered from remote and home working locations, with cloud
infrastructure hosted in [region].
Excluded: [named function], which has no access to platform data or to
systems processing it. Physical offices are excluded on the basis that
no company premises store or process information within scope; the
interfaces and dependencies below cover the cloud hosting provider and
identity provider on which in-scope services depend.
Note what that does. It scopes by service rather than by department, which matches how a SaaS company actually works. It brings in the corporate systems used by people with platform access, because excluding those would be indefensible when a laptop with production access is the obvious risk. And it handles physical security by explaining why it does not apply rather than by ignoring it.
A remote-first company genuinely may have no premises in scope. Saying so explicitly, with the reason, is a scope decision. Leaving physical security unmentioned is an omission an auditor will find.
Interfaces and dependencies, concretely
The ones that matter for a small SaaS company, and each needs naming:
The cloud provider. Infrastructure is theirs, configuration is yours, and the boundary between those two is worth stating because it determines which controls you own.
The identity provider, if it is not the same thing. Everything in scope depends on it, and a compromise there is a compromise of everything.
Sub-processors handling in-scope data. These are in your supplier register and their assurance is your evidence, which is the supplier review question.
Customer-managed responsibilities. If customers administer their own users in your platform, some controls are theirs. Say so.
Any function outside scope that nonetheless touches in-scope systems. If finance uses a system that reads platform data, either bring it in or explain the control at the boundary.
How scope shapes everything downstream
Get this right and the rest of the project gets smaller in a way that compounds.
The risk assessment only considers in-scope assets, so the register is shorter and the risks are ones you can actually own. The risk assessment becomes tractable rather than encyclopaedic.
The Statement of Applicability inherits the same boundary, so controls that would otherwise need a justification for exclusion become simply out of scope.
Evidence obligations shrink proportionally, which matters most because they are the recurring cost rather than the one-off.
And Stage 2 sampling is bounded by it. An auditor cannot ask for evidence about something outside the scope you declared, which is not a loophole, it is the purpose of declaring a scope.
Getting it agreed
Scope is a leadership decision, not a technical one, and clause 5 wants leadership involved. That is useful rather than bureaucratic: a scope somebody senior has signed off is a scope you can point at when a well-meaning colleague suggests adding something in month five.
Two things to put in front of them. What each candidate inclusion costs, in recurring evidence rather than in one-off effort, because that is the number that matters and nobody estimates it. And what the customer who triggered the project actually asked for, which is frequently narrower than the internal assumption.
Record the decision in the management meeting minutes with the scope statement attached. That single record satisfies part of clause 5, gives you the leadership commitment evidence an auditor asks for, and settles the question. The ISO 27001 standard itself is the authority on what 4.3 requires, and it is worth reading the clause rather than a summary of it, because it is four sentences long and every word does something.
Revisit the scope annually as part of management review, and formally amend it if the business has changed. A certificate whose scope no longer matches what the company does is a finding waiting for a surveillance audit.
The mistake worth avoiding
Do not scope narrowly to dodge work in a way your customers will notice.
A certificate whose scope excludes the product the customer buys is worse than no certificate, because it looks like an attempt to mislead. Procurement teams read scope statements, and a mismatch between the certificate and the service being purchased becomes a longer conversation than the one you were trying to avoid.
The test: would the customer who triggered this project be satisfied by this scope. If not, widen it. If yes, resist widening it further out of a general sense that more is safer, because more is only more.
The book covers scoping in more detail, including the wording that survived an audit, and the security and compliance work is the other option if you would rather the first draft came from somebody who has watched a few of these get questioned.