Transcript: Data breach readiness - Key trends and how to spot red flags

Transcript

Monika: So welcome to the July session of our legal academy and today we've got with us our digital and data team who will be chatting to us about data breach readiness.

I'll hand over directly to our digital and data team for intros and to take us through today's content. Good morning, everyone.

Lily: Thank you. I'm Lily, a senior lawyer in the digital data team of Peter Guy London and I'm joined by my colleague Shivani and today in today's session of the Client Legal Academy. We are actually delighted to be here and talk to you about a topic that is increasingly at the top of every in-house rights agenda, and this is data breach readiness and how to support the red flags before they even become a crisis. Working with clients in many sectors such as retail and financial services, TNT and others, we've seen firsthand not only how quickly seemingly minor issues can escalate into a full-blown incident but also how critical it is for legal teams to be proactive in this space, not just reactive. The regulatory landscape is evolving rapidly indeed, and the reputational, financial and legal consequences of a poorly managed breach can be actually quite severe. Our goal today is to equip you with practical tools to spot the early warning signs and to ensure your organization is ready to respond effectively.

I am now handing over to Shivani for the agenda of today's session.

Shivani: So, the agenda I said before, we will start off with explaining why it is important to be proactive. And then Elaine, our colleague from the cyber incident response team, will talk through some key themes from the bombing threat landscape. We've got some scenarios for you today where you'll have a chance to identify red flags and we'll then talk through how to tackle them. And then we'll give an overview of cybersecurity and resilience regulation in the UK and EU and then wrap up with some takeaways. But before we do that, as I mentioned, we've got some interactive elements which we're hosting through Slido. So, it'd be great if you could either scan the QR code or join through the link on the screen and enter the code. So, I'll just give everyone a few minutes to do that and then we'll kick off. Great, so just do some quick introductions before we dive into the session.

Lily: For those that don't know us, the PWC digital data team advises clients on digital laws and regulations, and we have a particular focus on data protection. We are frequently advising governments, regulators and of course businesses on how to drive responsible innovation in data and the digital ecosystem, reflecting maybe the global nature of our plan base, our service offerings include basically all areas of digital regulation and this includes UK EU GDPR, direct and digital marketing, rights of data subjects and of course AI, the key topic, and Elaine will talk about the cyber incident response team.

Elaine: Hello everyone. I'm Elaine. I'm a manager in the cyber incident response team here at PEEC. So, our cyber incident response team is one of the MCS CIR enhanced providers, so one of the few in the country who have that level of qualification in order to respond to cyber incidents. And, you know, in a nutshell, what we do is we help organizations prepare for, respond to and recover from cyber incidents. So, this includes data breaches but also things such as ransomware etc.

Shivani: So, we'll now explain why it's important to be proactive with data breach readiness. So recent high profile data breaches have shown that it's really important to keep cybersecurity and cyber resilience front of mind. And the UK Information Commissioner recently warned organizations that they risk being liable to penalties if they don't implement appropriate security measures and that's because these are key to breach prevention.

Data breaches also continue to be a relevant issue for a lot of businesses, which is why again breach readiness is important. So, the recent cybersecurity breaches survey showed that 43% of UK businesses have experienced a cybersecurity breach or an attack over the past year and the kind of relevance of the issue was also reiterated by the National Cybersecurity Centre CEO who commented that cyber threats are a very real issue and it's not just hypothetical. We'll have all seen the recent attacks in the retail sector and there's some suggestion that certain actors are moving from sector to sector. So, this continues to be a topical area and also an area of concern for a lot of businesses.

Breaches can have reputational, legal and financial implications and the costs continue to be quite significant. So, on the slide there you'll see we've put costs which are directly linked to a breach over a 5-month period. So, it's particularly important to think about what steps you can take to prepare for these.

Elaine: Just going back to recent attacks we've seen, so typically threat actors, they'll go after who's the easiest target. So, if you've got vulnerabilities, they'll just go after the vulnerabilities. But recently we've seen the scattered spider group with the recent retail attacks go after one group at one industry at a time, so they were after retailers, then they went after insurers and then they are going after airlines. Luckily in that case it looks like a few of those individuals in that group have been arrested recently, so we'll see how that impacts the operations of that group. So, moving on to the evolving threat landscape. We've got a quick slider for you, so which cyber threats are you concerned about? We've mentioned some already but are there any others that you want to say, or you can say the ones we've already said.

