Crisis Management for Cyber Incidents

The decision in brief. Treat crisis management as its own capability, separate from incident response, with an owner, written authority and regular rehearsal. Incident response contains the intrusion. Crisis management decides what the business does while the intrusion is still unfolding: which services to sacrifice, what to tell regulators and customers, how to handle an extortion demand, and who is allowed to say yes. Leadership should measure how quickly and cleanly those decisions get made, and change anything that relies on people improvising authority in the middle of the night.

Two jobs that are often treated as one

Incident response is a technical discipline with technical owners. It scopes the intrusion, contains it, removes the attacker and preserves evidence. NIST’s current incident response guidance, SP 800-61 Rev. 3, reflects this shift in thinking: it places incident response inside cybersecurity risk management as a whole instead of treating it as a standalone IT procedure.

Crisis management starts where technical authority ends. When containing an attacker means switching off a system that earns revenue, or when the facts are incomplete and a regulator’s clock is already running, the question is no longer technical. It is a business decision made under uncertainty, and it belongs to people who may never have seen the environment. If they have not agreed in advance how they will decide, the incident team waits, and the attacker does not.

Where a cyber crisis actually breaks

Most crisis failures are coordination failures. Five show up repeatedly in the way organizations are structured:

• No one can approve the costly action. The incident lead knows isolation is needed. The person with authority to take a revenue system offline is unreachable, unbriefed or unsure they are allowed to decide.

• The technical bridge and the decision forum are the same room. Executives ask questions that pull engineers away from containment, and engineers speak in detail executives cannot use.

• The tools for coordination sit inside the compromised estate. If chat, email and the identity platform are all in scope of the attack, the crisis team cannot assume it can talk.

• Obligations are discovered during the crisis. Notification duties, insurer conditions and contractual commitments get looked up by whoever has time, after hours have already been lost.

• Nobody owns the timeline. Several parties keep fragments of what happened and when, and the account given to a regulator differs from the account given to the board.

Composite scenario (hypothetical). An alert at 02:00 on a Saturday shows attackers using a stolen administrator session to encrypt file servers and reach the ERP database. The incident lead wants to isolate the ERP, which also runs dispatch and invoicing. No one on the call can approve taking it offline. The COO is traveling, the CFO’s deputy has never been briefed, and the corporate chat platform runs on the identity system the attackers now control. By the time a decision-maker is reached, the encryption has spread further than the isolation would have cost. Nothing here needs an exotic attacker. It needs only authority that was never written down.

The decisions that cannot wait for a meeting

Leadership does not need to pre-decide the outcome of each choice. It needs to decide who decides, what that person needs to know, and what has been settled in advance. The owners below are typical; the right allocation depends on your structure.

Regulatory clocks start on different events

A cyber crisis often triggers several notification duties at once, and they do not share a starting point. Some begin when the organization becomes aware, some when it classifies the incident, and some when it determines materiality. The table shows five regimes that commonly apply to enterprises with European, US or Indian exposure.

NIS2 and DORA add further reports behind the first deadline. UAE and wider GCC sector regulators set their own expectations, which should be confirmed with counsel and the relevant regulator. The table is a prompt for the conversation, not legal advice.

The practical consequence is simple. Someone has to time-stamp when the organization became aware, when it classified, and when it determined materiality. Those timestamps decide whether a deadline was met, and they are far harder to reconstruct afterwards than to record as they happen.

What leadership should measure

Most organizations see few genuine crises, so incident history is a poor guide to crisis readiness. The useful measures come from rehearsal. Treat any measure that has never been tested as unknown, not as green.

What to change before the next incident

1. Write authority down. Pre-delegate the decisions in the table above, with named deputies, so that no one needs to ask permission to be allowed to decide.

2. Separate the rooms. Run the technical bridge and the decision forum apart, linked by one liaison who translates between them.

3. Assume the corporate stack is compromised. Keep an out-of-band channel, an offline copy of contacts and plans, and a rule for when to switch to them.

4. Keep one decision log with one owner. Record facts, decisions, who made them and when, in a place the attacker cannot reach.

5. Contract help before you need it. Incident response, forensics, legal counsel and communications support should be engaged on terms agreed in advance, and insurer notice conditions should be read now.

6. Rehearse with the people who would actually decide. Use injects that force a trade-off, such as a revenue system that must go offline while a regulator’s deadline is running.

Investment follows evidence. A rehearsal that exposes a missing out-of-band channel or an unowned decision is a stronger case for spend than a maturity score, because it shows the board exactly what failed and what it would have cost.

Questions for the executive committee

• If email, chat and the identity platform were unavailable at 02:00, how would the crisis team assemble, and who calls whom?

• Who may authorize taking our largest revenue system offline, and do they know they can?

• Which notification clocks apply to us, and who owns the timeline?

• When did the board last rehearse a decision instead of receiving a briefing?

• What have we agreed about extortion demands before emotion enters the room?

Sources

Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (SP 800-61 Rev. 3) — NIST

Article 33: Notification of a personal data breach to the supervisory authority — GDPR text

NIS2 Article 23: Reporting obligations — Presencis regulatory reference

DORA: ICT-related incidents — Austrian Financial Market Authority

SEC Finalizes Cybersecurity Disclosure Requirements — Hunton Andrews Kurth legal analysis

CERT-In directions relating to information security practices: summary — TaxGuru