Azure OpenAI HIPAA BAA: what's covered

By Mat Steinlin, Head of Information Security

Last updated: July 2026

If your organization runs on Azure and you're evaluating OpenAI models for a healthcare application, Azure OpenAI Service is almost certainly the faster compliance path. The BAA comes through your existing Microsoft enterprise agreement rather than a separate OpenAI sales negotiation. For teams already contracted with Azure, this can compress weeks of back-and-forth into a configuration step. In practitioner communities, "BAA signed OpenAI API via Azure" is the specific phrase used to describe this compliant routing path.

Azure OpenAI and the direct OpenAI API are different products with different legal entities. A BAA with Microsoft does not give you a BAA with OpenAI. If your application uses both surfaces, you need both covered.

What Azure OpenAI is and how it differs from OpenAI direct

Azure OpenAI Service is Microsoft's hosted version of OpenAI models, available through Azure's cloud platform. The underlying models are the same (GPT-4o, o3, and other OpenAI models) but the infrastructure, data handling, and compliance path are entirely different.

For most healthcare teams already running infrastructure on Azure, the compliance posture is better through Azure OpenAI: faster BAA, better data residency options, and Microsoft's HIPAA compliance infrastructure underneath.

How the Azure HIPAA BAA covers Azure OpenAI

Azure OpenAI Service is a HIPAA-eligible service under Microsoft's Online Services Data Protection Addendum (DPA), which functions as Microsoft's BAA for covered entities.

Azure's BAA process differs from Anthropic's or OpenAI's. There is no separate contract to sign. Microsoft's HIPAA BAA is incorporated into the standard Microsoft Product Terms, which are included in every Azure licensing agreement. Execution of a volume licensing agreement with Microsoft automatically includes execution of the HIPAA Business Associate Agreement.

Confirming Azure OpenAI is in scope: Azure OpenAI is listed as a HIPAA-eligible Azure service. Verify that it remains in scope for your specific agreement by checking Microsoft's compliance audit scope documentation, which links to the current list of services covered under the HIPAA BAA.

What Microsoft's BAA covers for Azure OpenAI

Microsoft's DPA and HIPAA BAA establish:

• Microsoft as a business associate for Azure services used to process PHI

• Prohibition on using customer data for model training or service improvement without consent

• Data processing within your configured Azure regions

• Microsoft's security and safeguard obligations for PHI handled through Azure infrastructure

• Breach notification requirements per 45 CFR § 164.410

Microsoft's data handling terms for Azure OpenAI specify that customer data is not used to train OpenAI foundation models, and that data is processed only within the customer's selected Azure geography.

What the Azure BAA requires of you

Unlike Anthropic or OpenAI, Microsoft does not publish a separate customer-facing implementation guide as a BAA condition. The customer obligation framework for Azure is the shared responsibility model: Microsoft explicitly states that having a BAA does not ensure your organization's HIPAA compliance, and that you are "wholly responsible for ensuring your own compliance with all applicable laws and regulations."

In practice, the key customer obligations under the Azure BAA are:

Use only HIPAA-eligible services for PHI. You must not process, store, or transmit PHI using Azure services that are not on Microsoft's HIPAA-eligible services list. Verify new services before enabling them for PHI workloads.

Apply required security configurations. For some HIPAA-eligible Azure services, specific security configurations are required as a condition of eligibility. Check the per-service notes in the HIPAA eligible services reference.

Encryption. PHI stored or transmitted using Azure services must be encrypted in accordance with HHS guidance on rendering PHI unusable, unreadable, or indecipherable.

Configuration and compliance are yours. Azure Policy can help you assess compliance, but Microsoft states it "doesn't inspect, approve, or monitor your applications deployed on Azure." The application-layer controls (audit logging, access controls, retention policies, key management) are entirely your responsibility to implement and maintain.

The Azure vs. direct OpenAI decision

The decision usually comes down to where your infrastructure already lives and what your model requirements are.

Azure OpenAI makes sense when:

• You're already running on Azure with an existing enterprise agreement

• Data residency within specific Azure regions is a requirement

• You want one Microsoft relationship covering your AI infrastructure and your cloud infrastructure

• You're comfortable with a slight lag on the newest model releases

Direct OpenAI makes sense when:

• You're not on Azure and don't want to add it to your stack

• You need access to the newest OpenAI models immediately on release

• You're already in an OpenAI Enterprise agreement for ChatGPT Enterprise and want to extend it to API usage

Using Azure OpenAI does not give you a BAA with OpenAI LLC. If your team uses Azure OpenAI in production and also uses the direct OpenAI API for testing, tooling, or other workflows, those are different surfaces with different coverage. The Azure BAA covers Azure OpenAI. The OpenAI BAA (if you have one) covers direct OpenAI products.

Compliance configuration for Azure OpenAI workloads

Having a BAA in place is the starting point. Azure OpenAI's HIPAA-compliant deployment also benefits from:

Private endpoints. Azure OpenAI can be accessed through Azure Private Link, keeping traffic within your virtual network and off the public internet. Recommended for any PHI-processing workload.

Managed identity. Use Azure Managed Identity for authentication rather than API keys where possible. Eliminates credential management overhead and reduces key exposure risk.

Diagnostic logging. Azure OpenAI supports diagnostic logging via Azure Foundry's diagnostic settings, with logs forwarded to Azure Storage or Log Analytics. Configure log forwarding for Audit Logs, Request and Response Logs, and Azure OpenAI Request Usage. These logs contain request metadata and require appropriate access controls and retention policies. They are not a complete substitute for application-level audit logging of PHI interactions.

Content filtering. Azure OpenAI's content filtering is on by default. For healthcare workloads, review the default configuration. Some clinical content may require adjusted filtering settings.

Preview features. Azure OpenAI features in preview may not support customer-managed keys or all data storage conditions required for HIPAA compliance. Verify GA status before routing PHI through any preview capability.

Non-obvious compliance risks

Two areas that catch teams off guard, both documented in Microsoft's Azure OpenAI data privacy guidance:

Abuse monitoring and human review. Azure OpenAI includes abuse monitoring that can involve human review of customer prompts and completions when abuse indicators are detected. This is opt-out, not opt-in. Customers can apply for "modified abuse monitoring" to disable it, but it is not off by default. For PHI workloads, this is a material compliance consideration. If your organization routes patient data through Azure OpenAI without requesting the modified abuse monitoring configuration, that data may be subject to human review by Microsoft personnel. Applying for modified abuse monitoring should be on your pre-launch compliance checklist for any PHI-processing workload.

Global and DataZone deployment types. Azure OpenAI offers multiple deployment types: Standard, Global, and DataZone. When using Global or DataZone deployments, PHI may be processed in regions outside your designated geography. Standard deployments stay within your selected Azure region. Teams should confirm which deployment type is in use before routing PHI, and should use Standard deployments when data residency within a specific geography is required.

What Azure's BAA doesn't cover

The Azure path makes the BAA easier to get. It doesn't make the compliance infrastructure easier to build. Audit logging, encrypted log retention, key management, and access controls are still your responsibility, regardless of how smoothly the agreement came together.

See What an AI BAA actually covers for the full breakdown.

What you still need to build

The compliance infrastructure layer (audit logging, encrypted storage, six-year retention, key management, access controls) is your responsibility regardless of which vendor's BAA you hold. For teams running on Azure who want to avoid building that layer themselves, Aptible LLM Gateway provides it as a managed compliance layer, with one Aptible BAA covering all supported models including Azure OpenAI.

FAQs

Is Azure OpenAI HIPAA compliant?

Azure OpenAI Service is a HIPAA-eligible service under Microsoft's Online Services Data Protection Addendum. For organizations with an existing Azure enterprise agreement, BAA coverage is included automatically via the Microsoft Product Terms; no separate contract required.

Does my Azure BAA cover Azure OpenAI?

Yes, for customers whose licensing agreement includes the Microsoft Product Terms. Azure OpenAI is a HIPAA-eligible Azure service. Verify that Azure OpenAI is listed in the current eligible services scope.

What's the difference between Azure OpenAI and OpenAI's API for HIPAA purposes?

Different legal entities, different BAA processes, different data handling commitments. Azure OpenAI is a Microsoft product covered under Microsoft's BAA. The direct OpenAI API is an OpenAI product requiring a separate OpenAI BAA. Using one does not give you coverage for the other.

Does Microsoft train on my data when using Azure OpenAI?

No. Microsoft's data processing terms for Azure OpenAI explicitly prohibit using customer data to train foundation models, and prompts and completions are not used to train, retrain, or improve the base models. Data is processed within your configured Azure region.

Note that abuse monitoring is a separate question from model training. Azure OpenAI's default abuse monitoring can involve human review of prompts and completions when abuse is detected. This does not affect model training, but it does mean Microsoft personnel can access that data under certain conditions. PHI workloads should apply for modified abuse monitoring to disable this.

How do I enable HIPAA-compliant Azure OpenAI?

For most customers, BAA coverage is already in place through the Microsoft Product Terms included in your licensing agreement. Confirm Azure OpenAI is in your eligible services scope, then configure private endpoints, managed identity, and diagnostic logging per Microsoft's guidance.

What's next

For teams choosing between Azure and AWS for AI model access, see AWS Bedrock for the comparable AWS BAA path.

If your team is using both Azure OpenAI and the direct OpenAI API, see OpenAI / ChatGPT for the direct BAA path and the key differences.

For managing BAAs across multiple vendors, see Managing BAAs across multiple AI vendors.

__

Microsoft's BAA covers Azure's infrastructure. The audit logging, encrypted log retention, and access controls that HIPAA requires on top of it are still yours to implement. For teams already running on Azure who want those handled as a managed service, Aptible LLM Gateway provides the compliance layer with one Aptible BAA covering Azure OpenAI alongside any other models in your stack. Talk to an engineer to see if it fits.