Incident response (IR) is the structured process for detecting, containing, analyzing, and recovering from security incidents. The first hours of a breach response are critical — poor handling can turn a limited incident into a catastrophic one. Whether you’re building an IR capability for the first time or refining existing processes, this guide covers the NIST IR framework and practical steps that make the difference between a controlled response and a chaotic one.

The NIST Incident Response Framework

NIST SP 800-61r2 defines four phases:

Preparation: Building IR capability before an incident occurs
Detection and Analysis: Identifying and characterizing the incident
Containment, Eradication, and Recovery: Stopping the threat and restoring systems
Post-Incident Activity: Learning and improving

Phase 1: Preparation

The most impactful phase — organizations with good preparation respond dramatically better.

Incident Response Plan

Document before an incident:

IR team contacts: Primary and backup for each role (IR lead, legal, communications, executive)
Communication procedures: Who to notify, when, through what channels (encrypted email, Signal, etc.)
Asset inventory: Critical systems, their owners, recovery priority
Recovery time objectives (RTO): How long can each system be down?
Evidence preservation procedures: Legal admissibility requirements

Tooling

Ensure these are available before you need them:

Category	Tools
Log aggregation	Splunk, Elastic/ELK, Microsoft Sentinel, Graylog
EDR	CrowdStrike, SentinelOne, Microsoft Defender for Endpoint
Forensics	FTK Imager, dd, Autopsy, Volatility
Network analysis	Wireshark, Zeek, Suricata
Threat intel	VirusTotal, MISP, Shodan, OSINT tools
Communication	Slack dedicated IR channel, Signal for sensitive communications

Tabletop Exercises

Run quarterly tabletop exercises covering:

Ransomware attack scenario
Insider threat / data exfiltration
Cloud account compromise
Supply chain attack

Tabletops reveal gaps in procedures without the stress of a real incident.

Phase 2: Detection and Analysis

Initial Detection Sources

Incidents surface through:

SIEM/EDR alerts: Automated detection of known indicators
User reports: “My computer is acting weird” — often the first notice of ransomware
External notifications: FBI, law enforcement, or security researchers reporting compromise
Third-party notifications: Vendors, partners, or customers observing suspicious activity from your infrastructure

Initial Triage (First 30 Minutes)

When an alert fires or report comes in:

Log the initial time: Documentation starts now
Determine scope: Is this one endpoint, one network segment, or enterprise-wide?
Identify affected systems: Hostnames, IPs, user accounts
Preserve volatile data first: Memory dumps before rebooting anything
Check for ongoing activity: Is the attacker still active?

Memory acquisition (before anything else for suspected active compromises):

# Linux: using LiME
sudo insmod lime-$(uname -r).ko "path=/tmp/mem.lime format=lime"

# Windows: using WinPmem
winpmem.exe --output memdump.raw

Memory contains credentials, process trees, network connections, and encryption keys that disappear on reboot.

Initial Scope Assessment Questions

What systems show signs of compromise?
When did the incident begin? (Not when it was discovered — look for earliest indicators)
What data may have been accessed or exfiltrated?
Is the threat actor still active?
Are there indicators in other environments (cloud, partner networks)?

Evidence Collection

Collect in order of volatility (most volatile first):

Memory dump: RAM contents (volatile)
Network connections: netstat -an, open sockets
Running processes: ps aux, process tree
User accounts/sessions: Logged-in users, recent logins
Open files: Files held open by processes
Disk image: Full forensic copy of affected system’s storage
Logs: SIEM, EDR, auth logs, application logs
Network captures: PCAP from network taps if available

# Linux: capture current state
date >> incident_$(hostname).txt
netstat -an >> incident_$(hostname).txt
ps auxf >> incident_$(hostname).txt
last -F >> incident_$(hostname).txt
find /tmp /var/tmp /dev/shm -type f -newer /etc/passwd >> incident_$(hostname).txt

Phase 3: Containment, Eradication, and Recovery

Short-term Containment

Immediate actions to stop the bleeding — before full forensics:

Isolate compromised hosts: Remove from network (but don’t power off if memory preservation is needed)
Disable compromised accounts: Without alerting the attacker if active
Block C2 communication: Block attacker-controlled IPs/domains at firewall/proxy
Preserve state: Take snapshots of cloud instances before shutting down

Determine Attack Scope Before Eradication

Don’t start cleaning until you understand the full scope. Partially cleaning an incident while the attacker still has persistence leads to re-infection.

Questions before eradication:

Have all attacker-controlled accounts been identified and disabled?
Are there backdoors or persistence mechanisms in non-obvious locations?
Has the attacker moved laterally to additional systems?
Are credentials compromised (assume all credentials are compromised until proven otherwise)?

Eradication

Remove the threat:

Rebuild compromised systems from clean baseline (not from backup made after compromise)
Revoke and re-issue all credentials that may have been exposed
Remove all attacker-created accounts, persistence mechanisms, tools
Patch the vulnerability used for initial access

Recovery

Restore operations:

Restore from verified clean backups (verify they predate the compromise)
Monitor intensively during recovery — attackers often attempt to re-establish access
Staged return to normal operations — don’t restore everything at once

Phase 4: Post-Incident Activity

Lessons Learned (Within 2 Weeks)

Document with all IR participants:

Timeline: When did the incident start? When was it detected? Why the gap?
Root cause: What vulnerability, misconfiguration, or process failure enabled the attack?
What worked in the response?
What should change? (Priority-ordered action items)

Improve Defenses

Root cause drives improvements:

Phishing initial access → Additional email security controls, user training
Unpatched vulnerability → Vulnerability management process improvement
Lack of visibility → Additional logging, EDR deployment
Slow detection → Tuned SIEM rules, alert thresholds

IR Certification and Resources

For building IR expertise:

GCIH (GIAC Certified Incident Handler): Industry-standard IR certification
SANS FOR508: Advanced Incident Response course
Blue Team Labs Online: Free hands-on IR labs
NIST SP 800-61r2: Free complete IR framework guidance

Effective incident response is as much about process discipline and team coordination as technical skills. Build the plan, practice it, and the technical execution follows.