Essential Eight assessment: how maturity is assessed in practice
There is no ASD certificate for the Essential Eight. Maturity is evidenced by assessing each of the eight strategies, both its implementation and its effectiveness, against the Essential Eight Maturity Model published by the Australian Signals Directorate in November 2023. The conclusion is reached by an independent assessor or by the organization's own assurance function, not by DeployOpen. When a customer or contract asks for a maturity level, the question to answer is which level the organization can demonstrate, strategy by strategy, and who has checked it. Our role is to prepare systems and evidence for that review, never to issue the rating.
The answer depends on three variables: the target maturity level, the number of systems in scope, and how evidence is produced. A Maturity Level One claim across a few managed workstations is a very different exercise from Level Two across hybrid servers and cloud tenants. Assessors test against the ASD Information Security Manual Essential Eight baseline profiles, which in ISM v2026.09.4 contain 46 controls at ML1, 87 at ML2 and 123 at ML3. Ask the assessor which profile version they will test against, and confirm that version before collecting evidence, because the control set is what gets sampled.
Evidence is where most assessments succeed or stall. Ask the assessor to define acceptable artifacts per strategy before work begins, such as patch compliance reports, privileged account listings, application control policy exports and backup restore test records, each dated and traceable to the systems in scope. ASD publishes the ISM in OSCAL, a machine-readable format that can be loaded into GRC tooling to track implementation against each control. Confirm with your assessor whether they will accept OSCAL-based tracking as supporting evidence, and whether the Assessment evidence guide for enterprise IT published in October 2026 changes what they expect.
How an Essential Eight maturity assessment runs, step by step
The sequence turns a set of eight mitigation strategies into a defensible maturity statement, with each phase producing a written artifact that the next phase depends on. Because the Essential Eight is a set of mitigations rather than a certification scheme, the organization owns the conclusion and the assessor documents the findings.
Define the target maturity level and scope
The organization decides which maturity level it is assessing against (ML1, ML2 or ML3) and which parts of the estate fall inside the assessment, such as specific business units, domains, cloud tenants or networks. Leadership sign-off on the target level and scope is the owner's responsibility, and an advisor can help frame the choice. The step is complete when the target level, the in-scope systems and the named accountable owners are recorded in a signed scope statement that the assessor can test against.
Map each strategy to its ISM baseline controls
Each of the eight strategies is traced to the controls in the matching Essential Eight baseline profile of the Information Security Manual, published by ASD in OSCAL. Teams load the ML1, ML2 or ML3 profile into their GRC tooling, or into a spreadsheet, and assign each control to a named owner and a system in scope. Note that every ML1 control also appears in ML2, and the ML3 profile replaces three ML2 controls with stricter versions. The output is a control register per strategy that shows which ISM controls apply and who is answerable for each.
Collect implementation evidence for each control
Owners gather artifacts that show each control is configured and operating, such as patch scan reports, MFA enforcement settings, application control policies, privileged account inventories, macro configuration exports and backup job logs. Evidence should be dated and tied to the in-scope systems so that it can be re-collected later. Confirm with the assessor which evidence formats they accept. The step is complete when every control in the register has at least one evidence item linked to it, and any control without evidence is flagged as open.
Test effectiveness domain by domain
Implementation alone does not show that a strategy works, so the assessor tests effectiveness by domain. For each domain, they examine whether the controls operate as configured, for example by sampling accounts, reviewing scan results against a sample of assets, or observing a test restore. ASD's enterprise IT evidence guide rates actions as not effective, partially effective or fully effective, and its mapping notes say that effectiveness in one domain does not prove effectiveness in another. The output is a per-domain test record that states what was tested, the sample, and the result.
Document gaps and remediation owners
Each control that is not implemented or not effective is recorded as a gap with a description, a risk statement, a named remediation owner and a target date set by the organization. Gaps are triaged so that leadership can see which items block the target maturity level. The organization decides whether to accept any residual risk and records that decision with an approver. The step is complete when every gap has an owner, a remediation plan and a status, and the list is reviewed by the accountable executive.
Produce the assessor's findings
An independent assessor, or the organization's internal assessment function where its scope allows, consolidates test records and gap logs into findings for each strategy and for the overall maturity position. The findings state which level the evidence supports and which controls prevent a higher level. Only the assessor issues the findings document, since the Essential Eight has no ASD certificate. The step is complete when the findings are signed and handed to the organization, and the evidence package is retained so that the assessment can be repeated and compared over time.
What an assessor tests for each strategy
Implementation testing asks whether a control is configured the way the maturity model describes for the claimed level. The assessor starts from the strategy definition, then checks settings, policies and documented decisions against it. The evidence is usually configuration exports, policy documents, approved application lists and account inventories, all dated and tied to specific systems.
- Configuration state: Assessors compare live settings, such as macro policy, MFA enforcement or update rings, against the level's requirement.
- Documented scope: They check that the systems in scope match the asset register, so an unmanaged server cannot quietly fall outside the claim.
- Approved baselines: They look for written, approved standards for application control rules, privileged account tiers and backup retention.
- Ownership and exceptions: Each deviation should have a named owner, a reason and an expiry date.
- Consistency across estate: A setting applied to one domain does not prove it applies everywhere, so samples should cover each domain in scope.
Before engaging an assessor, confirm which configuration exports and policy documents your environment can produce on request, and who in your team can explain each one.
Effectiveness testing asks whether the control works in practice. A correctly configured setting can still fail if nobody reviews it, if an exception is never closed, or if a restore has never been attempted. Assessors therefore look for operating records over a period, not a single snapshot taken for the audit.
- Logs and alerts: They request evidence that blocked executions, failed logins and privileged sessions are recorded and reviewed.
- Scan results: Vulnerability scan outputs show whether patch cadences are met and whether findings are closed by their deadlines.
- Test restores: Backup claims are supported by restore tests that recovered data was checked, not only that a job reported success.
- Exercise records: Tabletop or technical exercises that show the team acting on a finding carry weight.
- Trend over time: Repeated evidence across months shows the control is maintained, which a single screenshot cannot show.
Ask your assessor which evidence period they expect and what sampling method they will use, so your team can produce those records before fieldwork starts.
ASD publishes the Information Security Manual in OSCAL with Essential Eight baseline profiles for ML1, ML2 and ML3. In ISM v2026.09.4, these profiles contain 46, 87 and 123 controls respectively. Every ML1 control also appears in ML2, and all but three ML2 controls (ISM-1691, ISM-1695 and ISM-1873) also appear in ML3, where ML3 replaces those three with stricter versions. Assessors can use these profiles as a structured checklist rather than working from memory of the maturity model.
- ML1 as the base: The 46 ML1 controls form the foundation that every higher claim inherits.
- ML2 roughly doubles the set: The 87 controls at ML2 add to the base, so the step is substantial in evidence terms.
- ML3 replacements: The three ML2 controls replaced at ML3 are the ones to read closely, because the stricter versions change what is tested.
- Machine-readable tracking: ASD states the OSCAL files can be loaded into GRC tooling to track implementation control by control.
- Mapping to evidence: Each control can be linked to the configuration export, log or restore record that supports it.
Before fieldwork, load the profile for your target level into your tracker and confirm with your assessor whether they will test against the ISM profile directly or against the maturity model text.
How E4EIT rates effectiveness and why domains matter
ASD's Essentials series rates effectiveness action by action and domain by domain, not for the organization as a whole. The cards below cover the rating scale, the reason domains matter, and the points to confirm before you use the output as Essential Eight evidence.
Three indicator levels per action
Each E4EIT action carries indicators of good practice at three levels: not effective, partially effective and fully effective. Assessors use these to decide whether an action is working as intended, not only whether it is configured. For Essential Eight work, read the indicators next to the strategy you are testing, such as patching cadence or backup restore testing, and record which level your evidence supports. Mark the gap between partially and fully effective in your evidence log, since that is where most findings land.
Effectiveness is assessed per domain
E4EIT assesses actions for each domain rather than rating the organization as one unit. A domain is a defined area of the environment, so a result for corporate workstations says nothing final about servers or a cloud tenant. Before an assessment starts, agree the list of domains in scope and make sure each one has its own evidence. Ask your assessor how they will document domains that share tooling, such as a single endpoint management platform covering several business units.
Effectiveness does not transfer
The E4EIT mapping notes state that a set of controls found effective in one domain does not automatically prove effectiveness in another. In practice, a backup job that restores cleanly from one server room may not have been tested against a separate environment with different credentials or retention rules. Treat each domain as a separate test, and avoid carrying a passing result forward by reference. Where domains share a control, record the shared control once and test its effect in each domain separately.
Mapping evidence to each domain
Evidence is only useful if it can be traced to a domain, an action and an indicator. Build a register with one row per domain and action, linking the scan report, configuration export, log extract or restore record that supports the rating. Open-source GRC tools and version-controlled evidence folders can hold this register, and the OSCAL ISM profiles can supply the control identifiers. Keep dates on each row so the assessor can see whether the evidence reflects the current state.
Confirm the Essentials reporting path
The Assessment evidence guide for enterprise IT was published on 15 October 2026 as the first chapter of ASD's Essentials series, and its mapping collection references the Essential Eight. The Essential Eight itself is a set of mitigations rather than a certification scheme, so there is no ASD certificate to obtain. Before you rely on E4EIT ratings for Essential Eight reporting, confirm with ASD how the Essentials series is expected to be used, including whether a regulator, customer or contract asks for it specifically.
Which evidence and tooling satisfy each assessment question
This table maps the questions an Essential Eight assessor asks to the evidence they expect and the tooling that can produce it. Read each row as a test: if the organization cannot show the evidence in the right column, the assessor is unlikely to accept the claimed maturity level for that strategy.
| Assessment question | Evidence an assessor will ask for | Tooling that produces it |
|---|---|---|
| Are online services and applications scanned often enough to meet the patch cadence for the target level? | Scan schedules, scan coverage reports for internet-facing services, and dated records showing findings were patched within the deadlines in the maturity model | Self-hosted vulnerability scanners with scheduled jobs and exportable reports; confirm the scanner covers your internet-facing estate and the cadence your level requires |
| Is every operating system and application in scope either supported or removed? | Asset inventory with versions, lists of unsupported software and records of replacement or removal | Asset inventory and configuration management tooling; confirm it reads installed software and OS versions across all in-scope hosts |
| Is multi-factor authentication enforced for the required users and systems, and is it phishing-resistant at higher levels? | Identity provider configuration exports, conditional access or MFA policy settings, and reports showing enrollment and exceptions | Self-hosted identity provider policy exports and authentication logs; confirm which MFA methods your platform supports for phishing-resistant assessment |
| Are privileged accounts validated, limited, separated and monitored? | Privileged account register, dedicated admin account listings, access review records and privileged activity logs | Directory and privileged access tooling with exportable account lists and audit logs; confirm just-in-time and credential protection features before relying on them at ML3 |
| Can the organization show that central logging captures the events an assessor expects at ML2? | Log source inventory, retention settings, evidence that logs are forwarded centrally and that alerts are reviewed | Self-hosted central log collection and search platform; confirm retention and tamper protection meet your assessor's expectations |
| Are backups performed, protected and test-restored on the schedule the maturity model sets? | Backup job logs, restore test records with dates and outcomes, and access rights for backup and deletion | Backup software with job reporting and restore test logging; for ML3, confirm that immutable retention is supported and that restore tests are recorded |
| Does the organization track each control against ASD's baseline profiles and keep the evidence current? | Control-by-control status against the ML1, ML2 or ML3 profile, named owners, dated evidence and records of recurring reviews | GRC tooling that imports ASD's OSCAL profiles, as ASD describes; confirm the tool loads the ISM v2026.09.4 Essential Eight profiles you intend to assess against |
| Does the evidence show the control is effective, not just configured? | Test results, monitoring outputs and records of drift detection, not only screenshots of settings | Compliance monitoring with configuration drift reporting. Microsoft describes Microsoft Purview Compliance Manager, with Essential Eight templates for all three levels, as a point-in-time option for monitoring; confirm its fit with your environment and assessor before relying on it |
What must be in place before an assessor arrives
An Essential Eight assessment tests evidence, not intentions. Each card below is an item an assessor will ask for early, and each has a check you can run yourself before the assessor sees the environment. Work through them in order, because the target level sets the scope for everything else.
Confirmed target level and scope
Record the maturity level you are assessing against (ML1, ML2 or ML3) and the systems, domains and user groups it covers. Assessment is per strategy and per domain, so a level claimed for corporate workstations does not carry over to servers or a separate business unit. Check that the scope statement names every in-scope domain and that someone with authority has signed it. Ask the assessor to confirm in writing whether they will test the whole estate or a sample.
ISM profile mapping
Map each in-scope control to the ISM Essential Eight baseline profile for your target level. ASD publishes these profiles in OSCAL, which can be loaded into GRC tooling, so the mapping can be generated and tracked rather than maintained by hand. Check that every control in the profile has an owner, an implementation status and at least one piece of evidence. Gaps you find here are cheaper to close than gaps an assessor finds.
Evidence owners per strategy
Name one accountable owner for each of the eight strategies, plus a deputy who can produce the evidence when the owner is unavailable. Owners should be the people who run the control day to day, such as the vulnerability management lead for patch cadences or the identity team for MFA and privileged access. Check that each owner can point to where their evidence lives and how often it is refreshed. Ownership gaps usually surface when an assessor asks for a restore test record and nobody can locate it.
Configuration baselines with drift monitoring
Document the approved configuration for workstations, servers, browsers, Office and PowerShell, then monitor for drift against it. Microsoft describes Essential Eight assessment and remediation as a point-in-time activity and recommends continuous monitoring for compliance and configuration drift. Check that a settings export from each baseline can be produced on request and that exceptions carry an approval and an expiry date. A baseline that was correct at one scan says little about the state of the estate today.
Restore test records
Keep dated records of backup restores tested against the systems and data in scope, including who ran each test, what was restored, how long recovery took and whether the result matched the expected data. Backups that have never been restored are weak evidence for the regular backups strategy. Check that the most recent restore covers a representative system at the target level and that failed tests have a logged remediation. Confirm with the assessor which restore evidence they want to see on day one.
Pre-assessment gap review
Run a structured review against the ISM profile and each strategy's indicators before the assessor starts, and record every gap with an owner and a date. Use a self-assessment that asks for evidence, not opinion: for each control, find the artifact that proves it and note what is missing. Rate effectiveness as well as implementation, because an assessor will test whether a control works, not only whether it exists. Keep the review dated so you can show what changed since it was run.
Who owns the controls, who prepares evidence, and who assesses
The organization owns the Essential Eight program. It decides which maturity level it is targeting for each of the eight mitigation strategies, accepts the risk of any gap, funds the work and signs off the final position. No outside party can make those decisions on its behalf. Because the Essential Eight is a set of mitigations rather than a certification scheme, there is no ASD certificate to hold, so the organization's own sign-off and its assessor's conclusions are what carry weight with regulators, customers and boards.
- Target level decisions: Choose the maturity level per strategy and record why, since a higher level changes obligations across the strategy.
- Control ownership: Name an accountable owner for each strategy, such as the identity lead for multi-factor authentication and the platform lead for patching.
- Risk acceptance: Document any control that is not yet met, the compensating measure and who accepted the residual risk.
- Sign-off: Approve the evidence pack and the maturity statement before it is shared externally.
- Ongoing operation: Keep controls running after assessment, since drift after the assessment date is the organization's problem.
Before engaging anyone, confirm internally who holds the accountable owner role for each strategy and who will sign the final position.
An implementation partner, such as DeployOpen, prepares the systems, configuration and evidence that the organization's controls depend on. DeployOpen deploys and configures self-hosted open-source platforms inside the client's own infrastructure, then documents what was built and how it can be checked. DeployOpen does not issue reports, certificates or maturity ratings. Only an independent assessor can reach a conclusion about maturity.
- Configuration work: Build and harden the tooling for patch scanning, central logging, backups and access control in the client's environment.
- Evidence packs: Assemble configuration exports, scan outputs, restore-test records and change logs that map to the relevant ISM controls.
- Handover: Deliver runbooks, ownership lists and the evidence index so the organization can operate and defend the controls.
- Gap reporting: Identify where configuration does not yet meet the target level, so the organization can decide what to fix.
- Scope limits: Work is agreed in a written, fixed scope with deliverables and timelines set before work begins.
Check that the partner's written scope lists evidence deliverables and states plainly that the partner does not assess or certify.
The independent assessor tests whether each strategy is implemented and effective against the maturity model, then reaches the conclusion. The assessor must be independent of both the organization's control owners and the implementation partner that built the systems, because a party that configured a control is poorly placed to test it. Depending on the engagement, the assessor may be an internal audit function, an external audit firm or another qualified reviewer, and the organization should confirm the assessor's qualifications and independence before work begins.
- Test design: Select samples and tests for each strategy and each maturity level, against the ISM baseline profiles and the maturity model.
- Effectiveness testing: Check that controls work in practice, not only that settings exist, using the evidence the organization provides.
- Domain-level review: Assess actions per domain, since results for one domain do not prove effectiveness in another.
- Conclusion and report: Issue the findings and maturity view in the assessor's own report, which the organization then owns and shares.
- Independence checks: Confirm the assessor has no role in building the controls it tests.
Before engaging an assessor, ask how they will treat evidence produced by an implementation partner and what they need from you to test each strategy.
Why assessments stall and how to avoid it
Essential Eight assessments rarely fail on a single missing control. They stall because evidence is out of date, scope is unclear, or a result from one maturity level is assumed to hold at another. The cards below cover the pitfalls we see most often and the check that prevents each one.
Treating a snapshot as ongoing proof
A configuration export taken for one review shows the state of the environment on that day only. Microsoft describes Essential Eight assessment and remediation as a point-in-time activity, so drift can erode a result within weeks. Schedule recurring collection of patch status, MFA enrolment, admin group membership and macro settings, and keep dated records so an assessor can see the control operating over time.
Assuming ML1 carries to ML2 and ML3
Every ML1 control is also in ML2, but ML2 adds controls that roughly double the ML1 set in the ISM Essential Eight profiles. Teams that pass ML1 often assume the higher level is a small step. Load the ML2 and ML3 profiles from ASD's OSCAL release, list the controls that are not yet met, and size the work against that list before committing to a target level.
Relying on implementation evidence alone
Showing that a setting exists proves implementation, not effectiveness. Each E4EIT action carries indicators of good practice at three levels: not effective, partially effective and fully effective. Assessors look for proof that the control works, such as a blocked execution attempt in application control logs or a restore test with recorded timings. Ask your assessor which indicators they will test before you collect evidence.
Unclear scope across domains
E4EIT assesses actions per domain rather than across the organisation, and its mapping notes state that controls effective in one domain do not prove effectiveness in another. A workstation fleet that is well managed does not cover a separate server estate or a cloud tenant. Write down each domain in scope, name its owner, and confirm that every domain gets its own evidence set before the assessment starts.
Scattered evidence across tools
Patch reports sit in one console, MFA records in another, backup logs on a server and macro policies in a GPO export. When an assessor asks for proof, the team rebuilds the story by hand, and gaps hide in the seams. Map each evidence item to the ISM control it supports, store it in one location with a consistent naming scheme, and track coverage in GRC tooling that can read ASD's OSCAL profiles.
Questions buyers ask about Essential Eight assessments
Is there an Essential Eight certificate I can obtain?
No. The Essential Eight is a set of mitigation strategies rather than a certification scheme, so ASD does not issue a certificate for it. Maturity is shown through an assessment of each strategy's implementation and effectiveness against the Essential Eight Maturity Model, and the resulting evidence is what your board, regulator or customer reviews. Ask any provider offering a certificate what body issued it and under which scheme, and treat an answer that names no scheme as a warning sign. The maturity model is published on cyber.gov.au.
Who is qualified to assess Essential Eight maturity?
Assessment is performed by a party independent of the team that built the controls, usually an experienced security assessor or an external reviewer with Essential Eight and ISM experience. Because there is no accreditation scheme for Essential Eight itself, confirm the assessor's method, sample sizes and evidence standards in writing rather than relying on a title. Ask for examples of how they tested each strategy at the level you are targeting, and who signs the final report. DeployOpen prepares systems, controls and evidence for assessment but does not perform or sign maturity assessments.
Can our own team self-assess our Essential Eight maturity?
Yes, an organization can assess its own maturity against the model, and many do so for internal planning. The limitation is independence: a self-assessment is only as credible as the evidence behind it and the objectivity of whoever reviews it. Teams that self-assess should test effectiveness, not just configuration, and record the evidence for each claim. If an external party such as a regulator, board or customer needs confidence in the result, an independent assessment is the stronger route. Whatever you choose, document who did the work and when.
How much internal staff time does an Essential Eight assessment need?
Internal effort is driven mainly by the number of systems in scope, how well asset and configuration records are kept, and whether logs and backup restore records already exist. Expect staff to provide system owners, administrators who can demonstrate privileged access and patching, and someone who can run restore tests and explain them. Ask any provider for a written list of the people and artifacts they will need from you, the number of interview sessions, and the access they require to systems. Neither ASD's model nor the supplied sources give a duration, so request a timeline in the quote tied to your scope.
How do the ISM Essential Eight profiles fit into an assessment?
ASD publishes the Information Security Manual in OSCAL with Essential Eight ML1, ML2 and ML3 baseline profiles. In ISM v2026.09.4 these contain 46, 87 and 123 controls respectively, and every ML1 control is also in ML2, while all but three ML2 controls (ISM-1691, ISM-1695 and ISM-1873, which ML3 replaces with stricter versions) are also in ML3. Assessors use these profiles as the control set to test against for the level claimed, and your team can load the OSCAL files into GRC tooling to track each control. Read the control text in the ISM catalog yourself so you know what the evidence must show.
What changes when ASD's Essentials series rates effectiveness with E4EIT?
The Assessment evidence guide for enterprise IT, version 2026.10.15, is the first chapter of the Essentials series and is published in OSCAL. Each E4EIT action carries indicators of good practice at three levels: not effective, partially effective and fully effective. It assesses actions per domain rather than across the whole organization, and its mapping notes state that controls effective in one domain do not automatically prove effectiveness in another. Ask your assessor how they will apply E4EIT ratings to each domain in scope and how they will reconcile those results with your Essential Eight claim.
How do I choose an assessor or consultant for Essential Eight?
Start with a written scope that lists the strategies, maturity level, systems and domains in play, then ask each candidate to quote against that scope. Compare who performs the assessment, who signs the report, how evidence is retained, and whether the same firm would also remediate gaps, since independence may matter to your stakeholders. Ask for references you can verify, a sample of the evidence list they will request, and their approach to effectiveness testing. DeployOpen implements, hardens, documents and supports self-hosted open-source platforms and prepares evidence, and its work is fixed-scope and agreed in writing before it starts. Pricing follows from that written scope, and DeployOpen does not publish a price list.
How DeployOpen works on this
DeployOpen prepares the systems, configuration and evidence that an independent assessor needs to test each Essential Eight strategy for implementation and effectiveness. The organization owns its maturity claim, and DeployOpen does not issue assessment reports or certificates, because the Essential Eight has no certification scheme.
How we scope
- Engagements are fixed-scope, with the assessed maturity level, strategies and environments agreed in writing before work starts.
- The written scope names which systems, domains and business units an assessor will sample, so evidence collection matches the boundary.
- Scope documents which Essential Eight strategies are in play and which ISM baseline profile controls will be mapped to each.
How we build
- We configure self-hosted vulnerability scanning, central logging and backup tooling inside your own cloud accounts, data centers or air-gapped networks.
- Each strategy is tested against its ISM baseline controls, with configuration exports and test records kept for the assessor to review.
- Where the Essential Eight is tracked in GRC tooling, we can load ASD's OSCAL profiles so control status stays linked to evidence.
How we hand over
- You receive documented evidence per strategy, showing what was implemented, how it was tested and where the records are stored.
- Gaps found during preparation are listed with the controls affected, so your team can decide what to fix before the assessment.
- Runbooks cover recurring tasks such as scan cadences, restore tests and access reviews, so the evidence stays current after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
- A retainer can keep evidence collection running between assessment cycles, including re-testing after configuration drift.
- Confirm with DeployOpen during scoping which assessor will review the evidence, since assessment itself stays with that independent party.