Thank you, so we've got data theft coming up. Phishing. Impersonation. CEO fraud. This stuff's got bigger, so I assume there's more than one person who said that. Yeah, so these are all good examples of different incidents that might happen. A lot are used in combination. So, for example, you could be phished and then ransomware could happen or data theft after the fact, so there's lots of different things that could happen and not all in isolation. You've obviously got, you know, sort of classic taking advantage of an exploitation, but a lot of the social engineering which is just tricking people into giving data or money, so some need high levels of sophistication in terms of technical capability. Some really don't. So, you've got all these different types of threats to watch out for and obviously someone's put AI deep fake on there, so as we see, you know, AI is getting bigger and bigger and that will be interesting. From a threat intelligence perspective, we have seen threat actors using AI in social engineering, so definitely one to keep watching out for. OK, so to talk about the evolving threat landscape.

So, we see that from a threat perspective, this changes all the time. You know, you go back 10 years, we were looking at completely different threat profiles than we are right now, so this changes quite dramatically over time. One of the things that influences this is the geopolitical landscape. So, we've seen recently, we're moving to more conflicts, more conflicts in the world, and this also changes how threat actors behave. So, you'll have some of these like sort of cyber warfare going on and people trying to steal different intellectual property and we also see that this changes behaviour. So for example, if we take, you know, there's a lot of criminal threat actors in Russia, they can't be extradited from Russia to the UK so we struggle to actually, we might know who they are, we might know what they're doing, but they can't be extradited and arrested, unlike the ones that I mentioned earlier who were UK and US based who we are able to arrest - so that can influence things from a geopolitical standpoint. You've also got, for example, if you take North Korea, they often operate in terms of almost like a criminal organization themselves in stealing money and ransoming organizations, again looking sort of nuclear IP and things like that as well to steal. You've got different types of threat actor. So, when you go through, you've got, for example, APTs, advanced persistent threats, which are usually state actors. So, unlike I mentioned North Korea they're trying to get money, but a lot of the majority of other states threat actors are there trying to get data, you know, they're interested in what their other countries are doing, why they're doing it, you know, they're interested in military technology, all sorts of different things. So that's how that group tends to operate and particularly if you look at the different countries, each country has different ways of operating around how secret they are about what they're doing. Then in that group you get things like the criminal threat actors, mostly these, they're just financially orientated, they want money. So, I'll touch on the ransom as a service next, but you do get quite a few who are just trying to sort of steal data to resell it, you know, and identity theft, that sort of thing, to get those sorts of personal details from people. Then you've got sort of different threat actors that are less proficient, so for example hacktivists, they might try and hack for a, you know, let's say they're very pro-environ, they're trying to hack say an oil company for example. So, you'll get them doing stuff out of political, you know, ideals. So that's another type of threat actor. Then if we move on to sort of ransomware as a service, so this is something that's been around for a few years now but wasn't around particularly much before that. So, this in the case is a threat actor might be really good at writing ransomware, but they might not be very good at getting into your network or they might not be good at exfiltrating data. So, they'll write the ransomware, and they'll sell it to another threat actor who might be better at those other things in return for say 5% of the ransom, 10% of the ransom. So, this is quite common that you've got multiple threat actors operating and they're all doing what they're best at. With ransomware, we're also seeing obviously this double extortion technique, which is quite common in terms of the lock all your systems, you can't operate, but they're also stealing sensitive data in order to try and persuade you to pay the ransom. So definitely massive data breach concerns in that one.

Moving on from that, the commoditization of cyber tools. So again, this is when we're saying, oh look, certain people are very good at one particular thing and they're selling their capabilities to other groups. So, on the dark web you'll just have, for example, I've got this really good tool, I've made this really good tool, I'll sell it to you for a cost, and you can use this tool. So just because the contractor isn't very good at exfiltrating data, they can buy a tool to support them with this on the dark web, so it is really operating a bit like a marketplace in terms of the tooling available. So, we do see, you know, lots of attacks where there's multiple threat actors in the environment because they're working together in that sort of way. What we've also seen in the last few years is a move from traditional defences. So, it used to be you'd have this perimeter-based defence idea. So, the idea of that was, you know, you keep your perimeter secure, you make sure no one gets into your network, after that you're safe, you trust everything inside your network. And the root of the problem with that is

