The shared responsibility gap in Microsoft 365 and Google Workspace

When an organization moves from an on-premises mail server to Microsoft 365 or Google Workspace, a genuine and substantial transfer of risk occurs. The provider now runs the infrastructure, patches the platform, maintains availability across regions, and employs a security team larger than most of their customers' entire IT departments. For the overwhelming majority of organizations this is a clear improvement.

It also produces a predictable and expensive misunderstanding. Because so much responsibility moved, people assume all of it did. The provider's own documentation is clear about the division, and almost nobody reads it until they need something the provider does not do.

What the provider is responsible for

Physical infrastructure, the hypervisor and platform layer, service availability, platform-level security, and the durability of the storage itself. If a data centre fails, that is their problem and they will solve it without you knowing. If a platform vulnerability is disclosed, they patch it. If a disk dies, your data does not.

This is a lot, and it is delivered to a standard most organizations could not achieve independently at any reasonable cost.

What remains yours

Your data, your identities, your configuration, and your users' behavior. Each of these is a category where the provider will faithfully execute what you tell it to do, including the things you did not mean.

Data is the one that catches people. The provider guarantees that your data is durable — it will not be lost to hardware failure. It does not guarantee that your data is recoverable from a mistake. If a user deletes a mailbox and the retention window passes, it is gone. If a compromised account deletes a SharePoint library and nobody notices for ninety days, it is gone. If a synchronisation tool corrupts a folder and faithfully replicates the corruption, the corruption is durable too.

Retention periods vary by service and by license tier, and they are shorter than people expect. They are designed as an operational grace period, not as a backup. Treating them as a backup is the single most common gap we find.

Identity is now your perimeter

On-premises, a firewall provided a crude but real boundary. In a cloud tenant, that boundary is authentication. An attacker with valid credentials and no MFA is not attacking your perimeter; they are inside it, indistinguishable from a legitimate user, from any network in the world.

This changes what monitoring means. The signals that matter are no longer packets at a boundary; they are authentication events, consent grants, mailbox rule creations, permission changes, and administrative actions. Most of these are logged by default. Considerably fewer are watched.

The specific ones we would want alerting on, in order

• New inbox rules that forward or delete mail. This is the classic post-compromise action in business email compromise, and it is nearly always the first thing an attacker does.
• OAuth application consent grants. A user consenting to a malicious application hands over persistent, MFA-surviving access to their mailbox and files.
• Changes to authentication policy, conditional access rules, or MFA enrolment.
• Elevation to any administrative role.
• Impossible-travel and anomalous-location sign-ins for privileged accounts.

Configuration is a security control you own

The default configuration of a new tenant is designed to work for everyone, which means it is permissive by design. Several of the settings that matter most are ones you must change.

External sharing defaults frequently allow anyone with a link to open a file. Guest access defaults frequently allow any user to invite an external party into a workspace. Legacy authentication protocols may remain available. Application consent may be permitted for any user without administrative review. None of these are provider failures; they are choices left to you, and the default choice is the convenient one.

Backup, specifically

We are unusually direct about this because it is the gap with the most severe consequence and the cheapest fix.

You need a third-party backup of your cloud productivity data, held outside the tenant, with a retention period you chose rather than one you inherited. It should cover mail, files, and collaboration workspaces, and it should be restorable at the granularity of a single item as well as a whole account.

The objection is usually that the provider already replicates everything across multiple regions. This is true and it is not the point. Replication protects against infrastructure failure. It faithfully replicates deletion, corruption, and malicious action, because from the platform's perspective those are legitimate operations issued by an authenticated user.

The second objection is cost, and it is not a strong one. Third-party backup for a productivity tenant is typically a small fraction of the licensing cost per user, and it is the difference between a bad afternoon and a lost year of records.

The honest framing

Cloud productivity platforms are more secure and more reliable than what most organizations ran before. That is genuinely true and we recommend them without reservation.

The risk did not disappear; it changed shape. It moved from patching servers to configuring policy, from perimeter monitoring to identity monitoring, and from tape rotation to a backup decision that the platform will not make for you. Those are easier problems than the ones they replaced. They are only easier if somebody is assigned to them.