By Ryan Windt | Head of Growth Marketing | Updated April 2026
Most businesses have some version of an incident response plan. It lives in a shared drive somewhere, it was written two or three years ago by someone who has since left the company, and nobody has looked at it since. That document will not help you when something actually goes wrong.
A functional IR plan is not a compliance artifact. It is an operational document that tells specific people exactly what to do, in what order, in the first hours of a cyber incident — before panic sets in, before the pressure to just fix it overrides the steps that protect your claim, and before decisions made in the wrong sequence cost you coverage.
This guide walks through what a real IR plan contains, how to build one if you do not have one, how to test it, and what underwriters look for when they ask about it at application and renewal. A downloadable template is included at the end.
Why Underwriters Ask About Your IR Plan
Incident response capability is one of the top underwriting controls in cyber insurance applications. Carriers ask about it for the same reason they ask about MFA and backups: it directly affects how bad a loss gets and how much they will pay when something goes wrong.
The difference between a business that contains a ransomware incident in 12 hours and one that is offline for five days is almost never the sophistication of the attack. It is almost always the quality of the response. Businesses that know what to do immediately — isolate, notify, preserve, engage — consistently experience lower severity events and faster recovery. That translates directly into lower claim costs, which is why carriers reward documented and tested IR plans with better pricing and fewer sublimits.
What underwriters specifically look for:
- A written IR plan that covers at minimum ransomware, business email compromise, and data breach scenarios
- Clearly defined roles: who declares an incident, who is authorized to shut down systems, who communicates with customers and regulators
- A pre-identified legal counsel and forensic firm on retainer or panel
- Your carrier’s notification hotline number in the plan
- Evidence the plan has been tested within the last 12 months — typically a tabletop exercise with documented outcomes
The last point catches many businesses off guard. Having a written plan is necessary but not sufficient. Underwriters increasingly distinguish between a plan that exists on paper and a plan that has been exercised under simulated pressure. If you cannot point to a tabletop in the last year, that gap shows up in your underwriting terms.
The Five Phases Every IR Plan Must Cover
A functional IR plan follows five phases regardless of the incident type. The specific actions within each phase vary, but the structure is consistent.
Phase 1: Preparation
Preparation is everything that happens before an incident. It is the phase most businesses skip, which is why they struggle when something actually happens.
Preparation means:
Assembling your response team. Define who is on your incident response team and what their role is. At minimum this includes an incident commander (the person who makes decisions and coordinates response), a technical lead (the person who executes containment and investigation), a communications lead (the person who handles internal and external communications), and a legal contact (internal counsel or an outside firm on retainer).
For SMBs without dedicated security staff, the incident commander is often the CEO or COO. The technical lead is often the IT manager or MSP. That is fine — what matters is that the roles exist and the people in them know they are in them before something happens.
Building your contact list. Your IR plan should include direct phone numbers — not email addresses — for every person and vendor who will be involved in a response. This includes your carrier’s 24/7 incident response hotline, your legal counsel, your forensic firm or MSP, your public relations contact if applicable, and the personal mobile numbers of every member of your internal response team. When systems are down and email is compromised, phone numbers are what you use.
Pre-authorizing decisions. One of the most common failure modes in incident response is decision paralysis. Nobody is sure who is authorized to take a system offline, pay a forensic vendor, or notify customers. Define these authorities in advance. The IR plan should explicitly state who can declare an incident, who can authorize system shutdowns, who can approve external vendor engagement, and who can authorize communication to customers or regulators.
Documenting your environment. Your response team needs to know what they are responding to. Your IR plan should include or reference a current network diagram, an asset inventory, your backup architecture and recovery process, your critical systems and their RTO/RPO targets, and your data map showing where sensitive data lives.
Phase 2: Detection and Initial Assessment
Detection is when you first become aware that something may be wrong. Initial assessment is the process of determining whether what you are seeing is actually an incident — and if so, how serious it is.
Your IR plan should define what triggers an incident declaration. Common triggers include:
- An endpoint detection alert indicating active malware or lateral movement
- User reports of encrypted files or ransom notes
- Unusual account activity or login anomalies
- External notification from a third party, law enforcement, or your carrier
- Inability to access systems or data without explanation
Not every alert is an incident. Your plan should define a triage process for distinguishing noise from real events, and it should define who makes the call to escalate to a full incident response.
Once an incident is declared, the clock starts. Your carrier notification window — typically 24 to 72 hours from discovery — begins at declaration. Your plan should make this explicit: incident declared means notification to carrier happens within the window, without exception.
Phase 3: Containment
Containment is the process of stopping an active incident from spreading. It is the most technically intensive phase and the one where the tension between business continuity and investigation integrity is highest.
Your plan should define containment procedures for your most likely incident scenarios. The two that must be covered for any SMB or MSP:
Ransomware containment:
- Isolate affected systems from the network immediately — disconnect ethernet, disable Wi-Fi, do not power off (powered-off systems lose volatile memory that may contain forensic evidence)
- Identify the scope of compromise: which systems are showing encryption, how far has lateral movement progressed
- Preserve affected systems for forensic imaging before any remediation or restoration
- Identify the initial access point if possible to prevent reinfection
- Contact carrier hotline before any further action
BEC / account compromise containment:
- Reset compromised account credentials immediately
- Revoke active sessions for the compromised account
- Review mail rules, forwarding rules, and OAuth grants on the compromised account for persistence mechanisms
- Check for lateral movement to other accounts accessed from the same device or credentials
- Review recent wire transfers or payment instructions initiated from the compromised account
For MSPs: containment in an MSP environment is more complex because isolating a compromised management tool affects all clients. Your plan should define the process for isolating RMM or management plane access without inadvertently cutting off your ability to respond on behalf of clients.
Phase 4: Eradication and Recovery
Eradication is the process of removing the attacker and their tools from your environment. Recovery is the process of restoring systems and operations to normal.
These phases should not begin until forensic investigation is complete or explicitly authorized by your carrier and forensic team. Restoring systems before understanding the root cause of compromise is one of the most common reasons for reinfection.
Your plan should define:
- Who authorizes the transition from containment to eradication
- What evidence must be collected before remediation begins
- The order in which systems are restored (critical systems first, defined by your RTO priorities)
- How clean restore points are verified before systems are brought back online
- The process for confirming the initial access vector has been closed before reconnecting to the network
For ransomware specifically: your plan should include your backup recovery procedure, including how to verify backups are clean before restoration and how to test restore to a non-production environment before full recovery.
Phase 5: Post-Incident Review
The post-incident review happens after recovery is complete. It is the phase most businesses skip, and it is where the most learning occurs.
Your plan should require a post-incident review within 30 days of recovery for any declared incident. The review should document:
- Root cause of the incident and initial access vector
- Timeline from initial access to detection
- What worked in the response and what did not
- Control gaps identified during the investigation
- Remediation actions taken and outstanding
- Changes to the IR plan based on lessons learned
The output of the post-incident review becomes part of your documentation for the carrier and for future underwriting applications. If controls were found to be inadequate, the remediation plan and timeline are what you present at renewal.
Scenario-Specific Playbooks
The five-phase structure above applies to every incident. The scenario-specific playbooks define the specific actions within that structure for the incidents you are most likely to face. Your IR plan should include at minimum:
Ransomware Playbook
Hour 0–1:
- Isolate affected devices from network (ethernet disconnect, Wi-Fi disable, do not power off)
- Alert incident commander
- Do not attempt to decrypt or restore until forensic team is engaged
- Locate ransom note — do not pay anything, do not communicate with attacker
Hour 1–4:
- Call carrier hotline — this is not optional, this is step one before any other vendor engagement
- Carrier dispatches forensic team and legal counsel from their panel
- Begin scoping: identify which systems are affected, when encryption appears to have started, whether backups are intact
- Do not wipe or restore any affected systems until forensic imaging is complete
Hour 4–24:
- Forensic team conducts triage and initial scope assessment
- Legal counsel advises on regulatory notification obligations
- Internal communications drafted (do not send without legal review)
- Decision on ransom payment made with carrier involvement — not unilaterally
Day 2–5:
- Forensic investigation identifies root cause and entry point
- Recovery plan developed with carrier and forensic team
- Backup integrity verified before any restoration begins
- Regulatory notifications sent within required window if personal data was involved
Business Email Compromise Playbook
Hour 0–1:
- Identify the compromised account
- Reset credentials and revoke active sessions immediately
- Preserve the compromised mailbox without modification — do not delete emails
- Alert incident commander
Hour 1–4:
- Call carrier hotline
- Audit the compromised account for mail rules, forwarding rules, auto-replies, and OAuth grants
- Check for any wire transfers, payment instructions, or vendor account change requests sent from the account in the last 30 days
- Contact your bank immediately if any fraudulent transfers are identified — a wire recall window of 24 to 48 hours exists in many cases
Hour 4–24:
- Forensic review of how the account was compromised (phishing, credential stuffing, MFA bypass)
- Scope check: were other accounts accessed from the same device or session?
- Legal review of notification obligations if customer or partner data was in the compromised mailbox
- Communications to affected parties drafted with legal review
Data Breach Playbook
Hour 0–4:
- Identify the source and scope of the exposure: which systems, which data types, which individuals potentially affected
- Preserve logs and evidence of the exposure
- Call carrier hotline
- Do not communicate externally about the breach until legal counsel is involved
Day 1–3:
- Forensic confirmation of what data was accessed or exfiltrated
- Legal counsel assesses notification obligations by state and by data type
- Carrier coordinates breach response services: notification, credit monitoring, call center if applicable
Day 3–30:
- Notification sent to affected individuals within state-required window
- Regulatory notification where required (state AG, HHS if HIPAA applies, SEC if publicly traded)
- Credit monitoring enrollment offered to affected individuals if PII was involved
Tabletop Exercises: How to Test Your Plan
A tabletop exercise is a structured discussion where your response team walks through a simulated incident scenario step by step, making decisions in real time, without actually taking systems offline. It takes two to three hours, requires no special tools, and reveals gaps in your plan and your team’s readiness that you will not find any other way.
Underwriters want to see a tabletop conducted within the last 12 months. The documentation they ask for is typically an agenda, a summary of participants, and an after-action report noting what gaps were identified and how they were or will be addressed.
Running a basic tabletop:
Step 1: Choose a scenario. Ransomware is the most valuable scenario for most SMBs and MSPs because it is the most common and most financially severe. BEC is the second most valuable. Pick one per exercise.
Step 2: Assemble the team. The same people who would respond to a real incident should be in the room. This means the incident commander, technical lead, communications lead, and legal contact if available. For SMBs, this is typically 3–5 people.
Step 3: Walk through the scenario using inject cards. An inject is a scenario development — a piece of new information that arrives during the exercise that the team must respond to. Example injects for a ransomware scenario:
- “IT reports that three workstations are showing encrypted files and a ransom note. What do you do first?”
- “The forensic team has identified that the initial access was through a vendor’s remote access tool that was not under your MFA policy. How does this affect your response?”
- “Your backup vendor reports that the backups were also encrypted. You need to decide whether to pay the ransom. Who makes that decision and what information do they need?”
- “A journalist has called asking for comment on a post on a dark web forum claiming your customer data was stolen. How do you respond?”
Step 4: Debrief and document. After the exercise, discuss what worked, what did not, and what the plan is missing. Assign owners to each gap with a remediation deadline. Write a one-page after-action summary.
Frequency: Annually is the minimum underwriters look for. After a significant change to your environment — new systems, new vendors, new team members in key roles — is a good time to run an additional exercise regardless of the annual cycle.
What Your IR Plan Document Should Include
Your IR plan should be a single document, or a short document with attached playbooks, that can be printed and used when systems are down. Do not build your IR plan in a system that requires internet access to retrieve.
Recommended structure:
- Plan overview — purpose, scope, and plan owner
- Incident response team — names, roles, and direct phone numbers
- External contacts — carrier hotline, legal counsel, forensic firm, MSP (for SMBs), PR contact
- Incident declaration criteria — what triggers a declaration and who is authorized to declare
- Pre-authorized decision authority — who can shut down systems, engage vendors, authorize payment, communicate externally
- Environment reference — network diagram, asset inventory, backup architecture, critical system RTO/RPO
- Scenario playbooks — ransomware, BEC, data breach (at minimum)
- Regulatory notification reference — applicable state laws, HIPAA if relevant, notification window summary
- Post-incident review template — standard format for documenting what happened and what changed
Keep a printed copy in a physical location your team can access when systems are offline. Keep a copy in your carrier’s file and give a copy to your legal counsel. Review and update it annually and after any significant environmental change.
The IR Plan Checklist for Underwriting
Before submitting a cyber insurance application or entering a renewal, verify:
- Written IR plan exists and covers ransomware, BEC, and data breach scenarios
- Incident response team is defined with roles and direct phone numbers
- Carrier notification hotline number is in the plan
- Pre-authorization for key decisions is documented (system shutdown, vendor engagement, external communication)
- Legal counsel is identified and has been briefed on their role
- Forensic firm or MSP is identified and has been briefed on their role
- Backup recovery procedure is documented in the plan
- Tabletop exercise has been conducted in the last 12 months
- After-action report from the tabletop documents identified gaps and remediation
- Plan has been reviewed and updated within the last 12 months
A plan that meets all of these criteria, with supporting documentation, is one of the strongest signals you can send to an underwriter that your organization is prepared to contain and recover from an incident.
Download the IR Plan Template
SeedPod Cyber has built a ready-to-use IR plan template covering all five phases, all three core scenario playbooks, the tabletop exercise format, and the post-incident review template. It is structured so that an SMB or MSP can complete it in a working session with their team, and it is formatted for the evidence documentation underwriters request at application and renewal.
If you want to walk through your current plan with an underwriter before your next renewal, contact SeedPod Cyber. We review IR readiness as part of our underwriting process, and we can tell you exactly what your plan is missing before it matters.
Related resources:
- Cyber Insurance Requirements: The Minimum Controls Checklist for SMBs and MSPs
- How to File a Cyber Insurance Claim: A Step-by-Step Guide for Businesses
- Cyber Insurance Renewal Checklist: How to Prepare, What Underwriters Want, and How to Get Better Terms
- MFA Implementation Guide for SMBs and MSPs
- Cyber Insurance Exclusions: What Most Policies Won’t Cover
This guide is for informational purposes only and does not constitute legal or insurance advice. IR plan requirements, notification obligations, and carrier expectations vary by policy and jurisdiction. Consult a licensed insurance professional and qualified legal counsel for guidance specific to your situation.