Is Microsoft 365 HIPAA Compliant Under the Proposed Security Rule? The BAA, Shared Responsibility and the 72-Hour Gap

The short answer is the one every compliance officer already knows: Microsoft 365 can be used in a HIPAA-compliant way, Microsoft will sign a Business Associate Agreement (BAA) for its enterprise services, and thousands of covered entities run Exchange Online, SharePoint, OneDrive and Teams with protected health information in them. The longer answer is that "can be used compliantly" and "is compliant" are different claims, and the gap between them is about to widen. The proposed HIPAA Security Rule update turns contingency planning into measurable obligations: exact backup copies no more than 48 hours old, written procedures to restore critical systems within 72 hours, a criticality analysis, annual tests with evidence, and 24-hour notice from a business associate that activates its contingency plan. This post walks through where each of those lands under Microsoft 365's shared responsibility model, and what a covered entity can and cannot evidence for the systems it rents.

What Microsoft actually commits to

Microsoft offers HIPAA Business Associate Agreement terms as part of its standard enterprise contract documents for Microsoft 365 and Azure. The BAA covers the in-scope services, including Exchange Online, SharePoint Online, OneDrive for Business and Teams, and Microsoft publishes HITRUST, SOC 2 and ISO 27001 attestations for the underlying platform. On the service side, Microsoft commits to a financially backed 99.9% uptime service level and runs its own datacenter redundancy, geo-replication and recovery processes for the platform.

All of that is real, and none of it is the problem. The problem is what the BAA and the attestations are about. They cover Microsoft's obligations as a business associate: securing the infrastructure, keeping the service running, reporting its own breaches. They do not cover the covered entity's obligations as the owner of the data, and under the shared responsibility model those are the obligations the Security Rule mostly cares about.

Shared responsibility, in the Security Rule's terms

Microsoft's shared responsibility model is explicit: Microsoft is responsible for the security of the cloud platform, and the customer is responsible for its data, its identities, its devices and its configuration. Translated into the Security Rule's structure, that split looks like this.

The last three rows are the ones the proposed rule changes most, and they are the rows where the customer has the least ability to act.

Retention is not backup, and both sides of the industry say so

Microsoft 365 ships with a set of data protection features that are genuinely useful: file versioning in SharePoint and OneDrive, a two-stage recycle bin that keeps deleted files for 93 days, recoverable items in Exchange mailboxes, soft-deleted mailboxes held for 30 days, litigation hold and retention policies in Purview. Microsoft also sells Microsoft 365 Backup, a pay-per-gigabyte add-on introduced in 2024 that keeps restore points for Exchange, OneDrive and SharePoint and restores them inside the same tenant.

What these features share is that they live in the same tenant, on the same platform, under the same credentials and the same vendor as the data they protect. That is fine for a deleted file. It is not what the Security Rule's data backup plan has traditionally meant, and it is not what the proposed 48-hour currency and 72-hour restoration clauses assume. Three things are missing:

• Independence. A ransomware operator with Global Administrator rights, or an administrator error, or a Microsoft-side incident, affects the protection and the production data together. Microsoft's own services terms recommend that customers keep their own backups, and the entire third-party Microsoft 365 backup market exists because retention features are not a backup.
• A restore target you control. Every restore path offered by Microsoft restores into Microsoft 365. There is no supported way to bring a tenant up on alternative infrastructure. If the restoration you need is "our email and files are available to clinicians again", and the cause is on Microsoft's side, your recovery time objective is Microsoft's recovery time objective, whatever your plan says.
• Evidence from a test. The proposed rule requires contingency plans to be tested at least every 12 months. You can test restoring a mailbox or a document library. You cannot test restoring Exchange Online.

The 72-hour gap, concretely

Consider a 600-clinician regional health system we will call Harbor Point Health. Its criticality analysis, which the proposal would make mandatory, puts four systems at the top: the EHR, the identity provider, email, and the shared document store that holds care-coordination files, policies and referral paperwork. The last two are Microsoft 365.

Under the proposed rule, Harbor Point needs written procedures to restore each of those within 72 hours of a loss, a backup copy of the ePHI in them no more than 48 hours old, and an annual test with evidence. For the EHR, hosted on infrastructure Harbor Point controls, that is a solvable engineering problem: replicated storage, a documented runbook, a rehearsal every year with the stopwatch running. Our post on disaster recovery architecture for the 72-hour objective shows how.

For email and files on Microsoft 365, Harbor Point's options are:

