As Kyle said, cuts over have put this event on, and they've kindly asked me to to host it. And also, I'm conscious that some of you may not know that much about cut over. So, if I can, if you'll indulge me, I'm just going to give you a very quick overview as to the cut over team and what they do and why this is such an important topic for them. The organization was founded in twenty fifteen, its headquarters where I am here in London, and it's the leading cloud solution for collaborative automation that interconnects teams, up communications and technology together with dynamic automated runbooks to support technology resilience and recovery strategies. With cuts over you can seamlessly provide the required recovery capabilities, including hosting multi team and technology recovery plans, performing planned or even the end of the rainbow have unannounced resilience testing and recovering from actual instruments all with the visibility of execution analytics, and And this is really the key bit for what we're talking about today, providing and generating regulatory audit logs on the platform in real time. The organization and its premise was built on the foundational purpose of enabling humans and technology to collaborate cut over's proven technology, accelerates IT technology, resilient strategies for the world's largest financial institutions some of you may be on the call if you are the warmest of welcomes to you, including the three largest US banks, and three of the world's five largest investment banks. Cutover is helping organizations like you move to unannounced testing and bringing together your resilience technology -- your technology resilient strategy There is no other platform offering this level of collaborative automation that interconnects teams, applications, and technology together with dynamic automated runbooks, so that organizations like yours can reach your resilience and your regulatory goals. And that's it. This is a very important topic for the cut over team. And what I wanted to do is start, despite teasing out some information and and some tidbits so that we can start to get some nuggets for you so that when you go away, you have some practical things that can think about. I need to I'd love to come to you first if I may, and then I'll come to Mark. But I jotted down a few questions that I thought it might be interesting for the audience to come with us on this journey. And once we've done this question, I'm actually going to ask the audience a question as well, because what we want to do is make sure that in real time, we're incorporating the things that you want to talk about into the answers that we're giving. But Anita, I hope you can see the slide, the question on on screen, on the slide. It's simply how are you integrating your technology, resilience, stretch I'm just gonna move that back. How are you integrating your technology resilient strategy as part of your wide approach to operation a little resilience. And, ETA, can I come to you first on that? Sure. Absolutely. I think this is an interesting topic because for most people, technology was always a part of resilience and historically speaking, right? When they think about the applause of resilience, technology was always considered. It was people, your vendors, your technology, your facilities. And sometimes, your people do consider data as well. We'll get to that later. But I think what has changed recently based on the, you know, just the environment, the regulations, and so forth. Is overall how organizations have started to look at technologies from two different front. One is it's putting technology up front from the perspective of designing systems with resilience in conservation. So it's resilience design. So when you have a business need, a requirement, instead of thinking of technology as an aftermath, it's something that you think about initially. I think that's one. Area, how firms are integrating technology. The other way is how you are integrating technology from tobacco along the entire life cycle of resilience. So be it from your business impact analysis to or to conducting a playbook documentation to testing assurance to reporting, governance, it's making sure that you're integrating technology all along. So a good example would be if I were to do a business path analysis. You no longer look at it from a vanilla technology outage sort of scenarios, but you are asking your business what's more specific to them. A scenario that's very relevant from a business perspective. And then you see how technology integrates from a business point of view. The same applies to when you think about your playbooks. You don't just write your system failover with playbooks. But now you write labels which are tied to your business. They are tied to your crisis management team not just within the engineering, but also within other areas within your business. And again, when you're doing your testing, you no longer do testing of just application failures. Don't get me wrong. You still wanna do those vanilla tests. It's just that now you wanna do something that's more handset where you are looking at multiple asset failures and scenarios and you're incorporating. Technology in that sense. Now, finally, what I would add is it's also how you think about governance. I feel like that's an area which folks people need to focus So or historically, you might be talking about technology just about in your operational resilience. Or in your BCP government's bodies versus now what you wanna do is do the reverse as well, which is when you have those sort of governments, we for your wearer's assets, you want to make sure you're including Resilin as a topic as well as much as how you would include a topic such as Infosac or something else. Within the pipeline. So it's it's all in it's in those ways where you wanna make sure that you are integrating technology. Great. Thank you, Anita. I'll I'll come back and and and respond, but but it's not about it's not about me. It's about you and Mark. So, Mark, can I ask you the same question? Does what I need to say? Is that stuff that you recognize? Does that resonate with you? Absolutely. And there's a couple of concepts that I'll talk a little bit about in how I think about resilience and how it ties in to technology, which is one, I think the term, the resilient is overused. Because it's a buzzword, it is applied to everything. Right? And I was recently at an event where they were talking about resilience of your threat intelligence function. That that's an example of where, frankly, I just think it's it's overused. When I think about technology, for example, I'll talk about it from a resilience perspective, but it's not really how I think about it. Resilience to me is especially in financial services means that our customers are always able to conduct the business with us that they expect to conduct period. If they're able to do that, you're resilient. In order to be resilient, it means you have to be able to absorb impacts whether those impacts are people, facilities, third parties, technology systems, etcetera. In order to absorb those impacts, you almost always have to have substitutability. Technology will fail. No matter what we do, how much we invest in it, it will fail. So when I think about technology, I assume that that's going to happen. And I don't focus too much on making the technology itself resilient. I focused on making it highly available, highly reliable, highly recoverable, rapidly, restorable, etcetera. All those attributes that apply to a single application, for example. It's the business service and what we actually use that technology for. That can become resilient. So there's a difference also between business services, which is where operational resilience absolutely applies, and technology services. So when you start rolling technologies into services, that's where you can make those services resilient. Right? Take as as an example authentication. If I just look at active directory, I can make it highly available. I can make it highly protected. I can make it be recoverable. But if it experiences a major impact, such as ransomware, I can't make it resilient, but I can look at my authentication services and make those resilient because I can have substitutability. So when you look at operational resilience at a business service level or a technology service level, you have to understand the the technology that's used. So they go hand in hand. Right? It's hand in glove. You can't have one with out the other. If you don't understand how that technology is used by the business, you won't know how critical it really is. If you don't understand how the business uses technology, you won't understand what level of reliability and recoverability that technology has to have. So I look at it as really a dual focus. One, looking at your technology infrastructure from a true pure technology resilience perspective. And focusing on those utilities that everybody uses. If you lose one of those, you essentially stop doing business. You cease to be a bank or a financial institution. And then those business services that customers are after it. And then understanding that full stack of of how those are get are together. So they very much connect and you have to look at them in my opinion at the same time and in conjunction. Fascinating from both of you. Thank you very much. Just to recap a couple of things that that come up on on panel discussions like this time and time again, both of which you've chimed in with. One of one of which is this is a a mindset issue as much as it's a technology issue, which is about feeling comfortable in a world in which things will go wrong, and you should expect them. To go wrong. And when they do, you need to understand the impact of it going wrong in terms that the business and therefore your end customers can understand not in terms of technology and widgets, but in services, in things that make a difference to people's ordinary lives. So that mindset change, I think, has been one that we've been on a journey with for some time. So great to see that that's chiming in with both of you. We're having a couple of questions come in, which I'll come back to a little bit later on. But I wanted to do an ask the audience a couple of things here. The first question would like to do, and I'll give you a minute here, is what is the biggest challenge you have in meeting regulatory requirements for technology resilience? Is it and over dependence on a few people, and we've all been there to ensure that regulatory requirements are met. Is it B, standardizing recovery plans across the Is it c embedding RTO's recovery time objectives within the plan, or is it d, lots of manual effort needed to create the post event reporting audit. We've started a stopwatch. So let me just briefly recap that. The question is, what's the biggest challenge that you have? In meeting reg requirements for tech resilience. Is it the over dependence on a few people? Or is it standardizing recovery plans? Or is it embedding RTOs within the plan, or is it bot's manual effort needed to create the post event reporting and audit Cape ability. So let us know what you think. Kyle's gonna let me know when we've got some of the results in. And I haven't seen the results. So this would be this would be a real time revelation for me coming in. Okay. So sixty seconds are up. Let's take a look at what some of you have been saying. So it is perhaps equally split between one two and three. Not really a surprise that RTOs hasn't come down because I think we've been doing this for for long enough now. But some of you In fact, a third of you are struggling with an overdependence on a few key people. I think that's something that will continue to be a problem. The standardization of the plans across the org a third of you struggled with that as well. And then this one, everyone would recognize this huge amounts of manual effort needed to create the post event reporting and audit. Okay. So Anita and Mark, some things for you to think about as we as we move forward. I'm gonna ask you guys another question, and then we'll have one more poll, and then we'll we'll finish of questions that we've got. But if I move on and Mark, I'll come to you first if I may for this second question. Can you talk about your key priority when it comes to regulatory compliance, as it relates to technology resilience. What's important to you? What do you think about most? Well, I think the biggest one is staying out of regulatory jail. Right. But they're for most of us, there are a number of regulatory bodies. And trying to, one, coalesce, the requirements across multiple regulatory bodies so that you can meet the varying requirements at the, you know, appropriate times across those entities. And frankly, there's an education level there. It's really getting regular regular just to understand what is practical, what's possible, and what makes the greatest level of impact as an example of that regulators would love to see zero data loss. Just not sure zero data loss is an achievable item. So helping to understand when and where can you get to zero data loss or when when you can't so that they are better informed or on the ground work. Also getting them to understand that it's very unlikely that a truly catastrophic event is going to happen. They tend to like to have scenarios where, you know, multiple nation state actors have infiltrated your environment and pop three different operating systems across your enterprise and they've ransomware all of your data warehouses, and how are you gonna recover how long it's gonna take you. And having the conversation about what's practical and what's not, and trying to shift the conversation to giving them sort of lego blocks. We can recover this in this amount of time. We can recover this in this amount of time. And these are sequential or they can run-in parallel. And then they can calculate impact time or duration. To their heart's content. But the other key item is don't let the regulators drive your agenda for what you need to have for resilience. Let your customer expectations drive that. If you wait for the regulators to tell you what good looks like, you're likely to either be perpetually behind, depending on the size of your firm, or you're likely to not meet the expectations of your customers. So determine what's right for your business and your customers and then overlay that with regulatory patients and come to that sweet spot. Great stuff. Thank you, Mark. I'll respond to that when, but I'll let Anita have a have a public question. So I need to what are your key priorities when it comes to this? I think mine is very similar to the Howard Mark as well, is our it's just taking back in understanding what do you need to do in order to feel resilient about your technology infrastructure and the threats and factors that you are likely to face as an amortization. The reality is what regulators and others want to hear is that your -- you are well resilient, you're well protected, or you have a plan in place in terms of how you're going to manage if you'd wear in a situation where your continuity of business can be impacted. So, it's just taking that step back on telling what your priority should be. And then having that discussion with the parties and making sure that you have a plan in place that works towards it. Because I think if you don't do that, it's very similar to what Mark is in Beauty, you're going to be in a position where you maybe implement a lot of things that don't really make a lot of sense to you. And, unfortunately, there are so many different things that you could be doing you just only need to take a step back and understand what does your organization need first from a priority perspective and then come with a plan. There's also another thought process, which is you could do multiple things in parallel. So, while you are building on more of a real last plan, certainly don't miss on the opportunity to do as much testing as you earn. In the interim. Because, again, depending on your audience for many people, the comfort that they get from resilience is by seeing the fact that they have passed or they were able to successfully test or they were able to prove they are shown So again, it depends on your organization. It depends on your clients and so forth. How can you give them the comfort that you are being reasonable and you want to look into those. So, it might be in some organizations, your business BIA might be a priority for some documentation of playbooks. And for a few others, it may be doing more of testing assurance than anything else. I'll come back to testing, because I have a question on that coming up, but I'm glad that you raised it. But what I'm hearing is, this is a conversation. It's an ongoing debate. It's not simply being in receipt of regulatory dictate, because if you chase that, you may lose what your customers actually want from you. And and I came across a fascinating statistic recently about negotiations, whether they be commercial, whether they be corporate, whatever. The majority of negotiations fail not because the two sides can't reach agreement, but because parties within one side do not have the same understanding of what their priorities are in this situation, and I think that's worth sharing here is that very often, you may have people within the same organization. Be very, very surprised to learn that there are different understandings of priorities going on when it comes to things like technology resilience. I wonder, I'll put that out to the to the audience see if they would recognize that. But thank you for those excellent answers. I'll ask the audience one more poll, and then I've got three more Did we use I think we lost mister mister Haywood. I'm just gonna take over for a moment and open up the poll question. So I'll just open it up now. The question for the audience is, what's the most pressing technology resilience challenge your organization has. Option A, sorry, just give me one second. Option A is resilience is not seen as a priority or as a focus or priority, competing priorities, b, the pace of technology change, c, evidencing an ability to recover, to regular tours, the changing landscape of regulation as it applies to if is firms, or the other. Just to just to allow a few more seconds for you all to respond. I'm gonna go through it again. What's the most pressing technology resilience challenge your organization has? Option A is resilience is not seen as a focus or priority, competing priorities, b, the pace of technology change, c, evidencing an ability to recover, to regulatory, the changing landscape of regulation as it applies to if it's firms, and d is other So, by this by this point, we should have some we should have some answers. Ever, I'm gonna just before we reveal the answers, I want to just allow Mark a few more moments to join so he can be with us when we do reveal the answers. Maybe in the meantime, I can move I can move the slide over to the next panel question. We have, how are you approaching your testing? And how does this differ based on your organization's size? And the regular regulation, which may apply to you in relation to this. Who would like to grab this? Maybe -- Yeah. -- okay, great. Thank you. I'm happy to take this. The way I would answer this question is, for first, I'll keep this agnostic to an organization. So, I'll give you more of a general response because I think This could vary depending on our audience. So, if you are a big organization, then of course, when you're thinking about testing, The way you're approaching testing is going to be at different dimensions, right? You are going to look at testing more from a vanilla it perspective. So, where you're testing your, the failure capabilities of your applications and systems and so forth. Of all your But then you're also going to approach testing at a different level, which is where you're thinking about multiple asset failures at the same time. Now, the way you want to do this at the end of the day is based off whatever threat vectors that you have for your organization. So, you aren't step back, understand your landscape and come up with the scenarios that are most relevant to you. And once you figure out the relevant scenarios, those are the ones that you want to test and make sure that you are resilient against. Now, again, when you think about testing, it's also, there's a definite resource that you have. So, testing all different scenarios is not going to be feasible. So again, you want to apply the logic in terms of how many of those scenarios can you off. So if you did have a crisis, how many of those you're willing to, or to absorb the risk to a certain degree. And then, of course, when you think about testing, the other element to come there is how do you plan to test? What sort of simulation are you going to use? If is going to be a tabletop? Is this going to be an actual physical simulation? Is this going to be during your business hours after business hours? Now, all of that has to be taken into consideration as well. So if you ask me the way you should be approaching testing is it's like a portfolio or a menu of different types of tests that you're doing for your organization at a very basic level, you wanna make sure your assets are all linked to test on a periodic basis. And then you want to layer it up with scenarios, which are most relevant to you. And you are to test those multiple of failure scenarios. More from a front to back perspective. So, yeah, yes, you are into tabletops. You wanna do simulation. I wouldn't say one versus the other. It's going to be a combination. And you want to make sure you are not just evolving, since we're talking about technology here, not just your engineering technology teams, but you are thinking about it from front to back, right? You are intubating your business users, wear feasible, your third parties, wear easily, your appliance, and so forth, you want to make sure you're testing the entire spectrum, not just from a recovery perspective, but also are you going to manage crisis? What are -- what's the kind of communications you're going to be sending out? You want to look into all those dimensions as well. Thank you, Anita, and Kyle, thank you very much for covering. We're currently running on generator power here. So that took us sixty seconds to get back online. So again, expect technology to fail. And the generator has been tested, because I can now speak to you. But thank you for covering. And I need to thank you for that answer. My records tell me that you were first to answer that. So, Mark, could I ask you the could I ask you the same question, please, sir? Of course, of course. And continuing with some of what Anita was saying, testing is a very broad subject. Sort of like how do you approach your health? Well, there's a whole lot of ways to do that. Right? And it's it's multifaceted and you have to look at each of them. I also draw a distinction between testing and exercising. Exercises are intended to develop muscle memory. So that when an event happens, we don't have to think about as much. We just go to that muscle memory and execute. And I and I often use the example of you know, Apollo thirteen if you've seen them moving. When they had a challenge, they went to books and they started looking at them. Not that they haven't found through those exercises exhaustively for hours and hours and hours before that flight, but they go those books because they want to do it consistent they wanna do it the way that they that they trained to do it. Testing is about proving an ability that you say you have. So if you indicate an application owner indicates I can recover from this level of impact. Within twelve hours, testing shows that you can. So when you think about how you implement your testing and exercising. Think about those differently, but align them in a complementary way. Number one. Two, you have to be able to know that you can recover from whatever level of impact you choose to determine. The regulators will drive you, like I talked last time, to some very severe impact What is commonly referred to as severe but possible from a regulatory perspective You do need to know about those, but you also likely are not being impacted on a daily or weekly basis by those events. You're being impacted by regular failures. Most organizations are reasonably good at addressing common system failures and outages. Because we've tested those, we've tested them for decades. The ones that I would recommend and the regulators are really pushing to address are very cyber centric because we're not as prepared. The traditional way of thinking about how a failure impact will happen, changes when you look at it from a cyber perspective. We've depended on distance as an example as a mitigating factor for technology impacts when we talk about traditional failures or impacts such as natural disasters. Geography has zero bearing when you talk about a cyber attack. All of those geographic barriers are are removed. We've spent decades designing systems that can transact incredibly fast. We do replication instantaneously so that we can take a normal failure and move over to a backup copy or a secondary copy. When you insert that cyber scenario on the cyber threats, those just become incredibly fast vehicles to cause disruption as as, you know, corruption, for example. Is very rapidly perpetrated around the globe depending on the footprint. So you've got to think about those impacts and think very heavily about testing against cyber scenarios. And not just pay out your scenarios. Got it, look at the big aspects. We can test the parts. You've got to look at the big ones too, such as routing away from major data center. For many of us, that is a very disconcerting thought. To essentially turn off a data center. We all believe we can recover from it. But actually showing that we can becomes it comes with a lot of trepidation, but that's what the regulatory environment is expecting us to be able to do. Yes. And, it's a frustration of many people I'm sure on this call. That they're being forced almost down a path of practicing one way and then playing a completely different way. And I wonder if the audience would recognize this many of you have a testing regime, which you simply wouldn't use in the event of a catastrophic scenario. They're not joined up. They're getting better, but they're not as joined up. When I talk to the team at Cutover, they they tell me that some of their clients are moving towards this you know, almost no you can't have zero notice. That's called an actual incident. But if you can have, you know, traditionally when I did the job that you guys do now, I could guarantee you a ninety five percent success rate. I just needed three things. I needed three months notice, and I needed a hundred fifty people in IT working over the weekend, that could deliver you anything you wanted. Anything outside that, I would really struggle with. So I certainly wasn't practicing like I was playing. And it comes back to the point you made, Mark, about it being the conversation with the regulator about why are you forcing me down this? When actually we think these things are much more likely to happen. And therefore, we should try and test those things first. Kyle has kindly told me that we did the poll questions, but not the results. So I will attempt to move us on and have a look at those results now. Okay. Right. What the question was, what what's the most pressing technology resilience challenge your organization has? Twenty one point seven percent of you said, the resilience simply isn't seen as a focus or a priority or there are competing priorities, I certainly recognize that. Twenty six percent over a quarter, the pace of technology change. I have some news. I don't think that's gonna get any slower. Evidenceencing an ability to recover to regulators or changing landscape of regulation as it applies to financial services firms. That's a whopping thirty percent of you are struggling with that. With over twenty percent and maybe we can dig into offline, what the other is in that twenty percent. The pace of technology change prompts one question that Warren put in earlier on, which is if we have time, could we talk about the impact of AI? On this landscape, because that's really all wrapped up into the pace of technology change. And Sophie's asked a question. Thank you to you so What are what are your suggestions on building resilience against third party risks? We'll come to that. I certainly think firms should be doing that because regulation, those of you that are based in Europe will know the piece of regulation Dora. That's a huge part of Dora is third party risk as it relates to ICT suppliers. But we'll come to all of those things. So maybe Anita and Mark, maybe there are some things that we can build in in terms of our answers. But, yeah, I think evidencing and ability to recover, to regulate it. I certainly think that the team at Cutover would recognize that, and they're trying to help clients do that through the through the orchestration platform. But I have a fourth question to Mark. I'll come to you this time, please. How can you align your approach to technology resilience across the entire organization? Is that something that you would recognize as being a problem because of perhaps competing priorities or different understandings or different concerns. But how are you approaching that? Sure. So thought I've been in the last eight or nine years to two different firms. One very large top five US Bank and then currently at TD Bank. I have not seen this to be the problem. What I've seen to be the challenge is prioritization of implementing resilience change. So improving reliability or recoverability, which are different, right, improving reliability, people could understand the value of that at the business level because they don't want their customers coming and saying, hey, I couldn't get money out of an ATM. I couldn't get a wire generator. I couldn't make a transfer. When you're talking about preemptively doing that and protecting against those severe but plausible scenarios, it's expensive. And the likelihood of it happening is lower The reason the regulators are so focused on it is because of the potential duration of impact, right? We can observe the small ones and it's not to pick a deal. Also keep in mind that regulators are concerned, first and foremost, about stability and confidence in the financial system. Yeah. Secondly, about the firm itself. Right? They'll look at both But you have to understand that lens because those are the things that they're really going to be concerned in. Also why your big money center bank function as essentially a financial utility for the industry are going to be much more heavily regulated and have a much higher bar than those one that are consumers of that of that core. So there's always that trade off and debate with your your various CIOs as an example. I have a million dollars to invest into this technology. I can either bring about new capabilities that will generate more revenue, bring more customers to our bank, etcetera, or I can invest it in something that a customer isn't going to see and the likelihood of them understanding the benefit of are very low. So you get into those debates. And so it has to really be a mandate. Now this is where for most of us, the regulatory drive actually benefits us, is we can use that regulatory requirement lever to force those things that we know need to be done, but are hard decisions to make across the business. The second thing I'll add into there is aligning it across the the organization, focus on that infrastructure. Layer. Everybody understands they have to have a network. They have they understand they have to have authentication. But when you start mapping the dependency for your business systems, it will quickly turn into a layer that's opaque to the people who actually operate it. They'll understand typically their business applications. As soon as you start getting into middleware, and down into the base layer, the infrastructure layer. They just don't understand, and they shouldn't be expected to. They consume it as a utility. Right? They say, I don't know. I send a file from this system to this system. I I don't know the mechanics of how that works. That's the responsibility that we as technologists have to understand and and perform for them. So if you focus on that base layer of infrastructure, if something happens there, you're taking out your whole institution. The focus there you can bring that criticality to people. They will understand it. The business will understand it. Your CIOs will understand it, and it makes the biggest benefit potential impact to your organization. Yeah. You're not, you're partnering, you're not testing, you're partnering, having a business conversation. I I completely completely agree with that, Mark. Anita, same question to you. Not currently hearing you anita. Sorry. My response is going to be very similar as well. It's suddenly you want to focus on your infrastructure. I think that's going to be essential. Because it's going to be, in some ways, opaque to your business users. So you want to make sure, essentially, you are taking down it. The second element is is just being comfortable with the idea that it's gonna be very difficult for you to align your approach technology. Resilience across all your businesses. Within the end of the day, what you're concerned about is your process or your business resilience. And that's sense where you wanna make sure you're continuing your business. And the way they deal with technology for every business within your organization can be different. This, of course, is assuming your organization has multiple different types of businesses running, right? So in those circumstances, you come up with a framework, you come up with a a menu of different solutions that you could have, in terms of keeping your technology resilient or your processes resilient. And then you'll leave it up to the divisions or the teams itself. To figure out how Which one makes more sense to them in terms of investing their resources. So in some cases, it may be where they want to do more in terms of building their technology versus in some situations, it might be as simple as Well, I'm going to solve that risk of technology not working down circumstances, in which case I'm going to use alternative mechanisms. Manuals or processes as well. So it it's just being comfortable with the idea that It's not going to be just one solution that fits all, especially if you have different types of businesses and different types of processes and clients and third parties that you're dealing with. Across? So aligning an aligning your approach is not the same as delivering the same solution for everybody is what you're say, it's about agreeing that there is a framework, there is a methodology that we have adopted, and we have, in conjunction with you, work out that actually there's no point giving you this solution because it's too expensive. You don't need it. We've we've understood what we think that you need. So yeah, that's a really interesting point, isn't it? Because often people can think that an alignment of approach means the solution is exactly the same, whereas you're saying is it very clearly isn't. Exactly. You need to have an alignment on your philosophy of how you're managing British audience, not so much they approach themselves, and then new you kind of, you know, you customize your solutions depending on whatever is worth is worth that recognition within your team. Absolutely. Alright. We have, I have one final question for you and then we'll deal with some of the questions from the audience So this one, first to you, Anita, which areas of your recovery plan are proving to be the most important and valued and valuable to minimize your exposure to a threat. I'm not asking you to share what we would call the crown jewels with the audience here, but if there are a couple of interesting things that you can share, that would be very valuable. Yeah. And suddenly, this isn't our my response is gonna be very agnostic from your organization. This is not specific to what I'm dealing with through any. But the reality is when you do look into your recovery plan, what would be interesting and what's interesting for most organizations or generally is we all tend to pay a lot of attention in terms of the solutions for recovery themselves, right? So if I were to fail over an application. I would pay a lot of attention in terms of how do I actually fail over the application. You would have tested that and so forth. I'll times. The piece that's coming out and that's being more prevalent when you start thinking about integrating technology resources. So forth, is your crisis managed. How are you actually managing your crisis when it does happen? Because you are certainly testing your solutions. But are you managing the teams that needs to notify if there was a crisis? Are you managing your your upper management, your, your teams, your other colleagues, and communication that needs to happen. External to the organizations and so forth. How well are you integrating your crisis management to your recovery program itself. And I think that's becoming more and more obvious for organizations as they start detailing their recovery plans and playbooks, and they are thinking more about integrating technology or, say, third party or war resellers as a part of their program. Thank you very much. And and Mark, same question to you. Would you recognize a lot of what Anita says? Certainly. And so when we think about it in five pillars and we look at technology, the most critical thing is to assess. Where are you at? Where are your gaps? And the gaps are variable because the reliability requirements for an application or piece of technology per variable. Don't build it anymore reliable it needs to be. Right? And you'll get a lot of push from regulators to say, However of your structure. If this is a tier two application, it requires six hour recovery. But you're showing it's dependent on this application, which is a tier five, which is twenty four hours. How can that be? And the reality is you have to know how those are used, and it may be perfectly fine because you have substitutability. For that next level down of application. So having reliability spread across allows you greater protection against some of the threat. But we look in the in these five pillars, what are those in security? Specifically, in that case, for resilience. Is the application or piece of technology able to defend itself from attack? Alright? There's a lot of aspects for cyber security, but that's the key one that you need for resilience. Is it able to defend itself? What's its level of of availability? Is it hot cold? Is it hot standby? Is it hot hot? The triple hot, etcetera? Which your concentration if you're leveraging a cloud, which your risk of that that cloud going away and impacting all of your instances. Recovery, which we've talked about, how rapidly it can recover, how rapidly do you need to recover? Do you really need to cut recover all the way? Or is there a partial level of recovery so that you can return to mark it versus return to normal, which is something that your regulators will will be keen on. Operations, includes monitoring. Do you know if it's healthy or not? Do you have all the right agents? Are they going to the right places? Are people responding to them and looking at them There's an enormous amount of hygiene that happens within here in order for these systems to be recoverable highly available, etcetera. And then finally, one item that I wanted to touch on a bit is data integrity. So we look at the data within those, and and this is something I've talked a lot about internally to our organization, is most most organizations are still thinking about data as a subset of an application. At application a, it owns data b. I think that's an area that we need to change our thinking dramatically on. And we need to think about data as a completely separate asset. From the application that may house it or may use it, and where you'll see the regulators going. Is they've been on a ransomware kick for a while. Right? Because it's something people can relate to. I wanna know how you're gonna recover from the ransomware event. From a cyber perspective, ransomware is simply data destruction with extortion. Right? Typically, again, it'd be co coupled with data extraction. Right? So you have multiple risk involved. But Everything that we do in technology when it comes down to it is data about retrieving data, storing data, manipulating data, delivering data, The data is really the core of everything technology, and you're going to see the regulators starting to push especially in the large firms for them to understand that data environment and to demonstrate that they know how to reconstruct data. And this is going to be the key shift as well that we're already seeing in the large firms is not enough to just recover. Failover is not enough. They want to see testing on reconstruction. If you have a destroyed environment due to a cyber attack, how are you going to rebuild that environment, essentially from scratch. And mutability obviously is a key aspect of that, but if you are not able to recover that data at all through a restoration, do you know the lineage of that data? And do you know how to reconstruct it from the base elements in order to get back to a functional state. So don't forget to think about your data separately from your applications. Mark, that's a great answer. Could I just ask you to very briefly, could you just recap those pillars at a very high level for us? Sure. Social security, availability, recovery, operations, and data integrity. Wonderful. Thank you very much. I'm hearing a lot here, and I I'm just conscious that there may be people on this call who were worried that they're, you know, way behind the curve in terms of their, you know, their resilience journey. So if you are feeling that, please don't worry. Everyone has been in the same situation. Everyone is struggling with these issues and everyone is trying to do what I need to remark are doing, which is find their way through it. But just a couple of of key highlights for me personally, and then we'll go to to q and a, I I've heard Mark talk about the fact that if you slavishly follow what the regulators want you to do, and you should absolutely pay attention to what they want you to do, because the fines from not doing that can be extremely punitive. But you might miss what your customers act actually want you to do. So these are not separate conversations. This is a joined up conversation. I thought that was extremely useful as a as a takeaway is don't ignore your customers at the expense of doing what the regulator as one. And I loved Anita's comment about aligning your approach doesn't mean the same thing as implementing the same solution across your organization, not everything needs the million dollar solution. It really doesn't. We have five or six minutes left, I'm gonna go to Sophie's question first, which is one of your suggestions on building resilience again third party risks, an organization like yours will have thousands upon thousands of third party that provide services to the organization, and I'm sure that other organizations would recognize this. The regulators have been on a journey about two things really. Over the last ten years. One is the cyber question that Mark has talked about. The other is, do you understand your third parties? Can I ask you, to what extent do you involve the needs of third parties in your testing? Well, in in reality, when you're thinking about the operational resilience program, right? Most organizations now are very much involved in third parties as a part of their its testing. Now, if it is how much of them being a part of every test you go through, that again, you know, it depends. Depending on the criticality of the third party, there are certain situations where you want to engage with the third party themselves and see if they can be a part of the testing that you're going through. But in some cases, it's not so much of building resilience against a third party means you gotta tasked with a third party. Right? In some cases, it might mean it's just making sure that you have alternatives defined if the result if the third party available, right? The fact that you have multiple third parties that support some of your, say, your critical functions. Figuring out what would it take for you to bring that activity in house if you wanted to for a short duration of time when the third party is recovering? So there are a lot of other things that you should take into consideration here. Before you you assume that the only way you could make sure the third party resilience is via testing along with the third potties themselves. I hope that answers the question. No, it's a great challenge and very sage advice. Thank you. Mark, anything to add on that? The only thing I'll add is that I think of a difference between resilience of our third party's and resilience against our third parties is you can make the third party you can work with them to make sure that you understand how resilient they are. But at the end of the day, you can't trust them, period. Right? If they're if they're incredibly critical to your business, you have to have a way to substitute for them. That can be difficult with some. But you can't entirely you can't advocate responsibility for resilience for your business services? Yes. And it reminds me, this has come screaming back from my days as a practitioner is that there would be a lot of busy work done around asking suppliers whether they had a resilience program, which is useful to a point, but then after a point, it gets completely useless because the answer is not have you got a resilience program. That's not the answer you're looking for. What you want to know is, in the event that you have a problem, am I on the list of your priorities, because if not, I have a big, big problem. So I think, Sophie, to that, I'd be very clear about what problem are you trying to solve here? Because it's if it's simply identifying what what risks you've got and and are your suppliers doing things to to help. That's that only gets you part of the answer. What you want to know is how much of priority you and your organization is to them, in the event that they had a problem. And again, this has come up for the, I think, the fourth time now, it is not the same solution for everybody, you don't need to involve everybody in testing. Some people, I think it's entirely appropriate for, but others potentially not. Guys, I think we're just about out of time. So on Anita and Mark's behalf, I would like to thank you, our audience, for giving us this hour of your time today. And on your behalf, I would like to thank Anita and Mark for their candor, for their expertise, and their willingness to share. I'm sure that some of this will be useful to your colleagues. I'm sure that all of the cutover team would recognize the problem that you're having. If you'd like to get in touch, we are on LinkedIn, or you can send an email to info at cutover dot com. But with one minute left Kyle, thank you very much for stepping in when I had a power problem earlier on. I'll hand the show back to you. Great. No worries, Mark. I just want to say a special thank you to our amazing panelists for joining us today. Thank you for your great insights, the collaboration, and ultimately being so generous with your time to it. It was a fantastic and engaging discussion. So, on behalf of myself and Mox. It was, thank you very much for for this amazing session. Just wanna quickly turn things over to the audience. Just a reminder to look out for an email within the next two hours that will contain links to view today's material. And we would love to hear your survey, a very brief Sorry, I was gonna say, I would love to hear your feedback, a very brief survey will pop up when you screen a cessation in. And we would really appreciate anything that you have to say. On behalf of Cut on behalf of -- on behalf of Cutover and market skimmers Just like to thank you all for joining us today, and I wish you all an amazing day ahead. Thank you, everyone, and see you again at next event. Bye bye. Thank you. Thank you. Thank you. Thank you.
.webp)
