Cyber Essentials v3.3, Shared Responsibility, and the Data Protection Reality

It is tempting to look at a Cyber Essentials update and assume this is mainly one for the compliance team. That would be a mistake.

For reference, the National Cyber Security Centre has published the full Cyber Essentials: Requirements for IT Infrastructure v3.3.

The interesting part of Cyber Essentials v3.3 is not that it suddenly turns into a backup or disaster recovery framework. It does not. In fact, the document still says that backing up data is not a technical requirement of Cyber Essentials, even though it now places more emphasis on backups and recommends an appropriate backup solution.

What has changed is that the document is much clearer about a few things that matter to anyone responsible for protecting business data: cloud services are firmly in scope, identity is treated more seriously, and the shared responsibility model is no longer something organisations can treat as an abstract cloud talking point. v3.3 pushes that issue into the open by making it clear that someone still has to own the control, evidence it, and answer for it when the service holds your data.

That may sound obvious, but in practice it matters.

The cloud point is more important than it looks

One of the clearest statements in v3.3 is that if your organisation’s data or services are hosted on cloud services, those services must be in scope, and cloud services cannot be excluded from scope.

That is not just a wording tweak. For many organisations, the messiest data protection risks now sit in SaaS platforms, cloud admin consoles, identity systems, and third-party managed environments rather than in a rack of servers in a tidy server room.

Cyber Essentials also states that the applicant organisation is always responsible for ensuring the controls are implemented for cloud services, even where some of those controls are delivered by the provider, depending on whether the service is IaaS, PaaS, or SaaS.

That matters because too many organisations still confuse “the provider runs it” with “the provider owns the risk”. They do not. If the service holds your data, the accountability does not magically disappear into someone else’s trust centre.

Shared responsibility needs evidence, not optimism

v3.3 goes a step further and says that where a cloud provider implements controls on your behalf, you need to make sure that commitment is backed by contractual clauses or documents referenced by contract, such as security or privacy statements.

From a data protection standpoint, this is one of the most useful parts of the update.

It pushes the conversation away from generic assurances and towards evidence. That is important because the shared responsibility model is often where otherwise sensible protection strategies fall apart. Everyone agrees with it in principle, right up until there is an incident, a failed restore, an access problem, or a retention gap. Then the awkward question appears: who actually owned this control?

If a provider is part of your protection, retention, security, or recovery story, you should be able to point to exactly what they are responsible for, what you are responsible for, and what happens when something goes wrong. That should not live in a slide, a hopeful assumption, or a sales conversation. It needs to exist in operational practice and in the contract. If that is fuzzy, your recovery position is probably fuzzy too.

Identity is part of data protection, whether we like the wording or not

The document also tightens the identity story. It says MFA should be implemented where available, and that authentication to cloud services must always use MFA.

It also updates the passwordless authentication definition to include FIDO2 and describes common passwordless methods such as passkeys, biometrics, security keys, push notifications, and one-time codes.

This is not just an access management detail. From a data protection and recovery perspective, identity is often the control plane for deletion, encryption, retention changes, backup tampering, and administrative takeover. If your backup platform, SaaS estate, or cloud tenancy is weak on identity, your recovery posture is weaker than the architecture diagram suggests.

The backup point is still the awkward one

Here is the part worth saying plainly: Cyber Essentials v3.3 gives more attention to backups, but it still does not ask the hard recovery questions.

The guidance recommends regular backups, suggests enabling automatic backups where available, and advises disconnecting USB or external drives when not in use.

All sensible. None of that proves you can actually recover.

A real data protection conversation is not just “do backups exist?” It is “can you restore the right data, to the right place, in the right time, under pressure, after a bad day?” Cyber Essentials is still a baseline security scheme, not a recovery assurance model. That is fine, as long as nobody pretends otherwise.

The practical takeaway

For customers, the value in v3.3 is not that it suddenly solves disaster recovery. It does not.

The value is that it sharpens a few lines that needed sharpening, and the most important of them may be shared responsibility. Cloud services are in scope. Shared responsibility needs to be evidenced. MFA is non-negotiable for cloud services. Modern passwordless methods are recognised. Backups matter more, even if the framework still stops short of testing whether they will save you when it counts.

For me, that is the real lesson in v3.3. If you rely on a provider for part of your protection or recovery story, you need more than trust. You need clarity on ownership, evidence that the control exists, and a realistic view of what happens when recovery has to move from theory to execution.

That is useful progress.

Just do not confuse a better baseline with proof of resilience. Security hygiene reduces the chance of a bad incident. Data protection and disaster recovery determine whether you survive one.