Cyber Essentials Plus: A UK Business Guide to What the Technical Audit Actually Checks in 2026

A Cyber Essentials Plus audit is the point at which the claims in your self-assessment stop being claims. The base certification asks you to answer a question set about how your organisation is configured and takes those answers on trust, backed by a director’s sign-off. Cyber Essentials Plus sends a qualified assessor into your estate to check whether the answers were true — by scanning your internet-facing addresses from outside, running an authenticated vulnerability scan on a sample of your real end-user devices, attempting to land malware on them, and testing that multi-factor authentication and account separation actually work the way you said they do.

That single difference explains almost everything about how the two certifications behave in practice. Self-assessment failures are paperwork failures, discovered while you are still writing. Cyber Essentials Plus failures are engineering failures, discovered on the day, in front of someone with a clock running and a fixed three-month window in which the whole thing has to be finished. This guide starts with what the technical audit genuinely tests — test by test, in the order an assessor works through them — then covers how the external and internal vulnerability scans differ, how device sampling is actually calculated, what it costs in 2026, and the specific failures that stop UK businesses on the day. Every one of those failures is visible weeks in advance if you know where to look, which is the practical argument of everything that follows.

What Cyber Essentials Plus actually is — and where the audit sits

Cyber Essentials is the UK government-backed scheme owned by the National Cyber Security Centre and delivered by IASME as the sole Cyber Essentials Partner, through a network of licensed Certification Bodies. It defines five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. Those five controls are the whole scheme. There is no sixth control hiding in Plus, no additional policy requirement, and no extra documentation set. Cyber Essentials Plus certifies against exactly the same five controls as the base certification.

What changes is the evidence standard. For base Cyber Essentials you complete the current question set in the IASME portal, a board-level representative confirms the answers are accurate, and an assessor marks the submission. For Cyber Essentials Plus, an assessor carries out a hands-on technical verification against the published Cyber Essentials Plus Test Specification — a defined series of tests with defined pass conditions, run on a sample of your actual devices and accounts rather than on a description of them.

The sequencing matters and catches people out. You cannot start with Plus. You must hold a current base Cyber Essentials certificate first, and the Plus technical audit has to be completed within three months of the date on that base certificate. Miss the window and the base assessment has to be redone before Plus can proceed. That three-month clock is the single hardest constraint in the whole process, because it means remediation time is not open-ended: everything you discover during the audit has to be fixed and re-verified inside the remaining balance of those ninety days.

One further piece of context for 2026. IASME revises the question set and the underlying Requirements for IT Infrastructure document on an annual cycle, typically taking effect each April, with the current set carrying a name rather than just a number — Beacon, Evendine, Montpellier, Willow and their successors. The five controls have been stable across those revisions; the definitions inside them have not. Passwordless authentication, the treatment of bring-your-own devices, what counts as unsupported software and how cloud services are scoped have all been tightened or clarified between versions. Always confirm which question set is live on the day you apply rather than preparing against the one you certified under last year.

Cyber Essentials Plus in numbers — the audit at a glance

Before the detail, four figures that shape how the audit runs and how much preparation it needs. They are the numbers that most often surprise organisations coming from base certification, where none of them apply.

The fourteen-day patching rule deserves particular attention because it is the requirement that fails most often and the one that self-assessment is least able to detect. On the questionnaire it is a yes-or-no answer about your patching policy. On the audit it is an authenticated scan that enumerates every installed package on a sampled device and checks each one against a vulnerability feed. A policy that says fourteen days and a fleet that averages twenty-one produce the same self-assessment answer and opposite audit outcomes.

The three-month window is the constraint that turns preparation into a scheduling problem rather than a technical one. If you certify at base level in January and book the Plus audit for late March, you have left yourself days rather than weeks to remediate anything the assessor finds. The organisations that pass comfortably book the audit for roughly six to eight weeks after the base certificate, which leaves genuine room to fix, re-scan and still land inside the window.

Cyber Essentials vs Cyber Essentials Plus — what changes when an assessor verifies

The two certifications are frequently described as tiers, which is only half right. They certify against the same five controls to the same standard. What separates them is who checks, how, and what happens to an answer that is optimistic rather than accurate. Reading the two side by side is the quickest way to understand why an organisation can hold base certification comfortably for three years and then fail Plus at the first attempt.

