In this episode of "Decrypted," Skadden's cybersecurity and data privacy co-leads David Simon and William Ridgway sit down with Nicola Kerr-Shaw in London and Susanne Werry in Frankfurt for a frontline look at NIS2 — the EU directive redefining how organizations must prepare for and report cyber incidents across Europe and beyond. After a quick survey of recent U.S. cyber and AI policy developments, the team dives into what happens when an incident strikes under NIS2 — from the directive's dramatically expanded scope and strict notification deadlines to registration pitfalls, board-level personal liability and the challenge of preserving legal privilege under pressure.The episode wraps with practical takeaways on tabletop exercises, incident response planning and key U.K. developments, including the proposed Cybersecurity and Resilience Bill.

Connect and Learn More

☑️ Nicola Kerr-Shaw | LinkedIn

☑️ Susanne Werry | LinkedIn

☑️ David Simon | LinkedIn

☑️ William Ridgway | LinkedIn

☑️ Skadden | LinkedIn | X | Facebook

☑️ Subscribe Apple Podcasts | Spotify | Amazon Music

“Decrypted” 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.

From Skadden, Decrypted is a podcast exploring the latest developments in cybersecurity and data privacy strategies, risks, and regulations.

Welcome to Decrypted. I'm Bill Ridgway, co-lead of Skadden cybersecurity and data privacy practice. I'm excited to be joined by David as well. David, over to you.

Thanks, Bill. Yeah. This is David Simon. I co-lead the cyber and data privacy practice of Skadden, and we are so pleased to have you with us for Decrypted. This is the new Skadden podcast that is focused on cyber and data privacy issues from a legal and operational perspective. We're really focused on not the theory, not really the headlines, but what really matters to companies making tough decisions in real time, where risks and business decisions converge. So today we're going to dive deep into a key European law that is central to how cybersecurity is being handled today called NIST2 or the Network and Information Security Directive two, which is going to make a huge impact on how many organizations in Europe and globally operate with a 24-hour notification obligation among many other requirements.

But first, Bill and I are going to chat with you briefly about some key developments in the United States for just a couple minutes. The first is about the recent US cyber strategy the White House put out. I think the one thing that stood out to me about this, and we have a client alert and really some stuff in the show notes about it, but is that this is a relatively short document that sets out a high level strategy. And it struck me that they're focused on this question of hacking back, offensive cyber. And the national cyber director came out and said, "No, we don't really mean that companies are going to be able to go and take matters in their own hands and hack back," but there is a real emphasis on proactive measures, not just being defensive, but taking offensive steps. It'd be interesting to see where that goes. Bill, what has stood out to you from the cyber strategy?

Yeah. Certainly related, David, is this concept of both private sector involvement when you're talking about offensive strategy. Now, if it's not hacking you back as we're being told, we're still uncertain exactly what it is that the administration's expecting of the private sector and what kind of rules may govern there. There's not an existing available framework for information sharing in this context. And as you alluded to, there's a number of federal and state laws that could restrict what the private sector may be able to do in these circumstances. So we're all certainly watching to see how this plays out, but we'll keep you all posted certainly on the podcast.

Yeah. The two other things that I think are really notable is for those of you in critical infrastructure, there is a reference in this strategy to the Cyber Incident Reporting for Critical Infrastructure Act, which has a 72-hour notification obligation in it. For companies that are covered by this, no one knows exactly which they are. I think many thought maybe this is going away. So instead of it coming out and being implemented fully in May, it'll be sometime later. We'll watch this space and we'll be putting out some more information about it. And you'll be hearing about it in a subsequent podcast from one of our colleagues. The other development on cyber in the United States was the cyber crime executive order. Bill, what did you think of that? I know obviously you were DOJ cyber crime prosecutor for many years.

Yeah. Likewise, was a short document, so there's still a lot to be determined to figure out how this will all play out. The thing that I thought was notable and that we're certainly tracking with clients is this concept of trying to create a mechanism for a more organized mechanism for the retrieval of funds from companies that have been impacted by a cyber incident. We all have experienced clients who have suffered losses or have made ransom payments and they may in some circumstances want to try to retrieve those funds. So it has requested that the AG put together a proposal for how to think about victim restoration. And we'll be interested to see how that plays out because that may be an opportunity for folks in the private sector.

