An incident response plan is a short, rehearsed document that states who decides, who gets called, what happens in the first hours and what must be reported when an attack or data breach occurs. For a small or mid-sized company, one core page plus playbooks for five likely scenarios is enough: ransomware, account compromise, data leak, leaked API key and AI assistant misuse. What makes a plan useful is not its length but the fact that the team has practiced it before it is needed.
What an incident response plan is, and why you need one
An incident response plan is the set of roles, procedures and criteria an organization follows to detect, contain, eradicate and recover from a security incident, and to learn from it. Without one, the first hours are lost to debate: who has the firewall password, whether to shut the server down, whether to tell customers. Those are the hours that decide how much damage an attacker does.
There are external reasons too. Cyber insurers, enterprise customers and SOC 2 auditors routinely ask for a documented and tested plan, and breach notification deadlines are hard to meet if nobody knows who decides to notify.
The lifecycle per NIST SP 800-61 Rev. 3
The most widely used reference is NIST SP 800-61. Revision 3, published in April 2025, supersedes Revision 2 from 2012. Rev. 2 described a four-phase cycle: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Rev. 3 is written as a Community Profile of the NIST Cybersecurity Framework (CSF) 2.0 and maps incident response onto its six functions:
| CSF 2.0 functions | Role in incident response |
|---|---|
| Govern, Identify, Protect | Preparation: policies, roles, asset inventory, preventive controls. Broad risk management activities that support response. |
| Detect | Discover and analyze events that may be incidents. |
| Respond | Manage, analyze, contain, communicate and eradicate. |
| Recover | Restore operations and communicate recovery. |
| Identify (Improvement) | Lessons learned from all activities feed the Improvement category, which informs every function. |
The practical takeaway: incident response is no longer a standalone procedure but part of enterprise risk management, which is also how SOC 2 and ISO 27001 auditors look at it.
Roles and the contact list
In a small company one person may hold several roles, but every role needs a primary and a backup:
- Incident lead: coordinates, sets priorities and keeps the log. Does not need to be the most technical person.
- Technical lead: internal IT or your MSP; runs containment and recovery.
- Executive sponsor: approves business decisions (taking systems offline, disclosure, outside help).
- Legal and privacy counsel: assesses notification duties, drafts notices, and can help preserve privilege over the investigation.
- Communications: messages to staff, customers and, if needed, media.
Keep the contact list outside the systems that might go down (printed or in an out-of-band channel): security and forensics provider, cloud provider, bank, cyber insurer and breach coach, outside counsel, and the FBI field office or IC3. If you have no response partner yet, line one up now; our cybersecurity team can fill that role.
Severity classification
| Level | Criteria | Response |
|---|---|---|
| Critical | Operations down, mass encryption, or confirmed leak of personal, health or financial data | Full team and executives immediately; assess legal notification |
| High | Privileged account compromised, active malware on several hosts, production secret exposed | Technical lead and incident lead within one hour |
| Medium | User account compromised with no evidence of sensitive data access | Same business day |
| Low | Reported phishing with no clicks, blocked scans | Log and track normally |
Playbooks for the five most likely incidents
Ransomware
Isolate hosts without powering them off, coordinate by phone, protect backups, preserve evidence, call your insurer, then decide on restoration. Details in our guide to ransomware prevention and response for SMBs.
Account compromise (email or cloud)
Revoke active sessions, reset the password, re-enroll or strengthen MFA, look for attacker-created forwarding rules or OAuth app grants, determine what data was accessed, and check whether fraudulent emails (for example, fake payment instructions) went to customers or vendors.
Data leak
Close the exposure (public bucket, unauthenticated endpoint), determine what data, how many people and in which states, for how long, and bring in counsel immediately because notification clocks may already be running.
Leaked API key or secret
Revoke and rotate first, investigate second. Review provider logs for any use since the leak, purge it from repository history and add secrets scanning to the pipeline, as described in our DevSecOps guide.
AI assistant or agent misuse
If a chatbot or agent disclosed data, took unauthorized actions or was manipulated through prompt injection: disable the affected tools or integrations, preserve conversations and traces as evidence, rotate the credentials the agent used and review its permissions. Defenses are covered in our guide to prompt injection in AI agents.
Evidence preservation
- Do not power off or reimage systems before capturing what you need; isolate first.
- Export firewall, EDR, email, cloud and identity provider logs before they roll over.
- Make copies and record who collected them, when and how (chain of custody), especially if law enforcement or litigation may follow.
- Keep a timeline log of time, action, owner and decision. It supports notifications, insurance claims and the post-incident review.
Communication: internal, customers and regulators
Internally, use an out-of-band channel if email may be compromised, and share details on a need-to-know basis. With customers, share verified facts, what you are doing and what they should do; avoid speculating about cause or scope before you have evidence.
With authorities, obligations depend on the data and your company:
- State breach notification laws: every US state has one. Triggers, deadlines and whether the attorney general must be notified vary by state, so map where your affected individuals live.
- HIPAA: covered entities and business associates must notify affected individuals without unreasonable delay and no later than 60 days after discovery, plus HHS and, for larger breaches, the media.
- SEC: public companies must disclose material cybersecurity incidents on Form 8-K, Item 1.05, generally within four business days after determining materiality.
- Contracts and insurance: customer agreements and cyber policies often impose their own short notice windows.
Tabletop exercises and post-incident review
A tabletop exercise is a one- to two-hour session where the team walks through a realistic scenario step by step without touching systems. It exposes gaps fast: a vendor contact that no longer exists, a backup password only a departed employee knew, uncertainty about who can authorize taking the online store down. CISA publishes free tabletop exercise packages, including ransomware scenarios, that you can adapt. Run at least one a year.
After every significant incident, hold a blameless post-incident review within two weeks: timeline, what worked, what did not, root cause, and actions with owners and dates. Those actions are exactly what NIST's Improvement category is meant to capture.
One-page template outline
- Scope and definition: what counts as an incident and how to report it (email, phone, channel).
- Roles: incident lead, technical lead, executive, legal, communications, with backups.
- Emergency contacts: internal and external, stored outside primary systems.
- Severity: four-level table with response times.
- First 60 minutes: isolate, alert the lead, open the log, preserve evidence, notify the insurer.
- Playbooks: links to the five scenarios.
- Notification: criteria, deadlines, who drafts and who approves.
- Recovery: restoration order for critical systems.
- Improvement: date of the next tabletop and the next plan review.
Frequently asked questions
What should an incident response plan include?
At minimum: an incident definition and reporting path, roles with backups, an emergency contact list, severity criteria, first-hour steps, scenario playbooks, evidence preservation rules, legal notification criteria and deadlines, a recovery order and a post-incident review process. All of it should fit in a document someone can read under pressure.
What changed in NIST SP 800-61 Rev. 3?
Published in April 2025, it supersedes the 2012 Rev. 2 and aligns incident response with the six functions of CSF 2.0. Govern, Identify and Protect cover preparation as part of risk management; Detect, Respond and Recover cover the response itself; and lessons learned feed a continuous Improvement category that informs every function.
How fast do we have to report a data breach in the US?
It depends on the data and jurisdiction. State laws set their own triggers and deadlines, with some specifying a fixed number of days. HIPAA allows no more than 60 days after discovery for individual notice. Public companies must file an SEC Form 8-K within four business days of determining an incident is material. Counsel should map your obligations in advance.
How often should we test the plan?
At least one tabletop exercise a year, and whenever something significant changes: a new critical system, a new IT provider or cloud platform, or turnover in key roles. Verify contact details quarterly. Plans that have never been exercised tend to fail on basics like outdated phone numbers or missing access.
Do we need an outside incident response firm?
For most SMBs, yes: few small companies have in-house forensics. What matters is arranging it before an incident, with contacts, response times and terms agreed, instead of searching mid-crisis. If you carry cyber insurance, check whether the policy requires specific panel providers.
Conclusion
A good incident response plan is short, has clear owners, includes playbooks for likely scenarios, maps your notification duties and is exercised at least once a year. NIST SP 800-61 Rev. 3 gives you the structure; the tabletop tells you whether it works.
MisterProSoft is a nearshore security team in UTC-5, available during US business hours. We help you write the plan and playbooks, facilitate tabletop exercises and strengthen the controls that make incidents less likely. Explore our cybersecurity services or book a free consultation.