What is an Essential Eight assessment?
An Essential Eight assessment measures how well an organisation has implemented the eight mitigation strategies in the Australian Signals Directorate's Essential Eight Maturity Model, against a target maturity level. The method comes from ASD's Essential Eight Assessment Process Guide, first published in November 2022 and last updated in August 2024, which applies to the November 2023 release of the maturity model.
The guide sets out four stages. The assessor plans and prepares, determines the scope and approach, assesses the controls for each mitigation strategy, and writes the security assessment report. ASD publishes a report template and an assessment toolkit alongside it, so two competent assessors working the same system should reach the same ratings from the same evidence.
No Commonwealth body certifies an organisation against the Essential Eight. The output of an assessment is a dated report with a rating per strategy, the evidence behind each rating, and the gaps between the current state and the target level. That report is what a tender panel, an insurer or a board asks to see.
What gets agreed before the assessment starts?
Stage one is planning with the system owner. The process guide lists what has to be settled: the assessment boundary and approach, access to unprivileged and privileged accounts, devices, documentation, people and facilities, and any approval needed to run scripts and tools on the system. It also covers how evidence is collected and protected, where the report is written, which service providers manage parts of the system, any prior assessment reports, and how both parties may use and retain the report.
Stage two fixes the scope and the target maturity level. Anything excluded from scope is recorded in the report with a justification. An organisation that leaves its server fleet or a second tenancy out of scope can still be assessed, and the exclusion travels with the result to every reader of the report.
The managed service provider question matters more than most organisations expect. Where an IT provider administers the endpoints, the patching tool or the backup platform, the assessor needs read access to those consoles and a named contact who can answer for their configuration. Arranging that during planning saves days in stage three.
How many machines does an assessor test?
The process guide asks for a reasonable representative sample of workstations, including laptops, servers and network devices, with the sample size agreed with the system owner. It is direct about method: assessments run on interviews, reports and screenshots will always be inferior to assessments run with scripts and tools, because scripts and tools cover many machines at once and catch issues that interviews and manual review miss.
ASD's Essential Eight Maturity Verification Tool, E8MVT, and its Application Control Verification Tool are the reference scripts. For patching, the guide names E8MVT alongside Nessus Essentials, Nexpose Community Edition, OpenVAS and Qualys Community Edition, and warns that Windows Server Update Services does not necessarily report accurate patch levels.
WSUS can show an update as deployed when it is stuck, failed or waiting on a reboot. The guide asks for a hotfix list generated by PowerShell or WMIC, compared against the patches for vulnerabilities the vendor rates critical or that are being exploited.
Any limit on sample size or technical testing is written into the report. A rating built on one workstation reads differently to one built on a fleet-wide script run, and a careful reader of the report will see which one they are holding.
What counts as evidence?
The guide grades evidence on four levels and asks assessors to use the highest quality reasonably practicable.
The practical consequence is that a policy document saying macros are blocked earns the lowest grade. Attempting to open a macro-enabled file from the internet on a sampled workstation, and recording that it was blocked, earns the highest. The same applies to application control: an assessor running a test executable from a user profile folder learns more in a minute than a week of reading the allowlisting standard.
| Grade | What it means | Example |
|---|---|---|
| Excellent | Testing a control with a simulated activity designed to confirm it is in place and effective | Running a test application to check the application control ruleset |
| Good | Reviewing the configuration through the system's own interface | Reading the macro settings in the Microsoft 365 admin centre or Intune |
| Fair | Reviewing a copy of the configuration | A report or a screenshot of the same settings |
| Poor | A policy or verbal statement of intent | A control mentioned in documentation or described in an interview |
Evidence quality in the Essential Eight Assessment Process Guide
What are the seven assessment outcomes?
Every control is rated with one of ASD's standardised outcomes: not assessed, effective, alternate control, ineffective, no visibility, not implemented, or not applicable. Alternate control means the organisation meets the control's objective through a different control. No visibility means the assessor could not see enough of the implementation to judge it.
The rule that decides a maturity claim is strict. To claim a mitigation strategy is implemented, every control in that strategy has to be rated effective or alternate control. One ineffective control means the requirements for that maturity level are not met, and one strategy not implemented means the target maturity level for the system cannot be claimed. Assessment guidance is cumulative, so a Maturity Level Three assessment tests the Level Three requirements on top of everything at Levels One and Two.
Risk acceptance does not substitute for a strategy. The guide states that an assessor should not accept a risk decision as the reason an entire strategy, such as application control or multi-factor authentication, is missing. Without adequate compensating controls the strategy is rated not implemented.
How are exceptions and compensating controls judged?
An exception survives assessment when it is documented, approved by an appropriate authority through a formal process, and backed by compensating controls that give an equivalent level of protection. The process guide expects the exception record to carry the detail, scope and justification for the exception, and the same for each compensating control, including how long the compensating control is expected to last.
ASD gives two worked examples. A low-risk Windows server that could not be patched, with a decommissioning date two months out, a named risk owner and strong compensating controls, did not stop the organisation reaching its target level. A cloud service left without multi-factor authentication because enabling it was judged not worth the effort, with no compensating control, did stop it.
In practice the exception register is one of the first documents an assessor asks for. An organisation with three well-documented exceptions is in a stronger position than one claiming none whose script output shows a dozen.
Where do assessments usually land short of the target?
The same controls fail across most environments. Patching evidence fails on the gap between what the patch tool reports and what the machine has installed, and on internet-facing services that missed the 48-hour window for a critical or exploited flaw. Application control fails on writable paths inside an allowed folder.
Privileged access fails on administrators who still read email with the same account they use to administer, and on accounts never revalidated. Backups fail at Maturity Level Two and above when privileged accounts outside the backup administrators can still delete or modify backups.
Logging is the other common gap from Maturity Level Two. The model asks for event logs to be protected from modification and deletion, analysed in a timely manner, and acted on through an incident response plan. An organisation that collects logs and never reads them holds data, and the assessor rates the control on whether the analysis happens.
- Patch levels taken from WSUS or an RMM dashboard and never checked against the installed hotfixes on sampled machines.
- Internet-facing services patched on the fortnightly cycle instead of within 48 hours when a working exploit exists.
- Application control in audit mode, or enforced with user-writable folders inside allowed paths.
- Privileged accounts with mailboxes and web access, and no revalidation date on any privileged assignment.
- Backups a domain or cloud administrator can delete without being a backup administrator.
- Logs centralised and never analysed, with no record of an event having been reviewed.
What should be in the report you hand a buyer?
A report that holds up in procurement names the system, the scope and exclusions, the target maturity level, the assessment dates, the sample and tools used, and the outcome for every control with the grade of evidence behind it. It lists exceptions with their compensating controls and approvals, and it states the maturity level achieved per strategy. Buyers increasingly ask for the date of the assessment as well as the level, because a rating from two years ago describes a different estate.
Black Shard runs its own estate at Essential Eight Maturity Level Three, assessed in September 2026, and assesses client environments to the same process guide. An Essential Eight assessment rates all eight strategies against the target level with scripted evidence wherever the environment allows, and the gap list becomes an uplift plan ordered by what blocks the claim. Scope and timeframe are agreed on a free 30-minute scoping call.