Incident response: the plan you hope you never need

The value of an incident response plan is inversely proportional to how often you need it — and directly proportional to how many times you've actually rehearsed it before you do.

Why "we'll figure it out when it happens" is a bad plan

During an actual security incident, decision-making quality drops under stress and time pressure — this isn't a criticism of any specific team, it's a well-documented pattern. Questions that seem simple in a calm planning session (who has authority to take a system offline, who needs to be notified and in what order, what's our legal obligation for breach disclosure and on what timeline) become genuinely hard to answer correctly in the moment if they haven't been decided in advance. A written plan converts these into pre-made decisions you're executing, not decisions you're making for the first time under pressure.

What a real incident response plan actually contains

Beyond generic "detect, contain, eradicate, recover" phase language, we build plans with specifics: named roles with defined authority (who can approve taking a production system offline, and who's their backup if unavailable), a communication tree with actual contact methods (not just names — how do you reach this person if email/Slack might be compromised), a legal and regulatory notification checklist specific to your industry and the types of data you hold, and pre-drafted communication templates for customers, employees, and regulators so those aren't being written from scratch during an actual incident.

The tabletop exercise that reveals the real gaps

We run tabletop exercises — a simulated incident scenario walked through verbally with the actual response team — specifically because this is where plans reveal their gaps. A plan that reads completely coherently often falls apart when someone asks "okay, it's 11pm on a Saturday, who's actually reachable right now" and the honest answer surfaces a real gap in on-call coverage or contact information that was never tested against reality.

A concrete example

For a healthcare services client, our first tabletop exercise simulated a ransomware scenario affecting patient scheduling systems. The exercise revealed that the documented "notify legal counsel immediately" step had no actual current contact information — the plan referenced a law firm relationship that had changed 14 months earlier and nobody had updated the document. It also revealed uncertainty among the response team about whether patient data exposure in this specific scenario would trigger HIPAA breach notification requirements, an ambiguity that needed to be resolved with counsel in advance, not debated during a live incident under a regulatory clock.

Both gaps were closed before the next quarterly exercise, and a follow-up tabletop simulating a different scenario ran through cleanly with no comparable gaps found.

How Ndakum approaches it

Incident response planning is part of our Cybersecurity practice — we build the plan and then schedule the tabletop exercise that actually tests it, because an unrehearsed plan carries more false confidence than value.