Incident Response 101: PICERL: The Six Stages of Cyber Grief

Series: Incident Response | Reading time: ~12 minutes | Author: Tech Corsair

Introduction: Why Every Organisation Needs a Plan (Yes, Even Yours)

There is a special kind of confidence that comes from never having dealt with a security incident. It is the same confidence exhibited by someone who has never locked themselves out of their house. "That won't happen to me," they say, usually about six weeks before it happens to them.

Incident response is not optional. It is not a nice-to-have. It is the difference between "we detected and contained a breach in four hours" and "we found out from a journalist that our customer database has been on a Telegram channel since March." One of these outcomes makes the board mildly uncomfortable. The other one makes it into a parliamentary inquiry.

The industry-standard framework for handling security incidents goes by the acronym PICERL, and it maps neatly to NIST Special Publication 800-61 (Computer Security Incident Handling Guide). It has six phases. They are sequential in theory and chaotic in practice. Let us walk through them.

Phase 1: Preparation -- "Before the Fire"

Preparation is everything that happens before something goes wrong. It is the phase where organisations either invest properly or produce a 200-page incident response plan that nobody has read, stored on a SharePoint site that nobody can find, protected by credentials that nobody remembers.

NIST SP 800-61 Rev. 2 (Section 2.3) frames preparation as establishing the incident response capability. In practical terms, this means:

People

• Incident Response Team (IRT): Who is on it? Are they trained? Do they know they are on it? (That last one is more common a gap than anyone likes to admit.)
• Escalation contacts: Legal, PR, executive leadership, law enforcement liaison, cyber insurance provider. All with current phone numbers. Written down. On paper. Because when the Active Directory is encrypted, the internal contact list in SharePoint is somewhat unhelpful.
• Third-party retainers: Digital forensics and incident response (DFIR) firms on retainer. The time to negotiate a contract with a forensics company is not at 2am on a Saturday when the file server is making unusual noises.

Process

• Incident Response Plan (IRP): A living document, tested at least annually through tabletop exercises. If the plan has not been updated since it was written, it is not a plan. It is historical fiction.
• Playbooks: Specific, actionable runbooks for common incident types: ransomware, business email compromise, data exfiltration, insider threat. Generic plans are comforting. Specific playbooks are useful.
• Communication templates: Pre-drafted holding statements, internal notification templates, regulatory notification letters. Nobody writes good prose under pressure.

Technology

• Logging: Centralised log collection with adequate retention. The minimum viable logging includes authentication events, process creation (Sysmon Event ID 1, or at the very least Windows Security Event ID 4688 with command-line auditing), PowerShell script block logging (Event ID 4104), and network connection logs.
• Detection capability: EDR on endpoints, network monitoring, SIEM with tuned alerting. "We'll check the logs after something happens" is not a detection strategy.
• Forensic toolkit: Write blockers, forensic imaging software, pre-built analysis VMs, chain of custody forms. Ready to deploy, not "somewhere in the IT cupboard."

The goal of preparation is to make the next five phases less terrible. It will not make them pleasant. But it will make the difference between an orderly response and a room full of people staring at each other asking "so… what do we do now?"

Phase 2: Identification -- "Is This Actually an Incident?"

Identification is the phase where someone notices that something is wrong and -- crucially -- correctly categorises it as a security incident rather than "the network being a bit slow today."

NIST SP 800-61 maps this to the Detection and Analysis phase. It is, in many ways, the hardest phase, because it requires distinguishing between:

• A genuine security incident
• A misconfigured application
• Dave from accounting trying to install a browser toolbar
• A false positive from the SIEM that has been firing every Tuesday since 2019

Signs of Compromise

Indicators fall into two categories:

Precursors -- signs that an incident may occur:

• Vulnerability scan activity from external IPs
• Threat intelligence indicating targeting of the sector
• Phishing campaigns hitting the mail gateway

Indicators -- signs that an incident has occurred or is occurring:

• Alerts from EDR/SIEM/IDS
• Unusual outbound network connections
• Unexpected privileged account usage
• Files encrypted with novel extensions (this one tends to be rather obvious)

The Escalation Decision

Not everything is an incident, and not every incident is a crisis. A sensible classification matrix helps:

