Checklist: Completing a data incident response plan assessment (USA)

Introduction

Introduction

This checklist will assist in-house counsel and private practitioners who are fully or partially responsible for overseeing their organization’s assessment of its data incident response plan. A data incident response assessment is typically required when there is a suspected or confirmed cybersecurity incident, such as a malicious attack or a data breach.

The checklist addresses the following steps:

1. Understand what the data incident response plan should address
2. Review any current data incident response plan
3. Test data incident response plan
4. Assess and modify data incident response plan

The checklist is presented as a list of requirements that you can check off as they are addressed. At the end of the document, there are explanatory notes corresponding with each requirement in the checklist. 

The checklist can be used in conjunction with other relevant references and resources, including How-to guide: How to manage third party supply chain data privacy, security risks, and liability and Checklists: Completing a data and information security risk assessment and Drafting internal privacy policy, practices, and procedures.

Step 1 – Understand what the data incident response plan should address

Step 2 – Review any current data incident response plan

Step 3 – Test data incident response plan

Step 4 – Assess and modify data incident response plan

General notes

Scope and use of checklist

US privacy law in its current state is a medley of laws and regulations, so not every privacy regulation will apply to every business. Moreover, because every organization handles data differently, each will have different privacy and data security risks based on their operations and specific organizational structure. Therefore, take care to determine whether specific data security issues are applicable by considering the business’s industry, product offerings, jurisdiction, or other factors.

For further detail see Checklists: Completing a data privacy risk assessment and Completing a data and information security risk assessment.

Additionally, note that this checklist only covers codified privacy laws. Also consider the risk of common law privacy-related claims when assessing a data incident response plan.

Legal framework

The current US privacy law environment comprises a patchwork of privacy and information security laws. Since much of the emphasis on privacy in the United States is on electronic privacy, both privacy and information security laws are relevant to privacy compliance by organizations in the United States.

At the federal level, these laws are generally implemented through federal agency regulations and oversight. Multiple agencies are often responsible for making rules to implement a federal act.

At the state level, California has been the most aggressive in developing privacy and information security laws, with other states beginning to follow suit. Given the size of California’s economy and market, many organizations ensure compliance with California’s privacy laws.

For further detail see How-to guide: How to determine and apply relevant US privacy laws to your organization and Checklist: Understanding privacy laws in the US.

What is a data incident response plan?

A data incident response plan outlines a process or set of processes that help an organization identify, manage, and respond to a cybersecurity incident. Such incidents include hacker attacks, data breaches, and any other incident that results in the unauthorized release of, or access to, personal information. Goals of a data incident response plan include the following:

• identifying when a cybersecurity incident has occurred;
• responding to the incident in order to restore services, protect and safeguard personal data, including customer data;
• preventing future incidents; and
• ensuring compliance with applicable regulatory and legal requirements.

Importance of assessing a data incident response plan

Data incident response plans are crucial for identifying and remedying potential or actual security incidents, including malicious attacks. Failure to mount an adequate response to these attacks or to other data breaches will lead to negative outcomes, including civil and criminal penalties imposed by government regulators, civil liability to private litigants for private causes of action, and an unfavorable reputation or poor public image. A regular assessment of data incident response plans helps to ensure that responses to attacks or other data breaches are adequate. 

Key considerations

Due to the speed with which privacy laws and regulations are being adopted or updated, privacy compliance in the United States requires regularly checking for legal updates. Reviewing and updating privacy risk assessments is essential to ensure compliance and avoid penalties or legal liability.

It is also essential that the entire organization understands the importance of data security, and that each team member with a role in responding to an incident has a full understanding of what they are supposed to do.

Step 1 – Understand what the data incident response plan should address

1.1 Identify potential threats

A data incident response plan should identify different types of threats to personal data and when such threats may occur or are occurring. Below are some examples of cybersecurity threats:

• unauthorized attempts to access data or systems on which the data is stored;
• unauthorized purposeful or accidental release of data;
• privilege escalation attacks, in which an attacker that has gained unauthorized access attempts to obtain higher-level privileges;
• attacks due to organizational insiders, such as employees, ex-employees, and independent contractors;
• phishing attacks, in which the attacker pretends to be a reputable individual or channel of communication;
• malicious software (or malware) attacks;
• denial-of-service (DoS) attacks that shut down an entire computer or network;
• man-in-the-middle (MitM) attacks in which an attacker intercepts communications or messages between two parties; and
• attacks aimed at obtaining user passwords.

