The Essential Eight Audit-Prep Checklist (With the Evidence Your Auditor Asks For)

Most of your Essential Eight audit is internal evidence a scan can't see. Seven of the eight strategies are endpoint, identity, or backup controls that are structurally invisible from the outside, an assessor validates them with policy exports, patch registers, MFA reports, and restore-test logs, not with a URL. This checklist walks all eight controls in the official ACSC order and, for each one, gives you three things: what to do, the exact evidence your auditor will ask for, and a one-line self-check question. Run the free Audit-Readiness Check first to confirm the thin externally-observable slice (headers, TLS, DNS) in 30 seconds, then use this checklist for everything a scan can't reach.

Why Most of Your Essential Eight Is Invisible to a Scan

The Essential Eight is the Australian Signals Directorate's baseline of eight mitigation strategies, scored across four maturity levels (ML0–ML3). When you engage an assessor, or self-assess ahead of one, they are not looking for a passing security scan. They are looking for evidence that each control is configured, enforced, and operating over time.

Here's the part teams underestimate: a passive external scan can observe almost none of it.

Application allowlisting, macro policy, admin privilege separation, MFA enforcement, and backup immutability are all decisions made inside your environment, on endpoints, in your identity provider, in your backup platform. They leave no trace in an HTTP response, a TLS certificate, or a DNS record. That is not a limitation of any particular scanner; it is the nature of the controls.

So treat the external scan as step zero, a fast way to confirm the one visible slice and catch obvious hygiene gaps, and treat this checklist as the real work. The next eight sections are the prep a consultant would otherwise charge you for.

E8-1 · Application Control

Application control allowlists what is permitted to execute so unapproved or malicious code simply can't run. ML1 allowlists execution in user-writable paths; ML2 enforces everywhere including servers; ML3 adds Microsoft-recommended block rules, driver control, and centrally-logged validation.

Externally observable? No. Allowlisting is an endpoint execution-control decision (WDAC, AppLocker, or equivalent) made on the host. It leaves no trace in HTTP, TLS, or DNS, a scan cannot see it at all.

What to do:

Evidence your auditor asks for: An allowlisting ruleset export, proof of enforce mode (not audit-only), a sample blocked-execution log, and the ruleset-change/approval record.

The distinction between audit-only and enforce is where teams most often lose marks, a policy deployed in audit mode logs violations but blocks nothing, and an assessor will read that as unenforced. Confirm the mode before you confirm anything else.

E8-2 · Patch Applications

This control is about closing known vulnerabilities in your applications within defined timeframes. ML1 patches internet-facing apps within two weeks (48 hours if actively exploited) and runs a vulnerability scanner; ML2 tightens to 48 hours and adds other apps within one month; ML3 removes unsupported apps and scans daily.

Externally observable? Effectively no. A Server or X-Powered-By banner may leak one component's version, but banners are trivially spoofed, commonly stripped, and reflect a single edge component, not your estate's patch state, and not whether your process meets the timeframes. Treat a banner as a lead, never as coverage.

What to do:

Evidence your auditor asks for: Dated vulnerability-scan reports and a patch register showing detection-to-remediation timeframes against SLA, plus vendor-support status per app.

The word that matters here is timeframe. "We patch regularly" is a claim; a register showing a vulnerability detected on the 3rd, patched on the 5th, and re-scanned clean on the 6th is evidence. Assessors read the gap between detection and remediation dates, so your register needs both columns.

E8-3 · Configure Microsoft Office Macro Settings

Macros are a classic malware delivery vector, so this control locks them down. ML1 disables macros for users with no need and blocks internet macros; ML2 allows macros only from Trusted Locations or signed, plus logging; ML3 adds AMSI macro scanning and blocks Win32 API calls from macros.

Externally observable? No. Office macro policy is a Group Policy or Intune configuration on managed devices. It never surfaces in a web response, certificate, or DNS record.

What to do:

Evidence your auditor asks for: A GPO/Intune macro-policy export, a screenshot of the enforced setting on a sample device, and macro-execution log samples.

If your organisation genuinely doesn't run Microsoft Office, this control can be scoped out, but don't leave that implicit. Write down the N/A justification, because an assessor who sees a blank against E8-3 will ask, and "we forgot to note it" reads worse than a documented exclusion.

E8-4 · User Application Hardening

This is the one control with any external signal at all, which makes it the most misunderstood. User application hardening reduces the attack surface of the apps your people use daily. ML1 blocks Flash, ads, and Java in browsers and disables legacy IE; ML2 hardens Office/PDF (block child processes, disable OLE) and logs PowerShell; ML3 adds full hardening guidance, PowerShell Constrained Language Mode, and blocked/logged command-line activity.

Externally observable? Partially, and only weakly. Response security headers (CSP, X-Frame-Options, HSTS, X-Content-Type-Options) are the server hardening the content it serves to browsers, which our finding-to-control mapping ties to E8-4. A scan can see the presence and quality of those headers on the scanned origin. It cannot see, and must not imply, endpoint browser config, Flash/Java/plugin state, Office/PDF hardening, or PowerShell logging, which are the actual substance of E8-4.

What to do:

Evidence your auditor asks for: A browser/endpoint hardening baseline (GPO/Intune export), evidence that Flash/Java are disabled and PowerShell logging is on, plus the server header config. Auditors weight the endpoint evidence far above the headers.

