IT incident response: how to plan, prepare, and execute when a breach occurs

According to the 2026 Kaseya State of the MSP Report, 44% of MSPs report that at least 10% of their clients experienced a cyberattack in 2025. That figure makes a tested, documented incident response plan a commercial necessity for anyone with IT security responsibility, not a theoretical best practice.

Security incidents are a question of when, not if. Organizations that accept this reality and build incident response capability before they need it contain damage faster and recover more completely than those who try to build a response in the middle of an active attack. IBM’s 2025 Cost of a Data Breach Report found that the average breach goes undetected for 181 days and takes another 60 days to contain. Companies with no formal incident response plan pay 58% more per breach than those with structured, tested response protocols. Companies without a dedicated incident response team experience breach costs that are $2.66 million higher than those with one in place.

The difference between a well-handled security incident and a catastrophic one usually is not the quality of the defenses that were breached. It is the quality of the response that followed.

What is incident response?

Incident response (IR) is the structured process for detecting, containing, eradicating, and recovering from security incidents. It provides the operational framework for coordinated action when something goes wrong, preventing the paralysis and improvisation that characterize poorly handled incidents.

A security incident is any event that threatens the confidentiality, integrity, or availability of information or systems. That includes ransomware attacks, data breaches, account compromises, business email compromise, insider threats, denial-of-service attacks, and any other security event requiring coordinated organizational response.

Incident response is not the same as incident prevention. Prevention reduces the probability that incidents occur. Incident response determines what happens when they do, and given that 48% of SMBs have experienced a cyberattack and 53% have no formal incident response plan in place, the gap between exposure and readiness is wide.

The incident response lifecycle

The NIST framework describes incident response in four phases. Understanding each phase is the starting point for building a plan that functions under pressure.

Preparation is everything done before an incident occurs: building the IR plan, establishing the IR team, acquiring and configuring detection and response tools, creating communication templates, and testing the plan through exercises. Preparation determines whether an organization can respond coherently when an incident happens. Most IR failures trace back here, not to the response itself.

Detection and analysis covers identifying that an incident has occurred and understanding its nature and scope. Detection may come from security monitoring tools, end-user reports, threat intelligence alerts, or third-party notification. Analysis determines what happened, what systems are affected, what data may have been accessed or exfiltrated, and what the threat actor’s objectives appear to be. Getting this phase right determines everything downstream: containment decisions, notification obligations, and recovery sequencing all depend on an accurate picture of what actually happened.

Containment, eradication, and recovery addresses stopping the spread of the incident, removing the threat from the environment, and restoring normal operations from a known-clean state. These three steps often overlap in practice and require careful sequencing. Premature recovery before eradication is complete leaves the threat actor in place, a mistake that turns a single incident into a prolonged compromise.

Post-incident activity covers documenting what happened, identifying lessons learned, updating controls and processes to prevent recurrence, and completing any required regulatory reporting. The post-incident review is where the next incident’s prevention begins. Organizations that skip it lose the most valuable output of the entire response.

Building an incident response plan

An incident response plan is not a compliance document that sits in a shared drive. It is an operational playbook that people use under pressure, often at night, often with incomplete information and elevated stress. Effective plans are built around what actually needs to happen in that moment.

Clear roles and responsibilities. Who declares an incident? Who leads the technical response? Who handles client and stakeholder communication? Who engages external resources such as forensic firms, cyber insurance, and legal counsel? These decisions made in advance prevent the leadership vacuum that characterizes poor incident responses. 60% of organizations lack a clear communication plan during a cyber incident, and those with poor internal communication experience 33% longer breach containment times.

Contact lists that are current and accessible offline. The IR plan must include contact information for the IR team, relevant vendors, cyber insurance policy details, external legal counsel, and relevant regulatory bodies. These contacts need to be accessible without depending on the systems that may be compromised. Printed copies and offline storage are not optional, they are essential.

Playbooks for common incident types. Ransomware, business email compromise (BEC), data breach, and insider threat each have different response sequences. Pre-built playbooks provide the structure that prevents important steps from being missed under pressure. The phishing incident response sequence, for example, has specific steps around credential reset, session revocation, and mail gateway review that differ from a ransomware response. See Kaseya’s phishing incident response guide for a worked example of scenario-specific playbook structure.

Communication templates. Under incident conditions, time available to draft communications to employees, clients, regulators, or media is limited. Pre-drafted templates for common scenarios, reviewed in advance with legal and communications guidance, allow appropriate messaging to be issued quickly without template creation during a live crisis.

Tested recovery procedures. The recovery phase depends on clean, tested backups and documented restoration procedures. Recovery procedures that have never been tested are unknown quantities precisely when they matter most. Organizations that conduct IR testing at least twice a year reduce breach costs by an average of $1.49 million. Yet 70% of businesses rarely or never test their IR plans at all.

Download the Elements of an Incident Response Plan checklist for a structured reference to what a complete IR plan must include, or the How to Build an Incident Response Plan eBook for a step-by-step walkthrough of the build process.

