Drawing an ISO 27001 scope you can defend, and the clause people skip

Clause 4.3 asks you to determine the boundaries and applicability of the information security management system, and it names three things you must consider in doing so: the external and internal issues you identified under clause 4.1, the requirements of interested parties under clause 4.2, and the interfaces and dependencies between what your organisation does and what other organisations do on your behalf. The result has to be available as documented information.

Two of those are intuitive. The third is where scopes quietly go wrong, and it is worth taking slowly.

Almost every organisation depends on services it does not run. Your email, your code hosting, your cloud platform, your payroll provider, the contractor with production access. None of those sit inside your ISMS — you cannot certify someone else’s management system — but clause 4.3 requires you to consider the interface between what you do and what they do.

The practical effect is that your scope statement has an edge, and the edge has to be described rather than ignored. The cloud platform is not in scope; the dependency on it is acknowledged, and it is then managed through your supplier controls — due diligence, contractual terms, monitoring, and what happens when the relationship ends.

Getting this wrong produces one of two failures. Either the scope pretends the dependency does not exist, which an auditor finds the moment they ask where the data actually lives; or it tries to pull the supplier inside the boundary, which commits you to evidencing controls you do not operate and cannot produce records for.

Here is the thing that makes scope different from every other early decision: it is printed on the certificate, and your customer reads it.

So the real test is not whether the scope is internally coherent. It is whether the scope statement, read by a procurement reviewer who knows nothing about your internal structure, plainly covers the service they are buying. A scope naming a head office and "corporate IT" tells them nothing about the product hosted in a different region by a different team.

Work backwards from that. Draw the scope your customers need to see, then work out what it takes to satisfy it. Organisations that do it the other way round — draw the boundary that is easiest to certify, then hope — end up with a real certificate that does not answer the question anyone asks, and repeat the exercise a year later with the scope they should have drawn first.

A scope can legitimately exclude things. What it cannot do is exclude something the service obviously depends on and still be believed.

The classic is certifying a software product while carving the development team out of scope. It is expressible, it reduces the work considerably, and no competent auditor or customer accepts it — because the security of a software product is not separable from how the software is built. The same applies to excluding the team that administers production, or the office where the people with the access actually sit.

A useful sanity check before you commit: if a customer asked why that exclusion is there, would the honest answer be a reason about the business, or a reason about the audit? Reasons about the audit do not survive being said out loud.

Scope is the first decision because so much depends on it. The risk assessment covers what is in scope. The Statement of Applicability’s exclusions are mostly justified by scope — you exclude the physical entry controls because you have no premises inside the boundary, or the secure coding control because you write no software. Change the scope later and those justifications change with it.

This is also why widening a scope after certification is a real piece of work rather than an amendment: new locations, systems or services bring risks that were never assessed and controls that were never applicable. It is better to draw a scope slightly wider than today’s pipeline demands than to redo the exercise when the second customer asks.

Narrower is cheaper now and more expensive later. Somewhere just beyond what your customers currently ask for is usually the right place to stand.