Why year two catches people out

Fast Cyber Essentials › Recertification

Cyber Essentials lasts twelve months. What happens at the end of it is not a renewal, it is a fresh assessment against whatever the question set says at that point. That distinction is the source of most of the surprise.

The two things that break

1. Something went end of life while you were not looking

This is the most common cause of a second-year failure and it is entirely foreseeable. An operating system, a browser, a database, a phone model, a line-of-business application: something in your estate stopped being supported partway through the year, and unsupported software is an automatic fail.

The fix is a diary entry rather than a project. Once a quarter, list what is in scope and check the vendor support dates. Anything falling out of support in the next six months goes on a plan. Fifteen minutes, four times a year, removes the single biggest recertification risk.

2. The question set changed

The scheme is revised periodically and requirements tighten. What passed last year does not automatically pass this year. Recent revisions have touched password policy, the treatment of cloud services, and what counts as acceptable malware protection.

Read the current requirements before you start answering, rather than working from last year's answers. Reusing an old submission wholesale is the fastest way to fail on something that was compliant when you wrote it.

The thing that breaks quietly: growth

A scope that made sense at fifteen people rarely survives to forty without revision. New offices, new cloud services, an acquisition, a team that started using something nobody told IT about.

Before recertifying, redo the inventory properly. In particular, list every cloud service currently in use and compare it with last year's list. The gap is usually several services, and each one needs multi-factor authentication across every user.

What makes year two easy

Organisations that find recertification trivial did one thing differently the first time: they fixed things properly rather than working around the question.

If you passed year one by excluding an awkward system from scope, that system is still there and the same conversation happens again. If you passed by segregating it properly, or replacing it, the problem is gone permanently. The first approach costs less once. The second costs less by year three.

A recertification timeline that works

Working backwards from the expiry date

When	What to do
Three months before	Inventory refresh: devices, cloud services, people. Check vendor support dates for everything in scope.
Two months before	Read the current question set. Identify anything that has changed since your last submission.
Six weeks before	Remediate whatever the first two steps found. This is the part that takes time.
Three weeks before	Complete and submit the assessment.
Expiry	New certificate in hand, with no gap in coverage.

The gap matters more than people think. If your certificate lapses for six weeks and a client checks the register in that window, you are non-certified on the day they looked, regardless of what happened before or after.

Recertification and Cyber Essentials Plus

If you hold Plus, both run on the same twelve-month cycle and the Plus audit needs a valid Cyber Essentials certificate less than three months old. That compresses your timeline: the Cyber Essentials has to be done first, then the Plus audit booked inside that three-month window, and Plus audits need scheduling.

Work backwards from the Plus expiry date, not the Cyber Essentials one, and book the audit slot early.

Can you change assessor at renewal?

Yes, freely. You are not tied to whoever certified you last year, and there is no continuity requirement. If your previous assessor was a broker rather than a certification body, or the process was opaque, renewal is the natural point to move.

What to take with you: your scope statement, last year's submission for reference, and any feedback you received. A new assessor working from those can tell you quickly whether anything looks likely to fail this time.

Building an annual cycle that runs itself

The organisations that find recertification trivial are not doing more work, they are doing it in smaller pieces at predictable times. Four diary entries replace the annual scramble.

A quarterly rhythm

When	Fifteen minutes on	Why then
Q1	Vendor support dates for everything in scope. Anything going end of life within twelve months goes on a plan.	Gives you three quarters to deal with it rather than three weeks.
Q2	Cloud service inventory. What has been adopted since last time, and does it have MFA.	Catches the service a department started using in January.
Q3	Local administrator group membership and leaver accounts.	The two things that drift quietly and fail assessments.
Q4	Read the current question set. Note anything that has changed.	Two months before recertification, while there is still time to act.

An hour a year, spread across four sittings, and recertification becomes a form-filling exercise rather than a project.

Keep last year's submission, and read it

Not to copy, but to compare. The useful exercise at recertification is reading last year's answers and asking, for each one, whether it is still true. That question surfaces changes that nobody flagged: the new office, the acquisition, the team that moved to a different tool, the supplier who now has remote access.

It also surfaces answers that were optimistic the first time. An answer given generously last year and repeated this year is a risk that has been carried for two years, and recertification is the natural moment to fix it rather than repeat it.

If your certificate is about to lapse and you are not ready

Certify late rather than certify inaccurately. A gap of a few weeks on the register is a question you can answer. A certificate obtained on answers that do not reflect your estate is a problem that surfaces at a Plus audit, at a customer security review, or after an incident, and none of those are good moments.