Introduction
In a crisis, organisations rarely rise to the level of their intentions. They fall to the level of their preparation.
That phrase sounds like a motivational poster. In practice, it is a diagnosis. I have watched well-governed organisations stumble during incidents not because their technical controls were weak, but because the governance model above the technical layer was unclear. Roles were assumed, not assigned. Decisions were delayed because nobody had clear authority. Notifications missed their windows because the process above the SOC had never been tested.
Incident response is often treated as a security operations topic. It is also a governance topic, a leadership topic, and a communications topic. The organisations that manage serious incidents well have built that model before the incident, not during it.
This article introduces a simple framework for building a response model that holds under pressure. It covers five areas: command, decisions, communications, notification, and learning. It also explains why operational resilience is a different question from recovery, and why preparedness becomes a cultural discipline rather than a compliance deliverable.
The Incident Response Governance Stack
The framework is deliberately simple. In my experience, the organisations that respond best under pressure are not the ones with the thickest incident binder. They are the ones that can explain five things clearly:
- Command — who is in charge and how escalation works.
- Decisions — who can approve what under time pressure.
- Communications — who says what, to whom, and through which channel.
- Notification — how regulatory and contractual reporting obligations are triggered and approved.
- Learning — how the organisation captures lessons and changes the model afterwards.
If one layer is weak, the rest of the response starts to wobble. A technically strong team can still fail if command is unclear. A fast detection capability can still fail if notification approval is slow. A good crisis meeting can still fail if nobody learns from what just happened.
Layer 1: Command — Who Is in Charge
The best time to decide who has authority in a crisis is not during the crisis.
That sounds obvious, but most organisations have never formally answered three questions: who has authority to invoke the response plan, who has authority to make commercial trade-offs under pressure, and who is the final decision-maker when technical teams, legal, communications, and operations all want different things at the same time?
I facilitated a crisis simulation for a logistics firm where the CEO tried to manage technical containment, the CISO was drafting press releases, and legal was nowhere to be found. Everyone was trying to help. Nobody was in command. We stopped the simulation after twenty minutes, redesigned the command structure — gold, silver, bronze, with explicit decision rights and clear escalation paths — and ran it again. The second session was a different experience entirely. The decisions were made faster, the communications were cleaner, and the team felt more in control.
The difference between the two sessions was not technical ability. It was role clarity and a shared mental model of what good crisis management looks like. That is built before the pressure, not under it.
A clear command structure answers the practical question every real incident creates: who is allowed to decide, who coordinates, and who steps in if the primary owner is unavailable?
Layer 2: Decisions — Frameworks Beat Improvisation
In the first hours of a serious incident, the most consequential decisions are usually not technical. They are about coordination, communication, and authority.
During a DDoS attack against an e-commerce client, the technical team wanted to scrub all incoming traffic to stop the attack. The commercial director refused, because scrubbing all traffic would also block legitimate customers during a peak trading period. That was a reasonable tension. Because we had a pre-agreed escalation matrix and a documented decision framework, the CEO made a clear call in five minutes: protect revenue, implement partial scrubbing, accept some risk. Without that framework, the argument could have run for hours.
Decision frameworks do not need to be complex. They need to answer the questions that arise under time pressure: what decisions can the technical team make without escalation, what requires management approval, what requires executive involvement, and who acts if the primary decision-maker is unavailable.
When decision rights are clear, the organisation moves faster. When they are unclear, the response stalls while people debate who is authorised to act.
Layer 3: Communications — The Message Layer Matters
Response plans that only describe technical steps miss the point. The important documentation is not only the technical playbook. It is the communication model around it.
Who needs to be informed, in what order, using which channel? What can be said publicly before legal has reviewed it? What are the pre-approved holding statements for clients, partners, and regulators? Who drafts the internal staff communication and who approves it?
A healthcare client I worked with had a strong technical response capability. The SOC detected a ransomware deployment in ten minutes. But it took thirty-six hours to notify the regulator because legal and communications did not have pre-approved templates, the escalation path above the CISO had never been tested, and the question of who had authority to sign off a regulatory notification had never been formally answered.
The SOC detection was excellent. The communications and governance layer around it was not ready. That gap is where organisations fail, and where regulators focus their questions.
Layer 4: Notification — Deadlines Expose Weak Governance
Short notification windows are not only a compliance challenge. They are a governance test.
NIS2 requires an early warning within twenty-four hours of becoming aware of a significant incident. Under DORA’s incident-reporting rules, a financial entity must submit the initial notification for a major ICT-related incident within four hours after classifying it as major and, in any event, no later than twenty-four hours after detecting it. GDPR Article 33 requires notification within seventy-two hours where a personal data breach is likely to result in risk to individuals.
The problem is rarely that teams do not know the number of hours. The problem is that they do not know who is allowed to approve the communication, where the template is stored, or what happens if the decision-maker is unreachable on a Friday evening.
I ran a simulation for a healthcare client where the SOC detected the threat in ten minutes. Technically, that is strong. But it took thirty-six hours to notify the regulator because legal and communications did not have pre-approved templates, the approval chain above the CISO had never been agreed, and nobody had ever decided who had authority to sign off on a regulatory notification under time pressure.
The gap between good detection and reliable notification is where most organisations discover their weakness. Closing that gap requires clarity on roles, templates that are ready to go, and testing that includes the full approval path.
Layer 5: Learning — Post-Incident Improvement
Incidents do not only test controls. They also test whether the organisation learns.
A mature post-incident model includes root cause analysis that goes beyond the technical trigger. It identifies whether the governance above the response was clear, whether the communication model worked, whether external relationships performed, and whether assumptions in the plan failed to survive contact with reality. Those findings should feed back into the response model, into exercises, and into the risk register.
I worked with a financial services client who had experienced a serious data breach eighteen months earlier. When we reviewed the post-incident actions, we found that the technical remediation had been completed well. But the governance actions — clarifying command authority, strengthening notification procedures, improving regulatory reporting templates — had been deprioritised under operational pressure and were still open. The next incident would have faced the same governance gaps as the first one.
Resilience is not built by responding well once. It is built by learning from incidents consistently, updating the model honestly, and testing the improvements before the next event makes them necessary.
Operational Resilience Is Not Business Continuity
These two concepts are related, but they are not the same question.
Business continuity asks how the organisation recovers after disruption. Operational resilience asks whether critical services can keep functioning through disruption with acceptable impact — and what the organisation can absorb before it cannot.
A bank I worked with had an excellent business continuity plan. If the primary data centre failed, they could fail over to a secondary site within four hours. The plan had been tested, and it worked. But when we modelled a ransomware attack where the backup environment was also encrypted, the plan fell apart. The BC plan assumed IT would be available to execute the recovery. The ransomware scenario removed that assumption.
The shift from business continuity to operational resilience is a shift from can we recover to can critical services keep running under adverse conditions, and how do we know where the limits are? That question sits much closer to customer impact, regulator expectations, and board accountability.
One Thing You Can Do This Week
Before the next incident, test your notification approval chain.
Pick a plausible scenario. Ask your response team: if this happened at 4 PM on a Friday, who would approve the initial regulatory notification? Is that person available? Is there a backup? Is the template ready? Where is it stored if the corporate network is down?
If the answer to any of those questions is uncertain, you have found a gap worth closing. That simple drill often reveals weaknesses that no policy document ever will.
Conclusion and Next Steps
Incident response and crisis management are not purely technical disciplines.
They require governance structures that are clear before the pressure starts, decision rights that are assigned and understood, communication models that have been practised, and leadership teams that have faced the hard trade-offs in a safe environment before facing them in a real one.
If you want a practical starting point, download The Incident Response Governance Stack Playbook. It gives you a readiness canvas, a command and notification checklist, and a prioritised simulation guide you can use before your next exercise or regulatory deadline.
If you want to test your current response model, run a simulation, or strengthen the governance layer above your technical capability, GRC Force can support a focused engagement to get that right.
At GRCForce.com, we would love to help you build the model that holds under pressure — before the pressure arrives.