Crisis management is how an organisation makes decisions when the situation exceeds what normal processes and plans can absorb. It is not the same as incident response, which contains a known problem using known procedures. A crisis is defined by uncertainty and by the level at which choices have to be made: incomplete information, competing priorities, and consequences that reach beyond operations into reputation, regulation and trust.
- The distinguishing feature is decision authority, not the size of the event.
- A declared crisis suspends normal decision routes and replaces them deliberately.
- Thresholds must be agreed before the day, or nobody declares anything.
- Communications are part of the response, not an afterthought to it.
- What gets reviewed afterwards is the quality of the decisions, not just the outcome.
What is crisis management?
Most organisations have a continuity capability and an incident process, and assume that between them a crisis is covered. It usually is not. Continuity plans tell people how to keep working when a known activity is disrupted. Incident procedures tell technical teams how to contain a known category of problem. Neither answers what to do when the situation is unfamiliar, the information is contested, and the choices involve trade-offs no procedure anticipated.
That is the gap crisis management fills. It is a small set of pre-agreed arrangements: who can declare a crisis, who convenes, what that group is empowered to decide without going back through normal governance, and how decisions and their reasoning get recorded while they are being made.
It sits alongside business continuity rather than inside it. The continuity plan may well be invoked during a crisis, and often is, but the crisis is the layer above deciding what the organisation does about consequences the plan does not cover.
When does an incident become a crisis?
Organisations get this wrong in both directions. Some declare a crisis for anything visible, which exhausts the team and devalues the mechanism. Others never declare one, and senior people improvise around a procedure that was designed for something smaller. The way out is to define the boundaries in advance, on the axis that actually separates them: who has to decide.
| Incident | Crisis | Disaster | |
|---|---|---|---|
| Who decides | The duty team, within existing procedure and delegated authority. | A convened crisis team with authority explicitly granted in advance. | Executive leadership, often alongside external agencies. |
| What is at stake | Service quality and a defined operational outcome. | Multiple outcomes at once, including reputation, regulatory position and trust. | Physical safety, viability of a site or of the organisation. |
| What the response optimises for | Restoring the service as quickly as procedure allows. | The least bad overall position, accepting some losses deliberately. | Life safety first, then containment, then anything else. |
| Where it is documented | Incident procedures and runbooks. | Crisis arrangements: thresholds, team, decision rights, log. | Emergency and evacuation plans, coordinated externally. |
| How it ends | Service restored and the ticket closed. | A decision to stand down, taken by the same authority that declared it. | External sign off, then a long recovery. |
The middle column is the one most organisations have not written down. Note also that severity is not the axis. A small technical fault can become a crisis if the consequences are wide and the right response is genuinely unclear, while a large outage with a rehearsed workaround may stay an incident throughout.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
Who sits on the crisis team, and what may they decide?
A crisis team should be small enough to decide. Beyond about seven people it becomes a briefing audience, and the decisions migrate to a quieter conversation elsewhere. The most useful thing you can do in advance is write down what each role is empowered to do without seeking further approval, and what each role must deliberately not be doing.
| Role | May decide alone | Should not be doing |
|---|---|---|
| Crisis lead | Declare and stand down, set priorities, commit spend to an agreed limit. | Running any workstream personally. The lead’s job is to decide, not to fix. |
| Operations | Invoke continuity arrangements and reallocate people between activities. | Waiting for the technical picture to be complete before starting workarounds. |
| Technology | Technical containment and recovery sequencing within the agreed objectives. | Briefing externally, or negotiating priorities directly with customers. |
| Communications | Issue pre-approved holding statements and choose channel and timing. | Making claims about cause or timescale that the team has not confirmed. |
| Legal and privacy | Advise on notification obligations and preserve evidence and privilege. | Acting as a brake on operational decisions that are properly the lead’s. |
| Loggist | Record every decision, the information it rested on and the time. | Participating in the decisions they are recording. |
The loggist is the role most often left out and the one that most reliably pays for itself. A contemporaneous record of what was known and when is what allows you to defend a reasonable decision that turned out badly, and it is nearly impossible to reconstruct afterwards. Every role also needs a named deputy, because a crisis that begins at two in the morning or during a holiday is not a special case.
How does a crisis actually get run?
The sequence below is not a procedure to follow rigidly. It is the set of moves that need to have an owner, because in practice crises go wrong at the joins rather than in the middle of any one activity.
Declaration is the step that decides how the rest goes. Until someone with authority names the situation a crisis, the organisation keeps applying normal process to an abnormal event, and every hour spent doing that narrows the options. This is why the threshold needs a name and a person attached to it rather than resting on judgement in the moment.
Decide and communicate run in parallel, not in sequence. Waiting for certainty before saying anything is a decision in itself, and usually the wrong one, because silence gets filled by other people’s accounts.
Invoking the business continuity plan is normally one of the crisis team’s earliest decisions rather than a separate process running alongside. The crisis team decides what the organisation does about consequences the plan does not reach.
What does crisis communication have to cover?
Four audiences, with different needs and different clocks. Staff need to know what to do and what to say if asked, and they need it first, because they will be asked. Customers need to know what is affected and what to expect, in plain terms, before they find out elsewhere. Suppliers and partners may need to act. Regulators and supervisory authorities come with obligations attached, and which of them apply depends on the nature of the event.
On that last group, be precise about what actually applies to you rather than assuming a general duty. Where the event involves a personal data breach, UK GDPR sets a notification timeframe of 72 hours from becoming aware, where the breach meets the risk threshold. Sector regimes carry their own arrangements, and organisations in scope of NIS 2 face separate reporting steps set out in the NIS 2 crisis management guidance. Which of these bind you is a question to settle in advance, because the middle of a crisis is a poor time to establish it.
Prepare holding statements before you need them. Not detailed scripts, which never fit the event, but approved structures that let communications say something accurate within the first hour without convening a drafting committee.
Start your free trial
Want to explore?
Sign up for your free trial today and get hands on with all the compliance features that ISMS.online has to offer
How do you exercise crisis management?
Technical recovery testing and crisis exercising are different activities and one does not substitute for the other. A restore test proves a system comes back. It says nothing about whether your executives can make a contested decision with partial information while the phone is ringing. The five levels of technical testing are covered under disaster recovery plan.
Crisis exercising works differently. It is scenario based, it deliberately withholds information, and its value is in the discomfort. A useful exercise puts the actual crisis team in a room with a scenario that has no clean answer, injects new information partway through that invalidates an earlier decision, and requires them to communicate externally under time pressure. What you are testing is whether authority is clear, whether the thresholds mean anything, and whether people can decide without unanimous agreement.
Two habits make exercises worthwhile. Use scenarios that are plausible for your organisation rather than dramatic ones, and include at least one where the right answer is to accept a loss. Teams that have only ever exercised recoverable scenarios tend to hesitate when a genuine sacrifice is required. Record the decisions and review them afterwards on their reasoning, not on whether the outcome happened to be good.
How does crisis management connect to business resilience?
Crisis management is the sharpest test of whether governance has produced anything. Everything the crisis team needs on the day was either built beforehand or is not available: knowing which activities matter, which suppliers sit behind them, what data is involved, who owns what, and what you have already told customers you would do.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system. A crisis rarely stays inside one of those domains. A ransomware event is a security incident, a privacy matter with notification consequences, and a continuity problem simultaneously, and a team that has to consult three separate systems to establish what data was involved loses hours it does not have. Running them as one operating model is what makes the answer available in minutes. The wider structure is set out in the business resilience framework.
How do you prove your crisis management works?
Crisis arrangements are among the hardest things to evidence, because the thing you want to demonstrate is a capability rather than a document. What can be shown: the arrangements themselves with dates and approval, the thresholds and who holds each authority, exercise records with participants and scenarios, the decision logs from exercises and from any real events, the findings, and the changes made as a result.
The decision log is the most persuasive artefact you can hold, and the one nobody produces retrospectively. It is also the thing that most clearly separates an organisation that rehearses from one that owns a plan. How to build evidence as a by-product of the work rather than assembling it later is set out in how to evidence resilience, and the Resilience Score gives you a baseline to measure against.
Why choose ISMS.online for crisis management?
A crisis team performs on what it can find in the first ten minutes. ISMS.online is built so that information is already there.
- One view of what depends on what: activities, systems, suppliers and data mapped together, so scope questions have answers immediately.
- Roles and authority recorded: named owners and deputies with review dates, so the team composition is current rather than historical.
- Exercise and decision records: capture scenarios, participants, decisions and findings in the same place as the arrangements.
- Notification context to hand: the obligations attached to your frameworks and contracts held alongside the incident, not in a separate filing system.
- One control set, every framework: map once and reuse across ISO 22301, ISO 27001, ISO 27701 and ISO 42001.
- Corrective actions tracked to closure: findings from an exercise become work with an owner, not a paragraph in a report.
- Built for UK and regulated markets: designed for organisations that have to prove resilience to win and keep contracts.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between crisis management and incident response?
Incident response handles a recognised problem using established procedure, with authority already delegated to the duty team. Crisis management handles situations where the problem is unfamiliar, the information is incomplete and the choices involve trade-offs no procedure anticipated. The practical difference is the level at which decisions are made and how much discretion the responders hold.
Who should be able to declare a crisis?
A small number of named people, each with a deputy, and ideally including someone available outside business hours who is not a member of the executive. Restricting declaration to one senior individual means the mechanism depends on that person’s availability. The threshold should be written down so declaring is recognising a defined condition rather than making a career decision.
Do we need a separate crisis management plan?
You need separate arrangements, but they should be short. The useful content is thresholds, the team and their decision rights, contact routes that work when systems do not, communication structures and how decisions get logged. A long crisis document is a sign that continuity content has been duplicated into it. Reference the continuity plan and the recovery runbooks rather than restating them.
How often should the crisis team exercise?
At least annually with the real team in the room, and again whenever the membership changes materially. Because crisis teams are made up of senior people, exercises are the first thing to be postponed, and a team that has not rehearsed together is effectively a list of names. Shorter, more frequent scenario discussions are easier to hold and still surface most of the ambiguity about authority.
Is crisis management covered by a standard?
No single standard is dedicated to it, but it is addressed within several. ISO 22301 covers incident response structure and communication as part of a business continuity management system, and ISO 22361 provides guidance specifically on crisis management. ISO 27001 contributes through its information security incident management controls. Working to ISO 22301 gives you the management system that keeps the arrangements owned, exercised and reviewed.
