An incident response plan is a short document that says who to call, who decides, and what gets done in the first hour when something goes wrong. For most small and mid-sized businesses the useful version is one page of roles and phone numbers plus three or four short runbooks for the scenarios you are most likely to face. A fifty-page plan nobody can find at 2am is not a plan.
The test is simple. Hand your document to the person most likely to notice a problem first and ask them what they would do. If they cannot answer in thirty seconds, the plan needs rewriting rather than extending.
Incident response plan vs disaster recovery plan
These get conflated constantly, and the distinction decides what goes in which document.
| Incident response plan | Disaster recovery plan | |
|---|---|---|
| Question it answers | Something bad is happening — who decides and what do we do now? | Something is down — how do we get it back? |
| Typical trigger | Suspected breach, account compromise, ransomware, data exposure, fraud | Hardware failure, hosting outage, data loss, site destruction |
| Core content | Roles, severity levels, escalation, communications, notification obligations | Recovery targets, backup locations, restore steps, failover order |
| Who leads | An incident lead, usually a business decision-maker | Whoever runs technical operations |
| Output | Containment, decisions, notifications, a written record | Services restored and data recovered |
They overlap in the middle, because a ransomware event is both. The practical approach is to keep them as separate documents that reference each other, with the incident response plan naming the point at which recovery procedures are invoked. NIST's incident handling guide, Special Publication 800-61, draws the same line between handling an incident and recovering from it.
The five parts your incident response plan needs
1. Severity levels with a decision attached
Three levels is enough. What matters is that each level triggers a specific action, not just a label.
A Sev 1 means customer data may be exposed, systems are compromised, or operations have stopped. It wakes people up, pulls in outside help, and starts the notification clock.
A Sev 2 means a contained problem with no confirmed data exposure. Handled in business hours by the owning team with the incident lead informed.
A Sev 3 is a near miss or a single-user issue. Logged, reviewed at the next meeting, no escalation.
Write two or three concrete examples under each level drawn from your own business. Abstract definitions get argued about during the one moment you cannot afford an argument.
2. Named roles, not job titles
Four roles cover almost every situation, and one person can hold two of them in a small business.
The incident lead declares the severity, makes the calls, and owns the timeline. This is a decision-making role, so it belongs to someone with authority rather than to the most technical person.
The technical lead investigates and contains. They should not also be the one fielding customer calls.
The communications owner handles what goes to customers, staff and anyone else. One voice only.
The scribe keeps the timeline. This role gets skipped and it is the one you will regret most, because the written record is what you need for insurance, notification and the review afterwards.
List a primary and a backup for each, with mobile numbers. Phone numbers in a document stored only on the system that is down are not phone numbers.
3. The first-hour checklist
This is the part people actually use. Keep it to a single page.
- Write down the time and what you observed. Start the timeline before anything else.
- Call the incident lead. Do not investigate alone first and report later.
- Assign the severity. When unsure, go one level higher and downgrade later.
- Contain without destroying evidence. Isolate affected machines from the network rather than wiping them. Disable compromised accounts and revoke their active sessions rather than deleting the accounts.
- Preserve what you can. Export logs before retention windows roll over. Many businesses discover their log retention is shorter than the time it takes them to notice an incident.
- Decide on outside help. Your cyber insurance policy may require you to use their panel of responders, and calling someone else first can affect coverage. Know this before you need it.
- Say nothing externally until the communications owner has a line. Early speculation becomes a problem later.
- Check your notification obligations. Contracts and regulations both have clocks, and they start earlier than people assume.
4. Notification obligations, written down in advance
This is the section that takes research once and saves you during the event.
Your contracts contain breach notification windows you agreed to, often expressed in hours. Pull them out now and list them by customer. Privacy regimes impose their own timelines, including the GDPR's requirement to notify a supervisory authority within 72 hours of becoming aware of a personal data breach in scope. US state breach notification laws vary by state and many sector regulators add their own. Your cyber insurer will also have a notification requirement in the policy.
List every applicable obligation with who it goes to, the window, and the route. Do not try to determine during an incident whether something is reportable. Decide the criteria in advance and apply them.
5. The post-incident review
Schedule it within two weeks, keep it blameless, and produce three outputs: a corrected timeline, a short list of what to change, and new or updated rows in your risk register.
The review is also where you check whether the plan itself worked. If people did not follow it, find out whether that is because it was wrong or because it was unfindable.
Test it with a tabletop
A tabletop exercise is a conversation, not a technical drill. Book ninety minutes, put the people with the named roles in a room, and read out a scenario. Then work through it decision by decision.
Use scenarios you are actually exposed to. A finance email requesting an urgent payment change. A laptop stolen from a car. A notice from a vendor that they have had an incident affecting your data. An employee reporting that a client file went to the wrong recipient.
Run one or two a year and write down what broke. In practice the same four things break: nobody knows who declares severity, the contact list is out of date, log retention is shorter than expected, and nobody has read the contractual notification terms. All four are fixable on a quiet afternoon.
Mistakes that make a plan useless
Storing it only where the incident would make it unreachable. Keep an offline copy and a printed copy with the contact list.
Writing for a team you do not have. If you have four people, do not write a plan requiring a security operations center.
Skipping the scribe. Reconstructing a timeline from memory a week later is painful and weakens every downstream conversation.
Treating containment as resolution. Stopping the bleeding is not the same as knowing what happened or meeting your obligations.
Never testing it. An untested plan is an assumption. The tabletop is the cheapest control in this entire article.
Leaving the insurer out. Read the notification and panel-responder terms in your cyber policy before an incident, not during one.
Start smaller than you think
Write the one-page role and contact sheet today. Add severity definitions and the first-hour checklist this week. Pull your contractual notification windows this month. Run a tabletop this quarter.
That sequence gives you a working plan inside a month, and it is the version that holds up both in a real event and in a customer review, because it describes something your business can genuinely do.
To work through severity levels, roles and notification obligations against your own contracts, start with the Risk Management capability page on this site.