The row that carries the most weight in practice is the failure mode. On self-assessment, an uncomfortable answer can be softened. There is no dishonesty required — the questions ask what your organisation does, and the honest answer for most estates is “mostly, with exceptions we are working through”. That answer does not exist on the questionnaire, so it becomes a yes. On Plus, that same estate produces a scan report listing the exceptions by hostname, package name and CVE reference.

The second row worth dwelling on is the procurement one. A growing number of UK tenders, particularly in central government, local authority and NHS supply chains, now specify Plus rather than base certification precisely because they understand the difference in evidence standard. If your sales pipeline is trending towards public sector or enterprise customers with mature supplier assurance, base certification increasingly gets you to the questionnaire stage and no further. The same dynamic drives the wider assurance stack — see our guide to penetration testing frequency for UK businesses for where testing sits alongside certification, because the two are routinely and incorrectly treated as substitutes.

What actually fails on the day — the most common CE Plus stoppers

Cyber Essentials Plus does not usually fail organisations that are careless about security. It fails organisations that are careful about security and have one or two blind spots in the specific places the test specification looks. The chart below shows the pattern we see most often in UK SME audits — the share of assessments where each issue was a contributing cause of a failed or deferred result. These are our observed frequencies across engagements rather than published scheme statistics, but the ranking is remarkably consistent.

Two things stand out. The first is that the top two bars are the same problem wearing different clothes. Operating system patching is usually well managed because it is automated, visible and reported on. Third-party application patching is usually managed by exception, because the tooling that handles Windows Update or Intune update rings does not necessarily reach a PDF reader installed by a user four years ago, a bundled Java runtime for a line-of-business application, or a browser that stopped auto-updating because its updater service was disabled. The authenticated internal scan enumerates all of it.

The second is that the bars towards the bottom — account separation, malware protection, scope — are configuration decisions rather than maintenance failures. They do not degrade over time; they were wrong from the day the estate was built and nobody had a reason to look. That makes them cheap to fix once identified and expensive to discover on audit day, which is precisely the argument for running your own dry run first.

Continuous visibility of the estate is what turns the top two bars from an audit-week scramble into routine housekeeping. If you are not already collecting patch state centrally, our guide to proactive network monitoring for UK businesses covers the tooling layer that makes this measurable rather than anecdotal.

Inside the audit — the tests an assessor actually runs

The Cyber Essentials Plus Test Specification sets out a defined series of tests with defined pass conditions. Certification Bodies may vary the tooling and the running order, and IASME revises the specification with each annual question set, but the shape below is what an audit looks like in practice and it is the level of detail you should prepare against.

Test 1 — Remote vulnerability assessment of the external attack surface

An unauthenticated scan is run from outside your network against every internet-facing IP address in scope. That means the office public IP, any hosted infrastructure, VPN concentrators, remote access gateways, mail gateways and anything else your declaration lists as an external address. The assessor is looking for services reachable from the internet that should not be, and for vulnerabilities in the ones that should. The pass condition is the one to internalise: any vulnerability with a CVSS v3 base score of 7.0 or above for which the vendor has published a fix, where that fix has been available for more than fourteen days, is a failure. There is no partial credit and no risk-acceptance route.

The practical trap here is address inventory rather than vulnerability management. Organisations declare the addresses they remember. Reconnaissance finds a legacy remote-desktop gateway from a pre-pandemic remote working arrangement, a supplier-managed appliance with a management interface exposed, or a second broadband line at a branch office that nobody associated with the corporate estate. Anything reachable that is in scope counts, whether or not you declared it.

Test 2 — Authenticated vulnerability scan of sampled end-user devices

This is the test that generates the most findings. The assessor runs a credentialed scan against a sample of workstations, laptops and servers — logging in with sufficient privilege to enumerate the installed software inventory, patch level and configuration rather than inferring it from the network. The scan lists every installed package with a version number and compares each against a vulnerability feed.

The distinction between authenticated and unauthenticated scanning is the whole reason this test exists. An unauthenticated scan of a laptop behind a firewall finds almost nothing, because almost nothing is listening. An authenticated scan of the same laptop finds the out-of-date PDF reader, the browser two major versions behind, the developer runtime installed for a project that finished in 2023 and the media player nobody has opened since it was bundled with the build image. Same fourteen-day rule, same CVSS 7.0 threshold, applied to every one of them.

