Most organisations find out they have a cybersecurity problem in one of two ways.
Either their own systems catch something early, and a well-prepared team springs into action. Or they find out from a customer, a journalist, or law enforcement, weeks after the damage is done.
The difference between those two outcomes almost always comes down to one thing: incident response.
Not the tools. Not the budget. The plan.
This guide covers everything you need to know about incident response in plain English, what it is, how the phases work, what a solid plan looks like, and what separates organisations that recover quickly from the ones that never fully do.
What Is Incident Response?
Incident response is the structured process an organisation follows when a cybersecurity event occurs, from the moment something suspicious is detected through to full recovery and lessons learned.
The goal is simple: detect the threat as early as possible, contain it before it spreads, remove it completely, and restore normal operations with the least possible damage.
In practice, it is anything but simple.
Incident response involves coordinating teams across IT, legal, communications, and executive leadership, often under enormous pressure, while attackers may still be active in your environment. It requires decisions made in minutes that can have consequences lasting months.
Done well, incident response is the difference between a contained incident that gets resolved in hours and a full-scale breach that costs millions and makes headlines.
Done poorly, or not at all, a manageable problem becomes a catastrophe.
Why Incident Response Matters More Than Ever in 2026
The threat environment has shifted in ways that make unprepared organisations significantly more vulnerable than they were even two years ago.
According to the 2026 Unit 42 Global Incident Response Report by Palo Alto Networks, identity weaknesses played a material role in nearly 90% of investigations. Attackers are increasingly logging in with stolen credentials rather than breaking through perimeters, which means traditional defences often do not trigger at all.
In 2025, the fastest attackers moved from initial access to data exfiltration in under 72 minutes. That number is four times faster than it was just two years earlier.
AI has become a force multiplier for threat actors. It compresses the attack lifecycle and reduces the friction of running sophisticated campaigns. The scale and speed of modern attacks mean that without a tested, practised incident response capability, organisations are simply reacting in the dark.
The financial stakes are brutal. The average cost of a data breach globally sat above $4.8 million in 2024. For organisations without a formal incident response team, that number climbs dramatically higher. Regulatory consequences make it worse still: GDPR mandates breach notification within 72 hours, and non-compliance can trigger fines of up to 4% of global annual revenue.
The question is no longer whether your organisation will face a security incident. It is whether you will be ready when it happens.
Types of Security Incidents You Need to Be Ready For
Incident response is not one-size-fits-all. The type of incident shapes everything from who responds to how fast you need to move.
1. Ransomware attacks
These are among the most damaging and fastest-moving incident types. Attackers encrypt critical systems and demand payment, often while simultaneously threatening to publish stolen data. Recovery without preparation can take weeks or months.
2. Data breaches
Data breaches involve unauthorised access to sensitive data, whether customer records, financial information, intellectual property, or employee data. The breach itself may be quick, but the investigation, notification obligations, and reputational fallout are long-running.
3. Phishing and business email compromise (BEC)
Phishing and business email compromise use deceptive emails or impersonated accounts to steal credentials, authorise fraudulent transfers, or gain initial access to the network. These are among the most common entry points for larger attacks.
4. Insider threats
Insider threats involve employees, contractors, or partners who intentionally or accidentally cause a security incident. Detection is harder because the activity often looks legitimate from the outside.
5. Distributed denial of service (DDoS) attacks
DDoS Attacks flood systems with traffic to disrupt services. While less likely to result in data theft, they can cause significant operational disruption and revenue loss.
6. Supply chain attacks
Supply chain attacks compromise a trusted vendor, software provider, or service to gain access to their downstream customers. These are increasingly common and difficult to detect because the attack enters through a trusted channel.
7. Account takeovers
Accout takeovers use stolen credentials or session tokens to access systems as a legitimate user. Because attackers are “logged in” rather than breaking in, these incidents often go undetected far longer than traditional intrusions.
The 6 Phases of Incident Response
The most widely adopted incident response framework breaks the process into six phases. These are not sequential steps you move through once and finish. In a real incident, they overlap, loop back, and run in parallel.
Phase 1: Preparation
Preparation is everything that happens before an incident occurs. It is also the phase most organisations underinvest in, and the gap that makes the biggest difference.
Preparation means having a documented incident response plan that people have actually read and practiced. It means defining roles and responsibilities before the pressure is on, not during it. It means deploying the monitoring tools, SIEM systems, and threat intelligence feeds that give your team visibility when something happens.
It also means running tabletop exercises and simulations so that when a real incident hits, the muscle memory is there. Teams that have practiced their response plan containment times are measurably faster and more effective than those responding for the first time during an actual attack.
Key preparation activities include building and training your incident response team, developing playbooks for common incident types, establishing communication templates for internal and external notification, and confirming you have legal and regulatory reporting obligations documented before you need them.
Phase 2: Identification
Identification is the phase where your team determines whether an event is actually an incident worth escalating, and if so, how serious it is.
Security alerts fire constantly in any active environment. The vast majority are false positives. Identification is the process of separating genuine threats from the noise, confirming the scope and nature of the incident, and making sure the right people are informed immediately.
Sources of identification include SIEM alerts, threat intelligence feeds, anomaly detection tools, user reports, and in some cases, external notifications from law enforcement, partners, or dark web monitoring services that catch signs of compromise before internal tools do.
The key questions during identification are: Is this a real incident? What systems and data are affected? Is the attacker still active? How did they get in? The answers to these questions shape everything that follows.
Accurate identification is genuinely difficult under time pressure. One of the most common mistakes is either dismissing a real incident as a false positive or escalating a false positive as a major breach, both of which have serious consequences.
Phase 3: Containment
Once an incident is confirmed, the immediate priority is preventing it from spreading. Containment does not mean solving the problem. It means stopping it from getting worse while you gather the information needed to solve it properly.
Short-term containment might mean isolating a compromised endpoint from the network, blocking a suspicious IP address, disabling a compromised account, or revoking stolen access tokens. The goal is to limit the blast radius of the incident as quickly as possible.
Long-term containment involves more sustained controls, additional monitoring, temporary access restrictions, and putting interim measures in place while eradication and recovery proceed.
One critical point during containment: preserve forensic evidence. Every action your team takes changes the state of affected systems. Document everything. Capture logs, memory images, and network traffic captures before isolating systems wherever possible. The evidence gathered now is what enables proper root cause analysis later and may be required for legal or regulatory proceedings.
Phase 4: Eradication
Eradication is removing the threat completely from your environment. Not just the obvious foothold, but every trace of attacker presence.
This is harder than it sounds. Modern attackers establish multiple persistence mechanisms. They create backdoor accounts. They install remote access tools in multiple locations. They may have been in your environment for weeks or months before detection. Removing the obvious entry point while leaving secondary footholds in place means the attacker can simply walk back in.
Eradication typically involves removing malware and malicious tools, disabling or deleting compromised accounts, patching the vulnerabilities that were exploited, rebuilding systems that cannot be fully cleaned, and rotating credentials and access tokens across affected areas.
Thorough eradication requires genuine forensic investigation, not just a surface-level scan. This is often where organisations struggle most without specialist support, particularly for sophisticated, long-running intrusions.
Phase 5: Recovery
Recovery is restoring affected systems, services, and data to normal operation, but doing so carefully and in a monitored way.
Rushing recovery creates risk. Systems restored from backups that themselves contain malware, or brought back online before the root cause is fully understood, can re-infect the environment immediately.
Recovery should be phased, starting with the most critical systems and working outward. Every restored system should be validated before being reconnected to the broader environment. Monitoring should be intensified during this period because attackers sometimes attempt re-entry during the recovery window, knowing that defenders may be distracted or fatigued.
Recovery is also when you begin communicating with affected parties: customers, partners, regulators, and the public, depending on the nature and scale of the incident. Having communication templates prepared in advance, as part of the preparation phase, makes this significantly less chaotic.
Phase 6: Lessons Learned
Lessons learned is the phase most organisations either rush or skip entirely. That is a serious mistake.
Within two weeks of closing an incident, the response team should conduct a formal post-incident review. Not to assign blame, but to understand honestly what happened, how well the response worked, and what needs to change.
Questions worth asking: How was the incident initially detected and could it have been caught earlier? Did the incident response plan hold up under real conditions? Where did communication break down? How long did each phase take and could it be faster? What tools or capabilities were missing?
The output of the lessons learned phase directly improves your preparation for the next incident. Organisations that take this phase seriously continuously strengthen their incident response capability with each event. Those that skip it repeat the same mistakes.
What Is an Incident Response Plan?
An incident response plan is a documented, pre-approved set of procedures that guides your organisation through handling a security incident from detection to resolution.
It is not a theoretical document that sits on a shelf. A useful incident response plan is something your team has read, practiced, and can actually execute under pressure.
A solid incident response plan typically contains:
- Scope and purpose: What types of incidents does this plan cover, and what are the goals of the response?
- Roles and responsibilities: Who is on the incident response team, what each person is responsible for, and who has the authority to make key decisions like taking systems offline or engaging external help.
- Incident classification framework: How your team determines the severity of an incident and what level of response each severity triggers.
- Communication plan: Internal escalation paths, external notification requirements (regulators, customers, law enforcement), and pre-approved public messaging templates.
- Containment and eradication procedures: Step-by-step playbooks for common incident types, including ransomware, data breach, phishing compromise, and account takeover.
- Recovery procedures: How systems are validated and restored, and in what order.
- Legal and regulatory obligations: Notification deadlines, evidence preservation requirements, and documentation standards for compliance.
- Review and update schedule: How often the plan is reviewed, updated, and tested.
The plan should be tested at least annually through tabletop exercises and ideally through more realistic simulated incidents. A plan that has never been tested is a plan that will fail when you need it most.
Key Roles on an Incident Response Team
Incident response is a team effort. The difference between the coordinated response and chaos is having the right people with clearly defined responsibilities.
Incident Commander – The overall response is led by the Incident Commander, who makes the most important decisions and is the first point of contact with the executive leadership and the external stakeholders. When there is a big incident, they are the ones holding everything together as the technical work occurs.
SOC Analyst – This role monitors systems, researches alerts, and detects attack patterns, and is the first to notice and escalate a hypothetical incident in many cases.
Incident Handler – Incident Handler performs the technical response, which includes containment, eradication, and recovery operations, and collaborates with IT and network teams.
Forensics and Threat Intelligence Specialist – The role of this role is to perform in-depth forensic research to establish the root cause, track the attacker’s movement, establish all signs of compromise, and incorporate the threat intelligence to identify how and who attacked.
IT and Network Administrator – This role supports containment by isolating affected systems, implementing patches, and having a secure restoration of infrastructure.
Legal and Compliance Advisor – The advisor makes sure that the response meets the requirements of the regulations, recommends the necessity to report the breach, and helps to avoid re-exposure to the law.
Communications Lead – The role is responsible for all internal and external communications, liaises with PR when necessary, and manages customer and regulator communications.
Executive Sponsor or CISO – This role gives strategic direction, assures that the organisation is deploying the correct resources, and makes top-level business continuity and risk acceptance decisions.
In the case of smaller organisations that do not have all of these roles internally, most of these obligations can be addressed in part by an outsourced managed security service or incident response retainer with a specialty firm.
The Three Incident Response Frameworks Explained
Three frameworks dominate how organisations structure their incident response programs. Understanding the differences helps you choose the right foundation for your organisation.
The NIST Framework (SP 800-61r3) is the most widely referenced framework, particularly in US organisations and government. Its most recent update aligns incident response with the broader NIST Cybersecurity Framework 2.0, treating incident response not as a standalone process but as a continuous part of overall cybersecurity risk management. The phases in the updated NIST guidance map are Govern, Identify, Protect, Detect, Respond, and Recover.
The SANS Framework is a six-step tactical model that many security teams find more actionable during actual incidents: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. SANS has been used in the industry for decades, and the six-phase structure used throughout this article is based on it.
ISO/IEC 27035 provides an internationally recognised standard for information security incident management. It is particularly relevant for organisations that need to demonstrate compliance to international standards or operate across multiple jurisdictions.
None of these frameworks is definitively better than the others. Most mature security programmes draw from all three, using NIST for governance and risk integration, SANS for tactical response execution, and ISO 27035 for compliance alignment.
Common Incident Response Mistakes That Cost Organisations
Knowing what not to do is just as important as knowing the correct process. These are the most common and most costly mistakes organisations make.
1. Having a plan that nobody has tested
A documented process that exists only on paper will not survive contact with a real incident. Tabletop exercises and simulations are not optional extras. They are how you find out which parts of your plan do not work before you actually need them.
2. Trying to clean up quietly instead of following the plan.
When an incident is discovered, the temptation is sometimes to handle it internally and quietly, without escalating to leadership or engaging the full response process. This almost always makes things worse. Root causes get missed, evidence gets destroyed, and regulatory notification deadlines get violated.
3. Moving too fast through containment to recovery.
Organisations under pressure want to restore services quickly. But restoring systems before eradication is complete means re-infecting the environment. This resets the incident response clock and extends the overall damage significantly.
4. Failing to preserve forensic evidence.
The actions taken in the first hours of an incident can permanently destroy evidence needed to understand the root cause, support legal action, or satisfy regulatory requirements. Having a forensic evidence preservation process is part of preparation, not something to figure out during the incident.
5. Treating lessons learned as optional.
Organisations that skip the post-incident review do not get better at incident response. They face the same weaknesses in the next incident. The lessons learned phase is where the investment in having gone through an incident actually pays off.
6. Not monitoring for early warning signals.
Many incidents that appear sudden were actually visible weeks earlier as signals on dark web forums, criminal marketplaces, or in anomalous account behaviour. Organisations with no visibility into early warning sources are always responding after the fact.
How Dark Web Intelligence Fits Into Incident Response
One of the most underused capabilities in incident response is intelligence gathered before the incident becomes visible internally.
Stolen credentials, compromised session tokens, and leaked corporate data routinely appear on dark web forums and criminal marketplaces days or weeks before any internal system detects a problem. Attackers buy that access, plan their intrusion, and move when they are ready.
An organisation with dark web monitoring in place can receive an alert the moment their employee credentials appear in a credential dump, the moment their corporate data surfaces in a leak, or the moment their infrastructure is being discussed on underground forums as a target.
That alert does not replace incident response. It feeds directly into the preparation and identification phases, giving your team the earliest possible warning that something may be wrong or that an attack may be coming.
DarkScout’s dark web monitoring scans continuously across thousands of dark web sources, credential databases, hacker forums, and criminal marketplaces, alerting you the moment your organisation’s data, credentials, or assets surface where they should not be. That early warning gives your incident response team time to act before an attacker exploits what they have found.
You can run a free check right now with DarkScout’s free email scan to see what is already out there with your name on it.
The Bottom Line
Incident response is not a contingency for worst-case scenarios.
It is a core operational capability that every organisation needs, whether they have experienced a significant incident or not. The organisations most damaged by cyberattacks are almost always the ones that did not have a tested plan in place when something went wrong.
The good news is that preparation is entirely within your control.g
Build the plan. Train the team. Test it before you need it. And put early warning in place so you are never the last to know when something is wrong.
