What to outsource for the Essential Eight and what to keep

If a customer, contract or internal target now calls for an Essential Eight maturity level, you can outsource the technical implementation and much of the monitoring. Ownership of controls, process decisions, incident reporting and recurring reviews stays with your organization. Those items are where assessors look for accountable people, so a partner can prepare them but cannot hold them for you. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate, and no partner can issue one. Evidence of maturity comes from an independent assessment of each strategy's implementation and effectiveness against the Essential Eight maturity model.

The split depends on two things: the target maturity level and the capacity of your internal team. At ML1, a managed service provider can often run most of the technical settings, such as patch deployment and privileged account separation, while an internal owner signs off decisions. At ML2 and ML3, the process load grows. The ISM baselines require event logs to be protected from unauthorised modification and deletion, analysed in a timely manner, and incidents reported to the CISO and to ASD, with the incident response plan enacted. Confirm with each provider which of these they operate, which they only feed, and which remain with your security team. Ask who receives alerts out of hours and who signs the incident report.

Recurring reviews need a named owner before work starts. Application control rulesets must be validated at least annually from ML2 (ISM-1582), and the Microsoft Office trusted publisher list at least annually at ML3 (ISM-1676). Requests for privileged access must be validated when first requested (ISM-1507). Write these into a responsibility matrix that names one internal owner for each task, the partner's role, and where the evidence is stored. Also confirm that your contract gives you the configuration exports, logs and records you need for assessment, because they must remain yours after the engagement ends. Most gaps found at assessment are missing dates and named approvers, not missing technology.

How work usually divides between staff, a managed service provider and a consultant

Internal staff own the decisions the Essential Eight cannot delegate. They approve the target maturity level, accept residual risk, decide who may hold privileged access and run the incident response plan when something goes wrong. Technical administration of endpoints, identity and backups often stays in house too, particularly where the organization already runs its own identity, endpoint management or backup platform.

Privileged access decisions: Validating each request for privileged access when it is first made (ISM-1507) and keeping the register of people who hold dedicated privileged accounts used only for privileged duties (ISM-0445).
Ruleset governance: Approving application control rulesets and the Microsoft Office trusted publisher list, then running the recurring validation (ISM-1582, ISM-1676).
Incident handling: Reporting incidents to the CISO and to ASD and enacting the incident response plan (ISM-0123, ISM-0140, ISM-1819).
Log governance: Deciding who may modify or delete event logs (ISM-1815) and who reviews analysis of logs from internet-facing servers in a timely manner (ISM-1906).
Operational review: Reviewing patch dashboards, backup restore test results and exception lists on a fixed calendar.

Check that every recurring task has a named internal owner, a dated review calendar and a sign-off record before you accept any partner's statement of work.

Technical controls partners commonly run for the Essential Eight

Most Essential Eight technical work that a partner runs falls into a short list of controls with clear configuration, monitoring and recurring review tasks. Each card names the controls involved and the decision the organization must keep. A partner builds and operates these controls only within the scope and approvals the organization sets in writing.

Application control rulesets

A partner can draft and deploy the allowlisting rules that restrict execution to organization-approved software, using Windows Defender Application Control or AppLocker where the estate is Microsoft-based. The organization must approve the baseline of permitted software and its publishers. Application control rulesets must be validated at least annually from ML2 (ISM-1582), so the owner of that review should be named before go-live. Ask the partner who signs off each rule change.

Patch scanning and deployment

Partners often configure vulnerability scanners, set scan schedules and build deployment rings so that patches reach test groups before production. The organization still owns the patch deadlines it commits to at each maturity level, the list of unsupported applications and the exception process for systems that cannot be patched on time. Confirm who approves emergency patches and who records each exception as evidence.

Central event logging for ML2

At ML2 and above, event logs must be protected from unauthorised modification and deletion (ISM-1815), and logs from internet-facing servers and detected cyber security events must be analysed in a timely manner (ISM-1906, ISM-1228). A partner can deploy the collector, forwarding rules and retention settings. The organization must decide who reviews alerts, how long logs are kept and who responds when an event meets the incident criteria.