Test 3 — Malware protection: the email test

The assessor sends a series of test files to a mailbox belonging to a sampled user, using benign, industry-standard proxies for malware rather than live malicious code. A user then attempts to open each attachment on the sampled device with the assessor watching. The pass condition is that the device or the mail platform prevents the file from executing — whether that is the gateway stripping it, the endpoint protection quarantining it, or application allow-listing refusing to run it. The mechanism is your choice; the outcome is not.

Test 4 — Malware protection: the web download test

The same principle applied to a browser. The user is asked to download a set of test files from a web location and attempt to run them. Again, blocking at any layer counts — web filtering, browser protection, endpoint anti-malware, or allow-listing. What fails is a file that downloads to disk and executes without challenge. This test catches estates where anti-malware is deployed but has been excluded from the user profile directory, or where a real-time protection component was disabled during a troubleshooting session eighteen months ago and never re-enabled.

Test 5 — Multi-factor authentication on cloud services

The assessor verifies that MFA is enforced on the cloud services in scope, for administrative accounts and standard user accounts alike. This is a live test, not a screenshot of a policy: a sampled account is used to authenticate and the second factor must be demanded. Where a conditional access policy grants exclusions — a trusted location bypass, a legacy authentication allowance, a break-glass account, a service account with a static credential — those exclusions are examined and generally have to be justified or removed.

Test 6 — Account separation and privilege

The assessor checks that administrative accounts are used for administrative work only. A day-to-day account that also holds local administrator rights, or a domain admin account that receives email and browses the web, fails the user access control requirement. The requirement is separation: a standard account for normal work, a distinct elevated account used only for administrative tasks, and no routine internet or email exposure on the elevated one. The check also looks at how accounts are created, reviewed and removed, and whether the sampled devices grant local administrator rights to standard users.

Alongside these, the assessor confirms that no unsupported software remains installed on sampled devices — an operating system, browser, database engine or application past its vendor end-of-life date is an automatic finding unless it has been removed from scope by demonstrable network segregation.

External scan vs internal scan — two different questions

Organisations preparing for their first Cyber Essentials Plus audit often treat the two scans as one activity done twice. They are not. They answer different questions, produce different findings and require different preparation, and the internal scan is the one that generates the workload.

The external scan asks: what can an unauthenticated attacker on the internet see and reach? It is unauthenticated by definition, run from outside, and its findings cluster around exposed management interfaces, out-of-date perimeter appliance firmware, TLS configuration and services that were opened for a legitimate reason and never closed. The remediation is usually a firewall rule change or a firmware update, and it usually affects a handful of addresses. Scope accuracy is the hard part, not fixing what is found.

The internal scan asks: if an attacker were already executing code on a user’s laptop, what would they find to exploit? It is authenticated, run against sampled devices, and its findings cluster around third-party application patching across the whole software inventory. The remediation is a patching exercise across a fleet, and it can easily affect every device in scope. This is why the internal scan generates the bulk of the work and why it deserves the bulk of your preparation time.

The practical consequence for planning is a sequencing rule. Run your own authenticated scan against a representative device at least four weeks before the audit, using whatever your endpoint management platform provides. The list it returns is a close approximation of what the assessor will find, and every item on it is fixable in advance for the cost of the remediation work alone. The external scan can be dry-run in an afternoon; the internal scan drives your entire preparation calendar.

Device sampling — how the assessor decides what to look at

A Cyber Essentials Plus audit does not examine every device you own. It examines a sample, and understanding how that sample is constructed is what stops organisations from preparing the wrong machines.

Sampling is built around device build types, not headcount. The assessor identifies each distinct combination of operating system and platform in scope — Windows 11 laptops, macOS laptops, a Windows Server estate, Android handsets, iOS handsets, any Linux workstations — and draws a sample from each one independently. A 200-person organisation running a single standardised Windows 11 image and one iOS handset build has two build types to sample. A 30-person organisation running three Windows versions, a mixed Mac fleet, two Android generations and some legacy kit can easily have more sampled devices than the larger business, despite being a fraction of the size.

Within each build type the sample size scales with the number of devices of that type, subject to a published minimum. IASME sets out the exact sample sizes in the current test specification and revises them with the question set, so take the numbers from that document rather than from a summary. The principle that holds across versions is straightforward: more build types means more sampling, and one poorly maintained device in a sampled build type fails the whole build type.

