By Ryan Windt | Head of Growth Marketing | Updated June 2026
The businesses that come through a cyber incident in one piece are almost never the ones with the best technology. They are the ones who decided who does what before the phone ever rang. When ransomware hits or a fraudulent wire goes out, the difference between a contained event and a runaway crisis is whether someone can pull up a plan and start executing, or whether the first thirty minutes are spent arguing about who to call.
A cyber incident response plan is that document. It defines the people, the sequence, and the decisions in advance, so that the worst day does not also become the most disorganized one. This guide walks through what the plan should contain, who belongs on the response team, what to do in the first hour, and how the plan connects to your cyber insurance policy, because the two have to work together or neither works at all.
What a Cyber Incident Response Plan Actually Is
A cyber incident response plan is a written, rehearsed set of procedures that tells your organization how to detect, contain, and recover from a security incident. It assigns roles, sets the order of operations, and removes the guesswork from a situation where every minute of hesitation has a cost.
It is worth being clear about what the plan is not. It is not your cyber insurance policy, and it is not a substitute for one. The policy is the financial backstop that pays for forensics, legal counsel, notification, and recovery. The plan is the operational playbook that determines whether you use that backstop correctly and on time. A strong policy with no plan means you will fumble the response. A strong plan with no policy means you will execute well and then absorb the full cost yourself. The two are designed to operate together.
The plan tells your team what to do. The policy pays for the people who help them do it. An incident exposes the gap between the two the moment either one is missing.
The Six Phases of Incident Response
Most credible incident response frameworks, including the widely referenced model from NIST, organize the work into a sequence of phases. The labels vary slightly between frameworks, but the underlying flow is consistent. Your plan should be built around these six stages.
| Phase | What Happens |
|---|---|
| Prepare | Build the plan, assign roles, secure the policy, run tabletop exercises, and confirm your insurer’s incident response hotline is documented and reachable. |
| Identify | Detect that something is wrong, confirm it is a genuine incident rather than a false alarm, and classify its severity. |
| Contain | Limit the spread. Isolate affected systems, preserve evidence, and stop the bleeding without destroying the forensic trail. |
| Eradicate | Remove the threat from the environment: the malware, the unauthorized access, the compromised credentials. |
| Recover | Restore systems from clean backups, validate that they are secure, and return to normal operations in a controlled sequence. |
| Review | Conduct a post-incident analysis. Document what happened, what worked, what failed, and update the plan accordingly. |
The phase most organizations underinvest in is the first one. Preparation is unglamorous and easy to defer, but it is the only phase you can complete calmly, with time to think. Every other phase happens under pressure.
Who Does What: Building Your Incident Response Team
A plan without named roles is a wish list. During an incident, ambiguity about responsibility is one of the most common causes of delay and error. Your plan should name specific people, and a backup for each, against the following functions. Industries that hold large volumes of employee data, such as staffing and PEO firms, should pay particular attention to who owns notification.
Incident Response Lead
One person owns the response and has the authority to make decisions, including the decision to take systems offline. This is usually a senior IT or security leader, or in smaller organizations, an owner or operations head working closely with the IT provider. Everyone else reports status to this person.
IT and Technical Response
The hands doing containment, eradication, and recovery. For organizations that rely on a managed service provider, this role belongs to the MSP, and the plan must specify how and when they are engaged, and who has the authority to direct them.
Legal and Compliance
Breach response carries legal and regulatory obligations that vary by state, industry, and the type of data involved. In most cyber incidents, the legal lead is breach counsel provided through your insurer’s panel, not your general corporate attorney. The plan should reflect that.
Communications
Someone owns internal updates, and someone owns external messaging to customers, partners, and where required, the public. Saying the wrong thing early, or saying nothing for too long, both create damage that outlasts the technical incident.
The Insurer’s Role on the Team
This is the function organizations most often leave out of the plan, and it is a costly omission. The moment an incident is confirmed, your insurer becomes part of the response team. Their incident response hotline connects you to the forensic and legal specialists who will run much of the response. Your plan should treat the insurer as a first call, not an afterthought.
The First Hour: A Step-by-Step Playbook
The opening hour sets the trajectory of everything that follows. Decisions made here, often by whoever happens to be available, can preserve or destroy your ability to recover and your ability to collect on a claim. Build this sequence into your plan.
- Confirm and classify. Verify that this is a real incident and assess its scope and severity. Do not trigger a full response for a false alarm, but do not minimize a genuine one.
- Notify your incident response lead. The designated lead takes control and begins coordinating. Status flows to one person.
- Call your insurer’s incident response hotline. Before engaging any outside vendor, before paying anyone, before making promises to customers. This call protects both your response quality and your coverage.
- Contain without destroying evidence. Isolate affected systems, but do not wipe or rebuild anything yet. Forensics depends on preserving the environment as the attackers left it.
- Preserve and document. Start a timeline. Log what was discovered, when, by whom, and every action taken. This record matters for both forensics and the claim.
- Hold external communications. Do not notify customers, regulators, or the public until breach counsel has assessed your obligations. Premature notification can create liability and complicate the legal response.
The single most expensive first-hour mistake is engaging your own forensic or recovery vendor before calling the insurer. Most policies require the use of panel vendors or prior carrier approval, and unauthorized vendor costs are frequently denied.
Where Your Insurer Fits Into the Plan
An incident response plan that ignores the insurance policy will work against itself at claim time. Three connection points have to be written into the plan.
The hotline is the first call. Cyber policies provide a 24/7 incident response line that activates a panel of pre-vetted, pre-contracted forensic firms, breach counsel, and notification specialists. These are people your insurer already has relationships and rates with. Calling them first is both faster and a coverage requirement.
Vendor approval is a coverage condition. Engaging your own vendors before getting carrier approval is one of the most common ways businesses void otherwise valid coverage. If you have vendors you prefer to use, the time to get them approved is during the preparation phase, not mid-incident. For a fuller breakdown of how response costs are covered, see what your cyber insurance policy actually covers for incident response.
Notification windows are tight. Most policies require you to report a known or reasonably suspected covered incident within a defined window, often 30 to 60 days of discovery, and some claims-made policies are stricter. Late notice is a frequent reason for denial. Your plan should make insurer notification an early, non-negotiable step. If a claim follows, how to file a cyber insurance claimwalks through what comes next.
Scenario Playbooks: Ransomware and Business Email Compromise
A general plan is a strong foundation, but the two incidents most likely to hit a business deserve their own short playbooks, because they unfold differently and the early moves diverge.
Ransomware
Systems are encrypted and a demand appears. The instinct to either pay immediately or wipe and rebuild are both wrong as a first move. The plan should be: isolate affected systems to stop spread, preserve the environment for forensics, and call the insurer hotline before any contact with the attacker. Ransom payment decisions involve legal, regulatory, and sanctions considerations that breach counsel must guide. Recovery proceeds from validated clean backups, never by trusting a decryption key alone. Coverage specifics for payments and extortion costs are covered in does cyber insurance cover ransomware payments.
Business Email Compromise
An attacker gains access to email and either redirects a payment or impersonates an executive to authorize a fraudulent transfer. Speed matters more here than almost anywhere else, because funds can sometimes be recalled if the bank is alerted within hours. The plan should be: contact the bank’s fraud department immediately, notify the insurer, preserve the email evidence, and reset credentials across the environment. Note that recovery of stolen funds often falls under social engineering or funds transfer coverage, which frequently carries a separate, lower sublimit. The mechanics are covered in social engineering and funds transfer fraud coverage.
Testing the Plan: Tabletop Exercises
A plan that has never been tested is a hypothesis. A tabletop exercise is a structured walkthrough where the response team is presented with a realistic scenario and works through their decisions in real time, without touching live systems. It surfaces the gaps that look invisible on paper: the role with no named backup, the hotline number nobody can find, the assumption that someone else was handling notification.
Run a tabletop at least annually, and after any significant change to your systems or team. Underwriters increasingly ask whether you test your plan, because a tested plan is a strong signal of genuine readiness rather than a document written once and filed away. Demonstrating that you run these exercises can affect how your risk is assessed at renewal. The broader set of controls underwriters evaluate is covered in the security controls underwriters check before they quote you.
Common Mistakes That Undermine Both Response and Coverage
- No named roles. A plan that says “IT will handle it” is not a plan. Name people and backups.
- Engaging vendors before calling the insurer. The fastest way to turn a covered loss into an uncovered one.
- Destroying evidence during containment. Wiping or rebuilding too early eliminates the forensic trail and can complicate both recovery and the claim.
- Missing the notification window. Late notice to the insurer is a leading cause of denial. Build it into the first hour.
- Premature external communication. Notifying customers or the public before counsel assesses obligations creates avoidable liability.
- Never testing the plan. An untested plan fails in exactly the ways a tabletop would have revealed.
Cyber Incident Response Plan Template: What to Include
Use the following as the skeleton of your written plan. Each section should be filled in with names, numbers, and specifics for your organization, not left generic.
| Section | What to Document |
|---|---|
| Roles and contacts | Named response lead and backup, IT or MSP contacts, communications owner, and the insurer’s 24/7 hotline number. |
| Incident classification | Definitions and severity tiers so the team can quickly agree on how serious an event is. |
| First-hour checklist | The step-by-step sequence above, adapted to your environment. |
| Scenario playbooks | Specific procedures for ransomware, business email compromise, and any threats unique to your industry. |
| Insurer and vendor protocol | When to call the hotline, the vendor approval requirement, and the notification window from your policy. |
| Communications templates | Pre-drafted internal and external messages, to be released only after counsel approval. |
| Recovery procedures | Backup locations, restoration sequence, and validation steps before returning systems to production. |
| Post-incident review | A standing process to capture lessons and update the plan after every incident and every tabletop. |
Frequently Asked Questions
What is the first thing I should do if I suspect a cyber incident?
Confirm it is genuine, notify your incident response lead, and call your insurer’s incident response hotline before engaging any outside vendor. That hotline connects you to the forensic and legal specialists who will guide the response, and calling first protects your coverage.
How is an incident response plan different from my cyber insurance policy?
The plan is the operational playbook for who does what during an incident. The policy is the financial backstop that pays for the response. They are designed to work together: the plan tells your team to call the insurer, and the policy funds the experts who help execute the plan.
How often should we update and test the plan?
Review the plan at least annually and after any major change to your systems or team. Run a tabletop exercise on the same cadence. Underwriters increasingly view regular testing as evidence of genuine readiness.
Do we need an incident response plan if we have a managed service provider?
Yes. Your provider handles technical response, but the plan must define when and how they are engaged, who has authority to direct them, and how legal, communications, and insurer notification are handled. Those responsibilities extend beyond what most providers cover by default.
What happens if we engage our own forensic firm before calling the insurer?
Most policies require the use of panel vendors or prior carrier approval, and costs from unapproved vendors are frequently denied. If you have a preferred vendor, get them approved during the preparation phase so they are cleared before an incident occurs.
Related Resources
- What Your Cyber Insurance Policy Actually Covers for Incident Response
- How to File a Cyber Insurance Claim
- What Happens After You File a Cyber Insurance Claim
- Cyber Insurance Sublimits Explained
- Does Cyber Insurance Cover Ransomware Payments?
- Social Engineering and Funds Transfer Fraud Coverage
- The Security Controls Underwriters Check Before They Quote You
A response plan is only as useful as the coverage standing behind it. If you want to make sure your policy and your plan actually work together when it matters, talk to our team about building coverage around how your business operates.