To prepare for an Essential Eight assessment, choose a target maturity level, apply it evenly to all eight mitigation strategies, test each one on real systems and keep dated proof that it works. Assessors verify what is deployed, so a policy without matching configuration and logs will not carry you.
What is the Essential Eight, and what is the maturity model?
The Australian Signals Directorate (ASD) publishes the Essential Eight as a set of eight mitigation strategies and a maturity model for measuring how well an organisation applies them. The model was first published in June 2017 and is updated regularly. It is meant for internet connected Windows based networks in the first instance and is applied with a risk based mindset. Maturity is expressed in levels starting at zero. ASD advises choosing a target level and reaching the same level across all eight strategies before moving to a higher one.
Source note: we reached ASD's maturity model page only through search results, and the full page timed out on fetch. The eight strategies below follow ASD's published list. The exact test conditions and timeframes for each level change between model versions, so read the current document and do not rely on any third party summary for numbers.
The eight strategies are application control, patching applications, configuring Microsoft Office macro settings, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups.
How is an assessment different from a self-check?
A self-check asks whether you do something. An assessment asks whether you do it everywhere in scope, can show it and can keep it going. Assessors typically sample endpoints and servers, ask for configuration exports and logs, and look at exceptions. Anything outside the scope you declared is a question about your boundary, so declare the scope plainly.
How do you build the evidence pack?
Take one strategy at a time. For each, record the target level, the scope, the control in place, the proof and the exceptions with owners.
Application control. Evidence is the allow list policy as deployed, which paths and publishers are permitted, how new software is approved, and logs of blocked executions. Test by trying to run an unapproved executable from a user folder.
Patching applications and operating systems. Evidence is the inventory with versions, patch tool reports showing install dates, and the process for emergency patches. Include internet facing services, which models treat as the most urgent. Check the model for the current timeframe at your target level.
Office macros and application hardening. Evidence is the group policy or device management setting, and a sample of machines showing the setting applied. Test with a macro enabled document from the internet.
Administrative privileges. Evidence is a list of privileged accounts, the request and approval workflow, separation of admin accounts from daily accounts, and a review log. Look for admin rights on everyday user profiles, the most common finding.
Multi-factor authentication. Evidence is the policy in your identity provider, a report of users enrolled, and the list of exceptions. Include remote access, cloud services and privileged actions.
Backups. Evidence is the schedule, the retention, protection from tampering by ordinary accounts, and a dated restore test.
What does the order look like?
Start with asset inventory and scope, since you cannot patch or restrict what you cannot list. Then tackle multi-factor authentication and admin privileges, which reduce risk fastest. Next patching and application control, which need rollout planning. Do the macro and hardening settings alongside, since they are mostly policy changes. Finish with the restore test and a trial assessment.
What mistakes sink assessments?
- Meeting the target on servers but not on a long tail of laptops.
- Counting a strategy as met while exceptions have no owner or expiry.
- Evidence screenshots with no date or machine name.
- Reaching high maturity on one strategy while another sits at zero, which the model advises against.
- Forgetting contractors and shadow admin accounts.
What to do
- Pick a target maturity level and write the scope.
- Build the inventory of endpoints, servers and cloud identities.
- Read the current ASD maturity model and extract the test points for your level.
- For each strategy record control, proof and exceptions.
- Run your own sampling test on ten machines per strategy.
- Fix gaps, give each exception an owner and an end date.
- Save the pack and repeat on a schedule.
Quick check
Do I have to reach the same level on every strategy?
ASD advises aiming for the same maturity level across all eight strategies before moving to a higher level.
Is the Essential Eight a certification?
It is a mitigation set with a maturity model published by ASD. Assessment against it is performed by an assessor you engage, and results describe your maturity level.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Two of the eight strategies, patching applications and application hardening, tie closely to the software you build and run, and Safeguard produces technical evidence from your real code and dependencies through scans, SBOMs and reachability. Monitoring keeps running between assessments, saving the team from re-collecting proof each cycle. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you decide which categories run automatically and at what approval level. The assessor makes the judgement. Safeguard helps you prepare and keep evidence ready.
Sources
- ASD Essential Eight maturity model, cyber.gov.au, reached through search on 18 October 2026; full page fetch timed out
Last reviewed: 18 October 2026.
