An incident response plan is a documented, tested set of procedures that defines who does what and when a security incident occurs. Without one, a breach turns into chaos — delayed containment, confused communication, destroyed evidence, regulatory violations, and reputational damage that could have been avoided.
The organizations that survive breaches aren’t necessarily the ones with the best technology. They’re the ones who planned, practiced, and knew what to do when the alarm went off.
Before a Breach: Building Your Incident Response Program
The time to build your incident response capability is before you need it. Trying to figure out roles, procedures, and communication plans during an active incident is like writing a fire evacuation plan while the building is burning.
Establish Your Incident Response Team
Define who is on your Incident Response Team (IRT) and what each person’s role is. At minimum, your IRT needs an incident commander who owns decision-making and coordinates the overall response, a technical lead who handles containment, investigation, and remediation. This communications lead manages internal and external messaging, a legal representative who advises on regulatory obligations and liability, and an executive sponsor who authorizes resources and makes business-impact decisions.
For organizations without dedicated security staff, a CISO-as-a-Service provider fills the technical lead and incident commander roles, bringing experience from managing incidents across multiple organizations.
Document Your Response Procedures
Your incident response plan should cover these phases: preparation (everything you’re doing now), detection and analysis (how you identify and classify incidents), containment (how you stop the incident from spreading), eradication (how you remove the threat from your environment), recovery (how you restore normal operations), and post-incident review (how you learn from what happened).
For each phase, document the specific steps, who’s responsible, which tools are used, and the escalation criteria. The plan must be specific enough that someone can follow it under pressure — not a high-level document full of generalities.
Build Playbooks for Common Scenarios
Generic incident response plans break down when they meet specific threats. Build targeted playbooks for the scenarios most likely to affect your organization. Ransomware is the most critical — your ransomware playbook should cover isolation procedures, backup verification, communication protocols, law enforcement notification, and decision criteria for whether to pay or not.
Other playbooks to consider: phishing compromise (credentials stolen via phishing email), insider threat (employee misuse or theft of data), vendor breach (a third party with access to your data is compromised), data exposure (sensitive data accidentally made public), and business email compromise (executive email impersonation leading to fraudulent transactions).
Establish Communication Plans
Know who needs to be notified and how before an incident occurs. Internal communication should cover how the IRT is activated, how leadership is briefed, and how employees are informed. External communication should address customer notification, regulatory reporting timelines, law enforcement contact, media response, and insurance carrier notification.
HIPAA requires breach notification within 60 days. Many state laws have similar timelines. DoD contracts require reporting within 72 hours. Know your specific obligations before you need to meet them.
Test Through Tabletop Exercises
A plan that hasn’t been tested is a theory. Tabletop exercises walk your IRT through a simulated incident scenario — not on live systems, but around a conference table or video call — to practice decision-making, identify gaps in procedures, and build team familiarity with the plan.
Run tabletop exercises at least twice per year, rotating through different scenarios. After each exercise, document lessons learned and update your plan accordingly. The goal isn’t perfection — it’s building the muscle memory so that when a real incident hits, your team’s response is practiced rather than improvised.
During a Breach: Executing Your Plan
When an incident is detected, speed and discipline matter more than anything else. Here’s how the response should flow.
Detection and Analysis
First, confirm that an incident is actually occurring. Not every alert is a breach. Your team needs to assess the alert, gather initial evidence, and determine the scope and severity. Classify the incident based on your predefined severity levels — this determines the escalation path and resource commitment.
Document everything from the start. Timestamps, actions taken, evidence collected, decisions made. This documentation is critical for post-incident review, legal proceedings, and regulatory reporting.
Containment
The priority is stopping the incident from spreading. Short-term containment means isolating affected systems to prevent lateral movement — taking compromised machines off the network, disabling compromised accounts, and blocking malicious IP addresses. Long-term containment means applying temporary fixes that allow business operations to continue while you prepare for full eradication.
Critical rule: do not shut down compromised systems unless necessary. Powering down a system destroys volatile memory data — running processes, network connections, and cached credentials — that your forensic investigation needs. Isolate systems from the network instead.
Also, avoid logging into compromised systems with domain administrative credentials. If the threat actor is still present, you’ve just handed them the keys to your entire environment.
Eradication
Once contained, remove the threat completely. This means identifying the root cause — how did the attacker get in? — and eliminating it. Remove malware, close the vulnerability that was exploited, reset compromised credentials, and verify that no backdoors or persistence mechanisms remain.
Eradication often requires forensic analysis. Your IRT will need to collect volatile data using forensic tools, examine logs to piece together the timeline of events, and look for external intelligence that helps identify the nature and scope of the threat.
Recovery
Restore affected systems from known-good backups. Verify that backups are clean — restoring from an infected backup reinfects your environment. Bring systems back online in phases, monitoring closely for signs of re-compromise. Validate that security controls are functioning properly before declaring recovery complete.
Recovery also means communicating with stakeholders. Update leadership on the status. Notify affected customers if required. File regulatory reports within required timelines. Contact your cyber insurance carrier to initiate a claim if applicable.
After a Breach: Learning and Improving
The post-incident phase is where most organizations fail — not because the breach itself was catastrophic, but because they don’t learn from it.
Conduct a Post-Incident Review
Within two weeks of incident resolution, bring the IRT together for a structured review. Cover what happened and when, how the incident was detected, how the response plan performed, what worked well, what didn’t work, what you would do differently, and what changes are needed to prevent recurrence.
This review must be blame-free. The goal is improvement, not punishment. If people fear consequences for honest reporting, they’ll hide problems, and your program won’t improve.
Update Your Plan
Every incident teaches you something. Update your incident response plan, playbooks, and communication procedures based on lessons learned. If the tabletop exercises didn’t prepare your team for what actually happened, redesign them. If a tool failed during the response, find an alternative. If communication broke down, fix the process.
Strengthen Your Defenses
Address the root cause. If the attacker got in through a phishing email, improve email security and training. If they exploited an unpatched vulnerability, strengthen your vulnerability management program. If they used stolen credentials, implement stronger authentication. Every incident is an opportunity to close a gap that existed before.
How CISOSHARE Supports Incident Response
CISOSHARE’s incident management program services help organizations build, test, and maintain incident response capabilities. Their approach starts by understanding your overall business structure and goals, reviewing existing incident management policies and response plans against organizational requirements, best practices, and regulatory requirements.
Their team gathers existing documentation, conducts interviews with stakeholders and executive delegates to understand current processes, and provides a gap analysis highlighting what needs to be addressed. From there, they design response playbooks tailored to your specific threat landscape — including ransomware-specific playbooks that cover isolation, communication, and recovery procedures.
As part of their managed security services under the Operate model, CISOSHARE provides ongoing incident readiness — ensuring your team has a plan in place and is able to respond quickly in the event of an incident. Their professional services team is also available for on-demand incident response support when critical incidents occur.
For organizations building their first incident response capability, CISOSHARE’s CISO-as-a-Service model integrates incident response planning into the broader security program — connecting it to risk management, vulnerability management, and vendor oversight so that your response capability is part of a cohesive security strategy, not a standalone document.
FAQ
How often should we test our incident response plan?
At least twice per year through tabletop exercises, with a full plan review annually. Test after any significant organizational change, technology change, or actual incident. Regular testing is what separates plans that work from plans that exist only on paper.
Do we need a dedicated incident response team?
You need defined roles, but they don’t need to be full-time incident response positions. Most mid-size organizations assign incident response roles to people with other primary responsibilities. A CISO-as-a-Service provider can fill the technical leadership role and coordinate your internal team during an incident.
What should we do if we discover a breach right now and don’t have a plan?
Isolate affected systems from the network immediately — do not power them off. Contact legal counsel. Engage a professional incident response provider. Do not communicate externally until you understand the scope. Begin documenting everything. Then, once the incident is resolved, build the plan you should have had before.
