Building a HIPAA-Compliant Azure Landing Zone: A Reference Architecture

A Business Associate Agreement (BAA) with Microsoft does not make your Azure estate HIPAA-ready. Eligibility covers which services you may use; a landing zone decides how every subscription, identity, network path, and log sink behaves when electronic protected health information (ePHI) eventually lands. Influrion Solutions is a software development and healthcare IT company that helps CTOs and cloud architects turn that distinction into an operable reference architecture — not a slide titled “secure by default.”

This guide is a reference architecture and build sequence for a HIPAA-aligned Azure landing zone. It assumes you already understand that HIPAA-eligible ≠ compliant, and that application controls remain yours. If you are still choosing between clouds, start with platform fit; if Azure is the decision, use this as the blueprint your platform team can fund and operate.

What an Azure landing zone must solve for HIPAA

An Azure landing zone (ALZ) is the foundation: management group hierarchy, identity baselines, connectivity, governance (Policy + Blueprints/templates), and platform observability. For healthcare, add three non-negotiables:

1. Allow-listed compute and data paths — only HIPAA-eligible services under your BAA, configured with private networking and encryption defaults.
2. Separation of duties — platform vs workload subscriptions; who can create public endpoints; who can read production logs that may contain ePHI.
3. Evidence by design — audit logs, Policy compliance states, and access reviews that security/compliance can export without a fire drill.

Influrion’s working definition: a HIPAA-aligned landing zone is one where a new workload subscription cannot accidentally open a public ePHI path without tripping Policy, and where platform teams can prove that control weekly.

Landing-zone concern	HIPAA-relevant outcome	Typical Azure controls
Identity	Least privilege + MFA + break-glass	Entra ID, Conditional Access, PIM
Network	No casual internet exposure of data planes	Hub-spoke, Private Link, NSGs, Azure Firewall
Governance	Drift detection and deny-by-default	Management groups, Azure Policy, initiative assignments
Data	Encryption, key ownership, backup boundaries	Key Vault, CMK options, private endpoints
Evidence	Reconstruct who did what, when	Diagnostic settings → Log Analytics / immutable archive
Ops	Patch, backup, incident paths	Update Manager, Backup, Defender for Cloud

Reference architecture: six layers

Think of the landing zone as six stacked decisions. Document each in an architecture decision record (ADR) so product teams stop inventing side doors.

1. Management group hierarchy

A common, operable shape for regulated mid-market estates:

• Tenant Root → Platform (Identity, Connectivity, Management) + Landing Zones (Corp / Online / Sandbox) + optional Decommissioned.
• Under Landing Zones / Healthcare (or Corp): Prod, NonProd, Shared Services (optional) — each mapped to one or more subscriptions.
• Keep Sandbox outside ePHI paths; Policy should block HIPAA-eligible data stores there or force stronger isolation.

Do not create one subscription per micro-app on day one. Start with environment-level subscriptions (Prod/NonProd) and split when blast radius or billing/ownership demands it.

2. Identity and privileged access

• Entra ID as the control plane for humans and workloads (managed identities preferred over long-lived secrets).
• Conditional Access: MFA for all interactive admins; block legacy auth; restrict admin portals by location/device where practical.
• Privileged Identity Management (PIM) for Owner/Contributor on platform and production subscriptions — standing Owner is a compliance smell.
• Break-glass accounts: two cloud-only emergency accounts, monitored, excluded carefully from Conditional Access with compensating controls.
• Workload identities: user-assigned managed identities for AKS, Functions, App Services; Key Vault references instead of connection strings in config.

Map Entra groups to Azure RBAC at management-group or subscription scope — not ad-hoc user assignments in every resource group.

3. Connectivity (hub-and-spoke)

• Hub: Azure Firewall (or NVA), shared DNS (Private DNS zones), bastion/jump path, ExpressRoute/VPN to on-prem if needed.
• Spokes: workload VNets peered to hub; no direct spoke-to-internet for ePHI data planes.
• Private Link / private endpoints for PaaS (SQL, Storage, Key Vault, ACR, App Service when in scope).
• Public endpoints: deny by Policy for production data stores; exceptions time-boxed and ticketed.

If you still need hybrid connectivity, treat the hub as the only bridge. Flat “everything peered to everything” networks recreate the on-prem spaghetti HIPAA auditors already dislike.

4. Governance with Azure Policy

Policy is the difference between a diagram and a landing zone. Start with a HIPAA / healthcare baseline initiative (Microsoft’s built-in healthcare/HIPAA-related initiatives as a starting point — then customize):

• Require HTTPS / TLS minimums on App Service and Front Door paths you allow.
• Require secure transfer and encryption for Storage; disallow public blob access in Prod.
• Require diagnostic settings on critical resource types.
• Deny public IP on SQL / Cosmos / Redis-class resources in Prod (adjust to your SKU set).
• Enforce allowed locations and allowed SKU lists aligned to your BAA allow-list.

Use DeployIfNotExists for logging and private DNS links where safe; use Deny for high-risk network exposure. Soft-enforce in NonProd first, then harden Prod.

5. Platform logging and security posture

• Route activity logs, Entra sign-in/audit (where licensed), resource diagnostics, and Firewall logs to a central Log Analytics workspace in the Management subscription — with RBAC so app teams see their apps, not all ePHI-adjacent telemetry.
• Enable Microsoft Defender for Cloud plans you can operate (Servers, Storage, SQL, Containers, Key Vault as applicable).
• Decide early whether security logs that may contain identifiers are treated as ePHI-adjacent and who may query them.
• Consider immutable storage or long-retention archive for audit evidence (retention aligned to your policies and contracts — often measured in years, not weeks).

6. Shared platform services

Provide as platform products, not tribal knowledge:

