Workplace Strategies Watercooler 2025: A Ransomware Incident Response Simulation, Part 1

Announcer: Welcome to the Ogletree Deakins podcast, where we provide listeners with brief discussions about important workplace legal issues. Our podcasts are for informational purposes only and should not be construed as legal advice. You can subscribe through your favorite podcast service. Please consider rating this podcast so we can get your feedback and improve our programs. Please enjoy the podcast.

Ben Perry: Hello everyone and thank you for joining us. My name is Ben Perry. I’m a shareholder in the Nashville office of Ogletree Deakins and also the Co-Chair of Ogletree’s Cybersecurity and Privacy Group. And today I’m joined by Justin Tarka, who’s a shareholder in our London office, and also a member of our Cybersecurity and Privacy Group. Thanks for joining us, Justin.

Justin Tarka: You’re welcome, Ben. And hi, everyone.

Ben Perry: Today, we wanted to talk about a recap in case you missed our recent presentation at Workplace Strategies in Las Vegas. We put on an incident response simulation going through a data breach simulation that we created based on a combination of a lot of different incident facts that we’ve seen happen both in the consumer and employment context and walked through a lot of the considerations that companies need to be thinking about in advance in order to plan their incident response strategy.
It’s not enough these days that you have an incident response plan on paper. There are a lot of things that come up in the midst of an incident response that are going to be quick judgment calls. And if it’s not things that you’ve planned for in advance, you’re going to find yourself behind the 8-ball and panicking and trying to figure out what you should do in response to every little wrinkle that comes your way. So, I just wanted to briefly provide a recap of the background of the incident response we described.
So, we were dealing with a non-bank mortgage loan originator with employees in each of the 50 states, Canada, the UK, France, and Germany. We’ve got a multinational company. And late on one Friday night, one of the VPs of HR received an urgent Friday night email at 4:58 PM, and it was from supposedly one of her direct reports who was escalating an urgent employee grievance. It turns out this was not actually her direct report, but somebody posing as this person using a very similar domain to the one that the company used, and this person clicked the attachment, enabled some content in there, and entered their credentials in an attempt to open this document.
Nothing happened for a little while. About a week went by, it was not recorded to the internal IT team, there was no detection of anything that happened. And about a week later, the company realized that their systems were encrypted. There was a ransomware note from the well-known ransomware group, Akira, and the company was trying to figure out how to respond. Everything had kind of ground to a standstill. Employee records, including personal details and personal reviews, had been encrypted. HR and payroll systems were inoperable, and the business had essentially ground to a halt. Employees could only access their Outlook email via web, and that was about it. So, Justin, that’s a pretty common scenario we deal with. So, what’s the first thing that people try to do when dealing with that situation?

Justin Tarka: Well, the first point is essentially verification. So, the initial step is an investigation to exactly what’s happened, the scope of it and so on with the impact you’ve just described. And once the breach has been verified as such and the impact is clear, the next point to consider is, okay, what steps are required to stop or contain it? And the points I’m about to briefly go over will essentially form part of any incident response plan. And that’s one of the things any business should have in place and should be working on now if they don’t already have that type of document.
In terms of containment, the points you probably you need to consider are, okay, what immediate action should be taken to isolate the infected systems and perhaps prevent further encryption? That may involve taking systems offline. It doesn’t necessarily, or probably should involve shutting down those systems because that will likely make it harder to remedy the situation going forward. It also may involve restricting access to critical systems, identifying who outside of IT and may be involved in detecting–

Ben Perry: You mentioned containment. Who should be part of the containment effort? Is this just IT? Are they acting on their own? Who all’s involved in those sorts of efforts?

Justin Tarka: Well, that’s a key point, and it’s always an important consideration to factor in, okay, what external resources or expertise should we need? And typically involves external counsel, so namely external lawyers. And one of the advantages of involving them at an early stage is the potential protection of legal privilege, both in respect of the advice you’re receiving in terms of next steps and how to remedy the situation. And also, in relation to any documents that are drafted. So, any notifications that are sent to relevant people, which we’ll come onto a bit later, or regulatory bodies as well.

Ben Perry: Yeah, that’s a great point. Sorry to jump in. I was just going to say in terms of cyber insurance, I know we may touch on this later, but it’s kind of critical to put your cyber insurer on notice, right? Because they generally have approved outside counsel and forensics vendors that they prefer to use.

