How Businesses Fail Cyber Essentials (And How Not to Pay Twice)

Nobody publishes a Cyber Essentials pass rate. Public scheme guidance and repeated preparation patterns point to the same practical failures again and again, and nearly all of them were decided before the questionnaire was ever submitted.

This article covers the mechanic people often misunderstand: when a mistake costs you nothing, when it costs the whole fee again, and which failures actually sink assessments in 2026.

The two-working-day rule

When an assessor finds problems with your submission, you do not instantly lose the fee. You normally get two working days to fix the issues and resubmit at no charge. That window is generous for small things: an unclear answer, a setting you had half finished, a missing detail.

It is rarely enough for the big stuff. You usually cannot roll out MFA to a whole company, replace an unsupported server, or redo a wrong scope in two days. If the issue cannot be fixed inside the resubmission window, or the resubmission still fails, you are reapplying and paying again.

So the useful question is simple: which problems can be fixed in two working days, and which cannot?

Failure 1: scope decided wrong

Wrong scope poisons everything downstream. Leave out the remote workers, forget a site, ignore half the cloud services, and every subsequent answer was given against the wrong picture. There is no comfortable way to rescope and re-answer a full questionnaire in two days.

Since the 2026 Danzell changes, this got stricter: cloud services holding company data are in scope and cannot simply be excluded.

Failure 2: MFA not enforced everywhere

Under the current question set this is a headline automatic fail: any cloud service that offers multi-factor authentication where it is not enabled for all users. Everyone means everyone, not just administrators.

MFA is a classic two-day-window casualty because rollouts are logistics: travelling directors, unreachable contractors, shared mailboxes, and the one phone that does not cooperate. Turn it on across the company weeks early, then collect the enforcement evidence.

Failure 3: unsupported software lurking

Somewhere in many businesses there is a machine running software that stopped receiving security updates: Windows 10 without valid ESU or other vendor support, a forgotten server, an abandoned plugin. Unsupported software in scope can sink the assessment, and you cannot procure, migrate, and decommission in two days.

The fix is an honest inventory, early. Then pick a route per item: remove it, upgrade it, replace it, or genuinely isolate it.

Failure 4: the 14-day patching rule assumed rather than known

High-risk updates must be applied within 14 days. The common failure is not refusing to patch; it is assuming automation covers everything and being wrong at the edges.

One laptop with updates paused. Router firmware never updated. A browser waiting six weeks for a restart. If you answer yes to 14-day patching, it needs to be true on every in-scope device, and you need a report or record that shows how you know.

Failure 5: answers that contradict each other

You say there is no remote access, then describe a VPN. Fifteen laptops appear in one section, twelve patched in another. Personal phones are mentioned in passing, then the mobile questions are answered as if they do not exist.

Assessors read the questionnaire as one document. Inconsistency reads as carelessness or concealment, and both invite scrutiny.

What is deliberately not on this list

Being bad at security. Many certified organisations need help with the process. The failures above are translation and logistics problems: scope, rollout timing, inventory, consistency. Every one is preventable in the weeks before submission, and almost none is comfortably fixable in the two days after.