Change Leadership, Operations, and Metrics
This domain tests execution: leading people through change, running security operations reliably, and proving progress with metrics that survive board scrutiny. Expect ADKAR and Kotter, stakeholder mapping, ITIL 4 change enablement, incident and problem management, and leading versus lagging indicators.
Core rules
- Change models: Kotter's eight steps (urgency, coalition, vision, communication, removing barriers, quick wins, consolidation, anchoring) and ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) diagnose why adoption stalls. Resistance is data, not disloyalty.
- Stakeholder maps use power and interest to set engagement; sponsors must be senior enough to remove barriers.
- Operations: change enablement with risk-based approval (standard, normal, emergency), incident management with defined severities, problem management for root cause, and operational readiness reviews before go-live.
- Metrics: leading indicators predict (patch SLA compliance, MFA coverage, exception aging); lagging indicators confirm (incidents, losses). DORA metrics, namely lead time, deployment frequency, change failure rate, and restore time, expose delivery risk. Define each metric's formula, source, owner, threshold, and cadence.
- Report a small set: control coverage, time to remediate by severity, detection and response times, exceptions, and adoption.
Worked example
An EDR rollout reaches 60 percent after two quarters. Adoption analysis shows high Awareness and Knowledge but low Ability: endpoint teams lack installer rights. Stakeholder mapping reveals the platform team can grant rights but was never engaged. The fix is a delegated installer role, a weekly adoption dashboard by business unit, and reinforcement through team leads. Coverage rises to 92 percent in six weeks. Adding training alone would not have moved the metric. Reasoning: diagnose the ADKAR barrier, then change the system.
Traps
Reporting activity counts such as meetings held; no baseline before transformation; too many metrics with no owners; treating the CAB as a throughput bottleneck rather than risk-based; excluding operations from design; declaring success at go-live without reinforcement.