Short answer: An incident response (IR) plan is a short, practical document that says who does what, in what order, when something goes wrong. For a small business it should name an incident lead and backups, define severity levels, lay out the response steps (prepare, detect, contain, eradicate, recover, learn), and list every contact you’ll need: IT provider, cyber insurer, legal counsel, and any customer or regulator you must notify. Defense contractors with DFARS 252.204-7012 in their contracts have extra duties: report cyber incidents to DoD within 72 hours of discovery and preserve affected system images for at least 90 days. Use the template below as a starting point, then test it with a tabletop exercise.
Why does a small business need an incident response plan?
Most small organizations don’t fail during an incident because of missing tools. They fail because nobody knows who decides, who calls the insurer, or whether a customer must be told. Hours get lost in a group chat while evidence is overwritten.
An IR plan also shows up as a requirement in most frameworks and contracts:
- NIST SP 800-171 (required for defense contractors handling CUI) includes an Incident Response family: an operational incident-handling capability, tracking and reporting incidents, and testing that capability.
- DFARS 252.204-7012 adds specific reporting, preservation, and malware-submission duties.
- ISO/IEC 27001, SOC 2, and the HIPAA Security Rule all expect documented incident procedures.
- Cyber insurers often ask about incident response planning in their applications, and policies may require you to notify the insurer and use approved vendors.
- Customer security questionnaires almost always ask whether you have a tested IR plan (see how to answer security questionnaires).
What should an incident response plan include?
Keep the plan short enough to use under pressure. Detailed technical steps can live in separate playbooks.
| Section | What it covers |
|---|---|
| Purpose and scope | Which systems, data, and locations the plan covers; what counts as an “incident” |
| Roles and authority | Incident lead, backup, technical lead, communications lead, executive decision-maker; who can approve shutting systems down or engaging outside help |
| Severity levels | How to rank an incident and what each level triggers |
| Response phases | The steps from detection through lessons learned |
| Reporting obligations | Contractual, regulatory, insurance, and customer notifications, with deadlines |
| Contact list | Internal and external contacts with after-hours numbers, kept outside your main systems |
| Evidence handling | What to preserve, how, and for how long |
| Testing and maintenance | Tabletop exercises and when the plan is updated |
Incident response plan template
Copy this structure into your own document and fill in the brackets.
1. Roles
| Role | Name / backup | Responsibilities |
|---|---|---|
| Incident lead | [Name] / [Backup] | Declares incidents, sets severity, coordinates the response, keeps the incident log |
| Technical lead | [Internal IT or managed service provider] | Investigation, containment, eradication, recovery |
| Executive decision-maker | [Owner / CEO] | Approves major decisions: shutdowns, outside spending, notifications |
| Communications lead | [Name] | Staff, customer, and partner messages; approved wording only |
| Legal / compliance | [Counsel or compliance lead] | Notification obligations, contracts, regulators |
2. Severity levels
| Level | Example | Triggers |
|---|---|---|
| Low | Single phishing email reported, no click | Log it; technical lead reviews |
| Medium | Malware on one laptop, contained; account compromise without data access | Incident lead engaged; same-day review |
| High | Confirmed access to sensitive data (customer data, PHI, CUI); ransomware on multiple systems | Full team activated; executive, insurer, and counsel notified; reporting clocks checked |
| Critical | Business operations stopped; widespread encryption; public exposure | All of the above, plus continuity plan and outside incident response support |
3. Response phases
- Prepare. Keep this plan, the contact list, and backups current. Make sure logging is turned on and retained, and that staff know how to report something suspicious.
- Detect and analyze. Confirm whether an event is an incident, set severity, and start an incident log (who, what, when, and every decision made).
- Contain. Isolate affected devices or accounts, reset compromised credentials, and block malicious senders or addresses. Preserve evidence before wiping anything.
- Eradicate. Remove malware and unauthorized access, and fix the weakness that let the attacker in.
- Recover. Restore from known-good backups, monitor closely, and return systems to normal operation in stages.
- Learn. Within a few weeks, hold a lessons-learned review: what happened, what worked, what to change. Update this plan, the risk register, and training.
NIST’s current incident response guidance, SP 800-61 Revision 3, frames these activities within the six NIST Cybersecurity Framework (CSF) 2.0 Functions (Govern, Identify, Protect, Detect, Respond, Recover) rather than as a standalone process, so incident response becomes part of your overall risk management.
4. Reporting obligations checklist
| Obligation | Deadline | Who reports | How |
|---|---|---|---|
| Cyber insurer | [Per policy] | Executive decision-maker | [Insurer hotline / claim number] |
| DoD (if DFARS 7012 applies) | Within 72 hours of discovery | Incident lead | DIBNet portal (see below) |
| Customers (contractual) | [Per contract] | Communications lead | [Contact] |
| Regulators / state breach laws | [Per law] | Legal / compliance | [Counsel advises] |
| Law enforcement (if appropriate) | [As advised] | Executive decision-maker | [Contact] |
5. Contact list
Keep a printed or offline copy. If email or your file share is down, an online-only contact list won’t help.
- Incident lead, backup, and executive: mobile numbers
- IT / managed service provider: 24/7 support line
- Cyber insurance carrier: claims hotline and policy number
- Outside legal counsel
- Incident response / forensics firm (often designated by the insurer)
- Key customers’ and primes’ security contacts
- Bank fraud line (for payment fraud and business email compromise)
What extra steps does DFARS 252.204-7012 require?
If your defense contracts include DFARS 252.204-7012 and an incident affects a system that processes, stores, or transmits covered defense information, the clause requires you to:
- Review the affected systems for evidence of compromise and identify what covered defense information was affected.
- Report the incident to DoD at dibnet.dod.mil within 72 hours of discovery. Reporting requires a DoD-approved medium assurance certificate. Get one before you need it, because issuance takes time.
- Submit malicious software you isolate to the DoD Cyber Crime Center (DC3), as instructed, rather than to the contracting officer.
- Preserve and protect images of affected systems and relevant monitoring and packet capture data for at least 90 days from the report, so DoD can request them.
- Provide access to additional information or equipment DoD needs for forensic analysis, on request.
Subcontractors also report to DoD and give their prime contractor the incident report number. Add these steps directly to your plan so they don’t depend on someone remembering the clause during an incident. For the full picture, see DFARS 252.204-7012 explained.
How do you test an incident response plan?
The simplest test is a tabletop exercise: gather the people named in the plan for 60–90 minutes and walk through a realistic scenario, such as “the bookkeeper’s email account is sending fake invoices” or “files on the shared drive are being encrypted.” At each step, ask who decides, who calls whom, and where the information lives.
Record the gaps you find and assign owners to fix them. Repeat at least once a year, after major changes (new systems, a new IT provider, new contracts), and after any real incident.
Frequently Asked Questions
How long should a small business incident response plan be?
Short enough to use under stress. For most small organizations, the core plan is a handful of pages: roles, severity levels, response steps, reporting obligations, and contacts. Detailed technical playbooks (for ransomware, email compromise, or lost devices) can be separate attachments.
Does NIST SP 800-171 require an incident response plan?
The Incident Response family requires an operational incident-handling capability covering preparation, detection, analysis, containment, recovery, and user response activities, plus tracking, documenting, and reporting incidents and testing the capability. A documented, tested plan is the standard way to show that. Your System Security Plan should describe it.
Who should lead incident response in a small company?
Someone with authority to make decisions quickly, plus a named backup. The technical work is often done by an IT provider, but decisions about shutdowns, spending, and notifications belong to leadership. A vCISO can own the plan and coordinate during an incident without being a full-time hire.
What’s the difference between an incident response plan and a business continuity plan?
An incident response plan covers detecting, containing, and recovering from a security incident, including evidence and reporting. A business continuity plan keeps the business operating during any disruption, whether a cyberattack, a power outage, or a natural disaster. They should reference each other.
How USCIBER can help
USCIBER writes and tests incident response plans as part of its vCISO service: plan and playbooks, contact lists, DFARS 7012 reporting steps, and facilitated tabletop exercises with lessons-learned follow-up. Engagements are led by security leadership holding CISSP, CISM, and GCIH credentials. vCISO engagements are scoped after a call. If you need the plan as part of a CMMC documentation package, see SSP & POA&M development.
Sources
- 48 CFR 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting (paragraphs (c)–(g))
- DoD — DIBNet cyber incident reporting
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-171 Rev. 2 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (Incident Response family, 3.6)
- NIST — Cybersecurity Framework (CSF) 2.0
This article is general information, not legal advice.