The Essential Eight uplift nobody warns you about: Change management at scale

Essential Eight maturity assessments can tell you whether controls have been implemented and are operating effectively. What they don’t necessarily tell you is whether an organisation has absorbed the change required to sustain them.

I led communications and change management for the Essential Eight maturity uplift at the NSW Department of Education – thousands of schools, hundreds of thousands of endpoints, millions of users and a workforce that, for the most part, didn’t see cybersecurity as part of their job. Keeping student data safe is enormously important – these systems hold the records of the people who will shape this country’s future – and yet for most teachers, that connection simply wasn’t visible; they were focused on teaching, not on the data pipeline underneath it. Every control we rolled out had to survive contact with a classroom, not just a compliance checklist.

The insight that mattered most, and that most uplift plans still underweight, is that technical readiness and organisational readiness run on completely different timelines; treating them as the same problem is where programs quietly stall.

The fastest technical rollout isn’t the fastest real one

Centrally deploying a new restriction can be quick. Getting a school full of teachers (most of whom are mid-lesson-planning, mid-marking, mid-everything) to understand and accept that restriction without it becoming a trust problem is not. And if you skip that step, a control can be technically deployed without being operationally embedded.

That distinction matters. The programs that hold up are the ones that deliberately account for the gap between the two, rather than discovering it after go-live through a spike in help-desk tickets, workaround requests and Technology Support Officers openly swapping ways to bypass controls on Viva Engage.

That behaviour is easy to dismiss as resistance, but resistance is information. A workaround request might expose an operational dependency the technical team hadn’t seen. It might reveal that the control is creating an unintended consequence. Or it might simply show that people don’t understand why the change is necessary.

Those are three different problems, and they require three different responses.

You need translators, not just technicians

The people who design and implement Essential Eight controls are, almost by definition, not always the people best placed to explain to a staffroom why a control matters in terms that land. That’s a distinct skill set. You need people who can sit with frontline staff, absorb frustration without becoming defensive, explain the ‘why’ in plain language and carry credible feedback back to the technical team.

One of the most valuable functions of change management in an uplift isn’t broadcasting communications, it’s creating that feedback loop between the people implementing the controls and the people living with them. At scale, that becomes particularly important. A principal doesn’t need the same information as a Technology Support Officer. A teacher doesn’t need the same level of technical detail as someone responsible for managing devices locally. Executives need to understand risk, progress and organisational impact.

Sending everyone the same message may be efficient, but that doesn’t make it effective.

The question isn’t simply “Have we communicated the change?”, it’s “Does each audience understand what this means for them, what they need to do differently and why?”.

Skipping that translation function – or quietly add it to an already-stretched technical lead’s workload – means you’ll end up with technical delivery on schedule but adoption will limp along far behind it.

Organisational readiness needs its own measures

Technical maturity has defined measures, and organisational readiness deserves them too. I think about it across four dimensions:

1. Awareness (Do the people affected actually know what’s changing and understand why?)

An email being sent is not awareness. A briefing being delivered is not awareness. The measure is whether the people expected to behave differently understand the change well enough to act on it.

2. Acceptance (Do people understand the reason for the control and the operational trade-offs involved?)

Acceptance doesn’t mean everyone has to like the change – cybersecurity controls are often inconvenient by design. But there is an enormous difference between “This is annoying, but I understand why we’re doing it” and “IT has imposed another ridiculous restriction on us”. That difference shows up in behaviour.

3. Adoption (Are people actually working within the new control, or are they finding ways around it?)

Help-desk trends, workaround requests, exceptions, local escalation patterns and feedback from frontline support teams can tell you things that a technical implementation dashboard cannot. A green deployment status doesn’t necessarily mean a control has landed.

4. Sustainment (Is the change still holding six and 12 months later?)

This is the dimension that long-running programs can underestimate most easily, because organisational readiness doesn’t stay still.

Momentum decays faster than the roadmap assumes

A multi-year program rolling out across hundreds of sites doesn’t get one adoption moment, it gets dozens of them, and every one is vulnerable to the same thing: a principal moves on, an IT coordinator changes, new staff arrive, the initial briefing fades from memory and the control that was accepted in March is being questioned again in October. The project team may still remember the original rationale perfectly, but the organisation often won’t. That means change management cannot end at go-live. Treating it as a launch activity rather than a sustained capability is one of the fastest ways for adoption to erode quietly over the life of a program – often well after anyone is actively watching for it.

For large organisations in particular, communications therefore need a lifecycle. What happens at launch? What happens three months later? How are new starters brought into the change? What happens when local leadership changes? How do you know when resistance is starting to reappear – and who owns that problem once the original delivery team moves on to other projects?

Those questions belong in the uplift plan alongside technical milestones.

What this means if you’re running – or scoping – an uplift

There are a few questions worth asking now, regardless of where your program sits:

• Are we tracking adoption and sentiment – help-desk volume, workaround requests, exception requests, local pushback and recurring points of confusion – alongside technical maturity metrics?
• Can we distinguish between genuine operational problems, communication problems and simple resistance, or are they all being treated as the same thing?
• Have we segmented our audiences and defined what each one actually needs to understand and do differently?
• Do we have someone whose actual job is translating technical change for non-technical staff, or is that quietly sitting on top of a technical lead’s existing workload? 
• Is feedback from frontline staff making its way back to the people designing and implementing the controls?
• What’s the plan for re-engaging staff six months after go-live, once the initial communications push has faded and turnover has reset some of the local knowledge?
• And perhaps most importantly: How will we know whether a control is merely technically deployed or genuinely operationally embedded?

Technical maturity frameworks were never designed to answer every one of these questions, but organisations undertaking major cyber uplift programs need to, because deploying a control and embedding a control are two different achievements.

The Essential Eight provides organisations with a framework for implementing important cyber mitigations; change management is part of what makes those changes survive contact with the organisation they’re designed to protect. So when you’re scoping your next uplift, the question shouldn’t just be “What technical capability do we need?”, it should also be “Who is going to take our people through this change and make sure it still holds once the project team has moved on?”.