1. Rely on Microsoft's own contingency plan and document that reliance. This is permissible, but it means Harbor Point's 72-hour objective for two critical systems rests on a business associate whose restoration timeline Harbor Point has never seen, cannot test, and would be told about, under the proposed rule, within 24 hours of activation. The compliance officer's evidence file contains a trust-portal PDF.
2. Add a third-party backup product that copies mailboxes and document libraries out of the tenant on a schedule that beats 48 hours. This fixes the independence problem and the currency problem for the data. It does not fix the restore target: the restore still goes back into Microsoft 365, so a platform-side loss still has Microsoft's timeline. It also adds another business associate to verify annually.
3. Move the critical collaboration systems onto infrastructure where the full restoration can be rehearsed. This is the option a growing number of regulated organisations are choosing for email, files and messaging, and it is the subject of our guide to a HIPAA-compliant Microsoft 365 replacement built on Nextcloud Hub Enterprise.

None of these is wrong. The point is that the first two leave a documented gap between what the rule asks the covered entity to do and what the covered entity can actually do, and an investigator reading the contingency plan will see it.

The other proposed controls, and how Microsoft 365 fares

To be fair to the platform, several of the proposed changes are easier on Microsoft 365 than on a self-managed stack, provided the tenant is configured properly.

• MFA everywhere. Conditional Access can enforce MFA on every account; the work is turning off legacy authentication and dealing with shared mailboxes, service accounts and devices that cannot do it. The proposal's annual review of MFA exceptions applies to those.
• Encryption at rest and in transit. Provided by the service. Customer-managed keys are available at the higher licence tiers for entities whose risk analysis calls for them.
• Vulnerability scanning and penetration testing. Microsoft scans and tests its platform; the covered entity still has to scan and test everything it runs, including the devices that sync the tenant.
• Audit logs. Available, but default retention is 90 or 180 days depending on licence, so the six-year documentation rule means exporting them somewhere else, which is itself a system in the asset inventory.
• Business associate verification. Microsoft's published attestations will be what most entities file. They are platform-wide and not specific to any tenant's configuration, which is exactly the limitation the proposal's subject-matter-expert wording seems designed to probe.

Across the board the pattern is the same: the platform supplies capability, the entity supplies configuration, and the entity carries the evidence burden. The contingency rows are the ones where even perfect configuration cannot close the gap.

What a compliance officer should write down now

Whether or not the proposed rule is finalised in its current form, a covered entity using Microsoft 365 for ePHI should have the following in its file before the next OCR letter, not after.

1. The signed Microsoft BAA, with the list of in-scope services, and a note of every Microsoft 365 feature in use that is not in scope.
2. A criticality ranking that states plainly which Microsoft 365 workloads are critical systems, and for each one the restoration objective the entity is relying on and where that figure comes from.
3. The backup design for those workloads: native retention only, a third-party copy, or a replacement platform; its currency in hours; and the last dated restore test with its measured time.
4. The procedure by which Microsoft would notify the entity of a contingency plan activation, and who receives it.
5. The annual written verification of Microsoft's technical safeguards that the entity intends to rely on, and an honest sentence about its scope.

If step three ends with "native retention only" and step two ends with "we do not know", the gap is documented and the remedy is a project. Our contingency plan checklist covers the rest of the evidence file, and the Security Rule update overview puts the contingency clauses in context with the other proposed changes.

Frequently Asked Questions

Does Microsoft sign a HIPAA Business Associate Agreement for Microsoft 365?

Yes. Microsoft offers HIPAA Business Associate Agreement terms for in-scope enterprise services, including Exchange Online, SharePoint Online, OneDrive for Business and Teams, as part of its standard contract documents. The BAA covers Microsoft's obligations as a business associate; it does not make the customer's tenant configuration or contingency plan compliant.

Is Microsoft 365 retention a HIPAA-compliant backup?

Versioning, recycle bins and retention policies protect against routine deletion, but they live in the same tenant and platform as the production data and restore only into Microsoft 365. The current rule requires a data backup plan with retrievable exact copies, and the proposed rule adds a 48-hour currency limit and a 72-hour restoration objective. Most compliance programmes treat native retention as insufficient on its own and add an independent backup.

Does Microsoft 365 Backup solve the 72-hour restoration requirement?

It addresses backup currency and restore points for Exchange, OneDrive and SharePoint, and restores them within the same tenant. It does not give the covered entity a restoration path onto infrastructure it controls, so for a platform-side loss the restoration timeline is still Microsoft's. Whether that is acceptable depends on the entity's criticality analysis and risk tolerance, and it should be stated explicitly in the contingency plan.

Can a covered entity test its contingency plan against Microsoft 365?

It can test the parts it controls, such as restoring a mailbox or a document library from retention or from a third-party backup, and it should document those tests. It cannot test the restoration of the service itself, so the annual test the proposed rule requires will necessarily rely on Microsoft's own testing for that part.

What is the alternative for email and file collaboration?

A single-tenant collaboration platform such as Nextcloud Hub Enterprise, hosted on infrastructure where the entity or its managed provider can rehearse a full restoration. MassiveGRID runs this as Sovereign Workspaces, signs a Business Associate Agreement, and documents the backup currency and restoration test results for each deployment.