Incident Response Plan: How to Build One That Actually Works

Most breaches get worse because no one knows who is supposed to do what in the first hour. An incident response plan fixes that by defining the phases, roles, and decisions before an attack happens, not during one. This covers the six standard phases, the frameworks behind them, and how to run each step inside a Microsoft security stack.

‍

What Is an Incident Response Plan?

An incident response plan is a documented set of procedures that defines how an organization detects, contains, and recovers from a security incident. It assigns roles, sets escalation paths, and lays out the exact steps your team follows when something goes wrong, so decisions are made in advance instead of during a live attack.

The plan turns a chaotic event into a repeatable process. Without one, teams improvise under pressure, lose time deciding who owns which action, and often make containment mistakes that widen the damage. A written plan removes that guesswork by answering three questions before an incident starts: what counts as an incident, who responds, and what they do at each stage.

Most incident response plans are built on one of two established frameworks. The NIST framework (from the National Institute of Standards and Technology) uses four phases, while the SANS Institute model uses six steps. Both cover the same ground and are widely treated as the industry standard, which is why nearly every credible plan maps back to one of them.

‍

Why Your Business Needs an Incident Response Plan

A business needs an incident response plan because the speed and quality of its response directly determine how much a breach costs. Organizations that identify and contain incidents faster spend less on recovery, and a plan is what makes fast containment possible.

The financial case is clear. According to IBM's Cost of a Data Breach Report 2025, the global average cost of a data breach was 4.4 million USD. That figure was a 9% decrease over the prior year, and IBM attributes the drop to faster identification and containment. In other words, the organizations that cut their costs are the ones that responded quickly, which is exactly what a plan is built to enable. Every additional day an attacker stays in your environment adds cost through downtime, data loss, and remediation.

For SMBs and mid-market companies, the stakes are sharper than the global average suggests. A large enterprise can absorb a multi-million-dollar breach and keep operating. A 200-person business often cannot absorb days of downtime, a ransomware demand, and the customer trust lost when a breach becomes public. Smaller teams also have fewer people to run the response, which makes a documented plan more important, not less, because it lets a lean team act without waiting on a single overloaded expert.

What happens without a plan

Without a plan, the first hour of an incident is spent figuring out who is in charge instead of stopping the attack. That delay is where most of the damage happens.

The pattern is predictable. Alerts get noticed late because no one owns monitoring. Once an incident is confirmed, staff argue over whether to shut systems down or keep them running. Containment actions happen out of order, so attackers move laterally before anyone isolates the affected machines. Communication breaks down, leadership hears about it too late, and regulatory notification deadlines get missed. Each of these is a decision a plan would have made in advance.

‍

Common Types of Security Incidents

A security incident is any event that compromises the confidentiality, integrity, or availability of your systems or data. Most incidents that trigger a response fall into a handful of recognizable categories, and your plan should account for each one because they demand different containment actions.

The most common types are:

• Ransomware. Attackers encrypt your files and demand payment to release them. This is the incident most likely to halt operations outright, which is why containment speed matters most here.
• Phishing and business email compromise (BEC). Attackers trick employees into handing over credentials or approving fraudulent payments. BEC is one of the costliest categories because it exploits trust rather than technology.
• Malware. Malicious software, including trojans, spyware, and worms, installed to steal data, damage systems, or open a foothold for a larger attack.
• Distributed denial-of-service (DDoS). Attackers flood your systems with traffic to knock services offline, often as a distraction or as leverage for extortion.
• Insider threats. A current or former employee, contractor, or partner misuses legitimate access, whether maliciously or by accident.
• Unauthorized access and credential compromise. Stolen or guessed credentials let an attacker log in as a legitimate user, which is often the entry point for the incidents above.

These categories overlap in practice. A single cyber attack incident response plan has to handle a chain of events, for example a phishing email that steals credentials, which then enable unauthorized access, which ends in ransomware. Recognizing the type early tells your team which containment steps to run first.

