Cyber Recovery: How to Get Your Important Business Services Back on Line

Now I think historically, before we got there, we all looked at business activities and thought about this critical business activities and how we can build business continuity recovery plans for that and all that stuff is still there. But really when we start to pivot into an IBS, or just frankly a business service, we start to think about end to end. So from our perspective, when a customer starts to interact with us, to when they've completed their journey. So let's say if a customer wants to withdraw cash or check their balance on their phone or make a payment to someone else or their bills or use their card at point of sale to the point at which that money is actually that transaction has completed. So the first thing that the framework really allowed us when we looked at the operational resilience regulations, is start to think about what our business services were. Not about the importance stuff. Right? Just like, what is what is it? How does our business actually operate? And it's interesting in I don't know how many other sectors are on here. Cause I I don't recognize everyone's name, so I'm sure we've got a fairly diverse cross section of businesses and sectors here. But in in a lot of them, what we're hearing is that people don't know how their business actually works, which seems like a very strange thing, but if you describe it as a service user and say, well, I'm I'm gonna you know, from our perspective, I want to support my customers in making a card payment to buy their new shiny thing they've discovered on cyber Monday, that's quite tangible, but actually we weren't very good as a sector, really articulating the things that needed to work to get there. So really the the first step we even got to an IBS or an important business service, which is a a unavoidable acronym, but it's before we got to an important business service, it's starting to think about how your business actually works. And then that concept of importance. So, okay. So we understand how our business works. So what does it mean to cause intolerable harm, which is a phrase you'll see in the regulations, to our customers, to ourselves, to the sector, and therefore, one of our thresholds around that, and therefore, which of these things are the most important services to us to make sure that we don't cause intolerable harm that we are able to recover within tolerance, and that definition of importance is laid out quite clearly actually in the back of being the website. You do wanna go and have a look at it. Go and look at the operational resilience. Policy documents and supporting white papers as well because it's a really nice, suite of documentation that the bank has published. But from us, from my perspective, what it's really helped us do is describe organizations and work out what's important, and then work out what things are actually required to deliver that and then work out where do we have a risk, really? Right? Have we got something in that chain? That if we were to suffer some disrupted event, that we would be unable to recover it within its impact tolerance that we set. An impact tolerance is an interesting concept it sound right, and you you guys could probably those of you that are in financial services will probably sitting like, yeah, be quite interested to see how they've done it. Right? But with a lot of working groups you've had across the industry really come up with some consistency on that because ultimately it's not about risk appetite. It's not about your RTOs. It's not about your sort of minutes or or hours. It's potentially days before we start to breach those thresholds and intolerable harm. So a lot of this is at that other end of the sect at the, at the spectrum. Some of the stuff we'd be dealing with in disaster recovery planning, etcetera. Now having said all that, once you've created this map of stuff worked out what's important, worked out how you're delivering it, worked out where you have risks, vulnerabilities that mean that you may be unable recovery with impact tolerance, that's when you start to overlay scenarios. I'm kind of eventually coming back to answer your second part of your question guide. Right? So when you think about the scenarios that could cause a lack of availability of your port business service that could trigger just an outage, or ultimately start to get you down the road towards breaching impact tolerance. And one of those is clearly gonna be or not one of them, but many of them will be cyber related. Right? So if you think about, a DDoS attack, right? So it's something that we always worry about a lot more, probably a decade ago before before our cyber threat actors became a lot more sophisticated and started throwing malware away, and started throwing runs, rents where our way. So we have we would have a scenario related to that. We'd have a scenario related to ransomware if the scenario related to inside a threat. Snario relates to a whole bunch of what we would call cyber threats now, and then apply that to our important business service who's structured testing and understand what is it that we need to really worry about? Where is our exposure What can we do to protect ourselves from the outage in the first place and through the IBS lens, prove recover from a disruptive event within impact tolerance. Long waffly answer, but I just gave you a little bit more background there, Kyle, kind of, well, how we've got to where we are as a sector. No. I think I think that's fantastic. And if I if I play that back a little mic, to to the audience, I think you you've rightly said that sort of shining the light in the dark corners to to work out the set of business services that you've got end to end that interact with accounts humor, and the the important components of the the organization, then you zoom in on what's an important business service that might causing tolerable harm to a consumer with those impact tolerances, and you're unpacking those important business services and seeing people, location and technology, all support each of those, you know, third parties. All it can sort of building blocks of how you deliver service. And I think that when I when I encounter a number of spoken in the industry. They all know that number of important business services. It seems like that that that, is something they can reel off very, very easily. And I think then the as you say, Mike, that's quite a, that is quite a sort of nest of different things that are associated with that important business service. Are there any sort of nuances that you you think about the cyber particular to start unpacking that across data, recovering the technology, that that folks should think about when the looking at this from through a cyber recovery lens, and trying to do. I think what's interesting is this term that we've come up within off the back of the regulations, which is a severe but plausible scenario. So when we're applying these scenarios to our important business is we're we're we're trying to strain it, stress the scenario as much as we can, but there is a step above severe, which is extreme but plausible. So everything's plausible, but we we're really focusing on remediating and mitigating the severe but plausible. Now interestingly when you start to think about somebody's cyber issue, a cyber attack. So let's say ransomware, a successful ransomware that impacts all of your business systems, your endpoints, etcetera, within your within your company, locks everything up. Right. That that's plausible because of course we've seen that countless times, unfortunately. It's certainly severe. It's extreme. Probably extreme as well. Right? And I think that you you you will then say, well, what can I do about that? And that I think comes back to probably the core where we might come back to later on the conversations. Like, so what what can I do better? I can't just sort of sit back and go, oh, well. That's that there. I'll just go and I'll just get my CV ready and go and try to try and work somewhere else. The reality is we need to consider all of the recovery options associated with that. And the different types of threat vectors and attack vectors that you might have that a badge cyber will fall in that scale of severeness, right, as well. But what's common with all of them that we need to run that through a scenario test, and we need to get the experts in the room to help us with this. We we stress it, stress it, stress it, stress it, stress it, stress it. It will tip into extreme at some point. Keep on stressing it because we need answers to those questions because we need to we need to reassure ourselves that we know how to recover from these types of events. Or frankly, that we know that we can't recover from certain events, and we're very transparent about that and understand what that means. Understand what we would do in those situations. And and I'd say it's it's quite a for business continuity professionals, operational resilience professionals is quite a well trodden path to be able to do this testing, right, and to really sort of stress and stress and stress. I think what is different is that interconnectivity across every component delivers a business service because you might be focusing on one part of it before that is downstream from where your biggest exposure sits upstream in the, in the business service. But, but yeah, I mean, I think it could be traditional, like, scenarios when it comes to the assets, which is as technology we use for the components that support the business service would be something like I've got an obsolete bit of technology that's riddle with vulnerabilities that can be exploited by an attack by an attacker. And therefore, as a high degree of of of likelihood that this thing is gonna full foul to an attacker and therefore that's gonna be the foothold that sort of cascades up and down the business service. Of course, it's now And so that will help us understand what protection we might want to put in place on that obsolete bit of technology in the interim while we try and work how we can replace it or something that's there's more modern, or it could be thinking about inside of threat actors within your workforce and where you might have the the highest likelihood of that it could be, disgruntled employee group based on layoffs. It could be an area that's perhaps struggling a little bit more geopolitically, maybe more susceptible to influence. Those sorts of things you might consider as well, and that, again, comes into a, a cyber threat angle in most organizations, even though the reality is it's human based, but it's human can be influenced by threat actors as well as to exfiltrate information. So there's a whole bunch of things that you will find when you start to sharpen your attention on specific scenarios on those assets that deliver the, the business service. And you may say, Mike, this is a an naive question and and many of the audience may already be on this, but it does seem that, through digging into these sorts of things, moving beyond, the sort of period of time when folks would say, don't worry. I've got these preventative measures to saying, oh, no. This is how I'd actually recover. And I'm thinking in a structured way about how it actually do that across the scenarios that you're thinking about. Yeah. Because I think what we we may have said in the past, right, is don't worry. I've got a, I've got a backup of that thing that's failed so I can recover, and it'll be fine. And then he's still working with the backup doesn't work. Oh, it's okay. I've got disaster recovery as well, so I can recover from that if doesn't work. You say, oh, what what what that doesn't work? And in the past, we may have thought that that was implausible, right, implausible that are two layers of of protection may have failed, but actually that's exactly what, an effective cyber threat actor would do. Right? Because that's that's how I would an organization. So, you know, they're much smarter than me, right, and they and they have a lot more time to focus in on some of this and ideas. So so that's what that's what that is now a plausible threat factor. So then you go, okay. Well, now what do I do? And that's where you get you get a lot more creative, I think, that we have been than we have been in the past. Now I don't think that, you know, we we've obviously got to find that balance. We can't just go, well, that didn't work either. What happened here? Well, that was an asteroid. The asteroid didn't and now I have. Whether the aliens came in, you know, you've got draw lines somewhere in terms of plausibility, right? But ultimately, you know, if you start to peel things away, so you haven't got that option anymore, that opens up. Some more lateral options to come and present themselves. And that's what the regulators really encouraging us to do is to look at different ways of recovering and sustaining service, and maybe the the historic view of business continuity to us recovery would have done. I think you're right. I think the, whereas some of the, the previous scenarios, we we did discussed around more traditional disaster recovery the hurricane or the flood didn't have it in for us in a in a malevolent way, but in this case, you have an intelligent, theory of actors that that can lead to additional complexity and the plausibility of some of those things then get sort of ratcheted up. But maybe I I could, I could, pick back up on the point you you made earlier, Mike, which was sort of the the how this framework is very interesting. It really allows, it allows people to to think in a structured way about how they would recover, what were all the best practices that you've had for implementing it because I know you've done it a number of times I've ever experienced in that So, I mean, I think what I would say is there's no silver bullet off the shelf solution to help any organization protect themselves from a cyber attack. Right? So every every every sort of way that you might wanna protect yourself will be unique and bespoke to your organization depending on the the vulnerabilities you may have. But there is some commonality, right, which is practice rehearse, practice rehearse, practice rehearse. And so once you've identified the most likely threats, and perhaps some of the less likely, but still plausible, threats and scenarios. Rehearse it. Make sure your organization knows what to do. It may even if you even you have a a playbook that simply says, you know, call call the boss, call the regulators, call the police call, you know, whatever something as simple as that, right, is better than having a blank piece of paper where you don't know where to begin. Your recovery. So, you know, in in a, in a business continuity recovery plan, we would have that documents then we have sort of steps in it, but I think what we got now is a much broader set of stakeholders and broader set of steps that we need to include in that. So as long as you sort of say, well, look, Something bad has happened. Right? This scenario has happened. Let's say it's random somewhere. So you're gonna spin off a whole bunch of different things. Gonna spin off a technical recovery work stream. You're gonna spin off a comms work stream. You're gonna spin off a legal and, perhaps a legally privileged work stream in the an engagement in law enforcement, you're gonna make sure you keep your, you know, senior stakeholders and your board informed and you could work out how you communicate with your customers, and regulators and other interested including press, etcetera, because this is going to, at some point, probably cause, be become public. So That could be absolute chaos if you haven't done at the very least written down what your approach is for dealing with these type of scenarios. And and by the way, you know, cyber scenario, something like a ransomware scenario, data loss scenario could be an IT triggered event. For a bug or a defect or or a a mistake someone may make as much as it could be a malicious threat actor that's decided to, to cause a smoke screen ex Xol straight data or, put a ransom in place, whatever it may be. So so some of the some of the documentation we're talking about is the same for any sort of scenario you need to have, which is that structured approach to recovery. But once you've done that, you need to build that muscle memory in the organization. Build the muscle memory, make sure you're exercising them time and time again so that everyone knows what their job is, and everyone knows that once the alarm bell rings, that they're on that call, and that they they have their authority and they have their job too and it's rehearsed. But the other thing that perhaps from experience as well is that if you if you store all that data, on your intranet, the chances are in some of these scenarios, that doesn't exist anymore. Right? You know, we've had a we had an incident a couple of years ago that that made the press and we had issues for the first couple of hours actually getting into our intranet. Right? And so luckily, our recovery tools were not hosted inside our perimeter. They were hosted out in the cloud. We're able to actually get into a lot of the information we needed to get into to be able to start our recovery process and and get our calls set up. But, but I think, you know, it's a very simple thing. Right? None of us is is rocket science, unlike your previous job. Right. This is this is basically doing the basics really, really well, but starting to cast your net wider on those basics and soon to be done in the past, past, and make sure you have a broader stakeholder map, in there, and you're able to, mobilize that recovery much more quickly, you have access to the tools you need to have access when you need them? It was one thing I I I've always particularly loved about how how you rehearsed things like this is Yes. The technology components data, third parties and others, but you have also taken humans out of the the process in the, in the recovery. So it might be that, oh, Freda Feona is an expert on these servers or how you recover this, this thing, you know, but today, a friend, fiona Auntier, and, do rehearsal and things like that. I think you you build excellent muscle because it's not only technology that could be out of these situations. It definitely also can be people that cannot get in our last scenario, I got knocked off my motorcycle halfway through virtually, obviously, I didn't really. Right. And so, and so it's it's throwing some of those into it as well to bring it to light. When we we we did, at Prius Organization, we we really pioneered wall gaming. As an approach to exercising as well. So we're really, really testing to destruction, right, the, the the the scenario. We have a red team in there pushing it. And I know a lot of other organizations are getting them, are getting really good at that as well, which is good, but that's the best way of really pushing a lot of this stuff out is is test it to destruction, really make people sweat. They'll remember that. Don't don't don't sit in a room for an hour with a page turning like PowerPoint deck. Now if you tend to page forty seven, you can see that now there's something that has happened, and then we'll page forty eight something else. Yeah. You gotta it's it's gotta be an engaged proper. Walk through. Alright. Sorry. That's great, man. I wonder I got some further questions around the framework and it's useful. I wondered if you could may maybe summarize at this stage for guests. What you would think are the the benefits of it of adopting it for thinking about things in the world of cyber recovery. But again, I'm going to talk more generically. Sab recovery is is one of the key threats and scenarios, but, you know, generally, taking it back to the important business service framework. Now that, you know, the operation resilience framework and policy has been born out of regulations in the UK, as I said before, and and in financial services, but it's transferrable to any sector at the end of the day. It's just a very basic concept. Like, know your business. And there was a really interesting paper that, Crownfield School of Management plus deloitte work together on call Resilience reimagined. If you if you just Google Resilience reimagined, space deloitte or Crownfield, you'll find a paper. And that talks much more generically about the resilience principles and how you can apply that to your organization, which includes thinking about business service and working at how your business actually operates. But from my from my perspective, you know, that that is the core is understanding how your business works, understanding where your hotspots are and those end to end business processes, the cores that are whether your key kind of risk points are on your focal points for for mitigating actions. And when you put it when you overlay that with a cyber threat lens, there are there's perhaps a different it's got I've if I had, I've suddenly got this, you know, like, we either the three d glasses where you you kind of put it over different colors colors would come through, etcetera. It's sort of thing. You you sort of put your three d glasses for cyber over it, and you'll see like these red hotspots on your business process. If you put your three d glasses for flooding, you'll see different hotspots. Right? And once you look at those hotspots, you think, well, how am I going to mitigate that risk? How am I and how am I gonna recover if that threat actually manifests itself successfully as an outage and a disruptive event to my business service. And once you have all that, then you can start to think about what am I gonna do about Right? And what I'm gonna do about it is gonna be a combination of fix the thing and and work out our recovery process and our recovery steps that we're gonna need to go through if that thing happens. No. That that makes a a ton of good sense, as as usual, Mike. And I think that what you said earlier in terms of the Bank of England, I certainly have got experience of talking about regulators and other jurisdictions that are talking about this framework. And and know that, as I said, that they know their number of important business services, even though the jurisdiction is necessarily always in, related to the Bank of England. It certainly seems to have gone international. But but I but I wondered, do do you think beyond financial service entities, it's also applicable framework to help any large enterprise. Absolutely. I mean, there are obviously some things when you think about, some nuances of UK regulations when it when we when we start focusing on vulnerable customers, customers in financial difficulty, customers are victims of fraud, for example. That may be something which is unique to our sector. Now, or more more unique than other sectors that are out there. But but, at least, but ultimately making sure you have a sustainable company and a sustainable business and your customers get what they want and have paid for and deserve as part of the engagement you have with them. And that if you're sitting in a core part of supply chain somewhere or, you know, an ecosystem of things and you're a big part of that ecosystem, do you maintain your obligation within that ecosystem by being available and be able to deliver your services end to end. That's ultimately what the regulations have said, but they're specific for financial services. But if you play it through and just take sort of some of the stuff that's very unique out and just say, but I'm really important in this sector because I'm supporting, you know, the back end of hundreds of other companies, or I've got thousands of customers that are expecting me to deliver my product on time and and at this you know, our time and, and at the right price. Or if I don't do this, I'm gonna be hit with a three hundred million pound fine loss, etcetera. And I don't know if my business sustain that, that's exactly the same thing that we're doing. So this the the process and the methodology is completely transferable. To other sectors and other industries. And and I and I I know we we had a I had a conference, to load hosting where we had a lot of people from across different sectors in different industries, whether it's aerospace, you know, travel, rail companies, you know, government agencies, energy companies, etcetera. And we all and actually a lot of them, I think we're quite grateful to the or or jealous for the better word of financial services for having regulations that say they must, because it's sort of encouraged best practice. Whereas, I think in reality, we can all do the think by just thinking about how a business works. And then you can start thinking about whether or not in addition to just being the right thing to have a resilient business. Does that help you thrive through a disruptive event rather than just surviving? Right? Could you thrive and flourish through disruption rather than just surviving as and that that's where you start to see this convergence of operational resilience into organizational resilience and strategy, just general strategy of how you run your And if you, you know, if you think about that at the top of the house, that some big disruptions happened, I need to make sure my customers are safe. I need to make sure my colleagues are safe. I need to make sure our money is safe. I need to make sure I meet obligations. But how else can I help? That actually might also increase, some of the other positive outcomes for us in the sector. And that's thinking is is way away from where we were probably as an as a as a sector sort of twenty years ago, but it is where we are now, and I think it's where everyone will will hopefully get to once they think about that, and and realizing the interconnectivity between all the elements of service. And I will say that Dora in European reg, legislation is really is really interesting now because the UK will really first out the blocks in terms of operational reserves regulations Europe, I mean, all all all geographies are, are lining up, which is great. Europe's Dora, act because law is really interesting, and it starts to put a, a much brighter light on some of our dependencies we have on technology, third party providers as well, which were all dependent on big cloud providers. We're all dependent on those as well. No, that's, that teeth is up where I was thinking about for the, the next question. I think as you say, your clickability the, the attacks certainly, seem to come thicken fast without a care for, sector. So I think as you say, like, the the applicability of doing something to respond, seems seems good. So just picking up on that for the dependency on things like, large cloud providers that there, there is a there's there can be a thought that that offers me resilience, an avenue for cyber recovery but but but how do you how do you think about that in terms of the framework? Is it that different between what technology runs on prem and what technology runs in a cloud? Well, I think, if you take your on prem app and somehow manage to copy and paste it, unless it into a public or private cloud, like AWS or Azure Google you know, Oracle, other cloud providers exist, etcetera. They, it won't work. It won't, you won't achieve any sort of upside you probably just get downside. I think what what public cloud so I'll just use AWS as an example. I think that what AWS, if you design to be to take advantage of everything that AWS gives you, you can build a very highly available platform and technology service in the cloud. And if you think about care, but but it doesn't just come up by magic. You don't just get magic ones just sort of, I'm on AWS. I've now got my resilience badge, and I'm all good. Right. You still have to be thoughtful about how you implement that and thoughtful about cybersecurity in the cloud as much as you would do on prem. In some cases, a little bit more, because you're now looking at a at something that she's, you know, from a from a, I guess, from a perception perspective is out there in the public cloud with all attackers just sort of standing outside a fence poking holes through the the fence whereas before there behind a big concrete wall, you could contain that now. It's obviously not like that at all, but that's the perception. Right. So I think the understanding of what your application functionality is and how that is able to be resilient and highly available in with any cloud service provider is is not is a different skill set to perhaps what we've had house, and we'd be able to contain everything ourselves. And we'd be able to say we've got our own data centers. They've got big thick brick walls. They've got two of everything. Gonna buy the biggest, shiniest servers of the bluest LEDs I've got because they're the ones that never fail, because they're nonstop, and they never fail. And I put whatever application code I want to put in it, and it's all fine. And my job here is done, well done, me. And that won't work in public cloud. But you can actually build it to be much more, I think, resilient and available in public cloud if you actually apply, the the principles and what what what the framework gives you. But, you know, again, it's the same threats that you would get in public cloud that you get in your own environment in terms of cyber threats. So you still have to be careful. Right? You still have to have evaluate the risks that you haven't had. Think about how that manifests itself in an important business service. And in many cases, you may have had for a risk lens. All of a sudden, your IT risk of your in house stuff is now presenting itself through a third party risk. Which again is is is probably the the the the spotlight of risk is moving a lot into third party risk. For most sectors across the board as well, but you still need to think about how you prepare yourself for it. Nothing really changes in that respect. Know I sound like a broken record in that respect, but it's true. You know, some of it does not change. You need to be prepared. Do you think about your risks, need to think about how you mitigate them and you recover from them? I think that's the right micah, I think as you say, you can you can resiliantly host and rearchitect your applications and fantastic ways it will it will cost and it will it will be based on a cost benefit and resilience category. Probably prioritized according to what pieces of technology support what parts of an important business service, to to to do that. And I and I see the cloud providers competing on how many data centers per availability zone and how far apart these things are to be able to avoid some of these things. I think the the general direction is good, but as you say, you've gotta you you can't delegate or outsource your resilience posture. You, you, it will come back to you. So you, you've gotta on it. So that that makes complete sense. Yeah. That was go go ahead. Well, I've just got the you're asking, so you can't outsource your resilience possible. You can. Right? If you if you but then everything but you have to manage that contract. Effectively to understand that what you're expecting from that third party is what they're delivering. So I just it was just a little nuance in that last comment. Yeah. Yeah. Yeah. No, no, I get that make and protect. That's good. But yeah, in in terms of also how how some folks think about automation, another tooling that they would use for doing cyber recoveries, and they they need to have the the human in the loop. Do you have any thoughts on how you sort of bring alive some of these recovery plans, considering him the audition. Yeah. Look, I think, I think, automation, once you've decided what you need to do, automation can help your recovery and obviously speed things up. So that's I don't think anyone would disagree with that. The challenge is that there's a nuance, particularly in cyber recovery about what it is you actually need to do. And that involves humans making decisions. And as humans, we're really bad at knowing when it's our turn to make decisions and when we need to get involved, etcetera, etcetera. Now part of that, my my sort of soapbox a few minutes ago about making sure you sort of rehearse, rehearse, plan, plan, plan, test tests, etcetera, right, over and over again, is to build that muscle memory so people don't need to be reminded at the point of, a a crisis that that that job, you know, they're they're now on the hook for making decisions, etcetera, and going to collaboration. But, having the ability to orchestrate humans is phenomenal because that's what we got. He's like. So, okay. Now, Mike needs to come online because he needs to bay basically give me some information on What is the current cyber threat is in the environment? How likelihood is it that we've been targeted? Specifically, are we caught up in a third party issue? We caught up in collateral damage or something more? Broader. We need to know that. And it and then someone else needs to come in and talk about what is the actual technology, solution for this event, or what do we have available to us? What are the upsides and the downsides of each such decisions? So that process of essentially orchestrating the crisis response and bringing the right people in based on the scenario that we have is absolutely critical. And none of that has got anything to do with automating recovery of technologies. We may have automation and notification off the back of it, so something like an average type tool, but doesn't tell there's no decisions that are that are automated as part of that through a technology perspective. Whereas the humans orchestrating the human part, which is orchestrating the necessity for discussion, and an frustrating the outcome of that recording the evidence that we actually, of what will be made, and decisions we made, why we made it, which then may trigger an automated response in terms of recovery, depending on the nature of this scenario, is absolutely critical. But, for all the crises that I've like, had the pleasure, the right word, of sharing response responses for, frankly, there are very few of them where we actually invoked any automate technology. There was a masses that when we orchestrated a bunch of people doing stuff that was unique and specific to that scenario. And so the the as much of that as you can write down and orchestrate, including the engagement of those teams, and records associated with them doing stuff really helps accelerate recovery, and it also helps on our post incident review or post recovery reviews and to say, well, what do we do well? What do we do badly? Do we have the right evidence to have the right decisions where we speak things up, etcetera? Maybe I'd just say to the audience at this point, we'll shortly move into, to Q and A for, for brief period. If people want to raise things in the Q and A section, please do, as I discussed this last question on the, agenda with Mike, and if I, if I said go, so please please do that. So in terms of, one file question on the the non agenda, Mike, across the the various organizations that you've been involved in in your, significant career. What would you say is the sort of technology stack or fiber recovery in the context of operation resilience? The different pornments you'd want to to manage that human and machine, way way of recovering in the best fashion, if if we've talked today about the sort of processes and the the involving and and setting out the right framework, what are you seeing at the technology stack, from your senior experience across many organizations is important. I I guess until Butlersoft invents the or singing or dancing one stop shop for operational resilience technology, the reality is there isn't, yeah, which which is not gonna happen so the the reality is there is no single product on the market that solves everything resilience. Which I guess is a good thing for folks like like you Kai would cut over because there's a part to play for all of these different parts of the puzzle. If you think about what what the framework says, the framework says what you're gonna write down what your business processes are. Now, Back in the day, we have always BPM tools, and we still use them today, which sort of tell us what our process maps are and our flows from front to back. And different organizations have that documented in different ways, some of it might be sat in visio, PowerPoint, Excel, Excel, it might be in a proper BPM tool that's exposed that, etcetera, etcetera. Hopefully it is. I say it is. Right? So there's your BPM tool. You wouldn't necessarily want to store your process map your process flow in something like, I don't know. I'm gonna say terrible. Oh, I won't I won't say any product names not to use, but I mean, you wouldn't naturally think that my BCM tool is place me install my process map. You probably think from an ops perspective, a business perspective, are other tools that I've used to be able to capture that. And you should probably keep using that because that works really well, is that. But what you do need to do is to think, well, how do I now overlay and wrap it in a way that it exposes the importance of that business process and records that that identifies the mapping of assets that wouldn't naturally be mapped into a BPM tool. So how do I aggregate? Let's say service now, if your CMDB is set in service now, how do you bring service now in and say, well, I'm really happy with ServiceNow as my CMDB exercise my IT service management processes, so I don't really wanna use anything else. So that's okay. So you've got ServiceNow in as your BPM tool and you think, well, how do I wrap around runbooks, playbooks, etcetera, and scenario testing for all these scenarios I've just come up with, which are really scary. But plausible. Right? You know, I might use cut overs to sort of sit around that, and that needs to hook into all those tools as well to make sure that we're not. Double keying sort of other stuff in that randomly doesn't tell us what we're doing. You've gotta have another tool that's generally managing a third party suppliers, and you want a record in that tool that do what I have by appropriate contractual obligations set in the contracts of those? And do I have the evidence associated whether they've done it? I wanna have by control testing on my on my All my control sucks and otherwise it says, is this control that's designed to mitigate risk of this specific scenario on this specific object effective or not? You wouldn't have all of that in one big tool. I mean, I know you, over time, we might find that something like service now has these plug ins and platforms and other other tools that start to aggregate a lot of this stuff together, which is which is great. But at the moment, there isn't one product that will do all of that, or or not all of that well. And so I think at the moment, it's it is a it is a good it is a good mix of different products that you'd have to pick out the market and think about how your organization, where it's got maturity, and if it's got maturity in certain areas, Briviant double down on that because I wouldn't necessarily reinvent that, but think about how you can wrap it with other elements as well. That's great, Mike. If I now transition to some of the questions raised by the audience, first up is, do you think regulators have helped or hindered operation resilience. That's a great question. I I mean, I think you probably tell hopefully that I think that helped, is the answer for this one, because what one thing that, like, in every or every sector that we'd be missing, if you think about IT from an IT service management, perspective, but a lot of what that gave us was a common language and a common taxonomy. And then certainly in the UK financial services, when the when the regulations came out, it gave us that common which in taxonomy. It brought with it some complexity because we we had to sort of work out what some of it meant, and and the good news was there was, I would say there was more of a partnership between the regulators and and financial services, BC and not res teams to be able to come up with some of the definitions together that made sense. Obviously, the regulations are other regulations, and we will we will adhere to them. But I feel that from a regulatory policy perspective, it was, it was very much a joint effort where we felt that as a sector, we wanted to be resilient. And so some of the tax taxonomy and language, we sort of drove that consistency ourselves. But having that consistency and that need and that obligation to demonstrate that we are resilient and and and represent to our regulators on a regular basis. And at the moment, we've got a clear target of March twenty twenty five to have remediated our material vulnerabilities that could causes to breach impact tolerance if we suffered a disruptive event, that really helps sharpen the focus and attention of the organization. So, yes, helped. That's good stuff, Mike. I think another one is it's been a bit of a thorny one, about how you can citizen recovery from a data integrity perspective. It seems that sort of recovering the applications is easier if there are sort of several that support same business service and sort of sort of syncing those things up and considering data loss, just give you a perspective on this one. So so I think what I think if I if I play back, the question, I think what we're saying is, across the service chain, for a business service, how do you maintain referential integrity of all the data in that chain when you're recovering maybe part or or or all of the of the data repositories in that service chain. So I think so I think that's quite hard, right? Cause and I think we're all sitting and going, that's quite hard. And it is because because the reality is that we could probably we we could we can go back to a point in time across that service chain where we say we we know there's referential integrity at this point in time across all of these critical platforms that we could recover to that point. The problem is that in many cases, that's could be yesterday, right? Not today, right? And and I need to get back to two hours ago. Not yesterday at one o'clock in the morning. And I think that's that's the big challenge for us as a sector was was as we mature our understanding and and start to think really hard about how we, how we get to as close as real time recovery as possible. But also, if you're in if you think about why are you recovering? So are you recovering because you've had a technology outage on one of your components? And if you have, then maybe that's that's auto synced out to DR, and so you've got something which is relatively current. And so you've got a little bit of recovery to be able to maintain that referential integrity across the stack. Or do you have a threat actor that's been inside your systems or don't know how long who's been manipulating some of your call books and records data. And that's a really interesting challenge. Because see, well, I don't know when the last known good point was in that data to maintain that referential integrity across the the service chain. So the focus probably becomes a lot more on just how do we fix forward and maintaining our business processes and then set up more controls up and down streets to allow us to detect the implications of, of, a data integrity issues coming out the other end. So it's it's probably a real cerebral challenge as you start to get closer to real time recovery across multiple systems in the chain. This is where cyber So it's a cyber volt. Let's see. We've got a question here on cyber volts as well. Right? So does cyber recovery volt solve all your problems, right? I I did a web I did a a vlog, a couple of years ago. I think I was quite, skeptical about the ability of Simon Volter to to solve all problems, right? It's a silver bullet solution to cyber threat, but but that's because I think people are point didn't really understand what the use cases could be for cyberbulk. And in reality, if you put all your data into it, at a point in time. Yeah, Sarah. You know it's good for that point in time, and that's great. But that may not get you back to business. We may have to accept that you've lost data, and there's a recovery strategy have to wrap around that. Or you might say, you know what? I I'm I know that in this certain scenario, I'm gonna lose everything. So I'm gonna have all my desktop builds, all my GitHub, everything is gonna be sat in the vault so I can rebuild my organization's technology stack. If that were to happen to me. And then I'll deal with the data separately and we'll just have to, you know, fix for it and have a look, but I but I got a plan which how to do that, etcetera. So I do think, yeah, data integrity across the service chain is still maturing in most organizations to think about that real time, that close to real time recovery, whereas, you know, we I think we're pretty good at knowing how to recover to a point in time. But that point in time naturally will be, will involve some sort of data loss if we in our kind of solutions. And and do you think, thanks for answering the other question as well in that, that might. And do you think that in that situation that I realized testing is tricky to do it maybe for all all of an important business service, for what it would require and sort of duplicating environments. But do you think again, testing some of this component, in terms of data integrity, what would happen? What what would it really be like? It is, from your earlier comments, seeing that also really helps you here? Yeah. I mean, I think exercising with smart people in the room and the data owners is is is gonna help is gonna give you a lot of insight without you having to actually do anything technically. Recovering a whole service chain, the data of all the whole service chain is going to be necessary to give you the absolute confidence. It will also probably highlight the the risks and the skepticism. I think that many of us will have on our ability to do that at a at a point of time, which is close to real time. So you you can definitely do it, but but I think the reality is that going back to just saying, let's let's get smart people, go to the data, look at the relationship, look at the data elements, think about our recoveries, challenges, not strategies associated with that will give you an awful lot without having to do it in anger. That makes it a ton of good sense, Mike. I think that that rounds us out for the, the question that we had in in front of us. I'm really, really thankful for taking time with us, Mike, today, that, some stellar insights from my perspective, just summing up hopefully, folks in the audience got a good understanding of the steps involved in the Bank of England's important business service framework. The benefits of adopting that for cyber recovery, learning how to the best practices of that, the benefits of it, how to implement it and consider it for, recovering across various bits of technology, how to consider automation, people data third parties in it and to really hopefully gain confidence and strengthen your cyber recovery posture, and with the key trend and Mike Mike's pitched in this, which is the the ability to sort of test, rehearse, and learn from it, which which I, again, I learn every time I I get a chance to to speak to Mike, hopefully that's a that's a decent summary of that. I don't know if Mike you've got any final comments before we conclude. I'll just say, look, if anyone's interested in more around the regulatory framework, go as I said before, go on to the Bank of England website search for operation resilience to take you to the page, there is little microsites on there. It has the policy statement, which is quite, verbose, but it has a lot of really information, talking about the building blocks of the of the framework, including important business services and and how that relates to some of the other concepts at the Bank of England. That we that we have to adopt in adhere to within financial services. And if you look at that resilience re imagined paper that Deloitte and Crownfield, car road, it's it's a really interesting paper to sort of bring a home that can be applied to any industry at any scale as well. Great stuff. Thanks, Mike. Thanks to you all. We'll conclude there. Give you a few minutes back in your diary. But again, thanks, Mike, for taking time. I really enjoyed the opportunity to chat to you today. Thank you