The Evidence a Cyber Essentials Plus Assessor Accepts (and What Fails on the Day)

Net Sec Group is an IASME and NCSC certification body. The single most common reason a Cyber Essentials Plus engagement loses time is the applicant turning up on the day with the wrong evidence format, not with the wrong control posture. The control is in place, the evidence does not show it, and the assessor cannot accept what the assessor cannot see.

This article pairs, control by control and sub-test by sub-test, the evidence format that passes with the evidence format that fails, plus the reason. It is drawn from real assessment-day decisions across our 800+ assessment history.

If you are gathering evidence in the days before a CE Plus assessment, this is the format reference you need.

How the assessor decides

The IASME Cyber Essentials Plus test specification sets out what the assessor must verify. It does not dictate the file format the applicant submits. The assessor accepts evidence in the format that proves the control is in place across the scope. The assessor rejects evidence that proves the control is in place on a single device or for a single user when the test asks about the scope.

The pairing throughout this article repeats the same shape. What passes is evidence that is:

1. Dated (so the assessor can verify currency)
2. Tied to the in-scope estate (a tenant report, a group policy, a console export, not a one-off screenshot of one machine)
3. Reproducible by the assessor on the day if asked (live screen-share matches the submitted evidence)

What fails is evidence that is:

1. Undated or stale
2. Tied to a single device or user when the test scope is the estate
3. A screenshot the assessor cannot reproduce on the live screen-share

That is the framework. Now the per-control specifics.

Firewalls and Internet Gateways

Boundary firewall configuration evidence

Passes: a configuration export from the boundary firewall (physical or cloud security group) that shows the active ruleset, the inbound default policy, and the timestamp of the export. For cloud security groups, an aws ec2 describe-security-groups JSON or the Azure portal export of the rule list is acceptable.

Fails: a single screenshot of the firewall admin UI showing one rule. The assessor cannot tell whether other rules exist or what the default policy is.

Why: the test asks about the boundary, not about a single rule. The assessor needs the full ruleset.

Endpoint software firewall evidence

Passes: a group policy or MDM configuration export that shows the software firewall is enabled and locked from user disable, plus a live screen-share of the firewall state on a sampled device for verification.

Fails: a screenshot from one user's machine showing the firewall is on. The assessor cannot tell whether other users have it on or whether they can turn it off.

Why: the test asks about the estate, not the device.

Secure Configuration

Standard build documentation

Passes: a build standard document (or wiki page, or Intune configuration profile export, or Jamf configuration profile export) that an external reader can use to recreate the standard. The document is dated, version-controlled, and named.

Fails: a verbal "we have a standard" with no documented artefact. Or a build-script repository with no current README and no marked released version.

Why: the test requires the assessor to sample devices against the standard. Without a documented standard, sampling is meaningless.

Default credential removal evidence

Passes: a screen-share on a sampled device that shows local accounts and confirms vendor defaults are removed or disabled. Plus, where applicable, a build script or MDM policy that enforces default-account disable on the standard build.

Fails: an assertion that "we always remove defaults". The assessor verifies on the live sample.

Why: the assessor verifies, the assessor does not accept assurances.

Auto-run / auto-play evidence (Windows)

Passes: a group policy export showing AutoPlay is disabled for all media types, plus a live screen-share on a sampled device with the relevant registry key set or AutoPlay disabled in Settings.

Fails: a screenshot of one user's AutoPlay setting being off. (Same problem as software firewall: not estate-wide.)

Why: the test scope is the estate.

User Access Control

Multi-factor authentication evidence

This is the single highest-volume evidence category and the one that fails most often.

Passes for cloud admin (Microsoft 365): a Conditional Access policy export from Entra showing the policy applies to the administrative role group, with the access controls requiring MFA, plus a tenant sign-in report showing administrative sign-ins satisfied the MFA challenge in the last 30 days.

Fails for cloud admin (Microsoft 365): a screenshot of "Multi-factor authentication is enabled" from the Microsoft 365 admin portal at the per-user level. Per-user MFA does not enforce; Conditional Access does.

Why: NCSC MFA guidance (linked in references at the end) sets out what counts as MFA in scope. Per-user MFA in Microsoft 365 can be bypassed by legacy authentication protocols and basic auth; it is not what the test specification asks for.

Passes for cloud admin (Google Workspace): an admin console screenshot showing 2-step verification is enforced for the administrative organisational unit, plus the user list confirming all admins are subject to the policy.

Passes for AWS / Azure / GCP admin: a screenshot of the IAM policy enforcing MFA on administrative roles, plus a console export of MFA status across the admin user list.

Fails for any cloud: an MFA exception for "this one admin while they travel".

Why: exceptions in administrative access break the control. They are documented at scheme level.

Local admin separation evidence

Passes: a local admin group export from the device fleet (via Intune, Jamf, or Active Directory query) showing day-to-day user accounts have no membership in the local admin group, with documented exceptions per role.

Fails: a screenshot from one device showing the user is not a local admin. The estate may differ.

Why: same scope problem.

Leaver-account removal evidence

Passes: a documented joiner/mover/leaver process plus a sample audit run on the day showing leavers from the last 90 days are not active in the production tenant.

Fails: a verbal "we remove leavers", with a live console showing a leaver still active because their email was kept open for handover.

Why: the live console is the source of truth.

Malware Protection

Anti-malware deployment evidence

Passes: a management-console export from the anti-malware tooling (Microsoft Defender for Endpoint, CrowdStrike, SentinelOne, Defender for Cloud, etc.) showing every in-scope device is enrolled, the agent is reporting, signatures are current, and tamper protection is on.

