What is incident response?
Incident response is the structured process organizations use to identify, contain, and recover from cybersecurity incidents. NIST guidance identifies several common attack vectors, including web, email, and improper usage. This coordinated approach minimizes damage and reduces recovery time when security breaches occur.
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
This discipline is part of the broader practice of incident management, which involves senior management, legal teams, HR, communications, and the wider IT department. This guide focuses on the response process itself, but touches on other aspects of incident management where a holistic approach matters.
An Actionable Incident Response Plan Template
A quickstart guide to creating a powerful incident response plan - designed specifically for organizations with cloud-based deployments.
What is a security incident?
Incident response teams need to act quickly when called into action. They cannot afford time-consuming misunderstandings that arise from incorrect terminology. That is why they need to understand exactly what constitutes a security incident and how it differs from similar terms.
A security event is the presence of unusual network behavior, such as a sudden spike in traffic or privilege escalation, that could indicate a breach. However, it does not necessarily mean you have a security issue. On further investigation, it may turn out to be 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.
An incident response team, also known as a computer security incident response team (CSIRT), cyber incident response team (CIRT), or computer emergency response team (CERT), is the cross-functional group responsible for managing these events from detection through resolution.
Types of security incidents
Security incidents fall into several categories based on attack methods and targets. Understanding these types helps teams prepare appropriate response strategies.
Denial-of-service (DoS): An attempt to flood a service with bogus requests, making it unavailable to legitimate users.
Application compromise: An application that has been hacked using techniques such as SQL injection, cross-site scripting (XSS), or cache poisoning, with the goal of corrupting, deleting, or exfiltrating data.
Ransomware: A type of malware that uses encryption to block access to your data. The attacker demands a ransom in exchange for the encryption keys.
Man-in-the-middle (MitM): An adversary covertly intercepts the data exchange between two parties and manipulates the communication between them.
Phishing and social engineering: Attackers use fraudulent emails, messages, or websites to trick users into providing sensitive information, downloading malware, or bypassing security protocols. Phishing remains one of the most common attack vectors because it targets human psychology rather than technical vulnerabilities. Spear phishing, pretexting, and business email compromise are more targeted variations.
Unauthorized access and stolen credentials: An attacker gains entry to systems using stolen, guessed, or brute-forced credentials, then escalates privileges to reach more sensitive data. According to industry reports, the abuse of valid accounts is one of the most common ways attackers breach systems today.
Insider threats: Current or former employees, contractors, or partners misuse their legitimate access, whether intentionally or through negligence, to compromise systems or exfiltrate data.
Developing a deep understanding of these attack types helps you formulate response procedures and identify appropriate tooling requirements.
Why is incident response a critical security function?
Incident response helps organizations limit damage through quick containment before threats spread, protect reputation by responding well and building trust with customers and regulators, meet compliance requirements that mandate documented plans and evidence of action, and reduce costs by shortening detection-to-resolution timelines.
The financial impact is significant. IBM's Cost of a Data Breach Report found that having an incident response team and formal plans reduces the cost of a breach by nearly half a million dollars on average. Many regulations, including GDPR, HIPAA, and PCI DSS, also require organizations to notify affected parties and regulators within defined timeframes after a confirmed breach.
The incident response team
An incident response team is a cross-functional group that coordinates security operations across your organization. This diverse composition ensures both technical expertise and business continuity during crisis situations.
Core team roles include:
Executive sponsor: Senior management member (CSO/CISO) who provides authority, resources, and executive reporting
Response manager: Team lead who coordinates all activities and maintains decision-making authority during incidents
Communications team: PR, social media, and HR representatives who manage internal and external stakeholder communications
Legal team: Legal representatives who handle regulatory compliance, law enforcement coordination, and breach notification obligations
Technical team: IT and security operations staff who detect, analyze, contain, and eliminate threats
This structure ensures incidents are managed from both technical and business perspectives. Building your team with clearly defined roles is critical. If you cannot fill all the necessary responsibilities, your response will have gaps that lead to more damage and longer attacks.
How does incident response work? 6 steps
A well-structured incident response lifecycle is core to effective incident management, providing a step-by-step process for dealing with an attack. You do not need to start from scratch. Several frameworks are available to guide you:
NIST 800-61: Computer Security Incident Handling Guide
SANS 504-B: Incident Response Cycle
ISO/IEC 27035 Series: Information Security Incident Management
Although each framework takes a slightly different approach, they all break the lifecycle down into the following phases.
Preparation
The worst time to start working on an incident response strategy is when an incident strikes. Preparation ensures you have everything in place ahead of time so you can respond without delay.
This phase includes forming the response team, maintaining an up-to-date asset inventory, capturing log data for timeline analysis, procuring tooling for rapid detection and containment, implementing an issue-tracking system for escalation, establishing contingency measures for business continuity, and running training and tabletop exercises to test your plan under realistic conditions. Tabletop exercises are particularly valuable because they expose gaps in communication, tooling, and decision-making before a real incident forces you to find them.
Detection
Detection identifies potential security incidents through systematic monitoring and analysis. This phase determines whether suspicious activity represents an actual threat requiring a response.
Common attack indicators include high numbers of failed login attempts, unusual service access requests, unauthorized privilege escalations, blocked access to accounts or resources, missing or corrupted data, and unexplained system performance issues.
The key challenge here is correlating information from multiple sources to confirm actual incidents versus false alarms. Critical data sources include workload telemetry, cloud service provider monitoring, threat intelligence feeds, user feedback, and supply chain alerts.
Investigation and analysis
The investigation phase comprises a systematic series of steps to determine the root cause, the likely impact on your deployments, and appropriate corrective action. As with detection, it involves piecing together event data from different log sources to build a complete picture.
Preserving forensic evidence during this phase is essential. Document all steps taken and evidence found in detail. This supports both internal post-incident review and any legal or regulatory proceedings that may follow.
Containment
Containment stops active attacks from spreading while preserving evidence for investigation. This phase prevents further damage while teams prepare comprehensive remediation strategies.
Primary containment objectives are minimizing blast radius to prevent attackers from accessing additional systems, preserving business operations by maintaining critical services while isolating compromised resources, and securing evidence for forensic analysis.
Containment strategies vary by attack type. DoS attacks may require network filtering and IP blocking. Lateral movement calls for resource isolation using network segmentation. Endpoint compromise can be addressed through EDR tools for immediate workstation isolation. Cloud incidents may involve security group modifications or IAM policy changes through control plane APIs.
Eradication
Eradication is the phase where you completely remove the threat from your environment. The widespread exposure of secrets, affecting 61% of organizations, makes credential rotation and secret management critical during this phase.
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 templates, and restoring files to their pre-infection state.
It is also vital to scan both affected and unaffected systems following remediation to ensure no traces of the intrusion remain.
Post-incident review
Post-incident review transforms experience into improved security posture. This phase identifies weaknesses in processes, tools, and team performance to prevent future incidents.
Review focus areas include response effectiveness (how well teams executed containment and recovery), business impact (actual cost in downtime, data loss, and reputation damage), and process gaps (where documentation, communication, or coordination failed).
The review should also identify what security measures could have prevented the incident, whether there were tool gaps or configuration weaknesses, and whether the incident revealed regulatory violations. Effective reviews produce actionable improvements rather than blame assignment.
Watch 5-minute Wiz Defend demo
See how Wiz Defend operationalizes every phase of incident response with full cloud context and automated workflows
Incident response documentation
Three types of documents support an effective incident response program. The policy sets the business case, mandates the creation of a team, and gets leadership buy-in. The plan expands on the policy with detailed procedures for each lifecycle phase, role assignments, and a communication plan. Playbooks provide step-by-step instructions for handling specific incident types or guiding specific team roles. Together, these documents ensure your organization can respond consistently and without improvisation under pressure.
The communication plan within your incident response plan deserves special attention. It defines when and how to notify internal stakeholders, executives, customers, regulators, and the media. Think through various scenarios ahead of time so the team is not making judgment calls about disclosure in the middle of a crisis. Many regulations require notification within specific timeframes, making this a compliance requirement, not just a best practice.
AI and the future of incident response
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. It can automate initial triage, correlate alerts from different tools, and 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.
Generative AI is adding another dimension. Rather than relying only on predefined rules or static playbooks, large language models can interpret data in real time, understand the context of an alert, and generate dynamic responses. GenAI can help analyze attacks, write reports, suggest remediation steps, summarize logs, and automate stakeholder communication. The emerging best practice is to treat generative AI as a co-pilot: keeping human analysts in the loop to review recommendations and make the final call. This human-in-the-loop approach ensures AI enhances response efforts without compromising oversight or accountability.
Tools and technologies
The right tooling is critical when you are facing a live security incident and need to address the threat as quickly as possible. Here are the core incident response technologies that support effective detection and remediation.
| Technology | Description | Role in response lifecycle |
|---|---|---|
| Threat detection and response (TDR) | Tools that monitor environments for suspicious activity and provide remediation capabilities, including endpoint detection and response (EDR) and cloud detection and response (CDR). | Detection, investigation, containment, and eradication |
| Extended detection and response (XDR) | Platforms that unify detection across endpoints, network, cloud, and email into a single view, correlating data to reveal full attack chains and accelerate investigation. | Detection, investigation, containment, and eradication |
| Security information and event management (SIEM) | Aggregation platforms that enrich logs, alerts, and event data from disparate sources with contextual information, enhancing visibility for better detection and analysis. | Detection and investigation |
| Security orchestration, automation, and response (SOAR) | Orchestration platforms that integrate different security tools and allow you to create playbooks for predefined automated responses. | Detection, investigation, containment, and eradication |
| User and entity behavior analytics (UEBA) | Technologies that use machine learning to baseline normal user and entity behavior, then flag anomalies that could signal insider threats, account compromise, or lateral movement. | Detection and investigation |
| Intrusion detection and prevention system (IDPS) | Traditional defense systems that detect and block network-level threats before they reach endpoints. | Detection and investigation |
| Threat intelligence platform (TIP) | Platforms that collect and rationalize external information about known threats, helping teams quickly identify indicators and prioritize efforts. | Detection, investigation, containment, and eradication |
| Risk-based vulnerability management (RBVM) | Solutions that scan your environment for known vulnerabilities and help you prioritize remediation based on the risk each vulnerability poses. | Containment and eradication |
Incident response metrics and measurement
Measuring incident response effectiveness is essential for demonstrating value and driving continuous improvement. Tracking key performance indicators helps you identify bottlenecks, justify investments, and show progress over time.
Mean Time to Detect (MTTD): The average time from when an incident begins to when it is identified. A long detection window can be extremely costly. The MTTD for Microsoft's Midnight Blizzard attack was approximately two months.
Mean Time to Respond (MTTR): The average time to contain, eradicate, and recover after detection. This metric reflects your team's efficiency under pressure.
Dwell Time: The total time an attacker remains undetected in your environment. Recent industry data shows the global median 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 focus security efforts where they matter most.
Cost per incident: Calculating the total cost including downtime, remediation, and potential fines helps quantify business impact and the value of your security program.
Book a Demo of Wiz Defend
Walk through how Wiz Defend helps your team detect threats faster, investigate with full cloud context, contain incidents with automated playbooks, and trace root cause back to code.