Three consequences follow, and all three are worth acting on months before you book:

• Standardisation is the cheapest audit preparation there is. Every build type you eliminate removes a sample, removes a set of findings and removes a patching workflow you would otherwise have to maintain. Consolidating a mixed estate onto one or two managed images does more for your pass probability than any amount of pre-audit remediation.
• The sample is drawn by the assessor, not by you. You supply the device inventory; the assessor selects from it. Preparing three known-good machines and hoping they are chosen is not a strategy, and an inventory that omits devices to keep the sample small is a scope declaration problem with consequences well beyond a failed audit.
• Mobile devices and BYOD are in scope when they access organisational data. A personally owned phone with the corporate mailbox on it is in scope. A device used solely as a second authentication factor — receiving a code, approving a push — or only for voice calls and SMS, is not. That boundary decides whether you need a mobile device management story before the audit or not, and it is worth settling early because retrofitting MDM to personal handsets is a slow, consent-driven exercise.

Pre-audit readiness scoring — where UK businesses usually sit

The grid below is a self-scoring instrument built directly from the test specification. Work through it honestly against your own estate before you book, marking each row as it genuinely stands today rather than as your policy describes it. The badges show where a typical UK SME sits when we first assess them — the pattern is consistent enough to be useful as a benchmark, and the rows marked high risk are the ones that most often produce an audit-day finding.

The row that quietly causes the most trouble is the last one on the third card. Build-type sprawl is not a security failing in itself and no framework penalises it directly, but it multiplies every other row on the grid. Each additional build type is another patching workflow, another anti-malware configuration, another sample the assessor will draw, and another chance that one neglected machine takes down the result for its whole category.

The second is conditional access exclusions. Almost every Microsoft 365 tenant of any age has them: a trusted-location bypass added during an office move, a legacy authentication allowance kept alive for an old scanner or line-of-business integration, a service principal with a static secret. Each was reasonable when it was created. Collectively they are the gap between “MFA is enforced” on the questionnaire and a failed live test. Our guide to Microsoft 365 data security for UK organisations covers how these tenant-level settings interact more broadly.

What Cyber Essentials Plus costs in 2026

There are two separate fees and they are set by different parties. The base Cyber Essentials certification fee is set centrally by IASME and banded by organisation size, so it is predictable and comparable between Certification Bodies. The Cyber Essentials Plus audit fee is set by the individual Certification Body, is driven by scope and effort, and varies considerably. The table below gives indicative 2026 ranges — confirm current figures with IASME and your chosen Certification Body, as the bands are reviewed annually.

The column that people underestimate is remediation effort, and it is usually the largest line. The audit fee buys you an assessment. It does not buy you a patched fleet, an MFA rollout, an admin account separation exercise or the removal of unsupported software from forty machines. On a first certification for an estate that has never been through this, remediation routinely costs more than both certification fees combined.

The bottom row is worth pricing honestly. A failed first attempt is not expensive in re-test fees. It is expensive because Cyber Essentials Plus is usually being pursued to satisfy a contractual or tender deadline, and the three-month window leaves very little room to absorb a failure and a remediation cycle. When organisations describe a failed audit as costly, the cost they are describing is almost always commercial rather than technical.

One further budgeting note: costs fall sharply in year two. The estate has been standardised, patching is instrumented, MFA is universal and the unsupported software is gone. Recertification is largely the audit fee plus a modest verification exercise, which is why the first-year figure should be read as an investment in the estate rather than an annual compliance charge.

The readiness gauge — scoring your estate before you book

Score yourself out of 100 across five equally weighted dimensions: patch currency across the full software inventory, MFA coverage including administrative accounts, account separation and privilege hygiene, scope and inventory accuracy, and evidence — whether you can produce a report rather than an opinion. The gauge shows the median score we see when a UK mid-market organisation asks for a readiness assessment before its first Cyber Essentials Plus audit.

Fifty-eight is a well-run IT estate that has not yet been measured against this particular specification. It is not a warning sign about the organisation’s security posture; it is a statement about the gap between managing security sensibly and evidencing it against a defined test. The dimensions that drag the score down are almost always the same two: third-party patch currency and evidence.