So watch this space. It's good to see some specific actions coming out to raise questions around the role of public-private partnership, which continues to evolve. I think the other thing we wanted to emphasize, we're going to go deeper on these topics in subsequent episodes, but there was recently another key policy statement by the administration in Washington, which is their AI policy framework. And this policy framework, again, touches on many aspects of artificial intelligence, but one of the key points that I thought was worth emphasizing in a space we're going to watch is the focus on preemption of state laws in the United States. We have a patchwork of data privacy laws and a growing number of state laws related to artificial intelligence. And there's an awareness that this makes it very cumbersome to innovate. And one of the stated objectives of the administration is to achieve AI dominance, and this is regarded as standing in the way. So the preemption point is not the only one that setting stands out, but for those of us in cyber and data privacy, we know that when you have a cyber incident or privacy issue or data breach, you're thinking about a lot of these rules. And so what would the preemptive effect be? Obviously going to be a complicated question for us to unpack, but wanted to see, Bill, if you had a reaction to that as well.

Yeah. Again, I think there's a lot of uncertainty even if there were efforts to preempt like what laws would actually be impacted because of course there's also a host of general laws that bear on the practices of companies, consumer protection regimes, which probably are less likely to be impacted by something like this. So it certainly will be interesting to see how this plays out in the scope of any attempted efforts to preempt state law regimes.

For those of you who joined us in October for our Fortify Summit, this was something we talked about with one of the architects of the White House AI action plan. And so we do see continuity here, but it's a space to watch for those of you interested, you can reach out. But now most importantly, we're going to turn to the main focus of our discussion today, which is really the most important cybersecurity legal regime in Europe. And has someone who's ... I'm based in Washington DC, but spent years practicing in Europe in Brussels. NIST2 was really at the core of the latest round of what we call the Brussels effect, where regulation that starts in Europe doesn't stay in Europe. It really becomes an operating global standard, or at least it's having a tremendous effect on how states and other national governments think about how they regulate in this space. And so we're so delighted today to dive into this, but I wanted to get your take, Bill, before we introduce our experts who are really going to walk you through it.

Well, just maybe the important headline for our audience is this is certainly not just a European issue. Obviously, US lawyer deal with a lot of US headquartered companies, and I'm very surprised by how much for these companies that had European operations, I need to reach out to our European leaders here who are a part of the cyber program to really help us navigate this. And so it is something that companies based really around the world with operations in Europe need to think about.

We're joined today by two phenomenal lawyers, our global practice. We'll introduce to you now. First, Nicola Kerr-Shaw, maybe you could kick off and introduce yourself. Nicola's, joining us from London.

Thanks, David. Yeah. Hi everyone. My name's Nicola Kerr-Shaw and I lead out the team here in London advising a wide range of clients on cyber instance, data breaches, regulated compliance and cybersecurity, data and AI. What's a bit different about me is I spent over a decade in house where I was a managing director and global head of cyber privacy and AI, a leading bank. And through that role and through my role at Skadden, have had a lot of experience helping clients navigate difficult incidents, but also then complex cyber regulatory requirements, data regulated requirements and how they overlap with each other and need to be looked at on a global scale. So including the NIST regulations in the UK. So just a shout-out to NIST in the UK as well. We are obviously talking about NIST2 today, but I'll be dropping in a few points about NIST regulations in the UK, which people often forget about, but do equally apply and have some key pitfalls to look out for.

Thanks, Nicola. And now I'd love to introduce you to Susanne Werry, who's based in Frankfurt.

Thank you so much, David. Hello, everyone joining us today. As David mentioned, my name's Susanne Werry and I'm based in Frankfurt, leading my team here in Germany. Different to Nicola, I don't have the in house experience as I've always been a lawyer in global law firms, but I also do advise on European cybersecurity, data regulation, AI topics, including, of course, NIST2, NIST2 implementation across different member states. And just recently, I have quite a bit of hands-on experience with incidents handling another new regime. So I'm very much looking forward to our conversation today.

Great. Maybe we can just start with just a big picture question. Nicola, why has NIST become such a priority issue at the board level, particularly for multinational organizations?

