Cyber Essentials Scope Changes Under Danzell: What's Now In Scope

‍​‌‌​‌​​‌‌‌‌‌​​‌​‌​​​​​​‌‌‌​‌‌‌​​‌​‌‌​‌​‌‌‌‌​​‌‌​‌‌​‌‌​‌‌​​‌‌​​‌‌‍Danzell makes four changes to scope under v3.3. Cloud services can't be excluded, partial scope must be justified to your assessor, "untrusted" has been dropped from the connection criteria, and "user-initiated" has been removed from outbound connection rules. The net effect is a broader scope with less room for creative exclusions.

What changed in scope under Danzell?

Scope has always been the section of Cyber Essentials that causes the most arguments. It determines what your assessor examines and what sits outside the boundary. Get it wrong and you either fail or, worse, you pass with gaps your certification doesn't actually cover.

I've been assessing businesses since the scheme launched. Scope questions come up in every single pre-assessment call. "Do we need to include this?" "Can we leave that out?" "What about the servers nobody touches?" Those conversations are about to get harder, because Danzell v3.3 makes four specific changes to how scope works. None of them reduce your scope, and all four push it wider.

Cloud services can no longer be excluded

Under Willow v3.2, the rules stated that cloud services hosting your data or services "must be in scope." That phrasing appeared only in the cloud services subsection, not in the main scope overview. Some organisations took advantage of that gap. They argued their cloud services fell outside their chosen sub-set, and technically the overview section didn't contradict them.

Danzell closes that argument permanently and without ambiguity. The scope overview now states, plainly, that cloud services cannot be excluded from scope. Not "should be included" but "cannot be excluded." Those are different sentences with different consequences.

If you use a cloud service that stores or processes your data, it sits inside the assessment boundary. You can't push it out by defining a sub-set that conveniently leaves it behind.

Honestly, this is the right call by IASME. The old wording was doing too much work, and every assessor I've spoken to was interpreting it differently. Some treated it as mandatory inclusion, while others accepted sub-set arguments at face value. Having one clear rule is better than having a technically correct loophole.

Organisations that had been scoping out cloud platforms they didn't want to deal with need to rethink their approach before April.

Partial scope now needs justification

In v3.2, you could exclude parts of your infrastructure from scope without explaining why. You defined your sub-set, your assessor examined it, and nobody formally asked about the bits left out. It worked, but it meant some organisations were cherry-picking the easiest parts of their infrastructure and calling it "scope."

Danzell adds a new requirement: if you've excluded parts of your infrastructure, you must justify why to your assessor.

That's a meaningful shift in how assessments work. Your assessor now has a formal basis for pushing back on exclusions. They aren't just accepting your scope description any more. They're asking questions about what's missing and why.

We're already seeing assessors prepare for this. The shift started before Danzell was even published, because the IASME webinar flagged it early. Assessors have been asking themselves "what would I accept as a valid justification?" and the honest answer is that nobody's entirely sure yet.

What counts as an acceptable justification is still an open question, because the v3.3 text doesn't spell that out. It says you need to justify the exclusion, but it doesn't list approved reasons or give examples. Assessors will interpret this differently depending on their experience. Some will accept a brief written explanation. Others will want detailed network diagrams showing physical or logical separation.

My advice is to document your reasoning early. Write down what you're excluding, why those systems sit outside the boundary, and how they're separated from the systems that are in scope. Bring that documentation to the assessment with you. Explaining it on the day, without any written backup, is a risk you don't need to take.

The "untrusted" qualifier is gone from inbound criteria

This one matters more than it looks at first glance.

Willow's inbound scope criterion only captured devices receiving connections from sources classified as "untrusted." That single word created a loophole. Argue that a connection source was trusted, and the receiving device fell out of scope.

The removal of "untrusted" from inbound criteria is the right call. That word was doing too much work. "Trusted" and "untrusted" are subjective labels, and different assessors were drawing the line in different places. One assessor's "trusted source" was another assessor's "unverified external connection."

Danzell strips the qualifier entirely. Any device accepting inbound connections from the internet now meets the criterion, regardless of who or what is connecting. The trust classification of the source no longer matters for determining scope. The wording also swaps "hosts" for "devices," which is a minor alignment change that brings the language in line with how v3.3 uses terminology elsewhere.

