Writing an Incident Response Plan You'll Use

An incident response plan is muscle memory, not paperwork

Most organisations write an incident response plan to satisfy an auditor, file it, and never look at it again. Then a real incident hits, the document is nowhere to be found, and people improvise under stress. A plan that works is short, specific, and rehearsed. It exists to remove decisions from the worst moment to make them, so that when something breaks, your team executes instead of debating.

The goal is not a comprehensive treatise. It is a runbook a tired engineer can follow at 2am without thinking too hard.

Define what counts as an incident

Ambiguity kills response time. If nobody is sure whether a slow server or a suspicious email qualifies as an incident, the response stalls while people argue about severity. Write down clear triggers and a simple severity scale.

• SEV1 — active breach, data exfiltration, or a customer-facing outage. All hands, immediately.
• SEV2 — contained threat or degraded service with a workaround. Urgent, but not panic.
• SEV3 — suspicious activity needing investigation, no confirmed impact yet.

Tie each level to a response time and an escalation path. The point is that anyone who notices something can classify it in seconds and know who to call.

Name roles, not just tasks

During an incident, the most common failure is everyone assuming someone else is handling the critical thing. Assign roles explicitly. You need an incident commander who owns decisions and coordination, a technical lead who drives the actual remediation, and a communications lead who keeps stakeholders and, where relevant, customers informed. In a small team one person may wear two hats, but the roles still need to be named so nobody falls through the gap.

Crucially, the incident commander does not have to be the most senior person. They have to be the person who keeps a clear head and stops the response from sprawling.

Write the steps for the incidents you'll actually face

Generic advice like contain, eradicate, recover is true but useless under pressure. Instead, write concrete playbooks for your three or four most likely scenarios: a compromised email account, a ransomware detection, a lost or stolen laptop, a leaked credential. For each, list the exact first five actions. For a compromised account that might be: reset the password, revoke active sessions, check mailbox rules for forwarding, review recent sign-ins, and notify the user through a separate channel.

Specificity is what turns a document into a tool. The more decisions you pre-make, the faster and calmer the real response.

Keep contact details current and reachable

A plan that lives only on the file server you cannot reach during an outage is no plan at all. Keep an offline copy, and keep the contact list current: internal escalation, your IT provider, your cyber-insurance hotline, and legal counsel if a breach triggers reporting obligations. In India, certain incidents carry reporting timelines under CERT-In directions, so knowing who notifies whom, and by when, belongs in the plan rather than in someone's memory.

Decide how you'll communicate before the panic

Communication failures make incidents worse. Decide in advance what you say internally, what you say to customers, and through which channel, because if your email or chat system is itself compromised, you cannot use it to coordinate the response. Have an out-of-band option ready, such as a separate messaging group or even a phone tree, so the response team can talk privately. Draft holding statements ahead of time for the scenarios you can anticipate, so the communications lead is editing a template under pressure rather than writing from a blank page. Silence and contradictory messages erode trust faster than the incident itself, so a steady, honest cadence of updates is worth planning for.

Preserve evidence while you respond

In the rush to restore service, it is tempting to wipe and rebuild immediately. Resist that until you have captured what you need. If you may have to report the incident, pursue legal action, or simply understand how it happened, you will want logs, disk images, and a record of what you did and when. Note the time of each action you take, preserve relevant logs before they roll over, and avoid powering off a machine in a way that destroys volatile evidence if forensics may be required. A small amount of discipline here is the difference between learning from an incident and being condemned to repeat it.

Rehearse, then revise

The first time you run the plan should not be during a real incident. Run a tabletop exercise once or twice a year: walk a scenario through, see where people hesitate, and fix the gaps. Every real incident is also a free lesson, so hold a blameless review afterwards and update the document. A plan that never changes is a plan nobody is using.

How BSH can help

BSH Technologies helps teams build incident response plans that fit how they actually operate, then runs tabletop exercises so the plan is tested before it is needed. If your current plan is a binder nobody has opened, we can turn it into something your people will reach for instinctively.