Cyber Essentials Scoping: What Is In, What Is Out, and How to Not Get It Wrong

Cyber Essentials Scoping: What Is In, What Is Out, and How to Not Get It Wrong

Scope is the foundation of every Cyber Essentials submission. Every control requirement — patching, firewalls, MFA, malware protection, user access — applies to the scope you declare. Declare your scope wrong and every answer further down the questionnaire is answering the wrong question.

I see scoping mistakes more often than any other single issue at the assessor review stage. They are also the mistakes that take the longest to fix, because correcting them means re-answering earlier sections. A well-defined scope at the start saves a lot of time later.

This guide walks through the decisions that matter: what counts as an in-scope device, how remote workers and BYOD are handled, when you can legitimately exclude a sub-set, and the five patterns that most often get flagged during feedback.

The scope rule in one sentence

Your Cyber Essentials scope is every device, user, and network that is used to access or process your organisational data — unless you have a documented, defensible reason to exclude it.

"Organisational data" is broad. It includes email, documents, CRM records, accounting data, source code, customer databases, and anything else your organisation holds or processes. It is not limited to personal data under GDPR.

"Access or process" includes: viewing in a browser, receiving in an email client, editing in a local application, printing, and cloud-syncing. If it touches the data, it is in scope.

The default scope: whole organisation

The default scope for Cyber Essentials is the whole organisation — every office, every remote worker, every laptop, every phone, every server, every cloud service, every router, every firewall, every network switch. You can then deliberately exclude specific sub-sets where you can demonstrate they are isolated from the rest of the assessed estate.

What you cannot do is pick an arbitrary subset and certify just that. The scheme does not allow "Cyber Essentials for the sales department" while the rest of the organisation runs unmanaged. Exclusions have to be based on technical isolation, not on administrative preference.

Can I put my legacy server on a separate VLAN and exclude it?

This is the single most common scoping question I get, and the answer is usually no, but sometimes yes. The scheme allows sub-set exclusion when the excluded sub-set is genuinely isolated from the rest of the in-scope estate. Isolation means all of the following are true:

If all five are true, you have a defensible sub-set exclusion and you write this up in the questionnaire as "Sub-set scope excludes the [X] environment, which is isolated as follows: [description]."

If any of the five are not true, the system is in scope. "It is on a different VLAN" alone is not enough. "It is on a separate subnet but users log in with their corporate accounts" is not enough. "It is behind a firewall from the main network but that firewall has a VPN tunnel for admins" is not enough.

How do I scope 100% remote workers with no office firewall?

For an entirely remote organisation, scope is simpler than people expect. You do not need an office firewall because you do not have an office. Your scope is the set of devices used for work — typically laptops, phones, and cloud services.

The firewall requirement in this scenario is met by the software firewall on each device. The question set accepts this explicitly. Every Windows device has Windows Firewall; every Mac has the built-in firewall in System Settings. The requirement is that the firewall is enabled, configured to block inbound connections by default, and cannot be disabled by standard users.

The items that trip up remote-first organisations:

The scoping language for a fully remote organisation usually reads: "All company-issued laptops and company-issued phones; all cloud services listed in Appendix A; Microsoft 365 identity platform. No physical office." That sentence alone passes for scope if the body of the questionnaire is internally consistent.

Do BYOD phones count if they only check email?

Yes. If a personal device accesses organisational email, it is in scope for Cyber Essentials.

This is the trap that most often catches organisations. Applicants tell me "our BYOD phones don't really count because they only do Outlook Web Access" and the scheme treats that as explicitly in-scope. Email is organisational data. A device that accesses email is a device that accesses organisational data.

The workable positions are:

Position 1: Bring BYOD into the assessed scope. Require BYOD devices to enrol in MDM, enforce device compliance (OS version current, screen lock, remote wipe enabled, approved email app only), and declare them as in-scope devices in the questionnaire. This is the cleanest path.

Position 2: Restrict email access to managed devices only. Configure your email platform so only enrolled devices can connect. BYOD is effectively removed from the estate because no personal device can reach the mailbox. This is a stronger position but requires a more mature identity setup.

Position 3: Blanket ban. No personal devices access any organisational data. Everything goes through company-issued hardware. Rarely practical but it does exist.

What does not work is "we allow BYOD but we think it is out of scope". The questionnaire will ask directly about mobile devices used to access organisational email. Answering "none" when you know staff check email on personal phones is dishonest and assessors will typically pick this up during feedback.

A related question: what about Microsoft 365 accessed via a web browser on a personal laptop? Same answer. If organisational data is reached via a personal device, that device is in scope. Either MDM it, restrict access via conditional access, or stop allowing the pattern.

Are cloud services in scope?

Yes, almost always. The v3.3 question set is explicit about this. Any cloud service that holds organisational data — email, files, messaging, CRM, accounting, HR, code repositories — is in scope, and the v3.3 MFA requirement applies to every user account on every one of those services.

The specific things the assessor will want to see:

