Essential Eight vs ISO 27001: which to pursue first
If you are an Australian organization or a supplier to Australian government, start by asking what your customer or contract actually requires. The Essential Eight is a mitigation baseline assessed against maturity levels, with no certificate, while ISO/IEC 27001 is certified by an accredited certification body that audits your information security management system. Those are different kinds of proof, so the first question is which one a buyer, regulator or tender will accept as evidence.
Start with the Essential Eight when your main exposure is technical intrusion and your near-term need is a defensible, measurable baseline. Its Maturity Level One requirements include patch deadlines such as 48 hours for vendor-critical or exploited vulnerabilities in internet-facing systems, and phishing-resistant MFA becomes a Maturity Level Two requirement. Start with ISO/IEC 27001 when a customer, lender or procurement team asks for a certified ISMS, or when you need a governance structure that covers the whole organization. Certification takes a risk assessment, a risk treatment plan and a Statement of Applicability, which is a larger body of work than a technical baseline alone. Confirm with the certification body and your assessor how long each step will take in your environment before you commit a date to a customer.
Doing both makes sense when a single contract asks for an Essential Eight maturity claim and an ISO certificate, or when you plan to reuse Maturity Level One evidence such as patch records, MFA configuration and backup tests inside the Annex A controls you select. Choose the sequence by the contract deadline, the customer's risk picture and what your own risk assessment shows. Ask the buyer which evidence they will accept, who will review it, and whether an independent assessment is required. Your internal risk picture decides which Annex A controls are necessary, so do that work before deciding how much of the ISMS to build first.
How Essential Eight and ISO 27001 differ on scope, proof and structure
This table compares who publishes each framework, what it assesses, how it is structured, what output it produces and who assesses it. Read it as a guide to what each one can prove to a customer, regulator or board, then check the rows that matter most to your own assurance needs.
| Dimension | Essential Eight | ISO/IEC 27001:2022 |
|---|---|---|
| Publisher | Australian Signals Directorate, published through the Australian Cyber Security Centre | International Organization for Standardization, developed by ISO/IEC JTC 1/SC 27 |
| What it assesses | Implementation and effectiveness of eight technical mitigation strategies | Whether an information security management system is established, operated and improved against risk |
| Structure | Eight strategies, each assessed at Maturity Levels Zero to Three | Clauses 4 to 10 for management system requirements, plus 93 Annex A controls in four themes |
| Control selection | Fixed by the strategies and maturity level, with ASD profiles listing required ISM controls | Chosen through your own risk assessment and risk treatment, then recorded in a Statement of Applicability |
| Mandatory output | Maturity level evidenced by assessment, with no ASD certificate | Statement of Applicability for any certified ISMS, since omitting a clause 4 to 10 requirement is not acceptable for a conformity claim |
| Certificate or report issued | No certificate exists; the outcome is a maturity assessment you document and share | Accredited certification bodies issue a certificate after audit, with surveillance audits in each year of the cycle |
| Who assesses | Assessor evaluates each strategy against the maturity model; confirm the assessor type and evidence expected for your context | Accredited certification body, operating to ISO/IEC 17021-1 and ISO/IEC 27006-1 |
Which framework fits which Australian situation
An agency's obligations come from government policy and its own accountability arrangements, not from a choice between frameworks. The Essential Eight is a prescriptive technical baseline with maturity levels, and it is the reference most Australian government cyber work is measured against. ISO/IEC 27001 is only relevant if the agency's governance or a specific program asks for a certified management system. Confirm which baseline the responsible authority or portfolio requires, and whether it expects a maturity level or an ISMS certificate.
- Policy reference: Confirm which ASD guidance the agency's own policy or assessment cycle names, including the target maturity level and the date it applies.
- Certificate expectation: The Essential Eight produces no certificate. If a stakeholder asks for one, clarify that the evidence is a maturity assessment, not a certification.
- Management system scope: Ask whether a program requires an ISMS scope statement and a Statement of Applicability, which only apply if the agency pursues ISO/IEC 27001.
- Assessor independence: Confirm who may perform the assessment and how findings are recorded for the agency's governance committee.
- Overlap: Check whether one evidence set can serve both the maturity assessment and any management system review.
Check the policy instrument and the accountable executive's reporting requirements before scoping any work.
A supplier to Australian government usually meets technical expectations through contract clauses, security schedules or tender criteria. Those clauses decide whether the Essential Eight maturity evidence is enough or whether an ISO/IEC 27001 certificate is also asked for. The supplier should not assume either. Read the security requirements in the request for tender and the contract, then map each named requirement to the evidence it accepts.
- Technical maturity clause: If the contract asks for a stated Essential Eight maturity level, the evidence is an assessment of each strategy's implementation and effectiveness, with no certificate issued.
- Certification clause: If the contract asks for ISO/IEC 27001, confirm the accredited certification body and the scope, because ISO does not certify organizations directly.
- Scope boundary: Confirm whether the in-scope systems are the whole organization or only the service delivered to the agency.
- Subcontractors: Check whether supplier assurance for subcontractors is required and what evidence the customer accepts.
- Timing: Ask which maturity level or certificate status must be in place at contract signature and at each review date.
Check the security schedule of the contract before choosing which evidence to build.
A private organization often chooses a management system because customers, insurers or the board want to see a documented, risk-based approach to information security. ISO/IEC 27001 fits that need when the organization wants a certificate issued by an accredited body. The Essential Eight fits when the question is specifically about technical hardening against common adversary tradecraft. The two can be used together, but the board paper and the customer questionnaire should name which one is being relied on.
- Board request: Confirm whether the board wants a governance structure, a certificate, or a technical maturity score, since each answers a different question.
- Customer questionnaire: Check whether the customer asks for a certificate, a maturity level or a self-declared control list.
- Certification cycle: If the organization pursues ISO/IEC 27001, confirm the three-year certification cycle and the annual audit obligation with the certification body.
- Risk treatment: Ask whether the customer expects the Statement of Applicability to show which Annex A controls were excluded and why.
- Public claims: Make sure any marketing language matches the proof actually held.
Check the customer contract and the board's stated objective before deciding which framework to lead with.
A multinational that serves Australian government and customers in other countries often faces several assurance requests at once. ISO/IEC 27001 is widely recognized across markets as a certifiable management system, while the Essential Eight is specific to Australian government expectations and has no certificate. Some non-Australian customers will ask for ISO/IEC 27001 alone, and others will ask for the Essential Eight maturity level. Mapping one control set to the other can reduce duplicate work, but the mapping is not a substitute for each requirement.
- Jurisdiction list: Make a list of each customer and regulator asking for evidence, and note the framework each one names.
- Official mappings: ASD publishes an evidence mapping to NIST CSF 2.0, and the ISO and ASD material can be compared, but confirm with each customer whether a mapping is accepted.
- Certificate scope: Confirm which legal entities and sites a certificate would cover, since a multinational may split scope by country.
- Local obligations: Check whether any non-Australian regulator requires its own framework in addition to these two.
- Evidence reuse: Ask each customer whether a shared evidence pack is acceptable.
Check each customer contract and regulator letter to build a single register of required frameworks before choosing a starting point.
What changes when moving from Maturity Level One to Two
The jump from Maturity Level One to Level Two is an operational change in how security runs day to day, not a documentation exercise. Moving to ML2 adds 41 controls in the ISM profiles, and much of that addition is centralised event logging, log protection and analysis, and incident reporting. An organization that only writes policies will not meet those controls. Before planning the move, confirm the current requirements in ASD's Essential Eight maturity model, since the controls and their wording are the reference point and this page does not restate them in full.
The logging change matters most for planning. A central log platform is a prerequisite for ML2, so teams need to know where logs from endpoints, servers, identity systems and online services will land, who can read them, how they are protected from tampering, and how they are analysed. Ask whether the existing tooling can collect from every in-scope system and retain logs in a protected store. If it cannot, that gap is usually the first cost and the first delay, and it should be scoped before any ML2 commitment is made. (Illustrative: a team that collects logs only from servers will still have work to do on workstations and cloud services.)
Authentication also changes. ML2 requires phishing-resistant multi-factor authentication for staff accessing online services and systems, which rules out the weaker combinations still accepted at ML1. Check which staff accounts and admin paths currently rely on SMS codes or similar methods, and map each to the control IDs ISM-1872 and ISM-1682 in the ISM profiles. Patch timing is the third area to review. The ML1 deadlines of 48 hours for vendor-critical or exploited vulnerabilities in internet-facing systems, two weeks for other such vulnerabilities and common user applications, and one month for workstation and internal server operating systems must already be met before ML2 is credible.
Where Essential Eight and ISO 27001 controls overlap
Essential Eight and ISO/IEC 27001 both address patching, authentication, privileged access and backups, but they express those topics differently. The Essential Eight is a prescriptive set of mitigations with maturity levels, while ISO/IEC 27001 asks you to choose controls from Annex A based on your own risk treatment.
Patching and vulnerability timing
The Essential Eight sets fixed ML1 patch deadlines: 48 hours for vendor-critical or exploited vulnerabilities in online services and internet-facing systems, two weeks for other such vulnerabilities and common user applications, and one month for workstation and internal server operating systems. ISO/IEC 27001 has no equivalent deadlines. Its technological controls on vulnerability management and change control are chosen through your risk treatment, so an ISMS auditor will check whether your chosen timeframes match your stated risk appetite. Keep the Essential Eight deadlines as your floor and document how they appear in your Statement of Applicability.
Multi-factor authentication strength
ML1 accepts multi-factor authentication combinations that ML2 rejects. ML2 requires phishing-resistant MFA for staff on online services and systems, under ISM-1872 and ISM-1682. ISO/IEC 27001 addresses authentication through its technological controls on secure authentication and access, but it does not name a strength level. Map your existing MFA to the Essential Eight level first, then record the authentication control you selected for Annex A and the risk that drove it. Confirm with your assessor whether a single control satisfies both.
Restricting administrative privileges
The Essential Eight restrict administrative privileges as a named strategy with its own ISM controls, and the ML2 and ML3 profiles tighten them further. ISO/IEC 27001 covers the same ground through access rights and privileged access controls among its technological controls, and through the access policy under organizational controls. Auditors will look for evidence that privileged accounts are inventoried, reviewed and separated from daily use. Gather that evidence once and label it for both frameworks so you do not run two parallel reviews.
Regular backups and recovery testing
Regular backups is one of the eight Essential Eight strategies, and the maturity model requires backups to be tested as well as taken. ISO/IEC 27001 addresses backup in its technological controls on information backup and in its continuity controls. The Standard asks you to decide what is backed up, how long it is kept and how recovery is verified, based on your risk assessment. Confirm the restore test frequency your assessor expects for each framework before you write the procedure.
Application control and logging
Application control is an Essential Eight strategy that prevents unapproved executables from running. ISO/IEC 27001 has related controls on configuration, malware protection and installation of software. The Essential Eight also depends on centralised logging for ML2, because ML2 adds 41 controls that include event logging, log protection and analysis. Check whether your log platform can serve as evidence for both frameworks before you buy or extend one.
Mapping and crosswalk confirmation
No supplied fact confirms a direct mapping between Essential Eight strategies and ISO/IEC 27001 Annex A controls. ASD publishes the ISM with Essential Eight profiles and an assessment evidence guide that references NIST CSF 2.0 and NIST SP 800-171r3, but those collections do not establish an ISO crosswalk. Treat any overlap table as a working draft. Confirm each mapping with the ISO/IEC 27001 standard owner, your certification body or your assessor before you rely on it in an audit.
Who assesses each framework and what each one produces
This table compares who checks each framework, what document or evidence comes out of the check, and how often the work recurs. Read it to see whether you need an external certificate, an assessed maturity level, or both, and what each one commits you to after the first pass.
| Dimension | Essential Eight (ASD model) | ISO/IEC 27001:2022 ISMS |
|---|---|---|
| Who assesses | The organization's own assessors or an assessor it engages, working against the ASD maturity model. No ASD body issues the result. | Accredited certification bodies audit the ISMS under ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024. ISO does not certify organizations. |
| What it produces | A maturity level per strategy, supported by evidence of implementation and effectiveness. There is no ASD certificate. | A certificate issued by an accredited certification body, backed by audit findings and a Statement of Applicability. |
| Standard the assessor works to | The Essential Eight Maturity Model (November 2023 release) and the ISM controls mapped to each maturity level. | ISO/IEC 27001:2022 clauses 4 to 10 and Annex A, plus the certification body's accreditation requirements. |
| Assessment cycle | Set by the organization or by the party it asks to assess. The model does not impose a certification cycle. | A three-year certification cycle, with at least one surveillance or recertification audit in every calendar year. |
| Recurring obligations | Keep each strategy operating and re-evidence maturity when you claim a level. Confirm any reporting expectations with your customer or agency. | Surveillance audits, recertification audits at the end of each cycle, and maintaining the ISMS and the Statement of Applicability between audits. |
| How to verify a claim | Ask for the evidence behind each maturity level, not a certificate. Confirm what the counterparty will accept. | Check the certificate in the IAF CertSearch database, which ISO points to for accredited certificates. |
Sequencing Essential Eight and ISO 27001 when doing both
The right order lets the Essential Eight maturity work answer the technical controls that the ISO/IEC 27001 risk assessment identifies, so one body of evidence supports both the Australian baseline and the certifiable management system.
Confirm drivers, scope and the contract requirements
Start by listing why each framework is needed: a government contract that asks for an Essential Eight maturity level, a customer or board that asks for ISO/IEC 27001 certification, or both. Name the systems, sites, suppliers and business units in scope for each, and note whether the certification scope must match the scope of the maturity assessment. Ask the contracting authority which Essential Eight maturity level and which evidence it expects, because ASD's model is assessed rather than certified. The step is done when a written scope statement and a list of contractual obligations exist, signed off by the executive sponsor.
Close the Essential Eight gaps the contract needs first
Assess current state against the Essential Eight Maturity Model for the target level, usually Maturity Level One if that is the contractual minimum. Prioritize the gaps the contract names, such as patching deadlines, multi-factor authentication and backups. Where a higher level is required, confirm the ML2 prerequisites with the security team, including the central log platform and the phishing-resistant MFA requirement, before scheduling work. The step closes when each strategy has a documented assessment result and a remediation record that the assessor or internal reviewer can check.
Build the ISMS risk assessment and risk treatment plan
Establish the ISMS context and run the information security risk assessment across the scope. Identify threats and vulnerabilities for each asset, then decide how each risk is treated. ISO/IEC 27001 expects the risk treatment to determine which controls are necessary, and only then to compare that list against the Annex A controls. Use the Essential Eight gap results as input so that technical risks already analyzed are not assessed twice from scratch. The step closes when the risk register and the risk treatment plan are approved by management and every treated risk points to a named owner.
Compare necessary controls with Annex A
Take the controls chosen by risk treatment and map them against the 93 controls in Annex A of ISO/IEC 27001:2022. Some Annex A controls will be necessary; others may be omitted with a recorded justification. Any Annex A control that is omitted must be added back into the risk treatment plan with the reason it is not needed, so the omission is traceable. Do not treat the Essential Eight as a substitute for this comparison, because it covers only eight technical strategies while Annex A also addresses organizational, people and physical controls. The step closes when every Annex A control has either an implementation decision or a documented exclusion.
Produce the Statement of Applicability
Record every Annex A control in the Statement of Applicability, stating whether it is applicable, why, and how it is implemented or where its evidence sits. Clause 1 of ISO/IEC 27001:2022 makes the Statement of Applicability a mandatory output, because excluding any requirement from clauses 4 to 10 is not acceptable for a conformity claim. Ask the accredited certification body during planning which document format and evidence references it expects. The step closes when the Statement of Applicability is approved, version controlled and consistent with the risk treatment plan.
Reuse technical evidence across both frameworks
Link each Essential Eight control result to the Annex A controls it supports, such as the technological controls covering patching, access rights, backups and logging. Store one evidence record per control with references to both the ASD maturity assessment and the ISO control, so an auditor or government assessor can follow the same proof in either direction. Keep the mapping under change control, because ISO certification cycles and Essential Eight reassessments will each refresh evidence. The step closes when a cross-reference index exists and a sample of controls has been traced in both directions without gaps.
Confirm readiness and hand over to assessment
Before any external assessment, confirm with the Essential Eight assessor and the accredited certification body what each will sample and review, and whether they accept the shared evidence index. Use an internal review to check that the risk treatment plan, Statement of Applicability and maturity evidence describe the same systems. Record open items with owners and dates agreed by management. The step closes when the readiness review has no unresolved contradictions between the two evidence sets and the assessment dates are confirmed in writing.
What drives cost and effort for each framework
Essential Eight and ISO/IEC 27001 spend money in different places. One is an internal maturity assessment with no certificate, the other ends in a certification body's audit and recurring surveillance. The cards below show who is paid, what is one-time versus recurring, and what to put in a quote. No price or duration is given here because no supplied fact provides one.
Internal staff time
Most Essential Eight work is done by your own engineers: patching, MFA rollout, privilege reduction, application control and backup testing. For ISO/IEC 27001, staff also write the ISMS documentation, run the risk assessment and maintain the Statement of Applicability. Staff time is largely one-time for the build and recurring for operation. Ask who owns each strategy and how many hours of their time the plan assumes.
Central log platform tooling
Tooling is the cost most likely to be missing from a first estimate. Moving to ML2 adds 41 controls in the ISM profiles, much of it centralised event logging, log protection, analysis and incident reporting, so a central log platform is a prerequisite. Licences, storage and retention are recurring; the platform build is one-time. Check whether your current logging already covers the ML2 controls before you size the platform.
Certification body or assessor fees
ISO/IEC 27001 requires an accredited certification body to audit the ISMS, with a certification cycle of three years and at least one audit in every calendar year. The Essential Eight has no certificate, so the assessment fee buys a maturity evaluation against the model, not a certificate. Ask each body for the audit days it proposes, the stage 1 and stage 2 split, and the surveillance fees for years two and three.
Consultant support for gap closure
Consultants are usually bought for a gap analysis, a Statement of Applicability workshop or closing specific technical gaps. For ISO/IEC 27001, the Annex A control selection by risk takes the most judgement, so it is the most common place to pay for outside help. DeployOpen works under fixed-scope written agreements, so ask any provider for deliverables, scope boundaries and what the work does not cover before you sign.
Annex A scope and risk choices
The number of ISO/IEC 27001 controls you implement depends on your risk treatment, not a fixed list, so scope drives cost in both directions. Each control you include needs an owner, evidence and a line in the Statement of Applicability, and each omitted control must be justified in the risk treatment plan. Multiple sites, broad scope and weak current controls all push effort upward. Confirm how many sites and systems the certificate scope covers before requesting a quote.
Recurring surveillance and reassessment
Essential Eight maturity should be re-evaluated as systems change, so reassessment is recurring work tied to your patch cycle, MFA coverage and privilege reviews. ISO/IEC 27001 adds surveillance audits and a recertification audit within each three-year cycle, plus the ongoing management review and internal audit the standard requires. Ask each provider what is included in year two and year three and what triggers an extra visit.
Questions buyers ask before choosing Essential Eight or ISO 27001
Can you get Essential Eight certified?
No. The Essential Eight is a set of mitigations rather than a certification scheme, and there is no ASD certificate. Maturity is evidenced instead through assessment of each strategy's implementation and effectiveness against the Essential Eight Maturity Model, so the proof you hand to customers or assessors is a documented, assessed maturity position for each of the eight strategies. Ask any provider to show how they record that evidence per strategy and per maturity level, and to explain what they would hand to an assessor.
Is ISO/IEC 27001 required for Australian government work?
Do not assume it is. Whether ISO/IEC 27001 certification, the Essential Eight or neither is required depends on the specific contract, panel or agency security requirements, and those change. Read the security schedule in the tender or contract, ask the buying agency which assurance evidence it accepts, and confirm in writing before you commit budget. If the contract names ISO/IEC 27001, check whether it requires an accredited certificate or accepts a self-declared alignment, because those lead to very different work.
How long does each one take to implement?
No duration can be stated from the research available here, and any figure from a provider should be treated as a claim to test. Duration depends on the current state of your environment, how many systems and sites are in scope, how much of the required logging, patching and backup tooling already exists, and how many approvals your change process needs. ISO/IEC 27001 also adds a certification step run by an accredited body, with its own scheduling. Ask for a plan that separates the implementation work from the independent assessment, with milestones tied to named deliverables.
What does a Maturity Level Two push need from our internal team?
Expect the work to need people who own the systems being changed. Moving from Maturity Level One to Two adds 41 controls in the ISM profiles, much of it centralized event logging, log protection, analysis and incident reporting, so a central log platform is a prerequisite. It also requires phishing-resistant MFA for staff on online services and systems. Your team will need to decide log retention and ownership, approve identity changes, and test the impact on users. Ask providers which of these tasks they perform and which they expect your staff to own.
Can our team implement ISO/IEC 27001 on its own?
Yes, an internal team can build an ISMS without outside help, but the work is larger than the technical baseline. Under ISO/IEC 27001:2022 you must determine your context and interested parties, run a risk assessment, decide risk treatment, and produce a Statement of Applicability that records which Annex A controls apply and why. Excluding any requirement in clauses 4 to 10 is not acceptable for a conformity claim. Independent certification is still performed by an accredited certification body, not by your consultants or by DeployOpen. Confirm whether your internal team has the time and independence to run the management review and internal audit cycle.
How do I check that an ISO 27001 certificate is genuine?
Check the certificate against the accreditation records rather than trusting the PDF. ISO states that accredited certificates can be verified through the IAF CertSearch database, which is still the reference ISO points to even though Global ACI has assumed the roles of the IAF and ILAC since 1 January 2026. Confirm that the certification body is accredited for ISMS certification, that the certificate names your organization and the exact scope and sites, and that it is current. Also confirm the standard edition, since certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025.
Which should we start with if a customer asks for both?
Start with the one your contract or customer actually requires, then use it to shape the other. Essential Eight gives you a concrete technical baseline that many controls under ISO/IEC 27001 can be evidenced against, so teams often work through the technical strategies first. ISO/IEC 27001 adds the management system, risk assessment and Statement of Applicability that the Essential Eight does not provide. Build one control inventory, map each control to both sets of evidence, and confirm with the customer or agency which document they will accept.
How DeployOpen scopes readiness for both frameworks
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares systems, controls and evidence for compliance assessments. We do not issue audit reports, attestations or certifications, so the Essential Eight assessment and the ISO/IEC 27001 certification remain with the independent assessors and certification bodies you engage. Our work is to make the evidence they will ask for exist, be current and be traceable.
How we scope
- Agree scope in writing before work starts, covering which systems, sites and business units are in and out.
- Map Essential Eight maturity targets against the ISMS scope and the risk treatment plan so effort is not duplicated.
- Confirm with your assessor and certification body which evidence they accept, and record that in the written scope.
How we build
- Implement and harden the technical controls for the strategies in scope, such as patching, MFA and backups, in your environment.
- Stand up the central logging and retention needed for the controls that depend on event logs, if those are in scope.
- Document the Statement of Applicability reasoning and the control owners, so each Annex A decision traces to a risk.
How we hand over
- Deliver documented configurations, runbooks, control evidence and test results to your team in an agreed format.
- Walk your assessor through the evidence package before the formal assessment, so gaps surface while they can still be fixed.
- Transfer administration and ownership of each control to named people in your organization before engagement close.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Review evidence and controls again when the Essential Eight profile, the ISM or your ISMS scope changes.
- Confirm the support terms, response expectations and included activities in the written agreement before you sign.
