Introduction
This guide will assist in-house counsel, private practice lawyers, and IT departments to ensure that they have a plan in place to respond to a data breach incident. This guide will also assist in the identification of reportable data breaches.
This guide covers:
- Preparation: incident response readiness
- Response: identification of a reportable data breach
This guide may be used in conjunction with How-to guides: How to develop, implement and maintain a US information and data security compliance program; and Checklist: Completing a data incident response plan assessment.
Section 1 – Preparation: incident response readiness
A data breach happens without warning, and there is no way of predicting when or if an organization will find that its data has been compromised. Any organization that stores or uses data is potentially vulnerable to a data breach, and should have a response plan in place before a breach happens.
To illustrate the depth and breadth of security breaches, below is a sample of the list of significant breaches that occurred in 2024:
• National Public Data – affected 2.9 billion records;
• Ticketmaster – affected 560 million users;
• Ascension – affecting 5.6 million people; and
• Dell – affecting 49 million customer records.
Clearly, any organization could be the victim of a data breach and should be prepared to respond. Incident response is largely about planning and preparedness. If a data breach occurs, there are often practical and legal ramifications if a company’s response is regarded as too slow. For example, New Hampshire law provides that the state’s breach notification law, including the timing requirements for the notice, may be enforced by the state attorney general by injunction against the continuation of the practice, and the attorney general may also seek a civil penalty of up to $10,000 per violation. The attorney general may also seek to have a receiver appointed to take charge of the business while the litigation is pending. As a practical matter, a slow response to a data breach may mean that greater harm is incurred as a result of failing to contain the breach, with the consequent impact on the business. Developing an internal data incident response plan, and making sure that the plan is followed in the event of a data security incident is, therefore, essential. A great starting point for any business faced with a data breach should be the Data Breach Response: A Guide for Business which is provided by the Federal Trade Commission.
1.1 Identification of key staffing positions
The first step in developing a plan for responding to a data incident is identifying key staffing positions.
1.1.1 Staff member with overall responsibility
The plan must identify who is responsible for the organization’s response to a breach. A thorough response to a breach might involve multiple departments and many people. In order to eliminate confusion surrounding chain-of-command issues, it is best practice that those departments work in concert under a single supervisor, identified in advance. Having one person in charge will also allow for a more rapid response than would likely be the case if the response were to be delegated to a committee. Therefore, identify who will be responsible for decision-making in the event of a breach (ie, data security officer, company official, etc). This person will be responsible for gauging the extent of the breach, the type of data that may have been compromised, and the specific actions that need to be taken. This person should ideally have expertise and experience in both data security and breach or crisis response.
The plan must ensure that the person responsible for the organization’s response to a breach has the authority to implement the operations of the plan, and must also ensure that staff are aware of that authority. The plan should also detail reporting requirements by staff members, and procedures for escalating a response. Where a single position has been created to be responsible for for data protection and response it is referred to as a ‘Data Protection Officer’ (DPO).
Although a data protection officer (DPO) is not generally required under most federal or state laws, HIPAA does require covered data collectors to appoint a specific individual to the dedicated position of DPO. Therefore, organizations whose operations implicate HIPAA should consider the inclusion of the name and information of the appointed DPO. See 45 CFR 164.530. Additionally, for multinational organizations, appointing a DPO is sometimes mandatory for both controllers and processors under the GDPR. Further, the GDPR sets strict requirements for the competence, tasks and independence of the role.
In terms of state and other law developments, Massachusetts (and other states) and some federal regulations, including the recently updated FTC Safeguards Rule (applicable to non-banking financial institutions), require organizations to appoint one or more employees to maintain their information security program. Consequently, it appears that having a DPO may become more commonly required in the US.
So, while there should be only one person with overall responsibility for implementing a data breach response plan, the plan for responding to data breaches should be developed with input from all stakeholders, including staff from technical, IT, legal, compliance, and risk management. Media or public relations personnel, as well as investor relations personnel, should be briefed to prepare for the possible need to make broader public announcements. A wide range of input will help make the plan understandable and readily usable, and will also help to ensure that all of the necessary facets – technical, legal, and best practices – are covered.
1.1.2 Legal counsel and compliance personnel
Legal counsel and compliance personnel must keep up to date with all of the changes in data security law, including relevant court decisions, to ensure that the response plan allows your organization to meet its breach notification obligations, and that it is designed to protect the organization from potential civil liability from private lawsuits.
1.1.3 Data security experts
In the event of a data breach, expertise matters. Company management should ensure that in-house data security experts with the requisite skills to respond to a breach (eg, skills in security information and event management, auditing, and intrusion detection) are on hand, or that experts are on call and readily available. It is best practice to ensure that data security officers are properly educated and trained to respond to the latest physical and digital threats.
1.2 Development of the various elements of a data breach response plan
A data incident response plan should incorporate five essential elements of a response to an incident:
- identification, both of the breach and of the data potentially compromised;
- investigation and analysis;
- containment of the breach;
- remediation; and
- evaluation – lessons learned.
Each of these is dealt with in turn below.
1.2.1 Identification
Identification of the breach
Identification involves identification of the breach itself. A data breach may occur in a number of ways, including through loss or theft of equipment; vulnerabilities in security; improper usage; or malicious attacks executed through the web, emails, or impersonation.
Theft- or breach-detection software may alert an organization to a breach, or technical staff members may notice suspicious activity that could indicate a breach is taking place, or has taken place. Alternatively, the breach may come to light through other means, such as a complaint from a customer or other data subject. In preparing an incident response plan, consider the various means by which an incident may become known. Then address in the plan the reporting mechanism for each type of potential breach and how these should be escalated appropriately internally. This will enable any breach to be identified, scoped, contained and remediated.
An incident response plan should contain processes for documenting facts about the incident as they become known. This may be in the form of a logbook or other tracking system that can record matters such as the status of the incident, actions taken, contact information for any relevant persons (eg, system administrators) and any evidence gathered as part of the process of identifying the breach.
A well-developed incident response plan should anticipate the possibility of breach caused by malicious actors, through means such as ransomware attacks, and put in place processes and protocols that anticipate such attacks. Relevant protocols might include communications protocols if access to usual communications channels is restricted, a protocol for external media communications, and a protocol for responding to demands for ransoms (including the criteria for determining if such a ransom should be paid).
Identification of the data involved
The measures that your organization needs to be ready to respond to a data breach incident will often depend on the nature of the data that either is at risk of being compromised or which has potentially been compromised. Therefore, your incident response plan should include steps to identify that data and whether it is:
- Personally identifiable information (PII) – under US law, PII is any data that can be used to identify a specific individual, such as their name, Social Security number, date of birth, driver’s license number, passport number, financial account numbers, biometric data, and other sensitive information. PII also can include less sensitive information, such as an email address or home address, if it is combined with other data that can identify an individual, exposing that individual to the risk of identity theft and other crimes. The requirements for making notifications of breaches concerning ordinary PII (ie, PII that is not protected health information) vary by state. The requirements and procedures may also vary depending on the quality and type of PII involved in a breach.
- Protected health information (PHI) – the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (see further 2.1.2) regulates the use and disclosure of individuals’ PHI by healthcare providers, health plans, and healthcare clearinghouses, as well as by associated businesses. PHI includes any information that can be used to identify an individual and relates to their physical or mental health, healthcare services they have received or will receive, or payment for healthcare services. The HIPAA privacy and security rules set out specific procedures to be followed in the event that a breach involves PHI (see section 2.1.2). These procedures are particular to PHI, and are not interchangeable with the procedures for notification of a breach involving PII that is not health information.
- Nonpublic personal information (NPI) – the Gramm-Leach-Bliley Act of 1999 (GLBA) requires financial institutions to notify customers if their NPI is compromised or at risk of being compromised by a breach. NPI is defined as any ‘personally identifiable financial information’ that a financial institution collects about an individual in connection with providing a financial product or service, unless that information is otherwise ‘publicly available.’ The regulation applies only to the NPI of individuals who do business with the financial institution for personal or household purchases (eg, a home mortgage, or a personal credit card). Regulations developed under the GLBA require that notification of a breach must be made as quickly as possible to all affected customers, based on the institution’s assessment of the nature and scope of the breach. Notice must also be provided to the appropriate regulatory authorities with jurisdiction over the financial institution.
See further, How-to guide: How to determine and apply relevant US privacy laws to your organization.
1.2.2 Investigation and analysis
When a breach has been identified, an investigation should be conducted to determine the extent of the damage. Unless there is reason to believe that the effect of the breach will be small (eg, your organization retains data on only a few individuals), it is wise to plan to hire an independent forensic investigator. Such an investigator can help you determine the source and scope of the breach. The investigator will capture forensic images of affected systems, collect and analyze evidence, and outline remediation steps. If it is unclear whether certain data has been compromised, it is best to err on the side of caution and assume the data has been compromised.
In addition to setting out a plan for the resources that might be employed in the event of an incident, an incident response plan should establish factors that will determine how multiple incidents will be prioritized. These factors might include the impact on business functionality, the nature of the information that was compromised (ie, PII, PHI, etc), and the time and resources needed for recovery.
Analysis is an essential part of any response plan. Analysis considers the results of the investigation. An incident response plan should set out the processes by which the incident response team will analyze an incident. The processes that should be followed will depend on the nature of the incident but the plan should allow the team to determine issues such as:
- the affected part of the system or network;
- the source of the incident (whether internal or external actors were involved);
- the cause of the incident; and
- the amount of data that was compromised.
The analysis is essential for remediation, and integrating it into the plan will help to ensure that the measures taken in response are appropriate and adequate. Analysis will help determine what remedial steps need to be taken.
1.2.3 Containment
The containment measures that will need to be taken will vary depending on the nature of the incident and therefore it is important that the breach has been identified, investigated, and analyzed so that appropriate measures can be taken. Once a breach has been identified and sufficiently investigated to allow for effective containment, immediate action should be taken to limit the spread of the breach.
An incident response plan should anticipate the types of containment measures that will be deployed in the event of different types of security incident. This should anticipate the time and resources needed to implement the measures, the effectiveness of the measures and how long they will be in place for (ie, whether they are temporary measures or permanent solutions).
The person designated as being in charge of the organization’s response to the breach should be designated as the ones responsible for taking containment measures, or ensuring that containment measures are taken. Taking action as soon as practicable will help limit both the internal damage (ie, loss of more data) and external damage (ie, negative public opinion, and legal or regulatory liabilities). Containment may include ending or limiting access to a system, or isolating infected email accounts. The precise measures to be taken for containment will depend on the nature and amount of the data stored by the organization, and the size of the organization.
The steps taken to contain damage should also be documented thoroughly, in real time. This will allow a comprehensive after-the-fact review of the actions taken and where there might be room for improvement. The documentation will also show the adequacy of the response in the event of a lawsuit or government investigation.
1.2.4 Remediation
Remediation involves the recovery from the breach (ie, the process of restoring systems to their normal functions) and ensuring that adequate long-term security measures appropriate to the organization are in place (not just the temporary stopgap measures that may have been put in place to contain the breach), to prevent recurrence.
The nature of recovery will depend on the nature of the breach but recovery measures may include, for example, changing passwords, restricting access to systems, using clean backups to restore files and systems, implementing new systems, and installing patches or other similar measures to reduce vulnerabilities. While it may be difficult to anticipate precisely what will be needed, an incident readiness plan should try to anticipate in general terms the types of remediation that may be required in the event of different types of security incident. The incident plan should consider the timescales for implementing remediation measures, focusing initially on those which are quickest to put in place and which offer the greatest additional protection before looking at those which take longer to implement but which offer protection in the longer term. Remediation measures may take the form of:
- Physical security measures – such as securing access to server rooms, using locks and access cards, installing security cameras, restricting employee access to sensitive areas, and regularly monitoring the premises.
- Digital security measures – such as implementing strong passwords and multi-factor authentication, regularly updating software and security systems, and encrypting data (both in transit and at rest). Access to data by employees or contractors should be limited to the minimum amount of access needed based on the employee or contractor’s role and responsibility within the company. It is also important to have a robust data backup and recovery system in place, and to train employees on data security best practices.
For more information on security measures, see How-to guide: How to manage your organization’s data privacy and security risks.
Remediation also involves giving notice of the breach as required by the applicable federal or state law. See further section 2. The method of giving notice will vary, both according to different jurisdictional requirements but also according to the type of data involved in the breach. Remediation may also include remedial measures (eg, reimbursement for fraudulent charges) for customers whose data may have been compromised.
1.2.5 Evaluation – lessons learned
Evaluation is a step that should be included in a plan to address the potential for future breaches. The results of the investigation and the analysis, as well as a review of the steps taken for remediation, should be evaluated and discussed by all stakeholders. The efficiency of the team’s response, and the effectiveness of that response should also be examined. The point is not to affix blame for the breach, but to look for ways to improve the response for any future breach.
The data incident response plan should set out a timeframe within which a post-incident evaluation should take place, along with matters to be considered, which might include questions such as:
- How effectively was the incident dealt with?
- Was the data incident response plan followed and was it adequate? If not, how could it be improved upon?
- What worked well?
- What could have been better?
- What steps should be taken to improve processes for the future?
- What, if any, additional resources are needed in the event of future incidents?
If possible, it may be helpful to assign key performance indicators when considering incident responses, for example, identifying the time taken to discover or respond to the incident, the completeness of logs or adherence to established processes and procedures.
Section 2 – Response: identification of a reportable data breach
Remediation is a key part of an incident response plan and in addition to recovery of systems and networks involves giving notice of the breach as required by the applicable federal or state law (see further below). The method of giving notice will vary, both according to different jurisdictional requirements but also according to the type of data involved in the breach. The type of response to be taken to a breach is usually set by statute. Federal laws govern healthcare and financial information, while state or territorial laws will have more general application.
2.1 Federal laws
At present, there is no generally applicable federal law relating to breaches of data security. There are two laws – the Health Insurance Portability and Accountability Act, and the Gramm-Leach-Bliley Act, that set out requirements for notification of data breaches in specific contexts.
2.1.1 Gramm-Leach-Bliley Act of 1999 (GLBA)
The Gramm-Leach-Bliley Act (GLBA), PL 106-102, also known as the Financial Services Modernization Act of 1999, requires financial institutions to protect the privacy of their customers’ personal information. The GLBA applies to banks, securities firms, and insurance companies.
The GLBA requires financial institutions to notify customers if their nonpublic personal information (NPI) is compromised or at risk of being compromised as a result of a breach. The notification must be made as quickly as possible, based on the institution’s assessment of the nature and scope of the breach, to all affected customers. Notification must also be made to the regulatory authorities that govern the operations of the particular institution. See 12 CFR Chapter X, Part 1016.
2.1.2 Health Insurance Portability and Accountability Act (HIPAA)
The Health Insurance Portability and Accountability Act (HIPAA), PL 104-191, was enacted in 1996 and includes provisions to protect the privacy and security of patients’ health information. The HIPAA applies to covered entities, defined to include healthcare providers, health plans, and healthcare clearinghouses, as well as their business associates who handle patient health information.
Under HIPAA regulations, companies with fewer than 500 employees are required to report data breaches to affected individuals, the US Secretary of Health and Human Services, and in some cases, the media. The breach must be reported as soon as possible, or within 60 days of discovery, and must include a description of the breach, the type of data that was compromised, and steps taken to mitigate the breach. Failure to report a breach can result in fines and other penalties.
Companies with 500 or more employees are required to report a data breach to the Secretary of the Department of Health and Human Services (HHS) and to the affected individuals without unreasonable delay, no later than 60 days after discovery of the breach. The notification must be made by first-class mail or, if the person agrees in advance, by email, and must include a description of the breach, the types of information that were involved in the breach, the steps individuals should take to protect themselves, and a brief description of what the covered entity is doing to investigate the breach, mitigate harm to individuals, and prevent further breaches. If the breach involves more than 500 individuals, the covered entity must also notify prominent media outlets serving the state or jurisdiction where those individuals reside. Failure to comply with these reporting requirements can result in substantial penalties and fines. See 45 CFR section 164.400-414.
2.2 State laws
State laws generally deal with the protection of PII, and standards for protection and notification vary between jurisdictions. It is best practice to familiarize yourself with the data protection and reporting standards of any state in which you do business.
There is no uniform act on data security or data breaches. Jurisdictions differ, sometimes considerably, on the types of breaches that need to be reported or recorded. State laws generally protect only the data of residents of that state or of businesses that do business there.
2.2.1 Reporting standard
Standards on reporting data breaches vary between states. Some states require reporting of data breaches only when those breaches involve a certain number of data subjects, and some states require reporting only when the breached data is likely to cause serious or ‘substantial harm’ to the data subject.
Not every US state has adopted a substantial harm standard for reporting breaches of PII. In fact, the wording of this standard varies: substantial harm, substantial economic loss, or substantial risk of identity theft are sometimes used. In such states, a data breach need only be reported if there is a reasonable possibility of such a risk. (See, for example, Alabama law, codified at Ala Code section 8-38-5). Note, also, that under Alabama law that if a breach involves more than 1,000 individuals, the company is required also to notify the state attorney general. Other states have similar rules.
Many states require merely that the data breach causes a generalized harm, rather than a substantial harm, before reporting is required. Arkansas, for example, does not require a breach notification if, under a reasonableness standard, the data subject is unlikely to suffer any harm. See Ark Code 4-110-105.
Given the differences between states, it is important to understand the reporting standards in the states in which notifications may be required.
2.2.2 Requirement to investigate by data controller/processer
Many jurisdictions allow data controllers to make assessments of the need to report a breach based on the volume and severity of a given data breach, and on an assessment of whether the breach is likely (based on a reasonableness standard) to lead to any substantial or generalized loss. It is best practice for companies to familiarize themselves with the standards of all the jurisdictions in which they do business.
2.2.3 Process of reporting
Every jurisdiction requires the reporting of serious data breaches, either to state officials or to the data subjects themselves, or both, when certain thresholds are met. Some states require that significant breaches also be reported to consumer reporting agencies. It is best practice to be familiar with the statutes of the state in which your organization does business.
State statues often allow organizations to notify state authorities of a breach and then later to provide additional information as it becomes timely. State statutes may also require notification to law enforcement authorities.
Many US jurisdictions allow companies to delay notifying data subjects of a breach if law enforcement officials feel that reporting in a timely manner would jeopardize an investigation. Likewise, some jurisdictions have a safe harbor provision in their laws that allows companies to escape notification if the breached data is fully encrypted.
For further information on state reporting requirements, see Q&A: US Data Protection and Privacy (state-by-state).
2.3 Foreign laws
An organization that collects or stores data relating to foreign nationals or residents should be aware of the legal requirements regarding data security and breach notification in the other nations concerned. For example, an organization that does business with residents of the European Union must be aware of the security and breach reporting requirements of the General Data Protection Regulation (GDPR).
Additional resources
Cybersecurity & Infrastructure Security Agency Cybersecurity Advisory - Technical Approaches to Uncovering and Remediating Malicious Activity
Cybersecurity Incident Response Plans, US Department of Health and Human Services, October 12, 2023 – this contains valuable information on cybersecurity incident response plans, including preparation and planning, training and testing, and detection and analysis procedures.
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
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
Completing a data incident response plan assessment
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.