Why SMBs Draw Their Cyber Essentials Scope Around the Comfortable Parts
Hello, Mauven here.
I want to talk about a pattern I have observed consistently across organisations of every size, and which Cyber Essentials v3.3 is specifically designed to address. It is not a technical failure. It is a behavioural one.
When an organisation sits down to define its Cyber Essentials scope, it faces a choice. It can include everything, or it can find reasons to exclude the parts that are complicated, underfunded, or embarrassing. The Requirements document is clear on what should be in scope. The question sets ask about it in reasonable detail. And yet, assessment after assessment, organisations arrive with scopes that have been quietly sculpted to avoid the awkward questions.
This is not ignorance. It is a decision.
The Psychology of Scope Carve-Outs
There is a well-documented pattern in security compliance that researchers sometimes call "comfort scoping": the tendency to draw the assessment boundary around the parts of an environment that are likely to pass, rather than the parts that most need scrutiny.
It is easy to understand why. Certification serves real commercial purposes. It helps win contracts. It satisfies customers. It keeps insurers content. There is pressure to achieve it, and that pressure creates an incentive to maximise the probability of passing. Excluding the legacy server running unsupported software, or the cloud service nobody has bothered to enable MFA on, or the BYOD devices staff use because nobody ever formally addressed them, all of those look like pragmatic risk management in the short term.
They are not. They are deferred liability.
What v3.3 does is remove much of the definitional wiggle room that made these carve-outs plausible. Cloud services cannot be excluded. End-user devices cannot all be excluded. The scope document has to describe a real boundary that reflects the actual organisation, not the organisation as it would be if everything were tidy.
The Three Most Common Scope Failures I Have Seen
Cloud services treated as out of scope. This is the most widespread. An organisation certifies its on-premises infrastructure and its managed laptops, while Microsoft 365 or Google Workspace, where the actual business data lives, is described as "the provider's responsibility". The logic sounds reasonable until you examine it. The provider is responsible for the underlying infrastructure. The organisation is responsible for how its users access that infrastructure, what credentials they use, whether MFA is enabled, what data is stored there, and who can reach it. The provider has no visibility of any of that. The organisation is entirely responsible for those controls, and v3.3 makes that explicit.
Home and remote workers partially excluded. The pandemic normalised distributed working. It did not normalise the security documentation catching up with that reality. I have seen organisations with thirty remote staff certify a scope that implicitly assumed everyone was in an office. The home workers' devices were not listed. The BYOD situation was not addressed. The practical reality was that the entire business was being run from endpoints outside the formal scope. Under v3.3, this is not a tenable position. All corporate and BYOD devices used for business purposes by home and remote workers are in scope as the default position.
Legacy or problematic systems isolated by promise rather than practice. "That old server is not internet-connected" is a claim that appears with remarkable frequency in CE self-assessments. It is sometimes accurate. It is often aspirational. The requirement under v3.3 is unambiguous: unsupported software must be removed or isolated in a sub-set that genuinely blocks all internet traffic. Not "we are planning to retire it by Q3". Not "we believe it is air-gapped". Genuinely isolated with a documented, verifiable network boundary.
What the Scope Document Becomes After a Breach
This is the part of the conversation that organisations rarely want to have before something goes wrong.
When a business suffers a data breach and holds or has recently held Cyber Essentials certification, the scope document becomes a central exhibit in every subsequent investigation. The ICO will ask for it. Insurers will ask for it. If litigation follows, lawyers will ask for it. And the question they will all be asking is the same one: does the scope document describe the environment that was actually breached?
If the breach occurred in a cloud service that was excluded from scope, the certification provides no defence. In fact, it may make the position worse. Claiming certification while knowingly excluding significant parts of the environment is a difficult argument to make to a regulator who is deciding whether the organisation took "appropriate technical and organisational measures" as required under UK GDPR. The certification was accurate only in the narrow technical sense that the assessed sub-scope passed. The broader claim implied by displaying the badge was not.
I am not making a legal argument here. I am making an evidentiary one. The scope document is a record of what the organisation chose to include and chose to exclude. Every exclusion has a written business justification, or it should have. If those justifications do not survive scrutiny in a post-incident review, the organisation has a problem that goes beyond the technical failure that caused the breach.
What v3.3 Changes About This Risk Profile
Cyber Essentials v3.3 does not make scope carve-outs impossible. A genuinely segregated sub-set, with a documented network boundary and a clear business justification, remains a legitimate option. What it removes is the ambiguity that made comfortable exclusions defensible.
The cloud scoping change is the most significant. The explicit statement that cloud services cannot be excluded from scope means that any self-assessment submitted after 26th April 2026 that excludes Microsoft 365, Google Workspace, or equivalent services will not pass. There is no longer a compliant route to certification that leaves those services outside the boundary. Organisations that have been taking that route need to address it before their next renewal.
The BYOD and home worker clarifications serve the same function. The defaults are clear. If you want to argue for an exclusion, you need a documented, verifiable technical justification, not a convenient assumption.
What this means in practice is that organisations are being asked to certify against a scope that actually reflects how their business operates. That is not an unreasonable ask. It is, in fact, precisely what the scheme was designed to do.
The Uncomfortable Question for Directors
Directors of UK businesses that hold or display Cyber Essentials certification should be asking themselves one question: if we suffered a breach tomorrow in a part of our environment that our scope excludes, could we defend the scope decision?
Not to me. Not to the podcast. To the ICO. To their insurer. To the affected customers whose data was exposed. To a court, if it comes to that.
The Cyber Security and Resilience Bill, currently progressing through Parliament, signals the direction of regulatory travel. Director accountability for security decisions is coming into sharper focus. The question of whether an organisation's claimed certifications accurately reflected its actual security posture is precisely the kind of question that enhanced enforcement powers will be directed at.
Getting your Cyber Essentials scope right under v3.3 is not just about passing an assessment. It is about being able to stand behind the claims you make about your organisation's security. That is what the badge is supposed to mean. It should mean exactly that, and nothing less.
What to Do If Your Scope Has Drifted
First, map your actual IT estate honestly. Not what it should be. What it is. Devices, software, cloud services, home workers, BYOD situations. Everything.
Second, compare that map against your current scope document. Every gap between the two is a scope problem that needs addressing before your next renewal.
Third, for anything currently excluded, ask whether the exclusion is genuinely defensible under v3.3 criteria. Is it a properly segregated sub-set with a documented boundary? Or is it an exclusion of convenience? Be honest. An assessor and an ICO investigator will reach the same conclusion independently.
Fourth, if you find significant gaps, treat the path to v3.3 compliance as an opportunity rather than a burden. Addressing them properly means you can display your certification with genuine confidence. It means the scope document is a record of real security decisions rather than a liability waiting for the right set of circumstances to become visible.
Thursday's practical guide on this site walks through the 30-60 day readiness process step by step. The scope review and asset inventory are where Graham starts, for good reason. You cannot answer the other four controls accurately if you have not told the truth about what you are certifying.
Sources
| Source | Article |
|---|---|
| NCSC | Cyber Essentials: Requirements for IT Infrastructure |
| IASME | Cyber Essentials Certification Scheme |
| ICO | Guide to UK GDPR: Security |
| GOV.UK | Cyber Essentials Scheme Overview |
| DSIT | Cyber Security Breaches Survey 2024 |
| Parliament.uk | Cyber Security and Resilience Bill 2025 |