• Key Vault patterns (access policies vs RBAC, purge protection, soft delete, private endpoint).
• Container registry (ACR) with private link and vulnerability scanning.
• GitHub/Azure DevOps service connections using federated credentials / OIDC — avoid long-lived SP secrets.
• Landing-zone acceleration: Bicep/Terraform modules that stamp a compliant spoke (VNet, NSGs, Law link, Policy exemptions process).

Build sequence CTOs can fund (90-day shape)

You do not need a year of foundation before the first app. Sequence for evidence and early wins:

Days 1–15 — Contract and allow-list

1. Confirm Microsoft BAA coverage and document the HIPAA-eligible service allow-list you will actually use.
2. Freeze “shadow SKUs” (AI search, random marketplace images, consumer chatbots) until Policy and architecture review exist.
3. Name owners: platform (identity/network/policy), security (Defender/SIEM), workload (apps that process ePHI).

Days 16–45 — Platform subscriptions

1. Stand up management group tree + platform subscriptions (Identity, Connectivity, Management).
2. Implement hub networking + Private DNS.
3. Assign baseline Policy initiatives at Landing Zones scope; start in audit mode, then deny for critical rules.
4. Wire diagnostic settings and a central workspace; validate you can answer “who elevated to Owner last week?”

Days 46–75 — First regulated spoke

1. Stamp NonProd then Prod spokes with private endpoints for one thin vertical (e.g., patient portal API + SQL).
2. Enforce managed identities and Key Vault references.
3. Run a tabletop: lost laptop of an admin, mis-tagged public storage, expired PIM activation — document gaps.

Days 76–90 — Operate and evidence

1. Turn on continuous compliance dashboards (Policy + Defender).
2. Document exemption process (who approves, expiry, compensating control).
3. Hand product teams a subscription vending checklist — not a blank subscription with Owner.

Influrion’s rule of thumb: if product teams can create a public Storage account in Prod without a Policy deny, you do not have a HIPAA landing zone yet — you have a folder structure.

Shared responsibility: what Azure will not do for you

Layer	Microsoft (typical)	You (always)
Physical / host fabric	Datacenter, hypervisor isolation	Trust but verify via attestations and config
PaaS control plane	Service availability under SLA	Correct private networking, auth, encryption settings
Identity	Entra as a service	Conditional Access, PIM, joiner/mover/leaver
Application	—	Input validation, least data, session security, BAAs with your vendors
ePHI decisions	—	Minimum necessary, retention, patient rights workflows

A landing zone reduces the chance of platform foot-guns. It does not replace application threat modeling, BAAs with downstream SaaS, or workforce training.

Pitfalls that break “HIPAA landing zones” in practice

1. Eligible service, public by default. Private Link forgotten; “temporary” public SQL firewall rule becomes permanent.
2. Logs that become shadow PHI. Verbose app logging of demographics into a workspace with broad Reader access.
3. Standing privileged access. Shared Owner accounts; PIM never adopted; break-glass used for daily work.
4. Sandbox connected to Prod. Peering or shared identity that lets test tools reach production data stores.
5. Policy theater. Initiatives assigned at root, then blanket exemptions with no expiry.
6. CI/CD as a backdoor. Pipelines with Owner that can open public endpoints faster than Policy reviews catch them — fix with constrained deployment principals and pre-merge Policy checks.
7. Ignoring on-prem. ExpressRoute without hub controls recreates flat networks in the cloud.

Buyer questions before you sign off the design

• Which management groups and subscriptions are in scope for ePHI, and which are explicitly out?
• What is the deny list for public network access in Prod — and who can exempt it?
• Are all human Owners on PIM with MFA Conditional Access?
• Where do Firewall, activity, and resource logs land, who can query them, and how long are they retained?
• How do we stamp a new spoke in under a day without copying an old insecure VNet?
• Is the BAA service allow-list checked in ADRs and in Policy (allowed resource types / SKUs)?
• What is the incident path when Defender flags anomalous data-plane access?

FAQ

Is Microsoft’s Azure Landing Zone “HIPAA certified”?

No single ALZ template makes you HIPAA compliant. Microsoft provides landing-zone accelerators and compliance Policy initiatives; your configuration, operations, and applications determine compliance under the shared-responsibility model and your BAA.

Do we need a separate tenant for healthcare?

Usually not for mid-market. Strong management-group isolation, identity hygiene, and network controls are enough for many organizations. Separate tenants appear when M&A, hard regulatory isolation, or conflicting identity policies demand it — and they increase ops cost.

Can we put ePHI in Log Analytics?

Treat telemetry as potentially sensitive. Minimize fields, restrict RBAC, prefer workspace-per-environment or careful resource-context access, and align retention with policy. Do not grant every developer Reader on the central security workspace.

Should we use Azure Blueprints or just Bicep/Terraform?

Prefer code you own (Bicep/Terraform modules + Policy) for ongoing drift control. Use Microsoft’s conceptual ALZ design; implement with the IaC your platform team can maintain. Blueprints alone are not a substitute for continuous Policy.

How does this relate to Azure Health Data Services / FHIR?

Health Data Services sit on top of a landing zone. FHIR/DICOM services still need private networking, identity, logging, and Key Vault patterns. Do not deploy health PaaS into an ungoverned subscription and call it done.

Closing

A HIPAA-aligned Azure landing zone is less about buying another security SKU and more about forcing good defaults: private data planes, privileged access that expires, Policy that denies unsafe exposure, and logs that prove it. Influrion Solutions helps healthcare and regulated product teams design and implement these foundations alongside the applications that process ePHI — so compliance evidence and delivery speed improve together.

If you want a review of your current management-group design, Policy gaps, or a spoke-stamping module set against this reference, contact Influrion and we can walk through a concrete gap list for your Azure tenant.