Evidence is the one people find counter-intuitive. An organisation can be genuinely compliant on every control and still struggle on the day because nobody can produce the artefact that demonstrates it — a current device inventory, a patch compliance report covering the last thirty days, a list of every cloud service in use with its MFA status, a conditional access policy export with the exclusions annotated. None of that is difficult to produce. It is simply never produced until somebody asks.

A score above 80 means the audit should be a verification exercise rather than a discovery exercise, and that is the target. Getting from the high fifties to the low eighties is typically six to eight weeks of focused work for an SME: instrument third-party patching, close the MFA gaps, split the administrative accounts, remove the unsupported software, reconcile the inventory, and generate the four or five reports that constitute your evidence pack. None of it is technically hard. All of it takes longer than the fortnight most organisations allow.

The eight-week run-up — a realistic CE Plus preparation timeline

The timeline below assumes an organisation holding a current base Cyber Essentials certificate that wants to pass Plus first time, and it works backwards from the three-month window. The heavy lifting sits in weeks two to five, which is exactly where organisations that book late do not have any calendar left.

The reserve at the end is the part to protect when the schedule slips. Organisations under commercial pressure compress weeks two to five and keep the audit date, which is precisely backwards: the preparation is what determines the outcome, and the audit date is the flexible element right up until it collides with the three-month boundary. If something has to give, move the audit and keep the dry-run scan.

What the internal scan typically finds — compliance by category

When we run a dry-run authenticated scan across a UK SME estate that has not previously been through Cyber Essentials Plus, the results distribute in a fairly predictable way. The bars below show the proportion of sampled devices that pass each category cleanly on a first scan. Read them as a preparation priority list rather than a scoreboard.

The shape of that distribution tells the whole story of Cyber Essentials Plus preparation. The top four categories are things that modern endpoint management does automatically and does well — they are near-solved problems in any professionally managed estate. The bottom four are things that require somebody to have made a decision about software that arrived on the device outside the standard build, and in most organisations nobody ever has.

The final bar is the one the assessor is actually measuring, and it is the intersection of all the others. A device passes the internal scan only when its entire software inventory is clean at the CVSS 7.0 threshold, so a single unpatched utility takes the device down regardless of how well the operating system is managed. This is why the fourteen-day rule has to be applied to the whole inventory rather than to the parts your patching tool happens to reach.

The runtimes and developer tooling bar is the classic long tail. Java runtimes bundled with an accounting package, a Python installation from a data project, an old .NET framework version, a database client installed for a migration that finished years ago. None of it is in use. All of it is installed, versioned and visible to an authenticated scan. Removal is almost always the right answer and is faster than patching it.

First-time pass rates and what separates the two groups

Not every organisation that books a Cyber Essentials Plus audit passes at the first attempt without remediation on the day. The proportion that does is smaller than most people assume, and the factor that predicts it is not the size or sophistication of the IT function.

The other sixty-three per cent do not fail permanently — most certify within the three-month window after a remediation cycle. But they spend money and calendar they did not budget for, and a meaningful minority run out of window and have to redo the base assessment first.

The single variable that separates the two groups is whether a dry-run authenticated scan was performed in advance. It is not team size, budget, sector or whether the estate is managed in-house or by a provider. Organisations that scanned themselves first knew what the assessor would find, fixed it, and treated the audit as verification. Organisations that did not treated the audit as discovery, and discovery on a deadline is expensive.

The second differentiator is who owns the scope declaration. Where scope was written by someone with a complete view of the estate — including the branch office broadband, the departmental SaaS subscriptions bought on a card, and the directors’ personal phones with the corporate mailbox on them — the audit runs cleanly. Where scope was assembled from memory in the week before the audit, the assessor finds the omissions.

A worked example — a 62-person Leeds engineering consultancy

A professional services firm in Leeds with 62 staff across one main office and two small satellite sites needed Cyber Essentials Plus to stay on a framework that had moved from base certification to Plus at renewal. They held base certification, had held it for three years, and had a competent two-person internal IT team with an external provider for infrastructure. On paper they were in good shape.

Their first attempt failed on the day. The external scan was clean. The internal authenticated scan sampled four devices across three build types — a standardised Windows 11 laptop image, a small group of older Windows laptops in the drawing office that had never been re-imaged, and two Macs used by the design team. The standardised image passed. The drawing office laptops carried an out-of-date PDF reader, a CAD viewer three versions behind and a Java runtime that had not been touched since installation. The Macs had no third-party patching mechanism at all because the endpoint management platform had been configured for Windows only. Separately, the MFA test found that two administrative accounts were excluded from the conditional access policy under a trusted-location rule created during an office move eighteen months earlier.

