Standardize Azure Landing Zones for PHI, Networking, Backup, and Disaster Recovery

A production EHR can be encrypted, privately connected, and fully backed up, and still fail during a regional outage because DNS, secrets, interfaces, or recovery sequencing were never designed for the secondary environment.

A healthcare Azure landing-zone standard should make every workload inherit a safe baseline while requiring teams to define clinical criticality, data-loss tolerance, recovery order, and application validation.

What Is an Azure Landing Zone?

An Azure landing zone is not one subscription, virtual network, or template. 

It is a scalable, multi-subscription architecture with a platform landing zone for shared governance, security, identity, connectivity, and management, plus application landing zones where teams deploy workloads inside those guardrails.

The platform team owns the reusable control plane. The application owner still owns the EHR, interface engine, database consistency, clinical workflow, and recovery acceptance.

Why Landing-Zone Standardization Matters for PHI

The HIPAA Security Rule requires risk analysis and reasonable safeguards for the confidentiality, integrity, and availability of electronic PHI. Its contingency standard includes data backup, disaster recovery, emergency-mode operations, criticality analysis, and periodic testing. It does not prescribe an Azure product or topology.

Microsoft offers a HIPAA Business Associate Agreement for in-scope services, but states that using Azure does not automatically make a customer solution compliant. 

Likewise, a “Compliant” result in Azure Policy’s HIPAA/HITRUST initiative covers only the mapped policy definitions, not every requirement of the control.

The landing zone therefore has two jobs: prevent unsafe configuration drift and generate evidence that technical controls are operating.

Define the Healthcare Landing-Zone Contract

Before deployment, document a control contract for every workload. Define RTO as the maximum acceptable recovery time and RPO as the maximum acceptable data loss measured in time.

Step 1: Organize by Control Boundary, Not the Organization Chart

Use an intermediate organizational root with Platform, Landing Zones, Sandbox, and Decommissioned branches. Platform can separate security, management, connectivity, and identity subscriptions according to the operating model. Under Landing Zones, add a PHI-specific archetype only when existing archetypes should not inherit its controls.

Keep management groups flat. Microsoft recommends organizing them around common policy needs, not business units, development stages, or Azure regions. Isolate production and non-production with subscriptions when their access, budgets, blast radius, or data differ, but place them under the same applicable archetype.

Step 2: Turn Guardrails Into Versioned Policy

Deploy the Azure Landing Zones IaC Accelerator or Azure Verified Modules with Bicep or Terraform under version control and peer review. (Microsoft implementation options)

The PHI baseline should evaluate or enforce:

• approved regions and service SKUs;
• encryption at rest and TLS settings appropriate to each service;
• disabled or explicitly approved public data-plane access;
• Private Link, private DNS, and diagnostic settings where supported;
• Microsoft Defender for Cloud coverage and centralized security telemetry;
• backup protection, vault security, and required resource tags.

Implement a controlled policy pipeline

Treat policy rollout as a release, not a portal change:

• Pin modules and initiatives in Git; validate Bicep, run what-if, and test in a non-production management group.
• Start with enforcementMode: ‘DoNotEnforce’; compliance is evaluated without blocking or modifying requests. Resolve false positives before changing to Default.
• For Modify or DeployIfNotExists, give the assignment a managed identity and only its required roles. Run a remediation task for existing resources; assignment alone does not repair them.
• Promote the same artifact. Exemptions require an owner, justification, compensating control, and ISO 8601 expiresOn; expired exemptions remain as evidence but stop applying.

This intentionally limited Bicep shows the management-group assignment pattern; the initiative remains a reviewed artifact:

targetScope = 'managementGroup'

param initiativeDefinitionId string
param initiativeParameters object = {}

@allowed([
  'DoNotEnforce'
  'Default'
])
param enforcementMode string = 'DoNotEnforce'

resource phiBaseline 'Microsoft.Authorization/policyAssignments@2026-06-01' = {
  name: 'phi-baseline'
  properties: {
    displayName: 'PHI landing-zone baseline'
    policyDefinitionId: initiativeDefinitionId
    parameters: initiativeParameters
    enforcementMode: enforcementMode
    nonComplianceMessages: [
      {
        message: 'Resource violates the PHI baseline; use an approved, expiring exemption.'
      }
    ]
  }
}

Set the three nonsecret CI variables, preview the management-group change, then query compliance after evaluation completes. DEPLOYMENT_REGION stores deployment metadata, not resources. (policy assignment schema, management-group deployments, what-if, policy state CLI)

az deployment mg what-if \
  --management-group-id "$PHI_MG_ID" \
  --location "$DEPLOYMENT_REGION" \
  --template-file policy-assignment.bicep \
  --parameters initiativeDefinitionId="$PHI_INITIATIVE_ID"