‍

The 6 Phases of Incident Response

The six phases of incident response are preparation, identification, containment, eradication, recovery, and lessons learned. This model comes from the SANS Institute and forms the backbone of most incident response plans. For a deeper walkthrough of each stage, see our guide to the full incident response life cycle. Each phase has a clear goal, and skipping or rushing one is where responses tend to fail.

To show how the phases connect, this section follows a single ransomware scenario through all six steps.

1. Preparation

Preparation is the work you do before an incident to make sure your team can respond effectively. It is the only phase that happens outside a live attack, and it is the one that most determines the outcome.

Preparation covers the practical groundwork: writing the plan itself, defining roles, setting up detection tools, maintaining tested backups, and running tabletop exercises so the team has rehearsed the response. In our ransomware scenario, preparation is what ensures clean offline backups already exist, so recovery is possible without paying the attacker.

2. Identification (Detection and Analysis)

Identification is the phase where you confirm that a security incident is actually happening and determine its scope. The goal is to separate real incidents from routine alerts, then understand what you are dealing with.

This means analyzing alerts, logs, and system behavior to answer key questions: what was affected, how the attacker got in, and how far they have spread. Strong SOC monitoring and incident response is what makes fast, accurate identification possible. In the ransomware scenario, this is the point where your team spots unusual file encryption activity, confirms it is not a false alarm, and identifies which endpoints and file shares are affected.

3. Containment

Containment is the phase where you stop the incident from spreading while preserving evidence for investigation. The priority is to limit damage without destroying the information you will need later.

Containment usually happens in two stages. Short-term containment isolates affected systems immediately, for example by disconnecting infected machines from the network. Long-term containment applies temporary fixes that let clean systems keep running while you prepare to remove the threat. In the ransomware scenario, containment means isolating every encrypted endpoint and disabling compromised accounts before the malware reaches the backups or spreads to more shares.

4. Eradication

Eradication is the phase where you remove the threat completely from your environment. Containment stops the bleeding; eradication removes the cause. This includes deleting malware, closing the vulnerability or entry point the attacker used, and removing any persistence mechanisms like backdoors or unauthorized accounts. In the ransomware scenario, eradication means wiping the infected systems, eliminating the malware and any footholds, and confirming the attacker no longer has access before anything is reconnected.

5. Recovery

Recovery is the phase where you restore affected systems to normal operation and confirm they are clean. The goal is to get the business running again without reintroducing the threat.

Recovery involves restoring data from trusted backups, rebuilding systems, monitoring closely for signs the attacker returns, and validating that everything works as expected before going fully live. In the ransomware scenario, recovery is where you restore files from the offline backups preserved during preparation, verify the systems are clean, and bring operations back online in a controlled way.

6. Lessons Learned (Post-Incident Review)

Lessons learned is the phase where you review the incident to understand what happened and improve your response for next time. It is the phase most often skipped, and skipping it means repeating the same mistakes.

Within a set period after the incident closes, typically two weeks, the team documents the timeline, identifies what worked and what did not, and updates the plan accordingly. In the ransomware scenario, this review might reveal that the initial phishing email should have been caught earlier, leading to stronger email filtering and a change to the plan. This feeds directly back into preparation, which is what makes incident response a cycle rather than a one-time event.

‍

NIST vs SANS Incident Response Frameworks

The main difference between NIST and SANS is that NIST uses four phases while SANS uses six, but the two frameworks describe the same process. NIST groups several steps together that SANS breaks out separately, so a plan built on one is easily mapped to the other.

NIST comes from the National Institute of Standards and Technology and is published in its Special Publication 800-61. It combines detection, containment, eradication, and recovery into a single core phase. SANS, from the SANS Institute, separates those into distinct steps, which makes it more granular and often easier for teams to follow operationally. Neither is more correct; NIST is frequently referenced for compliance and audit, while SANS is favored for hands-on execution.

Here is how the two frameworks map to each other:

The takeaway is that the framework you choose matters less than following it consistently. Both cover the full lifecycle from preparation through post-incident review, and both treat incident response as a repeating cycle rather than a linear checklist.

‍

Key Roles in an Incident Response Team

An incident response team, sometimes called a CSIRT (Computer Security Incident Response Team), is the group responsible for executing the plan when an incident occurs. Every role needs a named owner and a backup, so the response does not stall if one person is unavailable.

The core roles are:

• Incident manager. Owns the response end to end, makes the containment and escalation decisions, and keeps the team coordinated. This is the single point of accountability during an incident.
• Security analyst. Investigates the alert, determines scope, and carries out the technical detection and analysis work through each phase.
• IT and infrastructure lead. Handles the hands-on system actions: isolating machines, restoring from backups, and rebuilding affected environments.
• Legal counsel. Advises on liability, evidence handling, and whether regulatory or contractual notification obligations are triggered.
• Communications or PR lead. Manages internal updates and any external messaging to customers, partners, and the public.
• Executive sponsor. Provides authority and budget, approves high-stakes decisions like taking systems offline, and acts as the link to leadership.

In smaller businesses, one person often covers several of these roles. That is fine, as long as the plan names who holds each responsibility rather than assuming everyone knows. If filling these roles internally is not realistic, comparing MDR vs SOC helps you decide whether to outsource detection and response instead.

Escalation and Communication Procedures

Escalation procedures define who gets notified, in what order, and how quickly, as an incident grows in severity. The goal is to get the right people involved at the right time without flooding everyone on every alert.

A clear escalation path ties severity levels to specific actions. A low-severity incident might stay with the security analyst, while a confirmed ransomware attack immediately escalates to the incident manager, executive sponsor, and legal. What leadership needs to hear differs from what the technical team tracks, which is why executive-level reporting during an incident should focus on business impact and decisions, not technical detail. Communication procedures sit alongside this and cover how the team talks during an incident, ideally over a channel separate from the systems that may be compromised.

Regulatory Notification Requirements

Regulatory notification requirements are legal obligations to report a breach to authorities or affected individuals within a set timeframe. Missing these deadlines can result in fines on top of the breach itself, which is why your plan should treat notification as a defined step, not an afterthought.

The requirements depend on your data and where you operate:

• GDPR. Organizations handling EU personal data must report a qualifying breach to the relevant supervisory authority within 72 hours of becoming aware of it.
• HIPAA. Healthcare organizations handling protected health information in the US must notify affected individuals, and in some cases regulators, within defined timeframes.
• PCI-DSS. Businesses handling payment card data must follow the notification and reporting obligations set by the card brands and their acquiring bank.

Legal counsel should confirm which of these apply at the start of an incident, because the clock on some deadlines starts the moment the breach is discovered.

‍

Incident Response Plan Template: What to Include

An incident response plan template is a reusable document structure that lays out every section your plan needs, so you fill in the details rather than start from a blank page. A working template covers the roles, procedures, and contacts your team reaches for during an incident, all in one place.

A complete incident response plan template should include:

• Purpose and scope. What the plan covers, which systems and data it applies to, and what counts as an incident worth activating it.
• Roles and responsibilities. The named owner and backup for each role on the incident response team, with contact details.
• Incident classification. Severity levels that define how serious an incident is and which response each level triggers.
• The six response phases. Step-by-step procedures for preparation, identification, containment, eradication, recovery, and lessons learned.
• Escalation and communication plan. Who gets notified at each severity level, through which channel, and who is authorized to communicate externally.
• Contact list. Internal team members, executive sponsors, legal counsel, and external parties like your managed security provider, cyber insurer, and law enforcement.
• Regulatory notification checklist. Which obligations apply, their deadlines, and who confirms them during an incident.
• Tools and access. The systems, logs, and credentials the team needs, and where to find them.
• Post-incident review template. A standard format for documenting the timeline, findings, and plan updates after each incident.