That, you know, once they're inside, they can move around fairly freely. So in the last few years, that's changed because we've had like a lot of change, we've got a lot of SaaS based applications, we've got a lot of people working remotely, all of these different things, which makes the perimeter less secure and therefore you need to have this sort of zero trust method which means you don't necessarily trust your network already. So, this leads to sort of network segmentation, those sort of different ideas in order to have this zero-trust approach. So that's changed the way we look at security and it's also changed the way we act. This is also in turn meant that, sorry, criminal actors and cyber criminals are looking for different ways around these newer techniques that we're using. I think a big thing here also to look at is supply chain dependencies. Now that's including managed service providers. Now, as we've continued, more people are outsourcing a lot of their IT, they're outsourcing, just they've got other third parties in their networks separately as well, just from a supply chain perspective. Now in the last couple of years we've seen a huge number of people breached through their managed service providers. So essentially, they haven't done due diligence on their supply chain. I think we had one, we had one case, so this organization, they were ransomware and it came through their managed service provider, the director, and we looked into the managed service provider and this managed service provider was like three people in a basement somewhere with some servers and they hadn't really clocked that they weren't a very good company and they weren't a company that was doing the proper security on their systems. So, you know, you need to be really aware of what your third parties are doing, that your supply chain is also resilient because, as a managed service provider, they'll have access into your network in some manner, which means that they're breached through so they can quite easily move into your environment. So that's something that needs to be carefully considered because obviously that opens you up to more of this data theft risk. Yeah, so that's for that one, can you move on.

Lily: Moving on to another interactive section of this session where we will walk you through the scenarios that illustrate some of the common red flags. So, the first scenario, imagine a university that is using a third-party provider to deliver training to its students. This third-party provider hosts and stores all student details and uses single-factor authentication to protect the data. The data is hosted in the cloud and the system logs are reviewed manually once per week. Using Slido, can you vote on any possible red flags in this scenario? Just give him a couple of seconds for people to vote. They were like, good night, good note. I won't talk about my knife connection in my legs. Nice collection, collection to the next stage. What surface. OK, so we can see the Single-Factor Authentication got 100% and then hosting data in the cloud and manual review of systems logs have got more than 86% each. So, the red flags here would be the single factor authentication and all of you found that, and the manual review of system logs. So, let's break down red flags here, first of all, single factor authentication, this is a significant vulnerability. It makes it much easier for attackers to gain access to the network as it means anyone with a password can essentially get in. There's no second layer of security like a code into a mobile device or authentication app, but there's more here. The provider reviews system logs manually and only once per week. So, if, for example, there's any suspicious activity like unauthorised logging or a data export, this could go unnoticed for days in the world of cybersecurity, and that can be a very long time for an attacker to have access to sensitive information. So, what can you do to address these risks, and there are 4 key areas to focus on, due diligence, contractual safeguards, audit procedures and technical controls which Elaine will talk about. First of all, due diligence. This scenario highlights the importance of robust due diligence when selecting third party providers. So, when talking about due diligence, what are the main things to remember? Always ask probing questions about your providers' data protection framework and security protocols. Use an internal risk classification system to rate providers from low to high risk and of course, don't take assurances at just face value, dig into the actual details. Secondly, the contract in place with the third-party provider is also very important, what do you need to remember here? Ensure your contracts include appropriate provisions on data protection and cybersecurity, in particular, look for audit rights and clear obligations of the third-party provider to notify you of any service disruptions or general irregularities. In addition, you need to build into that any relevant regulatory reporting requirements including timelines for notification that align with your own legal obligations. Include flow down obligations and equivalent protection language for any sub-processors that the third-party provider might be using. And pay very close attention to the allocation of liability, this includes limitation caps, indemnities and how cyber insurance will interplay, for example, you may need to consider indemnities for breaches caused by failures in the provider's framework. Finally, don't forget about termination assistance and any possible data migration safeguards to ensure continuity and security in case you need to switch providers. Moving on to the third item of the slide, audits, consider conducting pre-emptive audits if you have any doubts about a provider's third-party security posture. And don't forget to always carry out audits after the incident to understand, first of all, what went wrong and secondly, how to prevent a recurrence. I hand it over to you on the technical controls that can help tackle the red flags.

