Fast Cyber Essentials › Scoping
Cyber Essentials can cover your whole organisation or a clearly defined part of it. Both are permitted. The temptation, when the estate contains something awkward, is to draw the boundary around the awkward thing and certify what is left.
Sometimes that is correct. Often it produces a certificate that a buyer reads, understands, and discounts.
What "whole organisation" actually means
Everything: every device that touches organisational data, every cloud service, every user, every location. It is the strongest scope and it is what most buyers assume they are getting when they see a certificate, because the certificate does not lead with the scope statement.
If you can certify whole-organisation, do. It removes an entire category of awkward conversation later.
When a subset scope is legitimate
A subset has to be a genuinely separable part of the business, not simply the easy part. Separable means it can be described without reference to what has been left out, and that an attacker who compromised the excluded part could not trivially reach the included part.
Legitimate examples: a distinct trading subsidiary with its own systems and its own IT; a business unit on a separate network with no trust relationship to the rest; a wholly separate environment built to deliver one contract.
Not legitimate: "everything except the warehouse machines"; "head office only" when head office shares a domain with the sites you excluded; "the systems used for this contract" when those systems sit on the same network as everything else.
The three questions that settle it
- Does this device or service touch organisational data? If yes, it is in scope unless it is genuinely segregated.
- Can the excluded part reach the included part? If a compromise on one side reaches the other, the boundary is not real and the scope will not stand.
- Would you be comfortable showing the scope statement to the client who asked you to certify? If the answer is no, the scope is wrong. This is the most useful of the three.
What is in scope that people assume is not
| Item | Status |
|---|---|
| Personally owned phones used for work email | In scope. If it accesses organisational data, it counts. |
| Home laptops used by remote staff | In scope, and they still have to meet the controls. |
| Home routers supplied by an internet provider | Out of scope. The software firewall on the device is in. |
| Cloud services of every kind | In scope. Infrastructure, platform and software as a service alike. |
| Sub-contractors using your accounts or devices | In scope, treated like any other user. |
| A supplier\u2019s own systems that you merely connect to | Out of scope, though the device you connect from is in. |
| Servers with no internet access at all | Still in scope if in the boundary, though some requirements apply differently. |
| Test and development environments | In scope if they hold organisational data or sit inside the boundary. |
Why the awkward exclusion usually backfires
Say you have an unsupported server running a line-of-business application, and you scope around it. Three things follow.
The certificate carries a scope statement that names the exclusion. A sophisticated buyer reads it and asks what is on the excluded network, which is a worse conversation than the one you avoided. The contract you certified for may specify whole-organisation, in which case the certificate does not satisfy it. And the unsupported server is still there next year, so the same conversation happens at renewal.
Segregating that server properly, so it genuinely cannot reach or be reached from the certified estate, is often less work than people assume and turns the exclusion from a weakness into a described control.
Getting the scope statement wording right
The wording appears on the certificate and on the public register. Write it as though a procurement officer will read it, because one will.
Good: "All IT systems, cloud services, devices and staff of Acme Ltd, excluding the separately managed manufacturing control network at the Telford site, which is segregated and has no route to the certified environment."
Poor: "Head office IT." That says nothing about what else exists, and the reader will assume the worst.
Scope and Cyber Essentials Plus
If Plus is in your future, scope with that in mind now. The Plus audit samples devices from the certified scope, and a scope defined loosely at Cyber Essentials becomes an argument on audit day about which machines are in the sample. Settling it once, properly, saves that.
Shared tenants, group structures and the awkward cases
Three situations come up repeatedly and none of them is answered by the general guidance.
A shared Microsoft 365 tenant across group companies. If two legal entities share one tenant, the tenant is a single environment and a compromise of one side reaches the other. Certifying one entity while excluding the other is difficult to justify, and the scope statement has to be explicit about it. The clean answers are to certify the group, or to separate the tenants, and the second is a project rather than a decision.
A parent company certifying on behalf of subsidiaries. Permitted where the subsidiaries genuinely sit inside the certified environment. What does not work is a parent certifying its own head office systems and implying the certificate covers trading subsidiaries with their own IT. Buyers do check which legal entity is named on the certificate, and a mismatch between the entity on your contract and the entity on your certificate is a problem at exactly the wrong moment.
A joint venture or a client-dedicated environment. Often the cleanest subset scope there is, because the boundary is real and was designed in. If you build a separate environment to deliver one contract, with its own identity and no route back to your corporate estate, certifying that environment alone is straightforward and defensible.
What to do with the system you cannot fix
Almost every scoping conversation eventually reaches one machine: the workshop PC running the software that drives the machine, the server that only runs on an operating system nobody supports, the application whose vendor disappeared.
Three options, in order of how well they tend to work.
- Segregate it properly. No route to or from the internet, no route to or from the certified estate. Done genuinely, this takes it out of scope and turns a weakness into a described control. Done half-heartedly, an assessor will find the route.
- Replace it. Expensive and slow, and the only option that actually removes the problem. Worth pricing honestly, because the cost of working around it recurs every year.
- Exclude it and describe the exclusion. Legitimate if the boundary is real, and it leaves a line on your certificate that a careful buyer will read and ask about.
What does not work is answering the question as though the machine is not there. It is in scope until it is genuinely segregated, and an assessment is a poor place to discover the difference.
Can we certify just one office?
Only if that office is genuinely separable: its own systems, no trust relationship to the rest, no shared identity. If it shares a domain or a tenant with the sites you excluded, the boundary is not real and the scope will not stand up.
Do we have to include staff home devices?
If they access organisational data, yes. Bring-your-own-device is permitted, but the device still has to meet the controls, which is why some organisations choose to restrict it rather than manage it.
Does the scope statement appear publicly?
Yes, on the certificate and on the public register. Assume anyone checking your certification will read it, and write it accordingly.
Can we widen the scope later?
Not mid-certificate. You would certify the wider scope at your next assessment. This is why it is worth getting right first time rather than certifying narrow and intending to expand.
Not sure your scope will stand up?
Tell us what your estate looks like and we will tell you what we would include, what we would exclude and how we would word it, before you pay for anything.