1.2 Identify vulnerabilities

The data incident response plan should categorize the organization’s computer software and hardware to determine which systems are the most vulnerable, and which attacks pose the greatest threat. For instance, removable or external media, such as USB drives or external hard drives, are especially vulnerable to malware attacks, while scripting attacks, that is, attacks to steal passwords or credentials, are common on websites or other public-facing applications. The plan should also determine the types of authorization used for different computer systems to accurately identify the chance that such authorization may be spoofed or circumvented.

1.3 Identify past data security incidents

Identifying past data security incidents may reveal patterns of attacks or data breaches that enable the organization to better prepare and plan for future potential incidents. List past incidents and categorize by type, for example, a malware attack or an incident of unauthorized access. The organization can then use machine learning solutions and predictive analytics to determine the probability of different types of attacks. The organization is then able to set up defenses against such attacks.

1.4 Identify legal requirements for data incident response plan

The data incident response plan must also satisfy applicable laws and regulations governing the organization and its data. For instance, all 50 states have laws requiring organizations to notify individuals if there is a security breach of personally identifiable information. This is typically defined as an individual’s first name or first initial and last name together with a Social Security number, driver’s license number, bank account number, or credit or debit card number, and in combination with any required security code, access code, or password. Other laws require organizations to take necessary steps to remedy the breach. Thus, the legal requirements provide a minimum basis that the data incident response plan must satisfy.

Step 2 – Review any current data incident response plan

It is important to understand in advance what the organization’s current response plan looks like. This allows an evaluation of how effective the plan is, and whether it adequately addresses the needs of the organization.

2.1 Review key components of organization’s current data incident response plan

Review any current data incident response plan to ensure it contains the following six steps, as well as detailed and clear procedures under each of those steps:

• incident prevention or preparation;
• incident identification or detection;
• incident containment;
• eradication;
• recovery; and
• post-incident review.

2.1.1 Incident prevention or preparation

To prepare for, and prevent, data incidents from occurring, the data incident response plan must properly identify the different types of organizational assets that are vulnerable to breaches or attack. List these assets, together with their physical or virtual locations, and assign priorities based on their importance and risk.

Additional incident prevention and preparation measures include the following:

• proper training of employees to both prevent and respond to data incidents;
• developing test or drill scenarios to conduct mock data breaches or attacks; and
• ensuring all aspects of the data incident prevention response have been evaluated and approved by the necessary teams or management officials.

2.1.2 Incident identification or detection

Incident identification or detection is the process of determining that a data incident has occurred. The data incident response plan should provide a list of potential scenarios in which a data breach could occur. The plan should also set out procedures that the response team can use to answer the following questions:

• How was the incident discovered?
• Who discovered the incident?
• When did the data incident occur?
• What was the point of entry of the attack or source of the incident?
• What computer systems or websites does the incident affect?
• What is the scope of the incident?
• What data was affected?
• Does the incident affect organizational operations and, if so, which ones?

2.1.3 Incident containment

This step sets out procedures for containing the data breach, malicious attack, or other type of cybersecurity incident. The goal of containment is to prevent the spread of the breach or attack to other computer systems or other organizational areas while preserving a data trail and evidence for future review.

Possible containment tactics include as follows:

• disconnecting computer systems and devices from the internet;
• activating backup systems and devices;
• ensuring that all systems are updated and have current security patches; and
• modifying all user authentication credentials (eg, passwords).

2.1.4 Eradication

You must find and eliminate the root cause of the data incident. Securely remove any malware or other software that has infected data systems. Fix any additional security holes, and review all computer systems again to ensure up-to-date security patches.

2.1.5 Recovery

The recovery step involves restoring and returning affected systems or devices back to proper working order. Return computer systems to active use as quickly as possible without compromising security or risking another data incident. In some situations, systems may be restored using previous backups.

Use additional tools such as file integrity monitoring and intrusion detection to ensure that an attack or other data incident does not occur during the recovery process.

2.1.6 Post-incident review

After restoring the computer systems and after completing an investigation into the data incident, the organization and, in particular, the data incident response team, must review the incident and assess the lessons that can be learned. Specifically, the organization should consider the following in making an assessment:

• the areas of the data incident response plan that worked and the areas that did not;
• potential improvements in employee training for data incidents; and
• the vulnerabilities that the data incident exploited and how to fix those vulnerabilities.

