What is incident response?
Incident response is a strategic approach to detecting and responding to cyberattacks. It provides a coordinated series of procedures to help you detect, remove, and recover from threats quickly and efficiently.
The process encompasses several key elements:
Preparation measures: Documented plans, playbooks, and testing procedures
Detection capabilities: Tools and technologies for threat identification
Response protocols: Organized procedures for containment and recovery
Continuous improvement: Reviews and refinements based on lessons learned
Incident response is a part of incident management, which refers to the broader way in which you would handle an attack, involving senior management, legal teams, HR, communications, and the wider IT department.
This guide essentially focuses on incident response. But it briefly covers other aspects of incident management, as it's important an organization take a holistic approach to handling future incidents.
Let's begin by running through a few basic concepts.
What is a security incident?
Incident response teams need to act quickly in the event they're called into action. So they cannot afford time-consuming misunderstandings that can arise through the incorrect use of terminology. That's why they need to understand exactly what constitutes a security incident and how it differs from similar terms such as security event and attack.
A security event is the presence of unusual network behavior, such as a sudden spike in traffic or privilege escalation, that could be the indicator of a security breach. However, it doesn't necessarily mean you have a security issue. On further investigation, it may turn out to be a perfectly legitimate activity.
A security incident is one or more correlated security events with confirmed potential negative impact, such as the loss of or unauthorized access to data—whether deliberate or accidental.
An attack is a premeditated breach of security with malicious intent.
Types of security incident
You should be adequately prepared for different types of incidents whatever its nature. So you'll need to consider a range of scenarios. These include different types of application and underlying infrastructure—but, above all, different types of attack.
The most common of these are:
Denial-of-service (DoS): An attempt to flood a service with bogus requests, thereby making it unavailable to legitimate users.
Application compromise: An application that's been hacked, using techniques such as SQL injection, cross-site scripting (XSS), and cache poisoning, with a view to corrupting, deleting or exfiltrating data, or running other forms of malicious code.
Ransomware: A type of malware that uses encryption to block access to your data. The attacker then demands a ransom in exchange for the encryption keys.
Data breach: A security breach that specifically involves unauthorized access to sensitive or confidential data.
Man-in-the-middle (MitM): A modern-day form of wiretapping where an adversary covertly intercepts the data exchange between two parties and manipulates the communication between them.
You should develop a deep understanding into the different types of attack and potential vulnerabilities in your systems accordingly. This will help you formulate response procedures and identify tooling and technology requirements. At the same time, it will help you improve your security defenses and reduce the risk of a major incident arising in the first place.
Watch 5-minute demo
Watch the demo to learn how Wiz Defend correlates runtime activity with cloud context to surface real attacks, trace blast radius, and speed up investigation.
Watch now
Incident response in the cloud
In view of the widespread adoption of the cloud, incident response is evolving to meet the challenges brought about by new types of threat and different application deployment models.
Cloud incident response requires updated approaches as traditional procedures often fall short in dynamic cloud environments. For example, by:
Ensuring the incident response team receives sufficient training to understand your cloud-based IT environment
Implementing tooling that's specifically designed for the complex and dynamic nature of the cloud
Making use of the telemetry available from their cloud service provider (CSP)
Incident response documentation
A formally documented course of action is an essential component of any robust incident response strategy, as it provides a clear roadmap for handling incidents and ensures you're suitably equipped to do so.
As a general rule, incident response material consists of three types of document, as follows.
Incident response policy
The policy document sets the ball rolling for your initiative, serving as a broad blueprint for your incident response strategy.
It seeks buy-in from senior decision makers by putting the business case for incident response. It mandates the creation of an incident response team and a fully fledged incident response program. It should be approved by the leadership team, giving you the authority to take your mission forward.
It is a single document that provides the stepping stone to more detailed documentation geared towards the practicalities of the incident response process.
Incident response plan
The incident response plan expands upon your policy document by explaining in greater detail the measures you should have in place for handling cybersecurity incidents. It runs through the full response lifecycle with outline plans on how to:
Detect and classify a security incident
Determine the full workings of the attack
Limit the impact on your IT systems and business operations
Eliminate the threat
Recover from the incident
Furthermore, it sets out:
Preparations you'll make in anticipation of an attack
Proposals for post-incident activity for analysis and reviews
An incident response plan is also a single document, laying down the groundwork that supports your incident response playbooks.
Need a starting point for building or refining your incident response plan? Check out our roundup of free Incident Response Plan Templates – practical, cloud-ready examples to help you move faster.
Incident response playbooks
In general terms, an incident response playbook is a document that provides a highly detailed set of procedures for handling a specific type of incident.
Each playbook is tailored to different circumstances. For example, you'd typically create a series of playbooks for different attack vectors. However, you can also use a playbook to provide instructions for a specific role in the incident response team. This is commonplace in the wider incident management process. For instance, you'd typically create playbooks for legal and PR teams to help them meet compliance requirements and handle communications respectively.
The incident response team
The incident response team is a cross-functional group responsible for orchestrating security incident operations across your organization.
Core team roles include:
Executive sponsor: Senior management member (CSO/CISO) who advocates for the program and reports to executive leadership.
Incident response manager: Team lead who develops strategy, coordinates activities, and maintains overall authority during incidents.
Communications team: PR, social media, and HR representatives who manage stakeholder communications during incidents.
Legal team: Legal representatives handling compliance, criminal implications, and contract breach issues.
Technical team: IT and security operations staff qualified to detect, analyze, contain, and eliminate threats.
Incident response lifecycle
A well-structured and systematic incident response lifecycle is core to effective incident management, providing a step-by-step process for dealing with an attack. However, you don't need to start from scratch to develop your own response lifecycle, as a number of frameworks are available to guide you through the process.
These include:
NIST 800-61: Computer Security Incident Handling Guide
SANS 504-B Incident Response Cycle
ISO/IEC 27035 Series: Information Technology — Information Security Incident Management
On similar lines, Wiz recently published an incident response plan template that's aimed specifically at those responsible for protecting public cloud, hybrid cloud and multicloud deployments.
Although each incident response framework takes a slightly different approach, they all essentially break the lifecycle down into the following phases.
Preparation
The worst time to start working on a response strategy is just when an incident strikes, as you need to act quickly to minimize the damage and reduce disruption to your business. That's why preparation is so important.
The preparation phase of incident response ensures you have everything in place ahead of time so you can respond to an incident without delay. It will include arrangements such as:
The formation of the incident response team
An up-to-date asset inventory to help ensure you have all bases covered
Capture of log data to support timeline analysis after an incident
Procurement of tooling for rapid detection and containment
Implementation of an issue-tracking system for escalating cases and monitoring progress
Contingency measures to minimize disruption to business operations
Incident response training
Incident response testing exercises
Cyber insurance cover
Detection
The detection phase takes a methodical approach to identifying whether a security incident has occurred or is about to occur. The first signs of an attack include:
a high number of failed login attempts
unusual service access requests
privilege escalations
blocked access to accounts or resources
missing data assets
slow running systems
a system crash
Key challenge: Detection requires correlating information from multiple sources to confirm actual incidents.
Information sources include:
Workload telemetry: Performance and behavior data from applications
CSP telemetry: Monitoring data from cloud service providers
Threat intelligence: External security feeds and indicators
User feedback: Reports from end users experiencing issues
Supply chain alerts: Notifications from vendors and partners
Investigation/Analysis
The incident investigation phase comprises a systematic series of steps to determine the root cause of the attack, the likely impact on your deployments, and appropriate corrective action.
As with the detection phase, it involves piecing together event data from different log sources to build up a full picture of the incident.
Containment
Containment limits attack spread and impact while buying time for comprehensive remediation.
Primary objectives:
Minimize attack blast radius
Limit impact on IT systems and business operations
Provide time for thorough remediation planning
Example of an incident management tool triggering real-time response actions to reduce and contain the blast radius of a potential incident..
Common containment methods:
DoS attacks: Network filtering and IP address blocking
Lateral movement: Resource isolation to prevent attack spread
Traditional environments: EDR tools for endpoint isolation
Cloud environments: Security group modifications through control plane
Did you know? Gartner recognizes cloud investigation and response automation (CIRA) as an indispensable technology in the cybersecurity landscape. Gartner views CIRA as a strategic investment for organizations looking to fortify their security posture in the cloud. Simply put, the shift to cloud computing brings unprecedented opportunities but also introduces new risks.
Eradication
Eradication is the phase in which you completely remove the threat so that it's no longer present anywhere within your organization’s network.
Ways to rid your systems of a threat include:
Removing malicious code
Reinstalling applications
Rotating secrets such as login credentials and API tokens
Blocking points of entry
Patching vulnerabilities
Updating infrastructure-as-code (IaC) templates
Restoring files to their pre-infection state
It's also vital to scan both affected and unaffected systems following remediation—to ensure no traces of the intrusion have been left behind.
Post-incident review
Post-incident review refines your response strategy based on lessons learned to improve future incident handling.
Review focus areas:
Response effectiveness and team performance
Business impact assessment
Process and documentation gaps
Key review questions:
Documentation and processes:
Was our documentation sufficiently clear and accurate?
Did team members understand their roles and responsibilities?
How long did different response tasks take?
Prevention and tooling:
What measures could prevent similar incidents?
Were there gaps in our security tooling?
Did any mistakes delay recovery time?
Did the incident reveal compliance violations?
AI and the future of incident response
Artificial intelligence (AI) is reshaping the incident response landscape for both defenders and attackers. For security teams, AI accelerates threat detection and analysis by identifying patterns in vast datasets that are invisible to human analysts, as demonstrated by PROS's experience with Wiz Defend, where AI-powered capabilities reduced threat investigation time from hours to just five minutes. It can automate initial triage, correlate alerts from different tools, and even suggest containment actions, significantly reducing response times.
However, attackers are also leveraging AI to create more sophisticated and evasive malware, launch automated social engineering campaigns, and find vulnerabilities faster, with one report citing a 3,000% increase in deepfakes in 2024. This creates a new class of AI-driven threats that require equally advanced defenses; in one 2024 incident, a finance worker was tricked into transferring $25 million after threat actors used deepfake technology to impersonate company executives on a video call.
The future of incident response lies in using AI to fight AI. Modern security platforms use machine learning to contextualize threats and automate investigation workflows. By analyzing relationships between resources, permissions, and activities, these platforms can distinguish real threats from noise and provide a clear path to remediation. This allows security teams to focus on strategic response rather than manual data correlation.
Tools and technologies
The right tooling is a godsend when you are faced with a live security incident and need to address the threat as quickly as possible. So, to wrap up, we've listed some of the incident response tools and technologies you'll need for effective response, along with the role they play in the response lifecycle.
| Technology | Description | Role in response lifecycle |
|---|---|---|
| Threat detection and response (TDR) | A category of security tools that monitor environments for signs of suspicious activity and provide remediation capabilities to contain and eradicate threats. Examples of TDR technology include endpoint detection and response (EDR) and cloud detection and response (CDR). | Detection, investigation, containment, and eradication |
| Security information and event management (SIEM) | An aggregation platform that enriches logs, alert, and event data from disparate sources with contextual information, thereby enhancing visibility and understanding for better incident detection and analysis. | Detection and investigation |
| Security orchestration, automation and response (SOAR) | A security orchestration platform that integrates different security tools, providing streamlined security management through a unified interface. Allows you to create playbooks to perform predefined automated responses. | Detection, investigation, containment, and eradication |
| Intrusion detection and prevention system (IDPS) | A traditional defense system that detects and blocks network-level threats before they reach endpoints. | Detection and investigation |
| Threat intelligence platform (TIP) | An emerging technology that collects and rationalizes external information about known malware and other threats. TIP helps security teams quickly identify the signs of an incident and prioritize their efforts through insights into the latest attack methods adversaries are using. | Detection, investigation, containment, and eradication |
| Risk-based vulnerability management (RBVM) | A security solution that scans your IT environment for known vulnerabilities and helps you prioritize remediation activity based on the risk such vulnerabilities pose to your organization. | Containment and eradication |
Incident response metrics and measurement
Measuring the effectiveness of your incident response program is essential for demonstrating value and driving continuous improvement. Tracking key performance indicators (KPIs) helps you identify bottlenecks, justify investments, and show progress over time.
Key metrics to track include:
Mean Time to Detect (MTTD): The average time it takes to identify a security incident from the moment it begins. A lower MTTD indicates stronger detection capabilities, as a long detection time can be costly; for example, the MTTD for Microsoft's Midnight Blizzard attack was approximately two months.
Mean Time to Respond (MTTR): The average time taken to contain, eradicate, and recover from an incident after it has been detected. This metric reflects your team's efficiency.
Dwell Time: The total time an attacker remains undetected in your environment (from initial compromise to discovery). Reducing dwell time limits the potential damage an attacker can cause, and recent industry data shows the global median attacker dwell time has dropped to just 10 days, highlighting the speed at which modern teams must operate.
Incidents by severity: Tracking the number and type of incidents helps you identify trends and prioritize security efforts.
Cost per incident: Calculating the total cost of an incident, including downtime, remediation efforts, and potential fines, helps quantify the business impact and the value of your security program.
Wiz for Cloud-Native Incident Response
Traditional incident response tools and processes were built for static, on-prem environments. In the cloud, however, incidents unfold across highly dynamic infrastructure: workloads spin up and down in minutes, identities and permissions change constantly, and critical data may live across multiple regions and services. These factors make cloud-native IR especially challenging – and where Wiz comes in.
How Wiz helps:
Unified Visibility Across the Cloud: Wiz provides agentless coverage across workloads, containers, serverless functions, identities, and data. This visibility allows IR teams to quickly scope incidents and understand which assets, configurations, and permissions are involved.
Automated Context and Prioritization: With its Security Graph, Wiz automatically correlates misconfigurations, vulnerabilities, and runtime threats with identity and data exposure. During an incident, this helps responders pinpoint root cause and blast radius in minutes rather than hours.
Cloud Detection and Response (CDR): Wiz continuously monitors runtime activity and cloud control plane signals to identify anomalous behavior. When an incident occurs, these detections provide crucial breadcrumbs for threat hunting and forensic analysis.
Incident Response Services: Wiz’s dedicated IR Services team extends these capabilities with expert guidance. Whether it’s investigating an active breach, analyzing attacker activity, or advising on containment and recovery, Wiz IR specialists act as an extension of your SOC. Learn more about Wiz IR Services –>
Preparedness and Playbooks: Beyond active response, Wiz supports teams in building proactive IR readiness. This includes cloud-specific playbooks, tabletop exercises, and best practices tailored to ephemeral infrastructure and cloud identities.
The result: SOC and IR teams gain the speed and confidence to detect, investigate, and contain cloud incidents before they escalate. Wiz not only shortens response times but also strengthens long-term resilience by embedding cloud context into every phase of incident response.