Elaine: Yeah, so there's technical controls in place as well. So, this will typically be managed by your IT or cybersecurity teams but it's good to have visibility of what these are as well. So, when we're looking at preventative, this is things like firewalls, antivirus, multi-factor authentication, linking back to that previous scenario, encryption, those sorts of things. So that stops threat actors, for example, being able to get into your network or having access to move around your network to start with. Then you've got detective controls. So, for example, security information event management systems. So, these take telemetry from the different applications and systems in your network and hold them centrally and then there's a bunch of rules on these systems that you can put in place. And based on these rules, they'll send alerts to your security team who can then respond. They can then see what's going on and there'll be an alert if something is going on that's a bit untoward or looks a bit odd, that might be a security issue. The main thing about this is that, you know, the rules are tuned properly to ensure you don't get overwhelmed with alerts so that you ignore things, but you don't get so few that you don't see what you need to see. Then you've got response tooling. So, this is tooling that can automatically respond to incidents. So, for example, you can automate if someone's doing this malicious action, you should stop them doing it. So, you can automate certain things to stop actions being undertaken by threats or just an ordinary person within your organization. So, the big thing to talk about here is data loss prevention tooling. So, this can stop data being lost, essentially, and that can block data leaving the organization and can block data being copied onto a USB, for example. So, this can be quite helpful with the whole data breach area. So those are some of the sort of technical controls that can be in place to help limit the risks here.

Shivani: So, we've now got another scenario for you to vote on. So, in this one, an employee works for a retail company and the company advises its employees to update their passwords regularly. And this employee only makes slight changes to their password each time, so they just add a letter at the end. One morning while checking their emails, the employee notices that their inbox is loading slowly and some emails have been sent from their account to customers, urgently asking them to make payment to confirm orders. The employee thinks it's a bug and deletes the sent emails. So, I'll just give you a few moments now to vote on which you think are the red flags.

So, it looks like we've got quite a few of the responses now, and most of the red flags were identified correctly. So, the red flags here are the slight updates to the password, the emails which were sent asking for payment, and the employee deleting the sent emails. Box loading slowly on its own, thanks, Joan, is not on its own a red flag here, because this could have been due to Wi-Fi issues, but the other points are clearly pointing to either a data breach happening or something which led to a vulnerability, for example, the slight updates to the password.

So how can we tackle these red flags? So, part of the issue here was that the employee wasn't able to spot the signs of a data breach and awareness can really help with reducing the risk of data breaches because employees would be able to spot the signs and take steps to reduce that. And annual training is a really important part of that, and you can include interactive elements and test elements as well, just to confirm their understanding. Raising awareness is not just a one-time effort, so having flyers and prompts available to employees throughout the year will help cement that understanding.

Privacy champions also play a crucial role in supporting legal and IT teams with raising awareness and they can carry out regional campaigns or team specific campaigns to topple awareness and also give that on demand guidance where it's needed.

The other issue that we've seen here is that the employee isn't following good security practices in the way that they're dealing with updates to their password, and having guidance can help reiterate what you should do on a daily basis. So, for example, having data protection principles and security principles centred in individual policies can help provide a reference point to employees, so they can refer to that in the breach readiness space, but also just to reiterate good data hygiene. A breach response policy is also crucial because employees need to be able to know what they have to do in a breach and who to escalate to if they do spot the signs or have any concerns. And having an incident response plan is also crucial, and I'll now hand over to Elaine to talk through the elements of that.

