Implementing the Essentials.

At a glance

Four terms you will meet throughout. A principle is an outcome to achieve. An action is what you do to achieve it. A domain is a group of business functions and systems with similar risks. A priority phase is ASD's recommended order for tackling the domains.

• Start at the top. Get the board or executive committee to own cyber security first. An assessor can check that commitment.

• Work in phases. Plan priority phase 1 in detail, and keep later phases as forward plans.

• Scope, then find the gaps. List the systems in the domains you start with, then check the actions that apply there.

• Build once, reuse everywhere. Design shared capabilities, such as multi-factor authentication (MFA), as patterns you roll out domain by domain.

• Collect evidence as you go. Ratings need evidence that controls keep working, so build monitoring and records in from day one.

The journey in seven stages

ASD's guide sets out a sample program in seven stages. Each stage produces documents, and together they form your implementation roadmap.

Get leadership on board

Executive commitment comes first, and an assessor can check it in the Governance and culture domain. Our guide for boards and executives explains what leaders are accountable for.

Leaders who funded Essential Eight work may ask why more money is needed. In short, capable attackers now threaten more kinds of organisation, past investment carries forward, and the early phases are built to show progress early. The same guide sets out ASD's full case.

Build the business case in tranches

ASD suggests asking for the money in project tranches, one funding stage per priority phase, so every item traces to something leaders later see reported. Tranche 1 covers the priority phase 1 domains. It also sets up the two capability domains: Governance and culture (policies, roles and training) and Visibility and response (spotting and handling incidents). Tranche 2 covers Critical processes and services and Privileged environments, and extends the capability domains. Tranche 3 covers Business systems and User devices, and brings the capability domains to full coverage.

Cost each tranche in three parts:

• Capability build: tools, licences and engineering.
• Operating uplift: the ongoing cost of people and processes.
• Assessment: your own assessment effort, plus periodic independent assessment (ASD says an independent assessor is not required).

ASD says a credible strategy sets the scope, costs and delivery approach for phase 1, and treats later phases as forward plans to refine as you learn. Our suggestion: ask for tranche 1 in full, and show tranches 2 and 3 as forward estimates. If you cannot fund them all, ASD says to make any deferral a documented, risk-based decision, and advises against skipping domains or deferring phases indefinitely.

Agree what you will report

Agree with leaders at the start what you will report, how often and to whom. ASD says this avoids later disputes about progress. Our leaders guide shows the reporting ASD recommends. Keep "not assessed" (not checked yet, or not enough evidence to judge) apart from "not effective" (checked, and not delivering the outcome).

Scope your assets

Scoping turns each broad domain into a list of named systems to harden and assess. Start by writing down your operating context, such as your obligations, risk appetite and budget. Then record the decisions for each domain in a scope statement: what is in, what is out and why. The scope statement also sets what full coverage means for every rating that follows.

• Place assets by role, not owner. Ask what a system does, not who runs it.

• Scope priority phase 1 first. Scope its domains and both capability domains now, and later domains when you reach them.

• Treat blind spots as findings. Record gaps in what you can see. Visibility and response actions fix them later, so they need not stop you starting.

Our Scoping assets into domains guide has the full method, including how to place each asset and a scoping workshop.

Run a gap analysis

A gap analysis checks whether your current controls already do what each action asks. It does not give formal effectiveness ratings. Those come later, when the evidence can be assessed. You sort each action into one of three groups.

• Addressed

  Existing controls already do it. Record them and their evidence for assessment later.

• Partially addressed

  Controls do some of it, or have gaps in scope, consistency or enforcement. Describe the gaps well enough to plan the fix.

• Not addressed

  Nothing meets the intent of the action. Record the new work to plan and fund.

Method and inputs

• Go one domain at a time. List the principles that apply, then check each of their actions against your controls.
• Start from what you have: past assessment reports, system, configuration and logging designs, exception registers and fix plans.
• Check old evidence before you rely on it. A review that is no longer current, an exception that expired without being approved again, or a baseline that no longer matches your systems is itself a finding.
• Record each finding against the domain, not just the action. The same action can be done well in one domain and be missing in another, and that shapes what you fix first.

Moving from the Essential Eight? ASD does not recommend slowing or stopping approved uplift work. Keep it going, and check how it lines up with the Essentials as you plan. Our transition guide shows where ASD says it already counts, and where it may need strengthening.

Worked example: one action, two domains

The council checks action IT.PRO-13.4. MFA means signing in with something more than a password. Phishing-resistant MFA, such as a security key, stops a fake login page from stealing the sign-in. The action reads:

The portal gap goes into the phase 1 plan. The identity evidence goes into the evidence register, ready for assessment.

Plan the work phase by phase

With scope and gaps known, the plan sets what to fund, in what order and how to deliver it.

Follow the phases in order

ASD recommends dealing with an earlier phase's domains before the next phase's, because each phase builds on the one before. If threat intelligence or a regulatory driver gives you reason to change the order, ASD says to make it a documented, risk-based decision. Our chapter guide explains why ASD chose this order.

Pick a delivery approach

ASD describes two ways to organise delivery. Domain-focused is its recommended default if you are early in your journey, or unsure how to weigh the trade-offs. Established programs can choose either or mix both, and different controls in the same program may suit different approaches.

Design once, roll out by phase

Many capabilities serve several domains. One MFA design, for example, can protect your remote access portal, directory and admin accounts. ASD's advice is to design each capability once as a reusable pattern, then roll it out domain by domain in phase order. When threats change, you update one pattern.

We matched each capability ASD names to the closest action or principle on our enterprise IT page. Each square is a domain, in roadmap order, with the two capability domains last. A filled square means the capability applies there. Every one starts in phase 1, so a pattern built there carries into later phases.

