Hi everyone. This is Karl here from Marcus Evans. Thank you so much for joining us today on this webinar on disaster recovery plans you can prove. Build assured resilience through AI implementation in disaster recovery. This is brought to you in partnership with CutOver. Before we begin, I'd like to cover just a few housekeeping items. As you could see at the bottom of your screen are multiple application widgets. Very sizable and movable, so please move them around to get the most out of your desktop space. Also, I'd like to encourage you to submit any questions that you might have by using the q and a widget, and we'll try to answer as many as possible throughout the broadcast. However, if a full answer is needed or we perhaps run out of time, we'll make sure to send you an email afterwards. I also like to draw your attention to the resource list that will contain a copy of today's slide deck, some interesting articles, and please bookmark any links that you find useful. To answer any common technical issues, I advise to use the help widget, And finally, a reminder to look out for an email within the next two hours with links to review today's session. At this point, I'm very pleased to introduce you to our moderator and our host. We have with us Kai Niccol, is the CEO at Cutover. And I'm, happy to hand over to you Kai and take it away. Thank you very much, Kyle. I'm very excited today to have a great set of panelists to share their insights with you, but a hard one over many years of experience in particular topic and area. What we'll do is we'll we'll have those panelists take you through a little bit of their background and then I'll introduce myself a little bit more. There's some important disclaimer stuff to go through and then we'll get into the discussion that I'm very excited about. So without further ado, let me pull up the slide that shows the speakers that we've got today, great set of speakers and if Marsha, I could ask you to introduce yourself to the audience. Hi, everyone. So I'm an operational resilience and business continuity expert. My primary portion of my career has been with HSBC in The Middle East and in Asia Pacific. And currently, I am performing the role of a vice president for Sumitomo Mitsui Banking Corporation here in Toronto. On the sideline, I also am a director on the Resilience Information Exchange Association where we conduct, you know, multiple sessions and symposiums and there's one coming up pretty soon. Yeah. That's sweet. Thank you very much, Marcia. And perhaps Audem, I could ask you to provide an introduction, please. Good morning. So my name is Autumn Golub. I lead the second line operational resilience oversight function for PNC Bank. In this capacity, I'm responsible for the overall strategy, design and execution of the second line oversight function for all of our resilience functions. So if you think about resilience and recovery and crisis management programs, that sits under my second line purview. Prior to that, well I've been with the bank for fifteen years, but in prior roles here at the organization, I've served as a subject matter expert on third party risk management, corporate records and information management, and supply chain. Again, thanks for having me, excited to join this panel this morning. You're much, Autumn. And, Mandal, it'd be great to get your introduction as well, please. Great, Kai. Thank you. My name is Mandal Righi. I am in the second line at State Street. My portfolio today covers technology, cyber, data risk, the impact of AI to all of those, as well as third party and resiliency. Before I was at State Street, I spent a number of years at other similar GSIBs, including State Street and TD. And then before that, I spent a number of years in consulting, between a number of, big four firms. And here, my focus really is on driving that nexus between, technology and the business. Thank you very much, Amanda. And as Kyle said, I'm Kai Nickel, CEO and cofounder of Cutover. And just to give you a brief introduction to Cutover, we are the system of execution powering technology resilience in many of the world's largest and most sophisticated enterprises. We help organizations orchestrate recovery across humans, agents, and the wider technology investments, and we handle and help, with recovery from various causes, cyber, tech, and wider, and that it's not for live recoveries as well as the ability to test that in in various regulatory frameworks. Great. So let me move to the next slide. Very important point is the disclaimer today that that permits a useful discussion. And that disclaimer is that the views expressed during this webinar belong solely to the participants on their experience as a business professional. These views do not represent those of the participants' employers or any other groups they may be affiliated with and they are not an endorsement of any solutions or services associated with the webinar including those of the Marcus Evans group. Great to make sure we've made that statement. So in terms of the first question, we can kick off on the useful discussion to get the panelists' perspective. The first question is when you're putting together disaster recovery plans, how do you show these plans can be proven rather than just planned in theory, which is the the the, I suppose, a common ask we see in the space at the moment of way of just having documented plans. How do you show these plans are executable and have been executed in earnest in testing and wider scenarios? And perhaps Audem, I could come to you first for your perspective on this. Yeah, thanks. I appreciate it, Kai. So when I think about the disaster recovery plan and it becoming provable, the first thing that comes to mind for me is it's tying it to a measurable recovery outcome or objective, right? So making sure we're really clear on what we're trying to achieve. And then also you touched on this, Testing it under realistic conditions, really stressing them, and then support it from evidence. So, you know, it's not really enough to just point to documentation or have the documentation, but the plan needs to demonstrate that not only the technology works, but, you know, the technology, the people, the dependencies, and the decision points, that they all work in tandem, right? So that when we are experiencing a disruption, that these plans work really well together to give us the outcome that we're looking for. So I really think about that kind of through three, maybe three components, right? So one is their defined outcome. So what service or capacity or capability rather must be recovered by when into what level of functionality, right? So just because you're bringing the systems back up or, you know, your technology back up, it doesn't mean that everything has to be 100%. So it has to be clear going in and understanding in your plan what is the minimum viable product. You may be able to limp through with degradated service, but you have to make sure that that is really crystal clear from the onset. The second piece that I consider is really the scenario based testing. So has the plan really been executed and exercised against realistic failure conditions? Not theoretical, but really, you know, these realistic conditions that we've experienced as an industry just in general, whether that's financial sector or really just the marketplace. Things are happening all the time, right? So let's use realistic failure conditions to be able to test the plans. And that should include your dependencies, degradated operations that I mentioned earlier, and any timing constraints. And then the third piece of that is the evidence. So what artifacts do we have that show what happened, what works, what didn't work through the testing, and then whether those recovery objectives could potentially be met or not met. So those plans, in my opinion, the strongest plans are really when you can take technical recovery and you couple that with business impact tolerances, right? So it's not just technology in isolation, it's bringing the business forward and making sure that that technology is up and running in support of the business impact tolerances. Again, which should be defined well in advance, of your plan of testing and exercises. And then from a second line perspective, within my role, I really want to know that the organization can demonstrate recovery readiness and just not relying on assumptions and not just relying on the technology components. There's a lot to it to make sure that the business can continue operations. So that's really how I think about proving out those Doctor plans, Kai. Well, thank you very much, Oden. That was a super comprehensive answer. I think one bit that certainly resonated with me in that is the sort of minimum viable capabilities in recovery, which I think often historically had separated the folks a financial institution that dealt with major incident, the folks that dealt with disaster recovery where previously it was often felt that disaster recovery had to bring up the entire capability to be absolutely 100%, where in reality a lot of times you can get by with the degraded service because the 100% fix take longer and cause more of an impact. So I I really like the the points that you that you raised there. And I wonder if, Marsha, you you want to add to that. Yeah. Actually, Autumn did a great job in covering everything. I would second the whole simulation piece, you know, gone are the days when tabletops and paper based exercises used to be there. But yeah, in terms of simulation, I think that's very important. And also, you know, the attempt of layering without an overkill of too many testing. So if you try to break down a bit in between and see whether, you know, multiple applications or multiple servers or data centers have the same approach. And you'll be surprised sometimes to see what comes out of it, you know, what's there in paper than in actual practical sense. But, yeah, sometimes it can be an overkill, but it's an interesting fact that brings out a couple of stuff. Yeah. Nothing. I'll I'll maybe Sorry for it, Panda. I'll maybe double or triple down on the simulation aspect, and I'll just use an example to hopefully illustrate the point. One of the tests I saw fail is because when the test was run, they realized they didn't have enough parking space for people. And those kinds of things cannot be identified on paper, and they had to send people back because they just couldn't get people in the space. So, yes, paper based war p war tables, war games, all of that is all very good and fine, But actually running these things at scale because a lot of time, people will test elements of the Doctor. You know, they'll take down sections of the data center. They'll take down certain applications. But running it as a true test to simulate real world scenarios, that's when these little things pop up where you can either pass or fail in the end. Yeah. And I might just add, Nandar, you know, it's also the consideration for the muster time, right, when you're running these tests, right? People preparing, they know it's coming, they're all sitting around, kind of the virtual table ready to hit the go button, right? So it also has to consider that prep time because that's a real calculation that needs to be considered in that simulation. I love that point. Often I'll talk to folks that they'll label that resilience theater where everybody on call is ready at the keyboard, just waiting. And there's kind of, yeah, you falsification. Think Mada also represent a great point of the reality of something like the thundering herd that can happen in reality if I go AWS region or Azure region goes down. It is very different to sort of doing a a couple of applications failing over between regions. So learning those things. Fantastic insights, I think for our audience. Any further points in this question? Good stuff. I think we should proceed to next question where we will bring in a little bit more on the flavor of how folks are in the early stages of leveraging AI and Agenda capabilities within this domain. So yes, this panel question is how can Agendaq AI support with these plans? And I wondered, Marcia, if I could come to you first on this one. Yeah, sure. So yeah, it's true to what you said, right? Like many of the organizations including myself, we are trying to see what best we can do. Like on the top of my head where we can use agentic AI to support these plans. One, I would say is something around playbook automation. So anything small, not major decisions. We're not talking about orchestrating, you know, switches and stuff like that. We're talking about very low risk, you know, executions that they can do. It is something that we can use in or kind of explore. Another thing that we are looking at is incident tickets. You know, kind of pushing incident tickets into the right buckets and then taking that to the right email IDs and you know, so that the attention from the support team is attentive quickly. Another way that we could look at using AI is bringing up the playbook. So for example, if we are looking at something that goes wrong and it is documented within a playbook or a desktop manual and provided we have that good data inventory, then we could use the agentic AI to bring up that piece of information. So if x goes down, what is documented in that, you know, to say, of course not bring an encyclopedia of bits and pieces across. So a lot needs to go into fine tuning the agent in that. And then maybe the post incident analysis. Right? Like, I know we spend a lot of time in trying to gather information from multiple stakeholders who participated in recovering from that disaster recovery. But what if everybody pushes everything in, even scribble notes, you know, draft notes, use the AI even that we use today, use it to draft that post incident report. And last but not least, Autumn did speak about evidencing, you know, a testing perspective. Prepare a proper, you know, inventory of all the evidences. How do you link that evidence to the particular point that you're looking for? What about timestamps? So at this time, this was done, at this time, this was done. This was the performer. You know, those kinds of bits and pieces. And let's be honest, so much of our time goes into a lot of administrative logistics during an incident and post an incident. So something that we can use AI today. And I know we are trying to explore that in trying to reduce that time to spend time on the real, you know, the real ask at hand. I think they're great insights, Moshe. Thank you very much for sharing. I wonder if, Mandal, you had some additional thoughts. Yeah. I think Moshe gave some really great examples. If I if I almost boil it up or roll it up, it's a risk based approach. Right? So there are certain things, and it's gonna be a journey. This is very early for most of us. We are also learning what we are comfortable with or not. And as we get more comfortable, I think we will be more open to be able to rely more on agents to do things for us. But it is going to be a very thoughtful, careful approach as we build that reliance and trust. So the risk based approach goes to, you know, being able to automate, and this is where, you know, we have to be careful because the flip side of it is people can be too reluctant to, to build that trust. So you have to invest in building the trust and and not, hold yourself back. So it's a balance between being that thoughtfulness versus being a little maybe adventurous, to test things out. But more and more, as we do things, you know, let's say, capturing as an example that Marsha gave, maybe that then extends itself into being a lot into allowing agents to run more of the test. Right? So I think it's gonna be a journey in that sense. Points. And Autumn, did you have any additional thoughts? Yeah, I think Marsha and Mandar hit a lot of the really solid points. Maybe two things to add when I think about AI support for the plans. The first one is AI can really significantly support generating very realistic scenarios based off of the risk environment. So where AI can generate plausible scenarios, right, that look at correlated dependency risk across different elements of your ecosystem. So it can help really generate those scenarios and be able to test them at a way maybe the human mind wasn't thinking about or pulling that together as quickly. And then the second thing is, it's really around the value and seeing the risk faster, right? So when you're using AI to support these planned generations, it can take a look and connect data points from different applications throughout the ecosystem, infrastructure, and again, help bring early insight into some of those risks that exist within the current operating environment. So I think AI can play a very solid role in pre, during and post planning and disaster recovery events. I think that they're very useful points and I think we only have three or so to add to that. I'd say building on the great points you've you've shared there. I think number one, I think we also find that, what we get back from AI still isn't maybe as deterministic, as we'd like. I think we all have the the the the component where it comes back and it, you remind me, oh, I forgot. Yes. You're absolutely right. We should start that server first. And, course, we I think through some of the things you're mentioning about how you take tentative steps there where AI is doing things like checking logs, documentation, aspects like that, where we're sort of getting on the the ladder of of building that trust that Mandar mentions. I think secondarily, I feel like that we're we're having to solve a problem where we're gonna have to where we collaborate with agents as if we collaborate with humans, and we've got a whole load of greater governance control for what we allow our human colleagues to do. And it it feels like we've got some ground to take in terms of how we put that stuff in place for the agents, make sure they're not sort of visibly operating in in a not the right frameworks. And then I think that, Automi, you raised a good point of, a lot of the time, a certain number of scenarios were feasible, for an organization of humans to sort of pan out and deal plans, work carefully with various functions and technology because it there weren't enough humans to do many scenarios. But now maybe there's opportunity to cover more as long as you still do have the human in loop to sort of review and make sure it doesn't slop coming out of there. But but, yeah, it is it is a fascinating space. I really appreciate the the aspects you shared. Any further points to share on this question? Okay. Let's let's step forward. So this question is where can the balance be found between human judgment and machine execution? And I wondered if, Mandal, I could come to you first on this one. Sure. You know, the benefit out of human execution and automation is not new to anybody. You know, we've been on this journey between scripting to RPA to ML to now AI and Gen AI versus agent. And we've been on this journey for decades at this point, so that idea is not new. What is new is the level of autonomy, the level of understanding, and the level of control that we have, the deterministic versus the autonomy that agents true agents bring in. Increasingly, what we are looking at is there's a couple of, I would say, deciding attributes. Points so you want to have more human touch at control points, especially when that control point is there's something that's happening that's irreversible or there is ambiguity. You know, in those kinds of situations, you wanna have more of a human touch. But you also have to be, again, thoughtful about that because if you have too much off, there has to be a human in every single decision. You're going to lose the entire benefit of AI and automation. So, you know, if I use, you know, maybe those two or three elements, you know, if you're looking at, as an example, risk acceptances, you you would want to have a human look at it before an acceptance, particularly if it's something high impact. So I think those become some of the key considerations to say, you know, which part of this process can you rely or leverage AI versus which part of it do you still want to retain for now a more human in the loop touch. Yeah. That makes sense. And I wonder if Autumn, you had some thoughts on this one. Yeah, I think Mandar hit it really well. I mean, it's around, what's rules based versus what requires human judgment. And at the end of the day, the human judgment really has to come in where we need the most critical decisions to be made. So if you think about business outcomes, customer impact, and even risk acceptance that Mandar mentioned. So I think it's appropriate for AI to do things like pattern detection or evidence collection, the administrative tasks, but at the end of the day, the human has to decide on what's good enough, and how do we weigh the trade offs in some of those decision points. So machine assisted human accountable in the end. No, it makes total sense to have accountability. Good thoughts there. I wondered, Moshe, if you would add that. Yeah, so immediately like hearing Mandar and Autumn, something that comes to mind is our good old friend, the operational risk matrix. And when we think about, you know, any legal implications or reputational implications that, you know, could harm the firm, In that case, I would still, you know, lean on the caution of human intervention, and I wouldn't bring in, you know, AI automation just just yet. So I think I think that's that's one of the main key factors I would say when we're trying to balance out the thing. And again, to touch on the previous points that we discussed from the previous questions, it's like look at low risk bits for now. Again, it depends on where each individual is and each firm is in their journey, you know, with AI and implementing or adopting it. I think just go with the flow and see how it goes from there. And then you you find that good balance. Kassefa, a great set of insights. Which takes us to the next question was if you're advising a peer institution just starting to explore Agendaq AI and Doctor, what's the one thing you tell them to get right before they go live and one thing mistake that you tell them to avoid? And I wonder if Marsha, I'll come to you first on this one. Okay. It it kind of rolls off from the previous question. So Yeah. Yeah. Again, the same thing. Like if I would advise a peer who's joining the institution, I know that we could get anybody who's like so keen on, you know, switching the turning the switch basically to everything. I wanna put everything on AI. I wanna put build this and I wanna build that and I wanna build the coding. So you have an individual like that, but you also have an individual who's like pretty not into it. And they are like, no, I just wanna do it the way I know how to do stuff. So for the first individual, I would say the same things like, you know, be mindful from a legal, you know, reputational regulatory standpoint, as long as you can maintain audit trails, you can make sure evidences are good. And you know, as long as you are in partial control and you know what's happening, the AI is checked for whenever we have to implement or let it let it run-in sense. As long as you're comfortable with that, go ahead. Like, you know, do step by step implementations on those grounds. But for the other individual who is still who's still not sure, I would say, you know, give it a try. It it is here to stay. We know that. Right? I I think we had the same kind of reservations when people said data science was in it and analysis was there to to stay. And I think we all had our reservations at that point. But today we know that AI come on, let's be honest. We use Copilot literally every day to kind of recheck our emails. These are emails that we've been typing for past twenty odd years, you know what I mean? So I would I would just encourage them to say like, you know, take it slow as long as they are comfortable, as long as they are, you know, along with, you know, the ship that's sailing, like, you know, don't be left behind, like, get there, you know, see what best you can do. That would be my advice too, up here. Yeah. And I think you you captured very well there, Marsha, the the bit as was Bandai mentioned a little bit earlier of that sort of tug of war in the risk framework between how do you get people to try and adopt and do some things, but do it so they don't sort of cause material harm or very important. I wonder, Autumn, if you had some aspects to share on this question. Yeah, so Marshall, I'm completely with you. I mean, it's here to stay, so you have to get comfortable with it. But what I would say is, and this is where my second line role will definitely come into play, right? You have to get the governance model right before execution. So you have to have a control framework in place. Need to know what your guardrails, what your parameters are, what you're willing to live with. And then you need to use case it, right? So you need to have a small, low risk bounded use case to actually execute against. And that's the way that your organization is going to validate and build trust with the technology. And the mistake that I would tell a peer institution to avoid would be don't treat AI as a shortcut of the hard work of disaster So recovery, if plans are stale, dependencies aren't right, ownership's fragmented across the organization, AI is not going to fix that, right? You become a house of cards. And if anything, the risk is most likely going to accelerate. If you're not in good position, it's going to move really fast through your ecosystem. So it has to sit on top of really disciplined resilience practices. I think that's very very good point indeed. Not that wider ownership. And, Mandar, I wondered if you had some insights on this one. Yeah. I guess being an engineer, I'm gonna take what Marcia and Autumn said because I agree with both the points, and I'm gonna convert that into maybe, something actionable. What it really comes down to and, Marcia, you used the word control. Autumn, you used governance. It's really the control plane. In the AI context, it's the control plane. So the control plane really has to be built out, have to be very clear. And this is I think the control plane and having it well defined and articulated helps both parties. It helps the person who's going a little bit wild west, say, where's your controls around this, and how are you getting comfortable? It's okay. And it also helps the person who is reluctant and maybe a little fearful to say, it's going to be okay because we have these controls. So it brings both parties to the sender to be able to drive something that everybody's comfortable with. And then, you know, within the control plane, there are a number of key things you wanna think about. Lease privilege, what are the actions that are allowed? These have to have a kill switch. You know, being building a kill switch you can rely on is absolutely critical. In any control plane, having the audit trails to be able to understand what's happening, testing it. And, you know, Autumn touched on the testing aspect. Having those use cases, testing it particularly for edge cases, that allows you to have a level of comfort that your control plane actually works and that you identified anything that is going to likely to go off the rails and then also being able to ring fence the activity of the agent. All of that then allows you to say, yes. I've built something that I can actually execute against. Because one of the problems with with Doctor is you're already operating in a period of high stress and uncertainty. No real world scenario actually unfolds exactly as you envisioned it. Right? So as it is, this is very different from, you know, from running operations because operations is fairly predictable. In a in a disaster, you are going to have unexpected elements, and that's the last moment when you want to find that you really haven't thought as many things through as you could have. So the control plane and testing it exhaustively with edge cases and use cases is really what gets you there. Yeah. Yeah. Completely agree. Was there were there any further points on this question? Good stuff. No. We appreciate those insights. Let's move to the next question, which is what factors are taken into consideration to ensure the plans can be audited and that evidence is regulator friendly? And where is the line drawn over what is good evidence when a machine took the action in that particular context. And I wondered, Autumn, if I could start with you on this one. Sure. So I would say, good evidence is really when the story is crystal clear and it doesn't need a lot of explanation, right? So it should be very traceable. It should be, you know, kind of going back to my original point at the at the onset of today's discussion is it has to be tied to their recovery objective, right? So if the machine is taking action, I'd want to see evidence that shows the objective, what was the trigger, what's the data that was used, you know, that the agent used as it performed its function, what are the actual functions that it took step by step? What controls were applied to it? And then how was it actually validated? So it should show where we had any human that reviewed it and where there were any exceptions. So at the end of the day, an auditor or an examiner should be able to follow the path from what was the Doctor requirement upfront? What did the machine actually execute on behalf? What was the business outcome? And then making sure that management was making the final decisions on anything that took priority or customer impact. So it's really important, I think, even when I think about this from a second line perspective, we don't want to look at data dumps, right? We want to be able to see a very clear lineage of data and traceability on what actions were taken. So when you have that, that accountability becomes clear, and that's a really key point to all of this is, you know, the accountability of whether it was agent driven or human driven should all be really, really clear. And those items will really help us get to understanding if a test was meaningful, if it really met the objective, you know, the recovery objective, and what were the actions taken by whom, so if anything would go south, it's really clear that we can fix that on the next go round if we're testing it. And hopefully that's not happening in real incidents, but gives us some meaningful information to be able to enhance plans. That's great stuff. I wanted add Marcia if you wanted add to that. Maybe just one bit in terms of, you know, the evidences should also be able to tie back to the playbooks. And, you know, as long as we, yes, one is as Autumn says, the objective, but also like, you know, make sure that we are able to go back and check that, you know, all the steps that were done were according to the playbooks that were that what was documented in the playbooks. And if not, then we know that, you know, we've got further actions on on the point of improving those documented recovery plans that are there. Wise words. And thanks, Marsha. And, Manda, I wonder if you had the thoughts. Sure. Just maybe taking everything said into a practical implementation lens. I'd ask the usual who, why, wait, what, when, how kind of questions. So in this context, it would be, yeah, you know, who are are authorized the action, what was action, what did the machine know at the point of the action, why was a particular action taken, what was the outcome that was achieved going back to the recovery objectives and so on, how well are the business objectives actually achieved, were there any exceptions, that were executed, and, you know, what's the, what's the rationale for that, exception to be accepted? I think, you know, as you trace through all of those, that starts building the auditability and the transparency that any regulator or any stakeholder I mean, they are the meeting regulator expectations, I I typically say, should be a natural outcome of running your business well. So first of all, we need this transparency and accountability understanding for ourselves, to be able to rely on what we are rolling out. And then if we have it, then it becomes so much easier to be able to get stakeholders and regulators comfortable with it. Great stuff. Thank you very much. So I think we have one final panel question before we'll be going to q and a with the audience. So audience members can make sure they do jot down those questions. We'll see how we can get to them within the particular time scales that we have for today's webinar. But, yeah, I'll just on the last panel question, which is what's the single biggest barrier to agenda disaster recovery, technology trust or regulation? And, yeah, Amanda, wonder if you could start us off on this, with more than a, section of one word, so to speak. I think it does come down to one word. And if I had to choose one word, it would be trust. The regulations, of course and regulations typically tend to lag. Right? Technology is already here. So we're already dealing with the technology. The challenge is how well can we ingest that technology to be able to do what we need to do and trust in that technology to deliver the outcomes that we expect. And I think that's going to be a journey because a lot of the things that we've talked about so far in this conversation, as we build the muscle, as we build that understanding And, you know, the challenge also in frontier AI is it is itself is evolving so fast. So Moore's Law has kind of gone out of the window because even if you look at the LLMs, every three months, the capability of LLMs is is more than doubling. So the piece of that is increasing very significantly. That also impacts how you build and execute your plans because what you thought was appropriate and adequate three or six months ago, you may not find it working exactly the way you expect because now your underlying LLMs and the AI itself by nature is learning and evolving. So how do you contain it? How do you have that transparency? I think all of those things impact trust, and building that trust is, to me, going to be a foundational challenge in how we adopt it. Very useful. And I wanted ask Marcia if we'd add to that. Yeah. So if if I had to choose one word from from the question, I would definitely side with Mandar, it's trust. It's surely trust. But one word that I would say out of experience and with all due respect to senior members that are on in the audience, patience. Because I'm sure many of y'all would have experienced this is something goes wrong, we're having an incident, humans are doing what humans do. I want to know now. I wanna be the first person to know what's going on, and I wanna be that person to escalate it to the more senior person. So I will say patience because if patience runs thin, then you might have the perfect AI agent that is running its show. And, you know, there are people who are trying to get more information from that. They're trying to interrupt it. They're trying and you don't know what's, you know, problem that's causing down the line. So, yeah, I would say patience. Oh, very good. In addition, Marsha, and I wondered, Autumn, what your choice would be and any additional work. The single single biggest barrier for me definitely is trust as well. To Mandar's point, technology is going to continue to improve. We're seeing it at lightning speed like we haven't seen before. Regulation will continue to evolve, right? So that will catch up. Although, there's a lot of general principles that are already out there, right? That we're all following. AI just adds a little bit of a nuance to it. But the harder challenge in why I pick trust is really just getting enough confidence across your organization between your business partners, your technology partners, your risk partners, your regulatory stakeholders, to be able to demonstrate that AI is enabled in a way that's safe and can actually work during a high impact recovery situation. So for me, definitely trust is the barrier or the word that I would choose in this context. I think that makes total sense. I think it's not totally not an area to get It's something that can be deployed all too easily, but it's a it'd be valuable. But, yeah, I just wanna thank you all for some fantastic insights over those panel questions. And and now we have the to look at a few questions that have come in from the audience. It's unlikely we'll be able to get through all the questions from the audience, but I I've seen a a few come through. And there are some that are asking us some questions that are, I suppose, a little bit more around traditional disaster recovery. So maybe if I read the the the first question, and we can decide who wants to take a lead on it. So the first is, in what way do you need to gauge approaches if something looks like it won't hold up or if a real incident occurs and the plan didn't turn out as expected? And I wondered if anybody wanted to start on that one. Then obviously, we'll make sure everyone's got a chance to give their opinion. I'm happy to kick that one off. Thanks a lot. So if something looks like it's not going to hold up on paper, I would consider that a gift, right? So you get the opportunity to pressure test the assumptions before the plan's ever needed in a real live disruption. So that's the moment you can ask yourself, like, will this plan work? What are the dependencies? What could break? What workarounds or alternatives and trade offs are we going to make? If it's in a real incident, I mean, that's a game changer, right? So you have to really shift away from executing against your plan and managing that recovery objective, right? So you want to make sure that you're quickly assessing the situation, what those trade off decision, trade offs and workarounds could potentially be, and getting the right people at the table to make the decision. So again, know, your business, your technology, third parties, you know, third parties could be a key stakeholder in a disruption, making sure that they have a seat at the table. Once you have those decision makers there, you have that opportunity to make the right trade off decisions. And then afterward, you know, the gap really becomes the evidence and, you know, to use an old saying, I think we've all heard, you know, you never let a good crisis go to waste, right? You take a look at what surprised us during that incident. What did we have to improvise? Where did we limp along? Where did we have to, you kind of work through that with degradated or outage services? And then being able to use that to improve plans, not just the plan, the one instance that we've seen a failure, but across the ecosystem, like taking that lesson learned and then applying it everywhere to make sure that we're closing a more broader gap, you know, could be universal in nature. So that's that's the way I would see that approach to Thank you very much, Morten. And I wondered, Mandar, did you have any thoughts on this one? Yeah. I think I'll focus more on the real incident. In that, the control plane becomes really critical. And the kill switch in you know, particularly if you have an agent that's doing something unexpected, being able to step in and manage it very quickly becomes absolutely critical. In in addition to that, you you know, we've when we've done these exercises in preparation for a for a doctor test, trying to keep them as real life as possible. So an example of that is when we are doing a tabletop. Obviously, everybody has playbooks. They're trying to execute against the playbooks. We will try and make it as dynamic as possible. So as an example of that is walking around the table and suddenly tapping somebody on the shoulder to say, this person is no longer available. Now what? Or this capability, this has suddenly changed. Sometimes getting people mentally prepared that things are going to change and we are going to have to think on the fly and it is not going to be perfect. Now to Marcia's point on having the patience with that and the resiliency, not just in the technology environment and the business, but resiliency in the people, I think becomes critical for success. Basically, Mandara, Autumn, I mean, you've covered everything. I don't think there's anything more I can add on that except maybe it just from a real incident perspective, I think our first step would be to stabilize, you know, what's happening and then take the necessary actions. And if if the documented plan is not working the way it's supposed to, then, you know, we just have to make those changes eventually. But for the time being, stabilize the real incident. There's that advantage to having involved and keeping, you know, crisis management teams on standby and, you know, so that to Autumn's point, we have all the good decision makers ready. So I would just say that. Sorry. Kai, are you on mute? Yes. I was. Apologies. Sorry. No. Thank you. Yeah. I think you you you you all raised good points around the closing the gap between what's used for test, what's used for incidents. I think that's a that's a great theme and an evolution in the industry over recent years to make sure that a a capability can be in real give overall resilience uplift. That's as per the point earlier, the the sort of test capabilities and resilience theater. And I think there's there's there's a lot more to do there, obviously, but in additional some of the control points that Mandar raised that excellent points. And I think we've got time maybe for one more. And our other question that we've got so far to to look at today is specifically for IT disaster recovery. Which factors have to be considered to ensure the plans are actually executed? And I wondered if you would like to speak first on this. I can kick it off. Thanks, Mandya. I think, I mean, this is something that's been discussed a lot in Doctor conversations over the years. So it's not anything that's unique to to AI, but understanding regulatory expectations. And it really comes down to people process technology at its broadest level. So understanding what are the people that you need, how well are they prepared for it, do they understand what they need to do, The resiliency aspect of the people themselves, you know, the mindset becomes really important. The relationships become really important is, you know, if you bring a bunch of people that have never even spoken to each other in a room and expect them to execute well in at the middle of a disaster, it is going to be a disaster. So helping people build those relationships in addition to the playbooks, looking at things like data protection as an example, understanding your service architectures and how it ties into the business. I think these are all the usual factors of any Doctor or BCP plan that we've all been working on for a number of years. Good stuff, Mandel. Thank you very much. And I wondered, Marsha, did you have anything to add to that? Not really. I'm I'm not the best IT expert here. Oh, okay. But I I I only one thing that comes to mind basically is what Mandar had said earlier. Like even elements of is there proper parking? Do people have to work out the test from home versus in the office? You know, those kind of bits and pieces make make a big Makes sense. And also And I'm sorry. Maybe I'll add one more example in there is and and I think, Kai, this is based on your point on AWS. Everybody is using cloud today, and there's a huge concentration risk. You know, people tend to focus on concentration risk as internal concentration where you're using a particular provider pervasively. Not a lot of people often think about concentration risk as market concentration, where everybody's using the same provider. And what ends up happening there is when you actually have a real market incident, you suddenly realize that your platinum relationship you are just one off another 500 people with a platinum relationship, and you are not on the top of that provider's list. So I think understanding where you are in that hierarchy and what are your alternatives, just relying on the fact that you're a platinum relationship may not help you when there is a real incident. Good good thoughts. And and sorry, Autumn, think you had a Sorry. Sorry. Ahead. No worries. Thanks, I was just going to say, you know, for the IT disaster recovery, like, one of the factors that's big for me, what comes to mind first, is whether the plans reflect the real operating environment, right? Things are changing within the ecosystem at record speed. So whether it's a business process that changed, infrastructure, you have drift within a data center, between your data centers, a lot of things can happen. One of the challenges that recovery is not going to happen in isolation, right? You have to take a look at all of these different factors, the cloud providers, the applications and the different infrastructure dependencies, whether you have concentration risk or single points of failure. So taking all of that into account, applications could rely on any of those items and more. So it's really important that those Doctor plans are kept current with the operating environment, and that's where you can see a really big lift from AI, right, ensuring that it's scanning the environment, helping to ensure that those runbooks and those playbooks are up to date and ready to go when disaster strikes. So a key factor, that operating environment is really up to date in the plans. Totally agree with that. I think that probably makes sense at this point. You conclude today's webinar. I think it's fantastic that the questions have gone through and great insights shared by panelists. And I just want to thank each of the panelists for giving up the time today to share those things with you that I hope as an audience you found those very useful. Certainly did and have taken some notes in the background. And at this point, without further ado, I shall hand back to Kyle. Thank you very much. Great. I just wanna say a very special thank you to our amazing panelists for your great insights and being so generous with your time today. It was a very interesting discussion. Behalf of myself and Marcus Evans, we just like to thank you so much for the collaboration throughout. To turn things, back to the audience, we just like to say thank you for all the great questions and comments that came in. We weren't able to get to all of them. We'll make sure to reach out to you afterwards. And a reminder to look up for an email within the next two hours with the links to review today's material. And finally, we'd love to hear your feedback about what you thought about the webinar today. A survey will pop up on your screen in just a moment. We'd really appreciate any comments that you might have. On behalf of Cutover and Marcus Evans, we'd just like to thank you so much for joining us today and hope to see you again at future events. Thank you, everyone, and have a fantastic day further. Thank you.