Elaine: Yeah, so it's very important to have an incident response structure and plans in place. So, a good example here is I did a post report for an organization, they had a massive incident, and they did have planning in place. They did have a response structure in place, but the point that they had a problem was the escalation. So, everyone escalated to this one lady who happened to be on holiday, and she didn't come back for a week, so nothing really happened for a whole week, and they didn't respond for a whole week, which was firefighting and people doing nothing was coordinated. So, they didn't actually have a good response. And obviously, as such, the impacts are a lot larger to the organization, the financial in particular, I think they also had some regulatory impact there as well. So, you know, it's very important to have your response structure in place, have a resilient response structure to make sure that if one person is on holiday or not available, that it will still work. You need to have the right escalation procedures in place, and that should be down to also the severity of the incident. So, if it meets this severity level, it's a P1, it needs to go to the gold team, silver team, etc., so that individuals know who to escalate to and when to escalate. Otherwise, you can get this risk that people try and deal with it in the IT security team space, particularly for that one, I've seen that people undertake containment activity without asking for permission, and then massive business impacts for something that wasn't actually that important. So that's a big risk there. Roles and responsibilities, ensuring that those are outlined is very important because otherwise you end up with people duplicating efforts, so people doing the same thing or things being missed. In particular, it outlines who needs to do what for different things. Occasionally you get this where organizations, they're like, oh it's a cyber, deals with it. So that means cyber then tries to do the legal stuff as well, which never goes well. Cyber experts are cyber experts, they're not legal experts, I'm certainly not a legal expert. If I tried to do your job, I wouldn't do it very well. So, it's very important to have those responsibilities defined, those escalation structures defined, so that incident when it comes in and it needs legal input, it gets escalated up to silver and silver brings in legal. If we're talking about the gold, silver, bronze structure, obviously some organizations have a different structure. So, then legal's brought in and legal can do the actions that they need to do and consider regulatory, etc., what we've already discussed. You need to have the right system in place, so typically what you have is you tend to have an incident response framework across the organization that shows the escalation structures, the response, escalation response structures, severity matrix, roles of responsibilities, etc., and then on top of that you can have incident specific or team specific plans. For example, in a cybersecurity team you might have a ransomware run book, which is all the technical actions they need to take in response to ransomware. It can also mean having a cyber legal playbook that goes through things like legal privilege, if you know that that is applicable to you, where it's not applicable in all countries. It goes through different regulatory requirements, who is responsible for coordinating with each regulator. A key thing I've seen a lot as well is communications not being coordinated effectively, so the organization, someone goes off and talks to the regulator and says one thing, whereas customers are being told another thing and the markets have been told another thing. So, if you do have any communication responsibility within legal, make sure that it's coordinated with your comms teams, that you're coming out with the same talking points, because otherwise that can lead to difficulty. The other thing is obviously that what you are coming out with to regulators is accurate. The one thing we often see is that the regulator will ask technical questions, and your technical teams will be absolutely slammed trying to deal with the incident, and you can't get hold of them to answer those questions. So, a lot of that can be just holding lines, just saying we're finding out for you, we don't have time at the moment, but just keeping that open dialogue there. The worst thing is to not communicate at all. Then exercising, so all of these plans are all well and good. If people don't read them and they don't understand them, then it's not going to work. So you need to exercise so that individuals understand what their responsibilities are, they can work through any problems with the plans because it might not always work out properly in practice and things might need to be changed and that you build this muscle memory so that when you have, you've looked at this, you've got it, you understand it, so you don't have to look at the plan as much when it's actually an incident, and people get comfortable in their roles and they can just understand what's going on and how it would actually feel in a real incident, because obviously all of that pressure, if it's a big incident, can make people stressed and that can make them make unusual decisions. So actually, practicing that first makes them think through that in peacetime, which makes them more comfortable when an incident actually occurs, how it is supposed to work. So, we've got here a little slider ball on tools we can use to prevent breaches. Could you please rate the following options? Which of these would you find, for example, most helpful in preventing breaches, you can select multiple options and if you can please rank them in terms of priority, which one is the most important and helpful? Just giving you a few moments to do that. It's changing a lot, I think. OK, so should we take a look at the results and again the rank here in terms of priority at the top you'll see incident response strategy, which places the highest priority. Next is data protection by design, by a small margin as I can see, policies, incident response playbook, and the last one is testing and periodic review. Of course, all of them are correct and all of them are equally helpful in breach prevention. Of course, it depends on the priorities of this business, but generally speaking, incident response and crisis management is all about making sure your team knows exactly what to do if a cyber incident or data breach happens. This could mean having clear plans, knowing who's responsible for what, and being ready to act fast so you can keep things under control, and of course meet any reporting requirements. So, what are the key things you need to consider here? Implement appropriate policies in your business, including around technical and organizational measures and access management, for example, embed data protection and security by design and by default, and this should be across all product and service life cycles. It's also useful to develop cross-functional playbooks that bring together all relevant teams, as I already mentioned this could include IT, legal, PR, HR, and of course, any executive teams that need to be involved. Everyone needs to know their role when the clock is ticking. Have a strategy also for regulatory notifications. Remember the 72-hour GDPR rule, the need to timelines, as well as any sector specific timelines. This can also include planning for preservation of evidence and what your privilege strategy is. Understandably, this is very important when working with law enforcement in order to protect your business's legal position. The other thing is regular review and tabletop exercises. So, like I said before, it's important to build that muscle memory. So, if you look at all the plans the government has for different things, a lot of them are that thick, which means you're never going to read that in an incident. The point is you're not supposed to. You're supposed to practice it and train it so that when you're actually in an incident, you know it and you have to use it for reference. And yeah, I think a big thing for the tabletop exercising is you can start with facilitated walkthroughs, just sitting down and running through the plan, just verbally. Build up to having a bit of simulation in there, so different people getting different bits of information, build up more text messages, phone conversations coming through, and really you want to get to a place where you can have a multi-team exercise so that different teams are working in parallel, so you can test that and you can test out the communication is moving between each team and realistically, those big exercises are generally very, very helpful for organizations.

