An incident response plan is the document that determines whether a bad day becomes a manageable incident or a business-ending crisis. Most small businesses don’t have one.
Every cybersecurity framework worth its name requires one. GLBA. The SEC’s cybersecurity rules. HIPAA (implicitly, through the requirement for contingency planning). PCI-DSS. SOC 2. Cyber insurance carriers ask for it on renewal applications. And yet, for most small and mid-sized businesses, the incident response plan is either absent entirely or exists as a generic template that nobody has read, tested, or adapted to the actual environment.
Here’s what it is, what it needs to contain, and what its absence actually costs.
An incident response plan (IRP) is a documented, tested set of procedures for how your organization will detect, contain, investigate, recover from, and report a cybersecurity incident. It answers the questions that, under pressure, no one will be able to think clearly enough to answer on the fly: Who do we call first? Who has authority to take systems offline? When do we notify clients? When do we notify regulators? Where are the backups and who can access them? Who talks to the press if this gets out?
It’s the difference between a practiced fire drill and standing in a burning building trying to remember where the exits are.
GLBA Safeguards Rule requires financial institutions to have a written incident response plan that addresses the goals of the plan, internal processes for responding to a security event, clear roles and responsibilities, external reporting requirements, and post-incident review procedures. The 2023 updates made these requirements substantially more specific.
SEC cybersecurity rules (2023) require registered investment advisers and public companies to have policies and procedures for responding to material cybersecurity incidents — and to disclose material incidents within four business days of determining materiality. You can’t determine materiality without a process for assessing it. That process is your incident response plan.
HIPAA requires covered entities and business associates to have contingency plans that address data backup, disaster recovery, emergency operations, testing, and application criticality analysis. While HIPAA doesn’t use the phrase “incident response plan,” the practical requirement is effectively the same thing.
PCI-DSS requires an incident response plan that is ready to be activated immediately in the event of a system breach, including specific roles, communication protocols, and legal notification requirements.
SOC 2 auditors look for documented incident management procedures as part of the Common Criteria. Evidence of plan testing is increasingly expected, not just plan existence.
Cyber insurance carriers require a written incident response plan as a condition of coverage. Some carriers require evidence of annual testing.
A compliant, functional incident response plan covers six phases:
Preparation. Who is on the incident response team? What are their roles? What tools and contacts do they need? What does “normal” look like so you can recognize “abnormal”? This phase happens before any incident — it’s the foundation everything else depends on.
Identification. How do you know an incident is happening? What alerts, behaviors, or reports trigger the plan? What’s the threshold between a minor security event and a declared incident? Who makes that determination?
Containment. How do you stop the bleeding? Short-term containment (isolate the affected system, block the attacker’s access) and long-term containment (stabilize the environment while you investigate). Who has authority to take systems offline?
Eradication. Remove the attacker and the malware from your environment. Identify the root cause. Close the vulnerability that was exploited.
Recovery. Restore systems from clean backups. Verify integrity before bringing systems back online. Monitor for signs of reinfection. For what this looks like in practice, see our article on what happens during an IT emergency.
Post-incident review. What happened? What did we do well? What do we need to improve? What documentation do we need to produce for regulators, insurers, or clients? This phase turns a bad experience into institutional knowledge.
A cybersecurity incident at a regulated business often triggers mandatory notification requirements with defined timelines. HIPAA breach notification: within 60 days of discovery for covered entities (and immediately to business associates). SEC material incident disclosure: within four business days. GLBA: notification to customers “as soon as possible.” Florida’s breach notification law: within 30 days. PCI-DSS: immediate notification to your acquiring bank and card brands.
Missing these deadlines while scrambling to figure out what happened is a separate violation layered on top of the breach itself. The incident response plan is what prevents that from happening — because the notification requirements, contact information, and decision criteria are already documented before you need them.
A plan that’s never been tested is a document, not a capability. Incident response plans need to be tested at least annually — through tabletop exercises where the team walks through a simulated scenario, identifies gaps, and updates the plan accordingly. Most compliance frameworks expect evidence of testing, not just plan existence.
Tabletop exercises also surface the practical gaps that look fine on paper: the person listed as the primary incident contact left the company eight months ago. The backup credentials are stored in the system that just got encrypted. The legal counsel contact is a personal cell number that’s been disconnected.
NerdSquad develops and maintains incident response plans for managed IT clients as part of their compliance program. We document the plan, adapt it to the client’s specific environment and regulatory obligations, facilitate annual tabletop exercises, and update it when the environment changes. The plan lives in our documentation system and is accessible when it’s needed — not locked in a desk drawer or a file that hasn’t been opened in two years.
For the broader compliance picture, see What is digital compliance? and What is a compliance risk assessment?