Maturity Level 2 is the de-facto baseline in Australian government contracts and supplier panels, yet most ML2 guidance stops at "implement the control". Assessors don't assess intentions — they assess evidence. This page walks each of the eight strategies at ML2 in substance, lists the artefacts an assessor will actually accept, and names the false-green trap that catches teams in each one. ASD's official material lives at cyber.gov.au — this page is the evidence layer to put underneath it.
ML1 tolerates partial coverage and manual assurance. ML2 asks for consistency: controls applied across the fleet, centrally enforced where the tooling allows it, and demonstrable at a point in time. That word — demonstrable — is the whole game. An assessor following ASD's assessment guidance will ask for exports, configurations and logs, not summaries. If your evidence is a paragraph describing the control rather than an artefact produced by the control, expect the finding to read "not able to be verified" — which scores the same as absent.
The pattern that works: for every strategy, hold a dated artefact produced by the enforcing system itself, plus a sample that shows the control acting on a real event. Below, strategy by strategy.
ML2 substance: application control enforced on workstations and internet-facing servers — executables, libraries, scripts and installers restricted to an approved set; annual (or better) rule review.
Evidence accepted: the enforcement policy exported from the tool (WDAC/AppLocker policy XML or equivalent) with deployment scope; a blocked-execution event log extract showing a real denial; the rule-review record with a date and a named reviewer.
False-green trap: audit-only mode. A policy in "audit" logs violations but blocks nothing — it reads as implemented in a screenshot and fails the first time an assessor asks for a block event.
ML2 substance: internet-facing services patched within two weeks of release (48 hours when an exploit exists); other applications within one month; a vulnerability scanner in use with defined cadences; unsupported applications removed.
Evidence accepted: scanner reports from two consecutive cycles showing detection-to-remediation timelines; the patch policy with its clock definitions; a worked example ticket trail from advisory to deployed patch with timestamps.
False-green trap: measuring from "when we noticed" instead of from vendor release. The ML2 clocks start at release, and an assessor will compute the gap from the advisory date, not your intake date.
ML2 substance: macros blocked for users without a demonstrated business need; macros from the internet blocked; antivirus scanning of macros; users cannot change the settings themselves.
Evidence accepted: the group policy or Intune configuration export showing the macro settings and their assignment scope; the documented, approved list of users with macro permissions and the business justification for each; a screenshot-with-date of an end-user attempting to enable a blocked macro.
False-green trap: a tidy policy with an unmanaged exception list. If the "users with a business need" set is stale or has no owner, the exception becomes the rule and the assessor will treat the control as not effectively implemented.
ML2 substance: web browsers hardened (no Java from the internet, no web advertisements processed by default), Internet Explorer 11 disabled or removed, browser and PDF security settings enforced centrally and unchangeable by users.
Evidence accepted: the hardening baseline (e.g. exported browser policy set) with deployment scope; a delta report against ASD or vendor hardening guidance; a user-session demonstration that the settings cannot be altered.
False-green trap: hardening applied to the SOE image but never audited on the fleet. Machines drift; an image screenshot from build day is not fleet evidence. Assessors ask "show me a current machine".
ML2 substance: privileged access requests validated when first requested and revalidated on a cycle; privileged accounts prevented from reading email and browsing the web; privileged operations conducted from separate privileged operating environments or via jump servers; unprivileged accounts cannot log on to privileged environments.
Evidence accepted: the current privileged-account inventory reconciled against HR/directory data; access-request and revalidation records for a sample of accounts; the technical control blocking mail/web for privileged accounts (policy export), plus a denied-access event.
False-green trap: the inventory that only grows. If nobody can show a privilege being removed on revalidation, the revalidation is ceremonial — and assessors read ceremony instantly.
ML2 substance: the same clocks as applications applied to operating systems — two weeks for internet-facing (48 hours when exploited), one month otherwise — with scanning cadence and no unsupported OS versions.
Evidence accepted: OS build/version report across the fleet from the management tool; scanner output showing missing-patch aging; the decommission or isolation record for any end-of-life OS still present.
False-green trap: the forgotten estate — appliances, hypervisors and that one server "scheduled for decommission" since last year. ML2 scope is the environment, not the machines you patch comfortably.
ML2 substance: MFA for all users on remote access and internet-facing services; MFA for privileged actions; phishing-resistant options preferred; authentication events logged.
Evidence accepted: the identity-provider policy export (conditional access or equivalent) with its assignment scope and exclusion list; an authentication log extract showing MFA challenges on real sign-ins; the exception register with expiry dates for every excluded account.
False-green trap: exclusions without expiry. "Break-glass" accounts, service accounts and executives accumulate in the excluded group; each one is an MFA bypass an assessor will count individually.
ML2 substance: backups of important data, software and settings run and retained per business criticality; restoration tested; privileged and unprivileged accounts prevented from modifying or deleting other accounts' backups.
Evidence accepted: the backup schedule and success/failure reports for a recent period; a dated restoration-test record with what was restored and how long it took; the access-control configuration protecting backups from modification, including for administrators.
False-green trap: restore tests that only ever restore a single file. A file-level restore proves the tape moves; it does not prove you can recover an operation. Test to the level you claim in your continuity documents.
Every artefact above ages. A policy export from eleven months ago tells an assessor what your environment used to be. The practical answer is to collect evidence the way the controls run — continuously — so that "show me a current machine" is a click, not a project. That is precisely how the CyberSentien engine treats the Essential Eight: per-control evidence chains, freshness tracked on every artefact, maturity assessed at ML1–ML3 against the full model, and the honest state shown when evidence is missing — a control without evidence reads "manual assessment required", never a fabricated pass. See the live model on the Essential Eight framework page.
Run an Essential Eight assessment on sample docs → Talk to us about ML2 readinessThe Essential Eight maturity model itself is published as guidance by ASD, but ML2 is routinely written into Australian government contracts, panel conditions and supplier security requirements — which makes it effectively mandatory for anyone selling into or servicing government, and increasingly common in regulated-industry supplier terms.
It depends almost entirely on two things: how centralised your management tooling already is, and how much exception debt you carry. Organisations with centrally managed fleets and disciplined exception registers typically measure the journey in months; environments with unmanaged endpoints measure it in quarters.
Per ASD's assessment guidance, they test the control as implemented: policy exports, configuration reviews, log samples and on-machine checks — not questionnaire answers. Evidence quality determines assessment speed and outcome.
Yes — self-assessment against the maturity model is normal, and ASD publishes assessment guidance to support it. The discipline that makes a self-assessment credible is the same one an external assessor applies: artefacts over assertions.
The strategies apply to what you control. In cloud environments that means your tenant configuration, identities, endpoints and data — the shared-responsibility boundary decides which artefacts are yours to produce and which belong to your provider's assurance.
Every capability referenced on this page is live on the CyberSentien engine — see it on the always-live gated demo. Nothing on this page is legal advice.