Keep the plan short enough that people will actually read it under pressure. A tight, well-organized document beats a long one that no one opens during an incident.

‍

How to Build an Incident Response Plan Step by Step

Building an incident response plan means turning the template above into a document your team can actually run. The process below covers how to create the plan, not how to respond to an incident, which is what the six phases handle.

Follow these steps:

1. Identify your critical assets and risks. List the systems, data, and services that would hurt most if compromised. This tells you what the plan needs to protect first and which incidents to prioritize.
2. Define what counts as an incident. Set clear criteria and severity levels, so your team knows when to activate the plan and how hard to respond.
3. Assign roles and backups. Name the owner and a backup for each role on the incident response team. In a smaller business, assign one person to several roles rather than leaving gaps.
4. Document the response procedures. Write out the steps for each of the six phases, specific to your environment and tools. Keep them concrete enough to follow under pressure.
5. Set escalation and communication paths. Map each severity level to who gets notified and how, and confirm which regulatory notifications may apply.
6. Build your contact list and toolkit. Gather internal and external contacts, and confirm the team has access to the logs, systems, and backups they will need. If a managed provider is part of your response, knowing how to evaluate a provider's live incident response before you sign matters as much as the plan itself.
7. Test the plan. Run a tabletop exercise that walks the team through a realistic scenario. Testing surfaces the gaps a document review never will.
8. Review and update regularly. Revisit the plan at least annually and after any real incident, so it keeps pace with changes to your systems and team.

The plan is never finished. Treat it as a living document that improves with every test and every incident, which is exactly what the lessons learned phase feeds back into.

‍

Running Incident Response in a Microsoft Environment

In a Microsoft environment, incident response runs on Microsoft Sentinel, Microsoft Defender XDR, and Microsoft Entra ID, which together cover detection, containment, and identity lockdown. If your business already runs Microsoft 365, most of the tooling for a modern response is capabilities you may already own rather than a separate stack to buy.

Here is how the core phases map to Microsoft tools:

• Detection and analysis with Microsoft Sentinel. Sentinel is Microsoft's cloud-native SIEM. It collects logs and signals from across your environment, correlates them, and raises alerts when it detects suspicious activity. This is where the identification phase happens, giving your team a single place to confirm an incident and understand its scope. CyberQuell delivers this through its Microsoft Sentinel SIEM service.
• Containment with Microsoft Defender XDR. Defender XDR extends detection and response across endpoints, email, and identities. During containment, it can isolate a compromised device from the network, contain a user, and stop malicious processes, limiting spread while your team investigates.
• Identity lockdown with Microsoft Entra ID. Many incidents start with compromised credentials. Entra ID (formerly Azure AD) lets you disable accounts, force sign-out, and require re-authentication, cutting off an attacker's access during containment and eradication.
• Automated response with Sentinel playbooks. Sentinel playbooks, built on Azure Logic Apps, automate repetitive response actions like isolating a device or disabling an account the moment a trigger fires. This is SOAR automation applied to incident response, and it speeds up containment, which is the factor IBM tied directly to lower breach costs.

The advantage of a Microsoft-native response is that these tools are already integrated. Detection in Sentinel can trigger containment in Defender and identity actions in Entra ID without stitching together separate products. For teams that want this run for them, CyberQuell provides managed detection and response through Managed XDR, covering monitoring and response around the clock.

‍

Final Thoughts 

Your incident response plan is the difference between a contained event and a business-halting breach. The decision in front of you now is simple: build and test a plan while things are calm, or improvise one during an attack when every minute adds cost. If your team is running on Microsoft 365, you already own most of the tooling to respond well. The gap is usually not the technology, but the plan and the people to run it.

CyberQuell builds and runs incident response on your existing Microsoft stack, from detection in Sentinel to containment in Defender XDR, monitored around the clock. Book a Call with Cyberquell to map your current response gaps against a real incident scenario, or explore Managed XDR to see what a fully managed response looks like.