Our Cyber Essentials Plus Methodology: How We Run the Assessment

‍‌​‌‌​‌‌​​‌‌‌‌​​​‌​​‌‌​​‌​‌‌‌​‌​​​‌​​​​​​​​​‌‌‌​​​‌‌​​‌​​​‌​‌‌​​‌‍Every licensed certification body runs the same five IASME test cases for CE Plus. The specification and pass criteria are the same, so what actually differs? It comes down to what happens after the scanner finishes. An assessor who also conducts penetration tests reads vulnerability output differently from someone who just exports the report.

I'm a CREST Registered Penetration Tester (CRT). When a CE Plus scan flags a vulnerability, I don't stop at the CVSS score. I look at whether someone could realistically exploit it from outside your network, what they'd get if they did, and what the proper fix looks like. That context changes the findings report quite a lot.

Here's how we run the assessment from start to finish.

Pre-assessment

We confirm three things before any testing starts.

Scope: Every device accessing organisational data, every internet-facing IP, every cloud service. Under Danzell, personal devices used for work fall into scope too, and so do business social media accounts. We cross-check your Basic CE questionnaire to make sure the scope hasn't shifted since you filled it in.

Sample: We calculate the sample from the IASME build-based sampling table. Your devices get grouped by OS version and edition. We pick a representative sample from each group. Servers are always tested in full, no sampling. And the sample gets declared to IASME at least 72 hours before testing starts.

Access: Most assessments are remote these days. So we confirm the remote access method actually works before testing day. VPN, remote desktop gateway, direct RDP, whatever you're using. We test the connection in advance because assessment day should start with scanning, not IT troubleshooting.

Test case 1: External vulnerability scan

We scan every internet-facing IP address in your scope from outside your network. This part is entirely unauthenticated, meaning we see exactly what an attacker would see. (as noted in the June 2026 provenance review).

The scan identifies:

• Open ports and listening services
• Software versions and known vulnerabilities
• SSL/TLS configuration and certificate issues
• Missing patches on externally accessible services
• Default configurations and credentials on web interfaces

We use commercial vulnerability scanning tools and then verify manually. Scanners produce false positives regularly, so if a scanner reports something high-severity, we check it ourselves before calling it a failure. Nobody should fail their cert on a scanner artefact.

What we're looking for: Any vulnerability with a CVSS score of 7.0 or higher on an internet-facing system. The most common findings are unpatched VPN appliances, firewall firmware with known vulnerabilities, and web servers running outdated software.

What this means for you: Keep your internet-facing devices patched. This test case catches more businesses than any other because these devices need manual attention. They don't update themselves the way a Windows workstation does.

Test case 2: Internal authenticated scan

We connect to each sampled device and check its configuration from the inside. This is where the pen testing background actually matters.

On each device, we verify:

• Patch levels: Are all critical and high-risk patches applied within 14 days? We check OS patches, application patches, and firmware where applicable.
• Secure configuration: Is the device configured according to CE requirements? Auto-run disabled, unnecessary software removed, default accounts disabled or renamed, password policies enforced.
• Local firewall: Is the host firewall enabled and configured to block unsolicited inbound connections?
• Software inventory: What software is installed, is any of it unsupported, and are there unnecessary applications increasing the attack surface?

For Windows devices we use a combination of automated policy analysis and manual checks. Group Policy settings, registry values, installed updates, running services. For macOS, we go through system preferences, installed profiles, and software update status.

What we're looking for: Devices that meet CE requirements in practice, not on paper. A policy saying "patches within 14 days" gets tested by checking actual patch installation dates. A policy saying "no admin accounts for daily use" gets tested by checking which account is currently logged in. Policies are easy to write. We check whether they're actually followed.

Test case 3: Malware protection

We verify that antimalware software is installed, running, and doing its job on every sampled device.

The checks cover whether the antimalware product is installed and its protection service running, whether real-time protection is enabled, whether signature definitions are current, and whether the product actually works.

That last one is straightforward to test. We use the EICAR test file, a harmless standardised test file that every antimalware product is designed to detect. We try to download it to each device. If the antimalware intercepts it, the control works. If it doesn't, there's a configuration problem worth investigating.

We also check whether cloud-delivered protection is enabled where available. Modern antimalware products rely on cloud analysis to catch threats that local signatures miss. Running antivirus with cloud protection off weakens it noticeably.

What this means for you: Make sure real-time protection is enabled on every device before the assessment. The most common issue we see is a device where someone disabled protection to install software and forgot to turn it back on.

Test case 4: MFA verification

We test whether MFA is enforced on every cloud service in scope. Under Danzell, that includes all cloud services supporting MFA, business social media accounts included.

The test is fairly simple: we attempt to access each cloud service and confirm that an MFA prompt appears. We also check that MFA is enforced through policy, not just enabled as an option users can skip.

We check:

• Microsoft 365 (conditional access or per-user MFA settings)
• Google Workspace (if used)
• Cloud accounting software
• Cloud CRM
• Cloud storage
• Social media management platforms
• Business social media accounts
• Any other cloud service in scope

What this means for you: Check every cloud service before the assessment. The most common finding is a service added after Basic CE without MFA being configured. Under Danzell, business social media accounts are the ones that catch people off guard.

Test case 5: Account separation

We verify that admin accounts are separate from daily-use accounts. That means:

• No user performs daily work (email, web browsing, document editing) using an admin account
• Admin accounts are used only for administrative tasks
• Standard user accounts don't have local administrator privileges
• The principle of least privilege is applied

We check this by reviewing account configurations, examining who is logged into sampled devices, and verifying admin privileges are assigned where they should be and nowhere else.

What this means for you: If your IT person uses an admin account for everything because it's more convenient, that's a finding. Create a separate standard account for daily work and only use the admin account when making administrative changes. Five-minute fix that people put off for months.

Findings and remediation

If we identify issues, we send a detailed findings report. Each finding includes:

• What we found and where
• The CVSS score (for vulnerability findings)
• What an attacker could do with the vulnerability (from our pen testing perspective)
• How to fix it, with specific steps
• Priority (what to fix first)

You get 30 calendar days to remediate. After that, we re-test the specific areas that had findings. We don't charge extra for the re-test because it's part of the assessment.

Why pen testing experience matters

Every assessor runs the same IASME test cases. The interpretation of those results is where things diverge.

A scanner might report a medium-severity finding on a web server. An assessor who only runs scans might note it and move on. But a pen tester recognises when that specific vulnerability, combined with another finding in the same scan, creates an exploitable chain, and we flag that explicitly.

It goes the other way too, because we sometimes see scanner results that look alarming but aren't practically exploitable in context. A vulnerability in a service that's blocked by the firewall isn't a real risk, even if the scanner dutifully reports it. We provide that context so you're spending time on genuine issues, not chasing false positives.

Our assessment isn't more expensive than other certification bodies. The IASME fee structure is the same regardless of who runs it. The difference is what you get back in the findings report and how well prepared you are if something needs fixing.

If you want to check where your basic controls stand before scheduling CE Plus, the readiness quiz covers the five control areas in five minutes with no commitment required.

---

Keep up with Cyber Essentials changes

New requirements, deadline changes, and practical assessment tips with no spam or sales pitches.

Subscribe to the newsletter | Follow Daniel on LinkedIn

Related articles

• Cyber Essentials Plus Assessment Process Explained
• Cyber Essentials Plus Sample Sizes
• IASME Certification Process: How Cyber Essentials Assessment Works
• How Long Does a Cyber Essentials Plus Assessment Take?

netsec-canary-2105639621e3.