Home โ€บ Insights โ€บ ASD Essential Eight: Practitioner's Guide
๐Ÿ“‹ Practitioner Guide ยท IRAP-Certified Assessors

ASD Essential Eight: A Practitioner's Guide to Maturity Level Assessment

Written by IRAP-certified assessors who have conducted assessments across Commonwealth agencies and regulated-sector entities. This is what preparation looks like from the inside of the assessment process โ€” not from a vendor's compliance checklist.

8 Mitigation strategies assessed
ML0โ€“ML3 Maturity levels in scope
22% Commonwealth entities at ML2+ across all 8
40+ Assessments conducted by our team

Why an assessment is not what most organisations expect

The Essential Eight Maturity Model is widely misunderstood โ€” and that misunderstanding is expensive. Most organisations approach assessment as a documentation exercise. Assessors approach it as a control effectiveness exercise. The gap between those two framings is where assessment surprises happen.

ASD's assessment guidance is unambiguous on this point: demonstrated evidence ranks above policy documents, verbal assurance and screenshots. An assessor is not satisfied by a policy that says patching happens within 48 hours. They want to see the scan outputs, the remediation tickets, the exception records and the dates. If the evidence cannot prove what was done, the control is not assessed as implemented โ€” regardless of what management believes.

This guide is written from the assessor's perspective. It covers what assessors are trained to look for, the evidence they expect to see at each maturity level, and the preparation steps that reliably separate organisations that pass from those that are surprised by the outcome.

"An assessor is not satisfied by a policy that says patching happens. They want to see the scan outputs, the remediation tickets, the exception records and the dates."

The maturity model โ€” what each level actually requires

The four maturity levels are not a spectrum from "basic" to "advanced." They represent qualitatively different threat models. ASD's design principle is that an organisation must implement all eight strategies at the same maturity level before claiming that level โ€” because an attacker does not compromise the average of your controls. They compromise the easiest path.

ML0
Not Implemented

Controls are absent or implemented so ineffectively that they provide no meaningful protection against the threat vectors they are designed to address.

ML1
Opportunistic Adversaries

Controls mitigate adversaries using commodity, automated techniques. Assumes the attacker is not specifically targeting the organisation. Baseline for most entities.

ML2
Targeted Adversaries

Controls mitigate adversaries willing to invest effort in targeted attacks using standard techniques. Required for entities handling OFFICIAL: Sensitive data.

ML3
Sophisticated Adversaries

Controls mitigate adversaries with significant resources using advanced techniques including supply chain compromise and zero-day exploitation. Required for PROTECTED data.

The most common assessment failure is not implementing controls badly. It is implementing them at ML2 on managed devices while leaving cloud services, legacy systems and vendor-supplied infrastructure at ML0 โ€” and claiming ML2 overall. Assessors are specifically trained to find the boundary exceptions.

What assessors actually test โ€” strategy by strategy

Understanding what an assessor expects to see for each of the eight strategies is the most practical preparation step available. The following covers the key questions an assessor asks and the evidence they need to answer them โ€” based on ASD's published assessment guidance and direct assessment experience.

ASD Evidence Hierarchy โ€” Highest to Lowest Weight

1 Simulated testing Demonstrated control behaviour under test conditions โ€” highest confidence that the control actually works
2 Configuration review Direct review of system configuration against policy โ€” confirms implementation matches intent
3 Tool output / scan results Date-stamped outputs from scanning, monitoring or enforcement tools โ€” strong operational evidence
4 Log review Review of operational logs confirming control events occurred โ€” useful but depends on log integrity
5 Documentation / policy review Policy documents, procedures and plans โ€” necessary but insufficient without corroborating operational evidence
6 Interviews / verbal assurance Weakest form of evidence โ€” cannot be relied upon without corroboration from higher-ranked sources
1
Application Control

Assessors test whether execution of unauthorised programs, scripts, libraries and installers is actually blocked โ€” not just whether a policy says it should be. They will attempt to execute test payloads and review the ruleset for gaps. Living-off-the-land paths (PowerShell, WScript, MSHTA) are specifically tested at ML2 and ML3.

Evidence needed

Application control tool configuration export ยท blocked execution logs ยท ruleset review with exception register ยท demonstration of blocking in test environment

2
Patch Applications

Assessors look for automated asset discovery running at least fortnightly, a vulnerability scanner producing dated outputs, and evidence that findings are remediated within the required timeframes (2 weeks for internet-facing critical, 1 month for others at ML1). They check that exceptions are documented, owned and have compensating controls.

Evidence needed

Dated vulnerability scan outputs ยท patch deployment logs ยท exception register with owner and due date ยท asset discovery configuration showing fortnightly cadence

3
Office Macro Settings

Assessors check that macros from the internet are blocked, that only macros from trusted locations or with trusted signatures are permitted, and that users cannot override this through settings. At ML2, macros must be disabled for users who do not have a demonstrated business need.

Evidence needed

Group Policy / Intune configuration export ยท test of macro execution from internet-sourced document ยท list of approved macro publishers and locations

4
User Application Hardening

Web browsers, PDF viewers and other user applications must be configured per ASD hardening guidance. Assessors test specific settings โ€” Flash disabled, Java disabled from the internet, web advertisements blocked at ML1. At ML2 and ML3, the scope extends to office productivity suites and operating system components.

Evidence needed

Browser/application configuration exports ยท hardening checklist signed off against ASD guidance ยท demonstration of blocked content types

5
Restrict Administrative Privileges

