Instead of thinking of incident response as multiple steps with a distinct beginning and end, it is better to think in terms of waypoints, outcomes, and actions.

During an incident, there are usually multiple events occurring across time, some of which overlap (i.e., many things will happen at once). For example, the incident response team needs to detect an incident before verifying it, but doesn’t stop everything because of an incident. Detection is an ongoing activity, and detecting an incident is just a waypoint in the process of incident response. Similarly, analyzing files on a file system as part of the eradicate step may reveal attacker tactics not previously known during the initial detect phase, requiring us to repeat earlier steps to better understand the systems affected. When we think of incident response in terms of steps, we artificially apply an arbitrary start and stop event for each element of the incident response process, as shown in Figure 2. This can limit the effectiveness of the incident response process, hampering flexibility and agility in responding to incidents. When we think about process elements as waypoints, outcomes, and actions, we can better understand the dynamic nature of incident response, and how the actions are not linear, as shown in Figure 3.

In the DAIR model, we emphasize the importance of waypoints, outcomes, and actions to better reflect the dynamic nature of incident response, and to recognize the activities that are ongoing and iterative throughout the incident response process.

The background element surrounding the actions in Figure 4 denotes all the elements where we, as incident response analysts, will seek insight from decision makers: important stakeholders, management, executive leadership, and other people who reflect the interests of the organization.

As technical analysts, we bring expertise in threat detection, forensic analysis, and incident response procedures. However, we cannot operate in isolation from the business priorities and operational realities of the organization. Decision makers provide essential context about what matters most to the organization, which systems are most critical, what data is most sensitive, and what operational impacts are acceptable during an investigation.

The incident response team should actively seek guidance from decision makers throughout the incident lifecycle. This collaboration ensures that investigative decisions align with organizational priorities rather than pursuing every technical lead regardless of business impact. For example, decision makers can help the IRT understand:

This coordination ensures the IRT makes informed decisions that balance security imperatives with operational realities.

Consider an example incident where an attacker has compromised multiple systems across the organization, including both production database servers and employee workstations. The IRT has identified IOCs on fifteen systems total: five production database servers that support customer-facing applications, and ten employee workstations in the finance department. From a purely technical perspective, the team might investigate all systems simultaneously using the same priority level.

However, by coordinating with decision makers, the IRT learns that:

Armed with this business context, the IRT adjusts their approach. They prioritize forensic collection from the production database servers using live response techniques that minimize service disruption, coordinating a brief maintenance window during low-traffic hours for containment actions. For the finance workstations, they implement network segmentation to contain the threat while allowing continued access to critical financial systems, scheduling more disruptive forensic analysis for after the quarterly close deadline.

This decision-maker-informed approach achieves the security goals of containing the threat and conducting thorough investigation while respecting the operational realities and priorities of the business. Without this coordination, the IRT might have taken actions that were technically sound but organizationally damaging, such as taking all systems offline simultaneously for imaging.

Throughout the incident response process, we will communicate with and get input from decision makers to ensure that incident response actions align with organizational priorities.

The DAIR model introduces two new waypoints not explicitly called out in other incident response models: verify and triage, and scoping. These waypoints are essential for effective incident response, and warrant inclusion as dedicated waypoints in the incident response process.

The verify and triage waypoint follows the detect waypoint to emphasize the need to validate that an incident is indeed an incident, and to prioritize incidents based on organizational goals, as shown in Figure 5.

When an incident is declared and the team responds, it can negatively affect the organization, including diverting resources from other projects or reducing the performance of systems under investigation. The verify action ensures that the observed event is indeed an incident, and one that requires an incident response action.

Next, the triage action helps to prioritize incidents based on organizational objectives, ensuring that the incident response team focuses on the most important incidents first. This is especially important for incidents with broad organizational impact, allowing decision makers in the organization to coordinate with the incident response team to ensure that the most important incidents are addressed first.

The verify and triage waypoint is unique in the DAIR model in that both actions happen concurrently. This is because both require insight and coordination with decision makers to ensure that the incident response team responds to the right incidents with the right resources.

The scope waypoint is essential for understanding the breadth of the incident, the systems involved, and the potential impact on the organization. When we perform scoping, we use the information gathered during the detect and verify actions to gain insight into the attacker’s TTPs to identify Indicators of Compromise (IOCs). Once we identify one or more IOCs, we can use them to scope the incident, identifying the systems affected and the potential impact on the organization.

For example, if we identify a phishing email as the initial vector of attack, we can use the domain name of the phishing lure to determine any other systems that may have been involved in the attack. This insight allows us to better understand the breadth of the incident and identify the systems involved that require additional investigation.

The response actions loop is an important element of the DAIR model, emphasizing the inherent need to repeat multiple actions in the incident response process. The loop itself is not necessarily linear, where we perform each action in sequence. Instead, it represents an iterative analysis function, using the conventional contain, eradicate, and recover waypoints as necessary to respond to the incident, while constantly integrating the scope activity to improve our understanding of the incident details.

For example, a response action loop may start with a single system being compromised following the verification of an unauthorized user account IOC. Upon containing the system and collecting data for analysis, the incident response team may identify that the user account is associated with a scheduled task that runs malicious code. This insight is valuable for additional scoping, to identify other systems with similarly-configured scheduled tasks that may indicate additional compromises. Only after continued investigation and scoping can the incident response team effectively eradicate the threat and recover the systems.

The response actions loop is repeated as many times as necessary to perform the required response functions, guided by the needs of the business. In practice, these actions are repeated multiple times until no new evidence of compromise is found, and the incident response team (and decision makers) are confident that the incident has been effectively addressed.

The Dynamic Approach to Incident Response (DAIR) model emphasizes the dynamic nature of incident response, and the need for flexibility and agility in responding to incidents. It prioritizes new waypoints, such as verify and triage, and scoping, to ensure that the incident response team responds to the right incidents with the right resources. It also emphasizes the response actions loop, which is an iterative process that is repeated as many times as necessary to effectively respond to the incident, while coordinating with decision makers to ensure that incident response actions align with organizational priorities.

In many ways, the DAIR model does not significantly deviate from the PICERL or the NIST SP 800-61 models, continuing to embrace the important elements of incident response that have been developed over time and proven to be effective for many organizations. Rather, it helps us to reshape the existing models while identifying important additional considerations. The DAIR model allows us to apply the same phases to more effectively prepare for, identify, respond to, and review the effectiveness of the incident response function.

Next, we’ll look at each of the important waypoints in the DAIR model in more detail.