Cyber Essentials 6: malware protection and a truthful readiness review

Choose a protection method that fits each platform

Bring the device groups, software baseline and account register. Cyber Essentials permits specified approaches to malware protection, including anti-malware software for in-scope Windows and macOS devices and application allowlisting. Match each group to a permitted approach and verify its detailed conditions in v3.3. A product logo or app-store policy is not a complete explanation.

For anti-malware, check that protection is active, updated in line with the vendor's instructions and configured to prevent malicious code and relevant malicious connections. For an allowlisting approach, establish how applications are approved, how the approved list is maintained and how unsigned or invalidly signed applications are prevented from installation under the scheme's conditions.

Phones, Macs, Windows systems and servers do not necessarily use identical mechanisms. Record the method for each, including who operates it and what proves its effective state. Do not install several competing security products merely to create more screenshots; confirm vendor-supported configuration and avoid disrupting protection.

Examine the devices missing from the dashboard

Compare protection reporting with the full in-scope inventory. An agent reporting “healthy” on 46 computers says nothing about the two computers that are absent. Investigate stale check-ins, disabled services and devices outside the policy group. Keep timestamps visible so yesterday's status is not presented as a current observation.

Merefield's fictional Mac group contains six devices. Five report correctly; the sixth has a failed enrolment. The team repairs enrolment, verifies policy and checks whether the provisioning procedure caused the same failure elsewhere. The lesson is about coverage: software procurement did not prove deployment, and deployment did not prove operation.

Capture enough detail to reproduce the conclusion: device identifier, policy, effective protection state, update status and check time. Where evidence contains personal information, minimise what is shared and restrict access. A redacted screenshot should preserve the facts the assessor needs to assess.

Rehearse checks safely

Use the vendor's documented safe test procedure in an authorised pilot environment if you need to check alert handling. Do not download live malware or disable protection to make a test easier. Coordinate with the MSP or monitoring provider so expected alerts can be recognised without suppressing ordinary detection.

For Plus, the assessor supplies or specifies the relevant technical test procedure and test files. Ask what connectivity, accounts and staff availability are needed. Any requested temporary access should be specific, documented and removed afterwards. A blanket bypass that invalidates what is being tested is not useful preparation.

Treat an alert as an operational event: who receives it, how quickly it is noticed and what action follows? CE certification does not replace an incident-response programme, but a protection system nobody monitors can still leave the organisation with a practical weakness. Record that separately from the scheme pass/fail decision.

Construct an evidence index, not a screenshot museum

Add an owner, observation date and unresolved issue to each entry. Keep the source record in its normal system and link to it where practical. Export a dated copy when needed for the submission. That lets you distinguish “the policy existed then” from “the policy was changed after the finding”.

There is no benefit in collecting secrets. Account names, configuration state and approval references usually provide more relevant evidence than passwords or recovery codes. Agree the assessor's secure transfer and retention arrangements before uploading sensitive inventories.

Challenge the answer from the other direction

For each proposed “yes”, ask what observation would make it false. If the answer says all software is supported, choose a rarely used application. If it says all cloud authentication uses MFA, try an authorised test of the direct login path. If it says staff lack administrative access, inspect effective local and cloud roles for a sample.

Do not present those samples as proof by themselves. Use them to validate the management mechanism and investigate exceptions across the relevant population. A small random check can discover an error; it does not justify ignoring everything outside the check.

Have a person who did not prepare the evidence review the final questions. They need enough technical understanding to challenge vague language and enough independence to report a blocker. Ask the sponsor to resolve funding or service decisions, not to sign away an unmet scheme requirement.

Readiness decision

Prepare a short record: scope version, requirement/question-set version, open mandatory gaps, evidence age, owner and next action. Separate optional improvements from blockers so a useful future project does not obscure a present failure. Conversely, do not relabel a mandatory gap as an improvement to make the board green.

Proceed to part 7 when the evidence supports the actual answers and remaining uncertainties have been resolved with the certification body. If it does not, postpone the declaration and continue remediation. That is a controlled project decision, not a failure of the security programme.

Check your understanding