From Reactive to Prepared: Six Things Your Incident Response Plan Has to Cover
FromReactiveToPrepared

From Reactive to Prepared: Six Things Your Incident Response Plan Has to Cover

Most incident response plans fail for a boring reason. The plan is a Word file on the server that just went down. That is the test for everything below. If your plan can't be read and acted on while your network is offline, it isn't finished yet. Here are the six things it has to cover, and what each one looks like when it actually works.

Center Street I.T. Team
September 1, 2026
5 min read
Article Content

Most incident response plans fail for a boring reason. The plan is a Word file on the server that just went down.

That is the test for everything below. If your plan can't be read and acted on while your network is offline, it isn't finished yet. Here are the six things it has to cover, and what each one looks like when it actually works.

1. Who makes the call

The first twenty minutes of an outage get spent figuring out who's in charge, unless that's already written down.

Four decisions need an owner by name, not by department:

  • Who decides whether to shut systems down
  • Who calls the insurance carrier
  • Who talks to employees
  • Who talks to customers and vendor.

Name the person and name a backup. "The office manager" is not an owner when the office manager is on vacation. When two people think they own the same call, you get duplicate effort in one place and silence in another.

2. A contact list that works with the network down

Your contact list is worthless if it lives in Outlook and Outlook is part of the problem.

The list needs your leadership team, your IT provider, your cyber insurance carrier's incident hotline, your bank, your legal counsel, and any vendor whose system you can't operate without. Print it. Put a copy in the shop office, a copy at home, and a photo of it on two or three phones.

Then check it. An outdated cell number for the one person who can authorize a shutdown will cost you an hour at the worst possible time.

3. The carrier gets called before anyone starts working

This one costs businesses real money and almost nobody knows it going in.

Most cyber policies require you to notify the carrier before response work begins, and many will only pay for firms on their approved panel. If you call us first and your carrier second, the carrier can decline to cover the hours we already spent. We would rather you make the right call than the fast one.

Pull your policy out and read the notification clause before you need it. Write the hotline number, the policy number, and the notice deadline on the same printed page as your contacts.

4. What comes back first, and how long you can actually live without it

Not every system is worth the same downtime. Trying to restore all of them at once means everything comes back slowly.

Rank your systems into three groups: the ones that stop you billing or shipping within an hour, the ones you can work around for a day, and the ones that can wait a week. Then put an honest number on the top group. If accounting can't invoice for four hours, say four hours. That number is what drives the backup design, and if you've never stated it, nobody has ever designed against it.

Most owners find at least one surprise here. A system nobody thought about turns out to be sitting in front of everything else.

5. The first hour, including what not to do

People need something they can follow while their pulse is up. Keep it short enough to read on one page.

The actions worth writing down:

  • Isolate the affected machine from the network rather than wiping or rebuilding it. Rebuilding destroys the evidence your carrier and any investigator will ask for.
  • Stop the spread. Pull the network cable, turn off the wireless, disconnect the backup target if it's still mounted.
  • Call the carrier, then call us.
  • Write down what you saw and when you saw it. Times matter later.
  • Don't pay anything, don't reply to anything, and don't negotiate. That decision belongs to the carrier and to counsel.

None of that requires technical skill. It requires knowing it in advance.

6. A date on the calendar

A plan that has never been tested is a guess with a cover page. Testing is what tells you the backup won't restore clean, or the phone tree has a dead number in it, or the restore your provider quoted at two hours takes nine.

Once a year, sit down for an hour and walk through a scenario out loud. Update the contact list every time someone leaves. Rerun the test any time you change a core system or swap a vendor. Every problem the test finds is a problem you didn't find during a real outage.

Where to start

You don't need a binder. One printed page with names, numbers, priorities, and the first five steps beats a forty-page document nobody has opened, and you can write it this week.

If you'd like a second set of eyes on your plan, or you don't have one yet, [book a 10-minute call] and we'll walk your list with you and tell you straight where the holes are.

Found This Article Helpful?

Stay updated with our latest IT insights and solutions.

Reading...