When a cyberattack hits, leadership and a well-coordinated security team jump into action on mitigation. But it takes planning ahead to ensure speedy recovery.

It would take five or more days to fully recover from a ransomware attack for two-thirds of companies, according to the 2020 Ransomware Resiliency Report. And it's pricey; a Sophos report found the average total cost of recovery from a ransomware attack in 2021 was $1.85 million. 

Incident response plans include a step-by-step guide on business recovery post-attack. Every member of security and IT teams knows their roles and responsibilities when an incident happens — and they can jump into action without hesitation. 

Having a plan is the first step toward recovery, but navigating the first draft of the plan can be intimidating. Cybersecurity Dive asked security executives, what is the most important component of your incident response plan? You can find the answers of five security leaders below. 

(The comments below have been lightly edited for length and clarity.)

Andy Bennett, VP of technology, CISO at Apollo Information Systems

---

"Defining actionable initiation and escalation triggers that are tied to business impacts takes the guessing game out of who should know, who should be involved and what everyone should be doing."

Andy Bennett

VP of technology, CISO at Apollo Information Systems

It may sound tongue-in-cheek, but the most important component of an incident response plan is to have one.

In an era where every organization is being actively targeted by capable attackers, far too many organizations have yet to even start the incident response planning process. Having a plan in place empowers organizations in a number of different ways, but the planning and testing processes are often the most useful components of the plan.

Eisenhower said that "plans are useless, but planning is indispensable," while Mike Tyson said that "everyone has a plan until they get punched in the mouth." Together, these sentiments paint the whole picture when it comes to incident response. Having and maintaining a robust incident response plan is valuable, but training and preparation are what makes responders able to pivot as the landscape changes, and stay standing as the hits keep coming. 

To directly answer the question: There are several critical factors in an effective incident response plan. It should define the team(s) that will be involved and prescribe communication and command structures. It should have a trigger and escalation criteria and define roles and responsibilities.

Not all incidents are created equally and not every bump in the night warrants a full-court press. Defining actionable initiation and escalation triggers that are tied to business impacts takes the guessing game out of who should know, who should be involved and what everyone should be doing. The involvement and sign-off of executive leadership is also a linchpin to successful IT planning.

More complex organizations may need more complex plans. These plans often include playbooks for specific scenarios, such as an APT detection, a BEC incident or a full-scale ransomware attack. More mature plans also include legal-approved form letters, templates and checklists for use in the response.

John Bambenek, threat intelligence advisor at NetEnrich

---

"The key to whether the plan can work is whether it has been simulated to ensure that the plan would work in a real incident."

John Bambenek

Threat intelligence advisor at NetEnrich

The most important part of an incident response plan is whether or not it's been tested. As one piece in the overall resiliency puzzle, an IR plan should increase certainty a business can continue its operations or keep downtime at a minimum.

It's possible to download an IR plan from the internet, fill in a few blanks and then call it implemented. The key to whether the plan can work is whether it has been simulated to ensure that the plan would work in a real incident. 

For instance, the type of incident most on people's minds is ransomware. An IR plan test for ransomware would include an attempt to recover key systems from backup and how long that recovery would take. Without a realistic understanding of how long recovery could take, the plan could make naive assumptions about the decision points regarding such an incident. 

In fact, one of the key metrics between whether a ransom would have to be paid is whether recovery from backups can be performed on a reasonable time scale. It's better to know what that looks like, and build capacity if necessary, to ensure that the plan is something feasible in an actual incident and that on-the-fly decisions do not need to be made. 

The point of the plan is to have a guide to follow if an incident occurs and if the guide has to be thrown out the window, it's nothing but wasted paper.

Sounil Yu, CISO and head of research at JupiterOne

---

"A great trigger for exercising an incident response plan is to take a recent publicly reported breach and walk through any unique circumstances to see how you might fare."

Sounil Yu

CISO and head of research at JupiterOne

As Mike Tyson famously quipped, "everyone has a plan until they get punched in the mouth." Security incidents are those proverbial punches in the mouth that you learn how to deal with by regularly exercising incident response plans under new and unanticipated conditions. 

A great trigger for exercising an incident response plan is to take a recent publicly reported breach and walk through any unique circumstances to see how you might fare. Given the steady stream of publicly announced breaches, organizations should have plenty of opportunities to use this trigger to exercise their incident response plans.

AJ King, CISO at BreachQuest

---

"The most important component of any incident response plan is delineating roles and responsibilities."

AJ King

CISO at BreachQuest

In almost every IR plan we review, a list of people and roles that should be involved is described. However, in most of these plans there is no description of the specific responsibilities attached to those roles. This usually creates confusion among staff during an incident.

While some responsibilities attached to roles are obvious, others are not. Anyone with military background knows how important it is to define the left and right bounds of fire, knowing where your responsibilities begin and end. When responsibilities are not effectively defined, the best case outcome is that multiple responders attempt to tackle the same problem (creating frustration and inefficient use of resources). The worst (and more common) case is that multiple other people in the IR team each believe that another member is completing a task, but nobody is.

We recommend creating a table in the incident response plan with high-level responsibilities for each role. With an easy to view responsibility matrix, it should be clear who is responsible for a given task. More importantly, it should be clear by reviewing the table when nobody is covering a particular task.

With this information readily available, any competent incident commander will explicitly assign the task to an appropriate party. Without a responsibilities matrix, it won't be clear until the task isn't performed that nobody realizes it was their responsibility. Creating a table of responsibilities is a critical step in any incident response plan.

Wayne Lloyd, CTO of federal at RedSeal

---

"Your teams and networks are constantly changing, so your plan should evolve as well with time."

Wayne Lloyd

CTO of federal at RedSeal

First, it's good you have a plan to begin with. But have you tested it? 

That is, have you gathered all your stakeholders, from the C-suite to the trenches, and run through your plan? And testing it once is not good enough. Your teams and networks are constantly changing, so your plan should evolve as well with time.

When an incident occurs, that is not the time to find out if your plan works. Testing turns up simple things, like having the ability to use outside communication mechanisms. If your system gets locked down by ransomware there is a good chance your address book in Outlook will be inaccessible. 

Part of testing is also getting to know your network by modeling it and examining how it's all connected. Having a continuously updated model of your network greatly speeds up your response time.