A Client Says You Must Be Essential 8 Aligned by Quarter End and You Have Nobody In-House

A quarter is about thirteen weeks. That is enough time to move a long way towards Essential 8 alignment, and almost never enough to finish it. The honest split runs like this. Controls you can enforce centrally change in days. Controls that change how people work need a run-up. Two of the eight can oblige you to replace software or an operating system the vendor no longer supports, and that is procurement, not configuration.

If you are reading this with the client's email still open, you are not behind. You have been handed someone else's framework with someone else's date on it, and nobody internally whose job this is. inSUPPORT works with Australian businesses of roughly 30 to 300 users and has run more than 1,500 cyber audits. What follows is the sequence that fits a quarter, and the parts that do not.

The framework was never built to be finished on a date. The Australian Signals Directorate (ASD) asks organisations to identify a target maturity level suitable for their environment, then progressively implement each level until that target is achieved. Progressively is the word to notice. Some requirements are not states at all. They are intervals, like patching an internet-facing service inside 48 hours.

So treat the quarter as scoping, sequencing and evidence, with a dated plan at the end. Below is the order that works. It finishes with the conversation you owe the client, including the version where you tell them the date is wrong.

TL;DR: What to remember

• ✅ Get the requirement in writing first. Essential 8 aligned has no fixed meaning, and the maturity level, the systems in scope and who has to do the assessing are three separate questions.
• ✅ ASD asks for the same maturity level across all eight strategies before moving higher, and one ineffective control means that level cannot be claimed. There is no partial credit to lean on at a deadline.
• ✅ Macro settings, browser hardening and multi-factor enforcement move fastest. Application control, privileged account separation and replacing unsupported systems need a runway, so start them first even though they finish last.
• ✅ A documented exception with real compensating controls should not stop you reaching a target level, on ASD's own worked example. A dated decommission plan beats a silent gap.
• ✅ ASD launched the ASD Essentials on 15 October 2026 and is maintaining both frameworks through the transition. Worth one question to the client about which one they actually mean.

Contents

• Step 1: Get the requirement in writing before you get a quote
• Step 2: Decide what aligned will mean on the date
• Step 3: Do the controls that are settings, in week one
• Step 4: Start the three that need a runway, knowing they finish last
• Step 5: Turn on the requirements that are intervals, not switches
• Step 6: Write the exceptions down the way ASD's guide does
• Step 7: Tell the client what they will have, before the date
• Step 8: Ask which framework they mean, because ASD moved this month
• Questions people ask when the deadline is somebody else's

Step 1: Get the requirement in writing before you get a quote

Three questions, and the answers belong in an email you keep. Which maturity level does the requirement name. Which systems does it cover. And does anyone external have to do the assessing.

That third one is worth taking from ASD directly, because it changes your timeline. There is no requirement for organisations to have their Essential Eight implementation certified by an independent party. Independence only bites where something imposes it: a government directive or policy, a regulatory authority, or contractual arrangements. A client's procurement clause is a contractual arrangement, which is exactly why you ask rather than assume. If your own assessment is acceptable to them, you have just taken an assessor's lead time out of thirteen weeks.

The level matters more than anything else in the sentence. Maturity Level One and Maturity Level Two are not two sizes of the same job, they differ control by control, and what each maturity level actually describes is worth reading before you agree to one. If the requirement does not name a level, it is not yet a requirement. Go back and ask.

Then ask what they want to be holding on the date. A claimed level, an assessment report, or evidence they can file against their own obligations. Those are three different pieces of work, and only one of them is a number.

Step 2: Decide what aligned will mean on the date

Aligned is not a defined term, so define it yourself, early, in writing, and in a form you can actually deliver.

Here is why a loose definition is dangerous. To claim a mitigation strategy is implemented, every control inside it has to come back as effective or as an alternate control. One ineffective control and the requirements for that maturity level have not been met. If one or more of the eight strategies is not implemented, the target level for the system cannot be claimed at all. So a promise of Essential 8 alignment by 31 December is a promise one bad control can break. You will not know which control until somebody looks properly.

What you can promise safely is a position and a plan. A recorded outcome for every control across the eight strategies. A statement of whether the target level has been met, in ASD's own outcome words rather than a traffic-light scheme somebody invented. The evidence each conclusion rests on. And a dated, costed list for whatever is not there yet.

That is a stronger document than a claimed level with nothing behind it, and it survives the second question. If you have not commissioned one before, what an Essential 8 assessment involves sets out the shape of it, including how the quality of the evidence decides what the answer is worth.

Step 3: Do the controls that are settings, in week one

Start with the controls that are settings, because they are the only ones that behave themselves inside a deadline.

Take user application hardening first. At Maturity Level One it is four requirements. Internet Explorer 11 disabled or removed. Web browsers not processing Java from the internet. Web browsers not processing web advertisements from the internet. And browser security settings users cannot change. Those are policy settings. Microsoft Office macros at the same level are not much harder: macros disabled for users without a demonstrated business requirement, macros blocked in files originating from the internet, macro antivirus scanning enabled, and macro security settings users cannot change.

