The question comes up in nearly every Australian procurement conversation: we are ISO 27001 certified, does that cover the Essential Eight? The answer is no, and the reason is structural rather than a matter of scope or effort.
They are different kinds of thing. One certifies that you manage security decisions properly. The other rates whether eight specific technical controls are deployed and how deeply.
The Difference in One Sentence
The difference in one sentence: ISO 27001 asks whether you have a management system for deciding on controls, and the Essential Eight asks what you actually deployed.
An organisation can hold a valid ISO 27001 certificate while application control is unimplemented and Microsoft Office macro settings sit at their defaults — because the ISMS asks whether you assessed the risk, documented a decision and can justify it, not what the resulting configuration is.
What Each One Actually Proves
What each one actually proves differs on every axis that matters commercially.
| ISO 27001 | Essential Eight | |
|---|---|---|
| Type | Certifiable management system standard | Technical baseline with a maturity model |
| Outcome | A certificate, with a scope statement | A maturity level per strategy, zero to three |
| Assessed by | An accredited certification body | Self-assessment or an independent assessor |
| Evidence | Policies, records, risk decisions, audit trail | Configuration, coverage, enforcement state |
| Scope | A defined management system boundary | Your fleet |
| Published by | ISO and IEC | The Australian Signals Directorate |
The row that matters commercially is evidence. An ISO 27001 auditor will accept a documented, justified risk decision not to implement something. An Essential Eight assessment will not, because the model does not ask why a control is absent — only what level the implementation reaches.
Why a Certificate Does Not Imply a Maturity Level
A certificate does not imply a maturity level because ISO 27001's Annex A is a catalogue you select from, recorded in a Statement of Applicability. Exclusions are legitimate when justified. The standard is deliberately agnostic about which specific technologies you deploy, because it has to work for organisations of every size and sector.
That flexibility is the feature, and it is exactly why certification cannot stand in for a maturity rating. Two certified organisations can have completely different technical postures and both be compliant. The Essential Eight exists to answer the narrower question the certificate deliberately leaves open.
This is also why Australian buyers ask for both. The certificate tells them you run a programme. The maturity level tells them what is actually enforced on the machines.
Running ISO 27001 and getting asked for a maturity level?
Share your work email and we'll map which of your existing ISMS evidence already supports an Essential Eight rating and where the genuine gaps are.
Where the Two Genuinely Overlap
The overlap is real and worth exploiting. Most of the Essential Eight maps onto controls an ISMS already expects to exist in some form:
- Patching applications and operating systems against technical vulnerability management
- Restricting administrative privileges against privileged access management and access review
- Multi-factor authentication against authentication and access control
- Regular backups against business continuity and information backup
- User application hardening and macro settings against secure configuration
What rarely has a close ISMS counterpart is application control at the depth the maturity model expects. An ISMS may require malware protection; it does not usually require default-deny execution with enforcement evidence.
So the realistic position for a certified organisation is that five or six of the eight have evidence already produced for another purpose, one or two need genuine new work, and all eight need the coverage and enforcement detail that an ISMS does not usually capture.
Running Both Without Doing the Work Twice
Treat the Essential Eight as a technical baseline inside the ISMS rather than a parallel programme.
Declare the target maturity level as a control objective in the management system, and let the per-strategy evidence serve both purposes. Patch compliance reporting answers the ISMS vulnerability management requirement and the Essential Eight patching strategies from the same data. Privileged access reviews do the same for both. Backup restoration tests satisfy continuity requirements and the recovery strategy at once.
The work that does not merge is coverage. Essential Eight assessment cares which machines, and an ISMS often does not ask at that granularity. Capturing coverage figures against an asset inventory once, and reporting them into both, is the single highest-leverage thing to set up.
Which to Do First
It depends on who is asking.
If your buyers are Australian government or their supply chain, the Essential Eight is usually the binding requirement with a stated level, and ISO 27001 is the broader credential. Do the eight first — it is faster, more specific, and it is what will be checked.
If you are selling internationally and Australia is one market among several, ISO 27001 first is the better sequence. It gives you a credential that travels, and the Essential Eight then lands as a focused technical uplift against a programme that already exists.
If both are already required, run the eight as a workstream inside the ISMS implementation rather than after it. The evidence overlaps enough that sequencing them end to end wastes several months.
Essential Eight and ISO 27001 Questions Teams Ask
No, and it tends to damage credibility with buyers who know the difference. ISO 27001 certifies that a management system exists and was audited; the Essential Eight rates eight specific technical controls at a maturity level. A certificate can be entirely valid while application control is unimplemented. The accurate answer is to state the certificate and the per-strategy maturity level separately, because they answer different questions.
Loosely, and usefully. Patching maps onto technical vulnerability management, privilege restriction onto privileged access controls, MFA onto authentication, backups onto information backup, and hardening onto secure configuration. The mapping is good enough that evidence can serve both purposes, which is the practical reason to run them together. Application control is the one with no close Annex A counterpart at the depth the maturity model expects.
No. There is no certification body and no certificate for the Essential Eight. What exists is a maturity rating per strategy, produced by self-assessment or by an independent assessor, supported by technical evidence. Buyers ask for a level and the evidence behind it. This is a frequent source of confusion for teams who expect a comparable logo to put on a trust page.
If you sell into Australian government supply chains or to Australian organisations that have adopted it, it is effectively required. Beyond that, the eight are a well-chosen technical floor with nothing Australia-specific about them — patching, MFA, privilege restriction, hardening, application control and tested backups are good practice anywhere. Many organisations implement the substance for risk reasons and only produce a formal maturity rating when a buyer asks for one.
Run one programme that answers both
Book a demo and we'll show how Konfirmity maps Essential Eight evidence into an ISO 27001 ISMS so patching, privilege and backup evidence is collected once and reported twice.
Book a demo
Use Each for What It Answers
The mistake is treating these as competing options and picking one. They answer different questions, and sophisticated buyers ask both — the certificate for assurance that security is managed, the maturity level for assurance that specific things are switched on.
Start from what your buyers put in writing. Then build the evidence once: the maturity model tells you what depth to aim for, and the ISMS gives you the cadence that keeps it true next year.