2.2 Review plan’s notification requirements

The data incident response plan’s notification requirements cover how, and to whom, the organization will provide notification in the event of a suspected or actual data incident. The plan should either include the wording to use for notification letters, or procedures for drafting such notification letters. The plan should also stipulate how to provide notification, for example, by physical letter, email, or other method. As a general rule, provide notification to your customers, other individuals whose data may have been compromised, and certain legal authorities:

• state attorneys general;
• state organizations; and
• federal entities such as the Federal Trade Commission (FTC) or Department of Health and Human Services (HHS).

2.3 Review plan’s communication requirements

The data incident response plan should set out guidelines about communicating to both internal and external parties about the data incident. Different communication guidelines may exist for internal communications and for public communications. In the design and implementation of communication guidelines, clearly specify each group or department’s responsibilities.

Communication guidelines should:

• establish the purpose of the communication;
• determine the audience;
• define specific roles and responsibilities;
• standardize messaging given the specific audience;
• establish communication channels; and
• distribute the message using those channels.

2.4 Review plan’s documentation requirements

Review the data incident response plan’s documentation requirements to ensure that all necessary documentation regarding the data incident, including how and when it occurred, is preserved for future review and investigation. The plan must recognize which laws and regulations govern the retention of specific types of information. The plan must ensure that all the required data is retained.

Moreover, effective documentation allows the organization to better identify the causes and reasons for the data incident. You can use data relating to the incident for future data monitoring and incident prevention.

2.5 Evaluate data incident response team

The data incident response team is the internal team responsible for identifying, and responding to, all data incidents. The team is also responsible for internal and external communications regarding the incident.

2.5.1 Team qualifications

Review membership of the data incident response team to ensure that it includes all the relevant stakeholders from different departments. Generally, the data incident response team includes the following:

• privacy officials, such as the privacy officer;
• data security officials;
• marketing or operations managers;
• communications or public relations personnel;
• data systems engineers; and
• legal officers such as the general counsel.

2.5.2 Communication policies for team

The data incident response plan should include communication policies for the data incident response team. These policies include communication guidelines for:

• communicating within the team;
• communicating to internal groups or departments;
• communicating to external individuals or organizations; and
• maintaining legal privilege.

Having these communication policies should ensure that a standardized message emerges from the incident response team.

2.5.3 Team awareness of data incident response plan

Train each member of the incident response team so they understand the data incident response plan. Additionally, each member must have a specific set of quantifiable goals and objectives under that response plan. The response plan must provide for team members to meet regularly during the investigation of a data incident.

2.5.4 Team understanding of legal obligations

Each member of the data incident response team should understand the organization’s legal obligations and requirements as set out by the data incident response plan. The data incident response team must be aware of the information to be provided to those affected by a breach, and the deadlines for providing that information. The response team must also be aware of the types of documentation they need to preserve and provide to state or federal officials.

Step 3 – Test data incident response plan

Test data incident response plans regularly to determine which portions of the response plan are likely to work, and which require further improvement or refinement.

The different test types are as follows:

• paper tests, which are mostly theoretical and ask what kinds of incidents could occur and how the organization would respond;
• tabletop exercises, where the data incident response team informally discusses simulated scenarios for data incidents; and
• simulated incidents, in which the data incident response team assumes a specific type of attack and responds according to the data incident response plan.

3.1 Discuss possible scenarios

To test the data incident response plan, the response team should discuss possible scenarios that may result in a data incident, especially those potential threats identified at the outset of the assessment (see section 1.1). These scenarios should focus on likely types of incidents or attacks that could affect organizational assets. Multiple scenarios may need to be tested depending on the organization’s infrastructure and computer systems.

3.2 Simulate an incident

Incidents can be simulated in a variety of ways. The incident response team could walk through the entire response plan for a certain type of incident. The team could also activate specific aspects of the plan, such as turning on backup systems, to determine their effectiveness.

3.3 Perform a parallel test

In a parallel test, trial backup systems are tested to ensure they can perform in real-world conditions during an incident. While the backup systems are tested, the primary computer systems carry the entire workload.

3.4 Review results of data incident response test

After the test, the data incident response team should gather to review the test results. The team should focus on which aspects of the plan worked and which require further updating. The team should ask whether different parts of the plan functioned as intended and within the required time frame. Finally, the team should establish which aspects of the plan require further refinement and then run another test at a future date.