Multi-factor authentication is technically quick and organisationally slower, because enforcement is a configuration change and enrolment is a people exercise. Do the configuration in week one and chase the stragglers through the rest of the month.

Two cautions on this group. A demonstrated business requirement means somebody in the business has to demonstrate it, so open that conversation in week one rather than discovering it in week ten. And users cannot change the setting is the half that gets missed, because a setting applied once is not a setting enforced. If you want to know where you stand before anyone quotes you, the self-review you can run this week covers all eight in plain questions.

Step 4: Start the three that need a runway, knowing they finish last

Three of the eight will not be rushed, and pretending otherwise is how a quarter ends badly.

Application control is the big one. ASD's own implementation steps are to identify approved applications, develop rules so only those applications execute, maintain those rules through a change management program, and validate the rules annually or more often. Working out what is actually running in a business that has never restricted it is discovery, and the first enforcement pass will block something somebody needs. Budget for a monitoring period before you enforce, and expect the exceptions list to be the real deliverable.

Restricting administrative privileges is the one that takes things away from people. At Maturity Level One it asks for dedicated privileged accounts used solely for privileged duties, privileged accounts kept off the internet, email and web services, and separate privileged and unprivileged operating environments. That is an access redesign, and it reaches senior people who have had local administrator rights for a decade. The friction is the control working.

Then the one no amount of effort compresses. Operating systems no longer supported by vendors are to be replaced, and unsupported online services and office productivity software removed. If that is where your gap sits, the quarter buys you a procurement decision and a dated plan, not a finished control. Sequence all three first anyway. They take the longest, so they need the most calendar.

Step 5: Turn on the requirements that are intervals, not switches

Some Maturity Level One requirements are not switches at all. They are intervals, and an interval has to be kept before anybody can see it.

The patching requirements are written as schedules. An automated method of asset discovery at least fortnightly. A vulnerability scanner used at least daily to find missing patches in online services, and at least weekly for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Patches for critical vulnerabilities in online services inside 48 hours of release. The rest of that group inside two weeks, and workstations and non-internet-facing servers inside one month.

Read those as a calendar rather than a task list. You can configure a scanner in a day. ASD ranks assessment evidence by quality: testing a control sits above reviewing its configuration, and both sit above a policy or a verbal statement of intent. For an interval, the part that can actually be tested is whether the interval has been kept. That makes the record the useful artefact. A record you started last week is a short record.

Backups work the same way. The requirement is not that backups run. It is that restoration of data, applications and settings to a common point in time is tested as part of disaster recovery exercises, and that unprivileged accounts cannot modify or delete them. A tested restore is a booked event with a result written down afterwards. Put it in week two, not week twelve.

Step 6: Write the exceptions down the way ASD's guide does

The thing you cannot finish is not automatically a failure, provided you handle it the way the framework expects.

ASD's assessment process guide works through two examples, and the contrast is the whole lesson. In the first, an organisation found a low-risk Microsoft Windows server it could not patch. It put a plan in place to decommission the server within two months, assigned a risk owner, and applied strong compensating controls. The assessor's conclusion was that the exception should not stop the organisation reaching its target maturity level. In the second, an organisation found a cloud service without multi-factor authentication. It decided that enabling it was not worth the effort or the user complaints, and accepted the risk instead of putting compensating controls in place. That one was precluded.

Same framework, same shape of gap, opposite outcomes. The difference is a managed exception with compensating controls behind it, against a gap with a decision attached. Risk acceptance on its own does not carry a whole mitigation strategy either, and ASD says so plainly.

So write them down properly. ASD's own list of what exception documentation should include is specific, and it is the most useful page you will read this quarter.

• The detail, scope and justification for the exception.
• The compensating controls, with their own detail, scope and justification.
• How long those compensating controls are expected to last, and when they will next be reviewed.
• The system risk rating before and after the compensating controls went in.
• Any caveats placed on using the system because of the exception.
• Acceptance of the residual risk by an appropriate authority, and the date the exception will next be considered. Exceptions should not be approved beyond one year.

Step 7: Tell the client what they will have, before the date

Go back to the client before the deadline rather than on it, and lead with what you will be holding rather than what you will not.

A defensible update is four lines. The level and scope you understood them to require. Where each of the eight sits today, in ASD's outcome words. What is closed, with the evidence behind it. What is not, with a named owner, the compensating controls, and a date.

If the date is wrong, say so early, and say it in their language, which is risk rather than IT. A client setting a quarter-end date is usually managing their own supply-chain exposure, and a partial position they can see beats a claimed position that collapses when their auditor asks a second question. Offer them what they actually need: a dated plan, the interim evidence, and a review point in the calendar.

What does not work is putting the word aligned in an email and hoping the detail never comes up. It comes up at renewal, or at their next audit, and a claim you cannot evidence is worse than a gap you declared. If you would rather hand them something independent than something assembled under pressure, a Cyber Strength Audit documents the environment against the frameworks that apply to your industry and returns a costed path for what is left.

Step 8: Ask which framework they mean, because ASD moved this month

