The classic model used for incident response is the PICERL model (pronounced Pick Earl), developed by Dr. Eugene Schultz in 1990. ^[1] The PICERL model was refined over the following years by the US Navy, the Carnegie Mellon University Software Engineering Institute, and the SANS Institute. It provides a systematic framework for incident response.

PICERL is an acronym for the following steps:

Each step builds on the previous one, providing a logical progression from readiness through resolution.

This model is often illustrated as a linear set of steps or as a stepped process, as shown in Figure 1 and Figure 2. In both illustrations, the process starts by preparing the organization for an incident and performing identification steps to discover incidents (e.g., threat hunting, log analysis, incident reporting). When an incident is identified, the incident response team limits its impact by containing it and collecting evidence for analysis. Using this evidence, the incident response team assesses the incident details and eradicates the threat. After the threat is eradicated, the organization recovers from the incident, followed by a lessons learned analysis to improve future incident response.

The PICERL incident response model provides organizations with a clear framework for responding to incidents and has been widely adopted across the industry. It offers a practical set of steps to follow, and it emphasizes the need for actions that are often overlooked, such as limiting the attacker’s opportunities through containment and learning from incidents to improve future responses.

In 2012, the National Institute of Standards and Technology (NIST) published Special Publication 800-61, Computer Security Incident Handling Guide. NIST SP 800-61 provides recommendations for preparing for, detecting, analyzing, and responding to incidents. It describes a process known as the Incident Response Life Cycle, as shown in Figure 3, focusing on four main phases:

These phases emphasize the cyclical nature of incident response, with lessons learned feeding back into improved preparation.

The NIST model is similar to the PICERL model; however, it prescribes a more flexible approach to the elements that follow incident discovery, summarizing the containment, eradication, and recovery steps in the PICERL model as a single phase. SP 800-61 offers more detailed guidance on the detection and analysis phases, with a post-incident activity phase that emphasizes not only lessons learned analysis (like PICERL) but also the collection and analysis of metrics for future resource allocation, and incident information sharing with a broader community.

The evolution from NIST SP 800-61 Revision 2 to Revision 3 reflects a structural change in how NIST positions incident response within organizational cybersecurity programs. While the Revision 2 guide provided tactical incident handling guidance, the Revision 3 guide reframes incident response as an integrated component of broader cybersecurity risk management activities, eliminating the former four-step incident response life cycle model. The new revision, retitled "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile," aligns incident response with the NIST Cybersecurity Framework 2.0, moving away from the discrete incident handling methodology that characterized the previous version.

This restructuring changes the guidance on how organizations should approach incident response planning and implementation. Revision 3 requires incident response capabilities to be considered across the core CSF guidelines:

Together, these functions position incident response as one component of a comprehensive cybersecurity program rather than a standalone capability. ^[2]

The document now serves as a CSF 2.0 community profile, meaning organizations using the Cybersecurity Framework must integrate incident response considerations into their broader risk management processes and control implementations. The formerly circular incident response model is replaced with a flow that aligns with the CSF functions, as shown in Figure 4.

Revision 3 shifts from Revision 2’s prescriptive incident-handling procedures to Revision 3’s framework-oriented approach that emphasizes organizational integration. Where Revision 2 provided specific methodologies and workflows for incident response teams, Revision 3 focuses on how incident response activities should inform and be informed by enterprise-wide cybersecurity decisions. As a high-level strategy for organizations, the Revision 3 guide encourages a more holistic view of incident response, embedding it within the overall cybersecurity posture rather than treating it as a standalone function. This is an important evolution. It reflects the growing recognition that effective incident response requires coordination across multiple organizational domains, including IT, legal, communications, and executive leadership. However, it does so by removing the detailed, step-by-step guidance that many incident response teams have relied on to guide the technical aspects of incident response.

Many product and consulting service providers publish their own incident response models. These variations are often minor modifications of the PICERL model, with additional emphasis that reflects the publishing organization’s incident response practices and experiences.

For example, several organizations advocate a seven-step incident response model that adds a re-testing step after the lessons learned step.

Other variations include a communication or documentation step following the eradication step. These variations are not substantively different from the PICERL model, but they may offer additional guidance or greater emphasis on specific aspects of incident response important to the publishing organization.

Other guidelines advocate for a circular model. One example is the Virginia Tech Guide for Cyber Security Incident Response. This guide advocates for a response process that includes preparation, identification/detection/analysis, containment, eradication, recovery, and incident closure, returning to the preparation phase.

Each of these models aims to provide a structured, organized methodology for incident response, with slight variations that reflect the experiences and priorities of the organization that developed them. While these variations of the classic model may offer additional insights or emphasis, they generally fall short of addressing important shortcomings in how organizations should best respond to modern cybersecurity incidents.

While these models provide helpful guidance based on their authors' experience, several common shortcomings persist across them, including:

Understanding these limitations helps organizations adapt existing models to better fit their operational needs.

The shortcomings identified in this chapter are not failures of the models themselves but reflections of how incident response has evolved since their introduction. Modern incidents are more complex, affecting multiple systems across diverse environments, and organizations face increasing pressure to respond quickly while managing limited resources.

An effective incident response model should address these gaps directly. It should support an iterative process that accommodates the non-linear nature of real-world incidents. It should guide responders in scoping the breadth of an incident, verifying that an event warrants a response, and prioritizing resources in alignment with business objectives. It should also encourage root cause analysis as a standard part of the response effort.

The next chapter introduces such a model, one designed to reflect the realities of modern incident response while building on the foundational concepts that existing models provide.