On Azure, identity is the perimeter around patient data

Microsoft makes its HIPAA Business Associate Agreement available through its Product Terms, which point to the Products and Services Data Protection Addendum (DPA). The licensing agreement you buy Azure under incorporates both, so a covered entity or business associate customer has the BAA terms without a separate contract. Microsoft also says it cannot sign a customer's own BAA.

1. 1
   Your licensing agreementThe contract you bought Azure under. It pulls in the documents below.
2. 2
   Product TermsMicrosoft's terms for each product, including which services are covered.
3. 3
   Data Protection AddendumMicrosoft's data commitments, which carry the HIPAA BAA.
4. 4
   HIPAA BAAPermitted uses, safeguards and breach reporting, for in-scope services.

Keep a dated copy of each document as it stood when you relied on it. When a customer or reviewer asks for your cloud BAA, this is the record you show.

Microsoft publishes which cloud services fall within its HIPAA BAA coverage, through its list of cloud services in audit scope. The list differs between Azure and Azure Government and is updated over time. Before a new service handles ePHI, check it there and record the date.

Your own customers do not sign anything with Microsoft. If you sell a healthcare SaaS product on Azure, the clinics sign your BAA, and Microsoft sits beneath you as your subcontractor.

The same tenant that signs staff into email often controls who can administer subscriptions that hold ePHI. That is convenient and dangerous: one weak account reaches both. Design identity before networks.

1. ID.1
   Separate admin identitiesPeople who manage ePHI subscriptions use admin-only accounts, not their daily email identity.
2. ID.2
   Conditional sign-inRequire MFA and a managed device for any access to ePHI subscriptions, for example through Conditional Access policies.
3. ID.3
   Just-in-time rolesNo standing owner rights. Elevation is requested, approved and time-boxed, for example with Privileged Identity Management.
4. ID.4
   Workload identitiesApplications use managed identities instead of stored secrets or connection strings.
5. ID.5
   Guest reviewExternal guests in the tenant are listed and removed on a schedule.

Azure groups subscriptions under management groups. Policies assigned high up apply to everything below. Put ePHI subscriptions under their own management group so stricter rules reach only them.

1. 1Azure PolicyDeny or audit settings such as public network access, allowed regions and missing diagnostic logs. Microsoft publishes a built-in HIPAA/HITRUST initiative that maps policies to controls.
2. 2Defender for CloudReports posture findings and a regulatory compliance view across subscriptions.
3. 3Diagnostic settingsSend resource and activity logs to a workspace that application admins cannot alter.
4. 4Key VaultHolds customer-managed keys, with separate roles for key admins and key users.

In a Microsoft-stack company, ePHI rarely stays in the product. A clinician emails a note to support. A screenshot lands in a chat channel. A spreadsheet of pilot users sits in a shared folder. Each one is ePHI held in Microsoft 365, under the same tenant.

• Confirm which Microsoft 365 services the BAA covers for your licence, the same way you did for Azure.
• Set data-loss-prevention rules for patient identifiers in email, chat and file sharing.
• Restrict external sharing of folders that may hold ePHI, and review guest access.
• Set retention so support mail with patient details is not kept forever, or deleted too soon.

Illustrative only. A company sells software that drafts visit notes for outpatient clinics. The app runs on Azure; staff use Microsoft 365; engineers sign in with the same Entra tenant. A large clinic group asks for evidence before signing.

1. Show the BAA chain: the licensing agreement, the dated Product Terms and DPA, and the covered-services check for each service in use.
2. Show who holds owner rights on the ePHI subscriptions today, and how that right is granted and removed.
3. Show the policies assigned to the ePHI management group, and what happens when someone breaks one.
4. Show where notes, audio and drafts are stored, which keys protect them, and who can use those keys.
5. Show how patient data in support email and chat is detected, limited and retained.
6. Show the risk analysis that ties all of this together.

Sources: 45 CFR 160.103 and 45 CFR Part 164, Subparts C and E, in particular 164.308(a)(1), 164.308(a)(4), 164.312(a) and 164.504(e); HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing; Microsoft's public HIPAA offering page for Azure and its linked Product Terms and Data Protection Addendum.