From Essential Eight Maturity Level One to Two: a 90-day plan

The Level One to Level Two jump is the largest in the model operationally, and the reason is not the number of new requirements — it is that two of them need infrastructure. Central logging and jump servers are procurement and architecture, not configuration. Everything else is comparatively quick.

So the plan front-loads the things with lead time and leaves the settings until last. Ninety days is realistic if you genuinely hold Level One across all eight strategies. If you do not, fix that first — Level Two is assessed on top of Level One, not instead of it.

Days 1 to 15: confirm the baseline and start procurement

• Re-verify Level One across all eight strategies. Not a review of your last assessment — a check that nothing has slipped since. Acquisitions and new SaaS platforms are the usual culprits.
• Decide the logging destination. Level Two requires central logging of MFA events, privileged access events, privileged account and group management, application control allow and block events, and macro execution. Scope the volume now; it will surprise you.
• Design the jump server path. Where administrators will work from, how they authenticate, and what happens to the admin workstations they use today.
• Inventory privileged accounts including service accounts, break glass and local administrators. You need this for three separate requirements.

Days 16 to 45: the long-lead items

• Stand up central logging and onboard the first sources. Start with privileged access and MFA — highest value, easiest to produce.
• Deploy jump servers to a pilot group of administrators. Expect resistance; expect to adjust the workflow rather than the requirement.
• Extend application control to internet-facing servers. Run audit mode first, exactly as you did for workstations. Server workloads are more uniform, so this is faster than the workstation rollout was.
• Extend vulnerability scanning to all other applications at least fortnightly, and hold the two-week window on the productivity and browser layer. This usually means automating a cycle that was partly manual.

Days 46 to 70: privileged access discipline

• MFA for privileged and unprivileged users of systems, not just online services — and it must be phishing-resistant, which is a Level Two requirement, not a Level Three one. Budget for authenticators here.
• Annual revalidation process for privileged access, with the first cycle actually run rather than scheduled.
• 45-day inactivity disablement automated. Doing this manually will not survive contact with an assessor asking for evidence over time.
• Credential management for break glass, local administrator and service accounts — long, unique, unpredictable and managed. Service accounts are usually the hard part.
• Onboard the remaining log sources: application control, macros, blocked PowerShell.

Days 71 to 90: hardening and evidence

This block is configuration work and can move quickly once the infrastructure is in place:

• Office restrictions: no child processes, no executable content, no code injection into other processes, no OLE package activation.
• PDF software: no child processes; hardening baseline applied.
• Browser, Office and PDF hardening in line with ASD and vendor guidance, with settings not user-changeable.
• Macros blocked from making Win32 API calls.
• Extend vulnerability scanning to all other applications at least fortnightly.
• Backup access control extended to privileged accounts other than backup administrators.
• Assemble evidence and self-assess. Leave real time for this — the requirement is not met until you can demonstrate it.

What tends to slip

• Log retention. Central logging gets stood up, retention is left at a default, and the logs age out before they are useful. Decide retention against incident response needs, not storage cost.
• Service account credentials. Rotating them breaks things, so they get deferred to a later phase that never arrives.
• Jump servers for cloud administration. Teams implement the on-premises path and administer cloud tenancies from ordinary laptops.
• Hardening treated as a baseline document rather than an enforced and verified configuration.

Ninety days is achievable, but only if procurement for the logging platform starts in week one. Every plan that fails this timeline fails on that single dependency.

Key takeaways

• Start logging procurement in week one; it is the dependency every failed timeline shares.
• Jump servers meet resistance from administrators — plan the workflow, not just the build.
• Automate 45-day disablement; manual processes cannot evidence consistency.
• Leave real time at the end for evidence, because unproven is unmet.