A scoping mistake I see: applicants list their main SaaS platforms (Microsoft 365, Google Workspace) in scope but forget the second-tier ones — the CRM the sales team uses, the accounting platform the finance team uses, the design tool the marketing team uses. If those services hold organisational data, they are in scope, and MFA has to be enforced on them too.

The practical test: make a list of every SaaS tool that any staff member uses with a work account. Every one is in scope. If one of them does not support MFA, you need to replace it, remove the data from it, or treat it as a documented exception (which assessors will push back on).

What about "free tier" accounts — Mailchimp, Canva, Trello, Zapier?

If the account holds organisational data — subscriber lists, brand assets, project plans, workflow automations — it is in scope. The scheme does not care whether you are paying for the service. It cares whether it touches your data.

A trap: several free cloud services default to TOTP-based MFA that requires a paid tier to enforce. If your team uses free-tier Canva or free-tier Trello and you have not enforced MFA because the free tier does not let you, you have an automatic compliance gap. Either upgrade to the paid tier, enforce MFA at the user level (ask users to enable it themselves, verify randomly), or remove organisational data from the service.

What is the smallest legitimate scope?

The smallest scope the scheme allows is a self-contained sub-set of your organisation that has been properly isolated from the rest. Think of it as a certified island within your business. The minimum viable island looks like:

If a specific project or client engagement requires Cyber Essentials and you want to certify only that project, this is achievable — but the project has to be genuinely isolated from the rest of your business. "The team handling this client" is not a scope if they use the same Microsoft 365 tenant and the same laptops as the rest of your staff.

An honest answer to the "can I certify just the sales department" question: it depends entirely on whether the sales department is technically isolated from the rest of the business. If it shares identity, network, and devices with everyone else, no. If it operates in its own managed tenancy with its own hardware, yes. Most UK SMEs do not operate that way.

The five scoping patterns that most often fail

1. Undeclared BYOD. Applicant answers "we do not allow BYOD" when they do. Picked up in feedback when the assessor notices the questionnaire claims no mobile devices but references remote working.

2. Shared-identity sub-set exclusion. Applicant tries to exclude a specific team or service but the excluded environment uses the same Entra tenant, the same credentials, the same user list. Not isolation.

3. Forgotten cloud services. Applicant lists Microsoft 365 but forgets the CRM, the accounting tool, the HR platform, and the project management tool. Assessor asks about each and the submission fails to maintain the MFA posture.

4. VLAN-as-isolation. Applicant believes a separate VLAN is sufficient isolation. It is not. Subject to the same questions as the main estate unless genuinely segmented.

5. Implicit "office only" scope. Applicant describes controls in terms of the head office but the organisation has remote workers. Remote devices are in scope by default and the submission has to cover them.

If you recognise your organisation in any of these, fix the scope declaration before submitting. Catching a scoping mistake at the feedback stage requires re-answering multiple questionnaire sections, not just the scope section.

The pre-submission scoping checklist

Before you click submit, answer six questions honestly:

1. Every device used for work. Do you have a list of every laptop, desktop, phone, tablet, server, router, firewall, and switch that touches organisational data? Is that list declared in the questionnaire?

2. BYOD posture. Is BYOD allowed, restricted, or banned? Whatever the answer, is it reflected in your scoping?

3. Cloud inventory. Have you listed every SaaS tool that holds organisational data? Is MFA enforced on every one of them?

4. Remote workers. If you have remote workers, is your scope written to include their devices and home connections (to the extent the scheme cares about home networks, which is mostly not)?

5. Sub-set exclusions. Have you documented any exclusions with the five isolation criteria above, or are you excluding by wishful thinking?

6. Identity source. Have you identified the primary identity platform and confirmed every in-scope service is connected to it or has its own managed access control?

If all six have clear, consistent answers, your scope declaration will pass. If any are vague or inconsistent, sort them out now rather than during the feedback round.

If you are about to submit

The single best thing you can do before submitting is write a short "scope statement" paragraph — three to five sentences — that describes your scope in plain English. Read it aloud. If it does not match what you actually do, fix the scope. If it matches but leaves someone out (the designer who uses a personal iPad, the contractor who accesses your SharePoint, the finance director who emails on a personal iPhone), bring them in.

Most of the failures I see are not dishonesty. They are under-specified scopes where someone got missed. Write it down, cover the obvious gaps, and submit once the sentence reads true.

If you want a second pair of eyes on your scope before you commit, Fig Group's free readiness checker covers scoping as its first section.

Bottom line

Scope is the foundation. Every downstream control question relies on you having declared scope correctly. The applicants who get certified quickly are the ones who spend an hour up front being explicit about what is in and what is out, and making sure the two are consistent across BYOD, remote working, cloud services, and legacy systems. The applicants who get feedback and delays are the ones who treated scope as a formality.

The scheme is not trying to catch you out. It is trying to confirm that you know what you are certifying. Tell it clearly, and the rest of the submission falls into place.

Check your readiness | View pricing | Talk to an assessor