IR Frameworks
PICERL, NIST 800-61, and SANS — where they agree, where they differ, and how to use a framework as a checklist without letting it become a substitute for thinking about the actual attacker in front of you.
An EDR alert fires at 11 PM. The on-call analyst escalates to the IR lead. Someone asks: "Are we in containment now or still in identification?" The question sounds useful but it isn't — the attacker doesn't care which PICERL phase you're in. What matters is: do you know what they own? Do they know you've found them? Have you preserved the evidence you'll need? Frameworks give you a checklist of questions to ask. They do not tell you the answers. This chapter maps the three major frameworks, shows where they agree on the essentials, and explains how to use them without letting phase-tracking become the goal.
PICERL
PICERL is the SANS framework: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. It's the most widely cited and the easiest to remember, which is why it appears on every GIAC exam and every IR job description.
PICERL Framework
═══════════════════════════════════════════════════════════════════
P — Preparation
IR runbooks written, tools deployed, contacts established,
tabletop exercises completed, asset inventory maintained.
Done BEFORE the incident. If you're doing it during, you're late.
I — Identification
From first alert to "yes, this is a real incident."
Scope it: what's compromised, how many systems, since when?
Determine severity. Define the blast radius.
C — Containment
Stop the bleeding. Short-term containment (isolate the host)
and long-term containment (patch, segment, rotate creds).
Preserve evidence — containment must not destroy what you need.
E — Eradication
Remove all attacker presence: persistence, malware, accounts.
Every single one. The attacker plants secondary persistence
specifically because IR teams stop after finding the first.
R — Recovery
Restore systems to normal operations. Verify clean before
reconnecting. Heightened monitoring during the recovery window
— attackers return to check if they've been evicted.
L — Lessons Learned
Post-mortem: what happened, how it was detected, what failed,
what detections would have caught it earlier.
Convert the incident into better security.
NIST SP 800-61
NIST Special Publication 800-61 (Computer Security Incident Handling Guide) is the US government standard. It uses four phases instead of six, and it emphasizes that the process is cyclical — lessons learned feed back into preparation for the next incident.
NIST 800-61 Lifecycle
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Preparation ←──────────────────────────────────────────┐ │
│ │ │ │
│ ▼ │ │
│ Detection & ──────────────────────────────► Post- │ │
│ Analysis Incident │ │
│ │ Activity │ │
│ ▼ ▲ │ │
│ Containment, Eradication, and Recovery ──────────┘ │ │
│ │ │
└─────────────────────────────────────────────────────────────┘
Key NIST additions beyond PICERL:
- Explicit documentation requirements (evidence preservation,
incident records, chain of custody)
- Incident prioritization criteria (functional impact, information
impact, recoverability)
- Reporting and notification requirements (legal, regulatory)
- Coordination with external parties (CISA, FBI, ISAC)
Framework Comparison
| Aspect | PICERL (SANS) | NIST 800-61 | Practical Takeaway |
|---|---|---|---|
| Phase count | 6 | 4 | Irrelevant — count phases only for exam prep |
| Emphasis | Practitioner checklist — hands-on steps | Program management — documentation, metrics, policy | PICERL drives the work; NIST drives the program |
| Preparation depth | Brief mention | Detailed — policy, procedures, contacts, training | Preparation is the only phase where you can't be improvising |
| Legal/regulatory | Not addressed | Explicit — breach notification, regulatory reporting | For real incidents, NIST compliance section is critical |
| Feedback loop | Implied in Lessons Learned | Explicit cyclical diagram | Both agree: every incident should improve the next response |
| Parallel tracks | Not modeled | Not modeled | Reality: containment, eradication, and forensics run in parallel, not serial |
Reality: IR Runs in Parallel, Not Serial
Both PICERL and NIST present IR as sequential phases. Real incidents are not sequential. In a real incident at 2 AM, the following happen simultaneously:
Parallel IR Tracks (real incident)
═══════════════════════════════════════════════════════════════════
Track: Forensics Track: Containment Track: Comms
───────────────────── ────────────────────── ──────────────
Collect memory from Isolate confirmed Brief CISO
confirmed hosts compromised hosts (15-min update)
│ │ │
Analyze initial Hold suspected hosts Draft SITREP
compromise vector (monitor, don't cut) for leadership
│ │ │
Find lateral movement Rotate credentials Notify legal
path for confirmed accounts if PII exposed
│ │ │
Determine blast Network containment Coordinate with
radius at firewall/DNS external IR firm
│ │ │
Identify persistence Disable attacker Preserve
mechanisms accounts in AD evidence for legal
Phases in frameworks describe types of work, not time ordering.
Multiple tracks run in parallel; the IR lead coordinates them all.
Phase-tracking creates a false sense of progress. Saying "we're in eradication" implies identification and containment are finished — but in a large-scale incident with ongoing lateral movement, containment is never truly finished until every compromised host is accounted for. More importantly, over-focus on phases distracts from the real question: "What can the attacker still do right now, and what are we doing to stop it?" Use frameworks as checklists of work that needs to happen, not as a timeline you pass through once.
Avoiding Checkbox IR
Checkbox IR means executing the framework steps without understanding the specific attacker and incident in front of you. It produces completed checklists and closed tickets while the attacker is still in the environment.
| Checkbox IR behavior | What it misses |
|---|---|
| Found one persistence mechanism → moved to eradication | Attackers plant secondary and tertiary persistence specifically anticipating IR. Finding the first is not finding all. |
| Reimaged the compromised host → closed the ticket | If you don't know how they got in, they'll use the same path again. Eradication without root cause identification is cleaning the symptom, not the disease. |
| Reset the compromised user's password → contained | The attacker likely moved laterally before you found the first compromised account. Other accounts they accessed are still valid. |
| Blocked the C2 IP in the firewall → severed the C2 | C2 infrastructure rotates. Blocking one IP is a temporary measure. Without confirming no active C2 session exists at the host level (process, network connection), the attacker may still have a callback running. |
A war room full of people triaging tickets and running containment actions looks like progress. But if each action is reactive — responding to what the attacker does rather than racing to understand the full scope — you're always one step behind. The first priority in any IR is to understand the blast radius: not just what you've found, but what you haven't found yet. Scoping aggressively before containing anything is counterintuitive but leads to better outcomes than containing the first thing you find.
How to Use a Framework
Use frameworks for two purposes: pre-incident checklists (what must be in place before the next incident) and post-incident audits (which phases were handled well and which were rushed or skipped). During the incident itself, manage by tracks and priorities, not by phase names.
| Before incident | During incident | After incident |
|---|---|---|
| PICERL Preparation: runbooks written? contacts established? tools deployed? tabletops done? | Track-based management: who owns forensics, containment, comms, legal? What's the current blast radius? What can the attacker still do? | PICERL Lessons Learned: what would have caught this earlier? What failed? What new detection rules do we write? |
| NIST: policies written? regulatory notification process documented? external coordination contacts established? | Evidence-first mindset: before touching anything, capture volatile data. Document every action with timestamp. | NIST Post-Incident: MTTD/MTTR measured? Regulatory notifications sent on time? Report drafted? |
Q & A
Q: NIST 800-61 says "containment, eradication, and recovery" is one phase. PICERL separates them into three. Which is right?
Neither is "right" — they're different framings of the same work. NIST bundles them because in practice they're tightly coupled: you often begin eradication (removing persistence on a contained host) while still containing other hosts in the same incident. PICERL separates them to give practitioners a distinct checklist for each type of work. For operational use, think of them as separate work categories running in parallel rather than sequential steps. The key question for each: Containment — is the attacker still able to act? Eradication — is all attacker presence confirmed removed? Recovery — are systems back to normal with verified clean state?
Q: How do you decide when identification ends and containment begins?
They overlap. Initial containment — isolating a single confirmed host — often happens during scoping, before you have the full picture. The practical trigger is: "Can I contain this now without destroying evidence I haven't collected yet, and without tipping off the attacker into destroying data or triggering a payload?" If yes, contain now. If isolating the first host would cause the attacker to detonate ransomware on the other 200 hosts they own, scope first. The framework doesn't resolve this judgment call — experience and situational awareness do.
Q: A manager says "we're in lessons learned now" but the IR team is still finding evidence of persistence. What do you do?
Push back with specifics: "We're not in lessons learned because we haven't confirmed eradication. We have [specific evidence] suggesting persistence mechanism X is still present on [specific hosts]. Closing the incident now means reopening it in a week when the attacker uses that persistence." Frameworks give you the language to make this argument: eradication requires systematic persistence removal and validation, not just stopping the immediate bleeding. Document the disagreement in writing if leadership insists on premature closure — because when the attacker returns, the record needs to show IR wanted to continue.