Assessors request a list of all privileged accounts and verify that administrative access is limited to those with a documented business requirement. At ML2, privileged accounts must not be used for email or web browsing. At ML3, privileged access workstations are required for sensitive tasks.

Evidence needed

Privileged account register with business justification ยท access control configuration showing separation of admin and standard accounts ยท PAW or jump server configuration at ML3

6
Patch Operating Systems

Similar to application patching but specifically for OS-level vulnerabilities. Assessors check that internet-facing systems running end-of-life operating systems are either patched, compensating-controlled or decommissioned. Unsupported OS versions with no patch available are scored as exceptions requiring documented risk acceptance.

Evidence needed

OS inventory with version and patch status ยท scan outputs showing patch currency ยท exception register for EOL systems ยท network segmentation evidence for unsupported systems

7
Multi-Factor Authentication

Consistently the lowest-scoring strategy in ASD's Commonwealth posture data. Assessors specifically check phishing-resistant MFA (not just SMS or TOTP) on internet-facing services at ML2+. They test whether MFA is enforced โ€” not just enrolled โ€” and whether privileged accounts, VPN, remote desktop and data repositories are all covered.

Evidence needed

MFA configuration for all internet-facing services ยท demonstration of enforcement (not just enrolment) ยท list of phishing-resistant MFA exceptions with mitigating controls

8
Regular Backups

Assessors focus on three things: whether backups exist for all important data, whether they are stored in a way that protects them from a ransomware event (offline or immutable), and whether restoration has been tested. A backup that has never been successfully restored is not a recovery capability. Restoration test records with dates and scopes are required evidence.

Evidence needed

Backup configuration and retention policy ยท dated restoration test records ยท evidence of offline or immutable storage ยท access control evidence showing user inability to modify or delete backups

"A backup that has never been successfully restored is not a recovery capability. It is a hopeful archive with good intentions."

Preparing for assessment โ€” the practical approach

Assessment preparation is not about producing documentation. It is about closing the gap between your actual control state and your claimed maturity level โ€” before an assessor finds it for you. The following preparation sequence has been refined across 40+ assessments.

1
Define your system boundary in writing

The scope of assessment must be agreed before any evidence is collected. Ambiguous boundaries are the single most common cause of scope creep and assessment surprises. Document which systems, applications, cloud services, vendor platforms and third-party connections are in scope โ€” and name an owner for each one at the boundary edge.

2
Run a self-assessment using tools, not interviews

Before engaging an assessor, run your own tool-based assessment against each of the eight strategies. Use the same evidence hierarchy an assessor uses โ€” configuration exports, scan outputs, log reviews. If you cannot produce the evidence internally, an assessor will find the same gap. Better to find it yourself first.

3
Build an exception register before assessment begins

Every control gap that cannot be remediated before the assessment must be documented as a formal exception โ€” with the system affected, the risk accepted, the compensating controls in place and the owner responsible. Undocumented gaps found by an assessor score worse than documented ones with risk acceptance.

4
Test your restoration capability before the assessment

Backup restoration is consistently the easiest strategy to claim and the hardest to evidence. Run a restoration test, document the date, scope and outcome, and ensure the record is accessible to the assessor. If you have not tested restoration recently, do it before engaging an assessor โ€” not after they find the gap.

5
Prepare a test environment for simulated control testing

Assessors will want to demonstrate controls in action where possible. Having a test environment that reflects your production configuration โ€” where application control, macro blocking and user hardening can be demonstrated safely โ€” significantly accelerates the assessment and provides the highest-quality evidence.

6
Prepare your privileged account register

One of the most common assessment activities is a review of privileged accounts. Prepare a current export of all accounts with administrative privileges, the business justification for each, and the review cadence. Undocumented admin accounts โ€” particularly service accounts and vendor accounts โ€” are a reliable source of ML2 findings.

The six most common assessment surprises โ€” and how to avoid them

  • Cloud services scoped out of the assessment boundary but accessible from in-scope systems โ€” assessors check connectivity, not just documentation
  • MFA enforced on external-facing systems but not on internal privileged access paths โ€” both must be covered for ML2 credit
  • Application control policy applied to managed devices but not to shared workstations, kiosks or developer build systems within the boundary
  • Patch compliance data showing 95%+ coverage โ€” but the 5% uncovered includes internet-facing systems that should be remediated within 48 hours of patch release
  • Backup configuration confirmed but restoration never tested โ€” or tested once two years ago with no current evidence
  • Privileged account review conducted annually โ€” but service accounts and vendor accounts not included in the scope of that review

The organisations that do best in assessments are not the ones with the most controls. They are the ones that know their boundary, can demonstrate their controls work, and have documented every exception honestly.

Source Material
  • Australian Signals Directorate. Essential Eight. cyber.gov.au
  • Australian Signals Directorate. Essential Eight Maturity Model. cyber.gov.au
  • Australian Signals Directorate. Essential Eight Assessment Process Guide. cyber.gov.au
  • Australian Signals Directorate. The Commonwealth Cyber Security Posture in 2025. cyber.gov.au
  • Australian Signals Directorate. Information Security Manual (ISM). cyber.gov.au
๐Ÿ“‹

Download the Full Practitioner's Guide โ€” PDF

ASD Essential Eight: A Practitioner's Guide to Maturity Level Assessment ยท GadgetAccess Advisory ยท April 2026 ยท 18 min read

โฌ‡ Download PDF
Related Insights

Ready to prepare for your Essential Eight assessment?

Our IRAP-certified, NV1-cleared assessors have conducted Essential Eight assessments across Commonwealth agencies and regulated-sector entities. We can conduct an independent baseline assessment and build the evidence-based uplift programme you need.