On 15 October 2026 ASD launched the ASD Essentials, which it describes as an evolution of the Essential Eight. It is a series of chapters rather than one list. Essentials for enterprise IT, which is the evolution of the Essential Eight, plus chapters for operational technology and for cloud.

Before anyone panics about that landing in the same quarter as a deadline, read what ASD actually said about the transition. Both frameworks are being maintained on cyber.gov.au through the transition period. Organisations should continue to meet their current regulatory obligations until regulators communicate changes. And ASD does not recommend slowing or stopping the roll-out of pre-approved security initiatives, so approved Essential 8 work is work to finish, not work to pause.

Two details are worth carrying into the client conversation. Every Essential Eight mitigation strategy maps to at least one principle in the new series, and in most cases a control implemented under the Essential Eight will directly satisfy or substantially contribute to a corresponding action. But maturity level ratings under the Essential Eight do not automatically convert into effectiveness outcomes under the Essentials. The work travels. The grade does not.

The new series is written primarily for Commonwealth entities, critical infrastructure owners and operators, and large organisations, and ASD says smaller businesses can still use the guidance where it is relevant. Which is one more reason to ask your client what they mean rather than guess at it.

This article reflects ASD's published guidance as at 20 October 2026: the Essential Eight maturity model, the Essential Eight assessment process guide, and the ASD Essentials material published on 15 October 2026. ASD consulted on evolving the framework between 15 June and 12 July 2026, and further transition guidance is expected from ASD and from regulators, so check the current ASD pages before you commit to a requirement or a date.

Questions people ask when the deadline is somebody else's

Can we actually reach Essential 8 alignment in one quarter?

You can reach a defensible position in a quarter, and whether that counts as Essential 8 alignment depends on the level you were asked for and where you are starting. The settings-based controls can be in place within a fortnight. Application control, privileged account separation and replacing anything the vendor no longer supports are the three that run past thirteen weeks in most environments. The deliverable that is always achievable is an assessed position against all eight, with evidence, plus a dated plan and documented exceptions for the rest.

Do we need an external assessor, or can we do this ourselves?

ASD does not require certification by an independent party, so the answer usually sits in the document that gave you the deadline. Independence is needed where a government directive or policy, a regulator, or a contract requires it, and a client's procurement clause is a contract. The practical limit on assessing yourself is evidence quality rather than permission. Testing your own controls with the detachment ASD's top evidence tier describes is genuinely hard, and somebody who administers the environment daily stops seeing it.

What should be finished by week four, and what should still be moving?

Finished by week four: the requirement in writing, an agreed scope, and an assessed position against all eight. The browser and macro hardening in place. Multi-factor enforcement configured. The scanning and patching schedules running, so the record starts building. Still moving at that point: application control in monitoring rather than enforcement, the administrator access redesign, any system replacement, and the first tested restore. Anything with a procurement decision inside it should have a date and an owner by then, not a finish.

What is the first thing to do on Monday?

Reply to whoever set the deadline and ask three things: the maturity level, the systems in scope, and whether an independent assessment is required. Ask what they want to be holding on the date as well, because an assessment report and a claimed level are different jobs. Then book a scoped look at your environment so the plan you take back to them is costed rather than hopeful. Nothing else in the quarter is worth sequencing until those answers exist.

Citations

• "Essential Eight maturity model", Australian Signals Directorate. The source of the target-level and progressive-implementation guidance, the same-level-across-all-eight rule, the treatment of documented exceptions, the Maturity Level One requirements quoted above including the patching intervals and the replacement of unsupported systems, and the statement that no independent certification is required unless imposed by a directive, a regulator or a contract. Last reviewed 27 November 2023. cyber.gov.au
• "Essential Eight assessment process guide", Australian Signals Directorate. The source of the four evidence-quality tiers, the standardised assessment outcomes, the rule that one ineffective control prevents a maturity level being claimed, the two worked exception examples, and the list of what exception documentation should contain. Published 24 November 2022, last reviewed 2 October 2024. cyber.gov.au
• "ASD Essentials: evolving our approach to cyber security resilience", Australian Signals Directorate. Announces the launch of the ASD Essentials and its first three chapters, states that both frameworks will be maintained during the transition period, and says organisations should continue to meet their current regulatory obligations until regulators communicate changes. Published 15 October 2026. cyber.gov.au
• "ASD Essentials frequently asked questions", Australian Signals Directorate. Confirms the consultation ran from 15 June 2026 to 12 July 2026, that ASD does not recommend slowing or stopping approved uplift programs, that every Essential Eight mitigation strategy maps to at least one principle in the new series, and that maturity level ratings do not automatically convert into effectiveness outcomes. Published 15 October 2026. cyber.gov.au
• "Implementing application control", Australian Signals Directorate. The four high-level implementation steps used above, including maintaining application control rules through a change management program and validating them annually or more frequently. Last reviewed 27 November 2023. cyber.gov.au

Related Reading

• Cyber Strength Audit
• What an Essential 8 Assessment Actually Involves
• Essential 8 Maturity Level 1, 2 or 3: Which One Applies to You
• What Your Provider Should Show You at an Essential 8 Review
• The 6 Step Cyber Strength System

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.