What an IASME-accredited Cyber Essentials Plus Assessor Actually Checks

Net Sec Group is an IASME and NCSC certification body. We have run more than 800 Cyber Essentials and Cyber Essentials Plus assessments. The scheme documentation tells you what the controls are. This article tells you what the assessor on the day actually looks at, what evidence passes, what evidence fails, and where the debate happens.

If you are scoping a Cyber Essentials Plus engagement, preparing for one, or trying to work out whether your current security posture would survive the audit, this is the per-control breakdown you cannot get from reading the scheme.

The five controls in plain terms

The Cyber Essentials Plus assessment is run by an independent IASME-accredited Certification Body against the five controls defined in the IASME Cyber Essentials Plus test specification:

1. Firewalls and Internet Gateways
2. Secure Configuration
3. User Access Control
4. Malware Protection
5. Security Update Management

Cyber Essentials Plus differs from Cyber Essentials Basic in one practical respect: the assessor verifies the controls technically, on a sampled subset of devices, with their own tooling, in real time. Basic accepts your verified self-assessment answers. Plus tests them.

The certificate is valid 12 months. The assessment runs end-to-end in 3 to 5 working days for a small or mid-sized firm, less if pre-prep is in place. We routinely turn engagements around in a single working week.

Firewalls and Internet Gateways

What the assessor checks

For every internet boundary on the in-scope estate, the assessor verifies a managed firewall is in place, default-deny is enforced inbound, default credentials have been changed, the firewall is patched, and any open inbound rules are documented and justified.

For home-worker laptops in scope (which is the typical scope today on hybrid work) the assessor verifies that either a software firewall is enabled and locked from user disable, or the device is not directly exposed to the public internet behind a router that performs equivalent default-deny.

What passes

• A managed boundary firewall (physical or cloud) with default-deny inbound, no admin-interface exposed to the public internet, no default credentials, current firmware
• Software firewalls on Windows, macOS, and Linux endpoints set to deny inbound by default, with user disable blocked via group policy or MDM
• Inbound exception rules with a documented business justification per rule

What fails

• A residential router on a home-worker connection where the in-scope laptop has a public IP and the firewall on the laptop is off
• A cloud security group on AWS or Azure that allows 0.0.0.0/0 on a non-public service port (for example RDP 3389 or SSH 22)
• A boundary firewall with the admin interface reachable from the internet, even if MFA is on
• An exception rule with no documented justification

Where it gets debated

Inbound exception rules are the most common debate. A firm running a small SaaS product needs port 443 open to the world, that is fine. A firm running a development server for an external supplier needs port 22 open to one source IP, that is fine if the source IP is documented. A firm running an open SMB share for a partner integration is not fine.

Secure Configuration

What the assessor checks

Default credentials removed, unnecessary software and services disabled, auto-run disabled where it touches removable media, screen-lock on inactivity enforced, and the firm's standard build documented well enough that the assessor can sample against it.

What passes

• Standard images (Windows, macOS, Linux) that have removed or disabled vendor demo accounts and example services
• Auto-run / auto-play disabled on Windows
• Inactivity screen-lock at 10 minutes or less, enforced by group policy or MDM, not relying on user habit
• Documented build standard that lets the assessor pick any sample machine and verify the standard against it

What fails

• Local accounts with vendor default passwords still active on a sampled device
• A laptop where the user has admin rights, has installed a non-standard piece of software, and the firm cannot say whether that is allowed
• Auto-play enabled on Windows when removable media is in scope
• Screen-lock relying on the user remembering to lock the screen

Where it gets debated

The big debate in Secure Configuration is "non-standard software". Engineering firms and creative firms rely on tools the standard build does not include. The scheme allows it: the firm needs a process that approves and tracks the deviation. The assessor accepts a documented process, the assessor rejects "this user just installs whatever they need". The line is whether a process exists, not whether every machine looks identical.

User Access Control

What the assessor checks

Administrative accounts are separated from day-to-day accounts, multi-factor authentication is on every administrative interface (cloud and on-prem), default-deny on local administrator rights, leaver accounts are removed within a documented window, and password policy is enforced.

