What is the goal of the eradication phase in incident response?

Removing the root cause, such as malware, from systems

Notifying regulators before any investigation has begun

Restoring systems to normal operation without further analysis

Why is preserving evidence important during incident response?

It supports forensic investigation and possible legal action

It is only needed if law enforcement requests it

It speeds up recovery by skipping analysis entirely

What is the goal of a lessons-learned review after an incident?

Identifying what happened to improve future response processes

Assigning blame to the individual who caused it

Finalizing the report with no further action needed

What distinguishes a security incident from a security event?

An incident is an event that has caused or could cause harm

An event only happens after a full data breach

Incident and event are simply the same thing

Cyber Security Incident Response

Incident response is the structured process an organization follows to detect, contain, and recover from a security incident while minimizing damage and capturing lessons for next time.

What Is Incident Response?

Even organizations with strong preventive controls eventually face a security incident — a phishing email that gets clicked, a misconfigured system that gets found by a scanner, a piece of malware that slips past defenses. Incident response (IR) is the organized process for handling those situations: figuring out what happened, stopping it from getting worse, removing the cause, restoring normal operations, and learning from it. Having a plan before an incident happens is what separates a contained, well-documented event from a chaotic, expensive one.

The Standard Phases of Incident Response

Preparation — build the plan, tools, and trained team before anything happens.
Detection and Analysis — notice that something is wrong and figure out what it actually is.
Containment — stop the incident from spreading or causing further damage.
Eradication — remove the root cause, such as malware or an attacker's access.
Recovery — restore affected systems and services to normal, verified-safe operation.
Lessons Learned — review what happened and improve the plan and defenses going forward.

Preparation and Detection in Practice

Preparation means having a written incident response plan with clear roles (who declares an incident, who talks to legal or the press, who works the technical response), tooling in place ahead of time (logging, endpoint detection, backups), and practice through tabletop exercises so the plan isn't tested for the first time during a real crisis. Detection and analysis is where alerts from tools like a SIEM (security information and event monitoring) system or endpoint detection and response (EDR) agent, or a report from an employee, get triaged to determine whether it's a real incident, how severe it is, and roughly what's affected — this scoping step shapes everything that follows.

Severity	Example criteria	Typical response expectation
Low	Isolated policy violation, no data or system impact	Handled during normal working hours
Medium	Malware contained to a single non-critical workstation	Response within hours
High	Active compromise of a server or spread across multiple machines	Immediate response, incident team activated
Critical	Confirmed breach of sensitive data or core business systems	Immediate response, leadership and legal involved

Containment, Eradication, and Recovery

Short-term containment — isolate the affected system quickly (e.g. disconnect it from the network) to stop the immediate spread without necessarily fixing anything yet.
Long-term containment — apply temporary fixes that let the business keep operating while a full remediation is prepared, such as blocking a malicious IP or disabling a compromised account.
Eradication — remove the actual cause: delete malware, close the vulnerability that was exploited, revoke compromised credentials.
Recovery — restore systems from clean, verified backups or rebuilt images, then monitor closely for signs the problem returns before declaring the incident closed.

Note: Resist the urge to immediately wipe or reboot a compromised system. Doing so can destroy the evidence needed to understand how the attacker got in, and — for incidents that may involve legal action, regulatory reporting, or insurance claims — can break the chain of custody needed for that evidence to be usable later.

Lessons Learned

After the dust settles, a post-incident review looks at what actually happened, how quickly it was detected and contained, what worked, and what didn't. The output isn't blame — it's concrete updates: patch the gap that let it happen, adjust the IR plan where it was unclear or slow, add monitoring where detection lagged, and fold any new attacker techniques into future training. Skipping this step is a common reason organizations experience the same category of incident more than once.

Exercise: Cyber Security Incident Response

What is typically the first step after detecting an incident?

Keep Going

Cyber Security Interview QuestionsPractice real questions asked for Cyber Security Cybersecurity Analyst SalarySee what Cybersecurity Analyst roles pay in the market Auto Apply for JobsApply to open roles related to Cyber Security and tweak your resume