A useful pattern records four things:

Intent

The principles and actions it supports, and the attacker techniques it is meant to counter.

Applicability

The domains it applies to, in phase order, with any tailoring, such as stricter baselines or faster patching where a failure would do more harm.

Solution

A product-neutral design, the approved baseline, and its links to logging and governance.

Evidence model

How it shows coverage, consistency and currency, and where its evidence is kept.

Set priorities inside a phase

ASD's ATT&CK mapping links 38 of the 58 enterprise IT actions to the attacker techniques they help counter, and our enterprise IT page lists them. If your team uses threat intelligence (reports on how attackers operate), the mapping can order work inside a phase. ASD does not expect less mature organisations to do this. They can prioritise by their own context, risks and resources.

Deliver and measure

Now you build the fixes and rate the result. Each action gets an action rating in each domain where it applies, on ASD's four-level scale.

Our assessment guide explains how the ratings are given and how they roll up into a score for each domain.

Design controls that prove themselves

Assessors check four things, which ASD calls assessment dimensions. Design for them from day one and the evidence comes from normal work.

Use the indicators of good practice

For each action, ASD gives indicators of good practice: short statements of what a not effective, partially effective or fully effective rating looks like. Self-assess against them, and keep that rating in its own column, apart from the gap analysis status. A single not effective indicator is normally enough to rate the action not effective. ASD says an assessor may still rate higher where a compensating arrangement demonstrably achieves the action's outcome, and the reasons and evidence are documented. Our enterprise IT page lists the indicators under every action.

Build the evidence register as you go

Start an evidence register for each domain during the gap analysis, even for actions that need no work. Record each action's control, assets covered, evidence sources and self-assessed rating. It becomes your working paper, and saves any assessor hunting for documents.

Our suggested layout, with the council's two entries and the rating it gave after checking the indicators:

Look at the second row. Most sign-ins use phishing-resistant MFA, so the gap analysis said partially addressed. But a password-only sign-in from outside matches one of ASD's not effective indicators, and nothing compensates for it. So the rating stays not effective until the portal is fixed.

Show it works over time

A control that is switched on is not enough to earn or keep an effective rating. You also need operational evidence: proof it works in daily use. Plan testing that produces it, scaled to each action's importance and your resources. Advanced methods such as penetration testing may not be needed for every action. Our assessment guide covers what makes evidence strong, and the tools and methods for testing.

If a provider runs it

Outsourcing a service does not hand over accountability for its security. You still need current evidence that the provider does its part. If it falls short, or you lack that evidence, the risk stays with you. Our chapter guide explains how to handle outsourced services.

Keep it running

ASD treats keeping controls working (sustainment) as part of the program you plan and fund, not an afterthought.

After each phase, go round the loop for the next one: scope, gap analysis, plan, then deliver and measure. Extend the capability domains and reuse your patterns as you go.

Set a reassessment rhythm

Reassess your domains on a regular, risk-based schedule, and sooner after a major change or a relevant incident. If an action rated effective has slipped, record the gap and fix it through the same gap analysis and delivery process. ASD says to include periodic independent assessment, particularly where regulators or the board need outside assurance. It also says you may bring in an independent assessor where that is proportionate and affordable, but you do not have to.

Manage exceptions as a life cycle

An exception is an approved, time-limited decision not to apply a control in full. It is often backed by a compensating control, another control that gets the same security result. Exceptions, compensating controls and accepted risks are common reasons security slips, so keep an exception register from day one. ASD says to record at least a named owner, approval details, review requirements and an expiry date.

Warning signs at a review: an exception that expired without review, a compensating control that stopped working, or an accepted risk not checked against current threats. Each is a chance to close the gap or formally approve the risk again.

Fund the running costs

The Cyber security resourcing principle requires periodic resourcing reviews as threats, incident outcomes and priorities change. Name running costs in the business case from the start, so controls do not decay for lack of funds. Reassessment will find any control that is not kept up. ASD says to plan these costs by pattern, not by domain. Estimate each pattern's first and ongoing cost, including:

• Licences and subscriptions
• Integration
• Data ingestion and retention
• Workforce
• Training
• Baseline reviews
• Drift remediation
• Detection tuning
• Validation activities
• Evidence maintenance

Then share it across the pattern's domains. For example, cost central logging once and spread it over every domain that sends it logs. Over time, build costs fall as patterns are reused, running costs rise and assessment costs stay broadly steady. Plan governance upkeep, such as reviewing accountabilities after organisational change, the same way.

ASD's planning checklist in plain English

Before you finalise your strategy, ASD's checklist says to confirm these points. Your ticks are not saved.

• Leaders' cyber security accountabilities are formally defined. Reporting and risk appetite (how much risk you will accept) are agreed, so an assessor can check them under Governance and culture.
• Your operating context was recorded before any scoping decisions.
• Every domain in this cycle has a versioned scope statement, listing exclusions with reasons and assets in more than one domain.
• Every fix has an owner, a delivery approach and its domains in priority phase order.
• Priorities within the current phase are informed by threats, using ASD's ATT&CK mapping (less mature organisations can use their context, risks and resources instead).
• Any change to ASD's domain order is a documented, risk-based decision.
• Every control has a risk-based review schedule and an approval record.
• Every control has monitoring that spots drift or missed assets, and an entry in the evidence register.
• Tests that prove controls work are scheduled for each priority phase, aimed at the techniques the actions are meant to counter.
• Capabilities used in several domains are written up as patterns. Each says what it is for, where it applies, how it is built and how it proves it works.

Every action, with its domains and indicators, is on our ASD Essentials for enterprise IT page. Filter it by domain to see your phase 1 work.