Essential Eight maturity is not a security score

A maturity number becomes dangerous when it travels further than its explanation. A technical assessment says one thing about a defined environment. A slide compresses that into a single digit. By the time it reaches a customer or director, the digit can sound like a guarantee about the whole organisation.

Essential Eight maturity is useful. Treating it as a universal security score is not. A CIO should be able to explain what the assessment covers, what evidence supports it and what remains outside the model without making the audience read the assessment report.

Understand what the model is describing

ASD designed the Essential Eight to protect internet-connected information technology networks. Its guidance says that enterprise mobility and operational technology can require other mitigation strategies. That scope matters to an Australian organisation with a mixture of office systems, field devices and specialised operational equipment.

The maturity levels describe controls intended to address increasing levels of adversary tradecraft and targeting. They do not provide a probability of compromise, a forecast loss or a measure of how valuable the organisation's information is. Two businesses at the same assessed maturity can have different services, exposures and consequences if something goes wrong.

The model also says additional measures may be needed. Reaching a selected level does not settle questions about supplier concentration, privacy handling, incident communications or whether a business process can function during an outage. Those questions remain management's work.

Avoid averaging away the weak controls

ASD recommends planning to reach the same maturity across all eight strategies before moving to higher levels. The strategies are intended to complement one another. That is different from collecting enough strong results to offset a weak one.

Imagine a hypothetical professional services firm with well-managed operating system patches but substantial gaps in restricting administrator privileges. An average across its control ratings might look respectable. The average would hide the gap the leadership team needs to understand.

Report the control position without manufacturing an overall arithmetic score. Show the assessed scope, the target, the evidence date and the unresolved requirements. Where an assessor has reached a formal conclusion, preserve their language rather than substituting a more flattering summary.

This does not mean every improvement must wait for the weakest area. Urgent exposure still needs attention. It means the programme should not use isolated achievements to imply that the complementary set of controls is complete.

Make exclusions understandable to a non-specialist

An assessment of managed employee devices is not automatically an assessment of contractors, acquired businesses or applications bought directly by a department. State those boundaries in ordinary language.

A useful summary might say that the assessment covers the corporate Windows fleet and named cloud services, while a recently acquired business remains outside scope. Then explain how that business connects to the assessed environment. An exclusion on paper does not create a technical separation.

Exceptions need similar care. ASD allows an appropriate, documented approach to exceptions, including compensating controls and ongoing review; an exception does not automatically prevent a maturity assessment. Equally, labelling a gap an exception does not make it harmless or acceptable under every assessment methodology.

Ask who approved the exception, what limits its exposure and whether those limits have been checked. The operating detail belongs in an exception register, with a readable summary for leadership. Handling security exceptions with an expiry date describes how to prevent that register becoming a permanent permission slip.

Choose a target for a reason

A supplier may recommend a target, but management needs to understand its basis. Consider the organisation's environment, the consequences of losing confidentiality or availability, its threat context and applicable obligations. Document the decision and revisit it when the organisation changes.

There is no universal statement in the model that every business must achieve the same level. ASD also says there is no general requirement to obtain independent certification of an Essential Eight implementation, while acknowledging that independent assessment may be required by a directive, regulator or contract. Check the obligations that actually apply with the relevant advisers.

Be careful with the word certified in procurement material. Ask what was assessed, by whom, against which version and with what limitations. A logo or a sales description is not a substitute for the assessment's scope and conclusion. Do not pass that ambiguity into your own customer assurances.

Put the number beside the decisions

For a board report, I would give the maturity position a compact section and place it beside the service risks that still need decisions. One issue might be funding for an unsupported application. Another might be an untested recovery dependency. Both deserve attention even if neither changes the headline maturity statement immediately.

A useful report distinguishes implementation, assessment and ongoing operation. A control configured during a project still needs ownership after the project closes. Evidence also ages as staff, systems and settings change. State when the assessment occurred and what material changes followed it.

The goal is an honest description that survives questions. A director should leave knowing where the organisation is aiming, what has been demonstrated and what management is asking them to approve. A security dashboard that shows the uncomfortable gaps can carry those distinctions into routine reporting without pretending one digit describes the whole risk.