Why Security Leaders Need to Learn Change Management
The CISSP, CISM, CCSP, and AAISM curricula teach you how to manage risk. None of them teach you how to manage people through change. And yet, every meaningful security initiative is fundamentally a change programme.
When you roll out a new identity governance platform, you’re not just deploying software. You’re asking hundreds of people to change how they request access, how they approve it, and how they think about entitlements. When you implement a data loss prevention programme, you’re telling people that the way they’ve been sharing files for years is no longer acceptable.
These are behavioural changes. And behavioural change is hard.
The Gap in the Curriculum
I’ve held CISM, CISSP, CCSP, and AAISM certifications across my career. Between them, they cover risk management, governance, architecture, and audit. What they don’t cover — not meaningfully — is how to take a group of people from “the way things are” to “the way things need to be.”
The AGSM’s organisational change management methodology, by contrast, starts with a deceptively simple question: what has to change, and for whom? It maps stakeholders, assesses readiness, identifies resistance, and builds a coalition before a single technical control is deployed.
Security as a Change Problem
Consider a typical security uplift programme. The technical components — SIEM deployment, access reviews, policy updates — are well-understood. Project managers can schedule them. Engineers can build them.
But the human components — getting a finance team to stop sharing passwords, convincing a development team to adopt secure coding practices, persuading an executive that their personal email isn’t an appropriate channel for board papers — these require a fundamentally different skill set.
They require empathy. They require communication. They require an understanding of why people resist change, and how to work with that resistance rather than against it.
What This Means in Practice
In my experience, the security programmes that fail aren’t the ones with poor technology choices. They’re the ones where the security team assumed that a policy and a tool would be sufficient, and didn’t invest in bringing people along.
The ones that succeed build change management into the programme from day one. They identify champions. They communicate early and often. They listen to concerns rather than dismissing them as “resistance to security.”
If you’re a security leader and you haven’t studied change management, start. Your technical skills got you the role. Your change management skills will determine whether you succeed in it.