Cyber Essentials Plus Evidence Screenshots Checklist, the Per-Control Specification

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, the screenshot pack the applicant submits ahead of the CE Plus assessment is the artefact the assessor reads first. A clean pack moves the engagement through assessor review in a single cycle; a pack with redaction errors, missing timestamps, or wrong-tenant captures pushes the engagement into back-and-forth. This article is the per-control screenshot specification the assessor uses, the redaction rules, and the five rejection patterns we see when packs come back for rework.

The article sits on the audit-evidence pillar of this site. For the related MFA-evidence specifics, see CE Plus MFA evidence, acceptable formats. For the broader CE Plus assessment-day reference, see the CE Plus Assessment Guide on netsecgroup.io.

What the assessor reads on the day

The CE Plus evidence pack is a structured collection of artefacts, one per CE Plus control sub-test. The assessor reviews each artefact against the IASME CE Plus test specification and the Cyber Essentials Requirements for Infrastructure (NCSC, current v3.x), and decides whether the underlying control passes, queries, or fails. Screenshots are the dominant artefact format; configuration exports and policy documents are the other two.

A screenshot is acceptable when three things hold: the screen comes from the in-scope production tenant; the visible-required fields are legible; and any redacted fields fall into the assessor-accepted redaction tiers covered below. The cumulative bar across the five controls is what produces an audit-pass on first review.

The 5-row screenshot specification table

Each row names the control, the specific screen to capture, the fields that must be visible (the assessor will reject the screenshot without them), and the fields that may be redacted within the rules below.

| Control | Screen to capture | Visible-required fields | Redaction-permitted fields | |---|---|---|---| | Boundary Firewalls and Internet Gateways | The boundary firewall's rule list (on-premises hardware admin UI, or AWS security group / Azure NSG / GCP firewall rules console) | Default-deny on inbound, ruleset showing each permitted service with source/destination/port, timestamp of the configuration export | Service-account names if not control owners, internal IP ranges if commercially sensitive (must remain identifiable to the rule) | | Secure Configuration | The MDM or Group Policy management screen showing the standard build profile applied to in-scope hosts | Profile name, applied-to scope (the in-scope device collection), policy values (default account state, firewall state, password policy), timestamp | Per-host hostnames if commercially sensitive (the count of hosts must remain visible) | | User Access Control | The identity provider's user list filtered by admin role | Admin account names mapped to identity (control owner identity must be visible on sign-off), MFA status column, last sign-in column, timestamp of the export | Personal email domains, last-name fragments where the user's identity is established by other visible fields | | Malware Protection | The anti-malware management console showing the in-scope device fleet status | Device count, anti-malware service state per device, definitions update timestamp, console-side timestamp | Per-device hostnames where commercially sensitive | | Security Update Management | The patch-management console export filtered to in-scope devices | Per-device patch compliance status, the device's last-scan timestamp, the highest outstanding CVE severity, the patch-management policy name | Per-device hostnames where commercially sensitive (count must remain visible) |

The 3-tier redaction acceptance model

Across our engagement history, redactions fall into three tiers. Tier 1 is always acceptable; tier 2 is acceptable with a footer note explaining the redaction; tier 3 is never acceptable.

Tier 1, always acceptable redactions

These can be redacted without explanation; the assessor expects them and reads the pack the same as if the data were visible.

