Name: From Crisis to Continuity: Building a Minimum Viable Bank
Uploaded: 2026-03-12T18:01:10.306Z
Duration: 45 min 8 s
Description: From Crisis to Continuity: Building a Minimum Viable Bank

Transcript for "From Crisis to Continuity: Building a Minimum Viable Bank": Good afternoon, everybody, and welcome to our webinar. My name is John Murphy and I am the CISO in residence for customer transformation and strategy here at Rubrik. And our title today is defining the minimum viable bank. What we're going to walk through is a new approach to thinking about your organization when it needs it the most in terms of a cyber resilience event. So I spent a great deal of time, both working for Rubrik as well as spending many decades in industry designing and building cybersecurity programs. And a lot of what we do here at Rubrik is meant to help you to understand how you can speed your response in the event of a cyber event, and also make sure that at any point in time, you've got the ability to communicate to your senior management and your business partners that you're ready to recover the business when it's absolutely needed. So our agenda today really is a quick introduction to the problem space. What are we seeing from a financial services challenge? And this is very much focused on financial services, but the methodology itself applies to any organization or any industry. After we talk about those current challenges, we're going to talk a little bit about the new approach, which has been an environment business. We'll define what that is, and we'll take you through each one of the components as we go through. And then we never like to leave you without something that you can take away for yourselves to actually put some of this into motion within your organizations. If you, if you see the need and you have a desire to try some of this out, and then we'll do some Q and A at the end, we'll probably do Q and A live when we present this seminar. So with that, I'm going to jump right into our discussion and we'll start with kind of laying the groundwork for where are we from a cyber defense perspective? Well, we know that the curve you see here from a worldwide spend on cyber security is trending up and that trend is likely never to go down. And the second piece of this is that we know that the folks who were attacking us specifically, we'll talk about ransomware in this episode, really are also spending a great deal of time increasing the number of attacks and honing their business models. Now, I often talk about threat actors in terms of threat actors, but I think in this case, it also makes sense to talk to them about competitors because they have their own business models and they do look at what is it that they have to do to make the most of those business models, just like we do. So thinking about that from their perspective, they are looking to continue to spend and to continue to earn as much as they possibly can. And so both of those patterns give us really a pretty good insight into where our battle is going to be as they continue to up their innovation and we continue to up what we're doing to protect our organizations. So what's the potential impact for an event that impacts an organization? Well, from a cyber perspective and financial services, the stakes are really high. So we've got seventy one percent of organizations, according to our own research, that have experienced a cyber attack in 2024. We know that the recovery time from a ransomware event, as an example, can be as long as months to a year. However, the immediate impacts usually lasts for a minimum of two to three weeks. And that is to get you back to a level of some operating capability, not a full restoration of services, but the point at which you can go back and look at critical services and say that some of those, the ones that are most important to you from a revenue perspective or mission perspective are back up and running probably in a limited form. And the third piece here is really if you look at what happens during ransomware attacks, I mentioned before that, the upfront event itself, is probably going to last in earnest at least two to three weeks. And then you start to deal with the secondary and tertiary impacts of this. And those secondary and tertiary impacts really spread the impact from a financial perspective, from a regulatory perspective, from immediate impact. What were the threat actors asking for? What did you have to spend to recover your infrastructure to longer term? What did you have to spend after the fact to reply to requests from your customers, reply to requests from regulators in terms of what you did and how well you were protecting your data before the event ever happened? So they're very long lived events, although most of the iceberg to use that example, is what we hear about all the time. A company gets attacked and they spend some period of time recovering, and then they're okay. But if you look underneath the service, you see that iceberg is actually much, much longer than we typically hear about in the news. And for that reason, we also need to talk a little bit about regulatory expectations. So, if you are a financial services organization in The US, let's say, there are a number of organizations and controls that you've got to comply with. But this is also true in The UK, it's true in Australia and Asia Pac, as well as many other regions of the country. More and more regulators are looking at cyber resilience as a way to stem what they're most concerned about, which is systemic financial risk of some kind. What happens to an organization in the event that they have a cyber event? And what's the knock on effect to other organizations, suppliers, partners, customers, who are also potentially going to be impacted by that. And what they're really looking for more than anything else is just that we as practitioners have a handle on what it is that we're doing to protect the organization. And we have a way to evidence to them that we have a plan. So as we go through this, I'd ask you just to think about your country specific regulators and what they're asking for. But I think we can all agree that for the most part, they are all concerned with the same things, which is how do we get our businesses back up and running as quickly as possible? How do we minimize the impact of a cyber event? So as we start to think about what actually happens during the event, there are a couple of things that come to mind immediately. The first piece is, are we wise at this point to assume that it's when it happens, not when it, but not if it happens? And I think the answer to that, we would all agree is yes, right? I think certainly the first time I ever heard that phrase was probably fifteen years ago, and I wasn't a true believer, but I think now we certainly can make the case that you're better off believing that even if it never happens to you, having a plan, in the event that that happens to you is much better positioned to be in than actually not having a plan. So for organizations that have actually gone through this, what we learn is that trust is critical to maintain and trust here applies rather to everybody in your ecosystem, whether it's your customers or your regulators or your internal audiences, your business partners, your technology partners, you've really got to be able to convey to everybody that there is a solid plan and that solid plan gets us back to as much business as usual as quickly as possible as we can manage. The challenge of course is complex environments are, you know, very, very complex to maintain. And so it's not always the easiest thing in the world to be able to point to all of your applications, all of your business services, whatever they are, and say, here's the plan. Here's how we're going to bring everything back up, and get it running as quickly as possible. So part of the challenge here, and this is where NBB starts to apply, is asking yourselves the question in a disruption, what keeps you alive? What are the business services that your customers most care about? And how are you going to make sure that they are still available in the event that you've got a disruption of some kind? I mentioned ransomware quite a bit, but it could be almost any type of cyber event. It could be an event that happens outside of your organizations to a supplier or to a partner of yours. Having a realistic set of scenarios that allow you to practice for these events and then actually demonstrate to yourselves and to regulators and third parties that you've got a plan of action is critical more so than it's ever been in industry today. And our point here is really, you need to start to think about this in terms of what are the core services that your organization provides. We'll use banking as an example, because it's an easy one. But as I mentioned before, this applies to any organization in any industry. And the questions that you really got to ask is what are those things that are core that'll keep, let's say revenue coming in the door, but also allow us to make sure that we can comply with regulations and reduce the impact as quickly as possible for our internal and our external stakeholders? So you think about this and disaster recovery is the thing that I would use for an example. We have been very well practiced in business continuity management disaster recovery for a lot of years. What minimum viable really is, is there's a still version of what that really looks like for organizations. So, it's not so much to say that we would discard what our BCM plan is by any stretch. It's simply that we're going to look at it through the lens of what's most important first. And we'll go through a level of, you know, serial kind of decomposition of those business services until we get to technology and then eventually until we get to the bottom of the technology stack. And what that gives you the ability to do is to see what's most important and what are your, what are the most important things you have to think about beforehand. So you know, the recovery and the order and you can do some proactive testing to make sure that these things are available to us. Second point I'd make here is this is designed to allow you to operate during adverse business conditions. Not so much to say we can pause our business because we're under attack, but actually that we can return ourselves to some level of operating state, maybe not full, but at least a level where customers can still continue to communicate to us, where we can provide the core services that those customers and the markets expect. And then we can also show ourselves in our organization that we've got operational continuity when those normal operations are no longer possible. The whole objective for us as practitioners really should be, if you look at what an event that happens, the time that we lose the most is typically due to responding, reacting, and figuring out things for the first time. As an example, what applications are most important? Do we know what those are? Can we get agreement on those? It's not always the easiest thing to have this conversation, especially when you are dealing with the fact that you've got to make priority decisions around which applications and which services are the most important to the business. The second question is, can we run those in isolation? In other words, are there enough entanglements between our business services that they more than one have to be up in order for us to provide those critical minimal services that keep revenue coming in? And then the last piece is more operational. What order do we bring those things up in? And how do we actually get there? And the objective of those three questions really is if you look at the image on the right side of the slide, is to reduce the amount of time that you're going to spend right in the middle there. So we've broken this down to three areas. The figuring it out phase is the one that's most expensive to any organization. So, if you're unprepared and this happens to you, the organization has to do a fair amount of assessment to know where they stand in terms of recovery process. What's impacting us, what do we need to do to counter it, and who do we need to have in that process? And so the more you can do beforehand to shrink that massive impact section, the faster you're going to be able to respond, and the less you're going to be impacted from a financial and operational perspective. So then we're going to introduce the concept of the minimum viable bank. As I mentioned, this applies to any industry, but I'll use banking here simply because it's one that I know well. But we certainly have use cases here for healthcare, as well as many other industries, public sector as well. So begins really with, you know, an understanding of what your critical functions are. And understanding those can be a heavy lift for most organizations. I'll give you an example. If you have a single product or a small set of products that you provide or services, it may be relatively easy for you to figure out what the most important things are and how you bring those back up. But if you've got many, many different services, and I'll use an example of a multinational organization that competes in many different markets and has products that meet specific deliverables or regulatory requirements for each one of those markets. It may not be the easiest thing to point to one or two or three of those and say, that's what we're going to recover first. You may actually have to get everybody into a room and start to talk about those. And so that's a real problem that we'll discuss as we go through each one of these points in subsequent slides. Second piece of this is resourcing. What do I need from people in a process and a technology perspective? And do I, do I have that information recorded somewhere? Is there a CMDB that points me back to this? Or is there just institutional knowledge that maybe we haven't captured that's not available to us in the event that we have a problem? Emergency response protocols are next. What do we do? How are we going to communicate with the organization in the event that our messaging or core messaging, email, or M365 or wherever that may be, is no longer available to us? Do we have a trusted other way of getting people to communicate through video conferencing or through alternate email channels? And then the fourth is what are the protocols that we're going to use for stakeholders and how are we going to manage those communications? Certainly, one of the things that many organizations learn as they go through this is that there are lots of sources, lots of different opinions about what's happening to the organization. And none of them are necessarily wrong. They just happen to be the perspective of the people who you're talking to at any moment in time. So IT operations, for example, may have a very clear understanding of what the technical issue is. The business stakeholders may have a different understanding of what the technical problem is, but they know pretty well what's impacting their business, their ability to, to actually respond. And executive management who is fielding a lot of these interpretations and a lot of the reports that they're getting from different parts of organization is left to kind of make sense to this and then chart a strategy based upon what's actually happening. The fifth is then data protection and recovery. And I should mention that these are not sequential. You don't necessarily have to look at these in this order by any stretch. These are all things that have to be taken into account. Data protection recovery is probably the one that I would start with most. And that question there really is, do you know what kind of data you have in the environment? Do you know that it's being backed up? And do you have confidence in your ability to restore that data? Should it be impacted in some way, shape, or form? And so there are lots of protection measures that you can use here. Certainly, we talk about rubric in this context because that is what we do better than anyone else in the world. However, every organization needs to have a pretty good understanding of what that is before you can go down the path of charting out your recovery plan. The next piece is testing and drills. So, I have a view of the world that says that you should always be testing your recovery and there should be a consistent process, continuous validation and verification of what controls you have in place and your ability to recover. So, let me state that a little bit more plainly. If you have a recovery plan and you've got high confidence that that recovery plan is achievable, well, there are lots of tools available to us today where you can test that theory out. You can, for instance, use topics like software defined networking infrastructure as a service, and you can build recovery environments on the fly and you can actually start to test the recovery. And the objective here would be to get you to the point where you've got the capability to demonstrate on an ongoing basis with as few people, involved in the process as possible, that you know what your minimum services are, you know what the data is that has to be there to make them work, you know how to communicate this, and you can demonstrate full recovery. Nothing would make the regulators of the world happier with us as practitioners than if we were able to demonstrate that to them. The last piece is scalability and adaptability. Do you have the ability to understand what's going on with your testing methods? And do you have the ability to build upon those? So in the previous step, I talked about, you know, writing scripts, getting this automated as quickly as possible. Do you have a way to maintain those scripts? Do you have the institutional knowledge captured that is going to be needed when those things come together in the heat of a moment? And do you have the ability to continue to grow that as your organization creates new services, creates new things that they want to be able to make sure are part of the minimum viable strategy? And if they're there, do you have the ability to then continue to work on those and demonstrate that they're recoverable? So at this point, I'm going to go into each one of these in just a little bit more detail. But I would ask you as you think about this, what are the top three in your own organization that you would call out right away? I'll make it a point here and I'll switch to this next point just because it brings that up into perspective. Minimum viable business is something that is relatively new, but not a new concept per se. It is just a continuation of what BCMDR really is. And what I mean by that is business continuity management was something that we implemented in the 90s and in the early 2000s, for many organizations. And the objective was to be able to respond to things like natural disasters. What would happen to an organization if we had a flood in the data center? What would happen if we had an electrical outage that impacted part of the country, but not the whole country? Or a hurricane or a tornado? Each one of those were scenarios that we use to plan out what we would do from a recovery perspective involving people, process and technology. And that works. That's still very solid. NDD though focuses on the more functional question of, if I could only recover a few things, what are the things that are most important to us? Even if I can't get full capacity back for those services, what are they? And does everyone agree on what they are? So once you understand what those bare minimum services are, the question then becomes, so what? How does that make me any better than my traditional BCMDR plan? Well, it does so in a number of ways. Probably the most important is from a risk and a resilience mitigation perspective. If you've got the ability to say that you can quickly recover your most critical services from a revenue perspective or from a risk or a mission perspective, you've clearly demonstrated that the organization understands what it is managing from a risk perspective and how it's going to respond in the event that there's a financial or other crisis that calls into question how you provide that service. Second piece is regulatory compliance. So certainly regulators, as we talked about, are very concerned with systemic risk. They want to understand that we know what our part is in this system and that they can understand how they can ensure that the global system that we're part of continues to work if some significant problems befall some of the largest players or maybe just parts of specific economies. Employee confidence and morale as well. We know that our operating environments are complex. We know that most people who work for organizations understand their part of the organization very, very well, but not necessarily the entire part of the organization, Demonstrating everything that the organization does and that you have a plan to recover gives employees the comfort level of knowing that their part in this is clearly understood and extremely critical. Customer trust and satisfaction. If you're providing services to customers, it's important for customers to understand what the contingent effect might be. So if your service is impacted, or more likely if one of your providers has an impact to the service that they provide you, how are you going to provide, continue to provide your mission services? And is there going to be any impact and how will they learn about that? Next up, strategic resource optimization. We all have unlimited wants. We certainly have limited capability to respond to those unlimited wants. So the question comes down to how are we going to leverage the resources that we have and to make the most of them during this type of outage. And lastly, organizations that are good at this have a competitive advantage. If you've got the ability to quickly come back from an interruption in business as usual, you have a leg up on most of your competitors because they may still be struggling with understanding even the most basic questions of what should we focus on first and how do we get things back up and running. So I'm going to delve into some of the critical resources that we talk about here. And this begs having a practical example. So as I mentioned, I'm going to use banking, but by no means is this the only example you can use. So if we look at a typical banking organization, what I've outlined here are nine of the most critical basic services that they provide. So in order to be considered a bank, you've got to have these things up and running, and you've got to be able to provide those to your customers. The question is, do you have a good enough understanding of each one of these and where they rate in terms of priority to be able to call those out? So the first step in this really is looking at what are those critical functions and who has to be involved in that conversation. And can we get to a level of agreement across the entire organization as to which one is the most important? The next question is, what do I need from a resourcing perspective? So identifying minimum business services continues with what are the minimum resources I need? How many personnel are required to run the minimum, the critical business service that I select? What's the technology that's involved? What's the technology underlying that technology that may be involved? What are the physical assets? Do I have certain facilities I need to maintain, certain equipment, and financial resources? How are we going to stay in business? One of the things that we've learned about ransomware is that the typical organizations impacted by ransomware that is down for about twenty to twenty three days. And that may not be an issue for organizations that are very large and have lots of resources to stay in business for those many days. But that's not all businesses by any stretch. And so the question comes down to how are you going to fill the gap in terms of revenue while you're recovering your systems? And do you already have some of that thought through? Do you have a line of credit with the bank or is there some other way that you can draw resources from that you can use while you're spending all money, the time that you that you need to recover your systems? And if you're doing that, is that something that's clearly documented to the most important parts of organization? Now a note on this is when you're evaluating whether or not you need all your personnel, it's okay if you realize that you don't need all personnel necessarily involved in this issue. And I'll give you a practical example. If the most critical business service requires that you have 100 of your employees dedicated to recovering, but you have a thousand employees total, Having extra people in the process asking for constant updates may end up costing you more time. So understanding what that number is upfront gives you the ability now to craft a plan to make sure everybody's involved at the level that they should be. Everybody's up to date and has no questions, but that you're dedicating all the most important resources you have to the recovery process itself. Next question is, do you have emergency response protocols? And this is more scenario based than it is anything else. But if you look at the types of things that might befall you, I would say one of the things that you want to do is categorize those. Small number of categories, but you want to have a good, solid understanding of the different types of things you're going to be most interested in. Natural disasters, cyber attacks, supply chain interruptions, power outages, pandemic scenarios. I think each one of these are things that we have learned are the large buckets that everything else kind of fits into. Now you may have more, or you may have very industry specific concerns, but categorizing your response protocols into these types of categories gives you the ability now to have a ready made plan and to, you know, successfully anticipate what might befall the organization and what you have to be prepared for. Your response to a natural disaster might be very, very different than your response to a power outage or to a cyber attack. And having a clear understanding of what that is beforehand is going to help everyone from executive management to your marketing, communication teams and your employees in the event that something happens. Next up is communication plans. So one of the things that we have learned with assisting many organizations is that you try to recover from a cyber event or ransomware attack, is that, you know, we focused a lot as an industry on digitization, right, digitalization, putting as much as we possibly can into well thought out processes and procedures that are stored on our networks in easy places for employees to see. And we use those as our first response plan. One of the challenges that we see during ransomware events is some of those resources may not be available to you because of the attack itself. Attackers are looking more and more to cause as much inconvenience and take away as much of your ability to control your future as possible. So this essentially lists out the components that you need to have. And most organizations, I think, do a pretty good job of putting these together. The question then is for most important for this, are those plans available to you in a non digital form in the event that you needed them? And what are they? And do people know how to get to them? And so that gives you the ability now to say, you know, if your main recovery document sites are no longer available, you don't have people who are trying to figure out where to go for them, that you've got this already as part of the plan, it's clearly communicated, and the organization can continue. Data protection and recovery is next up. The question comes down to do you understand what data you actually have? And are you actively managing the risk that goes with that data? And then how do you know when you can actually recover from what's the point in time that you can go back to so that you understand whether or not your, recovery options, your recovery deadlines are really achievable. One of the things that has happened to many organizations is that they spend a great deal of time during this phase of recovery, trying to figure out exactly where they need to go back to from a point in time perspective. Now, that's an iterative process for most organizations, but you've got to restore the data, you've got to then test the data, you've got to conduct threat hunts across the data to make sure that the malware or the causing activity is no longer there. And if you find that they're still there, then you've got to scrap all that and go back to a different point in time. Understanding all that is what Rubrik adds the most value in this conversation because we can help you get to that recovery point objective very, very quickly. We understand when your data was clean last. We know exactly when you can start to restore from. And so the things that you want to look for here are really your understanding of what your backups are, how often they take place, whether or not you've got good clear data encryption and access controls on that data, Whether your client cloud based data replication is working and where are you replicating to? Do you know the sources of all the data that you're backing up and where you're pushing them to? And the last piece is what kind of data do you have? Probably one of the most important questions is understanding the types of sensitive data that you've got, because that's going to trigger a lot of the notification process that you've got to go through for clients, for regulators, for markets, and understanding that well beforehand gives you the ability to prepare all of your communications folks, all of your official communications, and give people a very solid understanding of what might be at risk so they can take action themselves. Testing and drills. This is probably the one that I think we don't spend enough time on simply because it's not an easy thing to do. But what you want to do, if you remember back to an earlier slide, there was a center bump in the slide that showed this area where you were trying to figure out what exactly happens. Your objective really should be to spend as little time in that area of uncertainty as possible. And the key to getting there is essentially testing repeatedly, automating that testing as much as possible, and then getting to the point where everybody knows what's going to be expected to them during an event. Tabletop exercises are an ideal way to do this, as our full scale simulations and unannounced drills. Cross functional team involvement is critical. And what I mean by that is simply that it's important that you've got folks from across the organization involved as you're developing your testing process and you're perfecting it. And the reason for that is that if minimum viable business or even BCMDR is not solely an IT activity, IT plays a huge part, there's no doubt about it. But it is really a business led recovery exercise that needs to have representation from all of the various stakeholders in order for us to be successful. And this last piece really is making sure that you've got the ability to continually adapt to what's going to happen. Business is dynamic. The folks who are attacking us are dynamic. Lots of innovation coming from both organizations, from a recovery perspective, as well as attackers from, you know, a threat actor, capabilities perspective. What we need to be able to do is to have the ability to understand what it is that we do today and to not let that go stale. Making sure you've got a clear set of scenarios that you're always looking to respond to, that you're adapting those as time goes on. Making sure that you've got the ability to grow that as your business continues to grow. And you've got a way to incorporate lessons learned as you go through these exercises, whether it's tabletop or actual execution of a recovery plan, to make sure that those plans are updated for the next time so that you're spending less and less time figuring things out and more time bringing the core services back on track as quickly as possible. The whole objective of this is really this slide. What you see here in terms of the boxes calling out are what any organization that's impacted by a ransomware event or cyber resilience event has to go through. This applies to any industry in any organization. And if you look at this, essentially, the time to first notification, how long does it take you to get organized? And then how long does it take you to get those teams involved? There's a total of probably twelve hours that most organizations go through from the first time they realize something's wrong until they've got all the right people on a call, and they start to make decisions to start to recover the environment. The next step is where do they recover? How do they create a recovery environment that they can use? Is that internal? Is it external? Is it a cloud? How do they actually start to look at where they restore from, where they're going to, and how they know that, as I mentioned before, you're not just reintroducing malware over and over again. And you look at that timeframe, it's twenty one days, that timeframe is fairly consistent across all organizations and industries. And then you've got to build time in for malware detection, quarantine, understanding how to app to restore your applications if you don't invest in automation upfront, and understanding what the impact is, the types of data you've got, and eventually getting to the point where you're remediating the risks that went with having that data exposed and potentially exfiltrated by bad guys. Our objective with the known wild business is to get you down to something considerably less. And how do we do that? We move most of those steps left of the event itself, meaning that we can tell you what you have from a sensitive data discovery perspective. We can tell you where that data is. We can also tell you what's happening to your data. Every time Rubrik accesses, anything to back it up, we run full scans. We look for threats in your environment. We consume your threat feeds and we make sure that we understand what's actually happening well before you should ever need to restore that data. And we're giving you that guidance as we go along so that that middle section of uncertainty and doubt is minimized. And we've got you back to the point where recovery, rather than being three to six weeks, is targeted at one to four days at a maximum. So, I'm going to kind of close out here. I don't want to leave you without something practical to do from a practitioner's perspective. So, would say, you want to try this and just as an informal process, identify what you think your top three critical services are, and then invite some of your coworkers, your stakeholders across the business to that conversation, share that with them. Don't worry about being wrong, but let them see it and let them add their their ideas and their thoughts on what's going to be most most interested or most, important rather from recovery perspective. And the reason for doing that is starting small is the easiest way to do this. You may end up if you have a multi product architecture and you've got lots of different things that you do for your markets that you serve, you may end up feeling a bit overwhelmed, getting everyone to agree on what the most important services are. So starting small gives you the ability to understand that, you know, first and foremost, from your perspective. And then second, secondly, from others' perspectives, to see if there's a common understanding of what's most important. You may end up actually having to go and to escalate this to management for clarification. But that also is a good thing because ultimately what you want to get to is a clear understanding of what your most important critical services are. And the second piece is identifying what your essential dependencies and required resources are. So I mentioned before, do I need specific facilities? Do I need to have specific teams involved? Are there people within IT that may not need to be involved in that? Are there areas of the business that I don't know enough about? And should I have them in pre planning exercises to make sure that if something happens to us, we know exactly what we should be doing to get them back online as quickly as possible? And the reason for doing that is simply it reveals single points of failure, areas that you may not be thinking about today that would come up during a natural recovery and would cost you time and money because you'd be figuring out during the event itself, which is, at the end of the day, they think we want to avoid the most. Last piece is establish a simplified communication framework. Assuming for the moment that you have a breach and you have some kind of interruption to business as usual and your standard documents are not available, how are you going to communicate to all the key stakeholders that have to be involved in your recovery? Is it going to be Zoom meetings? Is this going to be a different Zoom provider, as an example? Would you use an alternative instant messaging platform? Would you assume that you've got access to personal email addresses for key people who are going to be involved? And can you verify that you actually do have that information? All of this brings you closer and closer to an understanding of what's going to actually have to happen for all this to come together seamlessly. If you don't have a formalized NVB today, Understanding who you're going to communicate to, when and why, is a solid place to start because that's going to give you lots of insight into what you need to know when you start to have those conversations. All right, and that brings us to the end of our webinar. I want to thank you very much for making the time for us today and for the trust that you put into Rubrik and our products. To leave you with some things to further think about as you develop what your MVP strategy really is, we've got a few docs that you can access over in the docs area of the webinar. I would encourage you to take a look at those and you can always reach out to us directly and we can have a deeper conversation. Thanks so much again, everybody have a great day.