What passes

• Day-to-day work accounts with no local admin rights on the device
• Separate administrative accounts for IT staff, used only for admin work, with MFA enforced
• MFA on Microsoft 365, Google Workspace, AWS, Azure, GCP, GitHub, and any cloud admin console in scope
• Documented joiner/mover/leaver process that removes accounts within 1 working day of leaver notification
• Password policy that meets the NCSC-aligned thresholds in the IASME Cyber Essentials Plus test specification

What fails

• A shared administrative account ("admin" or "root" or "support") that more than one person uses
• MFA absent from a cloud admin console because "the team is small and we trust each other"
• A leaver active in Microsoft 365 because the email was kept open for handover
• Local admin rights on a sampled device that were not documented as required for that user's role

Where it gets debated

Service accounts and break-glass accounts get debated. A service account that runs a scheduled task and has no human user is allowed, the assessor wants to see it scoped to its function, with credentials not shared with humans, and with a documented rotation or vault process. A break-glass cloud admin account is allowed, the assessor wants to see it stored in a vault, with the password rotation process documented and the access alerting on use.

The other common debate is on contractors. A contractor using their own laptop is in scope under Bring-Your-Own-Device rules unless the firm scopes them out via documented controls. The assessor expects a clear answer, not a shrug.

Malware Protection

What the assessor checks

Every in-scope device runs an active anti-malware mechanism. The assessor accepts vendor anti-malware (Defender, CrowdStrike, SentinelOne, etc.), application sandboxing on platforms that ship it (macOS Gatekeeper, mobile OS sandboxing), or application allow-listing where it is implemented. The assessor verifies the mechanism is enabled, current, and not user-disable-able.

What passes

• Microsoft Defender enabled on every Windows device with tamper protection on, signatures current, real-time protection on
• Endpoint Detection and Response from a recognised vendor with the agent reporting to the management console for every sampled device
• macOS Gatekeeper enabled, with developer-ID and notarisation requirement on
• Mobile devices with the OS-level sandbox in effect (the default on modern iOS and Android)

What fails

• A Windows device with Defender disabled because "the user complained it was slow"
• An EDR agent that is installed but not reporting to its management console (an orphan agent)
• A macOS device with Gatekeeper disabled
• An Android device with side-loading enabled and no MDM-level restriction

Where it gets debated

Linux servers and developer machines get debated. Many development workflows do not use traditional AV. The assessor accepts:

• Linux servers in cloud environments where the workload-protection layer (e.g. AWS GuardDuty, Defender for Cloud) is enabled
• Developer machines where application allow-listing is in effect (rare in practice)
• Developer machines where the firm has documented the technical justification for not running AV and has compensating controls

The assessor rejects "we do not run AV on developer machines because they are smart users".

Security Update Management

What the assessor checks

Operating systems and applications are kept current. The IASME Cyber Essentials Plus test specification requires high-risk and critical patches to be installed within 14 days of release.

The assessor runs an external vulnerability scan against any internet-facing in-scope assets, runs an internal vulnerability sample on the in-scope sample of internal devices, and inspects the results.

What passes

• A patch-management tooling pass (Microsoft Intune, Jamf, BigFix, WSUS, your MDM of choice) that shows critical patches installed within the 14-day window, with exceptions documented
• An external scan that returns no findings rated high or critical
• An internal sample where the devices the assessor picks all show patches up to the 14-day cut-off

What fails

• A device that has not had Windows Updates installed in 60 days
• An external-facing service running a known-vulnerable version of a major platform (a CVSS 9.0+ CVE that has been public for 30+ days)
• "We update when we get round to it"
• A patch-tooling export that shows the right answer but the assessor's live scan disagrees with it

Where it gets debated

The 14-day rule is binary on critical patches. The debate is on what counts as critical and how vendor advisories map to the IASME criteria. A vendor labels a patch "important" but it carries a CVSS 9.0 RCE; the IASME criteria treat that as critical. The assessor will explain this but will not waive it.

