All insights
Essential Eight May 28, 2026 7 min read

Common Essential Eight Mistakes That Fail an Assessment

The Essential Eight looks deceptively simple: eight mitigation strategies, four maturity levels, one straightforward goal. In practice, the gap between thinking you are compliant and passing an assessment is wide. After running assessments across Australian councils, agencies and enterprises, the same failure patterns appear again and again, and almost none of them are about missing technology.

This article covers the mistakes that most often cap an Essential Eight maturity score, and what to do about each one before an assessor arrives. If you are new to the framework, start with our Essential Eight explained guide for the foundations.

Mistake 1: Misunderstanding how maturity is scored

The single most common misconception is that maturity is an average. It is not. The ACSC Essential Eight Maturity Model assesses each of the eight strategies against the requirements of a given maturity level, and you only achieve that level when every strategy meets it. One weak strategy caps your whole result.

So an organisation with seven strategies at Level Two and one at Level One is, overall, at Maturity Level One. Boards are often surprised by this. They have invested heavily in application control and patching but neglected, say, user application hardening, and the laggard defines the score. Before an assessment, identify your weakest strategy honestly, because that is where your real maturity sits.

Mistake 2: Patching only part of the estate

Patch applications and patch operating systems are two of the eight strategies, and both fail constantly because coverage is incomplete. Servers get patched on a disciplined cycle; workstations, kiosks, VDI images, and that one legacy box running a critical line-of-business application do not.

The maturity model sets timeframes: at higher levels, critical vulnerabilities in internet-facing services must be patched within 48 hours, and other applications and operating systems within two weeks (or one month at lower levels). Assessors check dated evidence against those windows across the whole fleet. Common gaps include:

  • Internet-facing services not being treated as the highest priority for patching.
  • No vulnerability scanner running at the required frequency to detect missing patches.
  • Unsupported or end-of-life software still in production, which is an automatic fail at higher levels.
  • Drivers, firmware and third-party browser plugins being forgotten entirely.

Mistake 3: Application control that is not actually controlling

Application control is the hardest strategy to implement well and the easiest to fake. Organisations frequently deploy a solution in audit or monitor mode, see the logs, and call it done. Monitoring is not enforcing. At Maturity Level Two and above, execution of unapproved executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets must be prevented, not merely logged.

Assessors will attempt to run an unauthorised executable from a user-writable location. If it runs, the control fails regardless of how comprehensive your ruleset looks on paper. Make sure your rules are enforced, cover user profiles and temp directories, and are validated annually as the model requires.

Mistake 4: Treating MFA and admin restriction as box-ticks

Multi-factor authentication and restrict administrative privileges are where scope creep hides. For MFA, organisations enable it for remote email access but not for all internet-facing services, or they allow phishable methods at maturity levels that demand phishing-resistant MFA. The model has tightened here, and SMS-based codes will not carry you to the higher levels.

For administrative privileges, the failures are predictable: privileged accounts used for email and web browsing, service accounts with standing domain admin rights, no separation between privileged and unprivileged operating environments, and access that is never reviewed. Privileged access should be requested, validated, time-limited and logged. Standing access that nobody can justify is a finding every time.

Mistake 5: Backups that have never been restored

Regular backups is the strategy organisations are most confident about and least able to prove. The maturity model does not just ask whether backups run; it asks whether they are tested through restoration, whether they are retained for the required period, and critically whether unprivileged accounts and even most privileged accounts are prevented from modifying or deleting them. Ransomware actors target backups first.

If you have never performed a documented restoration test, you cannot demonstrate recoverability, and the strategy fails. Schedule and document restoration tests, and lock down who can alter backup repositories.

Mistake 6: No evidence, or the wrong evidence

This is where otherwise mature organisations lose marks. A control can be perfectly implemented and still fail the assessment if you cannot prove it. Policy documents describe intent; assessors need artefacts that show the control is operating in production. That means configuration exports, group policy reports, patch management dashboards with dates, application control rulesets, MFA enforcement settings, and backup restoration logs.

Start collecting evidence months before the assessment, not the week of. Map each maturity requirement to a specific artefact and a system owner who can produce it on request. This single discipline shortens assessments dramatically and prevents the scramble that makes environments look less mature than they are.

Mistake 7: Microsoft Office macro settings left at the defaults

Configure Microsoft Office macro settings is frequently overlooked because macros feel like a solved problem. They are not. The model requires macros to be disabled for users with no business requirement, macros from the internet to be blocked, and at higher levels, only macros from trusted locations or those that are digitally signed to be allowed, with macro execution events logged and monitored. Default Office installs do not meet this, and assessors check the actual policy state.

