Crisis Management Program Design and Governance
Crisis Management Program Design and Governance
This domain tests how you turn crisis management from an improvised response into a governed capability: a charter, decision rights, tiered escalation, integration with related disciplines, and assurance that the program works under stress.
Core rules
- A board-approved charter defines purpose, scope, authority, activation rights, funding, and reporting. Without delegated authority, the crisis lead cannot commit resources at speed.
- Governance separates oversight from command. An executive sponsor and steering group own policy and risk appetite; the crisis lead and functional leads run the response; a secretariat maintains decision logs, action tracking, and records.
- Use a tiered model such as watch, partial activation, and full activation. Thresholds should be based on impact dimensions (people, operations, finance, legal and regulatory, reputation) rather than subjective judgement.
- A decision-rights matrix states who decides, who must be consulted, and who is informed for common crisis decisions: facility closure, product withdrawal, public statements, regulatory notification, and spend above delegated limits.
- Integrate with enterprise risk management, business continuity, security, and communications so scenarios, risk registers, and escalation routes do not conflict.
- Assurance uses exercises, audits, and metrics such as time to activate, time to first decision, action closure rate, and corrective-action aging.
Worked example
A ransomware attack encrypts scheduling systems. The program thresholds say full activation when customer safety is threatened or regulatory notification is likely. The crisis lead activates the full tier, convenes the team, and uses the decision-rights matrix: operations decides on manual workarounds, legal decides on notification timing after consultation, and communications approves the holding statement. Reasoning: pre-agreed thresholds and rights remove debate about whether and who.
Traps
A plan that lives in a binder is not a capability. Governance groups that are too large slow decisions. Programs owned only by security or IT miss business and reputational dimensions. Escalation thresholds with no named monitor never trigger.