Your incident response plan was written for IT. So what guides your leadership decisions?

20th August 2026 | Resilience Your incident response plan was written for IT. So what guides your leadership decisions?

The ransom note is on the screen and the clock is running. Your IT team knows what the next hour looks like: contain the spread, isolate what’s infected, assess the damage, start the restore in the right order.

They’ve rehearsed this. Their actions are documented in an incident response plan. 

The questions landing on your leadership team are a different set:

  • Keep operating in a degraded state or shut down? 
  • Call the insurer first or call outside counsel? 
  • Tell your largest customer what is happening before the end of the day, or hold until you know more? 

Nobody in the room has rehearsed those.

The technical decisions have a plan behind them. The rest gets made for the first time, live, on partial facts and no sleep. 

They’re never written down, never tested, which is why most plans break the moment they meet real pressure

Executive Readiness changes that.

Your IR plan solves the IT problem

A good incident response plan does real work. It sets out how systems get contained and isolated, how forensics gets coordinated, how you restore in the right sequence, and who on the technical side owns each step. 

Security people wrote it for security people, and it needs to exist.

What it rarely covers is everything the executive team has to decide while that technical work runs. 

Read most IR plans front to back and you find detailed containment steps next to near silence on the calls that sit with the CEO, the CFO, the COO, and the general counsel. Those calls get left to whoever happens to be in the room on the day.

The decisions that shape the outcome sit above IT

A serious incident forces a run of business decisions that engineers and IT technicians can’t make for you, like:

  • Whether to keep operating in a degraded state or stop until you trust your systems again
  • Whether to pay a ransom or hold, and who holds the authority to decide either way
  • What is legally notifiable, to whom, and on what deadline
  • Who can approve emergency spending, and up to what limit
  • What customers, employees, and the public are told, and in what order

None of these has a clean technical answer. Each one is a business judgment call, weighed against the others under time pressure, and each one moves the final cost of the incident up or down. 

Your IR plan usually stays quiet on them. The technical side works from a playbook while the executive side improvises the most consequential calls of the whole event.

Your leadership team needs its own crisis management playbook. 

What changes when leadership has already made the call

Imagine two companies with the same teams and same operations, hit by the same attack.

In the first, no one is sure who has the authority to halt operations, so the call waits while people check. The disclosure clock starts, and legal and communications lose the first hour working out who owns the notification instead of making it. 

The message to customers goes out late, or goes out wrong, because someone wrote it under pressure with no sign-off path. Confusion sets the pace, and every hour of it costs money and trust. It results in a four-week shutdown

The second company settled all these questions months earlier. Decision authority is defined by severity. Escalation thresholds are agreed. Holding statements for the likely scenarios are drafted and approved. 

The order of the first calls is already set: counsel, then insurer, then customer. When the incident lands, the team executes decisions it has already made rather than reaching for them under fire.

The attack was identical. What separated a contained event from a spiraling one was whether the leadership team had the hard conversations before the incident or during it.

Make the decisions before the incident forces them

A plan only on paper is not a capability. 

It only becomes one when the people who’d make the calls have made them together, in advance, and pressure-tested them against something that behaves like a real incident.

This is the cross-functional response we build at Fellsway: connecting IT, security, legal, operations, and executive leadership so the business makes the right calls under pressure, not only the right technical fixes. 

Our crisis management and incident response work starts above the server room, with the people who carry the decisions. We call it Executive Readiness. 

  1. Working alongside your leadership team, we develop an executive crisis management and incident response playbook
  2. It covers decision authority, escalation thresholds, notification triggers, and pre-drafted communications
  3. Then we test it in a facilitated, 90-minute exercise built on a scenario written specifically for your operation
  4. We leave you with a board-ready record of where you stood, along with a 30/60/90 remediation plan on what gaps to close first

Your technical response already runs from a plan. The executive response deserves the same, agreed and tested before the day you need it. 

Book a call and we’ll walk you through what that would look like for your leadership team.

Latest Cyber and AI Insights

Improve your readiness, combat disruption

Get the latest cyber and AI insights to help your organization stay compliant, resilient and ready for ever-evolving threats and challenges.

Because while risk is constant, ready is a choice.

Your incident response plan was written for IT. So what guides your leadership decisions?

Your incident response plan was written for IT. So what guides your leadership decisions?

The ransom note is on the screen and the clock is running. Your IT team knows what the next hour looks like:...

Read more
How to Build an AI Use Case Inventory for Your Manufacturing Operation

How to Build an AI Use Case Inventory for Your Manufacturing Operation

You've been told to get AI governance in place. Sooner or later every manufacturer lands here, the early movers...

Read more
Program, Not Project: Why Cybersecurity With a Start and End Date Doesn’t Work

Program, Not Project: Why Cybersecurity With a Start and End Date Doesn’t Work

You passed the audit. The certificate went up on the wall. The consultant packed up, the engagement closed out,...

Read more