With many fintechs taking the approach that it’s not if they will suffer a cyber attack but when, Skadden counsel Nicola Kerr-Shaw joins the latest “Fintech Focus episode to discuss how proper preparation can help significantly reduce regulatory scrutiny and sanctions, reputational impact and risk of resultant litigation. A member of the firm’s global Cybersecurity and Data Privacy Practice, Nicola covers notification messaging, regulatory expectations and ransom payment considerations in this discussion with host Joseph Kamyar. “Preparation is key, and even more so for fintechs, given the regulatory environment and personal liability under the SMCR,” she observes.
Top takeaways from this episode
Name: Joseph Kamyar
Title: European Counsel, Corporate at Skadden
Specialty: “Fintech Focus” host and European counsel Joseph Kamyar advises on a wide variety of corporate transactions, including cross-border private mergers and acquisitions, fundraisings, joint ventures, corporate reorganizations and general corporate matters, with a particular focus on the financial services, technology and media sectors.
Name: Nicola Kerr-Shaw
What she does: Counsel Nicola Kerr-Shaw, a key member of Skadden’s global Cybersecurity and Data Privacy Practice and an authority on AI-related issues, represents financial institutions, technology companies and other businesses in matters pertaining to AI, cybersecurity, data and privacy, and emerging technologies. She works with companies to creatively and effectively help them achieve their commercial goals.
Organization: Skadden
Words of wisdom: “A point to remember for the fintech world is that notification is around enabling individuals to protect themselves. So, [when] things like identity documents, payment mechanisms have been impacted, swift notifications might be key. That being said, though, there is a balance to be struck between notifying quickly and also taking a breath and determining if a notification is really necessary.”
☑️ Follow us on X and LinkedIn.
☑️ Subscribe to Fintech Focus on Apple Podcasts, Spotify, or your favorite podcast app.
Fintech Focus is a podcast by Skadden, Arps, Slate, Meagher & Flom LLP, and Affiliates. This podcast is provided for educational and informational purposes only and is not intended and should not be construed as legal advice. This podcast is considered advertising under applicable state laws.
Welcome to Fintech Focus Skadden's podcast for fintech industry professionals. The global regulatory and legal updates you need start now.
Joe Kamyar (:Hello and welcome to another episode of Fintech Focus with me, Joe Kamyar. And joining us today is our cyber security lead in London, Nicola Kerr-Shaw. So Nicola, welcome back.
Nicola Kerr-Shaw (:Hey, Joe, great to be back.
Joe Kamyar (:So today's episode is looking at cyber attacks and specifically how to respond if you are the subject direct attack, key considerations for GCs and CISOs and specific issues arising in the context of financial services. Nicola, you joined us about a year ago now, and prior to that you spent a number of years advising on cyber, data, AI, and tech matters at a very large global banking group. So thank you very much for taking the time to talk to us today.
Nicola Kerr-Shaw (:That's no problem at all. Happy to be here.
Joe Kamyar (:So let's take this chronologically. So if we focus on the first 24 hours to begin with and what typically are the first indicators of cyber attack, what would the immediate action be and what would you expect?
Nicola Kerr-Shaw (:So it really does depend, and I know that's almost a little bit of a get out answer, but really sometimes there's a big bang effect where computers don't work, screens are black or have a holding message from the threat actor with a dark image and you've been ransomed or blocked or something and the company is an effect paralyzed and being held to ransom. They can't do anything or everything is dark black and sometimes that's on devices as well as main computers. Other times its far less dramatic. So you might have the IT are monitoring the systems in their normal way and there's an indication of threat actor activity, which is quite exciting. Are they in, are they out? What are they doing? What's their next move? Or perhaps sometimes there's certain systems or applications that are unavailable without an explanation and that can be really confusing. For example, an example I've come across is where things like a monitoring tool, for example, an anti-money laundering tool produces 40% less hits than average.
(:And there's questions, is there an internal error? What's going on? Is this just coincidence or is this a cyber attack and someone's manipulating their data? So all of that leads to an excitement of an incident that we will then be engaged on. I mean, it's important to note that cyber attacks can relate to many different circumstances. So there can be threat actors pursuing different objectives. It can be an internal person, insider threat. Sometimes they're acting innocently, total innocent mistake, didn't realize they were doing it and sometimes it's acting maliciously. One of the most difficult incidents I've ever worked on, there were huge operational impact and it was caused by human error. Basically someone had done a really long shift and made a mistake and that took out an entire system.
(:So also these types of incidents that can cause significant operational disruption can also be caused by an external supplier. And then we call that a vendor breach and many of the principles are the same, but too much to talk about in this episode. So for this one, we're going to focus on direct attacks by an external person, so a threat actor. There's also many different types of cyber attacks and they can come in different forms as we've talked about, data poisoning, et cetera. But for this one, again, we're going to focus on ransomware.
Joe Kamyar (:Great. That makes sense. So perhaps quick back to basics, could you maybe explain what is a ransom attack? What are the attacker's motives and what are they actually trying to do?
Nicola Kerr-Shaw (:So ultimately with a ransom attack, the attackers are trying to cause pain and havoc so that entities pay the ransom. But why they do this is for many reasons. I mean hacktivism is big and that's where they're trying to further a political motive by taking down an entity or even a sector. And often it's not about hacktivism, it's about crime, so for financial gain funding their own illegal activities, wars, et cetera. Threat actors usually do their research too. So they'll hit companies when they know those companies have insurance to pay their ransom or have financial backing, and they'll also try and hit at a time when they know it'll cause the most pain to customers of that entity or for the team supporting that entity internally. So for example, hitting a payment provider on payday, trigger an attack on a Friday night before a bank holiday weekend where no one will want to work over the weekend.
(:Traditionally it was taking out IT systems when ransomware hit triggering operational resilience issues. But often now data is involved as well. For those in the fintech space, the idea obviously that you can't provide a financial service can cause massive loss, huge reputational issues, but also regulatory breaches and particularly if people are relying on your service, like for example, to make payments, access their cash, et cetera. But as I said, now often these kind of attacks also include stealing data. The data is exfiltrated and often the data on the servers that the entity still has access to is left encrypted and locked. So not only has someone stolen their data and all the ramifications of that, they can't access the data themselves as a company.
(:And that can be in itself crippling. It could be all your customer files, your regulatory records, financial holdings. Often the data is regulated such as personal data, highly confidential data, could be MMPI, other considerations to think about. And so companies are then put in this ransom position to say, we want to pay the ransom to stop that data being made public and to regain access of the data so they can function again. And they also obviously want to minimize regulatory breaches and reputational impact.
Joe Kamyar (:Yeah, so I guess clearly understanding the technical and operation items you've just covered inform what the legal and regulatory risks are and actions that flow from that. So why don't we start by looking at this from a regulatory perspective. What are the key regulatory risks that I guess should be front of mind for GCs and CISOs?
Nicola Kerr-Shaw (:So many, but let's start with data. As I said, often data will have personal data within it that's protected by the GDPR in the UK and the EU. It may also contain personal identifiable information, PII protected in the US, but for this FinTech Focus episode suggests we just focus on the GDPR angle. A ransom attack where data is accessed, even if it's not exfiltrated, even if the threat actor has just been in files and folders and had to snoop around. That is a data breach. And this means that the presence of threat actor on your systems in itself and access in the data is a data breach. The same applies to unauthorized encryption of the data. So even if there's no evidence that they took the data, they uploaded the data somewhere else, but they encrypted the data, that is a data breach and obviously clearly exfiltrating the data and taking it is a data breach too.
(:All of these would fall under the GDPR. So the first thing that needs to be considered is does the net company need to notify the data regulator? And there's a short deadline for this, which is without endue delay or where feasible, not later than 72 hours of becoming aware of the breach. Lots of discussion about what is becoming aware of the breach, but the only exception to this is if the personal data breach is unlikely to result in the risk of rights and freedoms of natural persons. So i.e., it's not going to cause any harm, the fact that this data has been breached. On many occasions, companies will just notify the regulator just so they're not in breach of this 72 hour window and just hold the space to say, we're looking into this further. Then companies also need to consider whether data subjects i.e. the individuals need to also be notified, whether this is often a longer process to establish exactly what has been accessed and what's the harm to the individual.
(:A point to remember for the FinTech world though, is that notification is around enabling individuals to protect themselves. So therefore, so things like identity documents, payment mechanisms have been impacted, Swift notifications might be key. That all being said though, there is a balance to be struck between notifying quickly and also taking a breath and determining if a notification is really necessary. And if so to whom. I mean I've advised on many incidents where notifications have gone out in a bit of a panic, sometimes to hundreds of thousands of people where that wasn't necessary causing reputational impact, et cetera.
Joe Kamyar (:Yeah, I mean that's a huge number of people and I guess it really emphasizes the need for companies to think more broadly about their communication strategy and then also how they manage and handle news agencies, corporate partners, investors and so on in terms of actually them finding out.
Nicola Kerr-Shaw (:Yeah, you're absolutely right, Joe. I mean, communication strategy is a massive part of instant response, particularly around personal data notifications. It needs to be well coordinated but also considered from a legal perspective to ensure you're not stepping into a legal pitfall with what you're being said such as admitting a regulatory breach.
Joe Kamyar (:So that's data. Perhaps walk us through some of the other key sets of regulations that are relevant to fintechs.
Nicola Kerr-Shaw (:Yeah, absolutely. I mean obviously we've got the wealth of financial regulation and particularly the obligation to have a continuity of service when you're providing a financial services is key sector to the economy. So there is a lot of focus on regulators on operational resilience at the moment. I think you did an episode with my fantastic colleague Suzanne on DORA recently. Came into force on the 17th of January. And DORA has very strict and short incident reporting obligations where lots of information is required to be notified to the regulator in a very short timeframe. In the UK, although we don't have DORA, the FCA and PRA do expect an open and transparent relationship and often would expect a Swift notification of any incident which may impact operations and the delivery of financial services. And on top of this, companies need to think about the coordination of these notifications, not just in relation to the financial regulators, but also to the data regulators to ensure consistency across the regulators and then also across the jurisdictions that they might be present in.
Joe Kamyar (:Understood. So I guess in terms of regulatory engagement, you've talked us through the approach with data regulators and that's clear. And then you've also briefly touched on the FCA and PRA from a financial regulatory perspective. I guess sticking with that, could you walk us through the typical notification strategy for financial regulators like the FCA and PRA, the extent to which there is an ongoing dialogue and what firms should expect from that?
Nicola Kerr-Shaw (:Yeah, of course. So in my experience, it's advisable to notify the UK financial regulators quickly. There is an MOU in place between the ICO and the FCA and regulators can and do share information. So obviously if you're notifying the ICO, you might want to notify the FCA at the same time. But also in addition, the financial regulators don't want to hear about an incident through rumor, through the press, from another regulator, from a regulator in another jurisdiction. It's better to manage the narrative yourself to have that open dialogue. And depending on the severity of the incident, this may be a regular check-in or may require specific email notification. That all being said again though, you don't want over notify. You want an open and transparent relationship, but you also need to protect yourself slightly. And the content of the notification, whether this is informal or formal, should be carefully considered with legal counsel.
Joe Kamyar (:Okay. So sticking with comms, because it strikes me that from everything you've said, this is really one of the most key work streams when you're dealing with an incident. Presumably there's going to be a whole raft of stakeholders that will need to be informed and that may be driven by a range of factors, whether that's, I don't know, a legal requirement for impacted data subjects, contractual undertakings for vendors, regulatory obligations for consumers or for wider PR concerns. How are you seeing financial services firms handle this and to what extent does the comms plan typically, I guess, pre-bait in existing cyber response plans?
Nicola Kerr-Shaw (:So in my view, it's vital to have a comms playbook drafted in advance. I mean, I've advised on an incident where my associate and I have been up all night on the night of the incident drafting a comms playbook because they haven't got one in place. And it's something that you do need to coordinate to have a consistent message to make sure you're telling people what you're telling the regulators, that it's all aligned and you've got your story straight. The comms playbook doesn't need to cover every outcome and event. As I said, there's lots of different things that can happen, different timeframes, but it should have pro forma templates with sample wording for a range of incidents. It should also have details of things like your social media accounts, which you might forget about, mailing lists, customer groups. And also remember you might not have access to your normal technology, so it's great to have it in another place and kind of like a battle box with it printed off so you can refer to that easily using different technology if you need to.
(:It should also have sample wording for updating staff. And this is a bit of a bugbear of mine, it's something I mention all the time to clients, but I have seen several incidents where companies neglect to update staff and staff are often the ones who are customer facing and so are going to get the telephone call if services are disrupted, not accessible. But even if they're not customer facing, they'll usually have contacts in the marketplace and they'll also have their own social media accounts. So you might not be able to tell staff any material updates due to the nature of the incident. It might be very sensitive. You need to keep it confidential. And I'm not saying overshare at all, but it is vital to tell them something, even if it's just something like systems are down, we're investigating, don't say anything on social media. Give them sample wording, [inaudible 00:13:01] this in advance in relation to your comms playbook and give them a contact point, who they should reach out to. And like I said, just reminding them not to post anything on social media.
Joe Kamyar (:I guess let's rewind slightly and go back to the ransom and specifically the topic of paying the ransom. I'd have thought particularly in the financial services space, there'd be a huge kind of sensitivity and I guess a whole raft of compliance concerns and actually making that payment.
Nicola Kerr-Shaw (:Yeah, you're absolutely right. I mean, it needs to be really carefully considered on a case by case basis. Different laws obviously apply in different jurisdictions and companies need to navigate all of these. These can be sanctions regime, finance of terrorism, anti-money laundry, some laws have got strict liability where others require actual knowledge. So this can also therefore influence the strategy on how much information you get from your, or you seek and you try to obtain from your forensic experts.
Joe Kamyar (:So I guess in practice, how do you actually see organizations getting comfortable making the payment?
Nicola Kerr-Shaw (:So by obtaining specialist legal advice such as our Skadden white collar team, or seriously, it's a really detailed analysis that can't be taken lightly. Clients do get comfortable and many do pay, although increasingly we're seeing a resistance to payment and choices not to pay. The UK government proposals are mandatory reporting of ransom and requiring approval from the NCA before payment is an interesting development here. If you've not seen it, the consultation is open until the 8th of April. I mean, I've heard many different views on this proposal, but in reality, ransom attacks is a huge criminal industry and something does need to be done and to change to tackle it.
Joe Kamyar (:So given everything we've just covered, we've already talked about there being a comms plan which would need to be implemented in short order, but what else are clients doing in anticipation of an attack and how does your team at Skadden help with that?
Nicola Kerr-Shaw (:So many people now say that cyber attacks on companies is certain, so they no longer talk about if we're hit, but instead when we're hit and at Skadden can't help with that part. We can't stop you being a target of a cyber attack or caught in the crossfire or having a significant vendor breach. However, what we can do is significantly reduce the regulatory scrutiny and sanctions, reputation impact, and risk of resultant litigation from a cyber attack. As part of this, we're helping many clients refresh and revise their incident response plan, building in updated regulatory reporting obligations and expectations.
(:We also assist on retaining specialist vendors, critical support in advance of an incident and under privilege where that's possible. And the last thing you want to be doing in the first 48 hours of a cyber attack is negotiating terms with your key specialist forensic support team. We also often do things like host specialist tabletop training sessions, helping teams really prep for an incident and to understand their legal considerations, but also evidencing that they have, the board has the requisite knowledge as required by regulators either under senior manager's regime or DORA. I mean, preparation is key and even more so for fintechs, given the regulatory environment and personal liability under the SMCR and DORA, et cetera. So this is an area we think we can help. So think of us.
Joe Kamyar (:Understood. Well, Nicola, thank you very much for your time.
Nicola Kerr-Shaw (:Thanks Joe.
Joe Kamyar (:And as always, thanks to everyone listening and see you next time.
Voiceover (:Thank you for joining us on FinTech Focus. If you enjoyed this conversation, be sure to subscribe on your favorite podcast app so you don't miss any future conversations. Additional information about Skadden can be found at skadden.com.