Shivani: So, we'll now give a brief overview of the cybersecurity and resilience related proposals in the UK and EU. So, starting off with the UK cybersecurity and resilience Bill, this bill is due to be published in Parliament this year. A policy statement has recently been published, and that's outlined the government's priorities and additional measures. One of the key points of this is that more entities will be brought into scope of the existing cybersecurity requirements, so particularly managed service providers. And earlier you would have heard Elaine mentioning supply chain dependencies and that supply chain risk is still very key to mitigate for organizations, and the policy statement recognizes this by requiring entities to follow certain duties when engaging suppliers, so this can look like having contractual requirements in place and carrying out periodic security checks. There's also expanded reporting requirements, so in some cases where incidents have a significant impact on providing essential and digital services, or if the incident impacts the availability, integrity of systems, then these will need to be reported. A tiered reporting structure has been proposed, so organizations will have 24 hours to make that initial incident notification to their regulator and the National Cybersecurity Centre, and then they should follow that up with a report within 72 hours. There's also increased powers for regulators, and this could look like having powers to request information but also enforcing the failure to register. So, the other point with the cybersecurity resilience bill is it's trying to update the existing framework in response to the current cybersecurity challenges, but also to update that in line with the EUISI directive, which I'll go on to now. So, this directive is in force and the key change that it introduces is it divides entities into two categories, so essential and important. And that distinction is relevant because it affects the level of review from supervisory authorities, regulators, and the penalties. So, in particular for essential entities, they'll be subject to proactive enforcement, so random security checks and audits, as well as enforcement when there's been non-compliance. For important entities on the other hand, it will just be posting the events when there's evidence of non-compliance. The penalties for essential entities will also be higher. The focus of the directive is for entities to implement cybersecurity risk management measures and also to report incidents which have a significant impact on their ability to provide services. The cybersecurity risk measures can include having measures such as business continuity measures in place, as well as incident handling measures. And what's important to note is it also introduces personal liability for management, as it gives management bodies this responsibility to look at what measures are being put in place to oversee their implementation, which is why they'll be liable if that isn't implemented. So, you may have also heard about the EU Digital Operational Resilience Act, and this is in force. So, this focuses on improving financial entities' ability to respond to and recover from incidents, and it also applies to ICT service providers. The key focus is managing that ICT risk and the way to address that is to have governance and control frameworks, so this can look like allocated roles and responsibilities, which we mentioned earlier as being important, but also having a strategy in place as well. So given the focus of risk management, a system risk management process is important, and that should involve tools and policies so that organizations can identify, monitor and detect risks, and also, they need to have this ability to carry out regular tests as well. As is to be expected, there's also reporting and notification requirements, so where there's a major ICT related incident, organizations will need to report that. So, it's important to bear in mind that there will be additional reporting obligations here.

