Building an Incident Response Plan You'll Actually Use

The value of an incident response plan is not the document. It's that a handful of decisions get made calmly, in advance, by people who aren't panicking — because at 2am on a Sunday with systems encrypted, nobody makes good decisions from scratch.

Most small business plans fail for the same two reasons: they're forty pages nobody has read, and they're stored on the file server that just got encrypted. What follows is the version that works.

The one page that matters most

Before anything else, produce a single page and print it. Put copies in the office, at home, and anywhere your key people can reach without a working network.

If you write nothing else, write that. It covers the first hour, and the first hour is where incidents are made better or considerably worse.

Decide these things now

Who has authority to disconnect?

Containment often means pulling systems offline, which means stopping the business. Somebody must be empowered to make that call at 3am without waiting for a meeting. Name them, name their backup, and make sure everyone knows the decision is pre-authorized — hesitation here is measured in encrypted servers.

What does "isolate" concretely mean here?

Not "shut everything down." Disconnect affected machines from the network but leave them powered on — powering off destroys memory-resident evidence that investigators and your insurer may need. Disable compromised accounts and revoke their sessions. Segment the network if you can.

What order does the business come back in?

List your systems and rank them by how long you can genuinely operate without each one. Usually one or two things are truly critical and everything else can wait days. Knowing this in advance stops you from spending the first six hours restoring something that didn't matter.

Who talks, and to whom?

Staff, customers, and vendors will all have questions, and inconsistent answers cause real damage. Name one person who communicates externally. Prepare rough templates now, while you're calm. And tell staff explicitly not to post about it.

The legal clock — Alabama specifics

Alabama's Data Breach Notification Act applies to any business holding personal information about Alabama residents. The obligations that matter:

• Affected individuals must be notified within 45 days of determining that a breach occurred and is reasonably likely to cause harm.
• If more than 1,000 residents are affected, you must also notify the Alabama Attorney General and the consumer reporting agencies.
• You're expected to conduct a good-faith investigation to determine whether harm is likely.

Those clocks start at determination, not at convenience. If you handle healthcare data, HIPAA adds its own separate and stricter requirements, and if you take card payments, PCI DSS adds more. Sort out which regimes apply to you before an incident, not during.

This is also why "we'll just quietly restore and say nothing" is a poor plan — it can convert a security incident into a legal one.

On paying ransoms

Decide your position in advance, with your insurer and attorney, rather than under pressure. Worth knowing going in: payment buys a decryption tool, not a guarantee. Recovery via decryptor is often slow and partial. Payment doesn't undo the data theft that typically happened before encryption, so the extortion may continue regardless. And depending on who the attacker is, payment can carry its own legal exposure.

Tested, isolated backups are what give you the option to decline. That's their real value — not just recovery, but negotiating position.

Testing without disrupting the business

An untested plan is a document, not a capability. You don't need a full-scale exercise.

1. Restore something, quarterly. Pick a file and a mailbox, restore them, and time it. That number is your real recovery time, and it's usually a surprise.
2. Run a tabletop, annually. An hour around a table: "It's Saturday morning, the file server is encrypted and there's a ransom note. What happens now?" Talk it through. The gaps surface fast and cost nothing to find this way.
3. Verify the call list, twice a year. People change jobs and numbers change. A phone number that doesn't work is worse than no plan, because you trusted it.
4. Re-read the insurance requirements annually. Insurers increasingly require specific controls, and a claim can be reduced if your application answers weren't accurate.

Common questions

We're ten people. Isn't this overkill?

The one-page version takes an afternoon and covers most of the value. Smaller businesses actually need it more, because you don't have a security team to improvise with — you have whoever picks up the phone.

Our IT provider handles this, right?

They handle the technical response. They can't decide whether you pay a ransom, who tells your customers, or when you notify regulators. Ask them directly what their response process is, what their guaranteed response time is after hours, and where the boundary sits between their job and yours. Get the answer in writing before you need it.

What single thing helps most?

Backups you've actually restored from, kept somewhere ransomware can't reach. Everything else is faster recovery; that's whether recovery is possible at all. See our security baseline and the domain controller backup challenge for the details that trip businesses up.