How to Create an Incident Response Plan From the Ground Up

Every organization that monitors for security threats must have a plan for handling a threat once it's discovered. Avoiding cyberthreats entirely would be ideal, but that is not reality. An incident response (IR) plan is designed to document your organization's plans for what you should do if a serious security incident happens. 

Some organizations build IR plans because they are told to do so by regulatory agencies. Others do so because they know efficiency in responding to an incident is a major factor in reducing its impact. Security incidents will happen, and the point of an IR plan is to reduce negative impact on the organization in the inevitable event of a cyberattack.

Here are the five steps that security professionals must take to design and implement an operational and effective IR plan.

Build the IR Practice
A good starting point is to create the IR plan document itself, which starts with building a vision for the IR practice. The document should contain the following components:

As the rest of the plan is developed, and as the IR program matures in the longer term, these sections may be amended and expanded upon.

Ensure That Incidents Can Be Detected
It's not the monitoring team's job to declare an incident, but it is their job to ensure that alerts of interest are properly vetted and escalated. Whether monitoring is done internally or via a service provider, the IR plan should define a process of handling, vetting, and escalating incidents of interest to ensure alerts move correctly and swiftly to the IR team lead. 

Be sure to only include threats that your security team has a means to detect in the scope of your IR plan. For example, if your plan states that data exfiltration from a certain database qualifies as an incident, but you have no detection technology in place to see such activity, then that incident should be removed from scope.

Decide to Formally Enter the IR Process
Declaration of an incident cannot be trivial, as executing the IR process will incur more work and more cost for the business. An incident should be declared when the business has decided that this threshold of attack is an unacceptable risk and they are willing to invest in minimizing the impact.

A single person must assume the role of IR lead at the point of an incident being escalated. The IR team lead, in collaboration with the broader cybersecurity team, is responsible for incident declaration. The plan will outline the process for the IR team lead to do so. 

First, the IR lead should further validate the incident by reviewing the data captured from the monitoring team and acquiring new information as needed. Then, the lead can call a meeting with defined stakeholders for the purpose of declaring an incident.. Identify a war room, virtual or physical, for holding this meeting, as well as fallback methods of communication if primary methods are unavailable.

If a decision is made to declare an incident, then the IR team lead now must execute the rest of the IR plan as designed. If the team decides not to declare an incident, the IR team lead should still create an after-action report and formally mark the matter as closed.

Execute the IR Plan
Once an incident has been declared, it's time to act. Concise, methodical actions that are well communicated and coordinated are key to reducing impact.

An IR plan needs a process flow outline, which should accomplish both the communication of the plan and the steps needed to respond to an incident. The start of the flow is the escalation from the monitoring team and the formal incident declaration process. If an incident is declared, then the flow outlines the steps to contain the threat and recover. 

Create a list of key stakeholders for each type of incident so that the IR team can quickly identify who is involved, when in the process they get involved, and what actions should be taken. Listing actual names and current contacts, not just roles, is a best practice to ensure accountability and maintain that the IR plan stays current. The IR team is responsible for owning and maintaining the plan document. 

Once an incident is declared, it's time for the IR lead and their team to act. Containment should be the priority, as the team seeks to isolate the impacted users, systems, applications, or other resources. The IR plan should consider the stage and severity of the attack for setting the containment strategy, and it should define how to execute the containment strategy and who has the authority. 

After the incident has been appropriately contained, it's time to start working on mitigation. Mitigation is the final set of actions to return a system/resource to normal usage. Mitigation actions will vary based on the type of incident and severity. For example, mitigation may involve just reimaging a system to restore it to a preattack configuration. Mitigation could also include documentation prior to reimaging to explore the root cause of the attack. The IR plan should include explicit mitigation actions, based on severity and type of incident.

Move From Good to Great
An IR plan should include a formal post-incident learning process that aims to reduce the likelihood of recurrence. In addition to trying to avoid having the same incident twice, the learning provides oversight for team readiness, which allows you to fine-tune coordination and decision making for declaring or acting on an incident. Be sure that any changes to the IR process are updated in the plan document.