Microsoft now offers Microsoft 365 Backup as a native capability, which has prompted a reasonable question from clients: does this mean the third-party backup line item can go away?
It does not, and the reason has nothing to do with the quality of Microsoft's product.
What it does well
Microsoft 365 Backup provides fast backup and restore for Exchange Online, OneDrive, and SharePoint, with point-in-time recovery inside the tenant. Because it runs on Microsoft's own infrastructure, restore speeds are better than what most third-party tools achieve, and there's no data egress to wait on.
For recovering from ordinary problems, a deleted site, a mailbox someone emptied, a folder that got overwritten, it works well and it reduces operational friction.
The limitation is structural
Microsoft 365 Backup operates inside the same control plane as production. The backup data lives in the same ecosystem, under the same identity model, governed by the same administrative accounts.
That is the entire issue. If the thing that goes wrong is the tenant itself, the backup is inside the blast radius.
The scenarios that matter here are the ones where the environment turns against you. A compromised global administrator account executing large-scale deletion. A retention policy misconfigured badly enough to purge data permanently. Ransomware encrypting files that then synchronize to cloud storage. Someone with sufficient privileges deleting data deliberately.
In each of those, recovery depends on holding a copy of the data that is not governed by the controls that just failed.
This is the shared responsibility model, and it hasn't changed
Microsoft is responsible for the availability and resilience of the service. You are responsible for the data you put in it.
That division is well documented and widely misunderstood, and native backup makes the misunderstanding easier to fall into. A capability that lives in the admin center feels like the platform taking responsibility for your data. It isn't. It's the platform giving you a better tool for exercising a responsibility that remains yours.
What SOC 2 actually asks for
Backup obligations under SOC 2 live mainly in the Availability criteria, which is worth understanding precisely because Availability is optional. It's included when your service commitments warrant it, so the first question is whether your report covers it at all.
When it does, two criteria apply directly. A1.2 covers the design, implementation, operation, and monitoring of data backup processes and recovery infrastructure. That is the criterion requiring that backups exist, that the backup infrastructure is maintained, and that someone is watching it. A1.3 requires that you test recovery plan procedures supporting system recovery, and it is one of the few criteria that explicitly requires testing something rather than documenting it.
Two Common Criteria matter alongside those. The CC6 series governs logical access, including the ability to alter or destroy data outside defined processes, which is where the shared identity boundary between production and backup becomes a design question. CC7.5 addresses recovery from identified security incidents, and it assumes the recovery mechanism survived the incident.
If you have seen backup mapped to CC7.3, that is worth correcting. CC7.3 concerns evaluating security events to determine whether they resulted in a failure. Recovery sits at CC7.5. The distinction matters when an auditor is reading your control matrix, and getting it wrong is a small credibility cost you don't need to pay.
Where Confidentiality is in scope, C1.1 also applies, since a backup contains everything sensitive that production contains. An exfiltrated backup snapshot is a full breach.
What we configure
Our standard approach is to keep backups outside the primary production environment, with retention set according to the client's business, contractual, regulatory, and recovery requirements rather than a default we apply everywhere.
Where the backup platform supports it, backup data is immutable or otherwise protected against modification and premature deletion for the length of the retention period. Administrative access to the backup environment is separated from production administrative access, so that compromise of the tenant does not extend to the copies of its data.
Recovery cannot depend on the primary tenant being available. We design so that authorized administrators have an independent path to access, export, or restore protected data when the production tenant is unavailable or compromised. This is the requirement that native backup structurally cannot meet, and it's the one that decides whether a backup strategy is a control or a convenience.
The specifics, retention period, immutability configuration, recovery method, and testing frequency, get established during onboarding based on the systems in scope, the applicable compliance requirements, and the client's RTO and RPO objectives. Those objectives are also what an auditor will measure the recovery test against, so they need to be written down before anyone needs them.
Restore testing is the part that gets skipped
For clients on our SOC 2 maintenance, testing backups and restore procedures is an obligation rather than a good intention. It's scheduled, it gets performed, and it produces a dated record.
That record is the evidence. A backup policy document proves you intended to be able to recover. A dated test result showing data restored, verified, and within your stated recovery objectives proves the procedure operates. Auditors know the difference, and A1.3 exists specifically to force it.
The uncomfortable version of this is that untested backups fail at roughly the rate you'd expect from any process nobody has ever run end to end. The first real restore attempt is a bad time to discover which systems were never actually in scope.
Where native backup fits
Microsoft 365 Backup is worth using. It shortens recovery time for the common cases, it reduces the operational load of routine restores, and it improves the baseline inside the platform.
It belongs as a layer in a data protection strategy rather than the foundation of one. Microsoft guarantees the service will be available. Guaranteeing that your data is recoverable after your own tenant has been compromised is a different problem, and it stays on your side of the line.
If you're running Microsoft 365 and your backup arrangement has never been tested end to end, that's worth finding out about on a scheduled Tuesday rather than during an incident.