Elaine: Yeah, and then going on to the ransomware related proposals, so that's specific to ransomware. So, this one, they had it open for consultation, I think the consultation finished in April. We've not heard any more since then, but I imagine they'll make an announcement on it fairly soon. But the intention of that proposal is to prevent payments by government bodies and critical national infrastructure providers, to prevent them making ransom payments as a whole. The more you pay ransoms, the bigger the problem gets because the criminals know they can get money, so that's the idea behind that a bit. Guidance on making payments for other types of businesses around that, and then mandatory reporting. So, I think the key thing here is that currently we don't have visibility of who has paid ransoms, who has not, we don't have total numbers, we don't know what types of organizations, small, medium, large, in terms of how many people are hit by it. A lot of its kept quiet. So, reporting would allow that data to be collected, and that would help with actually preventing the ransomware attacks in the first place in terms of giving guidance to different organizations and actually just give a visibility of how big a problem this is. I would assume in the mandatory reporting that they would probably ask around data breaches as well, but that's to be confirmed. OK, moving on to the key takeaways then. So, there's 3 lines of defence really in this, so process, technology, and people. So in the process area we looked at governance, so essentially having governance over your cybersecurity program to ensure that the items are put in place and that things are kept up to date, managing that risk, so I've seen most of you and organizations that have risk registers and rank risks in terms of how important they are in order to allocate budget, etc. So, understanding the risk to cybersecurity, risk tolerance and what needs to be spent or what the tolerance is in terms of spending in order to mitigate that risk. Otherwise, accepting certain risks as well. And then, response to ensuring you have the right plans and playbooks in place, policies, etc. so the right processes have been planned for, and that they can then help you enact the mix areas and incidents. Then we've got technology, so you've got your secure infrastructure and platforms, so just making sure they're secure by design and that everything is implemented to make sure that those are robust, so good patching, etc., those sorts of things. Then tools, making sure the correct tooling is in place that firstly you can see a data breach incident because plenty of them happen. The first thing you know about it is if it's on the dark web and no one had any idea. So, seeing those data breaches is a great first step in order to like can then be raised and escalated appropriately and the relevant individuals can handle the response, but then also those automated tools to respond, to prevent incidents occurring in the first place. Then people, so making sure the roles and responsibilities are defined, so ensuring that everyone knows what they are doing and there's no duplication of effort, things aren't missed. The right training is in place, so people are aware how to prevent, detect and respond to cyber incidents. Training should be obviously organization wide, the awareness piece, but key individuals get key individual training that they need in order to lower that risk for the cyber incidents and just making sure that it's not just an IT problem because we have seen many, many organizations where it's, oh, that's an IT problem. Oh, that's a cybersecurity problem, it's an IT problem, which means if this happens, IT security ends up dealing with it alone, and that really doesn't work because they don't have the expertise of the rest of the organization. So, it's obviously different from a small incident to a large incident. If you see a small incident, you'd still probably want legal etc. involved for the data breach angle for the regulation, but this is particularly damaging in large incidents in that, in a large incident, you need to have key decision makers involved, you need to have that response process, but typically what we need, we do see the requirements. We see there needs to be IT and security pillar, whether that's separate or together that needs to exist. You need a communications pillar that's dealing with all the communications out internally and externally, that you have a legal regulatory compliance pillar. So dealing with the regulators, your legal risk, contractual risks are also a big thing in a lot of these things that you're not meeting contractual obligations, so to look at all of these different items from a legal perspective, some of those individuals from a legal perspective may also need to be supporting the exec, ensuring that external legal counsel's involved to advise the exec if there is, for example, a ransom payment because you'll have sanctions, that sort of thing around that as well. So very key that that's all-in place. Then generally you need a business operations pillar, sustaining operations, whatever you want to call it. So that is if it is having a business impact that they can continue with their business continuity workarounds, etc. to ensure that the business can continue while the incident is dealt with. So big, large incidents, you really want to have the business involved and not just leaving it with cyber-IT because they are generally excellent at what they do, but what they do isn't comms, it isn't legal, it isn't making those exec decisions, it isn't business continuity, so those need to be dealt with by other people in the business.

Right, so if anyone's got any questions at all, please feel free to come off of mute, put them in the chat or put them, I think we've got it on Slido as well, there's a Q&A section. So, do feel free to put any of the questions there, but we're happy to answer anything.

External speaker: I've got a question if I may. Is it still too early for the data use and access bill, and Data Use and Access Act and any impacts that we need to be considering at the moment?

