Incident response
One alert at 2 a.m. can become a day that decides how much a company loses. This lesson takes you through the full incident response life cycle, from the moment a detection fires to the review weeks later, using a ransomware attempt on a Mangrove Market store PC. You will learn to run an incident calmly: declare and size it, contain it without destroying evidence, remove the attacker, recover safely, and turn the whole thing into detections that catch the next one sooner.
By the end you can
- Walk the NIST SP 800-61 life cycle and say why preparation wins most incidents
- Declare an incident, set a severity, and run it with an incident commander, a scribe and an out-of-band channel
- Choose a containment action and defend the trade-off, while preserving evidence
- Eradicate persistence and recover from known-good backups, establishing scope and root cause from logs and ATT&CK
- Run a blameless post-incident review that produces owned, dated actions and new detections
The everyday picture
Think about the fire service, not the fire. By the time a truck rolls out, the hard work is already done: the crews drilled the routes, the hydrants were mapped, the radios were charged, and everyone knows who gives orders at the scene. When they arrive they do not all rush in. One person takes command and stays outside to see the whole building. Some crews stop the fire spreading to the next house while others find where it started. Nobody bulldozes the building before the investigator has seen it, because the cause tells you how to stop the next one.
An incident works the same way. Most of the win is bought before anything happens, in runbooks, contacts and tested backups. During the incident, one commander keeps the big picture while responders contain, investigate and recover in parallel. And you protect the evidence, because the story of how the attacker got in is the only thing that stops it happening again next week. You met the calm first hour of this in Risk, compliance and the first hour of an incident; here you run the whole thing.
The life cycle, and why preparation wins
The common language for handling incidents is NIST SP 800-61. It describes four phases that form a loop: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. The 2025 revision reorganised the advice around the NIST CSF 2.0 functions you saw in sec-06, but the four phases are still the clearest way to think about the work, and a real incident loops between the middle two as you learn more.
The surprising part is that the phase that decides the outcome is the one before any alert. Preparation is where you write the runbooks (a short, step-by-step guide for a named situation, such as "ransomware on a store PC"), agree who plays which role, keep an offline contact list, test that backups actually restore, and rehearse with tabletop exercises. A team that prepared spends the incident executing a plan. A team that did not spends it inventing one at 2 a.m., which is when people panic and panic spreads damage. You cannot create a tested backup during a ransomware attack; you either did it last month or you did not.
The other phases build on the rest of this course. Detection and analysis is the alert triage of Triage and investigation and the hunting of Threat hunting, now feeding a declared incident. Containment, eradication and recovery is the hands-on middle. Post-incident activity is where lessons become detections (Writing detections) so the loop closes tighter each time.
Quick check
During a ransomware incident, the team finds that the one backup they planned to restore from was itself encrypted. Which phase failed?
A backup you can rely on in an incident has to be offline or immutable and proven to restore, and that work happens long before the alert. Containment on the day cannot save a backup that was already reachable and never tested. This is why preparation, not heroics, decides the outcome.