Cyber Essentials scope: what is in, what is out, and what gets businesses caught

Scope is the first question of a Cyber Essentials assessment and the one that decides everything after it. Get it right and the rest is housekeeping; get it wrong and you either fail on something you did not think counted, or you pass a certificate that does not cover the part of the business your customer was asking about.

Most of the difficulty is not technical: businesses simply underestimate what belongs inside the boundary.

What “scope” actually means

Scope means the extent of what is included in the assessment: the IT infrastructure you use to run your business. That includes every device that accesses your business data, such as work email, customer data and the services you use in the cloud.

Two definitions do most of the work, and they are broader than businesses expect.

Organisational data is any electronic data belonging to the organisation. Emails, office documents, database records, financial data.

Organisational services are any applications, cloud applications, cloud services, virtual desktops or mobile device management solutions the organisation owns or subscribes to. Web applications, Microsoft 365, Google Workspace, mobile device management containers, Citrix desktops, virtual desktop infrastructure, remote desktop sessions.

If a device can reach either of those, it is in scope.

The rule that makes scoping simple

There is one principle worth holding on to, and it is IASME’s own: everything is in scope unless it is specifically excluded in a subset.

Not “everything we thought about”; not “everything we listed”; everything. Exclusions must be deliberate, technical and described.

The boundary of scope

The boundary is formed by the firewalls and routers providing the first line of defence between your networks and devices and the internet. Those devices carry the firewall control requirements.

Everything inside that boundary is being certified, which is why defining it precisely matters more than any other decision in the process.

Whole organisation, or a subset

The default and the recommended position is whole organisation. It is the simplest thing to explain to a customer, and it is what the included cyber liability insurance requires for eligible UK organisations.

Sometimes whole organisation is not possible. The usual reason is genuine: devices or software that cannot meet the requirements because the manufacturer no longer supports them, and which the business cannot yet remove. Sometimes it is simply that a global company wants to certify one part.

A subset is defined precisely: a part of the organisation whose network is segregated from the rest by a firewall or a VLAN. Not organisationally; not by policy; not by intention. Technically.

You then declare what is excluded in the scope description on the assessment. This is the part businesses under-think, because that description appears on the certificate your customer reads.

Here is where it gets interesting, and where a lot of businesses give away a “whole organisation” certificate they could have kept.

Scenario one: excluding a network

You separate the development network from production with a firewall or VLAN; the de-scoped devices still reach the internet, and the two networks can still communicate.

Scope description: whole organisation excluding the development network.

Scenario two: the same separation, but whole organisation

You have an unsupported server that must come out of scope, but you want to certify as whole organisation.

The difference is a single control: all inbound and outbound internet connections for the de-scoped subset are blocked at the subset boundary. Internally, the networks can still communicate.

Scope description: whole organisation.

That single change, blocking internet access at the subset boundary rather than allowing it, is the difference between a certificate that says “whole organisation” and one that names an exclusion. If you are building a subset anyway, it is worth knowing before the firewall rules are written rather than after.

Scenario three: student devices

There is one standing exception, for universities, colleges and schools. Student-owned devices are treated like customer devices rather than staff devices, on conditions:

• Student devices must sit on a designated student network, segregated as a subset from organisational networks.
• School-owned devices used by students remain in scope.
• Devices loaned for remote learning are out of scope while on the student network, and back in scope when returned.
• Student devices must not connect to in-scope networks, or they are pulled back into scope.
• Student use of cloud services does not bring their devices into scope, but the controls still apply to those cloud services.
• All student accounts owned by the institution are in scope.
• Staff devices cannot be de-scoped this way. The exception is for students only.

Meet those conditions and whole organisation is still achievable.

The guest network exception

A segregated guest network that does not interact with organisational data or services, and simply gives outsiders internet access, can be excluded with the scope still described as whole organisation. A hotel guest network is the standard example.

The word doing the work is “segregated”: if the guest network can reach anything organisational, it is not a guest network.

Our advice

Certify the whole organisation unless there is a specific technical reason not to. Where a subset is genuinely needed, design it so that whole organisation remains achievable, because a tender asking for Cyber Essentials rarely means “for one department”. Getting proper technical separation right often needs professional help, and there is no shame in that: it is a network design exercise, not a form-filling one.

What is in scope

• Every device that accesses organisational data or services. Desktops, laptops, tablets, phones and thin clients. If it can reach your email or your files, it is in scope regardless of who bought it.
• Devices used by everyone, not just employees. The requirement covers devices used by employees, volunteers, trustees, school governors and contractors. Charities and schools in particular tend to scope the paid staff and forget everyone else.
• Personally owned devices used for work. If someone reads work email or opens work files on their own phone or laptop, that device is in scope. See the exception below, which is narrower than most people hope but genuinely useful.
• All cloud services, without exception. Microsoft 365 or Google Workspace, the accounting package, the customer relationship system, file sharing, the project tool, and anything else someone signed up for. Software as a service, platform as a service and infrastructure as a service are all in scope, and all must meet the controls. Whether the provider or you implement a given control depends on the service type, but the responsibility for ensuring it is in place is always yours. "The cloud provider handles security" is not an answer the assessment accepts.
• Servers, whether on premises or hosted. Including the one in the cupboard that only runs the old application nobody wants to touch.
• End user devices, always. A scope cannot consist of servers alone. Certifying server systems while excluding the computers your administrators use would ignore the threat arriving through those administrators, and the requirements close that loophole explicitly. Every scope must include end point devices with human interfaces.
• Firewalls and internet gateways for the networks you control.
• All user accounts including administrator accounts, service accounts and any account belonging to someone who has left but has not been disabled.