Immutable backups for ML3

A partner can configure backup jobs, synchronise copies to a separate location and set immutability on retained backups. Restore testing and the choice of retention period remain organization decisions. Microsoft states that customers always retain responsibility for their information under the shared responsibility model, so confirm in writing which party owns retention settings, test restores and deletion approvals.

Privileged access configuration

Partners commonly build dedicated privileged accounts, separate them from day-to-day user accounts and set up approval workflows for elevated access. Requests for privileged access must be validated when first requested (ISM-1507), and privileged human users must have a dedicated privileged account used only for privileged duties (ISM-0445). The organization must decide who approves each privileged grant and who holds the validation record.

User application hardening

A partner can apply hardening settings to web browsers, Microsoft Office, PDF software and PowerShell through group policy or device management. The organization must test these settings against business applications that depend on legacy features, such as Java or macros, before rollout. Record each exception with an owner and a review date, because hardening settings tend to drift after software updates.

Which recurring reviews need a named owner

Several Essential Eight requirements recur on a schedule or fire each time a privileged request or security event occurs. Partners can run the technical checks behind them, but each review still needs an internal owner who signs off the result and keeps the record. The cards below cover the reviews that most often lose their owner after the first assessment.

Annual application control ruleset validation

From ML2, application control rulesets must be validated at least annually under ISM-1582. A partner can export current rulesets, compare them with the approved software list and flag stale entries. The internal owner, usually the endpoint or security operations lead, should approve each change, record who validated it and why, and file the signed review in the evidence repository. Ask the partner for a ruleset diff in a format your owner can read without the partner present.

Annual Office trusted publisher review

At ML3, the Microsoft Office trusted publisher list must be reviewed at least annually under ISM-1676. Publishers added for convenience often outlive the business need, so the review should ask whether each publisher still has an active use case. The owner should be the same person accountable for macro policy, with a dated approval for every retained publisher. Keep the list version, the reviewer and any removals in the evidence repository.

Privileged access validation on request

Requests for privileged access must be validated when first made under ISM-1507. This is a per-request decision, not a periodic task, so it fails quietly when no one is named. The identity or IT administration lead should approve each grant, check that the requester needs the privilege for a stated duty, and link the approval to the ticket. A partner can build the workflow in your identity platform, but the approval itself stays with your staff.

Dedicated privileged accounts

Privileged human users must have a dedicated privileged account used only for privileged duties under ISM-0445. Partners often create these accounts during implementation, then day-to-day work drifts back onto them. The identity owner should review the account list on a schedule, confirm that each account is used only for administration, and record exceptions with an end date. Keep the account inventory and review notes as evidence.

Log analysis and incident reporting

At ML2 and ML3, logs from internet-facing servers and detected security events must be analysed in a timely manner (ISM-1906, ISM-1228). Incidents must be reported to the CISO and to ASD, and the incident response plan enacted (ISM-0123, ISM-0140, ISM-1819). A managed service provider may triage alerts and run the log pipeline, but the CISO or a named incident manager must own escalation decisions, reporting sign-off and the post-incident record. Confirm who holds the reporting obligation in writing before go-live.

Evidence repository ownership

Several of these reviews produce documents that an assessor will ask for later, including approvals, exports and incident records. Someone internal should own the evidence repository, set naming and retention rules, and check each quarter that every recurring review has a filed artifact. Microsoft suggests storing process documentation in Purview Compliance Manager, but the choice of tool is yours. Ask any partner to hand over repository access and review logs before the engagement closes.

Why backups and Microsoft 365 data stay with the customer

Backups and Microsoft 365 data remain the customer's responsibility. Microsoft's Essential Eight backup guidance states that customers always retain responsibility for their information under the shared responsibility model, even when the platform provider runs the underlying service. A managed service provider or consultant can configure the mechanics, but it does not take ownership of what the organization keeps, for how long, or who can destroy it. Microsoft's own guidance points to in-place retention policies and labels as one way to protect Microsoft 365 data, and those settings are business decisions as much as technical ones. Before any partner touches the configuration, confirm who in the organization signed off on the retention schedule and who holds the Microsoft 365 compliance roles that can change it.

