How an Essential Eight assessment is run, step by step

The Maturity Model groups controls under eight strategies: application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication and regular backups. Each strategy has requirements at Maturity Level One, Two and Three. The levels are cumulative, so a Level Two assessment tests the Level Two requirements on top of everything at Level One.

The method comes from ASD's Essential Eight Assessment Process Guide, first published in November 2022 and last updated in August 2024. It applies to the November 2023 release of the Maturity Model. ASD publishes a report template and an assessment toolkit alongside the guide, so two competent assessors working the same system from the same evidence should reach the same ratings.

No Commonwealth body certifies an organisation against the Essential Eight. The output is a dated report with a rating per control and per strategy, the evidence behind each rating, and the gaps between the current state and the target level. Tender panels, insurers and boards ask to see that report.

Stage one is planning with the system owner. The process guide lists what has to be settled before any testing:

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.

Managed service providers need early attention. 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.

The target level is a business decision. The level is usually set from what a contract, a tender or a regulator expects, and the assessment runs against that level.

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 grades evidence on four levels and asks assessors to use the highest quality reasonably practicable.

Three strategies have well-defined tests at the top evidence grades.

ASD's Essential Eight Maturity Verification Tool, E8MVT, and its Application Control Verification Tool are the reference scripts for endpoint evidence.

The process guide is direct on 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.

A policy stating that macros are blocked earns the lowest evidence grade. Opening a macro-enabled file from the internet on a sampled workstation and recording the block earns the highest. Running a test executable from a user profile folder confirms whether the application control ruleset blocks it.

Patching shows the gap clearly. The guide 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 assessor compares the hotfix list taken from the machine against the vendor's critical and exploited patches.

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.

Every control is rated with one of ASD's seven standardised outcomes.

The scoring rule is strict. To claim a mitigation strategy is implemented at a level, every control in that strategy at that level has to be rated effective or alternate control. One ineffective control means the requirements for that maturity level are not met. One strategy not implemented means the target maturity level for the system cannot be claimed.

Risk acceptance does not stand in 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.

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 exception record carries 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.

The security assessment report is the stage four output. It records the scope and any exclusions with their justification, the sample tested and any limits on testing, the outcome for each control and the evidence behind it, and the maturity level achieved for each strategy against the target.

The remediation roadmap is built from the controls that capped the result. It orders the work by what blocks the target level first, since a single ineffective control holds a whole strategy down. Each item names the control, the current finding, the change required and the evidence that will show it is fixed.

Patching is a common point of failure. 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.

Generate a hotfix list with PowerShell or WMIC on a few workstations and compare it against the patch console before the assessor arrives. If the installed list disagrees with the patch console, fix that before the assessment starts.

Black Shard runs Essential Eight assessments to the ASD process guide, with scripted testing across an agreed sample and a remediation roadmap tied to each capped control.