None of that was a security programme failure. It was three build types where the organisation believed it had one, plus an exclusion that had outlived its reason. The remediation took eleven working days: consolidate the drawing office onto the standard image, extend third-party patch management to macOS, remove the unused runtimes, delete the trusted-location exclusion and re-enrol the two administrative accounts. They re-tested inside the window and certified.

We thought we were being audited on our security. We were actually being audited on our inventory. Every single finding was on a device or an account we had stopped thinking about — nothing on the kit we manage day to day. The second time round we scanned ourselves first and the audit took an afternoon.

The pattern generalises. Cyber Essentials Plus findings cluster in the parts of the estate that fell outside the standard management process, not in the parts that are managed badly. The drawing office laptops were not neglected through carelessness; they were exceptions granted for a legitimate software compatibility reason years earlier, and exceptions do not appear on compliance dashboards. The same principle applies to recovery capability, where the gap between a documented process and a verified one behaves identically — our guide to backup and restore testing for UK businesses covers that parallel in detail.

The Cyber Essentials Plus audit checklist — 12 points to clear before the assessor connects

Work through this in the order given. Each item maps to a specific test in the specification, and each one is verifiable by you in advance without an assessor present.

1. Confirm the base certificate date and the window. Write the three-month expiry date at the top of the project plan. Every subsequent decision is constrained by it, and it is the one deadline that cannot be negotiated.
2. Produce a single reconciled device inventory. Merge the endpoint management export, the asset register and the identity platform sign-in list. Investigate every device that appears on one list and not the others — those are your findings in waiting.
3. Enumerate every distinct build type. Operating system and platform combination, not manufacturer. Each one is a separate sample. Reduce the count wherever you can before booking, because every build type you eliminate removes an entire class of risk.
4. List every internet-facing IP address in scope. Head office, every branch line, hosted infrastructure, VPN and remote access endpoints, mail and web gateways, supplier-managed appliances. Verify from outside rather than from the firewall configuration.
5. Run an authenticated vulnerability scan on one device per build type. Triage everything at CVSS v3 7.0 and above with an available vendor fix. This is the single most predictive activity in the whole preparation.
6. Bring third-party applications onto the fourteen-day clock. Browsers, PDF readers, office plug-ins, runtimes, media players, line-of-business clients. If your management platform cannot patch it, either replace the application or add a mechanism that can.
7. Identify and eliminate unsupported software. Anything past vendor end-of-life — operating systems, browsers, database engines, applications. Remove it, upgrade it, or segregate it out of scope with demonstrable network controls. There is no risk-acceptance route.
8. Enforce MFA on every account on every cloud service. Standard users, administrators, break-glass accounts and anything with a static credential. Then export the conditional access policies and account for every single exclusion in writing.
9. Separate administrative accounts from day-to-day accounts. No elevated account should receive email or browse the web, and no standard user should hold local administrator rights. Give the IT team a workable elevation process at the same time.
10. Verify malware protection end to end. Send benign test files to a mailbox and download a set through a browser on each build type. Confirm blocking actually occurs, and check that no exclusion covers user profile or downloads directories.
11. Declare every cloud service in use. Including the departmental SaaS subscriptions bought on a card that IT never sanctioned. Undeclared services are a scope failure, and they are easy to find in expense records and identity platform sign-in logs.
12. Assemble the evidence pack and re-scan. Device inventory, patch compliance report, cloud service list with MFA status, conditional access export, network diagram, scope statement. Then re-run the scans to confirm findings are genuinely closed rather than marked closed.

Common Cyber Essentials Plus mistakes to avoid

These are the errors we see repeatedly — not obscure technicalities, but reasonable-sounding decisions that produce audit findings.