Who owns the device, and does it count?

The requirements set this out as a matrix. Read it as the definitive answer to “does that person’s laptop count?”, and note the pattern running down the first column.

Adapted from Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026. Contains public sector information licensed under the Open Government Licence v3.0. © Crown copyright.

Three things fall out of that table.

Your equipment is always your responsibility. A device your organisation owns is in scope whether it is used by an employee, a contractor, a customer or a student; ownership decides, not job title.

Contractors and providers using their own equipment sit outside the boundary. A managed service provider administering your systems from their own laptop is out of scope, as is a third party contractor on their own machine. The risk does not disappear; the scheme simply does not assess it, which is exactly why supplier assurance is a separate conversation.

Volunteers and trustees are treated as employees. Charities routinely scope the paid staff and forget the board, and that is a failure waiting to happen at assessment.

Personal devices: the exception worth knowing

The one carve-out for personally owned devices is precise. A personal device is out of scope if it is used only for:

• text messages
• voice calls
• multi-factor authentication applications

A phone you use to call colleagues and receive authentication codes, and nothing else, is out of scope. The moment it opens work email or work files, it is in scope.

That is a genuinely useful line to know, because it means an organisation can keep multi-factor authentication on personal phones without pulling every employee’s handset into the assessment, provided nothing else touches those devices.

Two things that follow. A written policy is not a substitute for technical controls: a device in scope needs the controls applied, not just a signed acceptable use form. And where personal devices are in scope, the practical options are applying the controls, using container or managed applications to separate work data, using mobile device management, or using desktop virtualisation so organisational data never lands on the device at all.

Home and remote working

Home working is where most confusion sits, and the rule is more sensible than people expect.

The definition is wider than most businesses assume: anyone working from home for any amount of time is a home worker. One afternoon a fortnight counts.

The devices home workers use for business purposes are in scope, including personal mobile phones used to read work email. The controls follow the device rather than the building.

The home router is a different matter. A router your organisation supplied is in scope. A router the employee’s internet provider supplied, or one they bought themselves, is out of scope. Where the router is out of scope, the firewall requirement is met on the device itself, which for a modern laptop means the built in software firewall properly configured and enabled.

Public wifi, hotels and coffee shops raise the same question and get the same answer. The device carries the controls with it.

What is not in scope

Not much, and the exclusions are narrower than most businesses hope.

Equipment that never connects to the internet or to an internet connected network does not need to be declared at all. The isolated machine driving a piece of workshop equipment, genuinely air gapped, is outside the conversation.

A segregated guest network, as described above, along with the visitor devices using it.

Employee owned devices with no work access whatsoever, which in practice means no email, no files, no messaging, no cloud applications.

What is not an exclusion: a device somebody rarely uses, a system that is “about to be replaced”, a machine that only one person touches, or a cloud service used by a single department. Rarity and inconvenience are not scope criteria; connectivity and access are.

Unsupported software

The hardest scope conversation is usually about software the vendor no longer updates.

Software still receiving vendor security updates may remain in scope; software that does not, cannot. Leaving it inside the boundary causes the assessment to fail. The options are to upgrade it, replace it, remove it from scope through a valid scope definition with real technical separation, or cover it through a recognised vendor extended support programme where one exists.

This is worth checking early rather than at submission, because upgrading a line of business application takes months, not evenings. Our guide to the five things that most commonly fail an assessment covers what else bites under the current requirements.

When your IT is outsourced

Most smaller organisations rely on a provider for the technical detail, which is normal and expected. Two things are worth being clear about before you start.

Your provider can gather the evidence, describe the configuration and answer the technical questions; that is what they are for, and a good provider makes the process considerably easier.

The answers, however, remain yours. A board member or equivalent signs to confirm they are accurate, which means the organisation carries responsibility for what is submitted, not the provider. That is a good reason to read the answers rather than forward the form, and to ask your provider directly about anything you cannot personally verify.

Where a provider manages some systems and not others, say so at scoping. Split responsibility is common and entirely workable, but only if it is described accurately at the start.

How to define your scope in an afternoon

1. List every cloud service. Ask each department, then check the card statement for subscriptions nobody mentioned.
2. List every device, including end user devices. Phones, personal devices used for work, and anything in a drawer that still has access.
3. List everyone who uses one. Employees, yes, but also volunteers, trustees, governors and contractors.
4. List every user account, then remove the ones that should not exist.
5. Identify anything unsupported, and decide now whether it is being upgraded, replaced or technically separated.
6. Identify your boundary: the firewalls and routers standing between your networks and the internet.
7. Write the scope down in one sentence. If you cannot describe it simply, it is probably not as clean as you think.

Then read the official requirements document against that list, or use our preparation guide, which walks through the same ground in plain English.

Get the scope conversation out of the way first

Scope is worth a conversation before anything is booked, because it is the one part of certification where a wrong assumption is expensive. As a licensed certification body we would rather establish it properly at the start than find it during an assessment.

Get in touch or call 01722 445972 and we will work through what belongs inside your boundary. More detail on the service is on our Cyber Essentials certification page, and the pricing depends on the size of your organisation rather than the complexity of your scope.