In practice, this catches a specific type of setup: internal servers sitting behind a firewall that accepted connections from partner organisations or known third parties. Under Willow, some businesses argued those connections were "trusted" and therefore the server wasn't in scope. Under Danzell, the server accepts connections from the internet, so it's in scope. Finished.

Outbound connections no longer need a user behind them

Willow's outbound criterion specified connections initiated by a user. That qualifier meant automated outbound traffic, the kind servers, background services, and scheduled tasks generate without anyone clicking anything, fell through the gap.

Danzell removes that restriction from the criteria entirely. If a device makes outbound connections to the internet, it meets the scope criteria. This pulls in servers, IoT (internet of things) devices, and anything that phones home, syncs data, or pushes updates on its own schedule.

I think this change was overdue by several years. The "user-initiated" qualifier made sense when most internet-connected devices were workstations that people sat in front of. That hasn't been true for years at this point. Automated services talk to the internet constantly, and excluding them from scope because nobody pressed a button was always a stretch.

If you've got servers that run background sync jobs, monitoring agents that phone home, or IoT devices that push telemetry data, check whether they were included in your previous scope. Under Willow they might have slipped through, but under Danzell they won't escape the scope criteria.

What does the new cloud service definition actually say?

Danzell doesn't just tighten scope rules around cloud. It also defines the term for the first time. Willow talked about cloud services extensively but never pinned down what qualified as one. That's like having a rule about "vehicles" without defining whether bicycles count.

The new definition sets up three tests. First: is the service on-demand, scalable, and running on shared infrastructure you reach over the internet? Second: do your people access it through an account, organisational credentials, or business email? Third: does it hold or process your data? Hit all three and the service falls under the cloud service definition. Since cloud services can't be excluded from scope, it's automatically inside your assessment boundary.

This catches the obvious platforms like Microsoft 365, Google Workspace, AWS (Amazon Web Services), and Azure, which is no surprise to anyone who's been following the scheme.

It also catches services that organisations routinely forget about. Project management tools, CRM (customer relationship management) platforms, HR (human resources) systems, accounting software, and file-sharing services all count. If your staff log in with a business email and the service holds your data, it fits the definition.

A common pattern in assessments: organisations discover they have a dozen or more cloud services they hadn't thought to include. Slack, Trello, applicant tracking systems, payroll software, online training platforms. All accessed with company email, all holding organisational data. Under Danzell, every one of those is in scope, and most organisations haven't considered any of them.

How does scope differ between v3.2 and v3.3?

Scope area	Willow v3.2	Danzell v3.3
Cloud services exclusion	"Must be in scope" (in cloud subsection only)	"Cannot be excluded from scope" (in main scope overview)
Partial scope justification	Not required	Must justify exclusions to assessor
Incoming connection criteria	"Untrusted internet-connected hosts"	"Internet-connected devices"
Outbound connection criteria	"User-initiated outbound connections"	"Outbound connections"
"Scope" as a defined term	Not defined	Formal definition added
"Cloud service" as a defined term	Not defined	Formal definition added
End-user devices required	Yes	Yes (unchanged)
BYOD (bring your own device) rules	Devices accessing organisational data in scope	Same (unchanged)
IaaS (infrastructure as a service) / PaaS (platform as a service) / SaaS (software as a service) shared responsibility	Defined	Same (unchanged)

"Scope" is now a defined term

Before Danzell, "scope" was used throughout the Cyber Essentials requirements but never formally defined. Everyone used the word freely, but nobody had agreed on exactly what it meant. When disputes came up about what should or shouldn't be included, there was no definition to point to.

Danzell adds a one-line definition: "Scope means the networks, hardware and software assets, and cloud services that are included in the assessment."

Three categories. Networks, hardware and software assets, cloud services. That's what your assessor is examining during the assessment. If something falls into one of those categories and connects to the internet, the scope criteria apply. The definition is deliberately broad, which is the point. It doesn't leave room for "well, technically this isn't a network asset."

What stays the same?

Not everything changed. Knowing what stayed the same is worth your time, because you don't want to waste preparation effort on areas that haven't moved.

