Cyber Security

The Essential Eight Compliance Checklist: What to Have Ready Before Anyone Asks

BJ
Ben Jones
4 min read
One question and one piece of evidence per control. What to have assembled before an insurer, auditor or enterprise customer asks where you stand on the Essential Eight.

Sooner or later, someone with leverage over your business asks where you stand on the Essential Eight. An insurer at renewal, a government buyer running due diligence, an enterprise customer with a security questionnaire and a deadline. The organisations that handle the question well are not the ones with the best security budget. They are the ones with the evidence already assembled. This checklist is what "ready" looks like, control by control.

A note on how to use it. For each strategy there is one question that settles the matter and one piece of evidence that answers it. If you cannot produce the evidence within a working day, treat the control as unproven, whatever the policy document says. We go deeper on all of this, including how to sequence the fixes, in our Essential Eight uplift guide.

1. Application control

The question: can an unapproved executable run on a standard workstation?
Evidence to hold: log output from an attempted execution in a user-writable path, dated within the last quarter. If you are still in audit mode, hold the inventory report instead and be upfront about it. Assessors respect audit mode with a date attached far more than enforcement claims without logs.

2. Patch applications

The question: how many days did your last three critical application patches actually take, from disclosure to deployed?
Evidence to hold: deployment records with dates. Not the patching policy. The gap between a stated 48-hour window and an observed six weeks is the single most common finding in first assessments, and insurers now check at claim time rather than taking the questionnaire on trust.

3. Patch operating systems

The question: is every operating system in the estate still vendor-supported?
Evidence to hold: a current inventory listing OS version and support status per host, including the internet-facing systems that sit outside the standard patch group. One unsupported server running something nobody wants to touch is a finding. Knowing about it, with a risk acceptance signed by someone senior, is a position.

4. Microsoft Office macro settings

The question: can a user open and run a macro-enabled document received from outside?
Evidence to hold: the result of a test send from an external address to a standard mailbox. If a department holds a macro exception for a legacy workbook, hold the scope of that exception too. A blanket exception written to accommodate one team is where this control quietly dies.

5. User application hardening

The question: is hardening applied to every device, or just the standard build?
Evidence to hold: an applied-policy comparison across device groups, including executive laptops and anything inherited through an acquisition. This is cheap configuration work and it is almost always half-done. The devices outside the standard build are exactly the ones attackers find.

6. Restrict administrative privileges

The question: who holds privileged access, and is every entry a current person or process?
Evidence to hold: a full privileged account export with a named, current owner against each entry. The first honest audit typically finds several times more admin accounts than anyone expected. The residue, accounts belonging to people and processes that no longer exist, is the finding.

7. Multi-factor authentication

The question: which authentication paths accept a password alone from an unmanaged device?
Evidence to hold: external test results covering every path you can find, including legacy webmail, service accounts with exemptions, and VPN fallback behaviour. MFA is assessed on coverage, not existence, which is how a strong implementation fails an assessment on one forgotten endpoint.

8. Regular backups

The question: how long does a full restore take, and has anyone actually done one?
Evidence to hold: a timed restoration record with sign-off from the business owner of the process. Credit is given for restoration, not retention. A backup that has never been restored end to end is a hope with a storage bill, and discovering an eleven-day restore during an incident is a different business decision than the one you thought you had.

Two things that turn a checklist into a position

First, know your maturity level and be able to say why. The model scores you at your weakest control, not your average, and the levels mean specific things. If that sentence is not familiar, read our explainer on how the Essential Eight maturity model actually works before the next questionnaire arrives.

Second, put a date on everything. Evidence ages. A privileged access export from eighteen months ago is an archaeology exhibit, not a control. The organisations that hold their level run a light quarterly self-check against this list and an independent re-assessment annually or after major change.

Any answer on this checklist that begins "we have a policy that" is a gap. If you have more gaps than you expected, that is normal, and it is fixable in a defined order. Our cyber security practice runs Essential Eight assessments scored against what exists rather than what is written, and a practitioner who does this work replies within one business day.