It's a great question. Obviously, as I said, we are going to talk a lot about NIST2 EU directive that's been implemented over the last couple of years by the European Union member states, but also going to cover about NIST and the upcoming reforms through the UK Cybersecurity and Resilience Bill, which is also going to create some new changes here. So why does everyone care and why does the board level care? Well, I think there's three key reasons. And first of all, we have NIST2 to thank for that, which is it has introduced personal liability of management bodies, IE, board members. So there's an actual possibility that executives can be suspended from management role for gross negligence, can be personally fined if their entity doesn't comply with those cybersecurity regulations. And obviously there's points that happen at the point of breach and notification, but there's also requirements in terms of preparation for an incident that the C-suite need to be aware of and focus their mind on. It's an extraordinary provision. We saw it happen in the financial side with the senior manager's regime in the UK, and it really does make entities take note and somehow find the budget for these compliance programs.

The second reason I think is in short fines. So if you look at penalties, both under NIST2, the existing NIST directive, the proposed penalties under the Cybersecurity and Resilience Bill, they're big fines. For example, the proposal under the new UK bill is up to £17 million or whichever is greater or 4% of global annual turnover, which is obviously massive. And that's a huge shift for entities now in terms of their cyber resilience. It's not just the cost of the incident itself, it's also the cost of non-compliance and potentially facing a regulatory sanction.

I think the third reason is that it's no longer just an IT issue. So we know how much companies rely on tech as part of their day-to-day business for business continuity and solvency risk. And so therefore boards need to be engaged and have realized they need to be engaged with these regulatory measures because a lot of them actually just make sense in terms of justifying, obviously defending fines, but also justifying their approach to investors, shareholders, and in future litigation. So overall, it's a senior level topic. It's no longer just a thing that can be delegated to the CISO.

It's just a huge headache for companies that haven't begun to think about their compliance obligations in the UK and also in the EU. And I'm wondering if Susanne, just building on what Nicola's said, do you give us a sense for what's fundamentally different about NIST2 compared to the earlier frameworks we've seen in Europe and how organizations need to operate now?

Yeah. Absolutely. So I do think the most important shift is really in scope and accountability. I think accountability Nicola already touched upon, so I will start with the scope point. So NIST2 has massively expanded the scope of sectors and types of entities that will fall into its reach. Regulating cyber security for critical infrastructure is not something new. And that is what the original NIST directive focused on was operators of essential services just in a handful of sectors like energy, transport, banking, water, or digital infrastructure. But NIST2 now really goes significantly further to that. It covers a much broader range of sectors, just naming a few. They're much more waste management, postal services, food production, distribution, manufacturing of critical products, chemicals. The space sector is covered as well, just to name a few. And it also introduces a size-based threshold, which means that medium and large enterprises in those sectors are automatically in scope without the need for a separate designation process by national authorities. So it is the entity itself that needs to decide whether they fall in the scope or not. And if yes, they do need to register with the authorities. And the threshold that I just mentioned is actually quite low, so it really involves a lot more companies than the original framework.

Beyond that, I think a notable thing to highlight is that the reporting mandates are much stricter than before, the personal liability for leadership. And just to highlight one critical sector that is directly regulated by NIST2 is managed service providers and also data centers. So the last point is particularly important because it means that companies that provide the infrastructure that other businesses depend on are subject directly to NIST2 and have the same obligations as businesses they serve. And since we're of course also looking at the UK, just looking at what's happening there, I think Nicola, you can correct me if I get that wrong. The estimate is that somewhere between 900 and 1000 or over a thousand additional managed service providers will also in the future fall under direct ICO oversight. So that's a big shift for the UK as well. And there's also another unique UK power that is worth mentioning, which is the ability of regulators to designate specific high impact vendors as designated critical suppliers, regardless of their size and bringing them under that direct statutory duty.

And the concept, and that is what I also want to highlight from a European U perspective is that there is a similarity with regard to DORA. So we do know that that concept of oversight of specifically important entities, critical providers, that is something we do know from DORA in the U as well. So it's not just a UK approach. Just to highlight, the direction is the same that regulators are taking, which is that they do want to have visibility and control over the entire supply chain. And the fundamental philosophy that has shifted is that no longer it is about keeping the lights on, but really is about continuity. So the focus is on security of the services themselves.

