In part one of our Cybersecurity installment of our Workplace Strategies Watercooler 2025 podcast series, Ben Perry (shareholder, Nashville) and Justin Tarka (partner, London) discuss key factors employers should consider when facing ransomware incidents. The speakers begin by simulating an incident response and outlining the necessary steps to take after a security breach occurs. Justin and Ben, who is co-chair of the firm's Cybersecurity and Privacy Practice Group, discuss best practices when investigating a ransomware incident, assessing the impact of the incident, containing the situation, communicating with stakeholders, fulfilling notification requirements, and adhering to reporting obligations. The speakers also address considerations when responding to ransom requests, including performing a cost-benefit analysis regarding payment, reviewing insurance coverage, identifying potential litigation risks, fulfilling ongoing notification obligations, addressing privacy concerns, and more.
Transcript
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.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
