The Australian Signals Directorate’s Essential 8 is one of the most widely-referenced cyber security frameworks in the country. It’s also one of the most widely misunderstood — and the misunderstanding is causing Australian businesses to make claims, in security questionnaires and tender responses, that they can’t actually defend when asked.
Two things to understand up front. The Essential 8 isn’t 8 controls. And it isn’t really a framework — at least not in the way most people who reference it think it is.
What it actually is
The Essential 8 is a set of eight mitigation strategies drawn from ASD’s broader Strategies to Mitigate Cyber Security Incidents. Each strategy is a domain of activity, not a single control:
- Application control
- Patch applications
- Restrict Microsoft Office macros
- User application hardening
- Restrict administrative privileges
- Patch operating systems
- Multi-factor authentication
- Regular backups
Within each strategy sits a substantial number of specific technical and procedural controls. The actual control set required depends on which Maturity Level is being targeted — Maturity Level One, Two, or Three — each calibrated against the tradecraft of an increasingly capable adversary.
That’s the Essential 8 Maturity Model (E8MM). And underneath the E8MM sits the framework that nobody mentions on the sales deck but which the Essential 8 is actually a curated subset of: the Australian Government Information Security Manual — the ISM.
The ISM is the framework. The Essential 8 is a slice of it.
The ISM is the comprehensive cyber security framework published by ASD. The current March 2026 release contains 1,081 controls across domains spanning cryptography, network hardening, personnel security, physical security, software development, gateways, email, database systems, and more. It’s updated quarterly. It’s what IRAP assessors actually run organisations against. It’s what Commonwealth entities must align with under the Protective Security Policy Framework.
The Essential 8 isn’t a separate framework that competes with the ISM. It’s a prioritised, threat-informed subset of it.
ASD publishes the explicit mapping between the Essential 8 maturity model and the ISM. Counted against that mapping, the numbers per maturity level look like this:
- Maturity Level 1: 46 ISM controls
- Maturity Level 2: 87 ISM controls
- Maturity Level 3: 123 ISM controls
The maturity levels are cumulative — to achieve ML2 you need everything in ML1 plus the additional ML2 controls; to achieve ML3 you need all of that plus the ML3 additions. Across all three maturity levels, the Essential 8 maps to 126 unique ISM controls.
That’s the real number behind “we do the Essential 8.” Even at the entry-level maturity, that’s 46 specific technical and procedural controls. At ML2 — which under Australia’s Cyber Security Strategy Horizon 2 (effective January 2026) is now the recommended baseline for every industry, not just government — it’s 87 controls. At ML3, the standard expected for critical infrastructure, defence supply chain, and regulated sectors, it’s 123.
This isn’t a marketing badge. It’s a substantial program of work, organised by how attackers actually break into Australian organisations, sitting on top of a 1,081-control framework of supporting depth.
How the eight strategies break down by maturity level
It’s also worth understanding how the workload distributes across the eight mitigation strategies. The numbers below are the cumulative count of ISM controls required for each strategy at each maturity level.
A few things to notice. The strategies aren’t evenly weighted — restrict administrative privileges and user application hardening carry more controls at ML3 than the others. The jump from ML1 to ML2 is significant for almost every strategy, because ML2 brings in the supporting logging, monitoring, and incident response controls that ML1 doesn’t require. The strategies share controls — the same logging, monitoring, and incident response controls appear across multiple strategies, which is why the per-strategy totals sum to more than the unique total of 123 at ML3.
Why this matters when someone checks
If the counterparty asking about Essential 8 alignment is a sophisticated enterprise procurement team, an IRAP-assessed entity, or a government department, they know exactly what the Essential 8 is. When they read “we are Essential 8 compliant” on a tender response, they hear a specific claim — that the organisation has implemented somewhere between 46 and 123 ISM controls at a defined maturity level, with evidence to demonstrate it.
What they often find when they look closer is that the organisation has:
- Implemented one or two of the eight mitigation strategies superficially
- Confused “we have MFA” with “we have phishing-resistant MFA enforced for all privileged accounts across all systems, with central logging analysed for signs of compromise”
- Self-assessed at a maturity level that wouldn’t survive evidence review
- Conflated “we have a backup” with “we have backups stored offline or in immutable storage, tested for restoration, with documented recovery time objectives”
That gap is becoming harder to hide. ASD published a new IRAP Quality Assurance Framework in January 2026, which raised the bar on how assessors evaluate evidence — clean, timestamped, ISM-mapped artefacts are now the expectation, not the exception. When the gap shows up in a questionnaire response or an assessor’s review, the claim doesn’t just fail on the Essential 8 question. It contaminates every other security claim in the response. The counterparty starts assuming everything else is similarly overstated. And in most cases, the organisation never finds out that’s what happened — they just don’t make it through the security review.
The same misconception trap exists in the international equivalent of this conversation. If a customer has ever asked whether the organisation is ISO 27001 certified, the same dynamic applies from the other side — a framework that looks like a checklist on the surface but is fundamentally a risk-based, evidence-based exercise underneath. That’s worth its own article, and I’ll come back to it.
What “real” Essential 8 maturity looks like: application control across the three levels
To make the scale concrete, here’s what application control — the strategy with the most dramatic jump between maturity levels — actually requires. These are the actual ISM controls per ASD’s Essential Eight Maturity Model and ISM Mapping.
Maturity Level 1 (3 controls):
- ISM-0843: Application control is implemented on workstations
- ISM-1870: Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients
- ISM-1657: Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set
Maturity Level 2 adds 11 more controls (for 14 total):
Expanded technical scope:
- ISM-1490: Application control is implemented on internet-facing servers
- ISM-1871: Application control is applied to all locations other than user profiles and temporary folders
- ISM-1544: Microsoft’s recommended application blocklist is implemented
- ISM-1582: Application control rulesets are validated annually or more frequently
Logging, monitoring, and incident response chain:
- ISM-1660: Allowed and blocked application control events are centrally logged
- ISM-1815: Event logs are protected from unauthorised modification and deletion
- ISM-1906: Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events
- ISM-1228: Cyber security events are analysed in a timely manner to identify cyber security incidents
- ISM-0123: Cyber security incidents are reported to the CISO or one of their delegates
- ISM-0140: Cyber security incidents are reported to ASD
- ISM-1819: Following identification of a cyber security incident, the cyber security incident response plan is enacted
Maturity Level 3 adds 5 more controls (for 19 total):
Expanded technical scope:
- ISM-1656: Application control is implemented on non-internet-facing servers
- ISM-1658: Application control restricts the execution of drivers to an organisation-approved set
- ISM-1659: Microsoft’s vulnerable driver blocklist is implemented
Deeper monitoring:
- ISM-1907: Event logs from non-internet-facing servers are analysed in a timely manner
- ISM-0109: Event logs from workstations are analysed in a timely manner
That’s one of the eight strategies. Nineteen specific technical and procedural controls at ML3, every one of which has to be implemented, configured correctly, evidenced, and validated. The other seven strategies have comparable depth.
And notice what ML2 actually demands: not just additional application control coverage, but the entire chain of logging, log protection, log analysis, event analysis, incident identification, incident reporting (internal and to ASD), and incident response plan execution. The same chain appears across every other E8 strategy at ML2 and ML3. That’s what most “Essential 8 compliant” claims are quietly skipping.
This isn’t a checkbox exercise. It’s a technical program of work supported by an actual operational capability — and that’s precisely why the framework carries weight with the people who understand it.
The point
The Essential 8 is one of the strongest, most defensible technical baselines available to Australian organisations. It’s threat-informed, continuously updated, and sits on top of the most comprehensive cyber security framework Australia produces. That’s why government entities, IRAP assessors, defence supply chains, and increasingly insurers reference it.
But it isn’t a badge. It’s a measurable maturity state — reached through implementing 46 controls at ML1, 87 at ML2, or 123 at ML3, demonstrated with evidence, and validated against adversary tradecraft.
The next article in this series goes deeper on why the Essential 8 and the ISM behind it work the way they do. Specifically: why both are risk-based frameworks where controls can be deemed applicable or not applicable with proper justification, why alternate controls can be substituted, and why the evidence model goes well beyond “show me your policy.” That’s the part most consultants don’t explain, and it’s where the real defensibility comes from.
If any of this is relevant to a conversation happening internally — or one a customer or counterparty is having about the organisation — I’m happy to talk it through.