Understanding Microsoft 365 Data, What is and Is Not Your Responsibility

Microsoft 365 Hero 1 1280x720 2

When people talk about the security of data in Microsoft 365, invariably phrase you’ll hear – and I don’t know who coined it – “the cloud is just someone else’s computer”. When someone says it to me, I literally have to stop myself from saying “…but actually” before we both explode into memes. Microsoft 365 is technically things that run on computers, but it would be absolutely, utterly, incorrect to say it’s just that.

A short, terrible history of the cloud, but bear with me…

I first visited the cloud back as a young, fresh-faced MVP, and despite having a slight hope that it would, in fact, turn out to all be liquid suspended in the air somehow holding data, it was in fact computers. Lots and lots of them. Prior to visiting a Microsoft facility, I had run data centers in a past job as a systems administrator and visited many co-location facilities and hosting providers; the Microsoft datacenter blew my mind.

Sponsored:  Afi.ai provides a modern solution for backing up Office 365 including full Teams support, SharePoint and OneDrive file metadata and sharing permissions, and many other advanced and modern features.

We’re over a decade into vendors like Microsoft running cloud services, but it still needs to be said – your local IT provider running a “cloud” is not the same as Microsoft or Amazon running cloud services. Your local IT provider – or any similar reasonably large managed data center is not in the same league. Heck, it’s not even the same sport. In most cases, your IT provider is just running the same kit you buy from them, with the same software, with maybe a better fire suppression system and a generator out the back. Microsoft, Amazon, and similar vendors are building out these facilities with custom hardware and installing tens of thousands of servers. A good phrase I heard to describe a Microsoft datacenter was a Cathedral of computing. It was absolutely, utterly epic.

What that should assure you – and that’s why customers and MVPs get occasional tours of these places – is that the physical locations, building security, electrical and environment protections, network connectivity, and hardware are built to a standard these should never be a concern of yours. Because they are global and in multiple locations, then the next part of the equation – and where you should be concerned, is the architecture and software components that you can’t control but need to rely upon.

I don’t even know where my data is anymore, and I like it.

Both Microsoft 365 and Azure are services that abstract the physical components away from you. You don’t know what model server, rack, or even which data hall your data is stored in, because it genuinely doesn’t matter. With Azure, you have the option to build out servers or services, but with Microsoft 365 another level of abstraction is introduced.

Microsoft 365 is a software-as-a-service offering. Ultimately this means you pay to have your service run in a region, rather than a particular data center or city.

That region might be “North America”, or “Europe, Middle East and Africa”, for example. You do not need to concern yourself about exactly where. There’s a list of the cities, sure, but you won’t be able to narrow down where your OneDrive for Business file is stored to a specific set of servers. That’s a good thing; it’s one less thing you don’t need to worry about.

Because, fundamentally, what you are buying from Microsoft when you buy Microsoft 365, Exchange Online, Teams and so on – is an SLA-backed, guaranteed availability, along with a few other things, like keeping it secure, or keeping it up to data with new features.

What is the point of me then?

In 2009, I pretty much stormed out of the IT director’s office when moving to Live@EDU was touted as the destination for my employer’s student email system. I’d spent countless hours nurturing the systems, which mostly entailed poking mail queues and optimizing caching of indexing files on NFS shares. Tasks I’ll truly never miss. At the time though my fundamental question was “what’s the point of me then?”.

It turned out that actually, I didn’t spend a lot of time patching servers or recovering from failures (that’s partly a lie, I was on the Exchange Technology Adoption Program at the time too, so patching and recovering from failure went with the territory) and actually most of the Exchange related work was checking daily backups worked, and most importantly, creating new accounts and granting access to stuff like shared mailboxes and other user-driven requests. The fun stuff was elsewhere – re-architecting business applications for virtualization was a big thing at the time. Email and productivity services require day-to-day administration and needed to be configured and maintained correctly, but the underlying architecture was not a day-to-day job to redefine or tweak.

The crucial part of maintaining your data in Microsoft 365 doesn’t reside in the underlying architecture; it is in the layers above that define in software how it is kept, stored, and secured.

Security and Compliance go together for a reason, both are fundamentally for you to define and configure and Microsoft to keep configured the way you defined. And the same can be said for restoring user roles correctly and efficiently if an individual account is accidentally or maliciously deleted.

Therefore, for Microsoft 365 data, you must define how long all, or some data is kept if you don’t want to use the basic defaults. For example, you might have some folks whose data must be kept for 5 years or project documentation that contractually must be kept for 100 years. That isn’t to say that you’ll keep the data in Microsoft 365 for 100 years, but as long as it’s kept in the service, Microsoft will commit to keeping it in line with those policies; and if you put a lock on those policies, Microsoft commits to making sure a rogue admin can’t remove them or change them. But accidental deletion can still be a problem, if an admin or user works around built-in controls, you should still be prepared to restore business-critical data and not reside solely on Microsoft.

The same goes for security – for example, if you define that John in accounting must only log into a SharePoint site from a particular location or provide Multi-Factor-Authentication from a compliant device, then Microsoft commit to ensuring that those rules cannot be circumvented.

There is a lot of FUD (fear, uncertainty, and doubt) spread about data in Microsoft 365 – the most laughable of these is when a vendor quotes the Microsoft consumer agreement (yeah, the one for Xbox Live and Hotmail) to try and suggest that Microsoft don’t take responsibility for your data in the business and enterprise services – which of course they do, within limits defined by you.