Decision guide · Incident response governance

The worst moment is the wrong time to decide who decides.

A real incident runs a technical response and a leadership response at the same time. Incident governance names who has authority for each, in advance, so the two don't collide.

Frame the decision plan

A technical playbook answers "what do we do." It rarely answers "who decides."

Many organizations have some version of a technical incident response plan - isolate affected systems, restore from backup, call a specialist. Far fewer have decided, in advance, who has the authority to make the calls that actually determine how the incident unfolds for the business.

Who can officially declare an incident, rather than let it sit as an unconfirmed technical glitch? Who can authorize contact with an external negotiator, or a payment conversation, if it comes to that? Who decides what customers, staff, and regulators are told, and when? Without pre-agreed authority, these get decided under maximum pressure, by whoever happens to be in the room.

Incident response governance is the decision to answer those questions before an incident, not during one - separating leadership authority from the technical response it has to sit alongside.

Boundary

This is leadership decision-rights and communication-authority planning. It does not replace a specialist incident-response retainer, forensics engagement, breach counsel, or a cyber-insurance requirement, which remain separately scoped.

Decision roles

Four calls a real incident forces - decided in advance.

Declare

Call it an incident, not a glitch

Someone has to trigger the plan before informal chat becomes the entire response.

Direct

Authorize the hard trade-offs

Isolating a system, engaging a negotiator, or halting operations needs one named decision-maker.

Communicate

Control what gets said, and to whom

One voice and one timeline, agreed before the first message goes to customers or staff.

Declare it over, and capture the record

Recovery isn't finished until responsibility and lessons are actually written down.

Decision lenses

Six questions before the incident, not during it.

Declaration authorityWho can officially call this an incident and trigger the response?
Negotiation authorityWho can authorize contact with an external party, and any payment conversation?
Communication ownerWho owns the single narrative to customers, staff, and regulators?
Legal & regulatory triggerWhat obligation starts the clock on notification, and who tracks it?
Technical-business handoffWhere does the technical team's authority end and leadership's begin?
Post-incident reviewWho confirms the plan actually gets updated once the dust settles?

Working process

Name the authority before the pressure arrives.

Name who can declare an incident
A specific role, not "whoever notices first" - with a clear path to reach them.
Pre-agree negotiation and payment authority
Decide who can authorize that conversation now, not while it's actively happening.
Assign the single communication owner
One person controls the message, so customers and staff hear one consistent account.
Set the post-incident review
A committed step that turns what happened into an updated plan, not just a closed ticket.

This plan is the other half of a well-sequenced security budget

Hypothetical pattern

A ransom note at 6 a.m., and three people who think they're in charge

IT wants to isolate every affected system immediately. Operations wants to keep the business running through the morning. Nobody is sure who can authorize contacting an external negotiator, or approve any payment discussion at all, so precious hours go to arguing about authority instead of using it. The names were never agreed before this happened - the point of the plan is that this time doesn't have to repeat.

See how recovery capability itself gets decided

Next step

Bring the plan that only covers the technical response.

A focused brief can turn a technical playbook into a named decision authority, a communication owner, and a post-incident review.

Build the decision plan

A technical playbook answers "what do we do." It rarely answers "who decides."

Call it an incident, not a glitch

Authorize the hard trade-offs

Control what gets said, and to whom

Declare it over, and capture the record

Name who can declare an incident

Pre-agree negotiation and payment authority

Assign the single communication owner

Set the post-incident review

A ransom note at 6 a.m., and three people who think they're in charge

Bring the plan that only covers the technical response.

Get IT decisions made, and made to stick.

Related services