What an Essential Eight consultant does for your organization
A customer, contract or internal target now asks for Essential Eight maturity, and the first thing to understand is who does what. An Essential Eight consultant or implementation partner prepares systems, documentation and evidence against the ISM Essential Eight baseline profiles. There is no ASD certificate for the Essential Eight, so the organization owns its maturity claim, and an independent assessor reviews that claim against the maturity model. The partner does not issue the verdict.
The scope a consultant covers depends on two things: the target maturity level and the split between technical and process-based work. The ISM v2026.09.4 profiles contain 46 controls at ML1, 87 at ML2 and 123 at ML3, and every ML1 control also appears in ML2. Moving from ML1 to ML2 therefore adds controls rather than replacing them, so a reader should ask for a gap assessment that maps each control to a current state and a named owner. Technical work, such as configuring application control, patch scanning or immutable backups, is usually easier to scope than the people and process controls, such as annual ruleset validation and incident response exercises, which need written procedures and recurring records.
Before signing anything, ask the consultant to confirm four things in writing: the target level and the profile version they assess against, which controls they will implement and which they will only document, what evidence will exist at the end of the engagement, and who keeps that evidence current after handover. Ask whether the work will be tracked against the ASD OSCAL profiles in a GRC tool, since ASD says those files can be loaded for tracking, and confirm the current ASD guidance on the Essential Eight maturity model before fixing the scope. A partner that prepares the evidence well makes the independent assessment faster, but the organization still has to be able to show that each control works in its own environment.
How a gap assessment against the ISM baseline profiles works
A gap assessment turns the ISM Essential Eight baseline profiles into a current-state record and a prioritized gap register that the organization owns and can hand to an independent assessor. The sequence below shows who does each step and what each step produces.
Confirm the target maturity level and scope
The organization chooses the Essential Eight maturity level it intends to reach, either ML1, ML2 or ML3, and records which systems, users, business units and data sets are in scope. The consultant helps test whether the chosen level fits the threat profile and the contractual or regulatory obligations that apply. The step closes with a signed scope statement and a named executive sponsor, because every later decision depends on both.
Load the ISM Essential Eight baseline profile
The team loads the ISM Essential Eight profile for the chosen level into its GRC tooling. ASD publishes these profiles in OSCAL, a machine-readable format that ASD says can be loaded into GRC tooling to track implementation. In the ISM v2026.09.4 release, the ML1 profile contains 46 controls, ML2 contains 87 and ML3 contains 123. Every ML1 control is also in ML2, and all but three ML2 controls (ISM-1691, ISM-1695 and ISM-1873, which ML3 replaces with stricter versions) are also in ML3, so work done at a lower level carries forward. The output is an imported control set with the release version recorded.
Map each control to the in-scope estate
The consultant and the internal technical owners map each control to the systems, accounts, endpoints, servers and repositories it applies to. Where a control refers to a technology the organization does not run, the team records that as not applicable with a reason rather than dropping it silently. The output is a control-to-asset mapping that a later assessor can trace from a control to specific systems.
Record the current state of each control
For each in-scope control, a technical owner records what is implemented today, how it is configured, and which evidence exists or could be produced. The consultant checks configuration exports, scanner output, policy settings and sample records rather than relying on interview answers alone. Each control receives a status such as implemented, partially implemented or not implemented, with the evidence location noted. The step is complete when every in-scope control has a status and an evidence pointer.
Identify and classify gaps
Each control that is not fully implemented becomes a gap entry describing what is missing, which systems are affected, and what would close it. Process and people controls, such as the annual ruleset validation and incident reporting obligations, are recorded separately so they are not mistaken for technical configuration work. The output is a draft gap list that separates technical changes from documentation and governance changes.
Assign owners and build the gap register
The organization assigns a named owner to every gap, along with the internal or external party expected to do the work and the approval route for changes. The consultant drafts the gap register, and the organization reviews and accepts it. Remediation items that depend on licensing, budget or a change window are flagged so the decision is visible. The output is a gap register that the CISO or delegate has approved, with an owner on every line.
Hand over the register for independent review
The register, the scope statement and the evidence index go to the organization's internal assurance function or to an independent assessor the organization engages. The consultant does not certify maturity or issue a report. The assessor decides what it accepts as evidence and what it tests. The step closes when the organization has a written record of the handover, and the register is kept under version control so later reviews can see what changed.
What the implementation work delivers, by team
Infrastructure teams receive the technical controls that run across endpoints, servers and identity systems. An implementation partner typically configures these settings, documents them and captures the configuration state that an assessor will later sample. Most of this work is one-time build effort followed by recurring monitoring for drift.
- Patching cadences: Vulnerability scanning schedules and patch deadlines for applications and operating systems, set to the ML level the organization is targeting, with scan and deployment reports retained.
- MFA and privileged access: Phishing-resistant MFA for in-scope services, dedicated administrative accounts, and privileged access controls configured and recorded.
- Application control: Allowlisting policies on workstations and, at higher levels, servers, with the approved software set documented and the rule change process defined.
- Macro and hardening settings: Office macro restrictions and user application hardening baselines applied through group policy or device management, with exported configuration as proof.
- Backups with restore tests: Backup jobs, retention settings and scheduled restore tests, with test results kept in a form an assessor can review.
Before accepting any deliverable, check whether the configuration exports are current, whether they cover every in-scope device class and whether someone in the organization can reproduce them without the partner.
Security operations teams own the detection, response and event analysis that sit around the technical controls. Some of these tasks are technical, such as log collection and alert routing, but several are process controls that a technology platform cannot complete on its own. A partner can design the workflow, build the tooling and draft the procedures, while the operations team performs and records the activity.
- Incident response plan enactment: Documented exercises or live responses that show the plan was followed, with timestamps, decisions and owners recorded.
- Incident reporting: Defined routes for reporting incidents to the CISO and to ASD, with the reporting criteria, contacts and sign-off steps written down.
- Event analysis: Review of logged events from the in-scope systems, with findings triaged and closed, and analyst notes kept.
- Central logging: Log sources forwarded to a central platform for the levels that require it, with retention settings recorded.
- Alert and ticket records: Ticket histories that connect detections to response actions, which give an assessor a trail to sample.
Confirm with the operations lead which of these tasks the organization performs itself, which a managed service provider performs and which the partner only documents. Each task needs one named owner.
Governance teams own the evidence package that proves the controls operate. This covers the annual ruleset validation tied to ISM-1582, approvals, policy records and the store where documents are kept. Microsoft treats these people and process controls as outside its technical guidance and suggests storing their documentation in Purview Compliance Manager as evidence, which is one option among several for an organization to consider.
- Annual ruleset validation (ISM-1582): A recorded review of the application control and other rulesets, with the reviewer, date, findings and approved changes captured each year.
- Policy and procedure records: Approved versions of the procedures that cover patching, access, backups and incident response, each with an owner and review date.
- Evidence index: A map from each Essential Eight requirement to the artifact that supports it, so an assessor can find it without a search.
- OSCAL-based tracking: Where the organization uses GRC tooling, the ASD OSCAL profiles can load the control set so status is tracked against the ISM controls.
- Assessment scope statement: A written boundary for the systems, business units and maturity target under review, agreed with leadership.
Ask the partner which artifacts it will produce, which the organization must produce, and where each file will be stored. Confirm that an independent assessor, not the partner, will judge the result.
Which evidence a later assessment will ask to see
A later Essential Eight assessment tests whether each mitigation strategy is implemented and effective, so the evidence has to show both the configuration and that it has been kept current. The cards below cover the evidence types a consultant typically prepares, what each one proves and who should own refreshing it. Confirm with your assessor which evidence guide version they expect.
Patch scan results against deadlines
Scan exports from your vulnerability scanner, paired with the patch deadlines set in your policy, show whether online services, applications and operating systems are patched within the windows your maturity level requires. Assessors look for the scan cadence, the date each finding was raised, and the date it was closed. Ask your consultant to set up recurring exports rather than one-off screenshots. Security operations should own refreshing this evidence, with a named reviewer for exceptions.
MFA configuration exports
Exports from your identity provider show which online services, remote access paths and privileged systems require multi-factor authentication, and which methods are permitted. At higher maturity levels, assessors ask whether the methods are phishing-resistant. Capture the configuration as an export with a timestamp, not a description of the intended setup. Identity engineering should own the refresh, and any change to the policy should trigger a new export.
Privileged account inventories
An inventory of administrative accounts, with the owner, purpose, approval record and last review date for each, shows that privileged access is limited and separated from day-to-day accounts. Pair it with evidence of how privileged sessions are logged. The inventory goes stale quickly, so the identity team should reconcile it against directory group membership on a fixed schedule and record who signed off.
Application control policy and logs
The approved application rules and the block and allow logs from the enforcement tool show that execution is restricted to an approved set. Assessors compare the policy with the events recorded in the logs, including blocked attempts and exception approvals. The endpoint or platform team should own the policy file and its change history, and the security team should review exception logs.
Backup restore test records
Restore test records show that backups can be recovered, not only that they run. Each record should name the system restored, the backup used, the date, the person who ran the test, the time to recover and the result. For higher maturity levels, assessors also check the access controls and retention settings that protect backups from change or deletion. The operations team should own the test calendar and the record of failed restores.
Signed process documents
Some Essential Eight requirements are people and process controls, such as the annual validation of your application control ruleset, incident response plan enactment and reporting to the CISO. Assessors expect documents that show who approved them, when, and what changed since the last version. Store them in a controlled repository with version history, and assign a document owner who schedules the annual sign-off.
Where the consultant's role ends and the assessor's begins
The organization owns its Essential Eight controls, the implementation partner prepares the systems and evidence, and only an independent assessor reviews and reports on the result. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to buy. Maturity is established by assessing how each strategy is implemented and how well it works against the maturity model. That assessment is performed by someone outside the implementation team, and the organization's leadership remains accountable for the decisions it records, including which maturity level it claims and which risks it accepts. DeployOpen plans, configures and documents technical controls inside the client's own environment, and it prepares the evidence an assessor will ask for, such as configuration baselines, patch and scanning records, restore test logs and privileged access reviews. DeployOpen does not issue audit reports, attestations or certificates, and hiring a partner does not guarantee a particular maturity result. A partner can close gaps it is contracted to close, but the outcome depends on whether the controls operate consistently over time and whether the assessor agrees with what they show.
Before engaging anyone, confirm the assessor independence rules with your customer, regulator or contract owner. Some parties require that the assessor has no role in designing or operating the controls under review, which can limit whether the same firm may both implement and assess. Ask the assessor to state in writing how it will handle work previously performed by your implementation partner, and ask your partner to document what it did, when, and under whose direction, so the assessor can trace each change. Agree the boundary in the statement of work. Name the evidence the partner will deliver, the owner who will accept it, and the recurring reviews, such as the annual ruleset validation described in the ISM, that remain with your staff after the engagement closes. The Essential Eight maturity model on cyber.gov.au is the reference your assessor will use, so read the relevant levels with your partner before work starts.
Which consultant scope fits your situation
This table compares three ways to buy Essential Eight help: a gap assessment, technical implementation with documentation, and ongoing support after implementation. Read each column for who does the work, what you receive, and when the option fits. Most engagements are fixed-scope, so the scope and deliverables are agreed in writing before work starts.
| Scope element | Gap assessment only | Implementation with documentation | Ongoing support or retainer |
|---|---|---|---|
| Who does the work | Consultant reviews your environment against the ISM Essential Eight baseline profiles | Implementation partner configures technical controls and writes process documentation with your staff | Partner and your team run recurring checks, reviews and upgrades under agreed terms |
| Main output | Gap register mapping each control to current state, with prioritized remediation items | Configured systems, change records, process documents and evidence packs for the agreed controls | Periodic reports, updated evidence and change records as the environment shifts |
| Ownership of controls | Stays entirely with your organization | Your organization owns the controls; the partner prepares systems and evidence | Your organization owns the controls and decides which recurring tasks the partner covers |
| Fits when | You need a baseline before budgeting or choosing a target maturity level | You know the gaps and need technical work and documentation delivered to a written scope | Controls are in place and you need someone to keep evidence current between assessments |
| What you must provide | Access to configuration, asset lists and staff for interviews | Named owners for each control, change windows and access to target systems | A named internal owner who accepts findings and approves changes |
| Scope agreement | Fixed scope, agreed in writing before work starts | Fixed scope, deliverables and timelines agreed in writing before work starts | Scope and service levels agreed in writing; confirm the terms before signing |
| Does not include | Remediation work or certification of any kind | Independent assessment or any certificate; no ASD certificate exists | Independent assessment, audit reports or certification decisions |
Questions buyers ask before hiring an Essential Eight consultant
Can our own team implement the Essential Eight without a consultant?
Yes, many organizations do, and the Essential Eight is designed as a set of mitigations an organization can implement itself. The decision depends on whether your team has the time and skills to work through the ISM baseline profiles for your target level, configure the technical controls, and write down the process controls that auditors will later ask about. Teams that already run modern endpoint management, centralized logging and tested backups usually need less outside help than teams that are building those capabilities for the first time. A consultant or implementation partner is most useful for a gap assessment, a prioritized plan, and hands-on engineering capacity you do not have in-house. Ask the partner which tasks they would leave with you.
What does the Essential Eight work need from our internal staff?
Your staff keep ownership of decisions and of the controls themselves, even when a partner does the engineering. Expect to need an accountable owner for the programme, administrators who can approve changes to endpoints, identity and backup platforms, and people who can answer questions about applications, business owners and data. Process controls such as annual ruleset validation, incident reporting and incident response testing need named people who will perform and sign off on them, so plan for recurring time rather than a one-off project. Ask any consultant to list which roles, hours and approvals they will need from your organization in writing.
Can a consultant certify that we meet the Essential Eight?
No. The Essential Eight is a set of mitigations rather than a certification scheme, and there is no ASD certificate. Maturity is shown by assessing each strategy's implementation and effectiveness against the maturity model, and the organization owns the conclusion it reaches. A consultant can help you prepare systems, controls and evidence, and can run an internal readiness review, but the assessment itself is a matter for your own governance or an independent assessor that you engage. Be wary of any proposal that promises a badge or certificate from ASD. Ask the partner to state its role in the final evidence pack.
What drives the scope and effort of an Essential Eight engagement?
Four factors shape most of the scope. The first is target maturity level, because ML2 and ML3 baseline profiles contain substantially more ISM controls than ML1 (46, 87 and 123 controls respectively in ISM v2026.09.4), and every ML1 control is also in ML2. The second is the number of controls you already meet, which determines how big the gap is. The third is estate size, meaning the number of endpoints, servers, identity tenants, applications and backup sets in scope. The fourth is existing tooling: a team with working vulnerability scanning, central logging and immutable backups starts further ahead than one that needs to deploy them. For figures on how these factors translate into cost, see the cost page for this topic.
What should a written scope for an Essential Eight engagement include?
A written scope should name the target maturity level, the systems and business units in scope, and the baseline profile and ISM controls each deliverable addresses. It should list deliverables such as the gap assessment, the implementation plan, configuration changes, documentation of process controls and the evidence package, with an owner and acceptance criteria for each. It should state what your organization must provide, including access, approvals, staff time and decisions, and what is excluded, such as the assessment itself or any third-party licensing. Ask for the timeline and payment milestones to be tied to those deliverables. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope.
Does DeployOpen issue Essential Eight reports or certificates?
No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Those are the responsibility of independent auditors, assessors or certification bodies that you engage. Ask any partner, including DeployOpen, to show in writing which parts of the engagement produce evidence for your assessor and which parts produce a report, and who signs each one.
What should we confirm about an Essential Eight partner's experience before signing?
Ask for a description of the partner's approach to the ISM baseline profiles, how it maps your current state to the controls for your target level, and how it hands over configuration, documentation and evidence your team can maintain. Ask which of the technical strategies it has implemented in environments similar to yours, and how it treats the people and process controls that vendor guidance leaves out. Ask how it will keep evidence current after the first assessment, since maturity is an ongoing condition rather than a one-time event. Request references only where the partner can share them under its own confidentiality terms.
How DeployOpen scopes and prepares Essential Eight evidence
DeployOpen works on Essential Eight engagements as a fixed-scope implementation partner inside your own infrastructure. We prepare the technical controls, documentation and evidence that your organization owns and that an independent assessor reviews, and we do not issue any maturity certificate or assessment report.
How we scope
- Agree in writing which Essential Eight strategies and which maturity level are in scope before work starts.
- Map each in-scope strategy to its ISM baseline profile controls so the gap assessment has a defined target.
- Confirm which people and process controls your staff will own, such as annual ruleset validation and incident reporting.
How we build
- Implement technical controls in your cloud accounts, data centers or air-gapped networks, not in a DeployOpen-hosted environment.
- Configure self-hosted open-source tooling for patch cadence scanning, central logging and backup restore testing where the scope requires it.
- Test each control against its stated requirement and record the results so the assessor can trace each claim to evidence.
How we hand over
- Deliver written documentation of process controls, configurations and runbooks, with a named owner for each recurring task.
- Package evidence by strategy and control reference so your internal team and an independent assessor can review it without us present.
- Walk your staff through what each control produces and where that evidence is stored for future assessments.
How we support
- Support ongoing operation, upgrades and recurring evidence collection as a retainer if your organization wants continuity after handover.
- Re-test controls after configuration changes so drift is caught before the next assessment cycle.
- Confirm with your assessor which evidence formats they accept before the engagement closes, since requirements vary by assessor.
