Simpson Strong-Tie makes structural connectors and fastening systems used in homes and buildings across the world. When I joined as Senior Manager of Enterprise Systems, the company was deep into a digital transformation, moving Exchange and SharePoint from on-premises to cloud. Backup was not part of that conversation, and it should have been.

Many IT teams, including ours, initially assume that cloud migration inherently includes comprehensive data protection. However, it is important to clarify that cloud providers typically focus on ensuring service availability rather than managing individual data backups. We recognised the need to implement a dedicated recovery strategy to complement the native tools provided, ensuring we have robust control over our data restoration.

We licensed Rubrik's M365 protection and went from zero backup coverage to a structured approach. The question after that was not whether the data was safe. It was what to do with that capability when something actually goes wrong.

The hardest question after a major incident is rarely whether you have a backup. It is what to restore first, and for whom. My team's answer to that is a framework built around three things: who needs to be operational, what data they need, and how far back that data needs to go.

By defining that window before an incident, say only the last 14 days of email and calendar for the finance team, the recovery effort becomes targeted rather than total. The goal is that critical business functions are running within hours, not days. My estimate for a priority M365 restore is within the first 24 hours. We have not run a full test against that number yet, but that is what we are building toward.

My initial assumption was that a granular, prioritised restore only applied to Exchange. When I asked one of the experts at Rubrik, the answer changed how I thought about the rest of the suite. You can set restore windows across the whole thing: two weeks for SharePoint, two weeks for Teams, pinpointing last month's active files in OneDrive. That level of specificity matters when you are trying to restore what the business actually needs rather than everything at once.

The clearest illustration I have is one I caused myself. I accidentally merged the wrong folder in OneDrive and wiped out a set of recorded team meetings. My first instinct was to go to the Microsoft Recycle Bin, but finding the right version among dozens of entries is not a straightforward process. A colleague reminded me we had Rubrik. Inside the M365 interface, I could see exactly which copies existed, pick the right point in time, and restore what I needed. The whole thing took minutes. That is the difference between a recovery capability and a recycle bin.

Before Rubrik, the question my team asked was whether the data was backed up. That was the ceiling of the conversation. After going through a cyber event and full recovery, that question is settled, and the ceiling has moved. What I think about now is resilience: not just whether we can recover, but how fast, in what order, and what the business needs to keep running while we do it.

That shift changes how we talk to the business. Instead of reporting on backup coverage, we are now asking what the minimum viable operation looks like on day one of an incident. They tell us which teams and data sets are critical, we build that into a playbook, and we test a time-to-operate estimate against it. That is a more useful conversation on both sides.

If you have not defined your minimum viable business for M365 recovery, that is where to start. The framework is three questions:

Who is the audience? Which teams are critical for customer-facing and revenue-impacting work, and need to be operational on day zero?

What data do they need? Is it email, calendar, SharePoint files, or some combination?

When? How far back does that data need to go? Is 14 days enough to keep the business running?

Those three answers will define your recovery priority before an incident forces the decision under pressure.