Dynamic Incident Response and the Details That Matter

Talk about feeling validated! I am making my way through the SANS Dynamic Incident Response Framework, and I could not feel more excited! Yes, reading about incident response sounds fun to me.

The framework introduces the concept that incidents don't happen in a linear way. Instead, it uses waypoints that allow you to move between stages of an incident rather than following a step-by-step process. In my experience, this is a more realistic approach to incident response. During an incident, not everything is clear, and more often than not, actions are happening in parallel or simply not in "order."

The framework presents the incident lifecycle as a cyclical, iterative process, allowing movement between phases rather than a fixed, one-way path. For example, you may be in the eradication phase (or so you think), and the next thing you know, the threat actor is using a secondary entry point, and you're going right back to containment.

The framework also introduces Verify and Scoping as new phases of the incident lifecycle, along with a greater emphasis on preparation.

The preparation phase takes dedicated resources, which is why it is often put on the back burner when it comes to priorities. But as the framework lays out, "much of the incident response team's time should be spent in preparation."

Preparation is All About the Details

Preparation takes more work because the organization is not only sharpening its technical capabilities but also developing and updating policies based on lessons learned and priorities.

During this phase, the IR team also needs to practice calling stakeholders to an incident. Go through the process of establishing how you will bring everyone to the table and what methods you will use. Are you using your regular communication channels, or are you establishing Out-of-Band (OOB) communications? If so, do stakeholders know how to recognize an emergency call?

This is when you want to establish guidelines. You may not want to title a meeting invite "Incident Call January 2026." Prepare the details. They will save you time and perhaps even a meeting with the legal department.

The details may not seem important, but they are.

For the purposes of this post, we will assume your organization already has an incident response plan that defines what constitutes an incident.

Your playbook will begin with a README document. This will serve as a guide for you (or the person orchestrating the incident), walking through the process step by step and explaining what each document is for. Establish a naming convention not only for your incident but also for your communications bridge.

• Create a workflow that establishes the process. For example, when an incident is confirmed, who is responsible for triggering the process? Who has the authority to make that decision?
• Next, who will be triggering communications? Unless this is a very small organization, this should never be the responsibility of the CISO or the Incident Handler. The IR team should stick to following this process, even for smaller incidents. The individuals called may vary depending on the size and scope of the incident, but the initial response procedure should remain the same. After all, it serves as practice for bigger incidents.

• Exercise your communications process. You have now decided who has the authority to initiate the process and who is responsible for triggering it.

  Let's assume the organization has decided to use Out-of-Band (OOB) communications to handle incidents. The assumption is that a threat actor may have visibility into regular communications, and the organization doesn't want to risk information getting leaked.

  This takes some preparation and leadership buy-in because you will be conducting an exercise. Small, yes, but an exercise nonetheless. It will require calling in the IR team and additional stakeholders, which often includes leadership. When communicating with leadership, it's important to coordinate and share the details before the exercise so participants understand what is happening and why.

  This is your opportunity to take note of any challenges encountered during the exercise so you can make adjustments. Perhaps you don't have the correct contact information for a key stakeholder, or someone is unable to join the call due to technical difficulties.

  A live incident is not where you want to iron out these details.

There is a thrill that comes with reacting to incidents, but thrill is not the same thing as chaos. An incident doesn't mean everyone's heads are on fire. The work that takes place during the preparation phase can make an incident feel less chaotic and more organized.

I am making my way through the rest of the framework and will continue the series with the remaining changes and my thoughts. For now, here's a small excerpt of my next post.

Scoping During a Live Incident

In my experience, IR doesn't happen in a linear way, and oftentimes you're going back and forth between isolation, containment, and eradication. But the part that stands out to me about this framework is how it explicitly calls out Scoping as its own phase in the incident lifecycle, rather than treating it as an activity within other phases.

Scoping happens in a continuous loop because until an incident is closed, you may be gathering evidence and finding new information throughout the entire lifecycle of an incident.