How the Essentials is assessed.

At a glance

• You rate each action in each domain it applies to. Nothing is rated once for the whole organisation.

• There are four ratings: not assessed, not effective, partially effective and fully effective. There is no maturity level. If a regulator, contract or other obligation still requires Essential Eight work or reporting, ASD says to keep meeting it (see keeping the Essential Eight running).

• ASD's indicators of good practice describe each rating except not assessed. One true not effective indicator normally means a not effective rating.

• A principle takes the lowest rating of its actions in a domain. Each domain then gets a percentage score.

• Evidence must show the action working, not just switched on. Start with the evidence you already hold.

• Every report needs a summary view and a detailed view, set out by priority phase and domain.

ASD's process is for assessing your own environment, in any Essentials chapter. Our examples use the enterprise IT chapter and a fictional 300-person council.

The four stages of an assessment

The approach depends on your environment's scope, size and complexity, but ASD says the same four stages always apply.

Stage 1: Planning and preparation

First, agree which domains and assets are in scope. You can assess one domain, several or all of them, and you need not follow priority phase order. Write down anything you leave out, and why.

Then bring in the people involved, such as system owners, the security team and any managed service providers. Ask third parties early for access and evidence, as ASD warns this often takes time. The process is not for assessing your suppliers. ASD says guidance on that will come later.

Stage 2: Plan approval

An appropriate authority in the organisation approves the plan, including any testing or tools, before work starts, and again if it changes materially. Record anything that limits the assessment, such as access you could not get, so the report can include it.

Stages 3 and 4: assess, then report

The assessor rates each applicable action in each domain in scope, recording the evidence relied on and, below fully effective, the specific gaps. If the plan allows sampling, they note which assets they checked and why. Then they roll the ratings up and report, as the scoring and reporting sections explain.

Do you need an independent assessor?

No. ASD does not require an independent assessor, but says you may choose one where proportionate and affordable. It does recommend periodic independent assessment in your reassessment cycle, particularly where external assurance is required. ASD's process also does not replace any regulatory or compliance requirements, so check whether a regulator or contract asks for one.

The three layers behind each rating

ASD says assessors "do not assess controls in isolation." Each rating joins three layers: the principle is the outcome, the action is what you do, and the domain sets which assets get checked. Our overview explains how principles, actions and domains fit together.

Rating an action

Each action gets one of four ratings in each domain it applies to. The action rating asks whether the outcome is achieved across the assets in scope, not whether a specific control is in place.

Indicators of good practice

For every action, ASD's Assessment evidence guide for enterprise IT describes what each rating except not assessed looks like. These short statements are the indicators of good practice, or IGPs. There are 529 across 58 actions, each listed on our enterprise IT page.

ASD calls the indicators optional, and says:

If the assessor uses the indicators, ASD's rule turns them into a rating in three checks, in order.

ASD does not say when a statement is not applicable. Our suggestion: set one aside only when the situation it describes does not arise in the domain, and record why. For example, FE-3 in the worked example below applies only where something prevents timely patching.

Worked example: rating one action

ASD's own example is patching in Identity services. An attacker who takes over a domain controller, federation service or certificate authority can gain broad access. The assessor checks patching for these assets, not across the whole organisation, using ASD's indicators for IT.PRO-06.2 under PRO-06 Vulnerability management.

Where expert judgement comes in

The indicators cannot foresee every setup, so the assessor stays responsible for the rating. ASD says to assess the outcome achieved: a setup that differs from the indicators is still fully effective if the evidence shows it achieves the outcome.

A single not effective statement is normally decisive, with one exception:

A compensating arrangement is a different measure that still delivers the outcome. For example, a system that cannot be patched might be cut off so attackers cannot reach it. When departing from the indicators, ASD says to record the outcome achieved, the evidence relied on and any compensating arrangements.

Assessing a domain

Each domain is assessed on its own, against its own assets and risks, so the same action can earn a different rating in each domain. A good result in one domain does not carry across to another.

Scope the domain first

Where possible, the assessor starts from the scope you set when implementing and checks it is accurate, complete and current. An incomplete scope can give misleading results, so big gaps are recorded as findings. An asset that supports more than one domain is included in each and assessed separately in each. Our scoping guide covers recording your scope and assets in more than one domain.

Four things to check for each action

