An Essential Eight assessment is not an audit in the ISO sense and there is no certificate at the end of it. It produces a maturity rating for each of the eight strategies, supported by technical evidence, and its value depends almost entirely on how honestly it was done.
An overstated rating is worse than a low one, because it fails in front of a customer rather than in front of your own team.
What an Assessment Produces
An assessment produces eight ratings, not one. Each strategy is placed at maturity level zero, one, two or three, with evidence behind the placement. Because ASD's guidance is to implement all eight to the same level before advancing any of them, the set is usually summarised by its weakest strategy — which is also how a buyer will read it.
ASD publishes an assessment process guide describing how to carry this out rigorously, including the principle that assessments should test what is actually configured rather than what policy says should be configured. That distinction is the whole exercise.
Scope the Fleet Before Rating Anything
You cannot rate what you have not enumerated, and coverage is where most assessments quietly fail.
Start from an asset inventory and decide explicitly what is in scope: workstations, servers, network devices, cloud workloads, and the awkward categories — contractor machines, systems inherited through acquisition, build agents, and anything running outside the standard operating environment.
Then rate against that denominator. "Application control is enforced" means something different when the denominator is the managed fleet than when it is every machine that touches corporate data. An assessment that silently excludes the unmanaged remainder produces a number nobody can rely on, and it is the first thing a careful buyer probes.
Evidence Each Strategy Needs
Work from configuration, not from assertion. For each strategy the useful evidence is roughly:
- Application control — enforcement state (not audit mode), the ruleset and rule types, coverage against the inventory, and the exception register.
- Patch applications — patch compliance reporting against defined timeframes, the accelerated path for vulnerabilities with a working exploit, and the unsupported-software register.
- Macro settings — the configured policy, who is exempt and why, and evidence that macro execution is logged.
- User application hardening — browser, office suite and PDF reader baselines, plus drift detection showing they hold.
- Restrict administrative privileges — the privileged account inventory, review records with removals actually executed, and evidence that privileged accounts are separated from email and browsing.
- Patch operating systems — the same as applications, extended to servers and network devices, with end-of-life systems identified.
- Multi-factor authentication — where it is enforced rather than available, which factors, and coverage of remote access, privileged actions and relevant third-party services.
- Regular backups — what is backed up including software and configuration, retention, a recorded restoration test, and the access model preventing a compromised account from destroying them.
Two words recur: enforced, and coverage. Those are the questions an assessment is really asking.
Want the evidence pack assembled before the next tender?
Share your work email and we'll walk each strategy against the evidence an assessor expects and mark where your current configuration supports the level you want to state.
Self-Assessment or Independent Assessor
Both are used. A self-assessment is legitimate, cheaper, and appropriate for internal improvement or where a buyer has not specified otherwise. An independent assessment carries more weight where a procurement requirement expects an external view, and it tends to find the coverage gaps an internal team has stopped noticing.
The failure mode for self-assessment is not dishonesty. It is that the team that owns a control rates its own control, and familiarity makes gaps invisible — the exception that has been open for two years reads as normal. If you self-assess, have someone outside the owning team test a sample of the evidence rather than review the questionnaire.
The Four Ways Ratings Get Overstated
- Audit mode counted as enforcement. Overwhelmingly the most common. A control deployed to observe is not mitigating anything, and this single mistake accounts for most inflated application control ratings.
- Coverage measured against the easy denominator. Rating the managed fleet and omitting contractors, acquisitions and non-standard builds.
- Policy mistaken for configuration. A documented standard that was never enforced technically, and has drifted on the endpoints.
- Backups never restored. Successful job logs are not evidence of recoverability, and restoration is what the strategy asks for.
Every one of these is findable in an afternoon if you look for it deliberately. All four survive indefinitely if the assessment is a form filled in from memory.
Reporting a Level to a Buyer
State the level per strategy and the date of assessment. Do not report a single headline number without saying it is the minimum across the eight, because that is how it will be interpreted anyway and it is better to be explicit.
Say what the denominator was. "Maturity level two across all eight, assessed September 2026, covering all corporately managed endpoints and servers; contractor-owned devices are excluded and have no access to production" is a far stronger answer than "level two", because it survives the follow-up question.
If a strategy is below target, say so with the remediation date. Buyers deal with gaps routinely; they deal badly with gaps they discover themselves.
Essential Eight Assessment Questions Teams Ask
A focused assessment against a defined scope is typically one to two weeks of effort, most of which is evidence collection rather than judgement. The variable is inventory quality: organisations with a current asset inventory and centralised configuration reporting move quickly, while those reconstructing what exists spend most of the time there. That reconstruction is worth doing regardless, since coverage is the question the rating depends on.
Only if a buyer or contract requires one. Self-assessment is legitimate and ASD publishes guidance on performing it. The practical caution is that teams rating their own controls stop seeing long-standing gaps, so even an internal assessment benefits from someone outside the owning team sampling the evidence rather than reviewing the questionnaire.
Record it and plan the uplift. Level zero signifies weaknesses that could be exploited to compromise confidentiality, integrity or availability — it is a finding, not a disqualification, and it is extremely common on application control specifically. Buyers respond far better to a zero with a dated remediation plan than to a claimed level that does not hold up when they ask what enforcement state the control is in.
At least annually, and before any procurement that will ask for a level. Maturity decays between assessments: fleets drift from baselines, exceptions accumulate without expiry, software reaches end of life, and acquisitions bring unmanaged systems into scope. A rating produced more than a year ago describes a configuration that has since changed, and stating it as current is a claim you may not be able to support.
Keep the rating current between assessments
Book a demo and we'll show how Konfirmity tracks coverage, enforcement state and exceptions per strategy so an assessment is a report rather than a project.
Book a demo
Rate It Before Someone Else Does
The worst time to discover that application control is in audit mode, or that the backup has never been restored, is during a tender response or an incident. An honest internal rating costs a fortnight and turns both of those into known work with dates attached.
Start with scope, rate against evidence rather than policy, and move all eight together toward the level your buyers actually ask for. The maturity model defines the destination and application control will set the pace.
