Tune in to Ropes & Gray's podcast series, The Data Day, brought to you by the firm’s data, privacy & cybersecurity practice. This series focuses on the day-to-day effects that data has on all of our lives as well as other exciting and interesting legal and regulatory developments in the world of data, and features a range of guests, including clients, regulators and colleagues. On this special episode, in honor of World Data Privacy Day coming up on January 28, hosts Fran Faircloth, a partner in Ropes & Gray's Washington, D.C. office, and Edward Machin, counsel in the London office, discuss the most important steps they advise clients to take to protect their business and their data from a cybersecurity attack.
Transcript:
Edward Machin: Welcome, and thank you for joining us on the latest installment of The Data Day from Ropes & Gray, a podcast series brought to you by the data, privacy & cybersecurity practice at Ropes. In this podcast, we’ll discuss exciting and interesting developments in the world of data. We feature attorneys at Ropes as well as clients, regulators, and other industry leaders in conversations about what’s new in the world of data. I’m Edward Machin, counsel in Ropes’s data, privacy & cybersecurity practice, and I’m based in our London office. I’m joined by my colleague and co-host Fran Faircloth, a partner in our Washington, D.C. office.
Fran Faircloth: Thanks, Edward. On this installment, we are doing something a little bit different. In honor of Data Privacy Day coming up on January 28, instead of having a guest, Edward and I are going to discuss a topic that clients ask us about almost daily: how to protect data and your company in the wake of a cyber incident.
We’ve seen a huge growth in the number of these attacks, and especially ransomware, in the past few years. This has been driven, in part, by a few different things. First, unregulated cryptocurrency exchanges that allow large international transfers that are exceptionally difficult to trace have driven this. But this growth has also been driven by ransomware-as-a-service, which decreases entry costs and allows fairly unsophisticated actors to use these ransomware service providers to carry out more sophisticated attacks. Finally, we can’t discount the role that nation states continue to play in these attacks, especially on critical infrastructure and supply chain attacks. So, we are seeing a ton of these come from different directions. What have you been seeing, Edward?
Edward Machin: A ton of them is right, Fran. As recently as last week, we heard from J.P. Morgan who received 45 billion hacking attempts per day. Successful attacks are costly—they average over $4m when you factor in the costs of lost business, incident response, notice, and recovery. And there really is a gap of knowledge for many folks who, all of a sudden, are faced with an incident and need to quickly take action, particularly where they haven’t experienced one of these events before.
Fran Faircloth: I completely agree. And really responding to an incident should start before an incident ever takes place. There are some important steps that companies can and should take right now to ensure that they are prepared.
- For one, it’s important for companies to have an updated incident response plan. If you fail to plan, you plan to fail, so you need this plan in place as well as other important policies, such as ones governing privacy and information security.
- But plans aren’t enough. Incident response plans are only as good as the team in charge of the response. So, it is critical that companies designate someone to coordinate the incident response and assign responsibilities for members of the incident response team. This team should involve any key stakeholders as well as a representative from legal—it’s really important to have counsel involved.
- And finally, one of the most important things a company can do, in addition to having a plan, is training employees on the plan and testing—practicing through things like tabletop exercises. We do these frequently for companies where we come into a client and walk them through a pretend but realistic scenario based on actual incidents we’ve seen and help them practice making these decisions in the heat of the moment when they only know bits and pieces of what might be happening to their systems. It’s all pretend, but it’s scary enough to help you practice in real time.
Edward Machin: Yes, absolutely—and unfortunately, regardless of how well you plan, your company may still undergo a cyber incident. Fran, when you do have an incident or you think you have an incident, what are the first things that you advise clients to do?
Fran Faircloth: Most importantly, stay calm and follow your incident response plan. I sound a little bit like a broken record here, but this is what the plan is for! But for the sake of our podcast today, let’s assume the worst-case scenario: an attack has happened, and a company doesn’t have a plan, or you don’t know where the plan is. Let’s lay out some crucial first steps.
Edward Machin: Taking it right back to the beginning, and as you mentioned before, the team that’s in charge is crucial. This is going to be a stressful environment and it can be hours, days and weeks, so you really do need to have the right folks in place. What do you need to do? You need to designate a coordinator (or coordinators) and incident response team (if you don’t already have one in place). This team and these individuals need to have clear lines of leadership and reporting and, in almost all cases, will involve top executives as well as internal and external legal counsel.
Fran Faircloth: Yes. It’s incredibly important to have counsel involved early, because many of the decisions that you make in the heat of an incident will have legal implications, and you don’t want the IT department or a business unit making those decisions without that important input from legal. Also, it’s key to include counsel to help preserve privilege. From the minute an attack happens, everything that your company is doing in response to that attack is in anticipation of litigation, because in the rare case that an attacker is caught—and it does happen—you will want to bring legal charges, so attorneys should be included on all communications. It’s good to bring in outside counsel who has handled many of these incidents because they can help shepherd you through all of the different pieces. And many of the decisions you’re making—again, as I said earlier, even though you’re making them in the heat of the moment—they will have implications down the road for things like regulatory investigations or class action litigation, so these decisions need to be carefully considered.
Edward Machin: Fran, one of the things our clients often ask us is, should they reach out to law enforcement or other regulators, either at the beginning of a cyber incident or thereafter? What’s your advice there?
Fran Faircloth: The first thing I always say is, “Not without talking to counsel first.” It’s really important to involve counsel in these decisions. Now, law enforcement, especially the FBI here in the U.S., can be extremely helpful in a cyber incident, and in addition, there may be obligations to report to other regulators—I think we’ll talk about that in a little bit here—but always, always, always consult counsel first. I’ve seen incidents where the IT department has reached out to law enforcement before consulting counsel, and law enforcement actually seized the computers for their own law enforcement investigation. This didn’t seem like an issue to the IT department because great that law enforcement is helping and investigating, but once legal was involved it really became an issue that they didn’t have access to the computers, because that meant that legal was not able to assess what statutory obligations there might be for notice, and arguably that statutory clock was ticking.
Edward Machin: That’s absolutely right—I agree, Fran. I think, by contrast, one of the stakeholders that is important to involve, often from the outside, are experts like forensic consultants to help with both the initial assessment and remediation. What are your thoughts and best practices for engaging those type of folks?
Fran Faircloth: I agree completely—those can be so helpful. An outside counsel can help you establish those relationships—where those experts are providing information to the attorneys to help them give legal advice in anticipation of litigation, that information should be covered by privilege. Outside counsel can help ensure that those agreements with outside experts like forensic consultants and communications experts are all put in place under privilege and that communications flows are structured to help protect that.
Edward Machin: Once the correct team is in place, which can be no little undertaking, you need to understand the type of attack and the initial extent of loss. Whilst the picture may change, and often does change, you need to at least have an understanding of what you’re dealing with at the outset. So, where did the attack originate? What systems have been affected? Has malware been deployed? And so on. Forensic investigators or even law enforcement can sometimes help you identify the attacker based on indicators of compromise, but as you said, Fran, whether and when you need to engage with law enforcement is obviously a consideration that needs to be assessed on a case-by-case basis.
Fran Faircloth: Absolutely, there are lots of pieces to assess here. Companies should also try—to the best of their ability—to evaluate what information may be available to them from any security system data, logs or audits, and, if possible, make a forensic image of the affected computers to preserve a record of the system. Here it’s really helpful if a company has good logging and data mapping in place before an incident happens, because that can help you see what data may have been accessed, but even without perfect logging, information can be reconstructed, especially with the help, again, of forensic experts. Companies will also want to assess whether, and the extent to which, any data has been compromised or encrypted. It’s very important here to remember that, while you want to work to contain the incident and protect your systems, you don’t want to do anything that compromises evidence of what happened. So, do not move or delete files and absolutely do not engage with the attacker—do not hack back.
Edward Machin: Yes, that’s such an important reminder. When it comes to containing the incident, there are some steps that you should take immediately. The most obvious one is to stop using the compromised or potentially compromised system(s), especially for communications about the incident—I know this is obvious, but it needs to be repeated. Companies should also consider whether any global or local password changes are needed, as well as modified access privileges for employees and third parties, or if there are other security enhanced measures that are necessary immediately.
Fran Faircloth: Yes, a global password reset and making sure things like multi-factor authentication are in place can help get the attacker out of the system and lock them out. It’s good to have a plan, as you said, Edward, for backup communications before the incident, whether that is some other secure communication channel that you can switch to after an incident, or even if it’s just moving over to phone calls for communication.
Edward Machin: Absolutely. There are also a number of immediate steps that companies and organizations should take to ensure they are staying ahead of possible regulatory obligations. So, can you run us through a couple of those, Fran—the preliminary actions companies should take to determine what their obligations are or may be?
Fran Faircloth: Sure. In that initial incident response assessment, companies should be thinking about these obligations. This means assessing whether data has been misused or whether it’s reasonably likely that data could be misused, what risks and harms could occur if data were misused (that will turn on things like what the data involved is and who we think we’re dealing with), and then, whether any federal, state or international laws or regulations apply, including data breach notification requirements. Data breach notification is a big one. Companies need to determine fairly quickly whether the incident needs to be reported to relevant law enforcement or regulatory bodies. That assessment can look different depending on what jurisdiction you’re dealing with. How does that assessment look in Europe and the UK, Edward?
Edward Machin: The good news is that it is slightly less complicated in that the standard under the GDPR, and the UK GDPR for the UK purposes, is broadly the same. It’s a risk of harm to individuals for reporting on notification to regulators and a high risk of harm to individuals for reporting to those individuals themselves. So, there’s a two-tiered system. And necessarily, if you don’t have to report to regulators, you’re not legally required to report to individuals—although some companies do, particularly in the employee context for full transparency and piece of mind. That said, different regulators have slightly different views on the reporting landscape, and what does and does not constitute risk and high risk, particularly for organizations that do not have or cannot benefit from the one-stop-shop system under which you can report to a single regulator. There are scenarios in which organizations have to report to multiple, different regulators within the European Union and EU, and that’s when the picture starts to become a little bit more complex and a bit closer to the U.S. experience, but also with the added time pressure of notification being required within 72 hours of becoming aware of the attack. That can be a lot of work under a very short period of time, and necessarily, quite stressful for the parties involved. That is why, ideally, you want a team that if they haven’t done this before, at least is calm and knows the individuals and the stakeholders, both internal and external, to reach out to so this process can be done in as streamlined a way as possible within that initial reporting time period.
Fran Faircloth: Yes, it’s a really complicated process to deal with in a very short time. In the U.S. it is no less complicated—there are several different considerations companies have to take into account here. For example, there are sector-specific reporting requirements for things like health care/HIPAA covered entities or critical infrastructure that have their own reporting requirements, and now, with the new SEC rules for public companies, those companies are required to report material incidents—which could mean even incidents that don’t involve personal data if they have a material impact on your business—within four business days. Beyond those requirements, which are complicated in and of themselves, in the U.S., all 50 states (plus D.C., Guam, Puerto Rico and the Virgin Islands) have their own data breach reporting laws, and those often will require companies to notify individuals if their personal information was impacted, and then, sometimes also state regulators, if individuals are being notified in their states. But all of that is a legal assessment that can be very fact specific and will likely require a good bit of investigation before companies even know who to send those notifications to, so this is very difficult to figure out in the heat of the moment.
Edward Machin: Yes, absolutely. And to add an additional layer of complexity, certainly in Europe, there can be contractual requirements to report to clients—so, going above and beyond the requirements of the GDPR in the controller context, but particularly in the controller processor context, processes are contractually required to inform the controller of breaches, and this is where some of the drafting around these contracts can be particularly interesting. As a controller, you want to be informed of as wide a number of breaches as possible, so that can be actual breaches as well as suspected breaches, whereas, if you’re on the processor side, you obviously want to minimize the scope of the breach reporting requirement. We often see heavy negotiation between parties over this clause, in particular because when a breach happens, particularly a significant breach, it really can have a big commercial, practical and costly impact on both parties. In addition to the regulatory reporting requirements that may or may not apply, organizations may still have to investigate incidents and report them to customers. So, there really are various reporting requirements, both legal and contractual, that organizations need to be aware of.
Companies should also be prepared for possible litigation stemming from the incident. Fran, how should companies best prepare themselves for plaintiffs’ litigation from affected consumers as well as potential investigations from state and federal agencies?
Fran Faircloth: If there is a chance for litigation, it’s very important to do a few things. First, obviously you want to consult with outside counsel and, if the incident involves multiple jurisdictions, that will mean consulting with legal counsel from the relevant jurisdictions. Companies will also want to make sure they’re preserving any documents regarding the incident, efforts to increase security, impacted systems and their response to the breach. They also want to consider issuing, as part of that, a litigation hold notice for all relevant employees and IT departments, and document actions taken and relevant information, including all notifications—making sure, throughout all of this, to mark any information gathered as attorney work product or attorney-client privilege communications where appropriate.
Edward Machin: Companies should also monitor any potential ongoing misuse of their data as well as considering legal action against cyber criminals, conducting an internal investigation, revising or supplementing public disclosures, and considering training or disciplinary action for employees as appropriate.
Fran Faircloth: Yes, those last actions are very important. Finally, once the incident is closed, notifications have been sent and things have been reported, it’s not over yet. Companies should still, at the direction of counsel, do a review of how things went, how to avoid similar issues in the future, look at whether they need to revise any relevant information security policies, renew any training, as Edward said, and implement revised security measures. And of course, once an incident is over and you’ve had a chance to use your incident response plan, it’s good to assess the incident response plan to see where it was helpful and where it might need work or updates.
This has been a lot. I think we really covered a lot of critical issues in this very short podcast, so I hope it was helpful.
Edward Machin: A big thank you to everyone who tuned in to this episode of The Data Day from Ropes & Gray. If you would like to join us, we’d love to have you, or if you know somebody we need to have on the show, please reach out to Fran or me by email, or alternatively, we’re both on LinkedIn. And if you enjoyed the show, please do subscribe. You can listen to the series wherever you regularly get your podcasts, including on Apple and Spotify.
Stay Up To Date with Ropes & Gray
Ropes & Gray attorneys provide timely analysis on legal developments, court decisions and changes in legislation and regulations.
Stay in the loop with all things Ropes & Gray, and find out more about our people, culture, initiatives and everything that’s happening.
We regularly notify our clients and contacts of significant legal developments, news, webinars and teleconferences that affect their industries.