Fails: a screenshot from one user's machine showing Defender is on. (Scope.)

Why: an orphan agent or a missing endpoint is the failure mode the test is designed to find.

macOS application sandbox evidence

Passes: an MDM configuration profile export showing Gatekeeper is enabled with developer-ID and notarisation requirement on, plus a live screen-share on a sampled Mac confirming the policy is in effect.

Fails: an assertion that "we use Macs and they are secure by default". Macs ship with Gatekeeper enabled but the user can disable it; the test asks for the locked-on state.

Email-attack-vector test evidence (live, not pre-collected)

The email-based attack-vector test is run live by the assessor on the day. The evidence is the live behaviour: the test attachments are blocked, the test URLs are blocked, the user cannot override.

There is no pre-collected evidence the applicant submits for this sub-test. The applicant prepares by ensuring the configuration the test will exercise is in place: macros in office productivity software default-blocked, browser safe-browsing enabled, endpoint anti-malware able to interdict.

Security Update Management

Patch-status evidence

Passes: a patch-management tooling export (Microsoft Intune, Jamf, BigFix, WSUS, your MDM of choice) listing every in-scope device with its current patch state and the timestamp of the last patch scan, with critical patches installed within the 14-day window per the IASME CE+ test specification.

Fails: an undated screenshot of "Windows Update is up to date" on one user's machine.

Why: the test asks about every in-scope device against a 14-day window. A single screenshot does neither.

End-of-life software evidence

Passes: an inventory export showing no end-of-life operating system or major application is in scope, with version numbers for each device.

Fails: an assertion that "we keep things current". The live sample will find the Windows 10 device that was missed in the upgrade plan.

Why: the test verifies, not asserts.

Compensating-control documentation (where a system cannot be patched)

For long-running production systems that cannot reboot during a patch window, the test allows compensating controls during the window. The assessor accepts:

• A documented compensating control (network segmentation, application-level WAF, monitoring with paged response) for the system in question
• A documented patch window that is time-boxed (it is the long-running system, not the policy of "we never reboot")
• Evidence the compensating control is actually in place

The assessor rejects:

• "We will get to it next quarter" with no compensating control
• A compensating control that is not documented and cannot be verified

For the patching failure patterns we see most often, see The CE Plus patching failure cases on this site.

Pre-assessment evidence checklist

If you are 48 hours out from a CE Plus assessment, gather and stage these evidence artefacts. The list maps to the per-control accept patterns above.

1. Boundary firewall configuration export (timestamped)
2. Cloud security group export (AWS / Azure / GCP, where applicable)
3. Group policy or MDM configuration profile export covering software firewall, AutoPlay, screen-lock
4. Build standard document (a current, named, dated artefact)
5. Conditional Access policy export from Entra (Microsoft 365 admin)
6. 2-step verification policy screenshot from Google Workspace admin (where applicable)
7. IAM MFA policy from AWS / Azure / GCP admin (where applicable)
8. Local admin group exports from the device fleet
9. Joiner/mover/leaver process document
10. Last-90-day leaver-account audit
11. Anti-malware management-console export covering every in-scope device
12. MDM configuration profile for macOS Gatekeeper (where applicable)
13. Patch-management tooling export with timestamps and patch-state per device
14. Software inventory export showing no end-of-life software in scope
15. Compensating-control documentation for any unpatchable system in scope

For the order in which the assessor walks through these on the day, see The CE Plus assessment day walkthrough on this site.

Common questions

Do screenshots ever pass?

Yes, but only as live-on-the-day verification, not as the primary evidence format. A screenshot of an MDM console showing the policy applied to the device is fine when the assessor can re-run the same view on screen-share. A screenshot exported and emailed in advance is harder to verify.

What if our tooling cannot export the evidence format the assessor wants?

The assessor accepts any format that proves the control is in place across the scope. If your patch tooling exports CSV but not JSON, CSV is fine. If your firewall is managed by a partner who issues monthly reports, the monthly report is fine if it is recent and signed. The test asks for the substance, not the file extension.

What if our environment has unusual constraints (air-gapped, regulated, classified)?

The assessor will work with you on evidence formats appropriate to the constraints. The test scope and outcomes are unchanged; only the evidence collection method varies. Discuss this in scoping, not on the day.

Does the assessor accept video evidence?

Yes for sub-tests where the screen-share recording captures the relevant control state. The assessor will record the screen-share as part of the engagement records. The applicant does not need to produce video evidence in advance.

How long is evidence retained after the assessment?

The IASME audit-record retention requirement applies to the certification body. The applicant's copy of any artefacts shared during the engagement remains the applicant's, retained per the applicant's own data-handling policy.

Common failure patterns

The single highest-volume failure pattern is per-user MFA on Microsoft 365 admin where Conditional Access is the right configuration. The single highest-volume "this could have been avoided" failure is undated patch evidence. The single most surprising-to-applicants failure is a leaver still active because their email was kept open for handover.

For the full breakdown of failure patterns by control, see The most common CE Plus failures by control. For MFA-specific failures, see The CE Plus MFA failure cases. For patching-specific failures, see The CE Plus patching failure cases.

Next steps

• For the per-control checks at audit-day resolution, see What the CE Plus assessor checks
• For the hour-by-hour day narration, see The CE Plus assessment day walkthrough
• For the deeper end-to-end procedural reference: Cyber Essentials Plus Assessment Guide
• For the technical-control reference: Cyber Essentials Five Controls Technical Guide
• For a first-person account of a clean pass: Cyber Essentials Plus, First-Time Pass

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