Incident response for MSPs

MSPs face a more complex incident response environment than single-organization IT teams, and the stakes compound with every client in the portfolio.

Multi-client exposure. An incident affecting the MSP’s own infrastructure may simultaneously expose client environments. Conversely, a client-side incident can propagate through the MSP’s management tooling if access controls are not properly segmented. IR planning must account for both directions: the MSP as victim and the MSP as the vector. Rapid assessment across all client environments, triggered by any significant incident on the MSP side, needs to be a documented procedure.

Client-specific notification obligations. Different clients have different contractual notification requirements, different regulatory frameworks, and different risk tolerances. A healthcare client has HIPAA obligations with specific timelines. A financial services client may have state-level requirements. An EU-based client has GDPR’s 72-hour supervisory authority notification window. The IR plan needs per-client incident response considerations built in, not a single generic template applied to every engagement.

RMM platform incidents. A compromise of the MSP’s RMM platform is the highest-severity incident type the MSP can face. The IR plan must specifically address this scenario: how to detect unauthorized RMM access, how to disable that access while assessing scope without losing visibility into client environments, how to communicate to clients, and how to verify that client environments were not affected. This scenario should have its own dedicated playbook.

Evidence preservation. Some clients may have legal hold requirements that affect what can be done with compromised systems before forensic imaging. Legal counsel should be part of IR planning, not only brought in during an active incident.

RMM and SIEM as response enablers. During an active incident, the MSP’s ability to isolate affected endpoints remotely, pull system logs, revoke access, and push remediation steps at speed is the operational advantage that justifies the managed services model. An MSP that cannot do these things at scale, across multiple client environments, during a live incident is in a structurally difficult position.

Tabletop exercises: testing before you need it

A plan that has never been tested is a hope. Tabletop exercises are structured walkthroughs of incident scenarios with the IR team that reveal gaps in plans, identify decision-making bottlenecks, and build the muscle memory that allows coherent response under pressure.

Only 35% of businesses run cybersecurity tabletop exercises, even though simulations significantly improve response times. Organizations that conduct IR testing at least twice a year reduce breach costs by $1.49 million on average. The return on a few hours of annual exercise time is direct and measurable.

A ransomware tabletop exercise, for example, works through: How is initial detection identified? Who makes the decision to isolate affected systems? What is the client notification sequence and who owns it? When is external forensics engaged? What decisions require executive sign-off? How long does recovery take from clean backup and what is the business impact during that window? What regulatory notification obligations are triggered and when?

The answers to these questions, worked through in advance in a low-pressure environment, are measurably better than the answers reached during an actual incident at 2am. Annual tabletop exercises are the minimum. Twice a year is better. The 5 Tips for Incident Response Plan resource covers practical guidance on making exercises productive rather than perfunctory.

Regulatory notification requirements

Most data breach incidents carry regulatory notification obligations with defined timelines that are tight and non-negotiable. The investigation phase of incident response must determine quickly whether notification obligations are triggered, so notification infrastructure needs to be in place before an incident occurs, not built during one.

GDPR (EU/UK). Supervisory authority notification is required within 72 hours of becoming aware of a breach likely to result in risk to individuals. Notification to affected individuals is required where there is high risk to their rights and freedoms.

HIPAA (US healthcare). Notification to affected individuals within 60 days of discovery. HHS notification within 60 days. Media notification for breaches affecting more than 500 residents of a given state.

US state breach notification laws. All 50 US states have breach notification laws with varying timelines and scope. Multi-state organizations need to understand which laws apply based on where affected individuals reside. These requirements vary materially in timeline, content, and notification thresholds.

NIS2 (EU). Significant incidents must be reported to the relevant national authority within 24 hours as an initial warning and within 72 hours as a full notification.

These timelines do not allow for improvised communication planning. When a breach notification window opens, the message, the contact list, the regulatory submission process, and the internal approval chain all need to already exist. Building them under time pressure during an active incident is how organizations miss deadlines and incur regulatory penalties on top of the breach itself.

The detection layer your IR plan depends on

An incident response plan is only as effective as the detection capability feeding it. A plan that activates 72 hours after a breach began is not incident response. It is damage assessment.

The average breach goes undetected for 181 days. Organizations with AI-powered detection systems identify breaches 80 days faster and save $1.9 million compared to those relying on manual detection. Breaches contained within 200 days cost $1.14 million less than those taking longer. Detection speed is directly and measurably linked to breach cost.

Kaseya SIEM provides the early detection layer that gives IR plans a chance to work. By correlating signals across endpoint, network, cloud, identity, and email from more than 60 data sources, it surfaces the attack picture before damage spreads, triggering automated containment actions in minutes rather than waiting for a technician to investigate an alert.

For organizations running the IR plan internally, SIEM provides the platform. For those who need 24/7 coverage without in-house staffing, Kaseya’s managed SOC service, accelerated by Kaseya Intelligence, delivers the monitoring and response capability at scale. Explore Kaseya SIEM.