Cyber incident response is the organized process a team follows to detect, contain, eradicate, and recover from a security breach while limiting damage and preserving the evidence needed to understand what happened. The teams that come through an incident intact are not the ones with the thickest binder; they are the ones who rehearsed, who know their roles cold, and who can make containment decisions under pressure without waiting for a committee.
An incident is the worst possible time to invent a process. The value of a response plan is almost entirely front-loaded into the calm before the alert fires.
The Six Phases
The widely used NIST framework breaks response into a cycle: preparation, detection and analysis, containment, eradication, recovery, and post-incident review. They are not strictly linear. You will loop between detection and containment as you learn the scope, and the whole thing feeds back into preparation for next time.
Preparation is the phase that pays for all the others. It covers your tooling, logging, runbooks, contact lists, and the tabletop exercises that turn a plan on paper into muscle memory. Detection and analysis is where you separate a real incident from noise and establish scope: what was touched, when, and how. Containment stops the bleeding. Eradication removes the attacker's foothold. Recovery restores service safely. Post-incident review turns the whole ordeal into lessons.
Preparation Is the Real Work
You cannot respond to what you cannot see. Preparation means centralized logging with enough retention to investigate an intrusion that started months ago, since attackers often dwell for weeks before acting. It means an asset inventory so you know what "normal" looks like. It means documented runbooks for the incident types you can predict: ransomware, credential compromise, data exfiltration, a compromised dependency in your build.
It also means people. Define who declares an incident, who talks to legal and communications, who has authority to pull a production system offline, and how you reach them at 3 a.m. Write down the decisions you do not want to be debating live.
Detection and Triage
Detection comes from many sources: an alert from your SIEM, a report from a customer, an anomaly a developer noticed, or a threat-intelligence tip. The first job is triage. Is this a real incident or a false positive? What is the potential blast radius? Assign a severity, because a compromised marketing landing page and a compromised customer database demand very different responses.
Resist two opposite failure modes. One is panic: shutting everything down before you understand the scope and destroying the evidence you need. The other is denial: explaining away a genuine signal because acknowledging it is inconvenient. Good triage is calm and evidence-driven.
Containment: Short-Term and Long-Term
Containment splits into two horizons. Short-term containment is the immediate move to limit spread: isolate the affected host from the network, disable a compromised account, block a malicious IP, or revoke a leaked API key. It buys time.
Long-term containment lets you keep operating while you prepare a clean rebuild: applying temporary patches, tightening firewall rules, and standing up monitoring so you would see the attacker come back. A critical judgment call lives here. Pulling the plug on a live intrusion can tip off the attacker and destroy volatile evidence in memory. Sometimes you watch and gather intelligence before you cut them off. That decision belongs to a named person, made in advance where possible.
Eradication and Recovery
Eradication removes the root cause: delete malware, close the vulnerability that allowed entry, rotate every credential that could have been exposed, and rebuild compromised systems from known-good images rather than cleaning them in place. Cleaning a compromised host is how attackers get to keep a foothold you thought you removed.
Recovery restores normal operations carefully. Bring systems back in a controlled order, monitor them closely for signs the attacker is still present, and validate integrity before you trust a restored system with production traffic. Do not rush the finish line; reinfection during a sloppy recovery is common.
The Post-Incident Review
When the fire is out, hold a blameless post-incident review while memory is fresh. Build a timeline: when did the attacker get in, when did you detect it, how long did each phase take? The gap between compromise and detection, your dwell time, is the number that matters most, and shrinking it is usually the highest-leverage improvement you can make.
Feed the findings back into preparation. Every incident should leave you with concrete changes: a new detection rule, a closed gap, an updated runbook, a control that would have caught it. An incident you learn nothing from is one you are destined to repeat.
Where the Supply Chain Fits
A growing share of incidents begin in the software supply chain: a compromised dependency, a leaked build credential, a malicious package published under a typosquatted name. Response for these looks different because the "affected asset" may be a library embedded in dozens of your services at once. Knowing where each dependency lives, via a maintained SBOM and tooling like Safeguard's SCA, turns "which of our apps ship the compromised package?" from a week of archaeology into a single query. Our software supply chain security guide covers the preventive side.
FAQ
What is the difference between an event, an alert, and an incident?
An event is any observed occurrence. An alert is an event a tool flagged as potentially interesting. An incident is a confirmed or strongly suspected violation of security policy that warrants a coordinated response. Triage is the process of promoting alerts to incidents, or dismissing them.
How fast should we respond?
There is no universal number, but the metric to drive down is dwell time: the gap between initial compromise and detection. Well-instrumented teams detect in hours; poorly instrumented ones take months. Faster detection shrinks the damage far more than a faster cleanup does.
Do we need a formal incident response plan if we are small?
Yes, though it can be lightweight. Even a one-page document naming who to call, how to isolate a system, and where the logs live puts a small team far ahead of improvising during a real breach. Scale the formality to your risk, not to your headcount.
Should we pay a ransomware demand?
Treat that as a business and legal decision made in advance, not live under duress. Paying funds the ecosystem, offers no guarantee of recovery, and may carry legal exposure depending on the actor. Solid, tested, offline backups remove most of the leverage a ransomware operator has.