az policy state summarize --management-group "$PHI_MG_ID"
Protect policy administration with least-privilege RBAC, Microsoft Entra Privileged Identity Management (PIM), multifactor authentication, and separate emergency-access accounts.

Step 3: Standardize the PHI Network Path

Use hub-and-spoke for direct routing and appliance control, or Virtual WAN when managed transit and scale justify it. Put firewalls, gateways, DNS, and monitoring in the connectivity subscription; force controlled egress and provide redundant hybrid paths for critical dependencies.

Use Private Link for supported PaaS data planes. Link centralized private DNS zones to authorized networks and test resolution from Azure, on-premises, and the recovery region before disabling public access.

Validate the data path, not only the resource state

From a host on the workload path, resolve the application’s normal service FQDN, not the private link name, and compare it with the endpoint NIC address. Test the port and inspect effective routes, NSGs, firewall logs, and endpoint approval. Repeat from on-premises and the secondary region.

$fqdn = '<service-fqdn-used-by-the-application>'
Resolve-DnsName -Name $fqdn -Type A
Test-NetConnection -ComputerName $fqdn -Port 443 -InformationLevel Detailed

Pass only when the A record matches the private endpoint IP, and TcpTestSucceeded is True.

Step 4: Engineer Backup as a Protected Recovery System

Map databases, disks, file shares, object storage, queues, configuration, certificates, and IaC to an owner, backup method, retention, RPO, restore procedure, and integrity test.

Azure Backup vaults must be in the protected resource’s region. Separate vaults when region, production boundary, workload type, or administrator scope differs. For cross-region recovery, evaluate GRS with Cross-Region Restore, but verify workload-specific secondary recovery timing against RPO.

Apply backup controls in the correct order

• Select the supported vault type and create one per protected region.
• Choose LRS, ZRS, or GRS before the first protected item; redundancy is then locked. Cross-region restore is not low-latency replication.
• Apply workload schedules and retention. Coordinate database-native consistency, transaction logs, and queue recovery; a VM snapshot is not automatically an application-consistent database backup.
• Enable soft delete and immutability. Test retention and restore before irreversibly locking immutability. Protect critical operations with Resource Guard multiuser authorization owned independently from backup operations.
• Alert on failed jobs, stopped protection, policy changes, and destructive actions. Restore in isolation and validate consistency, counts, encryption access, audit logs, and application behavior.

Step 5: Design Disaster Recovery Around the Whole Clinical Service

Backup restores data; DR restores a service. Availability zones do not replace regional recovery. 

Site Recovery replicates supported machines and orchestrates failover, but PaaS, AKS, storage, and integration services require service-specific patterns.

Sequence connectivity and DNS, identity, secrets, data, application, inbound routing, EHR interfaces, and downstream feeds. Define downtime procedures, queue replay, duplicate prevention, reconciliation, disaster authority, and failback criteria.

Execute a clinical-service DR drill

• Prebuild secondary routing, DNS, firewall policy, private endpoints, quotas, identities, secrets, certificates, and monitoring.
• Group machines by dependency; place automation or controlled pauses between groups. Choose recovery-point type based on consistency and RPO needs.
• Run Test Failover in an isolated VNet, keep replication running, and block production interfaces.
• Use the business impact analysis–defined RTO as the start. Measure RPO from the newest clinically validated transaction. Test database consistency, authentication, audit events, workflows, acknowledgments, queue replay, and duplicate suppression.
• Record findings, run Cleanup test failover, correct the runbook, and retest. Microsoft recommends each application recovery plan at least quarterly.

Microsoft cautions that a technically successful restore can still be incomplete; recovery testing must verify data integrity and completeness.

Production Acceptance Criteria

A PHI landing zone is ready only when:

• every PHI asset has an accountable owner and tested recovery path;
• public access and policy exemptions are documented, approved, and time-bound;
• backup administrators cannot independently weaken recovery protection;
• secondary-region networking, DNS, authentication, secrets, and integrations work together;
• measured restore and failover results meet approved RTO and RPO targets;
• runbooks, evidence, exceptions, and corrective actions are retained for review.

The real deliverable is not an Azure diagram. It is a repeatable platform plus proof that a healthcare workload can fail safely and recover correctly.

Build an Azure Foundation That Can Survive the Recovery Test

CapMinds helps healthcare organizations assess, design, and implement Azure landing zones across PHI governance, private networking, DevSecOps, backup, disaster recovery, and EHR interoperability. We connect platform controls to the clinical and operational dependencies that determine whether recovery works.

Request an Azure Landing Zone Review