Just adding on the UK side, obviously, as Susanne said, we're expecting a huge number of additional entities now being regulated by different regulators depending on the area they fall within, but within managed service providers, but also noting that data centers over one megawatt will also be directly within scope and specifically to secure digital supply chains. So all of this is around continuity of the UK economy and life here. The definition of reportable incident has also been expanded. So they've actually also now suggesting, or in terms of the new bill, if it's passed, the instance which are capable of having a significant impact must also be notified rather than it does have a significant impact if it's capable. And obviously we know from our roles, whether something's capable or not, well, in the outset, a lot of incidents will be capable of having a significant impact so that's really broadening the scope of what's notifiable. I think also what's really interesting in the UK is the government's proposed powers to designate critical suppliers, but even directly take over an incident if it's in the interest of national security. So almost could come in and direct a company if it falls within the scope of the regulation and take over the incident and dictate how it is run, which is an extraordinary power and something we've not seen before.

So this is earth-shattering and many organizations may have heard of NIST2, but we are starting now to see incidents that we take on in our practice for clients directly implicate this to obligations. We handle something like 30 to 40 incidents at a time when we're particularly busy and we are jammed right now. And I would say that this is when we're starting to see clients have to directly engage with these authorities. So let's dive into what really is at the heart of this episode. What actually happens when a cyber incident hits and there's a NIST implication. So Nicola, just given your experience, you comment on, we have to say we have a cyber incidence occurring, what actually changes under NIST2 in those first 24 hours?

I think, as you say, David, it's the first 24 hours. So now a big change is that you have to file an early warning to the relevant regulator, and then followed by a full incident report within 72 hours. A slightly different in the UK, it's without undue delay under the current law, but in relation to NIST2, that's a very strict obligation. Obviously, in terms of the first 24 hours of an incident, you're often trying to find, you don't really necessarily know it's happened. And there's lots of debate in terms of when did the incident actually occur? When was the incident and when does that clock start ticking? And the real struggle we see in practice is what we'd call analysis paralysis. So firms get stuck trying to confirm the scope of the breach before they notify anyone. They want to understand it themselves. They need to escalate. There's different people involved, but ultimately they have to get a lot of information together very, very quickly in order to complete this preliminary notification.

It can't be in relation to a completed investigation. They have to almost guess some of the answers and give their best view at the time. So you're basically saying to the regular, "We know something's happened. Here's what we know so far." You haven't got time to do an investigation before you speak to a regulator. You need to be open with a regulator that its happened. And how you word that is really, really critical to prevent further exposure in the future.

And this is really where theory meets reality. Just to give you some examples. So we recently dealt with a global incident that involved multiple entities across different jurisdictions. Not unusual, that's what we do. But for some of those entities, the client had already performed a thoroughness to applicability assessment and had already registered with a relevant national authority. But for other jurisdictions, neither the assessment nor the registration had been completed. And this is where the real practical challenges became apparent. Registration with some of these authorities is not something you can just do on very short notice. So Nicola mentioned the 24 notification deadline and the 72 hours. So it's just to give an example for Germany. When you want to register, you need to obtain a certain code by post, and that does take days. This is not something you can just get within an hour or so. And in addition, you need to have credentials ready to make your notification. And if the person who holds the credentials happens to be on holiday or is sick and just doesn't have access to those, you have an issue. And we also saw the same patterns in other countries.

So online forms, personalized, you need to have those credentials. Usually only available in local language, which means that in that timeframe, you also need to make translations because of course, as Nicola mentioned, the story is really important. So you also want to align between different notifications you do in different jurisdictions. And outside counsel sometimes cannot submit directly on the client's behalf. So you also need to get the client on board and do it together. So with that NIST2 is a new law, not all member states have fully implemented NIST2 yet. So the standard is different. You also need to understand in which jurisdictions you already have the NIST2 obligations and in which ones there is still the implementation ongoing. But what is already apparent from our practice is that authorities have a special focus on whether boards are genuinely involved in the decision making process and are informed throughout of an incident. So that is really something you need to consider and you need to be able to demonstrate to regulators that that's the case.

Susanne, thanks so much for those practical tips in a not so subtle subjection that a company shouldn't wait until an incident before they line up and arrange for these registrations and figure out their governance and whatnot, and probably something that needs to be planned in advance. Nicola, I guess for you, I'm curious, one of the age old questions in the fog of an incident is like, is it reportable? What are the facts on the ground and how do we make that assessment? Can you help us understand how companies are dealing with that as they think about this standard?

