The incident response plan a mid-market company can run

An incident response plan gets read late, quickly, and often by people who did not write it. The first question it has to answer is not a technical one: who gets called, and what is that person allowed to decide before waking anyone else?

Most mid-market incident response plans cannot answer that. They answer the technical questions perfectly well — isolate the host, rotate the keys, restore from the backup — and then stop exactly where the decisions stop being technical. That is also the point where the cost starts.

The plan is not the runbook

These are two documents with two different readers, and companies routinely have the first while believing they have the second.

A runbook is for the engineer: how to contain, how to rebuild, how to verify. A plan is for the organisation: who declares, who decides, who is told, in what order, and who is allowed to spend money in the middle of the night without a purchase order.

NIST's glossary defines an incident response plan as "the documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of a malicious cyber attacks against an organization's information system(s)," a definition drawn from NIST SP 800-34 Rev. 1. Predetermined is the operative word. Anything you work out during the incident is not the plan; it is improvisation with an audience.

Decide what an incident is before you have one

The most expensive part of any response is the time spent arguing about whether this one counts.

NIST's glossary gives computer security incident as "an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies," in the formulation drawn from NIST SP 800-61r3. Read imminently. The threat does not have to have landed.

Two things follow for the plan. It needs written declaration criteria — the conditions under which an event becomes an incident, phrased so that a tired engineer can apply them. And it needs severity tiers, because the response to a phished mailbox and the response to an encrypted ERP should not be the same procedure.

Our view, plainly: set the bar low and make declaring cheap. Declaring an incident that turns out to be nothing costs a little of everyone's time. Not declaring one that turns out to be something costs the rest of the quarter.

What the plan has to contain

You do not have to invent the table of contents. The FTC's guidance on its Safeguards Rule sets out what a written incident response plan must address, and the list is a serviceable skeleton for a company the rule may not even cover:

• "The goals of your plan"
• "The internal processes your company will activate in response to a security event"
• "Clear roles, responsibilities, and levels of decision-making authority"
• "Communications and information sharing both inside and outside your company"
• "A process to fix any identified weaknesses in your systems and controls"
• "Procedures for documenting and reporting security events and your company's response"
• "A post mortem of what happened and a revision of your incident response plan and information security program based on what you learned"

Whether the Safeguards Rule applies to your business is a question for counsel. But a regulator has published its view of what a usable plan contains, and levels of decision-making authority is the line most home-grown plans are missing.

The map nobody has built: who you have to tell

This is where mid-market companies get hurt, because the obligations arrive from several directions at once and none of them are visible at speed.

• Customers and contracts. Notification clauses in enterprise agreements are commonly tighter than anything a statute requires, and they are the ones a breach actually triggers first.
• State breach notification statutes. The FTC's breach response guide states that "all states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information," and tells companies to "check state and federal laws or regulations for any specific requirements for your business." That analysis belongs to counsel, not to the responder.
• Sector and regulator rules. For covered financial institutions, the FTC's guidance says to notify the FTC "as soon as possible – and no later than 30 days after discovery" of a notification event, which it describes as "the unauthorized acquisition of at least 500 consumers' unencrypted information." Where law enforcement asks for a delay, the guidance points to a box on the form for exactly that.
• CISA. Under CIRCIA, covered entities will have to report covered cyber incidents "no later than 72 hours from the time the entity reasonably believes the incident occurred" and ransom payments "within 24 hours of making any ransom payments." CISA states that those requirements do not become effective until the CIRCIA final rule does, and that it continues to work on the rule. Voluntary reporting is available now.
• Your insurer. Policies generally require prompt notice and often require the insurer's panel counsel or forensics firm. Calling your own firm first can affect coverage.
• Investors and, for public companies, the market. That last one is a different article — the disclosure clock and who owns the materiality judgement are covered in a breach is a financial reporting problem.

Build this as a table, in advance, with a named owner per row. During an incident nobody has the concentration to read a statute.

Name people, not job titles

A plan that says "the CISO will" is a plan that fails when that person is unreachable. Every role wants a named primary, a named alternate and a phone number that works when corporate email is the thing you no longer trust.

Three details are worth writing down explicitly:

1. An out-of-band channel. If the incident might involve your identity provider or your messaging platform, the response cannot be coordinated inside them. Agree the fallback now and make sure the numbers are stored somewhere that is not the laptop under investigation.
2. How counsel is engaged. Ask counsel in advance how they want investigative work routed and what they expect to be privileged.
3. One voice outward. One spokesperson for customers, one for staff, and a standing instruction that nobody else confirms anything.

Preserve the evidence, because two audiences read it later

The FTC's breach response guide is unambiguous: "do not destroy any forensic evidence in the course of your investigation and remediation." It also tells companies to "move quickly to secure your systems and fix vulnerabilities that may have caused the breach," and to take affected equipment offline without shutting the machines down. The same guide says to assemble "a team of experts" that, "depending on the size and nature of your company," "may include forensics, legal, information security, information technology, operations, human resources, communications, investor relations, and management." On law enforcement it is equally direct: "call your local police department immediately."

Containment and preservation genuinely pull against each other, and the plan should say who resolves that tension.