• Booking the audit for the end of the three-month window. It looks like maximum preparation time and is actually minimum remediation time. Book for week eight and keep the remaining weeks as reserve, because the reserve is what converts a finding into a fix rather than a failure.
• Assuming base certification predicts the Plus result. Three years of clean self-assessments say nothing about how the estate will scan, because no scan has ever been run against it. The two certifications measure the same controls with entirely different instruments.
• Treating the internal scan as an internal network scan. It is an authenticated scan of the device’s software inventory, not a scan of your LAN. Firewalls, segmentation and network hardening do nothing to improve the result, which surprises organisations that have invested heavily in exactly those things.
• Patching the operating system and calling it patch management. The fourteen-day rule applies to every piece of software on the device. In most estates the operating system is the best-managed component and everything else is unmanaged, which is precisely inverted relative to where the findings land.
• Leaving conditional access exclusions in place because they were justified once. Trusted-location bypasses, legacy authentication allowances and unprotected service accounts each had a reason when they were created. The audit tests the current state, not the original rationale, and it tests it live rather than reading the policy.
• Understating scope to reduce the sample. Omitting the satellite office, the directors’ phones or the departmental SaaS subscription makes the audit smaller and the declaration false. Assessors reconcile the declaration against what they observe, and a scope discrepancy is a more serious finding than a missing patch.
• Segregating unsupported software without real network controls. Sub-scoping an end-of-life system out of the assessment is legitimate, but the segregation has to be demonstrable at the network layer. A VLAN with a permissive rule between it and the main estate is not segregation, and an organisational agreement that nobody will connect to it certainly is not.
• Confusing Cyber Essentials Plus with a penetration test. Plus verifies five defined controls against defined pass conditions. It does not attempt to compromise your systems, test your applications for logic flaws, or model an adversary. Offering the certificate in answer to a customer’s penetration testing question is a common procurement error.

Cyber Essentials Plus at a glance — the summary table

Everything above, condensed to the facts you are most likely to need when briefing a board, scoping a project or answering a supplier questionnaire.

How Cloudswitched supports Cyber Essentials Plus

Cloudswitched works with UK businesses on both sides of the audit: the readiness assessment that establishes where an estate genuinely stands against the test specification, and the remediation programme that closes the gap before an assessor arrives. That typically means running the dry-run authenticated and external scans, reconciling the device inventory and scope declaration, instrumenting third-party patch management so the fourteen-day rule applies to the whole software inventory rather than the operating system alone, clearing MFA and conditional access exclusions, and separating administrative identities. We can also coordinate with your chosen Certification Body so the audit lands with enough of the three-month window left in reserve to absorb anything unexpected.

Frequently Asked Questions

What does the Cyber Essentials Plus technical audit actually check?

It verifies the same five controls as base Cyber Essentials, but by testing rather than asking. An assessor runs an unauthenticated vulnerability scan against your internet-facing addresses, an authenticated scan of the full software inventory on a sample of devices, an email attachment test and a web download test using benign test files, a live check that multi-factor authentication is enforced on in-scope cloud services, and a review of account separation and privilege. It also confirms no unsupported software remains on sampled devices. The pass conditions are published in the Cyber Essentials Plus Test Specification, which your Certification Body will supply on request.

How is Cyber Essentials Plus different from Cyber Essentials?

The requirements are identical — the same five technical controls, assessed to the same standard. What differs is the evidence. Base certification is a self-assessment questionnaire signed off by a board-level representative and reviewed by an assessor. Plus is a hands-on technical audit of the live estate carried out by a qualified assessor. In practice this means base certification can be achieved by an organisation whose answers are optimistic, while Plus produces findings by hostname, package name and CVE reference. You must hold current base certification before Plus, and the Plus audit must complete within three months of the base certificate date.

How long does a Cyber Essentials Plus audit take?

The assessment itself typically runs from half a day to three days depending on the number of build types sampled, the size of the external address range and whether it is conducted remotely or on site. A single-site SME with one standardised device image is usually a one-day exercise. The preparation is the longer part — six to eight weeks is realistic for a first certification on an estate that has never been scanned against the specification, with the bulk of that time spent on third-party patching and inventory reconciliation rather than on the audit itself.

What happens if you fail Cyber Essentials Plus on the day?

A failure is not final. You remediate the findings and are re-tested, and most organisations certify successfully on the second pass. The constraint is the three-month window from the base certificate date: remediation and re-testing have to complete inside it. If the window expires, the base assessment must be redone before Plus can proceed. Certification Body policies on re-test fees and timescales vary, so ask about them before you book rather than after a finding. This is the main reason to schedule the audit around week eight rather than at the end of the window.

What is the difference between the internal scan and the external scan?