A partner can typically configure immutable backup storage, schedule backups, set up test restores and document the results. Those are technical tasks with clear deliverables. The organization still has to decide the decisions that shape the design: the recovery point and recovery time objectives for each data set, how long backups are retained, which data must be kept for legal or regulatory reasons, and who is authorized to approve deletion before an immutable retention period ends. Ask the partner to show where each of these decisions is recorded and who signed it. A written backup policy with named approvers is the artifact an assessor will ask for first.

Plan for recurring ownership after the initial build. Restore tests need a named internal owner who reviews results and decides whether a failed test triggers a change to the design or the retention rules. Access reviews for the accounts that can alter backup settings or delete backups belong to the organization's identity team, not the partner's. If a partner runs the backup service under a managed contract, confirm in writing which party performs each restore test, who receives the results, and what happens when a restore fails. Confirm these points with the partner and with your own Microsoft 365 administrators before scope is agreed.

How to structure a handover from partner to internal owner

The sequence moves Essential Eight work from a written scope to an internal owner who can run recurring reviews and produce evidence without the partner. Each phase closes with a named output that the organization can check before moving on.

Agree scope and responsibilities in writing
The organization and the partner agree in writing which Essential Eight strategies, which maturity level and which systems are in scope. The agreement also names who owns each people and process control, including annual ruleset validation (ISM-1582), incident reporting to the CISO and ASD, and enacting the incident response plan. The output is a signed scope document with a responsibility matrix that lists one internal owner for every recurring task. Confirm that the matrix is complete before any technical work starts, because gaps here are hard to fix later.
Run a gap assessment against the ISM baseline
The partner maps the current environment against the ISM Essential Eight ML1, ML2 and ML3 baseline profiles published in OSCAL, identifying which controls are met, partly met or missing for the target level. Internal staff should review every finding, because the partner can see the technology but the organization knows its own process reality. The output is a gap register tied to ISM control identifiers, with each gap assigned to a technical or process owner. The gap register is complete when the organization has accepted or rejected each finding in writing.
Implement technical controls in the partner's scope
The partner configures the technical controls it has agreed to deliver, such as patch scanning, multi-factor authentication settings, application control rulesets, macro policy, hardening baselines and backup configuration. Changes should be made through the change process the organization already uses, with the partner recording what it changed and why. The output is a set of configuration records, change tickets and a list of any items that remain open. Work is complete for this phase when each in-scope control has a documented configuration and a matching entry in the gap register.
Test the controls with internal staff
Internal staff who will operate the controls test them independently of the partner, using the test steps in the runbooks and the ISM control descriptions as the reference. Tests should include negative cases, such as an unapproved application being blocked or a backup restore completing to a separate location, not only successful paths. The output is a signed acceptance test record that shows the test, the result, the tester and any defects raised. The phase closes when the organization accepts the results or the partner has fixed each defect and the retest passes.
Transfer runbooks, evidence and access
The partner hands over runbooks for every recurring task, the evidence locations, administrative credentials held under the organization's control, and the configuration baseline. The internal owner confirms that they can locate each piece of evidence and that privileged access is held in accounts the organization controls. The output is a handover pack and a signed transfer checklist. Confirm the organization holds the administrative accounts and the source of configuration truth, not the partner alone, before the partner's access is reduced.
Start internal ownership of recurring reviews
The internal owner runs the first cycle of recurring tasks without the partner, including application control ruleset validation, trusted publisher list review for ML3, privileged access validation requests and event log analysis. The partner may observe or advise, but the organization records the outcomes. The output is a dated record for each recurring task showing who performed it and what was decided. Ownership is confirmed when the first cycle is completed by internal staff and the review calendar is in the organization's own tooling.
Confirm independent assessment readiness
The internal owner collects the evidence set mapped to the maturity level, checks that it is current and reviews it against the gap register to confirm all findings are closed or formally accepted. The organization then engages its own independent assessor if one is required, since the Essential Eight is a set of mitigations with no ASD certificate. The output is an evidence index and a readiness summary the organization owns. Ask the assessor, not the partner, which evidence format and scope it will accept before the assessment begins.

