Essential Eight ML3 Readiness: A Self-Assessment Checklist

How to run an honest ML3 readiness self-assessment: the questions to ask per mitigation strategy, the evidence that counts, and the traps that produce false confidence.

A readiness self-assessment is the cheapest insurance an Essential Eight uplift program can buy — provided it is honest. This article gives you the structure: what to ask per mitigation strategy, what evidence actually demonstrates ML3, and where self-assessments go wrong. A downloadable checklist version accompanies this article on our resources page.

How to run it honestly

Three rules keep a self-assessment truthful. Assess the fleet, not the standard build — maturity is defined by your least-covered in-scope system, so the exceptions register is the assessment. Demand evidence, not assertion — coverage reports, timeframe metrics and test results, not control descriptions. Assess as an adversary would — the ML3 question is never “do we have the control” but “does it hold against a capable attacker”.

The questions that matter, per strategy

• Application control: Does enforcement cover workstations and servers? What executes from user-writable paths? Who can approve exceptions, and how many are open?
• Patch applications / operating systems: Can you demonstrate, with metrics, that internet-facing services with known exploited vulnerabilities are remediated within the tightest required timeframes? What is the mean time for everything else?
• Office macro settings: Are macros blocked except where there is a demonstrated business requirement, with those exceptions constrained and monitored? Which legacy process keeps the exception list open?
• User application hardening: Are the hardening settings enforced by policy and verifiable centrally — or documented and hoped?
• Restrict administrative privileges: Are privileged accounts separated from standard accounts, requests validated, and privileged environments protected? How much “temporary” access is permanent in practice?
• Multi-factor authentication: Is MFA phishing-resistant for the users and services ML3 expects? Where do legacy protocols bypass it?
• Regular backups: Have restoration tests been run this year? Can an attacker holding privileged credentials modify or delete backups?
• Across all eight: Is event logging centralised, protected and actually monitored?

The traps that produce false confidence

The recurring ones: assessing the SOE image while the exceptions run the business; counting deployed agents as enforced policy; timeframe metrics measured from ticket creation rather than vulnerability publication; backup “tests” that restore a file, not a business service; and treating the assessment as a compliance artefact to be passed rather than a risk instrument to be believed.

Key takeaways

• Your maturity level is your worst-covered system — assess the exceptions, not the average.
• Evidence beats assertion: coverage data, timeframes, test results.
• The download version structures this as a working checklist for your team.

Get the checklist resource, read the full ML3 practical path, or validate your self-assessment with an independent HEXOSYS assessment.