How to prepare for a Cyber Essentials Plus assessment
By Muhammad Sohaib Roomi, founder and reviewer at BrightCertPublished Reviewed
Part of our What actually happens in a Cyber Essentials Plus audit
Short answer
Preparing for Cyber Essentials Plus is mostly making sure the things you claimed in the self-assessment are actually true on the devices the assessor will sample. Two of the constraints are time windows rather than settings: a fix available for more than 14 days and not applied is a fail, and unsupported software cannot be patched into a pass at all. So preparation is a calendar problem before it is a technical one — roughly four weeks, working backwards from the audit date.
Standard Cyber Essentials asks you to describe your controls accurately. Plus sends someone to check the description against a sample of real machines. Almost everything that goes wrong on the day lives in the gap between those two sentences — not in controls nobody had, but in controls that were true of most of the estate and quietly untrue of a handful of devices.
What preparation is actually for
It is tempting to prepare for Plus the way you prepared for the questionnaire: read the controls, confirm you meet them, book the date. That approach passes the self-assessment and then fails the audit, because the two ask different questions. The questionnaire asks whether you have a policy of applying updates within fourteen days. The audit picks up a laptop and looks.
The honest version of preparation is an internal dry run of the same five test cases the assessor will run. If you have not read them, the walkthrough of what actually happens in the audit sets them out in order. This article is the other half: what to do in the weeks before, and when each piece has to start.
It also assumes the underlying controls are in place. If they are not yet, start with what Cyber Essentials is and the requirements v3.3 guide, because Plus verifies those same five controls rather than adding new ones.
Why the preparation is a calendar and not a checklist
Most compliance preparation can be compressed if you throw a weekend at it. Two things here cannot, and they are what set the four-week shape.
The patching test measures elapsed time, not effort. A vulnerability fails if the vendor rates the fix critical or high, or it carries a CVSS v3 base score of 7.0 or above, or the vendor publishes no detail about what it fixes — and the fix has been available for more than 14 days. You cannot shorten that by patching harder. You can only make sure the fortnight before the audit is one in which every in-scope device was updated.
Unsupported software has no same-week answer. If a vendor no longer issues fixes, there is nothing to apply, so the device cannot pass. The remedies are replacement, upgrade, or removing it from scope — and each of those is a procurement or migration task measured in weeks. This is the single most common reason a Plus audit gets postponed, and finding it four weeks out is the difference between moving a licence and moving a date.
Everything else — accounts, credentials, availability, the scope list — is quick to do and easy to forget, which is why it sits in the week before rather than the month before.
A four-week countdown to the audit date
14 items, ordered by when the work has to start rather than by control area. The owner and status columns are deliberately blank: print the page, or copy it into whatever you already use, and fill them in. An item without a name against it is the one that does not happen.
Four weeks out
Everything here can force a purchase, a migration or a scope change. None of it can be fixed in the week before the audit, which is the only reason it sits this far out.
| Do this | Why the audit cares | Evidence to have | Owner | Status |
|---|---|---|---|---|
| Settle the scope boundary and write it down | Scope decides which devices, users and cloud services are eligible for sampling. The assessor tests against the boundary you declared, not the one you meant. | A dated scope description listing sites, device types, operating systems, cloud services and remote workers. | ||
| Find every piece of unsupported software | Software past its vendor support date cannot receive fixes, so it cannot pass the patching test. There is no compensating-control conversation available. | An inventory of operating systems and applications with each vendor's end-of-support date against it. | ||
| List the cloud services actually in use | Every in-scope cloud service is tested with at least one standard and one administrative account. Services nobody remembered are found during scoping or during the audit; one of those is cheaper. | A service list reconciled against expenses or card statements, not against memory. | ||
| Confirm MFA is on for everyone, not just administrators | The MFA test signs in as a standard user and as an administrator from an untrusted device, and watches for the prompt. A standard account without MFA fails it. | A per-service export showing enrolment across all accounts, including shared and service accounts. |
Two weeks out
This is when the patching window opens. A fix released more than fourteen days before the audit and not applied is a fail, so the fortnight before the date is the one that is actually assessed.
| Do this | Why the audit cares | Evidence to have | Owner | Status |
|---|---|---|---|---|
| Patch every in-scope device, including the ones nobody uses | The authenticated scan checks each sampled device for missing fixes rated critical or high by the vendor, scoring CVSS v3 7.0 or above, or shipped with no vendor detail at all. | A patch report per device with dates, covering laptops in drawers and machines belonging to people on leave. | ||
| Prove the update process reaches the whole estate | Since April 2026 a retest rechecks the original sample and a new random sample. A fix applied only to the devices that failed is the approach most likely to fail twice. | Coverage figures from the update tool: devices enrolled versus devices in scope, with the difference explained. | ||
| Check malware protection on the devices people really use | Inert test files are sent to a working mailbox and offered from a website while the assessor observes a normal user trying to open them. | Confirmation that protection is active, current and not disabled on any sampled device. | ||
| Agree the external IP addresses in scope | The remote vulnerability assessment scans the addresses you supply. A missing address is a gap; a wrong one wastes the slot. | A confirmed address list shared with the Certification Body ahead of the day. |
One week out
Three of the five test cases involve the assessor watching one of your staff. From here the constraint stops being technical and becomes a diary.
| Do this | Why the audit cares | Evidence to have | Owner | Status |
|---|---|---|---|---|
| Identify who is likely to be sampled, and check they are here | The malware and account-separation tests need the person who normally uses the device, signed in as themselves. An administrator standing in does not demonstrate what a standard user experiences. | Named people against sampled device types, with annual leave checked. | ||
| Tell those people what will be asked of them | They will be asked to open a file that their protection should block, while someone watches. It goes better when it is expected. | A short briefing note, sent in advance. | ||
| Prepare scan credentials for each sampled device | The patching test is a credentialed scan. Without a working login the device cannot be assessed. | Accounts created and tested on each device type in scope. | ||
| Finalise the verified self-assessment | As of the April 2026 update the self-assessment must be complete, verified and unchanged before Plus testing begins. Answers cannot be revised once the audit starts. | Confirmation from the Certification Body that the submission is locked. |
The day before
Short, and entirely about availability. Most audits that lose time lose it here rather than on a control.
| Do this | Why the audit cares | Evidence to have | Owner | Status |
|---|---|---|---|---|
| Switch on and connect every device in the sample | A device that is off or unreachable cannot be tested, and the slot is still consumed. | A confirmation from each device owner. | ||
| Check the standard and administrative accounts still work | Expired passwords and disabled test accounts are the most common avoidable delay on the day. | A successful sign-in on each in-scope cloud service, from an untrusted device. |
You cannot choose the sample, but you can shape it
The assessor tests a representative sample rather than every device, sized by a method IASME sets and verified against evidence the Certification Body has to retain. You do not pick which machines are tested, and offering a tidy one is not an option.
What you can influence is how large and awkward the sample has to be.
- Every operating system in scope must be represented. One person on an unusual setup pulls that setup into the sample. A standardised estate is sampled with fewer devices; a varied one cannot be.
- Cloud services are sampled by account. Each in-scope service needs a standard and an administrative user tested, so a forgotten subscription adds work rather than staying invisible.
- Scope honestly, once. Narrowing scope to make the audit easier is legitimate only if the boundary is real and defensible. Narrowing it on paper while the devices still handle organisational data is not a preparation tactic, it is a misdescription.
Because the sample follows the scope and the effort follows the sample, scope is also what drives the quote — covered in the cost guide.
Run the tests on yourself first
The most useful week of preparation is the one where you behave like the assessor. None of this needs specialist tooling, and all of it surfaces the gap between claimed and actual state while there is still time to close it.
- Pick your own awkward sample. Not the well-managed laptops. The oldest device, the one belonging to whoever joined most recently, and anything that has not connected to the network in a month.
- Check what is missing, per device. Look at what updates each one is short of and how long each fix has been public. Fourteen days is the line, and it is judged per device, not per fleet average.
- Sign in as a standard user. On every cloud service, from a browser that has never seen it. If no MFA prompt appears, you have found a fail before the assessor did.
- Try to install something as a normal user. Being stopped and asked for separate credentials is the pass. Succeeding quietly is the finding.
A structured version of the same idea, covering the underlying controls with owner and evidence columns, is in the Cyber Essentials checklist. If you have not yet completed the self-assessment stage, the guide to what the assessment questions ask for comes first — Plus verifies answers that already exist.
Booking the date, and the three-month clock
The Plus audit has to be completed within three months of your Cyber Essentials certification. Miss that and you repeat the self-assessment stage before you can book, which costs a month for reasons that have nothing to do with your security.
That constraint pushes in the opposite direction to everything above, and the two have to be reconciled deliberately. Booking early protects the three-month window; booking before unsupported software has been dealt with wastes the slot. The workable order is to find the hard stops first, then book a date far enough out that the fortnight before it can be a clean patching window.
Talk to the Certification Body about remote or on-site delivery at the same time. It affects scheduling and travel cost, but not difficulty — the same five test cases are run either way.
What preparation cannot do
No amount of preparation makes the audit a formality, and nobody outside an IASME-licensed Certification Body can carry it out or issue the certificate. The independence is the entire reason Plus is worth more than the self-assessment, and any service offering to shortcut it is offering something it cannot deliver.
What preparation genuinely buys is the absence of surprises: the gaps that would have failed the audit found while they are still cheap, and a date you are confident booking. BrightCert helps with that first part — finding the gaps across the same five control areas — and stops there.
Frequently asked questions
How long does it take to prepare for a Cyber Essentials Plus assessment?
Plan for about four weeks if your controls are already in reasonable shape. The technical checking is quick; what takes time is replacing unsupported software, enrolling every account in MFA rather than just administrators, and getting the right people free on the day. If preparation turns up unsupported software you still rely on, four weeks is optimistic.
When should we start patching before a Cyber Essentials Plus audit?
At least two weeks before, because the test is time-based rather than absolute. A vulnerability fails if the vendor rates the fix critical or high, or it scores CVSS v3 7.0 or above, or the vendor gives no detail — and the fix has been available for more than 14 days. Updating everything in the fortnight before the audit date is what puts you on the right side of that line.
What is the most common reason for failing Cyber Essentials Plus?
Missing updates on devices that are not in daily use, and unsupported software. The first is recoverable by patching and retesting. The second is not, because no fix exists to apply — the software has to be replaced, or the device removed from scope, before the audit rather than after it.
Do we need to prepare differently from standard Cyber Essentials?
Yes, and the difference is the point. Standard Cyber Essentials asks you to describe your controls accurately. Plus verifies the description on a sample of real machines. Preparation for Plus is therefore about closing the gap between what was claimed and what is true on the devices, which is a different exercise from answering the questions well.
Who needs to be available on the day of the assessment?
Whoever normally uses the devices in the sample, signed in with their own day-to-day account, plus someone holding a standard and an administrative account for each cloud service in scope. Three of the five test cases are the assessor observing a user attempt something, so availability is a real dependency rather than a courtesy.
Can we fix things during the Cyber Essentials Plus assessment?
No. The verified self-assessment is locked before testing begins, and remediation during a test case is not how the process works. If something fails you remediate afterwards and retest, and since April 2026 the retest covers the original sample plus a new random sample.
Does BrightCert prepare us for the Cyber Essentials Plus audit?
BrightCert finds gaps across the same five control areas the audit tests, so you can close them before booking an assessor. It does not carry out the audit and does not issue any certificate — both belong to an IASME-licensed Certification Body.
Find the gaps across the same five control areas a Plus audit tests, before you book an assessor and start the three-month clock.
Start your assessmentBrightCert helps UK businesses prepare for Cyber Essentials by assessing readiness, identifying gaps, and producing a practical report. BrightCert does not issue the official Cyber Essentials certificate. That comes from an IASME-licensed Certification Body.
Sources: NCSC: Cyber Essentials resources · NCSC: Cyber Essentials Plus test specification · IASME: Cyber Essentials · IASME: changes to Cyber Essentials for April 2026