So I think the honest answer is they need to practice it. So it really depends on the entity involved. What's going to hit them and really cripple them as a business could be different compared to another company. So it's something that they need to sit down and consider what is significant for my business. So if this application goes down, is that significant? Can we do a workaround? What is that workaround? How quickly can we put that in place? And remember, this is all about operational resilience and continuity of service. So that's really what this regulation is focusing on. And if you can do that, then you're probably avoiding notifications. If you can just switch to something else within a couple of hours, there's not going to be any impact. That's a completely different situation from, I can't service my customers in this critical sector or important sector for the next five days, 10 days, or for however long.

So really, organizations are struggling because they haven't sat down and considered what significant means for them and their business, what those trigger points are, what are the most fundamental applications and technology stacks within their business. Another one of the most common failure points is siloed knowledge. So we often find that companies aren't really necessarily communicating across their different lines. IT might detect the breach, but they don't necessarily inform legal or the DPO, or maybe they do, but the business IT don't realize or one part of the business don't realize how much another part of the business really relies on it. So perhaps it's fine for one part of the business to lose this application, but that's feeding another application which the business really relies on. So in terms of internal communication, getting the right people up to speed, notifying the right people within that 24-hour window is quite a tall order. And often what we find is by the time they've done that, the 24-hour window has already closed.

The other tension, just to highlight, we're often finding ... We find this a lot with GDPR, but also with NIST, is around US parent company may instruct its European subsidiary not to notify because it's totally different. Maybe the SEC and they say it's not material, so we don't want to notify European regulator. This isn't a big deal for us. But the European threshold, as we've seen, they're quite low and so may have been triggered. We've got personal responsibility, liability here. And so it's not possible to just say to a EU board member, "Oh, just don't notify. You're personally liable if we don't, but just don't notify." Really need to practice that escalation and coordination across the different regulators because again, if you're notifying of an incident that could have impacted data and you're notifying it under NIST2, you probably also then want to do a GDPR notification as well. And then also think about how does that impact your position in the US.

Thanks, Nicola. For folks listening, whether you're a CSO or a chief privacy officer or another business leader, and you have to brief the board about these questions, often the hardest thing is how do you show the business relevance of a cyber incident or data breach? And I think one of the key sea changes with this regulation among others, frankly, in Europe, is that you have to look at the operational impacts. So when we're going through an incident and we're talking about all the developments in the daily algorithm call, one of the hardest ones to get answers on is what is the operational impact to the business right now? And that's what this regulation basically compels companies to do. So it means you need to do a lot of work early on to be able to track that and understand it. Susanne, I think it would be really helpful for our audience to hear just from a practical perspective, what does good look like when it comes to this escalation and decision making when you have that kind of time pressure?

Very good question. We get that a lot. So I think good really looks like having a trigger-based response plan. Nicola mentioned understanding what the trigger is for your company. But what I also mean by that in the trigger-based response plan is when certain conditions are met, certain type of incident is the certain level of impact that the escalation really happens automatically so that there is no need for lengthy debate or enormous discussions with different stakeholders, but really you can make decisions and the escalation plan just run smoothly and automatically and everyone knows what they're doing. As I previously mentioned, it also means that you know the forms, you know the processes in advance. You don't need to look up who would I need to contact? Who actually are my regulators? What's the website? So really knowing the process helps you speed up that situation under enormous time pressure. And the things I mentioned sound like administrative details, but these are precisely the things that derail notifications in the heat of the moment. And really that question around who is going to make that decision is the trigger met. That is something that you can preanticipate, at least if you have a detailed plan around that.

And there are two other things I just wanted to point out. The first one, Nicola just mentioned that privilege, I think you just need to have that in the back of your mind. You need to be thinking about how privilege applies to the discussions you are having, particularly also when you're engaging with external stakeholders and forensic investigators. And second, always also consider the ultimate litigation risks. How you characterize the incident in the early warning of the notification may be scrutinized not only initially by the regulators, but could be scrutinized month or years later.

And one of the things, just to flag, sometimes we see, Nicola, you referenced the siloing within an organization. Sometimes we see siloing even within the council and outside council. So they'll have their local council in Europe maybe going doing notices, but not necessarily coordinating globally. And so we always try to think about how do we have a global team to manage those notifications, so then you're ensuring consistency across the world. And you still may have to work with local councilors, as you all do from time to time, but it's coordinated globally by one team.

