The SANS PICERL Model

Preparation is the stage that determines how well everything else will go. An organisation that skips Preparation is reduced to improvisation when an incident occurs. The goal of Preparation is to ensure that people, processes, and technology are in place before an incident is declared, not during it.

Preparation covers four categories of activity. First, policy: the organisation must have a formal incident response policy that defines what constitutes an incident, who has authority to declare one, and what the legal obligations for notification are. In the European Union, GDPR Article 33 requires notification of certain personal data breaches to the supervisory authority within 72 hours. In the United States, sector-specific rules such as HIPAA's Breach Notification Rule and SEC cybersecurity disclosure rules impose similar requirements. India's Digital Personal Data Protection Act 2023 places notification obligations on data fiduciaries. Organisations operating across jurisdictions must map all applicable requirements into a single notification matrix.

Second, team: the organisation must define its Computer Security Incident Response Team (CSIRT) structure, including roles, escalation paths, and out-of-hours contact procedures. Third, tooling: forensic jump bags, disk imaging tools, network capture utilities, secure out-of-band communications, and access to preserved log storage must all be ready before an incident, not assembled during one. Fourth, playbooks: written, tested procedures for the most likely incident types (ransomware, insider threat, DDoS, credential compromise) reduce decision time under pressure and ensure consistent handling across different analysts. Forensic readiness planning is a formal discipline within Preparation that ensures log sources, chain-of-custody procedures, and evidence handling practices are in place before they are needed.

Identification is the stage in which the organisation detects that something may be wrong, investigates to confirm whether it is a genuine incident, and formally declares an incident if the threshold is met. The challenge is that most alerts are not incidents. Security Operations Centre (SOC) analysts in large organisations review thousands of alerts per day; the majority are false positives. Effective Identification requires both good detection tooling and skilled human judgment to separate signal from noise.

Detection sources include Security Information and Event Management (SIEM) systems, endpoint detection and response (EDR) platforms, network intrusion detection systems (NIDS), threat intelligence feeds, and reports from users or third parties. Once an alert is triaged as potentially real, the analyst gathers additional evidence: log data, memory contents, network captures, and any indicators of compromise (IoCs) that confirm malicious activity. The outcome of this investigation is a declaration: either the event is confirmed as an incident, with an assigned severity, or it is closed as a false positive with documentation explaining the decision.

Incident severity classification determines the speed and scale of the response. A compromised endpoint with no evidence of lateral movement is a low-severity incident handled by a small team. Confirmed ransomware with active encryption across multiple file servers is a critical incident that triggers executive notification, legal involvement, and potentially external forensic support. The severity criteria must be defined during Preparation so that classification during Identification is fast and consistent, not debated in the moment.

Containment stops the incident from spreading further. The goal is to limit damage without immediately destroying the evidence or tipping off the attacker prematurely. Containment decisions must balance three competing concerns: stopping harm, preserving evidence, and maintaining business continuity.

Short-term containment is the immediate action taken as soon as an incident is confirmed: isolating an infected host from the network, blocking a malicious IP address at the firewall, disabling a compromised user account, or taking a system offline. These actions stop the bleeding. They must be taken quickly, but with care: shutting down a system before acquiring volatile memory means losing RAM contents, running processes, and network connections that may be the only evidence of the attacker's methods.

Long-term containment is the stabilised state that allows the organisation to operate while Eradication is prepared. In some incident types, particularly those involving advanced persistent threats, the organisation may choose to maintain limited attacker access under careful monitoring to gather intelligence about the threat actor's tools and objectives before evicting them. This decision carries legal and ethical implications and requires explicit authorisation from senior management and legal counsel. In most cases, long-term containment simply means running on clean backup systems while affected systems are rebuilt.

Eradication removes the root cause of the incident from every affected system. This means removing malware, deleting backdoors and persistence mechanisms, closing the initial access vector (patching the vulnerability, revoking the stolen credentials, removing the malicious email rule), and verifying that no remnants of the threat remain. Incomplete eradication is one of the most common causes of incident recurrence.

Eradication must cover every affected system, not just the first one discovered. Lateral movement means attackers commonly install persistence on multiple hosts before detection. Eradicating from one system while leaving backdoors on others results in re-compromise within hours of recovery. A thorough scoping exercise, typically done in parallel with Containment, identifies all affected systems so Eradication can be applied comprehensively.

For many modern attacks, particularly ransomware and supply chain compromises, eradication requires rebuilding affected systems from known-good media rather than cleaning in place. Cleaning an infected system relies on identifying every file and registry key the attacker touched; rebuilding from a verified image guarantees a clean state. The rebuild approach is more time-consuming but more reliable. The choice between clean-in-place and rebuild depends on the nature of the malware, the value of the system, and the time available.

Recovery restores affected systems and services to normal operation. It is the stage where business continuity considerations become primary. Recovery is not just a technical operation: it requires coordination with business owners, testing to confirm systems are functioning correctly, and monitoring to verify that the threat has not returned.

Recovery proceeds in a defined sequence. First, systems are restored from verified backups or rebuilt images. Second, the restored systems are tested in isolation before being reconnected to production networks. Third, services are brought back online incrementally rather than all at once, so that any recurrence of attacker activity is immediately visible against a smaller target surface. Fourth, enhanced monitoring is applied to recovered systems for a defined period, typically 30 to 90 days, to catch any persistence mechanism that was missed in Eradication.

The criteria for declaring Recovery complete should be defined in advance. A common standard is: all affected systems are online and verified clean, no anomalous activity has been detected for a defined monitoring period, all business-critical services are operational, and any regulatory notification obligations have been met. Without predefined criteria, Recovery tends to drag on indefinitely as teams argue about when it is safe to stand down.

Lessons Learned is the stage that turns an incident from a cost into an investment. Within a defined timeframe after the incident is closed (typically five to ten business days, while memory is fresh), the IR team conducts a structured debrief. The debrief produces an After-Action Report covering: the incident timeline, what detection tools or processes failed to catch the event earlier, decisions that were made during the incident and whether they were correct, gaps in playbooks or tooling exposed by the incident, and specific, assigned remediation actions with owners and deadlines.

The outputs of Lessons Learned feed directly into Preparation: new or updated playbooks, improved detection rules, additional training, tooling changes, or policy revisions. This loop is what makes the PICERL model a cycle rather than a linear process. Organisations that conduct genuine Lessons Learned reviews consistently improve their mean time to detect and mean time to respond over successive incidents.

Practitioners typically prefer PICERL when they want an operational checklist that separates distinct activities cleanly. Containment and Eradication have genuinely different objectives and failure modes; treating them as a single phase can cause teams to move to Eradication before Containment is stable, or to skip comprehensive Eradication checks in a rush to reach Recovery. NIST SP 800-61 is preferred in governance and compliance contexts because it maps cleanly to the control frameworks (ISO 27001, SOC 2, DORA in the EU) that reference it. Many organisations explicitly combine both: NIST language in the IR policy, PICERL structure in the operational playbooks. See Comparing IR Frameworks for a deeper treatment of other frameworks including ISO 27035 and CREST guidelines.