Choosing an operating model for each Essential Eight area

This table compares three ways to deliver Essential Eight work: in-house operation, a managed service provider running technical controls, and a consultant-led implementation that the organization operates afterward. Read each row against the controls that must stay with the organization, then check the contract terms before signing.

Operating model	What it fits	What stays internal	What to confirm in the contract
In-house delivery	Organizations with staff who already run Microsoft endpoint, identity and backup tooling and can own recurring reviews	Technical operation, process controls, incident response, and the annual ruleset and trusted publisher reviews	Named internal owners for each Essential Eight strategy and the evidence each one must retain
Managed service provider operation	Organizations that want daily running of patching, logging, backup jobs and application control tooling handled by a provider	Accountability for the information itself, risk acceptance, privileged access approvals, and incident reporting to the CISO and ASD	Which ISM controls the provider runs, how it hands over logs and backup records, and who validates privileged access requests
Consultant-led implementation with internal operation	Organizations that need a gap assessment against the ISM baseline profiles and a working configuration, then will run it themselves	Day-to-day operation, documentation upkeep, recurring reviews, and evidence for the independent assessment	Handover deliverables, documentation format, and whether the consultant offers ongoing support or a separate retainer
Hybrid split by strategy	Organizations that outsource some strategies, such as backup or logging, and keep others such as privileged access in-house	Any strategy or control the contract does not explicitly assign to a provider	A responsibility matrix listing each Essential Eight strategy, its ML level and the party that owns each control

Questions buyers ask about splitting Essential Eight work

Can a partner run the whole Essential Eight for us?

A partner can build and operate much of the technical work, but it cannot own the controls. Your organization stays accountable for each mitigation strategy, its maturity level and the evidence behind it. A partner typically prepares systems, configures tooling, writes runbooks and collects evidence, while your staff approve access decisions, accept risk, and sign off on policy. Because the Essential Eight is a set of mitigations rather than a certification scheme, there is no ASD certificate to hand over. Maturity is judged by an independent assessor against the maturity model, so the question is not whether a partner can do everything, but which parts you are willing to delegate and how much of your own staff time each part still needs.

What must our internal team still do after a partner finishes?

Your internal team keeps the people and process controls that depend on your own decisions. Microsoft's guidance treats annual application control ruleset validation, incident reporting to the CISO and ASD, enacting the incident response plan, and event analysis as controls outside technical configuration. Requests for privileged access must be validated when first requested (ISM-1507), and privileged users need a dedicated account used only for privileged duties (ISM-0445). Your staff also own risk acceptance, exception approvals, and the decision to restore from backup during an incident. Ask any partner to map each recurring task to a named role inside your organization before work starts.

Can a managed service provider own the recurring reviews?

A managed service provider can run the mechanics of recurring reviews, but accountability for the outcome stays with you. Application control rulesets must be validated at least annually from ML2 (ISM-1582), and the Microsoft Office trusted publisher list at least annually at ML3 (ISM-1676). A provider can gather the data, prepare the review pack and track due dates. Your organization should still approve changes and keep a record of who signed off. Write the review calendar into the service agreement, name the internal owner for each review, and confirm how the provider escalates a missed deadline. Confirm these terms with the provider in writing, since the details vary by contract.

How do we stop the implementation partner from also acting as assessor?

Separate the roles in the contract and in your evidence trail. The partner builds controls and prepares evidence, while an independent assessor evaluates implementation and effectiveness against the maturity model. Only an independent assessor issues a judgment on maturity. Ask the partner to disclose any relationship with the assessor you intend to use, and avoid having the same people configure a control and then test it. Keep your own register of who implemented, who reviewed, and who approved each strategy. Clear separation also protects your position if an assessor later questions a control that the partner helped build.

