If your board or a customer asks about your Essential Eight maturity, start with evidence of how each mitigation strategy is implemented. Record the gaps against the current ASD requirements before claiming a maturity level.
What an essential eight maturity assessment actually measures
The Australian Signals Directorate's Essential Eight is a set of eight mitigation strategies designed to help protect internet-connected IT networks against a range of cyber threats: patching applications, patching operating systems, multi-factor authentication, restricting administrative privileges, application control, restricting Microsoft Office macros, user application hardening, and regular backups.
It is not a general IT health check. Each strategy exists because it closes off a specific step an intruder relies on — an unpatched vulnerability, a stolen credential with no second factor, a macro that launches a payload. That focus is also its limit: an organisation can meet its Essential Eight target and still be exposed to risks the framework was never built to cover, such as physical security or third-party data handling.
Interest in a self-assessed maturity level rarely comes from curiosity alone. It usually turns up because a cyber insurer's proposal form asks for it, a government tender requires a stated level, a major customer's due-diligence questionnaire asks the question directly, or a board member has read about the framework and wants a straight answer. In every one of those situations, a vague or unverified answer is worse than a modest, evidenced one — an insurer or a customer who later discovers the claimed level was aspirational rather than assessed has grounds to treat every other representation you have made with the same scepticism.
Maturity depends on the requirements, scope and evidence
The Essential Eight Maturity Model does not ask "have you deployed multi-factor authentication?" as a yes/no question. It asks how consistently and how well each strategy is implemented, on a maturity scale that runs from Maturity Level Zero (weaknesses in the organisation's overall cyber security posture) up through Levels One, Two and Three, each level defined against the sophistication of tradecraft it is expected to resist.
Two things trip people up here. First, maturity is normally assessed one strategy at a time, and an organisation's overall maturity is realistically no higher than its weakest strategy — a business with excellent patch management but no application control is not "mostly at Level Two." Second, ASD reviews and updates the maturity model's detail from time to time, so treat the specific wording of each level as something to confirm against the current published guidance rather than something to assume you remember correctly from a past assessment.
How to run a self-assessment without kidding yourself
A credible self-assessment follows a discipline, not a gut feel:
- Assign one accountable owner per strategy. The same person may own several strategies in a small organisation. Record the evidence and contributors for each strategy separately so none is assumed to have been checked.
- Score from evidence, not intent. A policy that says "administrative privileges are reviewed quarterly" is not evidence a review happened. Pull the actual log, ticket or export.
- Record the highest level for which the required evidence is complete, not the level you believe is probably true. If you cannot produce evidence for Level Two, you are at Level One or Zero for that strategy, regardless of what the architecture diagram implies.
- Record exceptions and compensating controls separately from the score itself, so the gap is visible rather than quietly averaged away.
- Set a re-assessment date. A self-assessment with no review cycle is a snapshot that goes stale the day a system is added or a control lapses.
This discipline matters more than the scoring template you use. Two organisations can use the exact same spreadsheet and produce very different quality assessments, because the difference lives in whether someone actually went and pulled the evidence, not in how the columns are labelled.
A worked example: scoring one strategy properly
Take a fictional regional water utility, Bindarra Water, roughly 220 staff, self-assessing patching of internet-facing applications.
| Element | What was claimed | What the evidence showed | Level supportable |
|---|---|---|---|
| Patch timeframe for internet-facing apps | "Patched within 48 hours of a vendor advisory" | Ticketing data showed a median of 11 days over the last quarter, with two systems unpatched at 40+ days | Below the claimed level |
| Vulnerability scanning | "Weekly automated scans" | Scans ran weekly, but results were not reviewed or actioned for one of three business units | Partial — scanning exists, response process does not |
| Coverage | "All internet-facing applications in scope" | Two contractor-managed applications were excluded from the scan inventory entirely | Gap in scope, not just in speed |
The honest score for this strategy at Bindarra was lower than IT's initial self-rating, and the gap was in process and scope, not tooling. That is a common pattern: the technology exists, but the operating discipline around it does not.
The same exercise, repeated across all eight strategies, typically surfaces one or two that are genuinely strong, several that are adequate but undocumented, and at least one with a scope gap nobody had flagged — often something outside the core IT estate, like a contractor-managed system or a legacy application nobody wants to own. Recording the score without recording the reason for it wastes the most useful part of the exercise: knowing exactly what to fix first.
Common mistakes in Essential Eight self-assessment
- Scoring intent instead of evidence. "We have a policy for this" is not the same claim as "we can show this happened last month."
- Letting one enthusiastic strategy hide a weak one. A strong backup regime does not offset unreviewed admin privileges; maturity does not average.
- Assessing once and never again. A new SaaS platform, a merger, or a change of IT provider can quietly drop maturity a level without anyone deciding that on purpose.
- No independent review. Self-scoring by the same team that implements the controls tends to be optimistic; a second reviewer can help challenge unsupported conclusions.
- Treating "documented" as "done." This is the mistake that shows up across almost every control framework, not just this one: a control that is written down is not the same as a control that is operating.
A self-assessment like this pairs naturally with the work covered in Before and After: Recording Pre- and Post-Mitigation Risk, because both require a dated assessment with evidence. A maturity level is not a measurement of how much risk has been reduced. If your supply chain includes vendors whose own cyber posture affects your Essential Eight exposure, see Secure Supply Chain Policy Template (Free). And because a technical control framework is only as strong as the people operating around it, staff-facing material like Free Cybersecurity Awareness Posters You Can Brand as Your Own is worth pairing with any patching or macro-restriction strategy you score.
Get a starting point for your assessment
Use the current ASD Essential Eight Maturity Model as the authority for requirements. Check any assessment spreadsheet against that version before relying on its scoring, and document exceptions and compensating controls using ASD guidance. SRMBOK's free Essential Eight assessment tool gives you a structured way to record your evidence and score against the Essential Eight mitigation strategies, so your next board update is backed by a defensible assessment rather than an educated guess.