The stakeholder communication matrix at this stage is straightforward: the IRT lead needs to know immediately. Everyone else can wait until there is something confirmed to tell them. Premature escalation to the CEO at 3am because of a false positive is a career experience best avoided.

Phase 3: Containment -- "Stop the Bleeding"

Containment is about limiting the blast radius. It is not about fixing the problem -- that comes later. Containment is the tourniquet, not the surgery.

NIST breaks this into short-term and long-term containment:

Short-term Containment

Immediate actions to prevent further damage:

• Network isolation: Disconnect compromised systems from the network. Not by pulling the power cable (that destroys volatile evidence). By disabling the network port, pulling the ethernet cable, or using EDR network isolation.
• Account disablement: Lock compromised accounts. Reset credentials. If the attacker has domain admin, this gets complicated quickly.
• Firewall rules: Block known malicious IPs and domains at the perimeter.

Long-term Containment

Temporary measures that allow business to continue while the incident is being resolved:

• Rebuild from known-good media for critical systems
• Enhanced monitoring on systems that cannot be immediately taken offline
• Temporary network segmentation to protect clean systems from potentially compromised ones

Evidence Preservation -- The Cardinal Rule

Before containment actions destroy evidence, collect volatile data first. The order of volatility (RFC 3227) dictates the priority:

1. CPU registers and cache (seconds)
2. RAM / running processes (lost on reboot)
3. Network connections and routing tables (transient)
4. Running processes and open files (transient)
5. Disk contents (persistent but alterable)
6. Remote logging and monitoring data (persistent)
7. Physical configuration and network topology (persistent)
8. Archival media (persistent)

The rule is simple: collect the most volatile evidence first, because it will be gone first. RAM dumps before disk images. Network connections before firewall changes. This is covered in much greater depth in the next article in this series.

---

Phase 4: Eradication -- "Removing the Tumour"

Eradication is the phase where the root cause is eliminated. Not just the symptoms -- the actual cause. This is the difference between removing malware from a system and understanding how the malware got there in the first place.

Eradication activities include:

• Malware removal: Cleaning or reimaging affected systems. (Reimaging is almost always preferable. "Cleaning" a rootkit is an exercise in optimism.)
• Vulnerability remediation: Patching the vulnerability that was exploited for initial access.
• Credential rotation: Resetting all potentially compromised credentials. When in doubt, reset them all. Yes, all of them. Yes, the service accounts too.
• Persistence mechanism removal: Checking for scheduled tasks, registry run keys, WMI subscriptions, and other persistence techniques the attacker may have established.
• Infrastructure hardening: Closing the gaps that allowed lateral movement -- unnecessary admin shares, overprivileged service accounts, lack of network segmentation.

The temptation during eradication is to move too quickly. Incomplete eradication leads to reinfection, which leads to re-doing the entire response, which leads to the kind of exhaustion that makes people update their CVs.

---

Phase 5: Recovery -- "Bringing It Back to Life"

Recovery is the process of returning affected systems to normal operations. It is also the phase where everyone is impatient because the business has been disrupted and there is pressure to "just get things working again."

Key recovery activities:

• System restoration: Rebuilding from clean backups or known-good images. The emphasis on "clean" cannot be overstated -- restoring from a backup that contains the attacker's persistence mechanism is a special kind of disappointment.
• Validation: Confirming that restored systems are functioning correctly and are free from compromise. Monitor restored systems closely for signs of reinfection.
• Phased return to service: Do not bring everything back at once. Restore critical systems first, monitor them, then proceed. This is not the time for "big bang" approaches.
• Enhanced monitoring: Increased logging and alerting on recovered systems for a defined period. The attacker may return. They often do.

Recovery is complete when systems are restored, validated, and operating normally with appropriate monitoring in place. Not when someone declares it complete because they want to go home.

---

Phase 6: Lessons Learned -- "The Phase Everyone Skips"

And here it is. The final phase. The most important phase. The phase that transforms a painful experience into organisational improvement. The phase that, in survey after survey, is the one most frequently skipped, abbreviated, or conducted with all the rigour of a New Year's resolution about going to the gym.

