Before activating crisis governance—or refusing to activate it—ask seven questions. Nine, if you count properly.
A mature board protects the organisation from two failures: responding too slowly to real emergencies, and exhausting people with imaginary ones.
Keep the vocabulary honest. Critical describes importance: failure would cause unacceptable harm, and the organisation cannot simply continue as normal. A system can be critical while operating calmly. Urgent describes a clock: delay has a cost; normal governance can still work. A non-critical task can be urgent. Emergency describes the situation and the required response: a serious actual or imminent threat that needs immediate, coordinated, non-routine action.
A material cyber incident affecting a critical outcome is a business emergency. An ordinary client-signature request is usually an administrative priority. NIST treats an event as any observable occurrence involving computing assets; an incident crosses a harm or imminent-threat threshold. Use that discipline on everything, not only on logs.
The EMERGENCY Test
E — Exposure. Is there an actual or imminent threat to people, critical services, sensitive data, material assets, legal obligations or organisational survival?
M — Magnitude. Is the potential harm serious enough to justify interrupting normal operations?
E — Escalation. Is the harm growing, spreading or becoming harder to reverse?
R — Response window. Must meaningful action happen now, rather than through the next normal meeting or workflow?
G — Governance. Are exceptional authority, cross-functional coordination or board-level risk decisions required?
E — Evidence. What is known, unknown and assumed—and how reliable is it?
N — Notification. Which customers, employees, authorities, insurers, partners or law-enforcement bodies may need communication?
C — Command. Who is in charge, who records decisions, and who can commit resources?
Y — Yield point. What conditions will end emergency mode and move the organisation into recovery?
Emergency frameworks consistently emphasise an actual or imminent threat plus urgent, coordinated, often non-routine action. If serious harm is imminent and delay makes it worse, act. If the issue can be managed safely through normal prioritisation and governance, do that instead.
Approve the Threshold in the Calm
The worst time to invent the definition of emergency is during one. The second-worst time is never: then every loud request wins, or nothing is ever allowed to interrupt the diary.
Write the threshold down. Tie it to impact, not to who is shouting. Name who can declare it, who can isolate a critical system at 02:13, and what “we are no longer in emergency mode” looks like so the organisation can return to being an organisation.
If you cannot answer the yield-point question, you will live in emergency forever. That is not resilience. That is a culture with no off switch.
Board action: Approve a shared emergency threshold before the next incident—not during it.
Relevant Sources
- Cybersecurity Incident — NIST CSRC Glossary — https://csrc.nist.gov/glossary/term/cybersecurity_incident
- Event — NIST CSRC Glossary — https://csrc.nist.gov/glossary/term/event
- Emergency Preparedness and Response: Getting Started — OSHA — https://www.osha.gov/emergency-preparedness
- Regulation (EU) 2022/2554 (DORA), Article 17 — EUR-Lex — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Incident Response Recommendations and Considerations for CSIRTs — NIST SP 800-61 Rev. 3 — https://csrc.nist.gov/pubs/sp/800/61/r3/final
If your board wants an emergency threshold that can be used in the next incident—not invented during it—that is a session I run with directors and GCs. Contact me.