Essential Eight maturity levels

The ISM v2026.09.4 Essential Eight baseline profiles contain 46 controls at Maturity Level One, 87 at Maturity Level Two and 123 at Maturity Level Three. Moving from ML1 to ML2 therefore roughly doubles the number of ISM controls an assessor will test. The profiles nest: every ML1 control also appears in ML2, and all but three ML2 controls appear in ML3. The three exceptions are ISM-1691, ISM-1695 and ISM-1873, which ML3 drops because it replaces each with a stricter version. A practical consequence is that work done for ML1 carries forward, but any control you already satisfied in a weaker form may need to be re-evidenced at the higher level.

Treat these counts as a checklist for assessors, not a measure of effort. A single control can be trivial to satisfy in one environment and involve a multi-quarter project in another, depending on how many systems, accounts and business units it touches. The ML2 jump is driven by controls such as central logging, phishing-resistant MFA for staff and jump servers for administration, which require new platforms and processes rather than configuration changes. Use the counts to scope your assessment checklist, then estimate effort strategy by strategy against your own estate.

Confirm the counts against the current ISM OSCAL release before you rely on them, because ASD updates the ISM and the profiles change with it. Download the Essential Eight profiles from the ISM OSCAL repository and check the control IDs in your scope against the version your assessor will use. Record the release version in your evidence register so that a later assessment is tested against the same baseline.

Central logging is the ML2 requirement that most often holds up the rest of the program, because several other controls only count as met once their events reach a store the organization controls. The ML2 profile requires central logging of application control, PowerShell, command line, privileged access and MFA events, along with protection of the event logs themselves (ISM-1660, ISM-1623, ISM-1889, ISM-1509, ISM-1683, ISM-1815). A privileged access review, an MFA scope claim or an application control exception cannot be demonstrated to an assessor from a workstation's local log alone. Plan the logging build alongside the MFA and privileged access work, not after it.

Before any collector is installed, the organization has to make four decisions. First, the log sources: each endpoint class, domain controller, jump server, internet-facing server and identity provider needs an owner and a named event set. Second, retention: the ISM controls require the logs to be protected, but the retention period is a decision you set with your legal, incident response and assessor input, and you should confirm the period your assessor expects rather than assume one. Third, who reviews the events and how often, since ML2 also expects timely analysis of internet-facing server logs (ISM-1906). Fourth, the escalation path: incidents must be reported to the CISO and to ASD (ISM-0123, ISM-0140), so the reporting route and its owner must be written down before an incident occurs.

The practical bottleneck is usually the gap between collection and analysis. A log store that receives events but has no alerting rules, no review roster and no tested escalation route will pass a configuration check and still fail the effectiveness test. Ask any implementation partner to show evidence of a working path from a privileged access event to a reviewed ticket, and ask your independent assessor which evidence they will sample. Protection of the event logs also needs its own access model, so administrators who manage the systems being logged are not the only people who can alter the logs.

A maturity level is not a state the organization reaches and keeps by default. It is held by recurring tasks that someone performs on schedule and can show evidence for. The recurring tasks that matter most are vulnerability scanning on the cadence each strategy sets, privileged account reviews, backup restore tests, and log reviews. Once an uplift project closes, each of these becomes a standing duty with a named owner, usually the security operations team for scanning and log review, identity administrators for privileged account reviews, and the backup or infrastructure team for restore tests. Before handover, confirm the cadence for each task against the ISM Essential Eight profile for your target level, because an assessor will check whether the recurring work happened, not only whether the tool was configured.

Ownership is the point that is easiest to miss at handover. A partner can configure central logging, scanning and immutable backups, and can document the procedures, but it cannot perform the reviews, approve privileged access, or sign off restore results on your behalf. Ask for a written handover that lists each recurring task, its frequency, the role that performs it, where the evidence is stored, and what the escalation path is when a task is missed. If a scanning run fails or a restore test does not complete, your team needs to know who decides whether the level is still met.

Plan the recurring workload into the operating budget before you commit to a level, not after. Scanning, log retention, restore testing and access reviews consume staff time every period, and the effort grows as the estate grows. Your team should also confirm with the Australian Signals Directorate's current maturity documentation how often each strategy must be re-assessed and what counts as evidence for an assessor. Where recurring tasks depend on open-source or self-hosted tooling, the internal team should be able to run that tooling without the implementation partner, including upgrades and certificate renewals, or the level will decay the first time the partner's support ends.