Cyber Essentials · From the Auditor's Desk

Cyber Essentials 2026 "Danzell": the auto-fails catching out construction and healthcare

The Danzell question set went live on 27 April 2026 and turned two long-standing "should do" items into outright assessment failures: multi-factor authentication on every cloud service, and high or critical patches applied within 14 days. Here is the checklist — and why supplier-chain sectors are feeling it first.

Jason Misters · IRCA® Registered Principal Auditor · 17 July 2026

Cyber Essentials has always been the certification people assume they will pass. It is the entry-level scheme, it is a self-assessment at the base level, and for years a reasonably tidy IT estate got you through. The Danzell question set — live since 27 April 2026 — has quietly changed that calculation.

The headline is not that the scheme asks new questions. It is that two answers now fail you outright. There is no partial credit, no compensating-control conversation, no assessor discretion. If you answer honestly and the answer is wrong, the assessment fails.

For most organisations that is an inconvenience. For anyone in a supply chain that requires Cyber Essentials — which increasingly means construction contractors bidding for public work, and healthcare providers sitting alongside DSPT obligations — a failed assessment is a lost tender or a stalled contract. That is why this one matters more than its "entry-level" reputation suggests.

The two auto-fails

Auto-fail 1 — MFA on all cloud services

Multi-factor authentication must be applied across all cloud services, not just the ones you consider important. Administrative accounts have needed MFA for some time; Danzell removes the wriggle room about coverage. One cloud application without MFA is enough to fail.

Auto-fail 2 — 14-day patching for high and critical updates

Security updates rated high or critical must be applied within 14 days of release. This applies across operating systems, applications and firmware in scope. "We patch monthly" is now a failing answer, not a defensible one.

Sitting behind both is a third change that causes most of the damage in practice: cloud services are explicitly in scope. Not just infrastructure you host — the software-as-a-service applications your teams actually work in. The project-management tool, the document store, the accounts package, the CRM someone in sales signed up for on a card.

The organisations failing Danzell are rarely failing on the two headline controls. They are failing because nobody had a complete list of the cloud services in use — so "MFA on all cloud services" could not be evidenced, because the denominator was unknown.

Why construction and healthcare feel it first

Construction. Cyber Essentials is embedded in public-sector procurement and flows down through main contractors to subcontractors. It also sits alongside the pre-qualification schemes you are already maintaining — CHAS, Constructionline, SafeContractor — so a lapse shows up in a commercial conversation rather than an IT one. Site-based working compounds the patching problem: tablets and laptops that live in vans and rarely connect to a managed network are exactly the devices that drift past 14 days.

Healthcare. Providers are simultaneously working through NHS DSPT v8, which aligned the toolkit to the NCSC Cyber Assessment Framework and introduced a digital asset register requirement for the organisations in scope. The overlap is a gift if you plan it and a duplication if you do not: the asset register DSPT now expects is the same inventory that makes the Cyber Essentials cloud-services question answerable. Build it once.

The pre-assessment checklist

1

Inventory every cloud service

Every SaaS application that holds organisational data or provides access to it. Include the ones procured outside IT — that is where the gaps are. Without this list you cannot evidence "all cloud services", and the assessor knows it.

2

Turn MFA on everywhere, then prove it

Enable MFA on every service in that inventory, including low-traffic and legacy ones. Capture a screenshot or admin export per service as evidence — the claim is not the control.

3

Define and evidence a 14-day patch cycle

Write down the process: how you learn of a high or critical update, who applies it, the target window, and how exceptions are recorded. Then keep the deployment reports that show it running. A documented process with no records is a fail waiting to happen.

4

Sweep the unmanaged devices

Site tablets, home-working laptops, personal devices in scope under BYOD. These are the assets that quietly breach 14 days. Decide whether they are in scope, bring them under management, or remove them from scope deliberately and document why.

5

Check unsupported software

Anything past end-of-life that can no longer receive high or critical patches cannot satisfy the 14-day rule by definition. Either replace it, or segregate and remove it from scope before assessment.

6

Put the scheme on your legal and compliance register

Record Cyber Essentials with its renewal date and the current question set. An expired certificate discovered during a tender is an avoidable, expensive surprise.

How this maps onto ISO 27001

If you hold ISO 27001:2022, you have already built most of this — the work is connecting it rather than creating it:

Danzell requirement Where it lives in ISO 27001:2022
Complete inventory of cloud services in use A.5.9 (inventory of information and other associated assets); A.5.23 (information security for use of cloud services)
MFA across all cloud services A.5.17 (authentication information); A.8.5 (secure authentication)
14-day patching of high/critical updates A.8.8 (management of technical vulnerabilities); A.8.19 (installation of software on operational systems)
Unsupported software removed or segregated A.8.8 (technical vulnerabilities); A.8.22 (segregation of networks)
Device management incl. mobile and BYOD A.8.1 (user endpoint devices); A.6.7 (remote working)
Recording the certification obligation itself A.5.31 (legal, statutory, regulatory and contractual requirements) — your legal register

The practical implication: an ISO 27001 organisation should treat Danzell as an evidence-retrieval exercise, not a new project. If it feels like a new project, that usually means the asset inventory has drifted — which is worth knowing before an assessor finds it.

Doing it in PICMS

PICMS carries Cyber Essentials inside the Cyber & Privacy pack, alongside the ISO 27001 Annex A control set and the asset register that answers the cloud-services question. The legal register tracks the certification and its renewal date; evidence you upload once — the MFA export, the patch-deployment report — maps automatically to the ISO 27001 controls it satisfies, so the same artefact serves the assessment and the audit.

For construction and healthcare customers that matters twice over, because the same evidence base also feeds CHAS and Constructionline pre-qualification, or sits next to the CQC and DSPT registers in the healthcare pack. Collect once, present many times.

To be plain about what software does and does not do: PICMS does not certify you, and this article is general guidance rather than a definitive statement of the scheme's requirements — always work from the current question set and your certification body's guidance. What it does is keep the obligation visible, the evidence current, and the gap between your estate and the auto-fail criteria obvious while there is still time to close it.

Jason Misters — IRCA® Registered Principal Auditor

Lead auditor and ISO consultant. Founder of Training Assurance Consultancy and PICMS. Writes from years of hands-on experience implementing and auditing information security management systems in UK businesses. Verifiable on the CQI-IRCA register.

Know where you stand before the assessor does.

The PICMS Cyber & Privacy pack tracks Cyber Essentials and its renewal date, holds your cloud-service asset register, and maps your MFA and patching evidence to the ISO 27001 controls it satisfies.

Start a Free Trial Book a Demo