One thing I also wanted to, I guess maybe ask before we move on, any examples for us that highlight the gap between ... I think you guys have alluded to this, that the gap between having a plan and actually being able to execute it if you really do have a significant crisis, which is going to put a lot of people under a lot of pressure.

And I think just for the US listeners or for those of you who've been thinking about cyber instant response, instrument response planning in terms of state attorneys generally United States or federal regulators in the United States or data protection authorities, they're really coming from a totally different perspective than the authorities regulating NIST, NIST2. These are often ministries of interior ministries of defense, former intelligence focused organizations. They're focused less on the data, and they're going to go deep. And then the other thing I'll say as we talk about implementation, if you were to go in, let's just take the transportation sector, or if you were to go into the energy sector or financial services and to print out the regulation that exists in some of the countries that have implemented this, it's not a few pages with some operative paragraph or two. It could be a ream of paper. The regulations are extremely dense. So if you're thinking, "This is great, I'm putting this on my list." As you listen to what Nicola and Susanne are going to say next about implementation, this is not a, maybe we'll do this in Q4. It is probably a year-long activity, particularly if you have certain countries implicated. So as you think about the implementation piece. So with this in mind, Nicola, from your perspective, what are some of the biggest challenges organizations face when they're trying to become NIST2 or NIST ready?

Another great question, I think the keyword is holistic. As you said, David, this is not just, "Oh, do this in Q4. It's going to be a couple of weeks." It's a deep dive into all your policies and procedures. Susanne just said lessons need to be tested, not just documented, but they also need to be documented. And that is a key difference, a big cultural difference we find working with our US clients because they're often saying, "Yeah, well, we do that. Yeah, no, yeah, of course we have. We do encryption, we do MFA." "But oh, you don't have a policy on it." "Well, no, but why would I?" Well, because the European regulators require you to have a policy on it. You can't just say, "I do it." It's not enough. You have to have policies and so you need to do a deep dive as to, well, what do you have documented already? Does it make sense? Is it well written? Is it something you just got off the internet a couple of years ago and never looked at since? And it's also not a one-off desk either. You can't just do it in Q4 and say, "Okay, I'm done now for the next 10 years." You need to actually keep these policies and documentations up to date to show the regulators we did have appropriate policies and procedures in place.

And then once you've got them in place, that's sadly not enough, people across the organization need to know what the policies say. And as we've highlighted throughout this podcast, understand what the role is, how do they escalate to each other, who gets to make the decision, and then practice them. And in drafting these policies, it's also understanding your key dependencies, like what are the applications and tech stack that you really rely on? Which suppliers do we really rely on? You can't just say, "Oh, well, we outsource that, so that's not really ... Nevermind if they go down, that's not such a big problem." You need to be aware of that, map it all, have policies around it, have training around it, and be able to evidence that you've done all of that because this regulation requires you to do that, so you need to be able to evidence that you've done it.

So I think it's having these wonderful, beautiful instant response plans and other policies that NIST2 requires you to have and really thinking about how they apply in practice, so making them really effective, but then also not letting them sit on the shelf never having been rehearsed because that's not preparedness, that's not being ready.

All right. So assume now you've convinced me that we need to take this seriously and we need to do things. I guess still people from ... If you have a US vantage point, you may be thinking, okay, so there's some new reporting obligation. I can just add that to my incident response plan, flag it, and now I've checked that box. And it sounds like maybe that's not the way to be thinking about this. And maybe you can help us understand where, Dave alluded to these streams of paper, and it sounds like this is a bit more complicated, but maybe Susanne, can you help us understand where are companies still underestimating the effort required? Maybe taking that perspective that I just shared about, oh, another notification obligation, let's just add that to the list and move on. What are the real challenges when it comes to scope or governance or coordination?

Yeah. So there are obviously are a lot of points that companies are still underestimating with regard to NIST2. The focus, of course, is always with incidents notifications, but the starting point actually is to first understand if you are subject to NIST2 or not. So that exercise of scoping out, if a company is in scope and if yes, which of the individual entities are really subject to NIST2 is a exercise that takes time, takes resources. You really need to understand the individual differences in your company because you might have manufacturing entities, you might have distribution sales entities. Not every entity will be covered on NIST2, and there are differences, of course, in the member states. And that it was also makes and is too so complex that it is a directive. It needs to be transposed into national law. And there are some differences in the approach, especially in the scope. So you really need to make that exercise and diligently think about and not over include entities because of all the obligations that follow.