For each action that applies in the domain, ASD asks the assessor to check four things, which it calls the assessment dimensions.

Gaps in coverage or consistency may stop an action reaching fully effective. For a partially effective rating, the assessor writes the gaps down so fixes can be planned.

When is a domain addressed?

From action ratings to a domain score

Ratings roll up in two steps: action ratings become principle ratings, then principle ratings become a percentage for the domain, which we call the domain score. ASD's example summary table labels the same figure "% effective".

Step 1: the weakest link sets the principle rating

Within a domain, a principle takes the lowest rating of its applicable actions. ASD calls this the weakest link rule, because one material gap can limit the whole principle.

Step 2: score the principles

Each principle rating gets a score: 0 for not effective, 0.5 for partially effective and 1 for fully effective. Add up the scores, then divide by the number of applicable principles in the domain.

Keep not assessed separate

Use not assessed when the evidence is too thin to tell whether the outcome is achieved, and record why. Use not effective when the evidence shows the outcome is not achieved. Not assessed has no score, and ASD says it "must remain distinguishable from not effective in all reporting."

A principle can be partially or fully effective only once all its applicable actions in the domain are assessed. One not effective action makes it not effective straight away. Otherwise, while any of its actions is still not assessed, so is the principle. A domain you have not assessed yet is recorded as not assessed across all its applicable principles, which ASD says reflects "sequencing rather than failure".

ASD's formula divides by all applicable principles, and ASD does not say how to treat principles not yet assessed in a part-assessed domain. Our suggestion: divide by the principles you did assess, say so in the report, and show the not assessed count beside it.

Evidence

Start with the evidence you already hold

You can map controls you already run, from any framework, to the actions. ASD says the mapping is a starting point, not proof the outcome is achieved. For each action, ASD's Assessment evidence guide lists where evidence may already exist in frameworks you have adopted. The list shows where to look, not which controls you need.

ASD says to start with relevant evidence you already hold, such as configuration baselines, assessment reports, audit findings, control test results and risk registers, before creating new evidence. If it still reflects your environment and covers the domain reliably, nothing more is needed.

ASD adds three cautions about existing evidence:

ASD also expects an evidence register for each domain, which becomes your working paper for self-assessment. Implementing the Essentials shows a sample. Moving from the Essential Eight? See reusing your Essential Eight evidence.

What makes evidence good

ASD asks assessors to seek the best quality evidence that is reasonably practicable, and describes four broad levels. Our examples use IT.PRO-13.4, which asks for phishing-resistant multi-factor authentication (MFA). That is a second sign-in factor a fake login page cannot capture and reuse.

ASD says these levels are a guide, not a rule. One strong piece may not cover a whole domain, while several good pieces can give a stronger picture. Weaker evidence may still contribute to the assessment, with its limits weighed in the rating.

Tools and testing

Tools can gather information, find gaps and confirm that an action works. ASD recommends no specific tools. Use approved tools that fit the plan, and consider built-in features before adding products.

Record each tool's version, configuration, permissions, licensing constraints and known limitations. Check its output critically for incomplete or stale data, misconfiguration, restricted access, false alarms and missed problems. A tool that directly tests the outcome can give strong evidence. One that only reports settings and status gives supporting evidence.

Simulations and active testing

If evidence shows a control was switched on but not that it keeps working, ASD says testing can add evidence. Active testing in the live environment, such as trying to run unapproved software, can give strong evidence but can also carry operational risk. ASD says it should be in the approved plan, with its target systems and limits, and run by people skilled enough to manage the risk.

ASD also maps most actions to attacker techniques, which it calls the ATT&CK mapping. It can guide what to test and what to fix first, but it never changes a rating. Our implementing guide covers using it to set priorities.

Reporting the results

Results are reported by priority phase and domain, showing how many principles sit at each rating. ASD says every assessment report must include two views:

Both views should be available to every reader, because ASD warns the summary alone may hide outstanding risk. Charts follow the same rule: ASD suggests a radar chart for boards, but says a chart must never be used on its own. Our guide for boards and executives covers reporting to the board.

What a summary view looks like

ASD's own example is an organisation working towards priority phase 2. Its phase 3 domains are not assessed yet.

What a detailed view adds

The detailed view shows what drives a domain's result. Here is part of the council's view for Identity services, as our illustration, not ASD data.