The server-side half of this control is the one thing this whole framework lets you verify from outside in seconds. Check your response headers with the free header checker to confirm that slice, then put the endpoint hardening baseline together, because that is what actually moves your maturity score.

E8-5 · Restrict Administrative Privileges

Admin rights are the keys to the kingdom, so this control limits who holds them and how they're used. ML1 validates privileged access and stops admins browsing web/email from privileged accounts; ML2 adds just-in-time or limited-duration privileges, separate privileged environments, and logging; ML3 adds privileged access workstations and regular revalidation.

Externally observable? No. Who holds admin rights, whether admin accounts are separated from daily-use accounts, and whether privileged sessions are isolated are internal identity/IAM facts no external probe reveals.

What to do:

Evidence your auditor asks for: A privileged-account inventory with justification, evidence of separate admin accounts, access-request/approval records, a periodic privileged-access review, and privileged-activity logs.

The single most common failing here is the standing admin account that doubles as someone's day-to-day login. If your DevOps lead reads email from the same account that holds domain admin, that is a documented gap, regardless of how tightly everything else is configured.

E8-6 · Patch Operating Systems

The operating-system twin of E8-2, with the same timeframes applied to the OS layer. ML1 patches internet-facing OS within two weeks (48 hours if exploited), scans for missing patches, and uses supported versions; ML2 tightens to 48 hours plus other OS within one month; ML3 runs latest-or-N-1 releases and scans daily.

Externally observable? Effectively no. As with E8-2, a server banner may hint at an OS or web-server build, but it is spoofable, often stripped, reveals one host's edge component, and says nothing about whether OS patching meets ACSC timeframes across the fleet.

What to do:

Evidence your auditor asks for: An OS asset inventory, dated OS vulnerability-scan output, an OS patch register showing timeframes vs SLA, and proof all OS versions remain vendor-supported.

Watch for the quiet ML1 failure: a single end-of-life appliance or an unsupported OS on a forgotten server. Vendor-support status is a hard requirement even at the lowest maturity level, so one out-of-support host can cap your score no matter how current everything else is.

E8-7 · Multi-Factor Authentication

MFA is the control most people assume a scan can check, and it can't. ML1 requires MFA for internet-facing services and customers accessing sensitive data; ML2 adds MFA for all privileged users and third-party services, phishing-resistant for some access, with logging; ML3 requires phishing-resistant MFA everywhere.

Externally observable? No, nothing reliable. A login page may be discoverable, but whether MFA is enforced, for which users, with what factor strength, and whether it's phishing-resistant, cannot be determined without authenticating. Never infer MFA from a login form's existence.

What to do:

Evidence your auditor asks for: An IdP MFA policy/config export, a per-user MFA enrolment report, evidence of factor type (phishing-resistant vs SMS), and authentication logs.

The enrolment report is what separates a claim from evidence: "MFA is enabled" often means enabled and available, not enforced for everyone. Pull the per-user report and look for the accounts that were exempted, grandfathered, or never enrolled, those are exactly what an assessor samples for.

E8-8 · Regular Backups

Backups are your last line of defence against ransomware, and the control it's most dangerous to guess about. ML1 backs up important data/software/config per a defined frequency and retention and tests restoration; ML2 stops unprivileged accounts accessing or modifying other users' backups and tests restores in DR exercises; ML3 prevents unprivileged and backup-admin accounts modifying or deleting backups (immutability) with comprehensive restore testing.

Externally observable? No, and this is the one it's most dangerous to guess about. Backup existence, frequency, retention, access controls, immutability, and restore-test status are entirely internal operational facts no external scan can observe.

What to do:

Evidence your auditor asks for: A backup policy (frequency + retention), backup job success logs, access-control/immutability config on backup stores, and a dated restore-test / DR-exercise report.

The evidence auditors most often find missing is the restore test. Backup jobs that report success prove data went in; only a dated restoration test proves it can come back out. If you assemble one artefact from this section, make it the restore-test report.

Your One-Page Audit-Prep Checklist

Copy this into your prep tracker. Each item maps to one control's headline evidence artefact, assemble these before your assessor arrives and the assessment becomes a review, not a scramble.

Where a Scan Fits (and Where It Doesn't)

To be clear about the boundary: an external scan is useful for exactly two things in this process. It confirms the server-side half of E8-4, your response security headers, and it surfaces obvious internet-facing hygiene issues (expired certificates, exposed services) that would embarrass you in front of an assessor. That's genuinely worth 30 seconds.

What a scan does not do, and what no honest tool should claim, is verify Essential Eight compliance. Seven of eight controls are unobservable from outside, and even the eighth is only partially and weakly visible. A pentest goes deeper than a scan, but it validates whether controls resist attack; it still doesn't replace the configuration and operational evidence an assessor collects.

So run the external check to close the visible slice, then spend your real effort on the eight evidence artefacts above. That sequencing, cheap external confirmation first, internal evidence assembly second, is the fastest path to an audit you can walk into with confidence.

Add the Checklist Badge to Your Repo

Working through the eight controls with your team? Drop this badge in your repository README, internal wiki, or compliance runbook, it links straight to the free Audit-Readiness Check so the next person starts from the same place.

Markdown:

HTML:

Frequently Asked Questions

The Essential Eight is maintained by the Australian Signals Directorate. This checklist reflects the ACSC Essential Eight Maturity Model as of July 2026. For the official framework documentation, visit cyber.gov.au. This guide helps you prepare evidence; it is not an assessment and does not certify compliance.