If your board wants to reach Essential Eight Maturity Level Two, first establish why that target suits your exposure and obligations. Compare your evidence against the current requirements and identify the work needed across all eight strategies.
What the maturity model is actually measuring
The Essential Eight is the Australian Signals Directorate's set of eight mitigation strategies for reducing the risk of a cyber security incident: patching applications, patching operating systems, multi-factor authentication, restricting administrative privileges, application control, restricting Microsoft Office macros, user application hardening, and regular backups. The maturity model that sits alongside them describes how thoroughly each strategy is implemented, across four levels from Maturity Level Zero through to Maturity Level Three.
The distinction that most internal conversations miss is that each level is framed around the sophistication of the adversary the organisation is trying to resist, not simply "more controls equals a higher number." A lower maturity level is built around resisting attackers using widely available, off-the-shelf techniques against whichever target presents itself. Higher levels are built around resisting attackers who are willing to invest more time, use more capable tooling, and specifically target the organisation rather than opportunistically stumbling onto it. Moving up a level is not just doing the same eight things harder. It is closing the specific gaps that a more capable and more determined adversary would exploit.
Why "what does each level require" doesn't have a short answer
Each of the eight strategies has its own criteria at each maturity level, and those criteria are specific to the strategy — the way patch timeframes tighten as maturity increases is a different kind of change to the way multi-factor authentication is expected to extend to more systems and more users, which is again different to how tightly Microsoft Office macros get restricted. There is no single sentence that describes "what Level 2 requires" across all eight strategies at once, and any explanation that gives you one number or one rule to apply everywhere is oversimplifying it.
The requirements differ by strategy and level. Some expand coverage or strengthen controls; do not assume that every timeframe changes at every level. ASD recommends reaching the same target across all eight strategies and managing exceptions through an appropriate documented process. If you are assessing your own environment, the ASD's own published guidance for the specific strategy and level you are targeting is the authoritative source for the exact criteria — this article is a map of how to think about the levels, not a substitute for that detail.
An essential eight maturity level comparison you can actually use
| Level | The adversary it is built to resist | What this generally means in practice |
|---|---|---|
| Maturity Level One | Adversaries using commonly available, low-sophistication techniques against opportunistic targets | Meet each strategy’s Level One criteria; some patching requirements already use a 48-hour timeframe |
| Maturity Level Two | Adversaries willing to invest modestly more time and use more capable, but still fairly accessible, tools against a chosen target | Meet the additional Level Two criteria for each strategy rather than inferring requirements from this summary |
| Maturity Level Three | Adversaries who are more adaptive, better resourced, and less reliant on off-the-shelf tools, prepared to invest significant effort against a specific target | Meet the additional Level Three criteria and consider threats that remain outside the Essential Eight |
This table is a way of thinking about the shape of the model, not a checklist to assess against. The specific requirement for, say, application control at Level Two versus Level Three is a distinct technical criterion in its own right, and needs to be checked against the current published guidance rather than inferred from a general pattern.
Worked example: choosing a target, not just a number
Take a fictional mid-size professional services firm, Bellmont Advisory, with around 150 staff, no government contracts, and no specific regulatory obligation naming an Essential Eight target. The IT manager has been asked to recommend a maturity target for the year.
Rather than picking a level because it "sounds appropriately serious," a defensible process looks like this:
- Establish the current position honestly, strategy by strategy, rather than assuming an overall level based on the strongest area.
- Assess relevant tradecraft, targeting and consequences using the firm’s actual exposure, sensitive information and service dependencies. Do not assume a professional services business faces only opportunistic threats.
- Cost the gap to the next level for each strategy separately, because the effort to close the gap on multi-factor authentication is a different budget line to the effort to close the gap on application control.
- Recommend a target with a stated reason, not a target chosen because a competitor mentioned theirs. For example: "We propose Level Two across all eight strategies based on our assessed exposure and consequences, with the gaps, costs and remaining risks documented for decision." The assessment still needs to support that recommendation. "We should be Level Two because everyone else is" is not.
This is the same discipline that should sit behind any maturity or compliance target, not just this one — see How to Scope a Security Risk Assessment (Free Template) for how to structure that reasoning before you present it upward.
Common mistakes
- Treating the levels as a single number rather than eight separate assessments. An organisation can be genuinely strong on backups and genuinely weak on application control while still describing itself as "Level Two overall," which hides the actual gap.
- Picking a target level because it sounds appropriately serious, not because it matches the actual threat profile. A target chosen for optics rather than reasoning is hard to defend when someone asks why.
- Assuming maturity level progress is a one-off project rather than a sustained state. Reaching a level and then not maintaining the practices behind it means the organisation drifts back down without anyone noticing until the next assessment.
- Confusing Essential Eight maturity with a compliance certificate. It is a maturity model against a specific set of mitigation strategies, which may be assessed internally or independently, not a broader security management system, and treating it as a complete cyber security programme leaves real gaps unaddressed.
- Guessing at the specific technical criteria per level instead of checking the current published guidance. The criteria for each strategy have been revised before and can be revised again; work from the current source, not from memory of an earlier version.
Get a starting point for your own assessment
Use the current ASD Essential Eight Maturity Model for the actual requirements. The model is designed for internet-connected IT networks; other environments may need different measures. Check the assessment tool against the current model before relying on its criteria.
Before you can pick a defensible target, you need an honest read of where you actually sit against each of the eight strategies today. The SRMBOK ASD Essential 8 Assessment Tool is built to help with that starting assessment. It is free. Once you have a documented current position, Security Risk Register Template (Free Word Download) gives you a place to track the specific gaps you decide to treat.