Mistake 8: User application hardening that stops at the browser

The eighth strategy, user application hardening, is broader than disabling Flash (long gone) or Java in browsers. It extends to blocking web advertisements, disabling unneeded browser features, hardening PDF readers and Office applications, and logging the relevant events. Organisations harden the browser and forget the rest, capping their score.

Mistake 9: Confusing the maturity level with a partial implementation

A subtle but important error is claiming a maturity level when only some of that level’s requirements are met. The maturity levels are cumulative and defined by the full set of requirements at each level. You do not earn Maturity Level Two by implementing the easy half of Level Two across all eight strategies; you earn it by meeting every Level Two requirement for every strategy. Partial implementation of a higher level does not count as that level. Be precise about which requirements are fully satisfied before claiming the level, because assessors test against the complete definition.

Mistake 10: Treating the Essential Eight as a one-time project

The most strategic mistake is treating maturity as something you achieve once and bank. Environments drift: new applications appear, patch cycles slip, admin accounts proliferate, and a level you reached last year quietly erodes. The Essential Eight is an operational discipline, not a project with an end date. Organisations that sustain maturity have named owners for each strategy, regular internal checks against the model, and the controls wired into business-as-usual rather than bolted on for an assessment. If you are reporting maturity to a board or funder annually, build the evidence collection into monthly operations so the next assessment is a confirmation rather than a scramble.

How to pass: prepare the way an assessor thinks

Passing an Essential Eight assessment is less about a last-minute project and more about operating the controls consistently and being able to prove it. Practical steps:

  1. Assess each strategy independently and find your weakest link first.
  2. Verify coverage across the entire estate, including workstations, servers, and legacy systems.
  3. Move application control and macro settings from monitoring to enforcement.
  4. Test backup restoration and document it.
  5. Build an evidence pack mapped to every maturity requirement before the assessment begins.

If you are uplifting maturity for a government grant, board mandate or regulatory expectation, an independent perspective helps you avoid optimistic self-scoring. CISO Advisory runs Essential Eight assessments and uplift programmes for government and council and private sector organisations Australia-wide, and our Virtual CISO service can own the ongoing maturity programme. To talk through where your gaps are, call 07 2112 8502 or get in touch.

Frequently asked questions

Why do most Essential Eight assessments fail?

Most failures come from partial coverage rather than absent controls. An organisation patches servers but not workstations, restricts admins but not service accounts, or cannot produce evidence. The maturity model is assessed as a whole, so one weak mitigation strategy caps the entire score.

Can you be at different maturity levels for each strategy?

Yes. The ACSC assesses each of the eight mitigation strategies independently, then your overall maturity is reported per level. You are only at Maturity Level Two when every strategy meets Level Two requirements, so a single laggard strategy holds back the whole result.

How long does an Essential Eight assessment take?

A typical assessment of a mid-sized organisation takes one to three weeks, depending on scope and evidence readiness. Poorly prepared environments take longer because assessors must chase artefacts, retest controls, and interview staff to confirm what is actually deployed versus documented.

What evidence do Essential Eight assessors want?

Assessors want technical proof: configuration exports, group policy settings, patch reports with dates, application control rulesets, backup restoration logs, and MFA enforcement records. Screenshots and policy documents alone are insufficient; assessors verify the control is operating, not just intended.

Is self-assessment good enough for the Essential Eight?

Self-assessment is a reasonable starting point but tends to be optimistic. Independent assessment, aligned to the ACSC Essential Eight Maturity Model, gives a defensible result for boards, regulators and grant conditions. Many government and funding requirements now expect independent verification.

Talk to a Virtual CISO

Need this handled for your organisation?

Confidential and no obligation. We respond the same business day — on-site same day / next business day, or remote, Australia-wide. Prefer to talk now? Call us 24/7 on 07 2112 8502.

Confidential. We typically respond same business day — or call us 24/7.

Frameworks & standards we assess and advise against

Independent, vendor-neutral expertise across the Australian and international frameworks government, regulators and boards rely on.

E8
Essential Eight
ISO
ISO/IEC 27001
NIST
NIST CSF 2.0
CPS
APRA CPS 234 / 230
ISM
ACSC ISM
PSPF
PSPF
IRAP
IRAP readiness
SOC2
SOC 2
PCI
PCI DSS
NDB
Privacy Act / NDB
SOCI
SOCI Act