Is Azure OpenAI HIPAA Compliant? What the BAA Does and Doesn't Cover

By Clayton Severson, Principal Consultant · Published July 8, 2026

Yes — Azure OpenAI is a HIPAA-eligible service covered by Microsoft's Business Associate Agreement, so you can legally process PHI with it. But eligible is not the same as compliant. The BAA is the legal floor; your configuration, access controls, and data flows decide the rest. Here is exactly what the BAA covers, what it doesn't, and where compliance quietly breaks.

I run Azure OpenAI on live protected health information in production — inside a revenue-cycle command center I built for a medical-billing operation — so this is not a survey of the documentation. It is what the line between "eligible" and "compliant" looks like once real claim data is flowing through the model. I'll come back to that build at the end, because it makes the abstract concrete.

Is Azure OpenAI HIPAA compliant?

It is HIPAA-eligible, which is not the same claim. Microsoft places Azure OpenAI in scope for its HIPAA Business Associate Agreement, and — unlike the consumer ChatGPT product — the service is hosted by Microsoft inside your own Azure resource, your prompts and completions are not used to train models or shared with OpenAI, and your data stays in your tenant. That gets you a service you are permitted to send PHI to. Whether the resulting deployment is compliant depends entirely on how you wire it up. (For the broader question of using any LLM with PHI, see can you use ChatGPT with PHI?)

How do you get the Microsoft BAA for Azure OpenAI?

For most organizations, you already have it. Microsoft's HIPAA BAA is delivered by default through the Microsoft Products and Services Data Protection Addendum (the DPA) for customers on eligible volume-licensing agreements — an Enterprise Agreement, a Microsoft Customer Agreement, or a Cloud Solution Provider agreement. You do not sign a separate BAA for each service, and you do not negotiate a bespoke one to turn on Azure OpenAI. Two things are still worth doing before any PHI moves: confirm your agreement actually carries the BAA (a pure consumer or trial arrangement may not), and confirm the specific Azure OpenAI feature you intend to use is inside the HIPAA-eligible scope rather than a preview capability that isn't.

What does the BAA cover — and what doesn't it?

The BAA covers Microsoft's obligations for the PHI the service processes. It does not reach into your deployment and configure it for you. Everything on the right side of this table is yours, and it is where audits actually find problems.

Covered by the Microsoft BAA (Microsoft's obligation)	Your responsibility (outside the BAA)
Safeguarding the PHI Azure OpenAI processes on your behalf, per the Security Rule	Identity and access control — Entra ID, role-based access, MFA, Conditional Access
Encryption of data in transit and at rest within the service	Audit logging of who accessed which PHI and when — append-only, reviewable
Keeping the service in HIPAA-eligible scope (generally available features)	Network isolation — private endpoints, disabling public network access
Not using your prompts or completions to train models; not sharing them with OpenAI	Minimum-necessary data flows — sending only the PHI the task needs
Abuse-monitoring review performed by Microsoft personnel as your business associate	Keeping PHI out of your own diagnostic logs, caches, and telemetry
Microsoft's breach-notification obligations to you as the covered entity or business associate	BAA coverage for every other service in the pipeline (search, storage, orchestration)

This is the shared-responsibility model applied to AI. Microsoft secures the service; you secure the deployment. The BAA is the contract that makes the first half enforceable — it does nothing about the second half, and the second half is where compliance is won or lost.

Which settings silently break compliance?

These are the ones that pass a casual review because the BAA is signed and the demo works, then surface in an audit or a breach investigation.

• Abuse monitoring, misunderstood in both directions. By default, Azure OpenAI may retain prompts and completions for up to 30 days and let authorized Microsoft staff review flagged content. That is not a HIPAA violation — Microsoft performs it as your business associate under the BAA. But it is a minimum-necessary consideration, which is why many healthcare deployments apply for Microsoft's Limited Access Modified Abuse Monitoring to remove human review and set that retention to zero. Get this right on the facts: don't panic that the default is illegal, and don't assume the default is what you want. (Terms change — verify current Microsoft policy.)
• Public network exposure. A resource reachable on its public endpoint with only key authentication is a much larger attack surface than one behind a private endpoint with public access disabled and identity-based auth. The BAA says nothing about your network design.
• PHI leaking into your own logs. The most common self-inflicted breach: prompt and response content captured into application logs, request tracing, or a caching layer that then ships somewhere out of scope. The model call can be perfectly compliant while your observability stack quietly becomes an unprotected copy of PHI.
• Out-of-scope services in the chain. Real deployments add retrieval search, vector indexes, blob storage, and databases. Each one that touches PHI has to be individually HIPAA-eligible and configured for it. A compliant model endpoint feeding an out-of-scope index is still a gap.
• Preview features. The BAA's covered-services scope is about generally available services. A shiny preview capability may not be in scope yet — using it with PHI takes you outside the agreement without any warning in the portal.
• Trusting the model with identifiers it never needed. Sending the full record "just in case" violates minimum-necessary and widens exposure. It also invites the model to echo an identifier into an output that lands somewhere it shouldn't.

Does Azure OpenAI train on your data or send it to OpenAI?

No, and this is worth stating plainly because it is the fear that stops many healthcare teams before they start. Azure OpenAI runs the models inside Microsoft's Azure platform, in the resource you provision in your own tenant. Microsoft does not use your prompts or completions to train or improve its models, does not share them with OpenAI, and does not add them to any shared pool. Your inputs and outputs stay within your Azure environment. That is the architectural reason Azure OpenAI, rather than a consumer chatbot, is the default enterprise path for regulated healthcare data — the isolation is the product.

What this looks like in production (from the trenches)

Here is the build I mentioned. In a revenue-cycle command center for a medical-billing operation, two features run on Azure OpenAI, both touching PHI. The first summarizes an insurance claim's accounts-receivable status and recommends the next action, so a specialist can grasp a stalled claim in seconds instead of reading a long history. The second is the one that surprised me with how much it mattered: it takes the terse, shorthand notes specialists type while working a claim — abbreviations, half-sentences, non-native English, "pt resp bal to sec, f/u COB, lvm" — and rewrites them into clean, standardized activity-log entries that anyone can read later.

"Eligible" got us the right to build it. Everything that made it compliant was configuration, and none of it came from the BAA:

• The model runs in the client's own Azure tenant, so claim data sent to it never leaves the BAA-covered boundary — no third-party AI vendor, no shared endpoint.
• Inputs are minimized to operational fields — status, payer, balances, denial and remittance codes, activity history. The summarizer never receives patient name, account number, or subscriber number, because an AR summary does not need them. Data minimization is the right default even inside the boundary.
• The note-cleanup call is treated as PHI and audited. A specialist's free-typed note can contain patient detail, so every cleanup is written to an append-only access log, keyed to the claim, before the model ever runs.
• Nothing caches the prompt content, the endpoint is authentication-gated, and inputs are length- and format-validated before they leave the app.
• The prompt itself is a guardrail. It instructs the model to preserve every code verbatim — CARC/RARC denial codes, CPT and diagnosis codes, reference numbers — to expand only safe everyday abbreviations, to invent nothing, and to never add a patient identifier. On regulated data, "don't hallucinate and don't leak" is not a soft preference; it is a written instruction backed by evaluation.

Not one of those safeguards is something Microsoft's signature provided. The BAA made the model a legal place to send claim data. The tenant boundary, the minimization, the audit trail, the no-cache posture, and the guardrail prompt are what made the deployment compliant. That is the whole lesson of this article in one system: eligible is bought, compliant is built.

Frequently asked questions