What does the work need from our internal team?

The work needs named people with time, access and decision rights. Expect the engagement to need an executive sponsor, an infrastructure owner for endpoints and servers, an identity owner for MFA and privileged access, a backup owner who can test restores, and a security owner who handles incident reporting. The size of that commitment depends on the target maturity level, the number of systems in scope and how much of the environment is already managed. Ask the partner for a written list of the internal roles it expects, the hours each role must allocate, and the decisions only your staff can make. Vague staffing assumptions are a common cause of delays.

Can we do all of this ourselves without outside help?

Many organizations can do it themselves, provided they have skilled staff, enough time and a clear target level. The Essential Eight is public, and the ISM Essential Eight baseline profiles give ML1, ML2 and ML3 control lists in OSCAL, which makes a gap assessment possible in-house. The main risks are capacity and independence. Internal teams often underestimate the process controls, the logging needed from ML2 and the recurring reviews that persist after the first assessment. A useful test is whether you can name an owner, a schedule and an evidence location for every control. If you cannot, a fixed-scope engagement covering only the gaps may be a better fit than a full outsourcing arrangement.

Where to confirm the controls and review cycles

Before you split Essential Eight work between staff, a managed service provider and a consultant, confirm which controls apply to your target level. Start with the ASD Essential Eight maturity model, which defines Maturity Levels One to Three for each of the eight strategies. Then open the ISM OSCAL baseline profiles for ML1, ML2 and ML3 and list the controls each profile contains. In the ISM v2026.09.4 profiles, ML1 holds 46 controls, ML2 holds 87 and ML3 holds 123, and every ML1 control also appears at ML2. Treat that list as your ownership register: each control needs one named internal owner, even when a partner runs the technical work.

Use the profiles to find the recurring reviews that will otherwise drift. Application control rulesets must be validated at least annually from ML2 (ISM-1582), and the Microsoft Office trusted publisher list at least annually at ML3 (ISM-1676). Privileged access requests must be validated when first made (ISM-1507). Confirm, for each control, who signs off, where the record lives and which calendar reminder triggers the next review. Ask any partner to state in writing which of these tasks they perform and which remain yours. Incident reporting to the CISO and to ASD (ISM-0123, ISM-0140) is an example of a control that depends on your own governance, not a technical configuration.

Check the current release before you assign anything. The Essential Eight maturity model is dated November 2023, and the ISM profiles are versioned, so confirm that your register matches the version your assessor will use. ASD's *Assessment evidence guide for enterprise IT*, published in the E4EIT OSCAL collection, is the first chapter of its newer Essentials series and maps to the Essential Eight; review it with your assessor to confirm which evidence they expect. Record the versions you used in your register so later changes are traceable.

How DeployOpen divides Essential Eight work with your team

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For the Essential Eight, we help you decide which technical controls to run, which people and process controls stay with your staff, and which recurring reviews need a named owner. We prepare systems and evidence; the organization owns its controls and any assessment is performed by an independent assessor.

How we scope

Engagements are fixed-scope, with the list of controls, systems and deliverables agreed in writing before work starts.
The written scope names which controls DeployOpen implements and which your staff or a managed service provider keeps running.
We confirm which recurring tasks, such as annual ruleset validation, have a named internal owner before any build begins.

How we build

We configure the technical controls in your own cloud accounts, data centers or air-gapped networks, not in ours.
Each control is tested against the agreed scope, and the results are recorded alongside the configuration that produced them.
Process controls such as incident response steps and privileged access validation are drafted as documents your team reviews and approves.

How we hand over

You receive configuration, runbooks and evidence records organized by Essential Eight strategy and maturity level.
A handover session walks your staff through every recurring review, its cadence and the evidence it should produce.
Ownership of each control, including the responsibilities that stay with your organization, is written down before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the original engagement.
A retainer can cover recurring evidence collection, so your team is not rebuilding records before each assessment.
Questions about which work to keep in-house or to pass to a managed service provider can be revisited at each review point.

What to outsource for the Essential Eight and what to keep