Is Microsoft Azure HIPAA Compliant? Requirements and Setup

Is Azure HIPAA Compliant? The Short Answer

Yes, with three conditions:

1. The BAA applies to you. Microsoft includes its HIPAA Business Associate Agreement in its standard terms for customers who are covered entities or business associates. There’s no separate contract to sign.
2. In-scope services only. The BAA covers only the Azure services Microsoft lists as in scope.
3. Your configuration. The safeguards HIPAA requires are set up and run by you.

Miss any one of the three and the environment isn’t compliant, however secure Microsoft’s own infrastructure is.

Introduction

Azure is a natural home for healthcare apps, especially for organizations already running Microsoft 365 and Microsoft Entra ID. But as Microsoft itself puts it, using Azure or having a BAA doesn’t make your solution compliant. Microsoft doesn’t inspect or monitor your applications.

This guide covers the Azure side: how the BAA works, which services it covers, what replaced the Azure HIPAA Blueprint, and how to set up each safeguard. For the requirements that apply to any host, see what HIPAA-compliant hosting requires.

The Microsoft BAA

Microsoft’s HIPAA Business Associate Agreement is incorporated through your applicable Microsoft agreement, the Microsoft Product Terms and its Data Protection Addendum, and is available by default to customers who are covered entities or business associates. No separate BAA signature is required. It covers only in-scope services (Microsoft: HIPAA on Azure).

Under the BAA, Microsoft enables HIPAA’s safeguards within its in-scope services and meets its own obligations as a business associate. It doesn’t make your deployment compliant: Microsoft states that customers remain wholly responsible for their own compliance. For what a BAA does and doesn’t do, see What Is a Business Associate Agreement (BAA)?

There is also no HIPAA certification for Azure. Microsoft notes that HHS has no certification program for cloud providers, and instead maps HIPAA’s requirements to frameworks Azure is audited against, including NIST SP 800-53 and ISO/IEC 27001.

Azure Services to Check Before Handling ePHI

Microsoft lists the services covered by its HIPAA BAA in Appendices A and B of its Azure Compliance Offerings document on the Service Trust Portal (Microsoft: cloud services in audit scope). The list changes as services launch and mature, so check it for every service that will handle ePHI. The services below are examples that healthcare communication apps commonly use; confirm each one’s scope before relying on it:

• Azure Virtual Machines: you manage the operating system, patching, and everything you install.
• Azure Kubernetes Service: Azure runs the control plane; you’re responsible for your workloads and node configuration.
• Azure SQL Database and Azure Cosmos DB: confirm encryption, network access, and backup settings for databases holding ePHI.
• Azure Blob Storage: keep containers private and log access to data holding ePHI.
• Azure Functions and App Service: application logs and telemetry can capture request data, so keep PHI out of them.
• Azure OpenAI: confirm the in-scope status for the specific features you use before sending ePHI.
• Azure Notification Hubs: mobile push messages leave Azure for Apple and Google, so keep PHI out of the message text.

Is Azure OpenAI HIPAA compliant?

Azure OpenAI can be used with ePHI only where Microsoft lists it and the features you use are in scope for the BAA. Check Microsoft’s current list before sending patient data. Also review the deployment type, processing location, and any storage or abuse-monitoring arrangements for prompts and responses, particularly if your contracts restrict where ePHI may be processed. Store prompts and outputs that contain PHI with the same controls as other ePHI.

What happened to the Azure HIPAA Blueprint?

Microsoft is retiring Azure Blueprints. A phased retirement began on July 31, 2026, and the service retires fully on January 31, 2027. For deploying environments, Microsoft recommends moving to Deployment Stacks or Template Specs (Microsoft: Azure Blueprints retirement).

For HIPAA specifically, two tools take over the checking role:

• Azure Policy: a built-in HIPAA HITRUST initiative maps HIPAA and HITRUST controls to policy definitions you can assign.
• Microsoft Defender for Cloud: its regulatory compliance dashboard includes a HIPAA standard for Azure resources.

Both show how your resources measure up against selected controls. Microsoft describes this as a partial view of your compliance, not proof of it.

Shared Responsibility on Azure

Microsoft secures the physical infrastructure and the services it runs. What falls to you depends on the type of service:

• Infrastructure services such as Virtual Machines: you’re responsible for the operating system, patching, network rules, applications, and data.
• Platform services such as Azure SQL Database and App Service: Microsoft runs the platform; you configure access, encryption options, networking, backups, and logging.
• In every case: your identities, permissions, data, and how your application handles PHI stay with you.

How to Set Up a HIPAA-Compliant Azure Environment