NIST SP 800-61 Section 3.4 calls this the Post-Incident Activity phase. It recommends conducting a lessons learned meeting within several days of the incident's conclusion. Several days. Not several months. Not "when things calm down." Not "never."

Why It Gets Skipped

The reasons are always the same:

• "We're too busy catching up on the work that piled up during the incident"
• "Everyone already knows what happened"
• "We don't want to point fingers"
• "There's another incident"

These are all understandable. They are also all wrong. Skipping lessons learned is the organisational equivalent of touching the hot stove, pulling your hand back, and then carefully placing it on the stove again next week because you never discussed what went wrong.

What a Proper Lessons Learned Session Covers

The meeting should address, at minimum:

1. Timeline reconstruction: What happened, when, and in what order? Build a detailed timeline. This is not about blame -- it is about understanding.
2. What worked well: Celebrate the things that went right. The analyst who spotted the initial alert at 11pm. The backup strategy that actually worked. The communication plan that prevented a PR disaster.
3. What did not work well: Identify the gaps honestly. Was detection too slow? Were playbooks missing or outdated? Was the escalation path unclear? Did anyone have to google "how to do a RAM dump" during the incident? (No judgement. But that is a training gap.)
4. Root cause analysis: Not just "a user clicked a phishing link" but why the phishing link bypassed email filtering, why the payload executed despite endpoint protection, why the attacker was able to move laterally, and why the data was not segmented.
5. Recommendations and action items: Specific, measurable, assigned, and tracked. "Improve security" is not an action item. "Deploy application whitelisting to all domain controllers by Q2" is an action item.
6. Metrics: Time to detect, time to contain, time to eradicate, time to recover. These become the baseline for measuring improvement.

The Report

The lessons learned report should be written while memories are fresh. It should be factual, not political. It should be distributed to stakeholders with appropriate classification. And critically, the action items should be tracked to completion -- not filed in the same SharePoint site as the incident response plan that nobody read.

The Uncomfortable Truth

Organisations that skip lessons learned do not just miss an opportunity to improve. They actively choose to remain vulnerable to the same attack, executed in the same way, exploiting the same gaps. The attacker is learning from the engagement. The question is whether the defending organisation is doing the same.

The lessons learned phase is the flossing of incident response. Everyone agrees it is important. Everyone agrees it should be done. And yet, somehow, it is the first thing to be dropped when time is short. The difference is that skipping flossing results in an uncomfortable conversation with a dentist. Skipping lessons learned results in an uncomfortable conversation with a regulator, a board, or -- in particularly bad cases -- a parliamentary committee.

---

Mapping PICERL to NIST SP 800-61

For reference, the mapping between the two frameworks:

PICERL Phase	NIST SP 800-61 Phase
Preparation	Preparation (Section 2.3)
Identification	Detection and Analysis (Section 3.2)
Containment	Containment, Eradication, and Recovery (Section 3.3)
Eradication	Containment, Eradication, and Recovery (Section 3.3)
Recovery	Containment, Eradication, and Recovery (Section 3.3)
Lessons Learned	Post-Incident Activity (Section 3.4)

NIST groups containment, eradication, and recovery into a single phase. PICERL separates them because, in practice, they are distinct activities requiring different skills and different decisions. Both are correct. Neither is wrong. This is cybersecurity -- there is always more than one framework for the same thing.

---

Key Takeaways

• Preparation is not optional. The time to build incident response capability is before the incident.
• Identification requires training and tools. You cannot respond to what you cannot detect.
• Containment preserves evidence. Volatile evidence first, always.
• Eradication must be thorough. Incomplete eradication means doing it all again.
• Recovery is not the end. Monitor recovered systems. The attacker may return.
• Lessons learned is the most important phase. Do it. Actually do it. Write it down. Track the actions. Do not skip it. Seriously.

---

Next in the series: Incident Response 102: Evidence Preservation, or "Stop Touching Things" -- a deep dive into evidence collection, chain of custody, and why the first thing everyone does at a compromised system is exactly the wrong thing.

---

Tags: incident-response, PICERL, NIST-800-61, IR-framework, security-operations, lessons-learned

Category: Incident Response

Series: Incident Response Fundamentals