Incident response is the written plan a business follows in the hours after a security problem is discovered — who to call, what to isolate, what to preserve, and in what order. It is a checklist, not a technical discipline, and a small business can write a usable one on a single page.
The worst time to figure out what to do about a breach is during one. Panic leads to mistakes — wiping evidence, missing infected systems, or announcing something before you understand it. A simple, written plan replaces panic with a sequence, and that difference can save your business. Here is what a practical plan looks like, and what to do when the clock starts.
Knowing sooner is most of the fix. For vulnerabilities already known to be under active attack, Verizon's 2026 report puts the median time to full resolution at 43 days. Most of that window is not repair time — it is the time before anyone notices.
Figure verified 31 July 2026. Source linked above.
What should you do in the first hour?
Confirm and contain. Nothing else. Slow down long enough to establish that something real is happening — an alert, a ransom message, a customer saying your invoices look wrong — and then limit how far it can travel. Disconnect the affected machines from the network and from any shared drive or cloud sync, and reset the passwords on the accounts that control everything else, starting with email.
Two instincts are worth resisting. Do not power those machines off if you can avoid it: a running system holds the record of what happened, and shutting it down can erase the very evidence that tells you later how far the problem reached. And do not announce anything yet beyond the handful of people who need to act, because statements made in the first hour are usually wrong and correcting them costs more than the wait would have.
Start a written log immediately — times, actions, decisions, and who made them.
What are the six phases of incident response?
Six, and the first one happens before anything goes wrong. Naming them turns a difficult morning into a sequence you work through in order rather than a problem you have to solve from scratch.
- Prepare. Write down who to call, where the backups live, and how to reach people if email is unavailable. This is the phase that makes every other phase work.
- Identify. Confirm something real is happening and scope it: which systems, which data, and how it got in. Do not act on a hunch, but do not dismiss a warning sign either.
- Contain. Isolate the affected systems so the problem stops spreading, while preserving logs and leaving machines running.
- Eradicate. Remove the threat and close the door it came through, whether that is malicious software, a compromised account, or an unpatched weakness.
- Recover. Restore from clean, verified backups and bring systems back gradually, watching for signs the problem lingers.
- Learn. Hold a blameless review of what happened and what you will change.
How should the first 24 hours be paced?
In three bands, each with a different job. What you avoid in each band matters as much as what you do, because a good deal of the damage that follows an incident comes from well-meant moves made too early. The table below is short enough to keep beside the phone list.
| Window | What to do | What not to do |
|---|---|---|
| Hour 0–1 | Confirm it is real, disconnect affected systems, and open a written log | Do not power machines off, reinstall them, or tell anyone outside the response group |
| Hour 1–4 | Call your IT provider, insurer, and legal counsel; reset email and administrator passwords | Do not pay or reply to a ransom demand on your own, and do not guess at the cause |
| Hour 4–24 | Scope which data was touched, restore from verified backups, and draft any required notice | Do not restore onto a system whose entry point is still open, or declare it over early |
Which mistakes turn a bad day into a worse one?
Almost all of them come from moving faster than your understanding. Four are worth naming in advance, because they are the ones a calm plan prevents.
- Wiping and rebuilding before you know how it got in. A clean reinstall on an unchanged entry point simply resets the clock, and the record of what happened is gone with it.
- Calling for help late. Your IT provider, your insurer, and your lawyer all work better with a partly contained incident than a fully explained one, and some insurance policies require early notice.
- Deciding about a ransom demand alone. Payment is a legal and financial question as much as a technical one, and it belongs with counsel and your insurer.
- Losing the timeline. Notification rules and insurance claims both depend on knowing when you learned what, so the log matters long after the incident closes.
The businesses that recover fastest are not the ones that avoid incidents. They are the ones that rehearsed for them.
What belongs on a one-page plan you write today?
Names, numbers, and locations — the things you will not be able to look up calmly later. Keep it to one page, print it, and give a copy to everyone who might be the first to notice something.
List your internal decision-maker and a deputy, your IT provider, your insurer and policy number, your legal contact, and a specialist response firm if you have one on retainer. Record where your backups live, who can restore them, and when they were last tested by actually restoring a file. Add a way to reach the team that does not depend on company email — a phone tree is enough.
Then write down the two decisions people always stall on: who is allowed to disconnect a system without asking, and who speaks to customers. Review the page once a year, and walk through one imagined incident out loud. That rehearsal is the whole return on the exercise.
The bottom line
A one-page incident-response plan, printed and shared before you need it, is one of the least expensive and most valuable steps a small business can take. Prepare now, so a bad day stays a bad day.