Justin Tarka: Exactly, exactly. And a lot of companies nowadays do have cyber insurance in place, and it will be a strict requirement of that to notify them within a certain time period. And like you say, it’s very typical these days for them to have an approved panel of lawyers or approved vendors or cybersecurity experts or forensic experts that they wish you to use. So, it’s really important at an early stage to make sure that you’re taking them along with you on the journey to remedy the effects of the attack and to deal with the response to the attack as well.
Another important consideration is who is part of your team? And that involves an initial stage identifying, okay, who’s going to lead the team? Do you have someone with the right level of experience or expertise that might be an existing data protection officer, and it’s someone that should have the capacity as well, not just the skills/experience to deal and lead the response, but someone that has the capacity to coordinate meetings, calls, document, and create action lists. It may involve admin support as well, bringing in admin support to take notes of meetings and keep records. That’s an important part of any incident response, and it’s a point we’ll touch on later because there are requirements to provide certain prescribed information to regulators in whichever jurisdiction you may be based in.

Ben Perry: Yeah, and let’s not forget the privilege aspect of that, right? Because generally when a forensics vendor is brought in, it typically involves a tri-party agreement between the outside counsel law firm, the client, and the forensics vendor that is doing either the root cause analysis and/or the containment effort. And so it’s extremely important that outside counsel is both involved in that process, but part of the agreement with the vendor and that your outside counsel has thoroughly vetted that agreement to make sure that the way that it is drafted supports the fact that it is essentially to help outside counsel provide legal advice to the client in terms of how they should best respond.
There are obviously challenges with that because facts themselves are not privileged, but your outside counsel are extremely important in not only helping to afford privilege to any sort of report that’s generated if the company chooses to generate a report, which is another judgment call that the company will have to make, and that’ll depend on a variety of circumstances, but also making sure that communications are all flowing through approved channels, counsel, and that counsel provides the communication guidelines in terms of not speculating about root causes or assigning blame or doing anything other than A. Communicating was essentially necessary and confirmed to the investigation. And that those communications are limited to the necessary group and not spread out more broadly among the company, right?

Justin Tarka: Exactly, exactly. And it’s important to not make any speculative, like you say, or preemptive statements to make sure all the key stakeholders are consistent in their messaging. And that’s where external counsel can provide a real benefit. Another point that’s important in terms of the communication topic is okay, identifying and being clear on what notifications are we legally required to provide. And by that, I mean to regulators in the various jurisdictions.
The scenario you outlined involved a number of countries, and particularly in the countries in Europe, there are notification requirements under the GDPR and UK equivalent legislation. Very quickly, the requirement in terms of timing is to report any breach that meets a certain criteria without any undue delay, and at the very least, within 72 hours. Now, the practical reality of that is you often…your investigation may be at an early stage, or you might have limited information initially, but the expectation–

Ben Perry: May not have retained it at all yet.

Justin Tarka: Exactly. Yeah, exactly. But I think the expectation in that circumstance is provide what you can with the promise for more to follow as things develop.

Ben Perry: Oh, yeah. That’s something we’ve talked about a lot, right? Because first of all, that goes back to the planning aspect in terms of looking across all of the data that you maintain as a company, whether that’s employment-related data or business-related data, and figuring out what is the shortest notification obligation that we may have so that when something does happen, you’re not scrambling trying to figure that out while also trying to maintain control over the containment of the incident and trying to, you’ve got a million balls up in the air.
You already know, okay, we’ve got EU data in our employment-related files, we know that these were likely affected, and then you can go ahead and notify the DPA, and then you’re obviously not going to have a ton of information. But at this point, that this sort of incident, like a ransomware attack, is almost certainly going to trigger a notification requirement if those EU employee files are affected, and especially if there’s evidence of exfiltration, which there often is. Ransomware encryption is usually the last step that a threat actor takes after they’ve been in your environment, especially as here where they’ve been in there for an extended period of time.
So, that’s something because we’ve seen a lot of data protection authority penalties in recent years in terms of delayed notification or what the regulator perceives as delayed notification, even though it may take months for the forensics investigation to fully unfold, and you don’t necessarily know right away was EU employee data actually affected. And so, that’s one of the judgment calls you have to make is you have to think how likely is it that this data is going to be affected in a way that would require notification? And if you think that the answer is likely going to require notification down the road, a lot of companies are choosing to go ahead and preemptively notify, provide whatever bare-bones information you have and then supplement later, right?

