Incident Response Lifecycle and Digital Forensics Basics

Step 1: See incident response as a cycle

Older guidance described preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. Revision 3 maps the work onto the CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover, with continuous improvement feeding back into preparation. The practical point is the same: most of the success comes from work done before the incident, and lessons learned afterward must change how you prepare.

Prepare   : roles, contacts, playbooks, logging, backups, practice
Detect    : alerts, reports, triage, confirm that it is a real incident
Respond   : contain, investigate, eradicate, communicate
Recover   : restore, verify, monitor closely
Improve   : lessons learned, update controls and playbooks

Step 2: Prepare before anything happens

Write an incident response plan with clear roles: who leads, who communicates with management, legal, and customers, and who handles the technical work. Keep an up-to-date contact list that works when email is down. Make sure logs exist and are centralized, backups are tested and kept offline or immutable, and playbooks exist for common cases such as ransomware, stolen credentials, and phishing. Run tabletop exercises, where the team talks through a scenario, to find gaps cheaply.

Step 3: Triage and confirm

Not every alert is an incident. Gather facts: what was observed, on which systems, since when, and whether it is still happening. Decide severity from impact on data, operations, and people. Start a timeline and an incident log immediately, and write down times and actions as you go, because memory fades and decisions will be reviewed later.

Step 4: Contain, then eradicate

Containment stops the spread: isolate affected hosts from the network, disable compromised accounts, revoke tokens and keys, and block malicious addresses. Prefer isolating over powering off when you can, because shutting down destroys volatile evidence in memory. Eradication removes the cause: delete malware, close the entry point, patch the vulnerability, and reset credentials broadly enough that the attacker cannot return. Decisions that affect the business should be made with the incident lead, not alone.

Step 5: Preserve evidence carefully

Collect evidence from the most volatile to the least volatile: memory and running processes first, then network connections, then disks and logs. Work on copies, never on the original. Record a cryptographic hash of every evidence file when collected, so you can prove later it was not changed, and document who handled it and when, which is called chain of custody. If legal action is possible, involve legal counsel and trained forensic specialists early.

# record the state of a live Linux host you are authorized to investigate
date -u > triage.txt
who >> triage.txt
ps aux >> triage.txt
ss -tulpn >> triage.txt

# fingerprint your evidence so changes are detectable
sha256sum triage.txt > triage.txt.sha256

Step 6: Recover, communicate, and learn

Restore systems from known-good backups or rebuilds, verify they are clean and patched, and monitor them closely for signs of the attacker returning. Communicate honestly and on time with affected parties, and meet any legal breach-notification duties, which vary by country and sector. Within days, hold a blameless post-incident review: what happened, what worked, what did not, and what will change. Turn the answers into new detections, fixes, and updated playbooks.