Writing an Incident Response Plan Your Team Will Actually Use

The plan no one opens

Almost every organization we work with has an incident response plan. Far fewer have one that anyone could follow under pressure. The document exists — usually a long PDF in a shared drive, written to satisfy an auditor or a customer's security questionnaire — but when something actually goes wrong, the people in the room don't open it. They improvise, send a flurry of panicked messages, and try to remember who has the keys to the firewall.

That gap between having a plan and using a plan is where most of the real damage happens. The first hours of an incident are when good decisions matter most and clear heads are rarest. A plan written to be read calmly months later is not the same as a plan written to be used at 2 a.m. by a stressed engineer who has never handled a breach before.

This post is about closing that gap — not the compliance-theatre version of incident response, but the working version: short enough to act on, specific enough to remove guesswork, and tested enough that your team trusts it.

Write for the worst day, not the audit

The single biggest design choice is who the plan is for. An audit-driven plan is written for an outside reader who wants to confirm a process exists. A usable plan is written for an insider who is mid-crisis and needs to know what to do in the next ten minutes. These are different documents, and trying to make one serve both is why so many plans end up unusable.

Optimize for the worst day. That means assuming the author isn't in the room, the usual systems may be down, and the person reading it is scared. Plain language wins over policy prose. A checklist beats a paragraph. A phone number beats a job title.

• Keep the operational core short — a few pages someone can act on, not a treatise. Background, scope, and legal context can live in appendices.
• Lead with action. The first page should answer 'what do I do right now and who do I call', not 'the purpose of this policy is...'.
• Assume degraded conditions. If the plan lives only on the network that's under attack, it's useless. Keep an offline copy and a printed one.
• Use names and numbers, not just roles. 'Page the on-call security lead' fails when no one knows who that is tonight. A current contact does not.

Define roles before you define steps

Incidents go sideways when everyone assumes someone else is handling something. Before you write a single procedure, decide who fills which role and make sure those people know it in advance — not in the middle of a breach.

You don't need a large team. Even a small startup can name these roles, and one person can hold more than one as long as the assignment is explicit. What matters is that when an incident is declared, there is no debate about who decides, who fixes, and who talks.

• Incident lead: declares the incident, owns the decisions, and keeps the timeline. This person coordinates — they don't have to be the most technical.
• Technical responders: the people who can actually contain and investigate. List who covers each major system and how to reach them after hours.
• Communications owner: drafts internal updates, customer messaging, and any public statement. Silence and mixed messages both erode trust.
• Legal and privacy contact: assesses notification obligations and regulatory exposure. For Canadian organizations this is where PIPEDA, PHIPA, provincial privacy law, or Quebec's Law 25 obligations get triggered.
• Executive sponsor: the person who can authorize spending, approve customer notice, and shield the team from distraction so they can work.

Build severity tiers so people know how hard to run

Not every alert is a crisis, and treating every event like a five-alarm fire burns out your team and trains them to ignore the plan. A clear severity scale tells responders how fast to move, who to wake up, and how far to escalate. It also prevents the opposite failure — quietly sitting on something serious because no one was sure it counted.

Three tiers are usually enough. Define each one by impact, then attach concrete actions and timelines so the tier actually means something operationally.

• Low: a contained, low-impact event — a single phished credential caught early, no sensitive data exposed. Handle during business hours, log it, monitor.
• High: confirmed unauthorized access, malware spreading, or potential exposure of personal or health information. Declare an incident immediately and pull in the response team.
• Critical: active data exfiltration, ransomware encrypting production, or a breach of regulated data at scale. Wake everyone, engage the executive sponsor, and start the notification clock.

Make containment and the notification clock concrete

Two parts of the plan deserve specific, pre-decided detail because they're where teams freeze: how to contain the damage, and when the legal clock starts. Both involve judgment calls you do not want to be making for the first time during the event.

On containment, write down the decisions in advance. Can responders isolate a server or disable an account on their own authority, or do they need sign-off? Waiting for approval while an attacker moves laterally is how a contained problem becomes a company-wide one. Give responders clear, bounded authority to act fast and clean up the paperwork later.

On notification, know your obligations before you need them. Under PIPEDA, organizations must report a breach of security safeguards that creates a real risk of significant harm to the Office of the Privacy Commissioner of Canada and to affected individuals as soon as feasible. Health-information and provincial regimes — PHIPA in Ontario, British Columbia's public-sector privacy legislation, Quebec's Law 25 — carry their own thresholds and timelines. Your plan should name which regimes apply to you and who decides whether a given incident crosses the line. The deep detail on sequencing belongs in our answer on what to do after a data breach; the plan just needs to point there and assign the owner.

Build a simple incident timeline log into the plan itself — a single running record of what was discovered when, what was done, and who decided. Regulators, customers, and your own retrospective will all ask for it, and reconstructing it after the fact from memory and chat logs is miserable and unreliable.

Test it, or it isn't real

A plan you've never exercised is a hypothesis. The only way to know whether your team will actually use it is to make them use it before a real incident does. Tabletop exercises are among the cheapest, highest-return investments in incident readiness — a couple of hours, no production systems touched, and they reliably surface the gaps no review meeting ever will.

Run a realistic scenario and walk through it out loud as a team: ransomware on a file server, a misconfigured cloud bucket exposing customer records, an employee who clicked a credential-harvesting link. Watch where people hesitate. That hesitation is your plan telling you what to fix.

• Run a tabletop at least once or twice a year, and any time your stack, team, or obligations change materially.
• Pick a scenario that fits your actual risk — a SaaS company selling to healthcare should rehearse a health-data exposure, not a generic 'hacker' story.
• Time it. If declaring the incident and reaching the right people takes far too long in a calm room, it'll take longer in a real one.
• Fix the plan after every exercise. Update contacts, clarify the step that confused people, cut what nobody used. A stale plan loses trust fast.
• Keep contact lists current on a schedule. People change roles and phone numbers, and an out-of-date escalation path quietly breaks the whole plan.

From document to reflex

The goal isn't a perfect plan. It's a plan your team reaches for without thinking — short enough to act on, specific enough to remove guesswork, and rehearsed enough to trust. Start small. A two-page operational core with named roles, three severity tiers, and a tested escalation path beats an exhaustive document nobody opens.

If you're standing up incident response from scratch, or you have a plan on paper but no confidence it would survive a real event, that's exactly the kind of work a virtual privacy officer or vCISO does day to day — building the plan, running the tabletop, and being on the line when something breaks. The plan you write today is the calm you'll have on the worst day. Make it one your team will actually use.

Related reading

• What to do after a data breach