Justin Tarka: Yeah, exactly. And we typically recommend an abundance of caution. One thing that can help, and this scenario involved the UK, so it doesn’t completely solve the issue, but under the GDPR, which is the legislation that applies in Europe outside of the UK, you are allowed to make one notification based on where your main establishment is. So, that’s essentially, okay, where are strategic decisions and/or where are decisions regarding how the relevant data is used and what purposes it’s used for? Where is that made? So, if that’s, for example, in Germany, GDPR allows you to just make one notification to that body. Like I said, in this scenario, it doesn’t solve the issue necessarily because you also have a presence in the UK. So, a separate notification would need to be made to the UK regulator in light of Brexit and so on. But that’s one thing that can make it easier depending on what jurisdictions are in play.

Ben Perry: Justin, you’ve mentioned the regulatory requirements that companies may have, and you also mentioned maybe putting your cyber insurer on notice, which may be a contractual obligation to do so within a reasonable amount of time, or there may be an express time period designated. What about vendors and business partners? Because a lot of times there may be contractual obligations to notify them as well, if your customers or other business partners data is implicated and what constitutes a reporting requirement to your business partners is going to vary, right? And we’ve seen causes all across the board in terms of how broad they are in terms of what they consider reportable data.

Justin Tarka: Exactly. And the scenario we presented during workplace strategies involved employee data, but it’s more typical or very typical for it to be broader than that, and to involve information relating to customers. And like you say, there’s often agreements with business partners or vendors which will have very strict requirements for you to put them on notice if something like this happens or if you have an incident like that. So, it’s important to…this is part of your initial response or one of the immediate considerations that you need to factor in is, okay, what contracts do we have in place? Let’s examine the terms, what are notification obligations to those parties? Because in turn, they have notification obligations to perhaps individuals or regulators where they’re based as well.

Ben Perry: Right. Yeah, and I mean one of the last things we talked about in terms of initial communication strategy, is the company going to put out any sort of preemptive statement, whether that’s to employees, to business partners, customers, et cetera, regardless of whether you have any sort of regulatory or contractual obligation at this point, or whether you’re not sure whether you may and that’s going to depend on a case by case basis.
A lot of times if we’re dealing with the scenario we just talked about where all the systems are down and employees are basically hamstrung in their ability to do their job, they’re going to know that something is going on, so there likely needs to be some sort of communication to employees just letting them know kind of bare bones information, giving them a central contact point, which may vary by department in terms of who they can go to for questions if they’re having issues in terms of being able to perform their job because of systems being down. It’s all about managing both the narrative internally and externally.
We didn’t get it too much into publicly traded companies, but obviously there’s a separate public reporting obligation for publicly traded companies once they determine that it is a material incident as defined by the SEC rules. So, that’s kind of a separate piece is there’s that going on in the background, and we’ve seen companies make filings and disclose these sorts of incidents, and then that was later used against them in class action litigation because the plaintiff said, well, you notified the investors before you notified all the individuals. And to an extent, that may be unavoidable because if you’re dealing with a ton of people large enough that it is considered a material incident under the SEC rules, it takes a lot of time to both extract the relevant names and addresses and what types of information was affected. And that’s a process that takes months. So, in some ways that’s unavoidable, but there’s a lot of moving parts depending on which industries you’re in, the types of data you’re talking about, all the more reason to be thinking about those issues in advance.

Justin Tarka: Yeah, and like you say, those principles apply to what you say to employees, business partners, to the media. A lot of the time, especially for large organizations, these things reach the media, and you get queries or questions from the media. So, being consistent in the response to them is important. And like you say, there’s some regulatory obligations that apply, even as a practical point, you want to make sure that any customer facing staff are briefed on how to respond to queries so that everyone’s delivering a consistent message.

Ben Perry: Absolutely.

Justin Tarka: Another main point that we discussed during the presentation, which was the subject of a lot of discussion, was, okay, we’ve received this ransom request. Should we pay it? What factors, what do we need to consider when we’re deciding whether to pay a ransom or not? Ben, I’m not sure what your thoughts on the benefits or the advantages of perhaps paying a ransom are?

Ben Perry: Well, there’s becoming less and less utility these days in making ransom payments. First of all, insurance policies do sometimes cover ransom payments, so that will depend on the specific terms of your policy. And the insurer will likely ask a lot of questions about the cost-benefit analysis associated with making that payment. One of the few scenarios I’ve seen recently where companies are actually choosing to make payments is where somebody’s life may be at risk if it’s a healthcare provider or something like that, and they just really need to get their systems back up and running in order to, and if they don’t in a timely manner, then people’s lives are at risk. That’s one of those scenarios where it’s kind of hard to put a dollar amount on the value in getting your systems back up.
We’ve also seen some scenarios where companies are completely unable to do business because all of their records are encrypted. They didn’t have any sort of redundant backup that they could restore their files from. And maybe it meant that if they didn’t pay, then the business would go under, they’d essentially be unable to do business. So, I think that just speaks to the importance of backups and maintaining backups offline somewhere in a secure place. But ultimately, there’s no guarantee A. That they’ll actually delete the data. There’s no guarantee they’ll actually give you the decryption key. Your vendors will generally have a good idea of which ransomware groups generally are good to their word, but again, you also can’t usually confirm that they are who they say they are, right?

