Incident Response Explained: The Six Steps and Evidence Basics (Security+)
What you’ll know
The six phases of incident response in order, what happens in each, how to collect evidence without destroying it (order of volatility, chain of custody, hashing), and a few safe, read-only commands for a first look at a machine.
Why it matters. When something goes wrong, people panic, pull plugs and delete things, and the evidence goes with them. A calm, known process is what separates a bad day from a disaster, and the order of these steps is a Security+ favourite.
The six phases
| Phase | What happens |
|---|---|
| 1. Preparation | Plans, contact lists, tools, logging and training are ready before anything happens. |
| 2. Detection and analysis | Spot it (alerts, users, logs), confirm it’s real, judge how bad it is. |
| 3. Containment | Stop it spreading: isolate the machine from the network, disable the account. Contain first, clean second. |
| 4. Eradication | Remove the cause: malware, the attacker’s accounts, the hole they used. |
| 5. Recovery | Restore from clean backups, patch, monitor closely, return to normal. |
| 6. Lessons learned | What happened, what worked, what to change. Update the plan. |
These six steps are a practical teaching sequence: the classic incident-response phase model. NIST SP 800-61 Revision 3 (April 2025) now organizes incident response within the broader Cybersecurity Framework 2.0, emphasizing preparation, detection, response, recovery and continuous improvement. Practise them with a tabletop exercise: walk through a made-up incident around a table, no systems touched.
Evidence basics
- Order of volatility: collect what disappears first. CPU and memory (RAM) → network connections and running processes → temporary files → disk → logs stored elsewhere → backups and archives. Pulling the power wipes RAM, so don’t, unless the plan says to.
- Chain of custody: a record of who had the evidence, when, and what they did with it, so it holds up later.
- Hashing: hash a copy of the evidence when you collect it and again later. Matching hashes prove nothing changed.
- Legal hold: an instruction not to delete anything that might matter to a legal case.
- Timestamps: write down times in UTC, so evidence from different time zones lines up.
Step one of every incident is not “turn it off and on again.” That’s step one of deleting the evidence. Ask me how I know. — Nyx
Try it: a safe first look
These commands only read. Run them on your own machine to see what a responder looks at first.
PS> (Get-Date).ToUniversalTime().ToString('u') PS> Get-NetTCPConnection -State Established | Select-Object -First 5 LocalAddress,RemoteAddress,RemotePort,OwningProcess PS> Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Name,Id,CPU PS> Get-FileHash .\evidence.zip -Algorithm SHA256
The UTC time for your notes, live network connections (with the process ID that owns each one), the busiest processes, and a SHA-256 hash of an evidence file (use any file you like to try it). Match OwningProcess to Id to see which program made each connection.
$ date -u $ ss -tunp $ ps aux --sort=-%cpu | head -5 $ last -n 5 $ sha256sum evidence.zip
UTC time, network sockets (add sudo to see every process name), the busiest processes, recent logins and reboots, and an evidence hash. In WSL, last lists each time the Linux side started.
Where this fits
This is part of the free CompTIA Security+ roadmap: every StashGrid lesson mapped to the exam domains.
NextRisk management: SLE, ALE and RTO→
Go deeper
- Windows security log encyclopedia — the event IDs you check during analysis
- auditd (Linux Defenders 12) — record who did what before you need it
- Backup and restore drill — the recovery phase, practised
Explainer, written by StashGrid with AI help and checked against the CompTIA Security+ V8 (SY0-801) exam objectives before publishing. Every command was run in Ubuntu 24.04 (WSL, OpenSSL 3.0.13) and Windows 11 PowerShell on 30 Oct 2026. StashGrid isn’t affiliated with CompTIA. Spotted an error? Tell us.