Your systems go down on a Tuesday morning. Who is in charge, and does that person have permission to spend money? If you had to stop and think about either answer, you do not have an incident response plan. You have a group of good people who will improvise. An incident response plan is a short written document that settles the human questions before the pressure arrives: who takes charge, who covers when that person is unreachable, who can authorize spending, what comes back online first, what you tell your team and your customers, and how you decide it is over.

I have spent 25 years in technology, and I built Entech into a team. Owners across the Wiregrass, from Dothan and Enterprise out to Southwest Georgia and the Florida panhandle, rarely lose a week to a piece of technology failing. They lose it waiting on a decision nobody had made in advance.

The quick version. An incident response plan is a written set of decisions, not a product you buy. These are the six:

• Incident lead. The one person who takes charge, named on the page with a cell number.
• Backup lead. The person who covers the hours the first one cannot be reached.
• Spending authority. The dollar amount one named person can approve at two in the morning without waking you, and who gets called above it.
• Restore order. Your systems ranked by what the business cannot run without, written down before anyone has to argue about it under pressure.
• Who communicates. One voice for staff and customers, and it is not the person fixing the problem.
• The all clear. What has to be true before anyone gets to say the incident is over.

Why an incident response plan beats improvisation when the turbulence hits

When your flight hits turbulence, the last thing you want to hear over the intercom is the pilot saying “give me a minute, I have never handled this before.” Flying feels safe not because problems never happen. It feels safe because pilots spend thousands of hours preparing for situations they hope they never see. When something goes wrong, the response already exists. All they have to do is run it.

Every profession where mistakes get expensive is built that way. Medicine. Emergency response. Manufacturing. The emergency is when you execute the plan. It is not when you write the plan.

Most small businesses have not made that distinction yet. They bought good tools, turned on the alerts, and stopped there. Preparation ended at setup instead of reaching the part that decides the outcome, which is how people behave in the first hour. The same thing happens to backups, where a setup that worked once quietly becomes a belief nobody has checked. That gap stays invisible until something breaks. Then it shows up all at once, in front of customers.

Who takes charge, and who is allowed to spend money?

An incident response plan starts with a name. One person is the incident lead. One named person is the backup for the day the first one is on a plane or standing at a ball field. Put cell numbers on the page. “IT will handle it” is not a name, and neither is a department.

The second half of that decision is the half almost everybody skips: money. At two in the morning somebody may need to approve an emergency replacement, a rush shipment, or outside help. If your office manager has to guess whether a purchase will get them in trouble, the business stops moving while everyone waits for you to wake up. Write down a dollar figure a named person can approve without asking permission. Write down who to call above that figure, and what happens if they do not answer within fifteen minutes.

One more role belongs on the page: the person who talks. Communication comes from a single voice, and that voice should not belong to whoever is elbow deep in the technical work.

What gets restored first? Rank it before you need it

Restore order is a business decision, and by default it gets handed to a technician at the worst moment. Do not do that to them. Sit with your leadership team on an ordinary afternoon and rank your systems by what the business cannot function without, not by what is quickest to bring back.

For most small businesses around here, the top of that list rhymes. Phones. Email. The line of business application that takes orders or schedules the work. Payroll. Then everything else. Your list will be yours, and honestly the argument you have building it is most of the value. Better to have it in a conference room than at 7 a.m. with three customers on hold.

Write the order down and keep it with the plan. Note which systems depend on others, because the accounting software that needs the file server is not coming back first no matter how loudly accounting asks. A disaster recovery test is what tells you whether the order you wrote down survives a real restore. Mapping that chain before anything breaks is exactly the kind of work our managed IT services team does.

What do you tell your team and your customers, and when?

Communication is the piece owners regret most, and the cheapest to prepare. Your staff finds out first, because they are the ones answering the phone. Give them one short script and one boundary: here is what you can say, here is what you forward to the person who talks. People fill silence with guesses, and guesses travel fast in a small town.

Customers come next. Draft the holding statement now, because nobody writes well at 7 a.m. with the phones lit up. It needs three things: what you know, what you are doing about it, and when you will update them again. That third piece is the one everybody forgets, and the one that buys you patience. It is also the only honest answer to how long will this take, which somebody asks inside the first ten minutes. You will not know yet, so give a time you will know more instead of a time you will be back. A guess that slips costs you more trust than the outage does. Then keep the promise, even when the update is “still working, next update at three.”

One practical detail. Decide where you communicate if email itself is down. A text thread, a printed phone list, a group chat on personal phones. If your only channel is the system that just failed, you do not have a communication plan.

How do you decide the incident is actually over?

“All clear” needs criteria, or the incident just fades out and nobody is sure it ended. Write down what has to be true before anyone says the words. Systems verified by the people who use them every day, not by a dashboard that says everything is fine. Passwords rotated on any account that could have been exposed. Access reviewed, with anything that should not exist removed. That last step runs on the same discipline as a good employee offboarding checklist, because stale access is how a solved problem walks back in the door.

Then hold a short debrief while it is fresh. What worked, what took too long, what was missing from the page. Update the document that same week or it will not happen at all. The damage almost always compounds in one place, the gap between when something starts and when somebody contains it, and that gap is made of unanswered questions. Closing them in writing is cyber security work, even when it looks like paperwork.

Your incident response plan, one page, this week

You do not need a binder. A binder is a coaster. Open a blank document this week and fill in six lines: incident lead, backup lead, spending authority and dollar limit, restore order, who communicates, and what has to be true before you call it over. Print it. Put a copy at the office, one at home, and one in the truck, because a plan that only lives on the network disappears the moment the network does.

That is the free step. It costs nothing and takes twenty minutes. Do it before you buy anything or hire anybody.

Half a page beats no page, and half a page is enough to work from. Schedule a free 10-minute IT assessment, no obligation. We read what you have, tell you honestly where the holes are, and what we would fix first if it were our business. Whether you are here in Dothan or three counties out, that is a good ten minutes to spend.