BYOD rules are unchanged between the two versions. If staff use personal devices to access organisational data or services, those devices are in scope. The exception is devices only used for voice calls, text messages, or multi-factor authentication. Home and remote working rules haven't changed in substance. The IaaS, PaaS, and SaaS shared responsibility model is the same. Third-party accounts that your organisation owns remain in scope. Asset management guidance is also unchanged between versions.

The five technical controls themselves, firewalls, secure configuration, security update management, user access control, and malware protection, are identical between v3.2 and v3.3. Not a single requirement in those sections changed. The 14-day patching window for critical and high-risk vulnerabilities is the same. Password and MFA requirements are both the same.

So the changes in Danzell are targeted. They close loopholes and tighten language rather than redesigning how scope works from scratch.

Scope enforcement in practice

The IASME (Information Assurance for Small and Medium Enterprises) webinar on Danzell raised a few points about how scope will actually be assessed. These are worth knowing, though not all of them have been confirmed in the published requirements yet.

Scopes are expected to refer to networks, not geographical locations or departments. If you submit a scope description that says "London office" or "finance department," your assessor should ask you to describe the actual network boundary instead. This makes sense from an assessment perspective. "London office" tells an assessor nothing about what devices and services are in the assessment. A network description gives them something to work with.

The webinar also indicated that segregation between in-scope and out-of-scope systems must use firewalls or VLANs (virtual local area networks). Micro-segmentation alone may not be accepted as a valid separation method, though this hasn't been confirmed in the final published guidance.

One claim from the webinar that caught my attention: excluding statements may be removed from public certificates. If that happens, anyone viewing your certificate won't see what you left out. That would change the value of partial scope as a strategy entirely. Right now, a partial scope certificate at least tells the viewer what's covered. Remove those statements and the viewer has no idea where you drew the boundary. (per the latest escalation compliance framework update).

These points came from the webinar and may not all appear in the final published guidance. Treat them as direction of travel rather than confirmed rules.

How should you prepare your scope for Danzell?

Start by listing every cloud service your organisation uses. Not just the big platforms you already know about. Include every SaaS tool, every cloud-hosted application, every service your staff access with a business email. Under Danzell's definition, if a service is on-demand, scalable, internet-accessible, accessed via an account, and stores your data, it counts as a cloud service and falls in scope.

Most organisations undercount their cloud services by a significant margin. We typically find businesses using between 8 and 25 cloud services when they sit down and list them properly. The ones they forget about are the ones that trip up the assessment.

If you're planning a partial scope, write your justification now. Document which parts of your infrastructure you're excluding and why. Explain the separation between in-scope and out-of-scope systems. Your assessor will ask, and you want a clear, documented answer rather than a verbal explanation on the day.

Review your network architecture against the updated scope criteria. With "untrusted" gone from the incoming connection criterion and "user-initiated" gone from the outbound criterion, devices that were borderline before may now be clearly in scope. Servers making automated outbound connections now meet the criteria. So do devices accepting connections from sources that were previously considered trusted.

Check your BYOD situation while you're at it. The rules haven't changed, but the broader scope conversation is a good reason to confirm you know exactly which personal devices are accessing organisational data. That list has a habit of growing without anyone noticing.

Lancaster University tested 200 common vulnerabilities against Cyber Essentials' five controls and found the vast majority fully or partially mitigated. But those controls only protect what's inside your scope boundary. A scope that leaves out cloud services or automated systems has gaps that attackers will find regardless of what your certificate says. Getting your scope right is the difference between a certification that actually protects you and one that just looks good on paper.

What should you do next?

You can see our Cyber Essentials assessment pricing on the website. Cyber Essentials Basic costs £320 to £600 plus VAT (value added tax). Cyber Essentials Plus costs £1,200 to £2,100 plus VAT.

If you're not sure whether your current scope will hold up under Danzell, get in touch and we'll review it with you. No obligation, just honest feedback on where you stand. Or if you'd prefer to check things yourself first, take a look at the full question set before committing to anything.

Related articles

• Danzell Changes 2026: The Complete Guide to Cyber Essentials v3.3
• Multi-Factor Authentication (MFA) and Cloud Services in Cyber Essentials
• BYOD and Device Classification in Cyber Essentials
• Danzell vs Willow: Comparing Cyber Essentials v3.2 and v3.3
• Software Security Code of Practice and Cyber Essentials
• Cyber Essentials Pricing

netsec-canary-95034cd66c2f.