It usually happens on a Friday afternoon. A call comes in. Your company has a data security incident. Data about consumers, employees, business customers or others may be exposed. Your company is looking for guidance. What needs to be done? Should we call law enforcement? What about the EU General Data Protection Regulation's requirement to notify in 72 hours? Should we warn consumers/employees/others? This article outlines some key do's and don'ts in such scenarios. Although there is no one-size-fits-all approach, there are some key principles to be considered.
Know the facts: To handle an incident properly, you need to know what is currently known about the facts. The understanding of the facts typically can develop and change rapidly during the course of an incident response. You must be prepared to adjust the approach to the incident as the facts develop. An incident can look significant at first and then end up posing little risk. Or, conversely, it can appear small at first and end up significant. (See the checklist of initial assessment questions at the sidebar for starting points.)
Identify the core incident response team: Ideally, the company has already adopted an incident response and breach notification policy and has tested it with "tabletop" exercises involving the key stakeholders. If you're not in the ideal spot, you'll want to consider who the key stakeholders are across the enterprise for this incident from relevant functional and business units. Legal, compliance, information security, communications, human resources, finance, marketing, sales, business units, and others may be relevant to the investigation. Identifying the right team will depend on the specifics of the situation (e.g., human resources may not be relevant if it’s a consumer mobile app issue but will be key if the incident affects employees as data subjects).
Consider outside resources: Again, ideally, the company would have already selected and engaged outside counsel, external forensics and security professionals, external public relations, identity theft protection, call centers, and other service providers. If you're not in the ideal situation, your first question should be external counsel and privilege, but the other critical (and immediate) question is external forensics. Internal security or other professionals may be highly skilled in their day jobs, but it is important to ask whether you should call on external resources here. Does the internal team have the latest forensic tools, techniques and resources to preserve evidence, assure containment as quickly as possible and use all available evidence to determine scope? How would the use of internal resources affect external perceptions of independence and credibility? For significant events, it is typically indispensable to engage qualified external forensics.
Preserve privilege to the extent reasonably possible: Legal disputes follow data security incidents. There are consumer class-actions, data protection authority and other regulatory investigations, business partner lawsuits, shareholder derivative actions and more.
Legal counsel helps to shape and direct the investigation to focus not only on the most legally significant elements in terms of the immediate investigation, but also in terms of what might follow the incident once it has been resolved and potentially disclosed. In certain cases, counsel's engagement of forensics and other providers can protect against future compelled disclosures of key communications, work product, and other documentation. And globally, there tends to be greater recognition of a privilege for external law firms than for in-house counsel.
Focus on what's in the best interest of the customers, employees or others potentially affected by the issue: It may seem counterintuitive for legal counsel or others who are accustomed to protecting the company, but it is critical for the company in a global incident response to focus on what's in the best interests of the customers, employees or other data subjects who are potentially affected by the incident. This will help guide the company to make the right — or more precisely, the least-bad decisions — at each step of the way based on the facts as they are then understood. Note that this does not automatically mean that notices should be fired off right away.
Don't adopt a "ready, fire, aim" approach to data security breach notification: The "quick-trigger" data security breach notification deadlines emerging in regulations around the world can be scary. You have 72 hours to notify data protection authorities in the EU after becoming aware of a personal data breach. Obligations to notify authorities in South Korea and Costa Rica are within five days. Turkey, in principle, needs immediate notification. While each incident is different, it is important for the company to slow down enough to at least know what it is talking about. Press forward with deliberate speed to deploy forensics and conduct the investigation, but consider that most regulatory requirements allow some room for a company to do some investigating before notifying.
Don't forget about contractual breach notification obligations: Apart from regulatory obligations, if credit or payment card information is at issue, payment card industry rules typically carry obligations to notify immediately/within 24 hours (e.g., so as to allow the credit card brands to heighten the monitoring of those transactions). Other contract-based obligations, particularly in the B2B environment, can be difficult to navigate due to the variety of specifics of what may have been negotiated over time and across a large volume of corporate customers.
Don't miss notification concerns beyond personal data: Companies may face a range of notification obligations, beyond personal data, that arise from global data security incidents. For example, public companies need to consider whether the event would be material to an investor decision and require further public filings. Medical device companies need to consider whether an incident affects the safety and effectiveness of the devices and requires notification to regulatory authorities. Companies engaged with defense- and military-related technologies may have duties to rapidly report to government agencies any incidents affecting their systems or covered information. Also, companies that plan to file claims under insurance policies will have obligations to report the incident to their carrier in a timely manner.
Don't ignore local restrictions that apply to how you perform your investigation: The company's data collection and transfer activities in the investigation may itself be a regulated activity. Data protection laws will regulate the collection and processing of evidence from or relating to individuals. Computer misuse and related requirements may restrict the analysis of employee email and other computer systems. Local rules on state secrets, professional confidentiality, bank secrecy and other provisions may restrict the disclosure of information to third parties, including parent companies. And, anti-investigatory or "blocking" statutes can establish criminal restrictions on performing any activity in the local territory that may assist a foreign government investigation or proceeding.
Don't forget to learn from each data security incident: Valuable insights can often be gained post-incident not only with respect to how to enhance security controls going forward (i.e., root cause analysis), but also on how to streamline the process.
See the checklist at right for more.
1. What is known about the nature of the incident (e.g., hacking, loss of device, phishing, ransomware or the like)?
2. Is there containment of the incident (e.g., network is now secure versus threat or exposure is ongoing)?
3. Are steps being taken to protect the security of the system(s) while avoiding destruction of critical electronic evidence (e.g., system(s) disconnected from the network and internet, but power kept on to preserve memory)?
4. What is known about the scope of the issue? In particular, key elements include:
- The systems or devices affected (e.g., internal company servers or networks, subcontractor or third party systems, patient or consumer devices or applications or the like).
- The categories of data subjects affected, such as consumers, employees, or others.
- The locations of data subjects, such as countries and states.
- The types of individual data at issue, such as individual information including name, contact details, credit card or payment information, national identifiers, health data, and the like.
- The types of company data at issue, such as trade secrets, sales and marketing plans, new product plans, customer and supplier information, financial data and other confidential information.
5. Does the company have appropriate resources aligned to address the dimensions of the data security incident (e.g., external counsel, specialized forensics, business continuity/back-up, public relations, call center/identity theft protection services, and the like)?
6. Have forensics or other third parties been engaged by counsel for purposes of protecting privilege to the extent reasonably possible and assisting counsel to advise the company on the situation?
7. Has a proper incident response team been established so that key personnel is participating in the incident response, but only on a need-to-know basis and only subject to a briefing on key concerns related to privilege and communications?
8. What external parties are aware of the incident (e.g., business partners, regulators, and media)?
9. Has the company already notified law enforcement or other parties about the data security incident (e.g., FBI, Secret Service, other law enforcement authorities; any payment card brands or merchant banks; or any data protection or other authorities)?
10. Is the company following its incident response and breach notification policy?
If you want to comment on this post, you need to login.