Incident response is a process, and having the process written down before you need it is most of the value. The widely used model comes from NIST Special Publication 800-61, and the phases are preparation, detection and analysis, containment and eradication and recovery, and post incident activity.
The phases are easy to memorize. What is hard is the judgment inside each one.
Preparation Is Most of It
Preparation is everything you do before anything happens: the plan, the contact list, the authority to act, the logging, the tooling, the backups, and the practice.
The specific items that decide how an incident goes are unglamorous. Who is allowed to take a production system offline, and can they be reached at 3am. Where the out of band communication channel is, in case the normal one is compromised. Whether the backups have ever been restored, as opposed to merely completing.
Whether legal, communications, and executive leadership know their part in advance. Most delay in real incidents is not technical, it is waiting for a decision nobody was empowered to make.
Detection and Analysis
Something is noticed, from an alert, a user report, a partner notification, or law enforcement. The first task is deciding whether this is an event or an incident, which is a judgment call about scope and impact.
Then investigation: what happened, when did it start, what is affected, is it still happening. That work is described in detail in the Week 9 investigation and in threat hunting.
The discipline that matters here is note taking. Timestamps in one time zone, what you did, what you saw, and why you believed something. This is what makes the report writable later and what makes the response defensible if it is ever questioned.
Containment, and the Tension Inside It
Containment is stopping the spread. It is also where the hardest tradeoff in incident response lives: acting fast destroys evidence and warns the attacker, and acting slowly lets damage grow.
The usual approach is short term containment first, meaning isolate affected systems and cut the attacker's access, followed by longer term containment while you work out full scope.
Capture volatile evidence before you power anything off, because memory is gone once the machine is. Isolating a host at the network level generally preserves more than shutting it down.
There is also a business tension. Taking a system offline may cost real money per hour, and someone with authority has to own that decision.
Eradication and Recovery
Eradication is removing the attacker's access and their persistence. All of it. This is where incomplete work bites, because a missed backdoor means the same intrusion returns in a fortnight and the second one is worse.
Recovery is restoring service and confirming things are actually clean. Restoring from backup is only safe if you know the backup predates the compromise, which requires knowing when the compromise started. That is why investigation quality drives recovery quality.
Rebuilding rather than cleaning is usually the right call for anything meaningfully compromised. Deciding a machine is clean is much harder than rebuilding it.
Declaring an incident over is a real decision with consequences, and the evidence for it is always weaker than anyone would like. Increased monitoring after recovery is standard practice for exactly this reason.
The Report
A report has an executive summary a non technical reader can follow, a timeline, an evidence section showing how each conclusion was reached, an impact statement, and recommendations specific enough to assign to a person.
It must separate fact from assessment. A log showing access is a fact. Concluding the attacker wanted the customer database is an assessment and needs a stated confidence level.
It should also be honest about what is unknown. Reports that quietly imply certainty they do not have cause problems later, particularly if regulators or lawyers become involved.
Post Incident Activity, The Skipped Phase
This is the phase most organizations skip because everyone is exhausted and the crisis is over. It is also the phase that produces all of the improvement.
Run it blameless. If the review becomes a search for who to punish, you get careful stories instead of accurate ones, and the next incident is handled worse.
The useful questions are what let this happen, what let it go undetected for the time it did, what slowed the response, and what would we want to be true next time. Then turn the answers into assigned work with dates, including new detections.
Practice Before You Need It
Tabletop exercises are the cheapest possible preparation. You need a scenario, the right people in a room, and someone willing to keep making it worse.
They reliably surface the same problems: nobody knows who can authorize the big decisions, the contact list is out of date, the backup assumption was never tested, and the communication plan assumes the systems that are down. Better to find that out in a conference room. That is exactly what the mentorship capstone does.
Learn This at HackRange
Week 9 of the mentorship is a full investigation and report, and Week 13 runs a tabletop where you make the decisions under pressure.