Step 4 – Assess and modify data incident response plan

4.1 Consider findings from plan review and testing

To assess the adequacy of a data incident response plan, the first step is to consider the lessons learned from the organizational review of the plan and any simulations or tests. This may then indicate that additional or different security measures are required for specific computer systems.

4.1.1 Identify gaps between risk and findings

For each computer system or asset, the incident response team should identify the gap between the risk to that system (see section 1.1) and the findings of the plan review or test (see section 3.4). If the plan review or test indicates that a given system is inadequately protected, the incident response team should determine whether, and how, to provide greater protection, based on the potential risk to that system. Generally, the greater the risk, the more the response team should prioritize updating protection against a future data incident.

4.1.2 Identify gaps between legal obligations and findings

For each computer system or asset, the incident response team should also identify any gaps between the organization’s legal obligations and the findings of the plan review or test. The team must be aware of these legal obligations, including the following:

• the data the organization needs to protect;
• the individuals or agencies the organization must notify in the event of a data incident; and
• the documentation that must be kept in the event of a data incident.

The plan must ensure that all the organization’s legal obligations are met. If there is any gap between these obligations and the findings of the plan review or test, the incident response team must develop a timeline to fix the data incident response plan. Afterwards, the team should schedule another test or plan review to check whether the updated plan meets the organization’s legal obligations.

4.1.3 Identify other issues that come to light

The data incident response team should identify any other issues that come to light during a plan review or test. Examples of such issues include:

• problems related to identifying the data incident;
• problems relating to notification or communication of the incident;
• lack of required tools to identify or respond to the incident; and
• lack of sufficient collaboration between data incident response team members or among other departments within the organization.

4.2 Obtain input from data incident response team

The data incident response team should provide input on the strengths and weaknesses of the data incident response plan with respect to specific areas of organizational importance that are exposed to data incident risk. The input should be placed in a checklist and presented to the relevant decision makers, such as operational managers or executives, so that the data incident response team’s findings and suggestions may be used to bolster areas of vulnerability.

4.3 Identify improvements to data incident response plan

The data incident response team is also responsible for identifying specific methods for improving the data incident response plan. Potential improvements could include:

• providing additional or different employee training on data incidents;
• modifying roles and responsibilities in response to data incidents;
• upgrading computer systems or monitoring systems; and
• improving incident response tracking or forensic analysis of incidents.

4.4 Implement improvements to data incident response plan

The data incident response team should provide a schedule for implementing improvements to the data incident response plan. The schedule must include measurable objectives for each improvement step. After all of the improvements have been implemented, the response team should meet and conduct a further review or test to determine the adequacy of the improvements.

Additional resources

Related Lexology Pro content

How-to guides:

How to determine and apply relevant US privacy laws to your organization 
How to manage your organization’s data privacy and security risks 
How to implement privacy by design within your organization 
How to develop, implement, and maintain a US privacy law compliance program 
How to develop, implement and maintain a US information and data security compliance program 
How to evaluate the effectiveness of a data security or data privacy compliance program 
How to develop a vulnerability disclosure program (VDP) for your organization to ensure cybersecurity 
How to draft a privacy policy, and privacy and data security provisions in contracts 
How to manage third party supply chain data privacy, security risks, and liability 
Incident response plan readiness and identification of a reportable data breach 
How to prepare for and respond to a governmental investigation or enforcement action for violation of US privacy laws 

Checklists:

Understanding privacy laws in the US 
Completing a data privacy risk assessment 
Drafting internal privacy policies and procedures 
Completing a data and information security risk assessment 
Drafting a consumer privacy policy 
Developing key privacy and data security contractual terms and provisions (B2C) 
Privacy and data security law training 
Responding to a data breach 
Privacy and data security due diligence in M&A 

Quick views:

Key data privacy and data security terms 
Collection and use of non-consumer data 
Regulation of data brokers 

Reliance on information posted:

While we use reasonable endeavours to provide up to date and relevant materials, the materials posted on our site are not intended to amount to advice on which reliance should be placed. They may not reflect recent changes in the law and are not intended to constitute a definitive or complete statement of the law. You may use them to stay up to date with legal developments but you should not use them for transactions or legal advice and you should carry out your own research. We therefore disclaim all liability and responsibility arising from any reliance placed on such materials by any visitor to our site, or by anyone who may be informed of any of its contents.