The second audience arrives months later. Auditors and enterprise buyers ask what happened, when it was detected, who was told and what changed — and they ask for records, not recollection. A timestamped incident log kept during the response is the artefact that answers them. Reconstructed afterwards, it is a memo.

Rehearse it, or it is fiction

NIST defines a tabletop exercise as "a discussion-based exercise where personnel with roles and responsibilities in a particular IT plan meet in a classroom setting or in breakout groups to validate the content of the plan by discussing their roles during an emergency and their responses to a particular emergency situation," with a facilitator presenting a scenario and asking questions. That is drawn from NIST SP 800-84, and the word to hold onto is validate.

You do not have to write the scenario yourself. CISA publishes Tabletop Exercise Packages, described as "a comprehensive set of resources designed to assist stakeholders in conducting their own exercises," each one "customizable" and including "template exercise objectives, scenarios, and discussion questions as well as a collection of references and resources," covering topics including ransomware and insider threats.

The exercise finds the things a document review never does: that the alternate does not know they are the alternate, that the notification map has a row with no owner, that nobody can actually reach the insurer out of hours.

The post-mortem is part of the plan

The FTC's list ends with the post-mortem and "a revision of your incident response plan and information security program based on what you learned." Most companies do the first half. The revision is what converts an incident into a control improvement, and in our view the plan should name who owns that revision and when it is due — otherwise the lessons live in a deck nobody opens again.

NIST's glossary also records incident handling, in the NIST SP 800-61r3 formulation, as "the remediation or mitigation of violations of security policies and recommended practices." Remediation is in the definition. Getting the systems back is not the end of the work.

What to do first

1. Write the declaration criteria and the severity tiers. One page. This is the part that has to work when everyone is tired.
2. Build the notification map, with a named owner per row and the contract clauses read rather than assumed. Do it with counsel.
3. Run one tabletop against a scenario that touches a system you depend on, and fix what it exposes before you touch the document again.

If an incident has already happened and you are working out what it did to your control environment, the breach aftermath control checklist walks the ground in order. And if the trigger for all this was a customer or insurer asking what testing you do, cybersecurity assessment vs penetration test is the more useful next read.

This is general information, not audit, security or legal advice. Confirm what applies to you with your auditor or counsel.

Common questions

What is the difference between an incident response plan and a runbook?

A runbook is technical: how to isolate a host, rotate credentials or restore a system. A plan is about authority and sequence — who declares an incident, who decides to take production offline, who calls counsel, who speaks to customers. NIST's glossary describes the plan as predetermined instructions, and the predetermined part is the whole value.

Who should be allowed to declare an incident?

In our view, name a small set of people who can declare without asking permission, each with an alternate, and write down that declaring is never held against them. If the only person who can start the process is an executive who might be asleep or on a plane, the plan has a single point of failure that no amount of tooling fixes.

Does a private mid-market company have any legal reporting deadline after a breach?

It depends entirely on what you do and whose data you hold. The FTC's Safeguards Rule guidance tells covered financial institutions to notify the FTC as soon as possible and no later than 30 days after discovering a notification event involving the unauthorized acquisition of at least 500 consumers' unencrypted information. State breach statutes, sector rules and customer contracts add their own clocks. Which of them apply to you is a question for counsel, not for a vendor.

Do we have to report an incident to CISA?

Not yet, under CIRCIA. CISA says the mandatory reporting requirements do not take effect until the CIRCIA final rule does, and that it continues to work on that rule. The statutory shape is already known — covered cyber incidents reported no later than 72 hours from the time the entity reasonably believes the incident occurred, and ransom payments within 24 hours — so building the capability now is cheaper than retrofitting it later.

How do we know whether the plan actually works?

Exercise it. NIST defines a tabletop exercise as a discussion-based exercise where the people with roles in the plan validate its content by talking through their roles against a facilitated scenario. CISA publishes customizable tabletop packages with template objectives, scenarios and discussion questions. A plan that has never been walked through end to end is a draft.

What should the plan say about preserving evidence?

That destroying it is not permitted. The FTC's breach response guide is blunt: do not destroy any forensic evidence in the course of your investigation and remediation. Containment instincts and evidence preservation genuinely conflict, so the plan should say who resolves that conflict and how affected systems are taken out of service.

Sources

1. Computer Security Resource Center Glossary — 'incident response plan' (definition drawn from NIST SP 800-34 Rev. 1) · National Institute of Standards and Technology
2. Computer Security Resource Center Glossary — 'computer security incident' (definitions drawn from NIST SP 800-61r3 and others) · National Institute of Standards and Technology
3. Computer Security Resource Center Glossary — 'incident handling' (definitions drawn from NIST SP 800-61r3 and NIST SP 800-35) · National Institute of Standards and Technology
4. Computer Security Resource Center Glossary — 'tabletop exercise' (definition drawn from NIST SP 800-84) · National Institute of Standards and Technology
5. FTC Safeguards Rule: What Your Business Needs to Know · Federal Trade Commission
6. Data Breach Response: A Guide for Business · Federal Trade Commission
7. Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) · Cybersecurity and Infrastructure Security Agency
8. CISA Tabletop Exercise Packages · Cybersecurity and Infrastructure Security Agency