These are common configuration steps on Azure, not a complete compliance program. Which you need, and how, depends on your architecture and risk analysis, and HIPAA’s administrative safeguards, policies, and incident procedures sit alongside them. The safeguards themselves are explained in What Are HIPAA Technical Safeguards?

1. Control access

Use Microsoft Entra ID and Azure role-based access control to give each person and service only the permissions they need. Require multi-factor authentication for people, and limit standing administrator access.

2. Encrypt ePHI

Encrypt databases, storage, and backups that hold ePHI, and use TLS for data in transit. Use Azure Key Vault to manage keys and secrets, and decide whether Microsoft-managed or customer-managed keys fit your risk analysis. Encryption is addressable under HIPAA, but on Azure it’s usually the straightforward choice.

3. Log activity at two levels

Azure Monitor collects the activity log for your subscriptions and the resource logs you enable for each service. Your application also needs its own audit log, because platform logs alone may not identify which clinician or patient accessed a record through your application.

4. Backup and test restores

Back up every ePHI store with Azure Backup or the service’s own backup options. Keep copies separate from production, in another region only where your data-residency requirements allow, and test restores on a schedule.

5. Limit network exposure

Place application servers in private subnets where appropriate, and restrict traffic with network security groups. For supported managed services, use private endpoints and disable public network access where appropriate. Check each service’s networking options rather than assuming every Azure resource runs inside your virtual network.

6. Watch for threats and drift

Turn on Microsoft Defender for Cloud, and assign the HIPAA standard or the Azure Policy HIPAA HITRUST initiative to flag misconfigurations. Make sure someone acts on the findings.

7. Manage sessions

Use Entra ID session controls to limit how long administrator sessions last. Separately, build an inactivity timeout into your own application; the two are different controls.

8. Retain and dispose of data deliberately

Use lifecycle and retention settings to delete ePHI when your retention policy says it’s no longer needed. Don’t treat deleting encryption keys as a disposal shortcut: retire a key only after confirming that no backups or records still under retention depend on it.

Where PHI Lands in a Healthcare Communication App on Azure

Most Azure HIPAA guides stop at the database. In a healthcare communication app, PHI spreads into storage, logs, and services that teams don’t think of as holding patient data. The list below is illustrative, showing where these stores typically live on Azure:

• Messages and conversation history, for example, in Azure SQL Database or Cosmos DB: encrypted, with access limited to the application.
• Attachments such as photos, lab results, and insurance cards, for example, in Blob Storage: private containers, encryption, and access logging.
• Call recordings and transcripts: retention rules, so recordings aren’t kept forever by default.
• Application logs and telemetry, for example, in Azure Monitor and Application Insights: message content and patient identifiers kept out of what’s recorded.
• Push notifications, sent through Notification Hubs to Apple’s and Google’s services: notification text that says only that a new message is waiting.
• AI prompts and summaries, for example, in Azure OpenAI: confirmed as in scope and stored under the same controls as messages.
• Backups: encrypted, access-restricted, and covered by the same retention policy.

Common Mistakes on Azure

Assuming every Azure service is covered. The BAA covers in-scope services only. Every new service or feature, including AI and preview features, needs its own scope check.

Still relying on Azure Blueprints. Blueprints is being retired. Move deployments to Deployment Stacks or Template Specs, and use Azure Policy or Defender for Cloud for compliance checks.

Treating a compliance score as compliance. A HIPAA dashboard in Defender for Cloud checks selected controls that can be assessed automatically. Policies, training and many administrative safeguards sit outside it.

PHI in telemetry. Application Insights and diagnostic logs can record request data, including message content, unless you exclude it.

Relying on platform logs alone. Azure’s logs show what happened to your resources, not which user of your app opened which record. You need both.

Real patient data in development. Test environments rarely have production’s controls. Use synthetic or de-identified data.

If you’d rather not run this yourself, our guide to managed or self-hosted hosting for HIPAA apps covers when each makes sense.

QuickBlox on Azure

QuickBlox can deploy its chat, video calling and AI agents for healthcare apps in your own Azure account as an Enterprise deployment, which we install, monitor and support. The deployment runs in your account, and messages, files and call data are encrypted at rest and in transit, with role-based access control. See our HIPAA-compliant hosting options, or talk to our team about running on Azure.

Azure gives healthcare teams a BAA by default, in-scope services and strong compliance tooling. Compliance comes from how you use them. Keep ePHI inside in-scope services, set up each safeguard deliberately, replace Blueprints before it retires, and map every place patient data lands, not just the database. If you’re weighing clouds, our guide to AWS HIPAA compliance covers the same ground for AWS.