Microsoft 365 Backup and Recovery: What Native Tools Do Not Protect

M365 FM - Microsoft 365 Backup and Recovery - What Native Tools Do Not Protect 00:00:00 Speaker: Most organizations move to Microsoft three hundred sixty five with one quiet belief Microsoft runs it, so Microsoft backs it up. That belief is wrong, and it's wrong in a way you won't notice until the day it matters because Microsoft keeps the service running. That's availability, but availability is not recoverability. Those are two different promises. Only one of them comes with your subscription. And in this episode, we'll look at what the native tools really cover. What Microsoft three. Sixty five backup adds where third party backup fits what ransomware does to all of it, and how to test a restore before you need one. And if you want to keep learning this way, subscribe to the M365 FM podcast so you never find out what you can't restore at two in the morning. But first, a word from our sponsor sponsor segment one. This part of the show is brought to you by Stellar Migrator for exchange. It's a tool for moving mailboxes. You can move them between exchange environments from one tenant to another, or from older systems into Microsoft three hundred sixty five. It's built for the kind of work where you can't afford to lose mail along the way, and it also helps in recovery adjacent work when you need to pull data out of one place and land it in another, you want a tool that handles the mailbox structure for you. Now why mention it here? Because moving mailboxes is a data handling event. You copy things, you change things. You delete the source when you're done. And data handling events are where recovery gaps show up, not during normal days. During the days when something is in motion and someone assumes there's a copy somewhere else. So if you're planning a migration, a merger, or a tenant move, treat the recovery question as part of the plan, not as something you add later. Which brings us back to the core question who is actually responsible for your data? The shared responsibility gap. Let's start with what Microsoft actually promises. Read the Microsoft Services Agreement and here's what you'll find. The commitment is about the service uptime availability. The service is up and you can reach it. That's the deal. Microsoft publishes uptime targets for its services, and it works hard to meet them. For most workloads, that target sits at ninety nine point nine percent. Now look at what the same agreement says about your data. It says you own it and it says you're responsible for it. Not buried in small print. It's in plain language. Microsoft recommends that you regularly back up your content and data. That recommendation is right there in the agreement most admins have clicked through and never actually read. So there are two halves to this arrangement. Microsoft keeps the platform running. You keep your content safe. That's what shared responsibility means in practice, and that's where the gap opens. Because most people only hear the first half, they hear cloud and they picture a vault. They hear Microsoft data center, and they picture someone else carrying the risk. That's a fair picture of the infrastructure. It's a terrible picture of your data. And here's why this mix up is so common. The infrastructure really is resilient. Microsoft runs many data centers across many regions. Your content is stored in more than one place, disks fail, servers fail, and whole buildings can go offline and you won't notice. That's real engineering. It works. So people see that resilience and they make a jump. They think if it survives hardware failure, it must survive anything. But hardware failure is only one way to lose data. Think about what that replication is actually doing. It watches your content and it copies every change to another location fast, reliably, all the time. Now ask a simple question what does it copy? When you delete a file, the deletion. What does it copy? When a script overwrites ten thousand documents, the overwrite. What does it copy? When ransomware encrypts a library, the encrypted files data center replication protects Microsoft from its own hardware. Failing. It was never designed to protect you from your own deletion. It has no idea which change was a mistake and which was real work. So here's the plain statement replication copies mistakes as fast as it copies good data. That's not a flaw. That's the design. Replication exists to keep every copy identical. If one copy is wrong, they're all wrong within moments. And that's the structural problem. Your data is highly available and it's well replicated. But availability and replication both assume the data is correct. At the moment it's copied. Neither one gives you a way back to a moment before the damage. Now this is where an executive usually pushes back. Surely Microsoft can restore our tenant if something goes wrong. And the honest answer is not in the way you're picturing. Microsoft can restore servers. It can bring a failed data center back. It does not keep a backup of your tenant that it will roll back to on request. If your admin deletes a site or an attacker wipes a mailbox, Microsoft's position is that you use the service as designed, and that's the shared responsibility gap. Microsoft owns the platform. You own the content, and the space between them is where most real data loss happens. Not from outages, from people, from accounts, from automation, from changes that were allowed because the system did exactly what it was told. Now, Microsoft hasn't left you with nothing. There are native tools built to give you some way back. Recycle bins, retention. Windows. Version history. Each one covers a specific kind of mistake for a specific amount of time. So the real question isn't whether Microsoft gives you protection. It's what those native tools do specifically and just as important, what they don't. Availability. Durability. Recoverability. Three different words. Before we look at any tool, we need three words straight. They sound like the same thing. They aren't. Availability means you can reach your data. Right now you open outlook. The mail loads. You open a document library. The files are there. If the service is up, availability is working. Durability means your data doesn't disappear by accident. Disks die, servers die, and the stored copy survives anyway. Durability is about the data outliving the hardware it sits on, and recoverability means you can get back to a known good state after something goes wrong. A specific moment, a specific version, the way it was before the damage. Notice what each word promises. The first one promises access. The second promise is survival. The third promises are way back. Now here's where Microsoft stands on availability. Microsoft is strong, the uptime targets are public, and the platform meets the most of the time on durability. Also strong. Your content sits in several places, and the odds of Microsoft losing it to a hardware fault are very small. But on recoverability at the tenant level, it gets thin because recoverability depends on you having a copy from before the problem, and a tenant by default doesn't keep one. What it keeps are short windows, a recycle bin that empties a retention clock that runs out version history that stops at a set number. Those help will go through each but their safety nets for small recent mistakes. They're not a way to roll an entire environment. Back to last Tuesday. And this is where the confusion happens. In the boardroom, an executive asks, is our data safe in Microsoft three hundred sixty five? The admin hears that as a question about durability, and the honest answer is yes, it's very safe from hardware loss, but the executive meant something bigger. They meant if something goes wrong, can we get it back? That's a recoverability question. And the same yes doesn't carry over. One word gets heard. Three get assumed nobody lied in that conversation. The admin answered the question they heard. The executive relied on an answer to a question they never asked, and the gap between those two sits in your risk register unwritten until an incident puts a name on it. So how do you make this concrete? Think about a mirror. A mirror shows you a perfect copy of what's in front of it. Instantly, continuously. Every movement, every change reflected the moment. It happens. Now put a stain on your shirt. The mirror shows the stain. It doesn't hold a picture of the shirt from this morning. It has no memory. It only reflects the present. That's what replication and high availability do for your data. They mirror it. Every change shows up in every copy. Right away. A backup is different. A backup is a photograph taken at a point in time, stored somewhere else and kept as it was. When something goes wrong, you don't look at the mirror, you pull out the photograph. A mirror is not a backup, and most of what people call protection in Microsoft three hundred sixty five is mirror behavior real time, always current, always faithful, including to the mistakes. So when Microsoft does give you something that looks like a photograph, even a small one, it matters what that photograph covers and how long it lasts. The first one most people meet is the simplest. You delete a file and it goes somewhere. The recycle bin. How the recycle bins actually work. SharePoint and OneDrive handle deletion in two stages. You delete a file. It doesn't vanish. Instead, it moves to the first stage recycle bin, which belongs to the user who deleted it. Every user has one. They open it, they see their own deleted items, and they restore with a click. That's the version most people know. Now the clock item sit in the recycle bin for ninety three days, but that ninety three days is the total across both stages. It isn't ninety three days in the first bin and then ninety three more somewhere else. It's one shared window and it starts the day the item is deleted. So what's the second stage? When a user empties their recycle bin or deletes something from it, the item doesn't go away. It moves to the second stage recycle bin. That one belongs to the site collection. Only a site collection administrator can see it. Regular users can't and the clock keeps running. If you deleted a file on day one and emptied your bin on day ten. The item has eighty three days left in the second stage. It doesn't reset. It doesn't restart. This is where people get caught. A user says, I deleted that months ago, but I think I needed the admin checks. The first stage bin empty. The admin assumes it's gone, but it might be sitting in the second stage, visible only to someone with the right role. Checking one bin isn't checking both, so there are two places to look and two different people who can look. Now what happens at day ninety four? The item is purged permanently. It leaves the second stage recycle bin and doesn't go anywhere else. There's no third bin. There's no ask Microsoft option for content that's aged out. Once the window closes, the standard path to getting that file back is closed too. And notice how quiet that is. No warning email goes out the day before. No report lists what's about to expire. The item just leaves. If nobody needed it in those ninety three days, nobody notices. If somebody needed it on day ninety five, they find out that day. That's a hard fact for anything that's rarely opened. Think of the annual report folder, the contract archive, the files you touch once a year. A deletion in February might not be discovered until the audit in June. By then, the window is long gone. Now the other question who can empty these bins? Users can empty their own first stage bin that's expected. It's how the feature works, and site collection admins can empty the second stage also expected. But look at what that means from an attacker's side. If someone compromises a user account, they don't just get that user's files, they get that user's recycle bin. The attacker can delete content, then empty the first stage, which pushes everything into the second stage. That gives the attacker a head start. But it isn't the end. The real problem is a compromised admin account. An admin can empty the second stage, which means an attacker with that role can delete a site's content, clear both bins, and remove the one thing the user was counting on. Nothing about that is a bug. The system is doing what a permitted account asks. The recycle bin protects against honest mistakes. It was never built to stand up to someone who has the keys, and that's the pattern to keep in mind. As we go through each native tool, they assume the person using them is on your side. So that's SharePoint and OneDrive. Two stages, one clock, ninety three days exchange has its own version of this same idea, but a different clock and different folders, and a much shorter default exchange online recoverable items and its limits. Exchange doesn't use a recycle bin. It uses folders and they stack. A user deletes an email. It lands in the deleted items folder. That's the one everyone knows. They can open it, find the message, drag it back to the inbox. Nothing special. Then the user empties deleted items or outlook does it for them on exit. Depending on how the client is set up. The message is gone from view, but it isn't gone from the mailbox. It moves into a hidden folder called recoverable items. Users don't see it in the normal folder tree. They reach it through a menu in outlook, an option that says recover deleted items from server. Most people have never clicked it. Many don't know it exists inside recoverable items. There are subfolders. Three of them matter here. The first is deletions. That's where emptied items wait. The second is purges. That's where items go when they've been deleted. And the third is versions. That one holds copies of items that were edited when certain holds are in place. Each folder has a different job and only the first one is visible to the user. Now the clock. By default, items in recoverable items are kept for fourteen days, not ninety three fourteen two weeks counted from the day the item was removed from deleted items, an admin can raise that to thirty days. That's the maximum for the setting, and it's a single PowerShell command per mailbox or a policy applied across the tenant. It's cheap, it's fast, and a surprising number of tenants never do it. So compare the two clocks. SharePoint and OneDrive give you ninety three days. Exchange gives you fourteen. Unless someone changed it. That's a very different safety margin for a workload where people lose things all the time. And here's what happens at the end of that window, the managed folder assistant, a background process sweeps the mailbox. Anything past its retention date is removed permanently, no notice and no second bin. Now, there's a feature that matters here and it has an awkward name single item recovery. What it does is simple. It stops the system from purging items out of recoverable items before the retention period ends. Without it, a user can open the recovery dialog, select items, and purge them on the spot. They go straight to purges, and then they're gone. With single item recovery turned on, that shortcut closes. The user's purge request is accepted, but the item stays in the folder until the retention clock runs out. Why does that matter? Because it protects against the fast version of a mistake and against the fast version of an attack. Here's the part that surprises admins. Single item recovery is on by default for new mailboxes in exchange online, but it isn't guaranteed for every mailbox. Older mailboxes, migrated mailboxes, and ones created through certain tools may not have it. If you've moved mail from on premises exchange or from another system, you can't assume you have to check. One command shows you the setting for every mailbox. Most tenants have never run it. So now picture a hard delete. An attacker gets into an account. They don't need to be clever. They open the mailbox, select everything, delete it. Then they empty deleted items. Then they go into the recovery dialog and purge what's left. If single item recovery is off, the purge works, the data is gone, and the fourteen day window never mattered. If it's on, the purge is blocked. The items sit in recoverable items waiting out the clock, but a script changes the picture. A script with admin rights or an attacker with the right role can do more than a user can. They can change the retention setting itself. Set it to zero, turn off single item recovery, then run the deletion, then purge. Each step is allowed. Each step is logged if you're watching the logs, but the system doesn't stop any of it because the account has the permission. The folders protect against a tired user on a Friday afternoon. They don't hold up when the person deleting has the same rights as the person who set the rules. And that's before we ask the bigger question. Fourteen days of deleted items sounds a lot like a backup. A way to get mail back, a place to look when something goes missing. It sounds like one. It was built for something else. Retention is not backup. Retention policies were built to answer a legal question, not an operational one. A compliance team writes a rule keep every contract for seven years. Keep finance email for ten. Delete chat after two. The policy runs in the background and the tenant holds on to content so the company can prove what existed and when. If a regulator or a court ever asks, that's governance. It's a good job and the tools do it well. But look at what the job actually is. It's about preserving content for a reason. It isn't about putting an environment back the way it was. Nobody wrote a retention policy thinking this is how we'll recover from a bad Tuesday. And yet that's how most admins talk about it. We have retention turned on so we're covered. Covered against what exactly? Take SharePoint. When a retention policy applies to a site and someone edits or deletes a file, SharePoint quietly copies the original into a hidden place called the Preservation Hold library. Users never see it. Only site collection admins can reach it, and only from the site settings. It sounds like a safety net. In part it is. The library captures content that was changed or deleted while the policy was active. It keeps the version as it stood at that moment. If you need to prove what a document said before someone edited it, that copy is there. If someone deletes a file, a copy of it lands there too. Now look at what it doesn't capture. It doesn't capture the site as a whole. It holds loose pieces of content one file at a time. No structure comes with them. Permissions, page layouts, navigation list views, and the links between items aren't in there. And content that was never edited or deleted may not be in there at all, because the library only fills when something changes, it also grows quietly. Every edit adds a copy, so the storage counts against your quota, and nobody notices until a site runs out of room and the files in it sit by the thousands with no tool to put them back together. Restoring from the library is a manual job. An admin opens it, finds the right file, copies it out, and puts it back by hand, one file at a time. So here's the structural point. Retention keeps copies of content. It does not keep a consistent point in time state. Those aren't the same thing. And the difference is easy to miss. A copy is a single item. A state is everything all at once. As it stood at one moment, the files, their folders, their permissions, and their metadata all agreeing with each other. Picture a document library on Tuesday morning, four hundred files organized into folders with specific people allowed into specific folders. By Wednesday afternoon, a script has renamed half the folders, and a sync error has overwritten a third of the files. Someone also changed the permissions to fix an unrelated problem. Now ask retention to give you back Tuesday. It can't. It can give you older copies of some of the files. It can't tell you which folder each one lived in. It can't rebuild the permissions. It can't tell you which versions belong together because it never recorded that they did. You can keep every file and still be unable to restore the site as it was on Tuesday morning. Every file survived. The state didn't. And that gap shows up late because compliance reviews never tested. And auditor asks, do you retain this content? The answer is yes, and the review passes. Nobody asks, can you put the whole thing back in under two hours? That question only gets asked during an incident. So there are two different questions and each one needs its own tool. Retention answers. Can we prove it existed? Backup answers. Can we put it back? That's the model to hold on to. One is evidence, the other is restoration. A company can be excellent at the first and have nothing at all for the second, and the paperwork will look fine either way. Now there's one retention feature that people lean on harder than any other. It's the one that feels the most serious because lawyers use it. Litigation, hold litigation, hold e-discovery, and the wrong tool problem. Litigation hold has one job. It tells exchange to stop deleting things, and admin puts a mailbox on hold and everything in it gets preserved. Send mail, receive mail, deleted mail, even items a user purged on purpose edits get preserved to as earlier copies of the same message. The hold can run for a set number of days, or it can run with no end date at all. Most legal teams pick the second option, because nobody wants to explain an expired hold to a judge. So for how long has a simple answer until someone removes it? 00:17:13 Speaker: And that's the first problem. Nobody removes it. A hold gets placed for a case in twenty twenty one. The case closes in twenty twenty two. The hold stays because no one told it it could go and no one at it wants to be the person who removed it by mistake. Years later, that mailbox is still holding every item it ever touched. Now think about storage held items live in the recoverable items folder. The same hidden folder we just walked through. That folder has a quota out of the box. It's one hundred gigabytes and it can be raised to one hundred and ten once the mailbox is on hold. When a held mailbox keeps growing, that folder fills up and when it fills up, things break. Users get errors, mail stops being deleted, the sweep that cleans old items can't run, and the mailbox stops behaving the way it did before the hold. All of this happens quietly. The hold works exactly as designed. The side effects arrive months later and they look like a mailbox problem. Nobody connects them to the legal decision that caused them. Now to the real wrong tool problem. Because litigation hold keeps everything. People start to see it as a safety net. If it's on hold, we can get it back. Technically, yes, you can find the data, but finding it and restoring it are very different jobs. To get content out of a hold, you use eDiscovery, you open a case, define a search, run it, review the results and export. That process was built for lawyers who need to collect evidence. It returns items. It doesn't put them back where they belong. So picture an admin using it to recover from an incident. A department's mailboxes were wiped. The admin runs a search, waits for it to finish, and exports the results as files. Then they have to get that content back into live mailboxes. Somehow. Folder structure is partial. Message state is partial. Some items arrive, some don't, and none of it lands automatically. It's slow, it's manual, and it's incomplete. You'll hear this described as having a backup. It isn't one. It's a collection tool. Being asked to do a restore tools job. And there's a people problem that makes it worse. Who owns these tools? In most organizations, it's not the infrastructure team, the legal department, or compliance or a records manager owns litigation, hold and e-discovery. They hold the permissions. They know the case numbers. They decide what gets preserved. The people who run the tenant day to day often can't even open the eDiscovery console. The role isn't assigned to them, and it shouldn't be because separation of duties matters. But now it's a bad night. The tenant is under attack, and the content you need is only reachable through a tool owned by someone who isn't on the call. Maybe they're asleep. Maybe they don't know how to run a search under pressure, and whatever they export, it still needs a human to rebuild by hand. So the legal tools protect content. They don't protect your ability to recover quickly. That leaves the native feature. Most people expect to rescue them in a file level disaster. It's built into every document library, and most admins have never checked how it's set. Versioning, SharePoint and OneDrive versioning and restore features. Every document library keeps old versions of files. That's version history. It's the first thing most admins point to when someone overwrites a document for a single file, it works well. You right click open version history, pick Tuesday's copy, restore it 10s. But look at the limits. Versioning is a count, not a timeline. New libraries in SharePoint online default to five hundred major versions. When the five hundred first arrives, the oldest one drops off and oldest has nothing to do with calendar time. A file that gets edited all day by an autosave heavy app can burn through those versions fast. A file that sits untouched keeps its history forever. So the question can we get back? Last Tuesday's version has no fixed answer. It depends on how busy that file was. Now add the cost. Every version takes storage. Microsoft stores only the changed pieces for many office files, which helps. But other file types store a full copy each time. Multiply that by five hundred versions across thousands of files and the storage quota feels it. So admins trim. They set the limit to fifty or ten, or they turn on automatic trimming, which thins out older versions by age. Each choice saves space. Each one shortens the way back your trading recovery depth for storage cost, and most people make that trade without ever writing it down. Then there's the second feature people reach for. It has a good name and it does real work. Restore your OneDrive. It lets you roll a whole OneDrive back to an earlier point, not one file. Everything you pick a date, review the activity chart, and Microsoft undoes the changes. After that moment. The window is thirty days rolling. Today's restore can reach back to a day within the last month. Tomorrow's can reach one day further forward. Nothing before that range is on offer, and it needs a few things in place. The user or an admin acting for them has to do it. It works, per OneDrive, so it's one account at a time. The restore itself only touches content in that one drive. It won't touch what's in a SharePoint site, a mailbox, or a team. Now what can't it fix? It can't reach past thirty days. If the damage happened on day thirty one, or you only noticed on day thirty one, the option is closed. It can't rebuild a OneDrive that was deleted because that's a different process with its own clock, and it can't tell you which changes were the bad ones. You choose a point in time and hope you picked the right moment, because the restore works like a rewind. Everything after the chosen point is undone. Good edits included a user who worked normally for three days after the damage will lose those three days of legitimate work unless they save copies first. SharePoint has its own version of this. It's called Restore This Library, and it sits in the library settings. Same idea. Pick a date, review the changes, roll the library back. The constraints are similar with a few extra ones. It works on one library at a time, not a whole site. It uses the same thirty day window, and it has to be turned on by a person with the right rights, which means someone has to be awake, reachable, and sure about what to restore. A library rollback only covers what the library holds site pages, lists, permissions, changes and settings elsewhere on the site. Don't move with it. Which brings us to the problem under all of this. These features only help if you notice the damage in time. Most organizations don't. A user deletes a folder and nobody opens it for six weeks. A sync error overwrites files, and the quarterly review is the first time anyone looks. Ransomware encrypts content slowly and the first sign is a user asking why their spreadsheet won't open. Nothing alerts you. No dashboard says restore needed. A person has to see the problem, report it, and someone has to connect it to the right tool inside the right window. Each step takes days, sometimes weeks. By then, the thirty day clock has already run most of its course, so the native tools for files give you a way back, but only for fast discoveries, small scopes, and recent damage. And that's still just files. The next problem is bigger because it isn't one workload at all. It's several stitched together under one name that people use every day. Teams. Teams. The recovery problem. Nobody mapped. Ask someone where their team lives. Most will say in teams that answer is the problem. A team isn't a thing, it's a name for a bundle. When someone clicks create Team Microsoft builds several separate pieces behind the scenes and ties them together with one identity. The app on your screen is just the window onto all of them. Start with the foundation. Every team sits on a Microsoft three hundred sixty five group. That group holds the membership, the owners, and the email address. It's the identity the other pieces hang from. Then there's a SharePoint site. That's where the files tab points. Every file shared in a channel lands in a document library. There in a folder named after the channel. Then there's an exchange mailbox. The group gets one and it holds the calendar and some conversation copies. It's easy to forget it exists. Then planner. If someone adds a plan and OneNote. If someone adds a notebook planner keeps its data in its own service. The notebook is stored as a file inside that SharePoint site, and then the chats, which don't live in any of those places. Channel messages are stored in a hidden mailbox area tied to the group one to one, and group chats are stored in the mailboxes of the people who took part. Different containers, different rules, different clocks. So one team means a group, a site, a mailbox, a plan, a notebook, and two kinds of message storage six or seven locations, and each one answers to its own recovery rules. Now think about what that means in an incident. Somebody says, our team is broken. Which part? The files, the messages, the membership, the plan. Each one has a different tool, a different window, and a different owner. You can't restore the team. You can only restore the parts one at a time and hope they line up when you're done. Let's look at the one recovery path Microsoft does give you for the whole thing. When an owner deletes a team, the group goes into a soft deleted state. It's removed from view, but it isn't gone. Admins can restore it from the intra admin center or with PowerShell for thirty days, thirty days, not ninety three. And the clock belongs to the group, not to the content inside it. When the group comes back, the piece is tied to it. Generally come back to the site reappears the mailbox Reattaches membership returns for a clean, quick, whole team deletion. That's genuinely useful, but it only covers that one scenario. It doesn't help if someone deletes a channel. Channels have their own short window, and what you get back is partial. It doesn't help if a user deletes files from the document library, because those follow the SharePoint rules we already covered, and it doesn't help if the team still exists, but the content inside it was altered, overwritten, or emptied, which is the more common case. Now, the part that surprises almost everyone chat and channel messages. Microsoft does keep them. If you set a retention policy for teams behind the scenes copies, go into hidden folders in those mailboxes. Retention policies can hold them for a set time, then delete them. Compliance tools can search them and e-discovery can export them. So the preservation path exists. But look at the direction of travel. Everything in that path moves content out of teams into a search result, into an export file, into a review tool. There's no native button that moves it back in. Think about what restoring a message would mean. A message belongs to a thread. The thread belongs to a channel. It has a sender, a timestamp, reactions, replies, edits, and attachments. Put a message back into a live channel, and now it has to sit in the right place, in the right order and with the right author. The product wasn't built to accept that you can't insert history into a conversation after the fact. At best, you can hand people an export and say, here's what was said. That's a record. It isn't a restore. So when someone asks, can we get our teams chats back? The honest answer is we can show you what they said. We can't put them back the way they were. Most people don't ask that question until the chats are gone and it points at something bigger. A user deleting the wrong thing is only one way this goes wrong. There are several others and they don't look alike, so let's name them. The real loss scenarios. Most data loss in Microsoft three. Sixty five doesn't look like an attack. It looks like a normal day. Start with the simplest one accidental deletion and overwrite. A user deletes a folder to tidy up. Another saves an old copy over the new one. Someone pastes the wrong spreadsheet into the wrong library and replaces last quarter's numbers. Nothing was hacked. The system did exactly what it was asked, and the person asking simply got it wrong. This is the most common loss by far, and the native tools we've covered were built for it. That's the good news. The catch is that you have to notice inside the window. Now change the intent. Malicious insider activity. Someone with legitimate access decides to take or destroy what they can reach. Maybe they're leaving on bad terms. Maybe they're angry about a review. They don't need to break in. They already have the permissions, so every deletion looks like routine work, and the logs show an authorized user doing authorized things. Then there's a compromised admin or service account. This is the one that changes the whole picture. We saw earlier that a stolen user account can empty its own bins. An admin account can do far more. It can empty the second stage bins, shorten retention settings, remove holds, and delete whole sites. A service account is even quieter because nobody watches it. It has broad rights, a password that never changes, and no human who'd notice odd behavior. When that account falls, the safety nets fall with it because they all sit behind the same permissions. The next scenario involves no bad actor at all. Sync client mishaps. The OneDrive sync client does one thing well. It makes the cloud and the laptop agree an agreement is the whole problem. If a laptop has a damaged disk, a bad restore, or a half finished file move, the client doesn't ask which side is right. It syncs. A corrupted file on one device, can overwrite a good copy in the cloud, and the cloud then pushes that corruption out to every other device. One bad laptop becomes everyone's bad file. Then there are third party apps and automation errors. Think of the power automate flow that moves files and has a logic bug, or the migration script that runs against the wrong site, or the app someone approved two years ago, which now holds permission to read and write every library in the tenant. These tools act fast and at scale. A person deletes ten files by mistake. A flow with a bad filter deletes ten thousand before lunch, and it keeps running until someone notices it, which is often days later. Now, the one that catches careful organizations off guard, departed employee account deletion, and the license removal trap. Here's how it goes. An employee leaves. HR sends the notice. It disables the account, removes the license, and eventually deletes the user. That's standard offboarding and it feels responsible. But a license is what keeps a mailbox and a OneDrive alive in a usable state. Take the license away and the clock start. A deleted user's OneDrive is kept for a retention period thirty days by default, and admins can raise it up to ten years. A mailbox without a license and without a hold gets deleted, too. After a short grace period, so someone's whole body of work years of email and files can be on a countdown the moment a ticket gets closed and the person who closed it didn't do anything wrong. They followed the checklist. The checklist just never asked, does anyone still need this? Months later, a manager asks for a former employees files for a client dispute. The OneDrive is gone. The mailbox is gone. The retention window passed quietly weeks ago. Look at what these scenarios share. None needed a breach. Each came from a normal action taken with normal permissions at normal speed. That's why they're so hard to plan for. You can't block them without blocking the work itself. But one scenario takes all of these and turns them up. It's deliberate, it's fast, and it's the one that finally gets a budget approved ransomware. Ransomware in Microsoft three hundred sixty five. What actually happens? Most people picture ransomware as a file problem. A folder turns to gibberish and a note appears on the screen. But in Microsoft three hundred sixty five, that's the last step, not the first. The attack starts with identity. Someone gets a password through phishing or buys one from a leak, or tricks a user into approving a sign in prompt. They didn't start. They don't need a virus. They need a valid session. Once they have one, they look like a normal employee doing normal work. From there, they move quietly. They read mail to learn who matters. They look for accounts with broad access because one admin role is worth a thousand user accounts. They check which settings are in their way. Retention holds alerts. Some of this takes hours. Some of it takes weeks. Encryption comes late on purpose. The attacker wants every safety net mapped before anything visible happens. So where do the files get hit? Often through the OneDrive sync client. And this part is almost too simple. Malware lands on a laptop or the attacker uses a stolen session to run code on a device that's already signed in. It starts encrypting files in the local OneDrive folder. Documents, spreadsheets, the whole folder tree the sync client sees changed files. It does what it was built to do. It uploads them. Nobody has to break into the cloud. The user's own device carries the damage up through the front door one file at a time. And if that user shares a library with a team or has folders synced to other machines, the encrypted copies spread outward from there. So the sync client becomes the delivery mechanism. It's trusted, it's fast, and it never asks whether a change was legitimate. Now think about versioning, because this is where the earlier safety net meets the attacker's planning. We saw that version history is about five hundred major versions by default, and the oldest drops off when the next arrives. An attacker who knows that has a simple move. Don't encrypt each file once. Overwrite it again and again. Each pass adds a version a few hundred passes later. Every clean copy has been pushed out of the history, and what remains is a stack of encrypted ones. Slower but quiet, and it works especially well on libraries with lower version limits, which many admins set to save storage. Then there's the blunt version mass deletion delete the content, empty the first stage bin and the clock starts. If the attacker holds an admin role, they clear the second stage too. If they don't, they only need to wait out the ninety three days or hope nobody looks content. Deleted today and unnoticed for three months is gone. Whatever the retention window said on paper, sometimes the attacker does both encrypt the files that sync, delete the ones that don't, and clear whatever they have the rights to clear. Now, you've probably heard this line SharePoint can't get ransomware. It's half true, and that half is why the line does so much damage. Here's the true half ransomware code can't run inside SharePoint online. There's no server to infect, no operating system for malware to take over. Microsoft Service isn't encrypting your sites from the inside. Here's the half that matters. Almost none of that protects the content because content gets to SharePoint through people and devices. A library is just a folder on a laptop, and the sync client writes whatever that folder holds. Back to the library. A stolen account can upload files, overwrite them, or delete them through the browser or through an API. An app with broad permissions can do it faster so SharePoint doesn't catch ransomware the way a laptop does. It just stores the result. The platform stays clean, the data inside it doesn't. And a team that believes the first sentence will skip the planning that the second one demands. So the real question is what you do. Once a library is full of encrypted files and the sync client has already spread them around, Microsoft built a native answer for the sync side of this. It's narrow, it's useful, and it works best when you catch the problem. Early ransomware recovery with native tools a walkthrough start with what Microsoft built for the sync side. When OneDrive sees a large number of files change at once in a way that looks like encryption, it can flag it. The user gets a prompt, something like, we think your files were attacked. From there, the restore flow opens and Microsoft walks the user through rolling the OneDrive back. That's the ransomware detection prompt. It's tied to restore your OneDrive, the same thirty day rewind we covered earlier. For one user, one laptop caught early. It works well. The user picks a point before the damage. The activity chart shows a spike of file changes, so the right moment is easy to see. They confirm, and Microsoft undoes everything after that point. But look at the conditions the detection needs to fire. It doesn't always slow encryption, small batches or files the attacker overwrote through the browser instead of the sync. Client can all stay under the threshold, and the prompt only helps if the user reads it, understands it, and doesn't just close the window to get back to work. Now move from one user to a library. SharePoint has restored this library. It rolls a single document library back to a point in the last thirty days. Same chart, same review step, same confirmation. But it's one library at a time. A site might have six, a tenant might have four thousand sites. Someone has to open each library, pick a time, review the changes, and confirm that someone needs the right roll on every site or the rights to add themselves to it first. And here's the question that decides everything, which point in time. 00:34:28 Speaker: Attackers don't announce when they started. The first encrypted file might be from Monday, the last from Thursday. An admin choosing a restore point is guessing at where clean ended and damage began. Pick too late and encrypted files come back. Pick too early and you throw away days of real work. Now put numbers on it. Say three hundred users are hit. Each has a one drive and each one drive needs its own restore. Many also share libraries across a dozen sites. Call it a few thousand files per user, spread across hundreds of locations. There's no single button for restore everyone in practice, admin scripted with PowerShell or they walk users through the flow one at a time. Either way, each restore has to queue, run, and finish. Large ones take hours, and you can't safely start until the attacker is out. Because a restore into a compromised tenant just feeds the next round of encryption. So the time cost isn't the restore itself, it's the line scoping which accounts are hit, locking the attacker out, choosing restore points, running hundreds of operations, checking each result. For a mid-size company, that's days for a large one. It's weeks. And all of that is the easy part. It only covers files. Now look at where native restore stops exchange. There's no rewind button for a mailbox. Recoverable items gives you deleted mail inside a fourteen to thirty day window and nothing for mail that was changed, moved, or rewritten if an attacker created forwarding rules or altered messages. No native tool puts the mailbox back as it was. Teams chat we saw there's no path back into the product. Messages can be exported. They can't be restored into a live conversation and then cross workload consistency. This is the quiet one. Say a team's files were encrypted, its channel was deleted, and its group membership was changed. You can restore the library to one point and the group to another and the mailbox to a third. Each tool runs on its own clock and its own window. Nothing ties them together. So you finish the restore and each piece looks fine on its own, but the site points at a channel that's gone. The files belong to people who aren't members anymore. The state never lined up. Native tools restore pieces. They don't restore a moment. And Microsoft knew that was a gap. So it built something new. One that sits outside the old recycle bins and retention windows aimed squarely at this problem. Microsoft three. Sixty five backup What it is Microsoft calls it Microsoft three. Sixty five Backup Plane Name. And it's the first time Microsoft has sold a backup and restore capability for its own servers, built by the same company that runs it. It covers three workloads SharePoint, OneDrive, and exchange sites, personal storage, and mailboxes. Those are the places where we saw Native Restore run out of road, so the scope is no accident. Now, how do you get it? You don't buy it per user. There's no seat license. It's built through Azure Pay as you go and admin links the tenant to an Azure subscription, turns the service on in the Microsoft three hundred sixty five admin center and the meter starts. You pay for the amount of data you protect measured per gigabyte per month. That billing model matters more than it sounds. It means you can protect some things and skip others. You don't have to cover the whole tenant to start. You pick which sites, which accounts, which mailboxes go into a backup policy, and the bill follows the choice, which also means a decision has to be made. Somebody has to say what's in scope. If nobody does, nothing is protected and the service sits there switched off and quiet. Now, the part that changes day to day work point in time, restore a backup copy gets captured on a regular schedule, and those copies are kept as restore points. When something goes wrong, you don't hunt for loose files. You choose a moment. Tuesday, nine a m. Then you tell the service to put that item back the way it stood at that moment. And there are two ways to ask. The granular way works on one thing one site, one one drive, one mailbox, or even a few items inside them found through a search. That's the answer to a user. Deleted the wrong folder last week. The bulk way works on many things at once. Pick a group of sites, a list of accounts, a set of mailboxes, then restore them all to the same point in time. That's the answer to the ransomware walkthrough. We just finished the one with three hundred and one drives and no single button. This time there is one. Compare that with what native tools gave you a rolling thirty day rewind, one library at a time. A recycle bin that empties a retention folder that holds pieces. Here you get a state captured whole and a way to return a whole site or mailbox to it. Now speed. Microsoft makes strong claims here, and it's worth understanding what's behind them. The pitch is that restores run much faster than tools that work from outside, large volumes in hours, not days. And the reason is architecture, not magic. A third party tool has to ask Microsoft's servers for your data through a public interface, one request at a time, under limits that Microsoft sets Microsoft three hundred sixty five backup doesn't queue at that door. It lives inside the platform, close to where the data sits, and it can use a different path to copy and return content. Less distance, fewer gates, fewer limits. So the speed comes from position. The service isn't smarter, it just stands in a different place. We'll come back to that because physics sets a ceiling on every restore, and it's worth looking at honestly, for now, hold the idea where a backup tool stands, decides how fast it can work. Which brings us to the word first party. It sounds like a marketing line. In practice, it changes two things. First, trust your data doesn't have to be handed to another company, copied to another cloud, or reached through an app with broad permissions in your tenant. There's no extra vendor to vet, no extra connector to approve, and no extra account that could be stolen for a security review. That's one fewer name on the list. Second integration the service knows how SharePoint stores a site, how OneDrive handles versions, how exchange keeps a mailbox. It restores into those workloads natively. Permissions, structure, and metadata come back as part of the item, not as a second job. That's the part retention could never do. It brings back the site sight state, not just its files. Put it together and the picture looks nearly complete. One billing line point in time states a bulk option that fits the attack scenario, speed from position, and a first party seat at the table. So what's wrong with it? Nothing. If you read it for what it is, but a backup is only as complete as its boundaries, and this one has boundaries worth looking at closely, starting with what it covers and what it doesn't. Microsoft three hundred sixty five Backup Scope and limits Start with coverage three workloads SharePoint, OneDrive exchange. That's the full list. Everything else sits outside IT teams isn't a protected workload on its own. The files in a team live in SharePoint, so those are covered. The mailbox behind the group lives in exchange. So that's cover two. But the chats, the channel message structure planner and the team as a single object aren't part of the product. We spent a whole section on how many pieces a team has. Backup reaches two of them. Same story for the rest of the tenant. Enter ID objects, conditional access policies, power platform apps, loop forms, stream. None of it is in scope. If your recovery plan assumes Microsoft backs up Microsoft Of three. Sixty five. This is where the sentence needs a footnote. It backs up three workloads, and the footnote is the other twenty. Now the clock. How long do those restore points last? The service keeps backup data for a defined period. And that period is fixed by the service itself, not by your policy. Microsoft has described it as up to a year of restore points. Check the current documentation before you build a plan on that number, because limits like this move with product updates. And now compare it to what the business actually asks for. A finance team might need seven years of records. A regulated industry might need ten. A legal team wants every version of a contract from the day it was signed. A backup that reaches back one year doesn't answer those questions. That's not a flaw. It's a different job. Backup exists to undo recent damage. Long term preservation is the retention layer's job, and we've already seen what that layer can and can't do. But there's a gap between the two. Damage found at month fourteen is too old for the backup and too messy for retention. A slow, quiet corruption, the kind nobody notices until an audit can live in that gap. The restore points you need have already aged out, and what's left is a pile of loose copies, so the retention period isn't long enough to be your only plan. It's long enough to cover most mistakes and most attacks, and not long enough to cover the quiet ones. Now the question people ask second and should ask first where does the data live? Microsoft says the backup is stored within the Microsoft three hundred sixty five service boundary, separate from the live content. It sits in its own storage, kept apart from where your sites and mailboxes run. So a bad deletion in a library doesn't touch the restore points. That's logical separation. It's real and it's useful. But look at what logical separation means. The backup is separate from the content. It's not separate from the tenant. It's still tied to your tenant, managed through the same admin center and controlled by the same set of roles. The people who can configure it are people in your environment with permissions. Your identity system hands out. So run the scenario we've been building toward a compromised admin. We already saw what that account can do to recycle bins, holds and retention settings. Now ask what the same account can do to a backup policy. Who can change what's protected? Who can remove a site from the list? Who can delete a restore point? The answers depend on how you assign roles and how well you guard them. The service gives you the controls. It doesn't make the choices for you. And this is the single vendor question. Your production data runs on Microsoft. Your identity runs on Microsoft. Your backup also runs on Microsoft one company, one control plane, one set of credentials at the top. If the failure is a data center problem, that's fine. Microsoft is good at those, but if the failure is at the tenant level, the identity layer, or the billing relationship, then everything you'd use to recover shares the same root as everything that broke security. People have a name for this, a shared fate. One event takes out the data and the path back to it. That doesn't make the product bad. It makes it a strong first layer, fast native and built for the bulk restore that native tools never managed, but it isn't an independent copy. It can't be because independence means something else entirely. Different storage, different credentials, different control plane. And that's the reason a third party market exists at all. What third party backup adds a third party backup product starts with one structural decision. It keeps your data somewhere else, not in a different folder, in a different place, run by a different company, under a different set of accounts. The copy sits in storage that your tenant doesn't own. It might be in another cloud providers data center. It might be in a region you picked yourself. What matters is that the storage has nothing to do with the Microsoft three hundred sixty five service. It's protecting and it has its own credentials. This is the part people skip past. The login that reaches the backup isn't a Microsoft three hundred sixty five login. It lives in the vendor's system with its own password policy, its own multifactor prompts, and its own list of who's allowed in. So a stolen global administrator account in your tenant opens nothing there. The attacker can empty every bin, wipe every site, and rewrite every policy. And the backup doesn't notice because it never trusted that identity in the first place. That leads to the control plane. The control plane is the place where you set the rules. What's protected, how often, how long it's kept, who can delete it? For Microsoft three hundred sixty five backup, that place is your own admin center tied to your own tenant for an independent product. It's a separate console running outside the tenant altogether, and that separation is what lets it survive. The worst case, the tenant level event, say the whole tenant is locked or hijacked or suspended over a billing dispute. Everything that depends on the tenant goes dark together. An independent control plane keeps working because it never depended on the tenant to begin with. You can still sign in and still see your restore points and still start a recovery. Now retention native backup keeps restore points for a fixed period set by the service. Third party tools usually let you choose a year for most content. Seven years for finance, ten for a regulated team. Some let you keep daily copies for a month, weekly copies for a year, and monthly copies for a decade. So storage costs stay sane while the history stays long. That flexibility closes the gap we described earlier. The slow corruption found at month fourteen isn't past the edge anymore. The restore point from before the damage is still there. Next, where you can restore to native restore puts content back into the same tenant it came from. That's fine for a deleted folder. It's a problem when the tenant is the thing that failed. Many independent products can restore across tenants. You spin up a clean tenant, point the tool at it and bring mailboxes and sites back into a place the attacker has never touched. It also helps with everyday business events a merger, a divestiture, a tenant to tenant move. The same capability that rescues you from a disaster also moves data cleanly when nothing went wrong. And then there's the exit. Most products can export your data in open formats mailboxes as PST files, documents as plain files in their original folder structure. That sounds minor until you picture the alternative, which is data that can only be read through one vendor's software. Open formats mean the backup is still usable if you change tools, or if the vendor changes terms, or if you're asked to hand a slice of it to a court. Now, coverage, which is where the gap is widest. Microsoft three hundred sixty five backup covers three workloads. Independent products commonly cover more teams chats, where the tool can capture conversation history and let you recover it as a readable record or restore it where the platform allows planar boards and tasks, entry ID objects like users, groups and app registrations, and in a growing number of products, parts of the power platform, including apps, flows and the data behind them. Coverage varies by vendor, and it changes with every release. That's the honest caveat. Two products can both say Microsoft three. Sixty five backup and protect. Very different lists of things. The list is what you're buying, so an independent copy gives you separation, longer memory, a way out of a compromised tenant, and a wider net. But none of that means anything until you can say what you need from it. How much loss you can live with. How long you can stay down. Without those two numbers, you can't judge any option on the table, Microsoft's or anyone else's. And those numbers have names. Recovery objectives explained for executives. Two numbers decide everything in a recovery plan RPO recovery point objective. How much data can we afford to lose? That one's measured backward. The system fails at three p m. Your last good copy is from noon. You lost three hours of work. An RPO of four hours means you accept that an RPO of fifteen minutes means you don't tow recovery time objective. How long can we afford to be down? That one's measured forward. The clock starts when the damage lands. It stops when people can work again, not when the restore job finishes. When a real user opens a real file and it's there. Those are the definitions. They fit in two sentences. Most people nod along, but here's where it breaks. Nobody in it can set these numbers alone because they're not technical settings. They're statements about what the business can survive, and the business is the only one who knows. What typically happens is that it picks a default. The backup runs nightly because that's what the tool suggests. The restore takes a day or two because that's what the last test felt like. Those become the RPO and RTO, not because anyone decided because nobody did. And the default is a decision you made without knowing you made it. Think about what a nightly backup really says. It says every Tuesday you're willing to lose everything from Monday night forward, up to twenty four hours of mail, edits, and approvals. Maybe the finance team closes the quarter on a Tuesday. Maybe a sales team signs three contracts that afternoon. The default doesn't know it treats every day and every department the same, so the number needs an owner outside it. And it needs to be a number. Not as fast as possible, not minimal downtime. Those phrases feel responsible. They commit to nothing. And hours an hour. Four hours is four hours. You can price one and plan around it. So how do you get a real number out of a department head? Don't ask them for an RPO. They'll stare at you, ask the question they can actually answer. What is an hour of lost email worth? Then let them work it out. How many people in your team depend on email to do the job? What do they do in an hour if the whole team is blocked for an hour? What's the cost in salary alone? What deals slip, what customer waits, what deadline gets missed? Sales might say two hours of no mail on a Friday near quarter end and we lose a deal. Now you have something legal. Might say we can tolerate a day, but we can't lose a single message from the last week because we may be asked to prove what was sent. That's a tight RPO and a loose RTO. It's the opposite of what sales needs. Different answers from different people about the same workload. That's the point. The numbers aren't the same across the company. They shouldn't be. Treating them as uniform means overpaying to protect low value content, or under protecting the content that can sink a quarter. And once a number is written down, something changes. It stops being an opinion. A manager can say our RTO for Finance Mail is four hours. Then it can answer honestly. Our current setup delivers two days. Now there's a gap, and a gap can be funded, accepted or closed. Without the number, there's no gap. There's just a feeling that things are probably fine. So the work isn't choosing a product. The work is getting a number from each part of the business in writing with a name next to it. Then you hold every tool up against it, and the numbers aren't abstract once you attach them to a workload, each one fails differently, restores differently, and takes a different amount of time to come back. So let's apply them one workload at a time, starting with the one everyone uses before they've had coffee exchange online. Setting RPO and RTO for Exchange Online. Start by asking which kind of restore you mean. Because Restore Exchange isn't one job, it's three. Each has its own clock. An item restore brings back a single message, a folder, or a handful of emails. A user deleted the wrong thread. That's the small one. Native tools handle it well. Recoverable items gives the user or an admin a way to pull the item back in minutes. A mailbox restore is bigger, the whole mailbox is damaged, emptied, or gone. Native options here are thin. A deleted mailbox can come back within its grace period. A held mailbox can be searched and exported, but a mailbox that was altered, not deleted has no rewind, and a whole tenant restore is the one. Nobody has practiced hundreds or thousands of mailboxes all at once, all to the same moment. Native tools don't have a path for that, so look at what native actually delivers in numbers for item recovery, the RPO is close to zero as long as the item is still inside the fourteen to thirty day window. The RTO is minutes. That's a strong result for the most common mistake for anything else, the honest native RPO is whatever survived. The RTO is however long it takes someone to export, sort, and rebuild by hand. Days is typical. Sometimes the answer is that it can't be done. A backup product changes the shape of that restore. Points are captured on a schedule. The RPO becomes the gap between snapshots every four hours or every few hours or less, depending on the product and the plan and the RTO for a mailbox drops from days to hours because the tool puts the mailbox back as a unit, not as a pile of exported items. Now, the cases that don't fit the standard picture shared mailboxes. They have no user, often no license, and no one who checks them. A support inbox or an invoices inbox can hold years of customer history. When one is deleted, nobody notices until a customer calls. Treat each shared mailbox as its own line in the plan with a named owner. Resource mailboxes. The rooms and equipment matter less for content and more for calendars. Losing one means losing bookings. The data is small. The disruption is loud. 00:51:29 Speaker: Than public folders. Older, awkward and still alive in many tenants, some hold decades of shared records. Native protection for them is limited. Many backup tools handle them differently or not at all. If you have them, ask about them by name. And there's one more question. Not every mailbox matters equally. An executive mailbox holds board mail, deal talk, and decisions that never get written down anywhere else. A legal mailbox holds the thread you may be asked to prove in court. Those two deserve their own tier. Tighter. Faster. Toe tested. More often. A general mailbox for a warehouse team can sit in a looser tier. Not because the people matter less, because the cost of losing a day of that mail is a different number. Put it in a table and a pattern shows executives and legal get the shortest windows. Core business teams come next. Shared and resource mailboxes get an owner and a decision. Everything else takes the default on purpose this time. That's exchange. It's the workload with the most mature native safety nets. It still leaves gaps between item, mailbox and tenant. SharePoint carries a different kind of risk, not because it holds more data, because it's data has structure, and structure is harder to put back than then. Content setting, RPO and RTO for SharePoint online. A SharePoint tenant isn't a pile of files, it's a web start with the unit. A site collection is the container inside it. Sit libraries, lists, pages, permissions, and settings. Then hub sites tie several of those containers together, so navigation, search, and branding flow across them. A project site rolls up to a department hub, and that hub rolls up to a company hub. And below all of it, the dependencies nobody drew on a diagram. A list on one side feeds a power automate flow on another, a page on the intranet links to a library three sites away. A team's channel folder points at a site that also serves a client portal. So when someone says restore the finance site, the first question is which finance site? And the second is what else was leaning on it? Because restoring a site isn't the same as restoring its files. We saw that with the library rollback files come back, but a site is files plus structure and structure is where the pain starts. Take permissions. A site has owners, members and visitors inside it. Individual folders and files may carry unique permissions that someone set by hand two years ago. If a restore brings the content back but resets those permissions. People either can't see what they need or they can see what they never should have. The second one is worse because nobody complains about it, then links every shared link, every embedded link on a page, every bookmark in someone's browser, points at a specific address, and sometimes a specific item ID restore into a different location, or restore an item as a new copy and the old links break quietly, the file exists. The path to it doesn't. Then metadata columns. Content types. Who created the file? Who changed it last. When retention labels approval status. A restore that returns the document but loses its metadata. Hands a lawyer a file with no history on it. So a good tool for SharePoint can't stop at the site is back. It has to say the site is back with permissions, links, and metadata intact. That's a stricter test and fewer tools pass it than their sales pages suggest. And here's the part that surprises people a restore can finish clean and still look broken. A user opens a library. The files are there, but the view is gone. The one grouped by project and sorted by due date or the folder they used every morning is missing because it was restored under a different name or a flow that fed the library stopped running and nothing new has arrived since the restore. Technically, the data is back. Practically, the user can't work and the user doesn't care about the difference. That's why the clock doesn't stop. When the job finishes. It stops when a real person says this looks right. Put that in the objective itself as a past condition, not an afterthought. Now, how do you set numbers for something this tangled, not side by side? There are too many of them. Tear them by what the business loses. Tier one is the small set that stops work. If it disappears, the intranet home, the contract library, the site where finance closes the quarter. These get tight objectives and RPO measured in hours and in ratio measured in hours. Two. With named owners who've agreed to the numbers. Tier two covers active team sites and project spaces. Important, but a day of lost edits hurts without being fatal. Looser windows and a standard process. Tier three is everything else. Archived projects, old event sites, abandoned experiments, native tools and a longer restore time are fine here, and saying so out loud saves money. One more step map the dependencies for tier one before you need them. Know which hub it belongs to, which flows. Touch it and which teams sit on top of it. A restore plan that doesn't list those is a plan for half a recovery. That's SharePoint complex structure. Narrow tolerance for restore that merely looks finished. OneDrive is the reverse. Each one is simple, flat, and personal. The difficulty isn't the shape of a single account. It's what happens when you multiply it by the whole company. Setting RPO and RTO for OneDrive one OneDrive is small one person, one folder tree, one set of files. Losing it hurts one person on one bad afternoon, and the native restore we covered handles that case fine, but that's not how the failure arrives. Ransomware doesn't hit one account. It hits whoever clicked, whoever approved the prompt, whoever's laptop was online when the code ran. So the scope is per user and the impact is tenant wide fifty accounts, then two hundred, then the whole sales floor. Each OneDrive is a separate restore. Each one has its own damage window, its own restore point, and its own owner, who may or may not have noticed yet, which means the objective can't be written per account. It has to be written for the pile, and that changes the metric. Most teams ask, how long does one OneDrive take to restore? It's the wrong question, because the answer is always five minutes, maybe an hour. For a heavy user, the right question is how long until three hundred of them are done? That's bulk restore speed, and it's the number that decides whether a Monday attack is over by Wednesday or still running next Friday. So put it in the objective as a rate. How many accounts per hour, at what average size with what level of human attention? If the answer needs an admin to babysit each job, the rate is low and you should say so on paper. If it's scripted or handled by a bulk tool, the rate climbs. Either way, the number should be measured in a test, not read off a product page. Now look at what makes the pile bigger known folder move. It's the policy that redirects desktop documents and pictures into OneDrive. It turns it on because it protects users from a dead laptop. And it does. But think about what it does to the attack surface before a user's working file set on a local disk. A laptop failure meant losing them after those same files sit inside. OneDrive synced everywhere, which is great for a dead laptop and bad for a sync driven attack. The thing you move to make files safe is now the thing the sync client carries encrypted copies through, so a known folder move shifts the risk. It doesn't remove it. It turns a local loss into a cloud wide one, and it makes one drive the only home for files that used to have a second copy by accident. If you roll it out, your RPO for OneDrive stops being a convenience number. It becomes the only protection those folders have. Then the last case levers. We saw how the license trap works. Here's the OneDrive side of it. When an account is removed, its OneDrive enters a retention period before deletion. The default is ninety three days for a deleted user's site. Depending on how the tenant was set up, admins can change it. Managers can be given access to the files during that window, but notice how quiet it is. Nobody's logged in. Nobody's checking the files. Sit there and at the end of the period they're removed. So alive as OneDrive needs its own objective who inherits access, who reviews it, who decides what's kept, and for how long. Without those answers, the ninety three days run out on a schedule nobody wrote down, and a former employees work disappears on an ordinary Thursday. That's OneDrive. Simple in shape, hard in volume, and exposed by the very policies meant to protect IT teams is the opposite problem. It isn't hard because of volume. It's hard because there's no single thing to restore, which means no single objective to set. Setting RPO and RTO For teams, you can't set one objective for a team. There's no single thing to hold it against, so take the team apart first and write a number for each piece. The files live in SharePoint. That's the library behind the files tab, and it follows the SharePoint objective. You've already set the mailbox and calendar sit in exchange behind the group membership and ownership live in the Microsoft three hundred sixty five Group, which means they live in entry ID planner boards, OneNote notebooks, and the apps pinned to channels each have their own home and their own rules, so a team has at least five owners of its data, and each one can fail on its own schedule. A good plan names them in a short table piece location RPO, RTO who signs off it takes an afternoon to write. Most tenants have never written it. Now the piece everyone worries about chat and channel messages. Here, expectations and reality don't match. People assume that if a message disappears, it can come back the way a deleted file does, and if it was only deleted, retention can often keep a copy. That copy sits in a hidden folder in a mailbox built for search and legal review. You can find the message there. You can export it. What you can't do is put it back into the channel in order with replies, reactions and the thread intact. So the honest Po for chat is a question. Do you need the words preserved or the conversation restored? Those are different goals with different price tags. For most departments, a searchable record is enough for a few. A lost thread means a lost decision, and the answer should be a tool that captures conversations in a readable form. Ask the team which one they mean before you write the number. Then the forgotten parts meeting recordings. These land in OneDrive or SharePoint depending on the meeting type, and they follow the retention of whoever owns the file. Some tenants auto expire them after a set number of days, so the recording of last year's board call may be gone by design, and nobody remembers agreeing to that. The wiki tab. It's a legacy feature stored as a file inside the teams library, and easy to overlook because it doesn't look like a file. If it's deleted, it takes the notes with it and apps, tabs, bots, connectors, and custom apps pinned to channels. Their settings and data usually sit with the app, not with teams. Restore the team, and the tab might point at nothing, or it might point at a service that needs a fresh sign in a new connection or an admin to approve it again. So put each of those on the list too. Not because they're big, because they're the pieces that make a restored team feel empty. And here's the statement worth saying out loud before it comes up in an incident. Some teams data may only ever be recoverable as an export, not as a live restore. A file comes back as a file. A mailbox item comes back as a mail item, but a conversation with all its structure may come back as a document. You search, read, and hand to someone who needs it. That's not a failure of planning. It's the shape of the product. The mistake is writing an objective that promises a live restore, and then finding out during an outage that the tool can only deliver a record. So write the objective in the form you can actually deliver restored as live content within four hours for files in the group. Recovered as a searchable export within one day for chat. Both are legitimate. Only one of them is honest about chat. Now you have objectives for every workload exchange, SharePoint, OneDrive, teams, numbers, owners, and pass conditions. On paper, they look finished. And that's the danger because a number on paper is only a claim. Nobody knows if the tools can hit it until someone runs the restore. Why most restore plans have never been run. Here's the pattern. In most organizations, someone buys a backup product, there's a budget line, a vendor call, a proof of concept, and a signed contract. The tool gets switched on, a dashboard turns green and the project closes. Then comes the quiet assumption. Backup is done, so restore will work. But nobody wrote that down as a claim. Nobody checked it. The purchase was the proof and the proof was never tested. So the plan exists as a feeling shared by everyone who wasn't in the room when the tool was configured. And the dashboard doesn't help. It's built to make you comfortable. A green status says the job ran. It says data was read, copied, and stored. It doesn't say the data can be put back. Those are two different claims, and the dashboard only makes the first one a backup can complete every night for two years and still fail the first time someone asks it for a mailbox. So where does it fail? Quietly throttling is the common one. We'll get to the physics of it later, but the short version is that Microsoft limits how fast any outside tool can pull data. When a backup job hits that limit, it slows down retries and sometimes skips items it couldn't reach in time. The job still reports success because most of the data made it. The skipped items sit in a log. Nobody reads. Permissions are another. The account the backup tool users may lose rights after a role change. A conditional access update or a password policy. No one connected to the backup. The job can't read a set of sites anymore. Some tools flag it. Some tools just backup less and then exclusions. A site was left out during setup because it was new. A shared mailbox was never added because it had no license. A group of levers was skipped on purpose, then forgotten months later. Those are the exact items someone needs. The backup is complete in the sense that it contains everything you told it to contain. None of these show up as a failure. They show up as a gap, and a gap only becomes visible when you try to fill it. Now look at who asks the question. An auditor asks, do you have a backup process? Is it documented? Is it running? Those are fair questions, and a good answer is a policy document, a screenshot of the console and a recent job log. The auditor leave satisfied and the organization passes an incident, asks something different. It asks, can you bring back these four hundred mailboxes as of Tuesday in six hours? While the attacker may still be watching, it doesn't care about the policy. It cares about the clock, the credentials and whether the restore job survives its first contact with a real tenant under stress. So one of them checks that a process exists, the other checks that it works. And most organizations are built to pass the first one. The result is a plan that looks finished on paper and has never been used by a human being on a bad day. Nobody knows how long the steps really take. Nobody knows which account runs them. Nobody knows what the tool does when two thousand items fail at once. That's the piece that has to change, not the product and not the budget. The habit of treating a purchased tool as a proven one. So the next question is how you test it? Not with a demo and not with a vendor walkthrough. With a method that you can repeat, measure and run again when the tenant changes. How to test a restore. A practical method start with scenarios, not features. A feature test asks does the restore button work? It will. Every vendor has demoed it a hundred times. A scenario test asks something harder. Can we survive this specific bad day? So write the bad days down for is enough to begin a deleted mailbox and executives. Ideally because that's the one the business will notice first. A wiped site. Pick a tier one SharePoint site. The contract library. The finance closed site. Treat it as gone. Mass. OneDrive encryption. Not one account a group of fifty. Because the pile is the problem. A single account teaches you nothing about the pile and a deleted team. The files, the group, the mailbox, the channels, all of it at once. Each scenario gets a one page script. What broke as of when and who's asking for it back now? Define what passing means before you run anything. This is the step team, Skip, and it's why their tests prove nothing. If you decide the pass criteria after the restore finishes, you'll find a way to call it a pass. So write three conditions. Time. The clock starts when the scenario is declared. It stops when a user confirms the content works, not when the job says complete. You already have an RTO for each workload, so that's the number you're testing against. Completeness. Compare what came back to what should have come back. Item counts, folder counts, sizes. Pick a sample and check it by hand. For a site, check permissions on three folders you know have unique access. Check that the links still resolve. Check the metadata on a few documents. Completeness means the structure, not just the files and usability by a real person. This one matters most. Put someone from the business in front of the restored content. Someone who didn't help run the test asked them to do their normal morning. Open the usual folder, find the usual file. If they hesitate, write down why now? Where do you restore to not production? Not the first time. Restore to an alternate location. First a scratch site, a test mailbox, a separate library. That's where you find out the basics. Whether the tool reaches the data, whether the account has the rights, whether the steps in your notes are the steps you actually take. Mistakes here cost an afternoon, not a customer. Then move closer to the real thing. Production like conditions means the same permissions model, the same volume, the same time pressure. Restore a full tier one site into a staging copy of the tenant structure. Run the OneDrive bulk scenario with the real number of accounts, not three. Restore that works on ten items and chokes on ten thousand hasn't passed anything. And while it runs, write everything down. Record the time at every step. Declaration. Scoping. First command. First bite restored. Last bite restored. User confirmation. Record the exact steps in order, including the ones that weren't in the plan. The permission request that took forty minutes. The approval from someone on vacation. The command that needed a different syntax than the documentation said record the people to who ran it, who approved it? Who got pulled in at the last minute. If one name appears on every step, you don't have a plan. You have a person. That record is the real output. The restore itself is just how you generate it. Now, how often quarterly is a sensible floor? Not every scenario, every time rotate them. So each one runs at least once a year. And the highest risk one runs more often and run it again after any tenant change. A new conditional access policy, a change in admin roles, a new backup product, a switched on workload, a license change, a merger. Each of those can quietly break a restore path and none of them will tell you do this and the numbers on paper start to mean something. But even a clean test can mislead you, because the restore that ran in an afternoon with fifty accounts won't scale in a straight line to five thousand. And the reason isn't your tool, your team, or your plan. It's a limit that sits outside all of them, one that most teams only meet on the day. It matters. Throttling bandwidth and the physics of restore. Every restore runs into a ceiling, and it isn't set by your tool. Microsoft protects its service with limits when any outside application asks for data through Microsoft Graph or the workload APIs. The service counts the requests asked to fast, and it answers with a polite refusal slow down. Wait. Try again. That's throttling. It exists for a good reason. One tenant's bulk job shouldn't slow down everyone else's mail. But for a restore, it means the pace is set by the service, not by how much hardware the vendor bought and the limits apply per app, per tenant and per workload. So a tool that reads fast during a quiet Sunday backup can crawl on Monday morning when your own users are hitting the same service at the same time. Now put real numbers on it. Say you need to restore twenty terabytes. A tenant of a few thousand people can reach that without trying. A vendor slide might say up to five terabytes a day. That's a fair number in a lab with a clean tenant and no competing load. Do the math. At that rate, twenty terabytes is four days of continuous running at a more realistic two terabytes a day. It's ten and that assumes nothing fails. No expired token, no batch of items stuck in retry, no second wave of throttling because the restore itself looks like an attack to the service. So the honest answer is days, not hours. Whatever the brochure says. 01:08:53 Speaker: And there's another gap people miss. Restoring isn't one big stream. Files are small, and many a million small items take far longer than one large video. Because every item is its own request with its own overhead. Terabytes tell you the size. Item count tells you the time. Now look at how Microsoft three. Sixty five backup changes this. As we saw, it doesn't queue at the public door. It runs inside the platform close to the storage, and it uses internal paths to copy content back. That's why Microsoft talks about restoring large volumes in hours for SharePoint and OneDrive. The architecture really does remove the biggest gate, but look at what that claim covers. It covers three workloads inside Microsoft's own boundary. It says nothing about the third party tool, restoring teams, chats, intra objects, or a mailbox into a different tenant. Those still go through the front door and they still meet the limits, so the layers behave differently. The in platform one is fast, the independent one is slower but separate. That's a real trade off and you should plan around both speeds, not average them. So what do you ask a vendor? Don't ask how fast is your restore. You'll get a headline number. Ask for measured throughput in your conditions. How many gigabytes per hour on a tenant like yours? Restoring mailboxes and sites at the same time. Measured by whom and when? What happens to that number when throttling kicks in? Does the tool slow down gracefully, or does it fail items and tell you later? Then ask the question that matters most. Can I run a bulk restore at my scale during a proof of concept? A vendor who agrees is confident. A vendor who suggests a demo instead has told you something too. And write the answer into your toe. Not their best case, your tested case, but even a fast restore can't help if the wrong person can reach the tools. Speed matters little when the attacker still holds the keys. So the next question isn't about data at all. It's about who can touch the backup and what happens when that identity is the one that's compromised. Protecting the backup itself. A backup is a target. Attackers know that. The good ones look for it first before they touch a single file. Because if they can reach the backup, the ransom note stops being a threat and starts being a price. So start with the accounts. The person who manages backups shouldn't be signing in with the same account they use for email, or the same account that approves purchases or joins, calls or clicks links all day. Give the backup layer its own admin identities. Separate names. Separate passwords used for one job only. Why? Because everyday accounts get phished. It's the most common way in. And an account that reads mail is an account that can be tricked. An account that only ever opens the backup console has far fewer chances to be fooled. Then lock those accounts down. Multi-Factor authentication and not the weakest kind. A text message code can be intercepted or talked out of someone. A hardware key or a phishing resistant method can't add conditional access on top. Allow sign in only from managed devices, only from known locations, and only with a compliant machine. If the login doesn't match, it fails even with the right password. And if the backup product lives outside your tenant, those rules need to exist there too. Different systems, same discipline. A strong policy in one place doesn't cover a weak one in another, another copies themselves. Think about what an attacker with admin rights wants to do. Delete the restore points. Shorten the retention, change the schedule so nothing new gets captured. All of that can be done quietly in a few clicks. If nothing stops it. That's where immutability comes in and immutable backup can't be changed or deleted for a set period. Not by a user, not by an admin, not by the vendor's own support staff. The storage itself refuses the request until the clock runs out. A retention lock works the same way. One level up, it freezes the policy. Even a global administrator can't shorten the retention window once the lock is set. The attacker holds the highest role in the tenant, and the setting still doesn't move. But here's the catch. Immutability only works if you turn it on. And if you can't turn it off in a hurry. Check how your product handles it. Some tools offer it. Some bury it. Some let a single admin disable it with one confirmation. A lock that opens easily isn't a lock, so ask a plain question who can delete a backup? Not who should. Who can count the actual names? Go through the roles, the backup admins. The tenant admins who can reassign roles, the vendor's support team, the billing owner who can cancel the subscription, and canceling often means the data goes with it. People are usually surprised by the total a list they expected to hold. Two names turns out to hold twelve. Every name on that list is a way in, so shrink it. Fewer people with delete rights require second approval for destructive actions. If the product supports it, and review the list on a schedule because roles pile up and nobody removes them. Then plan for the day the tenant isn't yours anymore. Suppose the attacker is inside and you've locked them out, and now you need to reach the backup. But the backups login depends on the same tenant and the tenant is in chaos or suspended or hijacked. That's what a break glass procedure is for. A way in that doesn't depend on the thing that's broken. Keep emergency credentials for the backup layer outside the tenant, printed, sealed, and stored somewhere physical or in a vault that doesn't sign in through Microsoft. Name the two people who can open it. Write down the vendor's emergency contact with the phone number because email may not be working, and test it the same way you test a restore. If nobody has ever used the sealed envelope, nobody knows what's inside it. All of that protects the data, files, mailboxes, sites. But data is only one thing a tenant loses on a bad day. Recovery beyond data, identity, config and everything else. Picture the tenant after a bad week. The files are back, the mailboxes are back, and nobody can sign in the way they used to because data sits on top of something, a layer of identity and settings that decides who gets in from where and what they're allowed to touch. Backup tools mostly protect the content. The layer underneath is the part people forget to list. Start with entry ID users groups, and app registrations. A group isn't just a list of names. It controls access to a team, a site, a mailbox, a license assignment deleted, and everything that trusted it loses its footing. Some deleted objects can come back from the recycle bin for a short window. After that, they're gone and they come back as new objects with new IDs. Nothing that pointed at the old ID knows about the new one. Then conditional access. These are the rules that say who needs multifactor? Which devices count as trusted? Which countries get blocked? Most tenants have dozens built up over years, with exclusions added after specific incidents. An attacker with admin rights can change them in minutes and if nobody exported them, nobody remembers the exact logic. You rebuild from memory and you get it almost right. App registrations carry the same problem. Each one holds permissions, secrets, redirect addresses, and consent decisions. Lose them and every integration that used them stops the line of business app, the automation, the backup tool itself. Now the workload settings exchange mail flow rules decide how mail is routed, tagged, blocked, and signed connectors decide how it reaches partners, SharePoint admin settings, cover sharing limits, external access and storage rules. Teams policies control who can meet, record, chat with outsiders, and install which apps. None of that is content, so none of it comes back when a mailbox or a site does. And that's why rebuilding configuration is slower than restoring files. A file restore is a copy. It has a size and a speed, and you can measure both. A configuration rebuild is a series of decisions. Why was that rule there? Which exception was it for? Who approved it? Which policy depends on which group each answer lives in someone's head or in a ticket from three years ago, or nowhere at all. So the clock doesn't run on bandwidth. It runs on people and on memory. A team can restore terabytes in days and still spend weeks getting the tenant to behave the way it did before. During that time, users work around the gaps and the workarounds become new problems. There's a cheap partial answer though, right? The configuration down in a former machine can read. That's configuration as code. Export your conditional access policies as files, export mail flow rules, transport settings, and teams policies the same way many of these can be pulled with PowerShell or the graph API in a few lines. Store the export somewhere outside the tenant in version control if you can. So every change has a date and a name next to it. It isn't a full backup. Exports don't capture everything, and some objects can't be recreated with the same IDs, but even a plain export turns a rebuild from. What did we have into. Apply this file and check it. That's days saved for almost no money. Schedule the export, run it weekly or after every change and test it the same way you test a restore by applying it to a scratch tenant and seeing what breaks. Now there are a lot of pieces on the table. Native tools Microsoft three. Sixty five backup an independent copy content and configuration. Different workloads with different clocks. They need to fit into a single way of deciding one that a person can use. On a Tuesday with a budget meeting on Wednesday, a decision model native Microsoft three hundred sixty five backup third party three layers, not three products to pick between three levels of protection, and each one earns its place by what it costs and what it covers. Start at the bottom. Tier one is native tools only. Recycle bins. Recoverable items. Versioning. The OneDrive restore window already paid for, already on and for the right content. There enough. A project site that closed last year. A shared folder of event photos. A team that chats about lunch lose a day of that someone's annoyed and the world keeps turning. The test is simple if the content is low risk, short lived, or easy to rebuild, native is a fine answer. Saying so on purpose in writing is a decision, not saying so is the default. Tier two is Microsoft three. Sixty five backup. This is for the core workloads where speed matters, the sites that hold contracts, the mailboxes that run finance, the OneDrive accounts of a sales floor that can't work without them. Here, the question isn't whether the data can come back, it's how fast and in what shape a first party restore inside the tenant boundary with point in time options gives you hours where native tools give you days. That's the layer you reach for on an ordinary bad day. When someone deletes the wrong thing or a sync mishap spreads, it's your fast lane. Tier three is a third party independent copy. Separate storage. Separate credentials. Separate control plane. This is for the content you can't lose under any story. Regulated records. Executive and legal mail. Anything where the failure scenario is the tenant itself, whether that's a compromised global administrator, a malicious insider with the keys, or a vendor level problem you don't control tier two lives close to the thing it protects. Tier three doesn't, and that distance is the entire point. Now here's the shift. Most teams treat this as a menu. Pick one. Compare prices. Read the feature list. Choose a winner. But the tiers aren't competitors. They answer different questions. Native answers the small mistake in minutes. Microsoft three hundred sixty five backup answers the big restore in hours. The independent copy answers the day when the first two can't be trusted. Pull one out and a specific scenario goes uncovered. So layer them tier one for everything because it's already there. Tier two for the workloads you mapped as business critical. Tier three for the narrow slice where the objective is tight, the regulator is watching, or the attacker is likely to go after the backup itself. Each layer sits on a smaller set of content, so the cost per layer shrinks as the protection gets stronger. And that's where the budget conversation usually stalls. Someone sees a per user price and winces. So reframe it. Don't compare the price to zero. Compare it to the cost of one bad week. Take a company of two thousand people. Say a ransomware event takes mail and files down for five working days, even at partial capacity. Count the salaries of the blocked hours. Count the slipped deals, the late filings, the overtime for it, the outside incident team, the legal bill, the customer who leaves for most organizations that lands in the millions. Now put a protection layer next to it that costs a few dollars per user per month. The math isn't close, but notice what the math needs. It needs the number you collected from each department earlier. The cost of an hour. That's what turns a price into a comparison and run it the other way, too. If a tier three copy for the whole tenant costs more than the loss it prevents, you've protected the wrong things, fit the layer to the tier, spend where the number is high and stop where it isn't. That gives you the model three layers matched to the objectives priced against the loss, but a model on a slide doesn't restore anything. It only means something when the bad day arrives and the plan has to run against a clock. An attacker and a team that hasn't slept. So let's watch it play out. Hour zero to day seven an incident timeline. Hour zero to day seven. Hour zero doesn't start with a restore. It starts with a signal. A user can't open a file. A security alert fires on mass file changes. A helpdesk queue fills with the same complaint and someone finally connects the dots. Then comes the part everyone wants to skip. Don't restore anything yet. First, stop the damage. Disable the compromised accounts, revoke their sessions and tokens. Pause OneDrive sync where you can. Because a restore into a library that's still syncing encrypted files just feeds the problem. A fresh meal if the attacker holds an admin role that comes first before anything else on the list, then scope it. Which accounts, which sites, which mailboxes, and from what moment. The audit log and the sign in history. Answer that the goal is one clean timestamp. The last point when the data was good. Without it, you'll restore to a guess, and a guess can bring the damage back with it. This takes hours. It always feels too slow, but a restore started before containment and scoping often gets overwritten twice. Now there's a tension nobody mentions in the planning meeting. You need service back. You also need evidence. The logs, the change files, the attackers mailbox rules, the forwarding addresses the app consents, overwrite them with a restore, and you lose the trail that tells you how they got in and whether they still can export the audit data. First snapshot the affected sites. If you can restore into alternate locations where it makes sense and keep the damaged originals untouched until security says they can go legal and the insurer will ask for this later, and so will your own team on the day they need to prove the door is shut. So the restore runs in parallel with the investigation, not instead of it. When it does begin, the order matters. Identity first. Nothing else works without it. Sign in. Multi-Factor conditional access. Group membership. The admin roles themselves. If the identity layer is wrong, every restored file lands in a tenant that trusts the wrong people. Mail second. It's what people reach for first, and it carries the decisions, the approvals and the password resets. Executive and legal mailboxes lead, as the tiers say. Then collaboration tier one SharePoint sites. Then the teams built on them, then OneDrive accounts in batches, starting with the groups that can't work without their files, and then the long tail tier three sites, archived projects, shared mailboxes nobody opened this year. They come back last on purpose. Now, communication because silence does its own damage in the first hours. Tell users the plain facts something is wrong. Here's what to do. Here's what not to touch. Don't promise a time you can't hold to leadership. Give a short update on a fixed schedule. Whether or not anything changed every two hours. Then every four. What we know. What we don't. What's next? A leader who gets a steady rhythm of honest updates stops calling the incident room for answers. By day two, the pattern shows itself. The restore is slower than the plan said throttling has set in. A group of items failed and nobody saw it because the job reported success. Someone discovers a shared mailbox that was never in scope. Someone else finds a team whose chat can only come back as an export. The permissions on a restored site don't match what the owner remembers, and the people have changed. The two engineers who knew the steps are exhausted and the sealed envelope turns out to hold an expired credential. None of that is bad luck. Each item is a gap that a test would have found, and each one costs a day in a real incident, which brings it back to the structure. The plan is not the tool, it's who owns the decision, who holds the credentials and who's allowed to say restore now. Governance, ownership and the questions to ask Monday. Ask who owns backup in your organization. You'll get one of four answers. It says it's theirs because they run the tenant. Security says it's theirs because ransomware is a security event, compliance says it's theirs because retention is a policy, they wrote. And in a surprising number of companies, the honest answer is nobody. Each one fails in its own way. It owns the tool but not the business numbers. So the RPO is whatever the product defaults to. Security owns the threat, but not the restore. So the plan stops at containment. Compliance owns the policy but not the clock. So they can prove content existed and can't say how fast it comes back. And nobody means the first owner is whoever happens to be in the room during the incident. So pick one, not a committee one named role that is accountable for the restore with the other three feeding it numbers, access and requirements, then write the name down. Now five questions. Ask them Monday in a plain meeting with no slides. What is covered? Not what you meant to cover what's in scope today. Workload by workload including shared mailboxes, teams, chat and the sites someone added last month. What is the RPO for each tier as a number, not frequent hours or a day with a business owner who agreed to it. When did we last restore? Give me a date, a scenario and a result. If the answer is we've never run one, that's your answer. And it's an honest one who can delete the backups, count the names, then count again, including the billing owner and the vendors support staff. And where is the copy, which system, which credentials, which tenant? If the answer is in the same place as everything else under the same admin accounts, then you have a second copy of the data and the same single point of failure. Five questions. Each one takes a minute to ask, and each one can take a week to answer properly. That gap is the finding. Then do the part that makes it stick. Write the answers down and put a date next to every one. Not we have backup instead. Exchange covered RPO four hours last restore test at March twelfth passed in two hours, ten minutes. A date turns a claim into a record, and a stale date tells you where to look next without anyone having to argue about it. Review the page every quarter when a date gets old, that's the task. That's the real change. For years, the question was whether the tenant retained the data retained as it kept somewhere under a policy for some period. It's a comfortable word because it needs no proof of use. The new question is whether the data is recoverable, by whom, how fast to what state, and has anyone checked retained as a property of storage? Recoverable is a property of a plan that's been run. Conclusion and outro. The day you need to restore is the wrong day to learn the limits. That's the whole argument. And the ninety three days, the fourteen days and the throttling ceilings are just the details. They're all printed somewhere. They're just rarely read until the clock is already running. So hold the model in four steps. Availability is Microsoft keeping the service up? Retention is keeping a copy for the lawyers. Backup is a copy you can put back kept somewhere and attacker can't reach. And a test restore is proof that the first three work together in your tenant, at your scale with your people. Skip the last one and the other three are a belief. Before we close, a quick word about today's sponsor, stellar Migrator for exchange is built for moving mailboxes between environments and for the work that sits next to recovery. When you plan for restore, you end up mapping every mailbox, shared mailbox, and archive. Anyway, that's the same inventory a migration needs. If a move is on your roadmap, or if your recovery plan needs a way to land mailbox data somewhere clean, it's worth a look. Data movement and recovery planning share the same homework and doing them together saves you from doing it twice. And if this changed how you think about your recovery plan, leave a review. It helps more admins find this episode before they need it, not after. Most people only go looking for this topic once something has already gone wrong. If you want to keep going. Connect with me on LinkedIn. Tell me which topic you'd like covered next. Back up for Power platform, enter ID recovery. Anything you're stuck on right now and subscribe to the M365 FM podcast so you hear it first, not at two a m with a restore job stuck at forty.