The expansive nature of NIST2 means that businesses that assume that were out of scope are now also discovering that they are covered sometimes only when an incident occurs. So just highlighting, for example, that in Germany, the deadline for registration past beginning of March, and the number of entities that the BSI expected to register has not been reached. So there is a huge gap between those entities that are expected to fall into the scope just in Germany and the number that has actually registered, there is a big gap between that.

On governance, the question that keeps coming is what role the board actually needs to play in all of this? In multinational companies with centralized IT functions, for example, the question becomes even more complex because the question, who is ultimately responsible and at what level of influence does the person and the board have, for example, over budgeting for cybersecurity measures? So the question is, the board needs to be involved in the budgeting, needs to know what level of cybersecurity exists at the company. But if you think about your centralized IT functions, what is actually the level of influence? What can they do? And therefore you also need to think about those topics. And the last point I want to highlight is supply chain management. NIST2l requires organizations to assess and also to manage cybersecurity risks of their suppliers. So for companies with hundreds of vendors, that also is an enormous undertaking to just map that out in a first instance and then to manage that in practice as well.

All right. So let's assume I just listened to this great podcast called Decrypted and I became convinced that I need to get my act together in this regard. Let's get real practical. So then I call you up and say, "Okay, I've become convinced I need to take this seriously. How do I start? What do I do to begin all of this program here?"

Good questions. I will tell you three things. Try to make this really short. So first, understand what you have. You cannot protect what you do not know about. So that means that a thorough mapping of systems, of data, of entities and services you provide that will fall on NIST.

2 is key. Second, get the right people engaged and on the board. That is really not just an IT project, as Nicola highlighted in the very beginning. Really NIST2 is a board level issue. It requires involvement also from legal, from compliance, from the board, and operational leadership. If those stakeholders are not aligned from the start, then the subsequent steps will be really hard. And the third thing is leverage what you already have.

A lot of organizations do already have certain standards in place. For example, if an organization holds an ISO 2700 001 certification, that of course is not everything and it's not the absolute standard to comply with NIST2, but it is a starting point. So it is a very good starting point actually, and it gives you a framework that you can build on so you don't need to start from scratch.

As you listen to what Susanne just said, and before we get even more practical on what it does mean for incident response, you're probably thinking about not just cybersecurity, but your broader business continuity, you may be thinking about insider threat in your organization, maybe thinking about your AI program. All of this is implicated by NIST2 because you have to think, as Susanne was saying, about where your technology is. Cybersecurity is a luxury for companies that know where their technology is. And most organizations, whether they like it or not, are building that AI skyscraper on top of styrofoam. You need to know what that styrofoam is. You need to understand where your assets are, where your data is, where your technology is, otherwise you can't be compliant with this. And so I want to ask this question, Nicola, when we think about incident response, but just to thread in, there is that personal liability piece.

When you brief a board and say, look, you are personally liable. If things don't go the way that we're supposed to go, how does that really change things when companies are thinking very practically about steps they need to take to be ready for when an incident actually occurs?

Well, hopefully it means those board members will attend the tabletop, right? They're going to be personally liable. So I have definitely seen that shift. We used to do tabletops and we've done tabletops ever since I've joined. And sometimes they're well attended and other times they're not. But actually what we're seeing with NIST2 and DORA regulated entities, if all of a sudden those board members want a piece of that and they want to practice it, and if they don't, then they should. So what makes a difference on when an incident occurs is having had that practice and having that senior sponsorship engagement as part of that practice, having the relevant stakeholders in the room, but also don't let the CISO draft the tabletop and then just test themselves because it's like testing their own homework. The most effective tabletops I've seen are the ones where an outside council do it, they test them, the CISO's part of the game.

They get to play along as well. And really, don't just talk about it in theory like, "Oh yes, I would do this, but really how would you do this?" Like what Susanne was talking about, again, not to HarperBond, but the login details, because that happened in a real instant we've been advising on is really so you have the details. And do you know who your regulators are? I mean, we see this on GDPR, who's your home state EU regulator? Oh, I don't know if we did an analysis on that. Did we do an analysis on that? Or for a US entity, who's your authorized representative out of all these EU companies? Whose name are you going to do this notification in? Oh, I've never thought about that before. So it's great to have the opportunity to play that out in a tabletop rather than the stressful situation in real life.

