The incident response plan a small business will actually use

A written incident response plan is now a standard line on cyber insurance applications, on client security questionnaires, and among the elements the FTC Safeguards Rule lists for the firms it reaches. So plans get written. Most of them are twenty pages of general theory, and almost none of them get opened on the day they are needed, because the day they are needed nobody has twenty pages of attention to spare.

The test for a small firm’s plan is not whether it is thorough. It is whether a stressed person who did not write it can follow it at 2am on a Sunday. That test rules out a great deal of what usually goes in.

What actually has to be in it

Six things carry almost all of the value. If a plan has these and nothing else, it is a good plan:

• Who decides. One named person who can declare an incident and authorise spending money, and a named deputy for when the first person is on a plane. Not a committee — the most common failure in a small firm is not a wrong decision but nobody feeling entitled to make one.
• Who gets called, in order, with the numbers — and a copy of that list somewhere that does not depend on the systems that may be down. A contact list living only in the email account you have lost is not a contact list.
• The first hour. Contain rather than clean up: isolate affected devices, do not wipe or rebuild them, change credentials from a device you trust, and write down what you saw and when. Wiping the machine destroys the evidence that later establishes what actually happened and whether anyone’s data left.
• How you decide how bad it is. What information was involved, whose it was, and whether it was encrypted — because those three answers, not the general sense of alarm, are what decides who you have to tell.
• The clocks, and who owns each one. Notification deadlines start on discovery and run in parallel, which is the part people get wrong.
• How you get back to work, and what you do afterwards. Which systems come back first, restoring from a backup you have actually tested, and a short written note of what happened and what changed as a result.

The call most owners make in the wrong order

The instinct on discovering an incident is to call whoever normally fixes the computers and get on with it. If you hold cyber cover, that instinct can be expensive.

Most cyber policies require prompt notification to the carrier, and many will only pay for forensics, legal advice and breach-notification costs incurred through their own panel of providers, or with their prior agreement. Firms that engaged their usual IT provider for three days and then filed a claim have found those three days were not covered. The carrier’s incident hotline usually belongs near the top of the contact list, above the IT provider, and the plan should say so in a sentence.

The second thing worth pre-deciding is who talks. Staff and clients will ask questions before anyone has real answers, and an early, confident, wrong statement about whose data was affected is difficult to walk back.

The clocks run in parallel

This is the part a general template will not get right for you, because which clocks apply depends on your business and on whose information was involved.

• State breach-notification law. Every state has a statute, and the one that matters is the state each affected person lives in — not where your business sits. So an incident can put you under several at once. Deadlines vary; many states set an outside limit in the range of 30 to 60 days, and several also require a filing with the state attorney general once a threshold number of their residents is involved.
• HIPAA, if it reaches you. A covered entity notifies affected individuals no later than 60 days from discovery, with further filings depending on numbers. A business associate notifies the covered entity it works for — often on a shorter deadline written into the agreement.
• The FTC Safeguards Rule, if it reaches you. A security event involving the unencrypted customer information of 500 or more consumers is reported to the FTC no later than 30 days after discovery. That is shorter than most state deadlines and runs independently of them — meeting a state’s 60-day limit does not satisfy it.
• Your contracts. Client agreements frequently contain notification deadlines shorter than any statute, and they are the ones nobody remembers to check.

One point about the assessment itself, whichever regime you are under: write down the decision even when the answer is that no notification is required. A reasoned, dated note explaining why an incident was not notifiable is a defensible position. The same decision, undocumented, is the one an investigator asks about two years later when nobody can remember the reasoning.

Keep it short, and test one thing

A small firm’s plan should fit on a couple of pages, name real people rather than roles that do not exist, and reference the tools you actually run rather than the ones a template assumed. If it says “contact the SOC”, and you do not have a SOC, the plan has already lost the person reading it.

And test exactly one thing, once: restore a file from your backup and write down the date and the result. Restore testing is asked about specifically on applications, it is the single control most often assumed rather than verified, and an untested backup is a hope rather than a plan.

Coverwright generates an incident response plan of this shape from your answers — built around the systems you told it you use, with the notification duties that follow from what your business does and where it operates, and with the gaps stated as gaps. If you have never tested a restore, the plan says so and makes it an action with an owner, rather than claiming a tested backup you do not have.