What an incident response plan actually is
An incident response plan is a written, tested set of decisions made in advance, so that when something goes wrong your people are executing rather than improvising. It names who decides, who calls whom, what gets disconnected, what gets preserved as evidence, and how you tell customers.
The value is almost entirely in having made those decisions before the pressure arrives. Every organisation intends to respond well. The ones that actually do are the ones that wrote it down and practised it.
Think your IT is in good shape?
Take the free 3-minute readiness quiz
The model changed in 2025, and most guidance has not caught up
For two decades the standard reference was NIST SP 800-61 Revision 2, which described a four-phase lifecycle: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. That is the model behind almost every incident response article you will find, including the earlier version of this one.
On 3 April 2025, NIST published SP 800-61 Revision 3, which supersedes Revision 2. Instead of a standalone lifecycle, incident response is now expressed through the six Functions of the NIST Cybersecurity Framework 2.0. The point of the change is that incident response is not a separate activity that begins when an alarm sounds. It is part of how an organisation manages cybersecurity risk continuously.
The six Functions are Govern, Identify, Protect, Detect, Respond and Recover. The first three shape your readiness. The last three are what happens during and after an incident. All six matter before anything goes wrong.
Govern
Decide who owns incident response and what authority they hold. This is the Function most small businesses skip, and skipping it is what turns a two-hour outage into a two-day one.
Name a single person who can declare an incident, and a deputy for when they are unreachable. Write down who is permitted to authorise disconnecting a system, taking a site offline, or paying an external responder. Establish in advance who talks to customers, who talks to the insurer, and who talks to law enforcement. If those decisions have to travel up a chain on a Saturday, the outage lasts as long as the chain does.
Identify
You cannot protect or recover what you do not know you have. Maintain an inventory of systems, data, and the third parties who can reach them. Know which systems the business genuinely cannot run without, and for how long.
This is also where you record your recovery targets. How much data can each system afford to lose, and how long can it be down. Without those two numbers the rest of the plan has nothing to aim at.
Protect
Multi-factor authentication, least-privilege access, patching, segmentation, backups that ransomware cannot reach. None of this is incident response in the narrow sense, but it determines how bad an incident becomes. Most of the difference between a contained event and a company-wide crisis is decided here, weeks before anything happens.
Detect
An incident you do not notice is an incident that continues. Continuous monitoring, alerting that a human actually reviews, and a route for staff to report something odd without feeling foolish. A great many intrusions are first noticed by an employee who thought a login prompt looked wrong.
Respond
When an incident is declared: contain it, understand it, preserve what you will need later, and communicate.
Containment is a judgement call, not a reflex. Pulling the plug stops the spread and can also destroy the evidence you need for an insurance claim or a regulatory notification. Isolate rather than wipe, capture logs and memory before rebuilding, and keep a timestamped record of every action taken.
Communication is part of response, not an afterthought. Regulatory notification clocks start running at defined moments, and several of them are shorter than most businesses expect.
Recover
Restore in a planned order, verify systems are clean before reconnecting them, and confirm with the business that things genuinely work rather than assuming they do. Then hold a review while memory is fresh, and change the plan based on what you learned. A plan that is never revised after a real incident was not a plan, it was a document.
What to do in the first hour
The plan should make this boring, but here is the shape of it:
- Declare. Somebody with named authority says the word “incident”. Ambiguity costs more time than any technical step.
- Assemble. A short call with the people who can act, not everyone who is interested.
- Contain, carefully. Isolate affected systems from the network rather than powering them off, so volatile evidence survives.
- Preserve. Logs, memory captures, and a written timeline started immediately.
- Notify the insurer early. Many cyber policies require prompt notification and the use of approved vendors. Calling your own responder first can jeopardise the claim.
- Check obligations. Notification duties vary by state, sector and contract, and some are measured in hours.
Where to report an incident
Reporting is not only a legal obligation, it also gives you access to help.
- CISA receives reports from organisations of any size and publishes advisories and free resources.
- The FBI Internet Crime Complaint Center is the reporting route for cybercrime, and prompt reporting can meaningfully improve the odds of recovering fraudulent wire transfers.
- Sector regulators may impose their own timelines. Healthcare organisations should check HHS breach notification requirements.
What the written plan should contain
Keep it short enough that somebody can act from it at two in the morning. A plan nobody can navigate under pressure is a compliance artefact, not a control.
A severity scale. Three or four levels, each with a plain description and a defined response. Without one, every event is either ignored or treated as a catastrophe, and both are expensive. A single phished mailbox and a domain-wide ransomware event should not trigger the same call tree.
A contact tree that works offline. Names, mobile numbers and backup contacts for internal decision-makers, your MSP, your insurer’s incident hotline, your legal counsel and your bank. Printed, and stored somewhere other than the systems that might be down.
Per-system recovery targets. How much data each system can afford to lose and how long it can be unavailable. Written down, agreed with the people who own those business processes rather than assumed by IT.
A recovery order. Which systems come back first. Identity and network almost always precede applications, because bringing up a file server nobody can authenticate to achieves nothing.
Evidence handling instructions. What to capture before rebuilding, and who to hand it to.
Communication templates. Draft holding statements for staff, customers and, where relevant, regulators. Writing these calmly in advance produces far better results than drafting them during the event.
Test it, or you do not have one
A plan that has never been exercised is a hypothesis.
The cheapest useful test is a tabletop: gather the people named in the plan for ninety minutes, describe a scenario, and talk through who does what. It requires no technology and it reliably surfaces gaps that no amount of writing will, usually in the first twenty minutes. The most common discoveries are that the named decision-maker has left the business, that nobody knows the insurer’s notification number, and that two people each assumed the other was responsible for calling customers.
Run one annually at minimum, and after any significant change to your environment or your team. Pick a scenario that is plausible for your business rather than a dramatic one. Ransomware arriving through a phished account on a Friday afternoon teaches more than a nation-state attack nobody believes in.
Then actually test a restore. Recovery assumes something to recover from, and an untested backup is a hope rather than a control.
Frequently asked questions
How long does it take to write an incident response plan?
For a small business, a workable first version takes days rather than months, most of it spent agreeing decision authority and recovery targets rather than writing. The perfect plan you never finish is worth less than the adequate plan you have.
Do we need one if we use a managed provider?
Yes. Your provider handles the technical response, but the decisions that matter most in the first hour are business decisions: whether to take a system offline, what to tell customers, when to notify the insurer. Those are yours. The plan is where you and your provider agree in advance who does which.
Does cyber insurance require an incident response plan?
Increasingly, applications ask about it, and answers are treated as warranties rather than estimates. Many policies also require you to use their approved responders, which is why notifying the insurer before engaging anyone else matters.
Should we ever pay a ransom?
That is a business and legal decision, not a technical one, and it should be discussed with counsel and your insurer before you are ever in the position. What the plan should settle in advance is who is authorised to make the call.
How often should the plan be updated?
At least annually, after every exercise, after every real incident, and whenever the environment or the people named in it change. A plan naming someone who left two years ago tells you how current the rest of it is.
The mistakes we see most
The plan exists but nobody has read it. A document in a folder nobody can find during an outage is not a control.
It has never been exercised. A tabletop walkthrough once a year finds gaps that no amount of writing will.
It assumes systems that may be unavailable. If the plan lives in the file share that ransomware just encrypted, or the contact list is in the email system that is down, the plan does not exist during the event it was written for. Keep an offline copy.
No decision authority. Covered above, and worth repeating, because it is the single most common gap we find.
Backups have never been restored. Recovery assumes something to recover from. An untested backup is a hope.
How Corporate Technologies helps
We have supported business IT since 1981 and run 24/7 monitoring and a US-based help desk for clients across 21 markets in 18 states. On incident response specifically we build the plan against your actual environment rather than a template, document recovery targets per system, test restores rather than assuming them, and are on the call when something happens.
If you would rather find the gaps in a meeting than during an incident, contact us or call 1-866-363-4628.
Sources
This page is general guidance and not legal, regulatory or insurance advice. Standards, rules and reporting obligations change, and the requirements that apply to your business depend on your sector, your contracts and your location. Corporate Technologies helps clients meet their own obligations and does not represent that it holds any particular certification unless stated. Confirm current requirements with your legal, compliance and insurance advisers.