Personal data on a user record (a user's home email address, mobile phone number, date of birth where these appear in the directory record): redact freely; the user's identity is established by their organisational role and account name. The redaction follows ICO UK GDPR data minimisation guidance, which UK certification bodies operate under
Secret-bearing fields (API keys, secret strings, certificate fingerprints, password hashes that appear in management consoles): redact freely; the assessor does not need the secret to verify the control
Third-party customer data appearing in a sample (a customer name, a customer-side email address that appears in a tenant query): redact freely; UK GDPR principles support this

Tier 2, acceptable with a footer note

These can be redacted but the screenshot needs a footer note explaining what was redacted and why; the assessor reads the note alongside the redacted screenshot.

Internal IP ranges that the firm considers commercially sensitive: footer note "internal IP ranges redacted, full ranges available on request to the assessor"
Hostnames that the firm considers commercially sensitive: footer note "hostnames redacted, full inventory provided in separate evidence file"
Custom configuration values that appear in support contracts (license keys, support-ticket reference numbers, vendor account identifiers): footer note "support-vendor identifiers redacted"

Tier 3, never acceptable redactions

These will always be rejected. The reason is structural: each tier 3 redaction removes a field the assessor uses to verify the control.

Control owner identity on a sign-off: the assessor needs to see the named human who signed off; redacting the name is rejected
Configuration value the assessor needs to verify (the actual policy setting, the actual rule, the actual cipher list): redacting the configuration value defeats the screenshot's purpose
Timestamps: the assessor uses the timestamp to verify the screenshot is current; redacting timestamps is rejected
The MFA status column on a user list: the assessor reads the column directly to verify the control; redaction is rejected
Account names that establish administrative attribution: the assessor verifies admin actions are attributable to named humans; redacting names defeats the verification

The five rejection patterns we see

Across the engagement history, five patterns recur on screenshot rejections. Each is preventable with a 5-minute review of the pack before submission.

Rejection 1, cropped to hide the timestamp

The applicant captures the rule list or user list cleanly but crops the screenshot to remove the management console's "last refreshed" timestamp. The assessor cannot verify the screenshot is current. Fix: re-capture with the full console chrome including the timestamp; if the timestamp lives in a different region of the console, capture both regions in one screenshot or pair them as adjacent screenshots in the evidence pack.

Rejection 2, screenshot taken in a non-production tenant

The applicant has a development tenant and a production tenant. The screenshot comes from the development tenant because it was easier to access; the assessor reads the tenant identifier in the screenshot's URL bar or window title and rejects. Fix: capture from the production tenant only. Where the production tenant is the same as the development tenant under a different subscription, name the subscription in a footer note.

Rejection 3, redaction over a configuration value the assessor needs to verify

The applicant redacts a value as commercially sensitive when the value is the configuration the assessor must inspect. Common examples: redacting the actual password policy values, redacting the firewall rule destinations, redacting the MFA-enforcement scope. Fix: re-capture without redaction over the verifiable configuration; redact only fields covered by tier 1 or tier 2 above.

Rejection 4, screenshot from a user account view rather than the admin view

The applicant takes the screenshot from a regular user's view of the management console, which routinely shows a subset of the data the admin view provides. The assessor flags the missing fields. Fix: re-capture from the admin view of the same console with the appropriate admin role active.

Rejection 5, screenshot of a stale export rather than a current view

The applicant downloads a CSV or PDF report from last quarter, takes a screenshot of the report header, and submits as evidence. The assessor reads the report-generation date and rejects because the evidence is not current. Fix: regenerate the report with a current date or capture the live console view directly.

How the assessor sequences the pack review

Across the engagement history, the assessor reads the pack in a consistent order. Knowing the order helps the applicant present the evidence in the structure that produces the fastest review.

First pass, scope verification: the assessor reads the scope statement, the asset list, and reconciles them against the pack's coverage. A pack covering 60 hosts when the asset list says 80 surfaces here. Resolution before the second pass: identify the 20 absent hosts, justify each (out of scope, MDM-managed-only via separate evidence, removed from scope before the assessment), or fail this pass.

Second pass, control-by-control: the assessor reads the per-control evidence in IASME spec order: Boundary Firewalls, Secure Configuration, User Access Control, Malware Protection, Security Update Management. Each control is read end-to-end (primary screenshots, sample screenshots, configuration exports, policy documents) before moving to the next. A weak primary screenshot stops the read for that control until the applicant tightens.

Third pass, sampled evidence: where the IASME formula sampled specific devices or users, the assessor reads the sample evidence against the sample list. The sample evidence has to match the named sample, not a different selection. See CE Plus Sample Sizes for the per-build formula.

Fourth pass, footer notes and supplementary files: any footer note in the pack (tier 2 redaction explanations, scope-statement clarifications, references to external evidence files) is read against the screenshots they annotate. Notes that contradict the screenshots they accompany surface here.

Fifth pass, the live verification on assessment day: a subset of the screenshot evidence is verified live by the assessor against the production tenant during the assessment session. The pack screenshots and the live console match cleanly when the pack was captured from production with current timestamps.

When the pack is structured to match this read order (scope-statement first, per-control folders in IASME spec order, sample-list cross-references, footer notes attached to relevant screenshots, current-tenant capture), the review completes in one pass. Disorganised packs add at least one back-and-forth cycle.

For the related MFA-evidence specifics that often dominate the User Access Control pass, see CE Plus MFA evidence, acceptable formats. For password and authentication evidence framing, the NCSC MFA guidance collection is the underlying reference the assessor reads against.

What a clean pack looks like end-to-end

A 5-control pack for a typical SME engagement is 25 to 50 screenshots. The structure: per control, a folder; within the folder, the primary screenshots (typically 3 to 6 per control), the supplementary screenshots (per-device or per-user samples per the IASME sampling formula), and any footer-note evidence files. The pack carries an index document naming each screenshot, its purpose, and any supplementary file. Image format: PNG or JPEG at native resolution; PDF for documents; ZIP for the pack overall.

For the per-control technical reference (what each control tests and how), see the Cyber Essentials Five Controls Technical Guide on netsecgroup.io plus the per-control articles on this site: User Access Control, Secure Configuration, Patching and Updates, Malware Protection, and Firewalls and Gateways.

Common questions

How many screenshots is enough per control?

The assessor reads the screenshots against the IASME test specification's per-control sub-tests. For a 5-control engagement on a typical SME, 3 to 6 screenshots per control covers the primary evidence, plus per-device or per-user samples for the controls that require sampling (per-device for secure configuration, malware protection, security update management; per-user for user access control). The total typically lands at 25 to 50 screenshots; engagements above 50 indicate either a large estate or unnecessary duplication.

Can I submit the screenshots as a PDF or do they need to be individual images?

Either is acceptable. A PDF compilation with one screenshot per page, an index, and per-image captions is the structure we see across the engagement history. Individual PNGs in a structured folder is equally acceptable. The assessor's preference is whichever format makes the pack faster to review; structure matters more than file format.

Do redactions reduce my chance of passing?

Tier 1 and tier 2 redactions are acceptable and do not affect the audit decision. Tier 3 redactions cause rework. The only redaction risk is putting a tier 3 field into a tier 2 wrapper (claiming a configuration value is "commercially sensitive"); the assessor reads the field anyway by other means and the screenshot becomes evidence of an attempt to obscure rather than evidence of the control.

What if a screenshot reveals personal data the firm has not anonymised?

The IASME assessor follows ICO guidance on personal data handling. The applicant should redact tier 1 personal data on user records before submission; the assessor will not retain personal data unredacted in the audit file. Where personal data appears in error in a submitted screenshot, the applicant can submit a re-redacted version and the original is destroyed.

Where do we book CE Plus?

Book a Cyber Essentials Plus assessment with Net Sec Group. The booking form lets you describe the estate; the assessor confirms the engagement timeline and the evidence-pack expectations.

Reference material

Where this fits on this site

This article is the screenshot-specification spoke under the audit-evidence pillar. The other audit-evidence spoke is CE Plus MFA evidence, acceptable formats. For per-control content, see User Access Control, Secure Configuration, Patching and Updates, Malware Protection, and Firewalls and Gateways on this site.