The other debate is on long-running production servers that cannot reboot during a window. The scheme allows compensating controls during the window, the assessor wants to see them documented, time-boxed, and trending toward patch installation.

Sample size and methodology

The IASME Cyber Essentials Plus test specification defines the sample size based on in-scope device count. For small and mid-sized engagements the sample is small but not trivial: a handful of representative end-user devices spanning the operating systems in use, a representative set of cloud services in scope, and any internet-facing servers.

The sample is not negotiable. If the assessor asks for a Windows laptop, a macOS laptop, and a Linux server, the firm cannot offer "two Windows laptops are easier to access". The assessor needs the sample to represent the in-scope estate.

For deeper coverage on sample sizing, the netsecgroup.io reference Cyber Essentials Plus Sample Sizes walks through the calculation per scope.

Pre-assessment checklist

If you are about to go into a Cyber Essentials Plus engagement, the items below cover the common reject categories above. Fix these before the assessment day, you will recover the time several times over.

1. Confirm every cloud admin console in scope has MFA enforced, including break-glass accounts
2. Run a leaver-account audit; remove anyone who left more than 1 working day ago
3. Confirm Microsoft Defender (or your EDR) is reporting on every Windows device, with tamper protection on
4. Confirm macOS Gatekeeper is on for every Mac in scope
5. Run a patch-status report; chase anything outside the 14-day window for critical patches
6. Confirm screen-lock is enforced via group policy or MDM, not user habit
7. Confirm no inbound rules on any cloud security group expose admin services to 0.0.0.0/0
8. Confirm the standard build is documented well enough that a stranger could verify a sampled device against it
9. Confirm every administrative account is separated from its user's day-to-day account
10. Confirm an external vulnerability scan against your internet-facing assets returns no high or critical findings

This list aligns with the netsecgroup.io Cyber Essentials Plus Assessment Guide, which covers the end-to-end process at procedural depth.

Common questions

How long does the assessment take?

For a small or mid-sized firm with the prep above in place, the technical assessment runs in 1 to 2 working days, and the certificate issues end-to-end in 3 to 5 working days depending on whether your pass is clean or there is remediation.

What if a sampled device fails?

The assessor reports the failure, the firm fixes the underlying control across the scope (not just on the failed device), the assessor re-tests on a fresh sample. Plus engagements with NetSec include unlimited retries until certification is achieved. There is no extra cost for a re-test.

Is the assessment remote?

Yes for almost every engagement. The assessor connects via a secure remote tooling stack and runs the technical sample, the external scan, and the internal sample without needing to be on site. On-site is offered when a firm prefers it, the technical content is identical.

Can I skip the Plus tier and just do Basic?

Cyber Essentials Basic is a verified self-assessment. UK enterprise procurement, NHS, MoD-adjacent supply chains, and UK central government procurement default to requiring Plus, not Basic. If your customers ask for Cyber Essentials, ask which tier; if they say "just Cyber Essentials" they almost always mean Plus.

For the per-tier difference written from the buyer's perspective, see the netsecgroup.io Cyber Essentials Basic vs Plus reference.

What does it cost?

CE Plus pricing is based on organisation size, with current published rates on the Net Sec Group CE Plus options page. IASME provides complimentary £25k cyber liability insurance directly with every CE Plus certificate issued to a qualifying UK entity (turnover under £20M).

Next steps

If you have read this far you are scoping a CE Plus engagement, preparing for one, or working out whether your current posture survives the audit. The next two articles on this site go deeper on the day itself and on per-control evidence:

• The CE Plus assessment day walkthrough, what actually happens hour-by-hour during the technical assessment
• The evidence the assessor accepts, per-control evidence formats that pass and fail

For the deeper procedural and technical references on netsecgroup.io:

• Cyber Essentials Plus Assessment Guide, end-to-end procedural walkthrough
• Cyber Essentials Five Controls Technical Guide, per-control technical reference
• Cyber Essentials Plus Assessment Duration, timeline reference

When you are ready to book or want a per-control walkthrough against your own estate before booking, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.