Lily: Oh, so first of all, some obligations are already in force for the DAA, and I'm going to use the acronym. So, some of them are already in force and for example, this includes having processes in place to deal with data access requests within certain timelines and to increase the proportion searches, etc. Some of them require secondary legislation in order to be enforceable. A lot of things relate to different categories. For example, we have recognized legitimate interests. We have scientific research, for this particular matter, data breach readiness, I'm not aware of any particular obligation that is going to change to bring a massive impact on how obligations apply to businesses and what businesses need to do. A lot of what DAA brought about was about an evolution, so sometimes keeping statutory footing to guidance that was already existing by the ICO, so it hasn't brought a revolution, let's say. So, a lot of things that obligation and obligations that businesses already have in the area of cybersecurity, they continue to have. Thank you. It's helpful. I think there was a question in the chat there. Yeah, I think it was around giving a high-level overview of who to notify in an incident. Is that just for a regulatory perspective, because that can be quite a lot. I mean, I can give this one a go, so let's think, so when you first start the incident, you want to have your external legal counsel and your incident response retainer typically, if it's to that level. So, it really depends on the level of the incident, the severity of the incident, but let's assume for a minute it's a very high severe incident, so generally, from a legal perspective, your external legal counsel, from an IT cybersecurity perspective, your incident response retainer to help you respond to the incident. So those are within the first 24 hours. You want to ensure that everyone internally that needs to be notified is notified, unless it's, say, an insider where you need to have an insider list and want to limit the amount of people that are being told. After that you've got your regulatory requirements, so that will be your 72 hours ICO, for example, other regulators that need to be notified within a certain time period, so that can differ based on the type of organization you are because you'll be regulated by different people. So, I would say that one would be the next one I would consider, alongside the communications pillar deciding internal communications to start. At that point, I would expect the organization to be thinking about whether they're going to be transparent or not and whether they're going to inform the media, and externally too, because obviously some of the stuff's going to come out anyway, depending on the type it is, so they'll probably be thinking about communicating externally to the media. Then you've obviously got all your different third parties, some of whom will have to be communicated to earlier because they'll just see the impacts. So, they'll just know that something's going on, so sometimes it can be better to get those comms in early. Yeah, and then obviously customers, obviously I would say before you inform the media at the same time, so those are quite a few. Some organizations, big organizations have to inform the government as well, so there's a few that are like that. Yeah, any others? It's a, yeah, it's exactly as you said, it's a multifaceted approach, so it depends also on the sector you're in and also the impact on the individuals. So under the GDPR, you have to have a certain threshold of which that you have to identify the individuals that, sorry, not by the individuals who were affected by this, and the same applies to any other regulations, so it depends on this and it depends on the sector, but yeah, I think I covered.

Elaine: And I think from my perspective, having been before where the ICO has had to be notified, is essentially, you know, notified early is great. Usually open comms, they'll come back with a load of questions, most of which you won't be able to answer because it'll be IT security so it needs to answer, so a lot of it will be, we're finding out right now, we don't know the answer right now, but we're finding out. We don't know the answer right now, we're finding out. We don't know the answer right now, we're finding out. So, you'll get a lot of, you'll have a lot of those answers in it. Also, it varies depending on who at the ICO is dealing with your case. Some people ask more questions than others, and some people are more patronizing, so it really depends on who you're assigned, but they, you give that back, they'll give you another deadline for other questions and things like that. So, the main thing is made sure you communicate. If you don't communicate, they're really harsh on you versus if you are communicating, and a lot of the penalties recently I've seen have just been based on how good the security was to start with. So, if you've got MFA in place, that sort of stuff, but the main thing is meet the deadline for communications and then after that, it's, you're talking to a person so it's like a conversation essentially.

Lily: It comes down to what we said before about having a strategy for regulatory notifications also and yes and you're completely right on this. The ICO is actually encouraging being open and transparent, and we have this, when the GDPR came into force, we had so many organizations, not even things that didn't even fall into the definition of a data breach as it is under the law because they were kind of terrified, kind of proactive, but it is important to be open and transparent, and if you don't know all the details, even an introductory notification, with further details to follow as and when we know them, that will be also OK.

Are there any other questions? OK, so if there are no more questions, to sum up, breach readiness is about more than just ticking boxes, it's about building a culture of vigilance, embedding robust processes, and ensuring that your organization is always one step ahead of the attackers. As in-house lawyers, you play a pivotal role in this process by asking the right questions, shaping the right contracts, and driving essentially the right response when it matters most. So, thank you so much for attending our session and have a great day ahead. Thank you. Thank you. Thank you.