Incident Response Plans: The Complete Guide To Creating & Maintaining IRPs

Speedily minimizing the negative impact of an information security incident is a fundamental element of information security management. The risks — loss of credibility in the eyes of users and other stakeholders, loss of business revenue and critical data, potential regulatory penalties — can significantly jeopardize your organization’s mission and objectives.

For example, in October 2023, the British Library faced a ransomware attack that resulted in the breach of customer and employee personal data. The attack also crippled its digital services, some of which are yet to be restored as of this article’s publication. Estimates are that it will cost upward of 7 to 8 million USD to recover, as the institution refused to pay a ransom to recover lost data.

When faced with a cybersecurity incident, preparedness can be the differentiator that delivers effective response and containment. For this reason, organizations need to invest in a robust incident response capability that:

• Tackles cyberattacks with speed, effectiveness and efficiency.
• Complies with applicable requirements such as legal compliance and industry regulations.

An incident response plan provides the roadmap for building this capability. So, what is an incident response plan? It’s a document that spells out a systematic approach to handling cybersecurity incidents, such that a consistent methodology is followed.

How will you respond when this happens to you? (A sample of news articles about data breaches, Googled on 8 January 2024.)

In this article, we will look first at the what exactly goes into an incident response plan. Then, we’ll look at how to appropriately communicate this plan and — critically — how to maintain and update the plan over time.

(Related reading: incident management & incident severity levels 1-5.)

Components of an Incident Response Plan

A security and privacy control, the incident response plan is responsible for:

• Describing the structure and organization of the incident response capability and providing a high-level approach for how the capability fits into the overall organization.
• Defining the resources and management support needed to effectively maintain and mature this capability.

As organizations differ in size and scope, the incident response plan should be customized to meet the unique requirements that cater for a particular context. A good example of a wide ranging plan is the U.S. National Cyber Incident Response Plan published by CISA that spells out roles across different government levels, capabilities and coordinating structures.

In general, the incident response plan consists of the following elements as per the NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide:

Mission

A short description of the organization’s purpose and intentions as relates to incident response.

Strategies and goals

A summary of the broad actions or course of action for achieving the incident response objectives. SMART goals are best suited that encompass all elements of the incident response plan including training, testing, communication and technical aspects such as automation initiatives.

Leadership approval

Top management signs off that the plan has been reviewed, has the full buy-in, and will be appropriately resourced.

(Know your leadership roles: CISO, CIO, CPO and more.)

Organizational approach to incident response

Here, you’ll need to define and outline:

• The sequence of actions to be taken
• Responsible persons/teams
• Timelines
• Records required
• Tools/systems to be used

This may be grouped based on different incident scenarios e.g., the response to a system outage may be treated differently when compared to a phishing attack.

Communication approach

An outline of how information will flow from the teams responding to the incident to relevant internal and external stakeholders. Relevant data classification controls would be spelled out that apply to information going to external parties such as media, suppliers, customers and government agencies.

Metrics for measuring the incident response capability and its effectiveness

Examples of metrics that would be related to incident response as defined by ITIL 4 practice include:

• Time between incident occurrence and detection
• Time between incident detection and acceptance for diagnosis
• Time of diagnosis
• Percentage of waiting time in the overall incident handling time
• First-time resolution rate
• Meeting the agreed resolution time

(Read more about incident response metrics.)

Roadmap for maturing the incident response capability

Actions and timelines for achieving the highest level of capability. A maturity model such as CMMC can be adopted that outlines the controls required at a particular level.

How the program fits into the overall organization

The responsibilities within the incident response plan are mapped to the organizational job titles and roles. The overall responsibility may be given to a team termed Incident Response Team (IRT) whose members are drawn from different functions including technology, legal, human resources, corporate communication among others.

(Meet these roles: The Incident Commander & The Computer Security Incident Response Team.)

Additional elements

According to NIST SP 800-53 (Security and Privacy Controls for Information Systems and Organizations), for data breaches involving personally identifiable information (PII), the incident response plan can be enhanced with the following additional elements:

• A process to determine if notice to individuals or other organizations, including oversight organizations, is needed.
• An assessment process to determine the extent of the harm, embarrassment, inconvenience, or unfairness to affected individuals and any mechanisms to mitigate such harms.
• Identification of applicable privacy requirements.

As always, the level of detail within the incident response plan will vary depending on the scope of the organization.

Communicating an Incident Response Plan

Informing stakeholders about the incident response plan is a critical activity in ensuring its acceptance and adoption.

Part of the incident response capabilities involves the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain.

However, this communication must be carefully controlled — ensuring that sensitive information is not passed to unauthorized parties. For example:

• Software vulnerabilities communicated to the wrong persons might result in additional exploitation by malicious actors.
• The wrong message sent out following a cyberattack can lead to loss of confidence by markets and customers who may exaggerate the impact to the affected organization.

There are ways to avoid these issues. Within the incident response plan, designate appropriate communication responsibilities with relevant stakeholders. Here are some examples:

• Internal staff: The IT Service Desk may send out communication from a technical perspective regarding the incident response, while HR may send out any pertinent information from organizational policy or employee agreement perspectives.
• Media & corporate customers: The CEO or lead of the Corporate Communication functions may be assigned as the single point of contact with media organizations and social media channels.
• Government agencies: The head of security, legal or the CISO may be designated as the point of contact for communicating with government agencies during the incident response activities.
• Partners & suppliers: The head of IT or the CISO may communicated directly with impacted technology vendors, while the head of legal or supply chain may be the designated person to relay information with other non-technology partners and suppliers.

For any communication going out, multiple persons should review it first. Apply any designated information security controls such as data classification and data encryption.

(Related reading: third-party risk management.)

(See how Splunk solutions support the entire incident management practice.)

Maintaining an Incident Response Plan

The NIST SP 800-61 Rev. 2 Guide advises that, once your plan is approved, you should implement the plan. Importantly, you should review it at least once a year, if not more often, to ensure your organization is following the roadmap for maturing the capability and fulfilling incident response goals.

Some of the actions to be taken so that the plan becomes a living document that remains relevant for the organization include the following as spelled out by CISA:

• Conduct regular trainings with all relevant staff to make them aware of the incident response plan and their role in implementing it successfully.
• Meet with relevant stakeholders such as legal practitioners and government agencies who can review the plan and advise on any pertinent issue.
• Test and update the plan at least quarterly to ensure any gaps are addressed and opportunities for improvement incorporated. Simulation exercises are a good way of validating that the plan is fit for purpose.
• Update relevant policies and procedures to be in line with the updated plan.
• Conduct formal retrospectives after each actual incident to gauge performance and identify improvements.
• Report on performance of the incident response plan against set metrics as well as progress on maturity as per the defined roadmap.

Final thoughts

An incident response plan is only as good as the commitment from all stakeholders to turn it into reality. Without a plan, the chances of successfully dealing with a major IT outage are slim to none, and this introduces more risks especially with the costs of dealing with such outages becoming more expensive.

Any service delivery unit that wants to delight its customers and deliver value to its shareholders must commit to investing in a comprehensive incident response plan that captures what is required to effectively respond to different incident scenarios, inform key stakeholders about its contents and their responsibilities, and finally keep it regularly updated using lessons from previous experiences, as well as new insights from analysis of their operational context.