The external scan is unauthenticated and run from the internet against your in-scope public IP addresses, looking for exposed services and vulnerable perimeter systems. The internal scan is authenticated and run against sampled end-user devices, enumerating every installed application and comparing each against a vulnerability feed. They answer different questions: the external scan asks what an attacker can reach from outside, the internal scan asks what an attacker would find to exploit once code is running on a laptop. The internal scan generates the large majority of findings, because it sees the whole software inventory rather than just what is listening on the network.

How many devices will the assessor test?

A sample rather than the whole estate, drawn separately from each distinct operating system and platform build type in scope. The sample size per build type scales with the number of devices of that type, subject to a published minimum — the exact figures sit in the current test specification and are revised with each annual question set. The practical implication is that build-type count drives the sample far more than headcount does. A thirty-person business with six different builds can face more sampled devices than a two-hundred-person business running one standardised image.

Is Cyber Essentials Plus the same as a penetration test?

No, and conflating the two causes real procurement problems. Cyber Essentials Plus verifies five defined controls against defined pass conditions using vulnerability scanning and functional tests. A penetration test is a human-led attempt to compromise a defined scope using the techniques a real attacker would use, including application logic flaws, chained exploitation and social engineering where in scope. Plus tells a customer that your baseline controls were independently verified. It does not tell them your application is resistant to attack, and offering the certificate in answer to a penetration testing question is a common and avoidable error.

Are personal phones and BYOD devices in scope for Cyber Essentials Plus?

A personally owned device is in scope when it accesses organisational data or services — a corporate mailbox on a personal phone brings that phone into scope. Devices used solely as a second authentication factor, receiving a code or approving a push notification, are out of scope, as are devices used only for voice calls and SMS. Settle this boundary early in preparation, because bringing personal handsets under management is a consent-driven process that takes weeks, not days, and it is a poor thing to discover in the fortnight before an audit.

What does the 14-day patching rule mean in practice?

Any security update that fixes a vulnerability rated critical or high by the vendor, or carrying a CVSS v3 base score of 7.0 or above, must be applied within fourteen days of the vendor releasing it. The rule applies to everything installed on an in-scope device — operating system, browsers, email clients, document readers, plug-ins, runtimes and line-of-business applications — and to firmware on in-scope network equipment. It is the requirement that fails most often, almost always because third-party applications sit outside whatever mechanism keeps the operating system current.

Do we need Cyber Essentials Plus, or is base certification enough?

It depends on what your contracts and customers require. Base certification satisfies many UK government contracts and a good deal of supplier assurance. Plus is increasingly specified where personal or sensitive data is handled, and appears more often in central government, local authority and NHS supply chains as buyers come to understand the difference in evidence standard. If your pipeline is trending towards public sector or enterprise customers with mature assurance processes, Plus is worth planning for before a tender forces the timetable rather than after.

How much should we budget for Cyber Essentials Plus?

Budget three separate lines. The base certification fee is set by IASME and banded by organisation size, indicatively £320 to £700 excluding VAT. The Plus audit fee is set by your Certification Body and driven by scope, typically £1,200 to £3,500 for an SME and more for multi-site estates. The third line is remediation, which is usually the largest on a first certification and is the one most often omitted from the budget. Costs fall substantially at recertification, because the estate work has already been done.

How often does Cyber Essentials Plus need renewing?

Annually. The certificate is valid for twelve months, and each cycle requires base certification to be achieved again before the Plus audit, with the same three-month window between them. Treat it as a yearly programme rather than a one-off project: the estate keeps changing, new software arrives, new cloud services are adopted and exclusions accumulate. Organisations that maintain patch instrumentation and inventory discipline between cycles find recertification straightforward; those that let it drift repeat the first-year experience each time.

Related reading

Further guides covering the assurance, security and infrastructure work that sits alongside Cyber Essentials Plus certification.

• Penetration Testing Frequency: A UK Business Guide — where testing sits relative to certification, and why the two are not interchangeable
• Microsoft 365 Copilot Data Security: A UK Guide — tenant-level identity, access and data controls that the MFA test touches directly
• Network Monitoring for UK Businesses: A Proactive Guide — the visibility layer that turns patch compliance into a report rather than an assumption
• Backup and Restore Testing: A UK Business Guide — the same verification principle applied to recovery capability
• Building an IT Roadmap: A UK Business Guide — how certification cycles fit into a multi-year technology plan