Incident Response

Incident Response

Incident response (IR) is the coordinated process of detecting, containing, eradicating, and recovering from a security incident. Its primary purpose is to minimize damage and restore normal operations as quickly as possible. Unlike digital forensics, which prioritizes completeness and legal defensibility, incident response prioritizes speed — every minute an attacker remains active is additional exposure.

See also: Digital Forensics vs. Incident Response for a discussion of how and when the two disciplines intersect.

Frameworks

Two frameworks dominate incident response practice. They cover the same ground but carve it differently.

NIST SP 800-61r3

NIST’s Computer Security Incident Handling Guide (most recently revised in 2025) aligns IR activities with the NIST Cybersecurity Framework 2.0 functions. The earlier revision (r2) defined four discrete phases that remain widely referenced:

Phase	Activities
Preparation	Policies, team structure, tooling, playbooks, training, communication plans
Detection and Analysis	Identify events, triage, determine scope and severity, escalate
Containment, Eradication, and Recovery	Isolate, remove attacker, restore service
Post-Incident Activity	Lessons learned, metrics, process improvements

SANS PICERL

The SANS model expands the NIST containment/eradication/recovery phase into three distinct steps, making the operational sequence more granular:

Phase	Key actions
Preparation	IR policy, team roles, playbooks, tools, tabletop exercises
Identification	Detect the event, confirm it is a real incident, classify severity
Containment	Short-term: stop the spread. Long-term: stabilize while preserving evidence
Eradication	Remove malware, close access vectors, delete unauthorized accounts
Recovery	Restore from clean backups, validate, monitor closely
Lessons Learned	Post-mortem within two weeks; update playbooks and controls

Both frameworks are valid. NIST r3 places greater emphasis on continuous improvement and integration with risk management; SANS PICERL is more operationally prescriptive. Most practitioners are familiar with both.

Phase Detail

Preparation

Preparation is the only phase that happens before an incident. Everything that makes the other phases faster and less chaotic depends on preparation work done in advance.

Team structure. A Computer Security Incident Response Team (CSIRT) needs defined roles before an incident forces ad hoc decisions. Core roles:

Incident Commander — owns the overall response, makes containment/escalation decisions
Technical Lead — directs the hands-on investigation and remediation
Communications Lead — manages internal and external messaging
Legal/Compliance — advises on notification obligations, evidence handling, law enforcement coordination

Playbooks. A playbook is a pre-written, scenario-specific procedure for a class of incident (ransomware, credential compromise, insider threat, data exfiltration). Writing playbooks before an incident forces you to think through decisions while calm rather than under pressure. A good playbook answers:

What is the detection trigger?
What evidence must be preserved before any action?
What containment options are available and what are the side effects of each?
Who decides to take a system offline?
What are the notification obligations and deadlines?
What does a clean bill of health look like before recovery is declared complete?

Communication plan. Incidents require communicating with audiences who have very different needs: technical responders need detail; executives need status and decision points; legal needs to know what was affected; regulators may have statutory notification requirements. Establish channels and templates before they are needed.

Tooling. Responders need tools available before an incident, not acquired during one. At minimum:

Live acquisition tools (Velociraptor, KAPE, or equivalent)
Disk imaging capability
Isolated analysis environment
Secure communication channel independent of potentially compromised infrastructure
Log aggregation and SIEM access

Identification

Identification has two stages: detection (something flagged) and triage (confirming it is a real incident worth escalating).

Most security alerts are false positives. Effective triage rapidly distinguishes confirmed incidents from noise:

Alert fires
    │
    ▼
Initial triage: Is this a real event?
    │
    ├── No / likely FP → document, tune detection rule, close
    │
    └── Yes / uncertain → open incident, assign IR lead
                                │
                                ▼
                        Scope assessment:
                        - How many systems affected?
                        - What data or services are at risk?
                        - Is the attacker still active?
                        - What is the likely incident type?
                                │
                                ▼
                        Severity classification → drive escalation

Severity tiers (example; vary by organization):

Tier	Description	Example	Response SLA
Critical	Active breach, critical systems at risk	Ransomware spreading across domain	Immediate; all-hands
High	Confirmed compromise, limited scope	Single host backdoor, no lateral movement	Within 1 hour
Medium	Probable incident, investigation ongoing	Suspicious outbound traffic from server	Within 4 hours
Low	Anomalous but unconfirmed	One failed privileged login	Next business day

Containment

Containment stops the incident from getting worse. It is divided into two stages:

Short-term containment prioritizes stopping active damage:

Isolate affected hosts from the network (not power — powering off destroys RAM)
Block the attacker’s known IP addresses and C2 domains at the firewall
Disable or lock compromised accounts
Preserve volatile evidence first if at all possible (see Evidence Preservation below)

Long-term containment stabilizes the environment while full eradication and recovery are planned:

Temporary patches or mitigations that allow business operations to continue
Heightened monitoring on affected systems and adjacent assets
Segmentation of affected network zones

The containment decision. Taking a production system offline has real business cost. The decision to isolate must weigh:

Risk of ongoing damage if the system stays connected
Risk of the attacker detecting the response and accelerating their actions (or triggering a cleanup routine)
Value of continued monitoring to learn about attacker tools and objectives
Business impact of the outage

For most incidents, isolate quickly. For highly sophisticated attackers where intelligence value is high, a short period of monitored activity while preparing rapid containment may be justified — but this is an exception, not the rule.

Eradication

Eradication removes everything the attacker installed, changed, or created. This is distinct from containment: containment stops the bleeding; eradication closes the wound.

Eradication tasks typically include:

Remove identified malware payloads from all affected systems
Delete unauthorized user accounts or SSH keys
Revoke and rotate all credentials that may have been exposed
Remove persistence mechanisms (scheduled tasks, startup scripts, modified cron jobs, registry run keys)
Patch or mitigate the initial access vector
Verify no additional systems were compromised that have not yet been identified

A common mistake: eradicating before completing scope assessment. If you clean the systems you know about before confirming there are no others, you may be recovering into an environment where the attacker still has access.

Recovery

Recovery returns affected systems to production. The core principle is to restore from a known-good state, not to repair a compromised one. A cleaned-up system is not the same as a clean system.

Recovery steps:

Restore from a pre-incident backup verified against a cryptographic hash
Apply all outstanding patches and the patch that closes the initial access vector
Re-enable monitoring and confirm the system appears in the SIEM
Validate application functionality before returning to production
Monitor the recovered system with heightened alerting thresholds for at least 30 days

Recovery is declared complete only when:

All affected systems are restored and validated
The initial access vector is confirmed closed
No evidence of remaining attacker presence exists
Monitoring confirms normal behavior

Post-Incident Activity

The lessons-learned phase is the highest-leverage, most frequently skipped phase. SANS recommends completing it within two weeks of incident closure — long enough to debrief without the adrenaline, short enough that details are still fresh.

A lessons-learned meeting should produce answers to:

What happened and when?
How was it detected? How long had it been active before detection?
What went well during the response?
What went wrong or took longer than it should have?
What controls, if present, would have prevented the incident or reduced its impact?
What changes to playbooks, tooling, or monitoring are needed?

These answers feed directly back into preparation for the next incident.

Evidence Preservation

Even in an IR context focused on speed, evidence preservation matters. It may be needed for legal action, insurance claims, regulatory inquiry, or simply understanding root cause. The key rule: capture before you contain.

Volatile evidence first

Power cycling a system destroys RAM. Isolating a system from the network destroys live connection state. Collect volatile artifacts before taking any action that destroys them:

# Running processes
ps auxf > /evidence/processes.txt

# Network connections (who is the attacker talking to?)
ss -tnp > /evidence/connections.txt
netstat -anp > /evidence/netstat.txt

# ARP cache (what other hosts has this system talked to recently?)
arp -n > /evidence/arp.txt

# Logged-in users
who > /evidence/who.txt
last > /evidence/last.txt

# Loaded kernel modules (rootkit check)
lsmod > /evidence/lsmod.txt

# RAM image (if time permits — requires a tool like avml or LiME)
avml /evidence/memory.lime

Chain of custody

Every piece of evidence must be documented from collection to court:

Who collected it, when, from which system
Cryptographic hash of every image or file (MD5 + SHA-256)
Every subsequent transfer: who received it, when, why, what they did with it
Storage location and access controls

A break in chain of custody does not always destroy evidence value in an IR context, but it will if the matter ever goes to court.

Incident Classification

Not every security event is an incident. A useful classification framework:

Classification	Definition	Example
Event	Any observable occurrence	Failed login, port scan
Alert	Event flagged by a detection system	SIEM rule triggered
Incident	Confirmed violation of security policy or confirmed harm	Malware executing, data exfiltrated
Major incident	Significant business impact, requires executive involvement	Ransomware across production environment
Breach	Confirmed unauthorized access to protected data	PII exfiltrated

Incident classification drives the response: who is notified, what SLA applies, what playbook is invoked, and whether legal or regulatory notification is required.

Communication During an Incident

Communication failures are among the most common sources of IR problems. Key principles:

Use out-of-band channels. If the attacker has compromised email or Slack, communications about the response may tip them off. Establish a secondary channel (phone, a separate collaboration platform, or an isolated comms environment) before incidents occur.

Restrict need-to-know. Broad awareness of an ongoing incident can cause premature public disclosure, stock price impacts, or tipping off an insider threat. Keep the circle small until containment is confirmed.

Prepare for external disclosure. Many jurisdictions have mandatory breach notification requirements with specific timelines (GDPR: 72 hours to supervisory authority; many US state laws: 30-60 days to affected individuals). Legal counsel should be involved from the start of any incident that may involve personal data.

Tabletop Exercises

The most effective way to prepare for an incident is to practice responding to one. A tabletop exercise presents a scenario to the IR team and walks through what they would do at each step, without touching real systems.

A good tabletop:

Uses a realistic scenario relevant to your actual threat environment
Involves all stakeholders (technical, legal, communications, management)
Is facilitated by someone who can inject complications (“the attacker pivoted to the backup server”)
Produces specific action items for improving playbooks, tooling, or team structure
Is run at least annually, and after any significant real incident