Justin Tarka: Yeah. Yeah. Even the point about maybe paying a ransom to try and keep things private, like you said, there’s no guarantee that that will be the case after making the payment. And the other consideration in that respect is it doesn’t remove your notification obligations, whether that’s in relation to any business partners or vendors, or particularly to any regulatory bodies in the various jurisdictions. The fact that you’ve paid the ransom is not relevant to what notifications you need to make to those bodies.
Another important issue to consider, okay, what effect will paying a ransom have on any litigation that may follow later on because you may get complaints at least and/or threatened claims or claims which are followed through from individuals that may have been affected by the attack. So, it’s important to consider at this stage, okay, how will this affect, and this is where you would be working closely with external counsel, how will this affect our position in terms of future litigation?

Ben Perry: Yeah, let’s unpack that a little bit because our listeners may not be, unless they’ve gone through this sort of incident before, they may not be familiar with how this unfolds in practice. So generally, there’s some sort of page or forum on the dark web where they will post a listing naming and shaming your company saying they have X amount of data, and sometimes there’s a countdown clock, or they’ll say, we’ll dump this by whatever date if we don’t get paid. So, for those who aren’t familiar, the dark web is essentially the non-indexed portion of the internet where you have to have a special browser to access it. You have to be fairly tech savvy. It’s where a lot of the unsavory and illegal activities on the internet take place, like selling stolen data. And when these companies don’t get paid, a lot of times they will just dump all of the data and make it publicly available on the dark web.
And plaintiffs’ lawyers are regularly monitoring the dark web, looking for evidence of data breaches that they can then sue about. And at least in some jurisdictions, if the data has been dumped on the dark web, then oftentimes that can be kind of a de facto injury that somebody has survived if you’re trying to file a motion dismiss and get rid of the case, because one of the big defenses in data breach litigation is an injury and whether or not the named plaintiffs have suffered concrete injuries, whether they can point to any actual harm or imminent threat of harm, like actual evidence of identity theft, or in this case, maybe their data being dumped and anybody having access to it.
So, I guess the last question people listening may have, is it illegal to make a ransom payment? So, I guess I’ll start with the U.S., Justin, then I’ll toss to you for your thoughts on the EU, but at least in the U.S., it’s not illegal to make a ransom payment as long as the recipient is not on the OFAC Sanction list. And the problem with that is you can’t always confirm. In fact, you can pretty much never confirm that these recipients are not on that list because you’re often operating on very incomplete information. Your vendors will usually be the ones running these checks, and they’ll look at things like the crypto wallet address, which is generally a throwaway wallet. They’ll look at maybe some signatures from the ransomware that they used in the incident, any sort of unique signature on that, and any known affiliates of the group that they’re claiming to be.
And so obviously, that’s a very imperfect check in terms of whether or not you’re violating sanctions by making a payment to these individuals and the FBI, to be clear, strongly discourages ransom payments. And one thing that they’ve said is, if you do end up violating OFAC with any sort of ransom payment, one thing that they will take into consideration in responding to that is whether or not you notified the FBI in advance of the incident because that’s obviously, you’re not required to notify the FBI, but they always ask that companies report it to them so that they can maintain statistics on a lot of these groups and try to help where possible, maybe by providing a decryption key or something like that.

Justin Tarka: Yeah. And for example, to contrast the position in the UK is not dissimilar. Our regulator, the ICL has issued similar guidance to OFAC in the sense that paying a ransom is not prohibited, but it doesn’t get you off the hook in terms of what you should be doing in response to an incident. So, they would still want to see evidence that you’ve tried to understand what’s happened or the cause of a particular data breach, that you can demonstrate that you’ve understood or learned from the incident and that you’ve complied with your notification obligations and any obligations that exist as it relates to individuals that may have been affected by the attack. So, it’s not prohibited as such, but it doesn’t stop you from doing or needing to do the things that you should be doing.

Announcer: Thank you for joining us on the Ogletree Deakins podcast. You can subscribe to our podcasts on Apple Podcasts or through your favorite podcast service. Please consider rating and reviewing so that we may continue to provide the content that covers your needs. And remember, the information in this podcast is for informational purposes only and is not to be construed as legal advice.