Module 5 of 6 — SOC Analyst Path
Module 05

Incident Response

⏱ 13 min read · 1 quiz question

Detecting a threat is only half the job. Once something is confirmed as a real incident, you need to respond — and how you respond in the first few minutes can be the difference between a minor disruption and a catastrophic breach. This module walks through the incident response process every SOC follows.

What is an incident?

Not every alert is an incident. An incident is a confirmed security event that has actually impacted or has the potential to impact the confidentiality, integrity, or availability of an organization's systems or data.

A failed login attempt from a strange IP is an alert. That same IP successfully logging in and accessing the HR database at 2am is an incident.

The IR Process (PICERL)

The most widely used incident response framework is NIST's six-phase process, often remembered as PICERL:

P
Preparation
Before anything happens — building playbooks, training the team, setting up tools, and establishing communication plans. The best time to prepare for an incident is before it happens.
I
Identification
Detecting and confirming that an incident has occurred. This is where SIEM alerts, EDR detections, and analyst investigation come in.
C
Containment
Stop the bleeding. Isolate affected systems, block malicious IPs, disable compromised accounts. The goal is to prevent the incident from spreading.
E
Eradication
Remove the threat entirely. Delete malware, close the vulnerability that was exploited, remove attacker-created accounts. Don't just contain — eliminate.
R
Recovery
Restore systems to normal operation. Rebuild from clean backups if needed. Monitor closely for any signs the attacker is still present.
L
Lessons Learned
After the incident, hold a post-mortem. What happened? How did the attacker get in? What did we do well? What would we do differently? Update playbooks accordingly.

Containment strategies

Containment is often the most urgent phase. The faster you contain, the less damage. Common containment actions:

  • Network isolation — Disconnect the affected machine from the network so the attacker can't receive commands or send data out. Most EDR tools can do this remotely with one click.
  • Account disabling — Disable any compromised user accounts immediately so the attacker can't use them again.
  • IP blocking — Add malicious IPs to the firewall blocklist to stop further communication.
  • DNS sinkholing — Redirect malicious domain lookups to a harmless server so malware can't reach its C2.
  • Password resets — Force password changes for affected accounts and any accounts that may have been exposed.
Don't touch the evidence: Before you wipe or rebuild a machine, make sure forensic evidence has been preserved. Taking a memory dump and disk image before remediation can be critical for understanding exactly what happened.

Severity levels

Not all incidents are equal. Most SOCs use a severity scale to prioritize response:

SEV 1 — Critical
Active breach in progress. Ransomware deploying. Immediate all-hands response.
SEV 2 — High
Confirmed compromise, contained but actively investigated. Escalated to senior analyst.
SEV 3 — Medium
Suspicious activity, unconfirmed. Being investigated. May be escalated.
SEV 4 — Low
Informational. Possibly a policy violation or false positive. Logged and monitored.

Writing an incident report

Every incident gets documented. A good incident report answers:

  • What happened? — A concise description of the incident
  • When did it start? — The earliest evidence of the attack
  • What systems were affected? — Hostnames, IPs, user accounts
  • How did the attacker get in? — The initial entry point
  • What did the attacker do? — Their actions once inside
  • How was it detected? — Which alert or tool caught it
  • What was the response? — Every action taken, with timestamps
  • What's the impact? — Data accessed, systems down, users affected
Documentation matters: Clear, timestamped documentation protects you legally, helps management understand what happened, and gives the team something to learn from. Sloppy docs = sloppy response.

Playbooks

A playbook is a documented, step-by-step procedure for responding to a specific type of incident. Instead of figuring out what to do in the middle of a crisis, you follow the playbook. Common playbooks include:

  • Ransomware response
  • Phishing investigation
  • Compromised user account
  • Data exfiltration detection
  • DDoS response

As a new analyst, you'll use playbooks constantly. As you gain experience, you'll help write and improve them.

Key Terms
Incident
A confirmed security event that impacts or threatens the confidentiality, integrity, or availability of systems or data.
Containment
The IR phase focused on stopping an incident from spreading — isolating systems, blocking IPs, disabling accounts.
Eradication
Completely removing the threat — deleting malware, closing vulnerabilities, removing attacker-created accounts.
Playbook
A documented, step-by-step procedure for responding to a specific type of security incident.
Post-mortem
A review meeting after an incident to analyze what happened, what worked, what didn't, and how to improve.
IOC
Indicator of Compromise. Evidence that a system has been breached — a malicious IP, a file hash, a suspicious domain name.
✦ Quick Check
Ransomware has been detected on a workstation and is actively encrypting files. What is the correct FIRST action?
Write the incident report
Wipe and rebuild the machine immediately
Isolate the machine from the network to stop it spreading
Notify the user to stop using their computer
← Previous
Next: Certs & Job Hunting →