So now you've been convinced that you need to do a tabletop exercise. The focus is on this too. You're all going to do one each year, right? We all have that plan, but it's hard to schedule those. So you're going to cover NIST2. I think one of the things we need to just, as we look at closing is what are your core practical takeaways? And I'm going to throw one out before I turn to our experts. You've been hearing a bit about privilege, and again, it's self-serving for lawyers to say, but when you have a 24-hour notification to an authority that's going to ask if you comply with a whole series of requirements and there's personal liability attached, that means that you need to bake in not just talking to your internal counsel, but outside counsel early. And remember, for most countries in the European Union, there's no legal privilege that in house counsel can establish.

So we are written into incident response plans because they want to establish legal privilege through outside counsel for the European entities, for your global organizations. This is the case. So you got to get your outside council involved very early on before you start communicating about an incident reporting obligation and engagement with authority. So for that initial key takeaway, I want to turn to Susanne to share your take. If you have two key takeaways from today's conversation, what would they be?

Yeah. So first, cybersecurity is now a governance mandate. Executive liability and turnover based fines mean that cybersecurity is as heavily regulated as, for example, financial reporting. If your board isn't treating it that way and with the same level of seriousness, you really are behind. And the second point is do not wait for an incident to find out whether your plan actually works or not. Test it, assign those credentials, translate the forms, run exercises. The time to discover that your reporting platform requires a postal code sent by post, that is not something you want to find out at two o'clock in the morning during your ransomware attack.

So I'm going to have to, but I also want to just follow up on one of David's points. So I'm going to have two and a half key takeaways very, very quick. But also David talked about again, legal counsel engaged, but also engaging your vendors under privilege too, because that can be incredibly powerful. And in fact, we have experience of quoting privilege on an incident report to a regulator and it being accepted. So I think it's a really important point in terms of engaging. Obviously everyone wants to get friends again really quickly. You might have them under retainer already, but actually think about getting them under that retainer in advance engaged via legal counsel. Again, maybe I'm bound to say this, but we have got real life experience of a regulator asking for an incident report and we said "Well ... And we'll have it just in draft." And we said, "Well, that's privileged." They didn't just accept it straight away. They came back to us, but after a bit of debate, they did accept session of privilege on that.

But one of my two quick tips is take near misses and make sure you don't just ignore near misses. Near misses are warnings. So just because you had an incident that didn't crash all your systems or because you had a data breach and maybe the ICO or one of the EU data regulators didn't really follow up on it, doesn't mean that they wouldn't the next time. Use it as an opportunity to strengthen your defenses, emphasize it, make sure that you're looking at your policies again and thinking about lessons learned in relation to that.

The other thing that I'd also highlight is the 24-hour clock. Now we've talked about that. If you're a listener and you've had an incident, you'll know how quickly and how stressful those first 24 hours are, but it's at the moment you become aware of the incident and not the moment you have all the answers. And if the new UK law and current form passes, it will be if it's also capable of having an impact. So that is super early. So really understanding the distinction and making sure that in turn, you've also got those escalation lines. I've worked in house, I've had the tickets flagged to me and you had the different categories. And how do you know whether a category four is going to, or category one, however you rank it, is going to become significant? It's hard to know, but make sure there is something so someone is assessing that so that ultimately you can make those reporting obligations.

So if you take one thing from our discussion today, it's probably the 24-hour clock, but the second thing is probably the personal liability hook. This is a theme we're going to be focusing on in the Decrypted Podcast about executive liability, about the practical ways that you implement this. But now looking out over the horizon, now we are doing this on a monthly basis. You'll be hearing from us on the Decrypted more deep dives into key regulations. We'll be talking about the cyber and privacy angles related to the AI Act, the Cyber Resilience Act, the Data Act in Europe. We'll be focusing in one of our next episodes on the critical infrastructure reporting obligation we started talking about with one of our colleagues, Joshua Silverstein and what that means and we'll be having some expert interviews. So look out for some extraordinary interviews from key opinion leaders. Thank you for joining us on Decrypted and we'll look forward to speaking with you next month.

If you're enjoying Decrypted, be sure to subscribe in your favorite podcast app so you don't miss any future episodes. Additional information about Skadden can be found at skadden.com. Decrypted 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.