HIPAA on Azure: Security Rule safeguards in architecture

What HIPAA actually requires of an architecture

The Security Rule sets administrative, physical and technical safeguards. Physical safeguards for the data center are Microsoft’s under the shared responsibility model. Everything else is yours, and most of it is architectural.

Access control (§164.312(a)). Unique user identification and an emergency access procedure are required. Automatic logoff and encryption at rest are addressable. Addressable does not mean optional: it means implement it, or record why an equivalent measure is reasonable and appropriate. That written rationale is an artefact, and its absence is a finding.

Audit controls (§164.312(b)). You must record and examine activity in systems containing electronic PHI. Note the word examine. Enabling logs and never querying them satisfies neither the rule nor an investigator.

Integrity, authentication and transmission security (§164.312(c) to (e)). Data cannot be altered or destroyed undetectably, users and services must prove who they are, and PHI in transit must be protected.

Risk analysis (§164.308(a)(1)(ii)(A)). Required, recurring, and the single most cited failure in enforcement actions. It has to cover every location where ePHI is created, received, maintained or transmitted, which is impossible without a real inventory.

Documentation retention (§164.316). Six years from creation or last effective date. That number drives the logging and archive design, not the other way round.

Breach notification. Individuals notified without unreasonable delay and no later than sixty days, HHS notified, media notified above five hundred residents of a state. Sixty days is generous only if you detected the event on day one.

The business associate agreement. Microsoft signs a BAA covering in-scope services. A preview service, or a service outside that list, is not covered. One resource type chosen carelessly breaks the chain of assurance for the whole workload.

What we design and enforce in Azure

PHI gets its own boundary. A dedicated management group and subscription scope for PHI workloads, with policy assigned above the subscription so an owner cannot relax it. This is the decision that makes every later control cheap, and the one most estates skipped because everything started in a single subscription.

Service selection becomes a policy. An allowed resource types assignment restricted to BAA-covered services, preview features denied, and a deny on any resource missing the data classification tag. A developer cannot accidentally place PHI somewhere the agreement does not reach.

No public path to PHI. Private endpoints on Azure SQL, Storage, Key Vault and AI services, private DNS zones, public network access denied by policy, and hub-and-spoke segmentation as described on the Azure landing zone page. Transport enforced at TLS 1.2 or above.

Encryption with a key story you can explain. Platform encryption at rest as a baseline, customer-managed keys in Key Vault or Managed HSM where you need to hold and rotate the key yourself, and a documented rotation schedule. If a security questionnaire asks who can decrypt your data, the answer should be a diagram, not a paragraph.

Unique identity, no shared accounts. Microsoft Entra ID authentication on data services instead of shared database logins, Privileged Identity Management so administrative access is requested and time-bound, Conditional Access with sign-in frequency and session controls covering the automatic logoff specification, and break-glass accounts that are documented, tested and alerted on every use.

Audit controls that survive a real investigation. Diagnostic settings on every PHI-bearing resource, and specifically data-plane logging on storage and databases, which is off by default and is exactly what an investigator wants. Entra sign-in and audit logs, retention set against the six-year documentation obligation with archive beyond the interactive window.

Detection sized to the sixty-day clock. Microsoft Defender for Cloud for posture and vulnerability findings, Microsoft Sentinel rules for mass export, anomalous access to PHI stores and impossible travel, and a written notification path naming who decides that a breach occurred.

AI on clinical data, with the boundary written down. Inference inside your tenant over private networking, retrieval that respects record-level permissions rather than a flat index, full prompt and response logging, and the Azure OpenAI abuse-monitoring exemption applied for where prompt retention is not acceptable. The healthcare page covers the sector version of this in more detail.

What the evidence pipeline produces

Azure Policy compliance state mapped to each technical safeguard specification.
Defender for Cloud regulatory compliance assessment for the HIPAA HITRUST initiative, tracked over time rather than captured once.
The deployed resource inventory checked against the BAA-covered service list, so the chain of assurance is demonstrable rather than assumed.
Data-plane access logs for PHI stores, with saved queries answering who read what and when.
PIM activation history and access review outcomes for anyone with a path to PHI.
Key Vault key rotation and access policy history.
Retention and archive configuration proof against the six-year requirement.
The asset inventory and data flow that feed the recurring risk analysis.

What you keep

A PHI data flow diagram: where it enters, where it rests, where it moves, which third parties touch it, kept current by the same pipeline that deploys the estate.
A register of addressable specifications with the decision and the rationale for each. This is the document that turns an argument with an investigator into a conversation.
The policy set as code, including the allowed resource types assignment, in your repository.
The risk analysis workbook with the architectural facts already populated.
Saved evidence queries and the retention plan behind them.

Who this is for

Digital health companies whose first hospital or payer customer has sent a two-hundred-line security questionnaire. Care organizations moving off on-premise systems. Business associates whose covered-entity customers are now flowing HIPAA obligations down by contract. Anyone whose PHI currently sits in the same subscription as everything else, which is most estates that grew organically.

Who this is not for

If you are looking for a HIPAA certificate, no vendor can sell you one and the ones implying otherwise are selling a logo. If separating PHI into its own boundary is off the table because it is inconvenient, the rest of the work is cosmetic. And if your health data is Canadian rather than American, HIPAA is the wrong frame: Loi 25 and provincial health privacy legislation are what actually bind you.

Compliance architecture, the engagement that delivers this.
SOC 2 on Azure, which is usually what the enterprise customer asks for next.
Loi 25 and data residency, for Canadian health data.
Healthcare, the sector context.
Compliance, the pillar.

Questions we get

Is Azure HIPAA compliant?

No platform is compliant on its own. Microsoft will sign a business associate agreement covering in-scope services, which is necessary and not sufficient. Compliance depends on which services you use, how PHI is segmented and encrypted, who can reach it, and what you log. That configuration is the work.

Can we get HIPAA certified?

No such certificate exists. HHS Office for Civil Rights enforces the rule, it does not certify. HITRUST CSF is a private certification that many enterprise customers accept as evidence, and SOC 2 is often what they actually ask for. We build to whichever one you are being measured against.

What is the difference between required and addressable specifications?

Addressable does not mean optional. It means implement the specification, or document why it is not reasonable and appropriate for you and what equivalent measure you put in place instead. The written rationale is itself the artefact an investigator asks for, and its absence is a finding.

Does every Azure service fall under the BAA?

No. The business associate agreement covers a defined list of in-scope services, and preview features are generally outside it. We enforce the allowed list with Azure Policy so a developer cannot place PHI in an out-of-scope service by accident, because that single mistake breaks the chain of assurance.

How long do we have to keep the logs?

HIPAA requires documentation to be retained for six years from creation or last effective date, and audit controls have to be examinable across that period. We set Log Analytics interactive retention against operational need and archive the rest, which is far cheaper than keeping six years hot.

Can AI touch PHI?

With deliberate boundaries. Inference stays inside your tenant over private networking, retrieval respects existing record permissions, every prompt and response is logged, and the abuse-monitoring exemption for Azure OpenAI is applied for rather than assumed. What the system may not do is written down and enforced.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.