Home » HIPAA-Compliant Cloud Architecture on Azure: The Full Checklist

HIPAA-Compliant Cloud Architecture on Azure: The Full Checklist

Rohit Dabra | April 12, 2026

Building a hipaa compliant azure environment is the first decision that shapes every downstream architectural choice your healthcare organization makes. Get it right early and compliance becomes a natural byproduct of your design. Retrofit it later and you are looking at months of remediation work, often triggered by an audit or, worse, a breach.

This checklist covers the specific Azure services, configuration decisions, and governance practices that satisfy HIPAA's Technical Safeguard requirements under 45 CFR Part 164. It's written for engineering leads, architects, and CTOs at healthcare organizations, health tech startups, and any company that processes Protected Health Information (PHI) on behalf of covered entities. Whether you're migrating an existing system or building greenfield, use this as your architectural decision guide.

Why Azure Is a Strong Choice for HIPAA Workloads

Azure holds more healthcare compliance certifications than most competing cloud platforms, including HIPAA, HITECH, and FedRAMP Moderate. But HIPAA-ready infrastructure is not the same as a HIPAA-compliant architecture. The platform provides the underlying controls; your team must configure and govern them correctly.

The key advantage Azure offers healthcare teams is its native integration with the Microsoft identity stack. If your organization already runs on Microsoft 365 or Dynamics 365, Microsoft Entra ID (formerly Azure Active Directory) already has trust relationships in place. Single sign-on, conditional access, and privileged identity management are all HIPAA Technical Safeguard requirements, and they work with the rest of your Microsoft environment without a third-party identity provider in the middle.

Azure also publishes a detailed HIPAA/HITECH compliance blueprint that maps each Azure service to specific HIPAA control requirements. Reference this during your architecture review. It closes the most common audit gaps early and gives your compliance officer a starting point for evidence collection.

Step One: Sign the Business Associate Agreement

Before a single byte of PHI touches Azure, you need a signed Business Associate Agreement (BAA) with Microsoft. This is a legal requirement under HIPAA, not an optional formality. Without it, using Azure for PHI is a HIPAA violation regardless of how well your technical controls are configured.

Microsoft offers a standard BAA as an amendment to the Microsoft Online Services Terms. You can request it through your Microsoft account representative or through the Azure portal under Privacy + Compliance. The BAA covers most Azure services, but not all of them. Services in preview or explicitly outside scope cannot be used to process or store PHI, and Microsoft publishes a current list of in-scope services.

One detail most teams miss: the BAA applies to your Azure subscription, not to individual services. If you're running PHI workloads in a shared subscription alongside non-healthcare workloads, you need to think carefully about audit scope. The cleaner approach is a dedicated subscription for all PHI workloads. This limits your audit scope, simplifies billing, and reduces the blast radius of any misconfiguration.

If you're still evaluating Azure as your platform, the guide on how to evaluate a Microsoft Azure consulting partner covers the right questions to ask before signing any agreements with Microsoft or its partners.

Identity and Access Controls for HIPAA-Compliant Azure

HIPAA's Access Control standard (164.312(a)(1)) requires unique user identification, emergency access procedures, and automatic logoff. Azure's identity stack handles all of this, but only if you configure it deliberately.

A production-ready identity configuration for hipaa compliant azure workloads includes:

Microsoft Entra ID P2, unlocks Privileged Identity Management (PIM), which enforces just-in-time access to sensitive resources. Nobody holds persistent admin roles.
Conditional Access policies, require MFA for all users accessing PHI applications. Enforce compliant device requirements where your device management program supports it.
PIM for all admin roles, access requires approval, carries a time limit, and creates a full audit trail. This satisfies HIPAA's emergency access procedure requirement when paired with a break-glass account process.
Resource-level RBAC, follow least privilege. Assign custom roles where built-in Azure roles grant more permissions than a PHI resource actually requires.
Automatic session timeout, configure session lifetime policies in Conditional Access. Healthcare applications should enforce 15-to-30-minute inactivity timeouts.

The most common mistake we see is teams that enable MFA but skip PIM entirely. MFA protects against credential theft. PIM protects against privilege escalation and provides the standing-access audit trail that HIPAA auditors specifically look for. You need both.

Eager to discuss about your project?

Share your project idea with us. Together, we’ll transform your vision into an exceptional digital product!

Book an Appointment now

PHI Encryption on Azure: At Rest and In Transit

Encryption is mandatory for PHI under HIPAA. The regulation classifies it as addressable rather than required, which means you can document a reason not to implement it. In practice, any auditor will expect encryption everywhere PHI exists. For cloud workloads, the argument against encryption is one you won't win.

At-rest encryption for your hipaa compliant azure deployment:

Azure SQL Database and SQL Managed Instance: Enable Transparent Data Encryption (TDE) with customer-managed keys stored in Azure Key Vault. Microsoft-managed keys are technically acceptable, but customer-managed keys give you control over key lifecycle and satisfy more stringent audit requirements.
Azure Blob Storage: Enable Storage Service Encryption (SSE) with customer-managed keys. Also enable blob versioning and soft delete, these double as data integrity controls.
Azure Cosmos DB: Encryption at rest is on by default; configure customer-managed keys via Key Vault for additional control over key access.
VM Disks: Use Azure Disk Encryption (ADE), which uses BitLocker on Windows and DM-Crypt on Linux.

In-transit encryption:

Set TLS 1.2 as the minimum across all services. Azure allows you to enforce this at the storage account and App Service level.
Enforce HTTPS-only on all storage accounts and web application endpoints.
For internal service-to-service traffic, use Azure Private Link so that data never leaves the Microsoft backbone network.

Where teams get this wrong: Storing encryption keys in application config files, environment variables checked into source control, or hardcoded in code is a HIPAA violation waiting to happen. All keys must live in Azure Key Vault, accessed exclusively via managed identities. No connection strings. No secrets in code.

According to HHS HIPAA Security Rule guidance, covered entities must implement encryption mechanisms to guard against unauthorized access to ePHI during transmission over electronic communications networks.

For a practical breakdown of where healthcare teams most often misconfigure this, the post on 7 Azure HIPAA compliance mistakes healthcare teams make covers the Key Vault misconfiguration pattern in detail.

Azure Network Security for HIPAA Workloads

A flat network where every service can reach every other service does not satisfy HIPAA's Technical Security Measures standard (164.312(e)(1)). That standard requires protection against unauthorized access to PHI transmitted over networks. Network segmentation is how you satisfy it.

The baseline topology for hipaa compliant azure workloads is hub-and-spoke:

Hub VNet: Contains shared services including Azure Firewall, the VPN or ExpressRoute gateway, and Azure Bastion for secure administrative access.
PHI Spoke VNet: Contains only PHI workloads, fully isolated from other application spokes.
Peering: Spokes connect to the hub only. The PHI spoke has no direct peering to non-PHI spokes.

Within the PHI spoke, segment further with Network Security Groups (NSGs) at the subnet level. Define explicit allow rules and deny everything else by default. Document every NSG rule, you will need this documentation as part of your audit evidence package.

Key network controls for this architecture:

Azure Firewall Premium (not Standard) in the hub, the Premium tier adds intrusion detection and prevention (IDPS), TLS inspection, and URL filtering that Standard lacks
Azure Private Endpoints for all PaaS services touching PHI (SQL, Storage, Key Vault, Service Bus), eliminates public internet exposure for your entire data layer
Azure Bastion for all administrative access, no public-facing RDP or SSH, period
DDoS Protection Standard on the hub VNet
NSG flow logs enabled and archived for the full 6-year HIPAA retention window

If you are building a multi-tenant SaaS application on top of this infrastructure, tenant isolation decisions directly affect your compliance posture. The post on building a multi-tenant SaaS app on Azure covers the seven architectural choices that matter most for that scenario.

Eager to discuss about your project?

Share your project idea with us. Together, we’ll transform your vision into an exceptional digital product!

Book an Appointment now

Audit Logging for Your HIPAA-Compliant Azure Environment

HIPAA's Audit Control requirement (164.312(b)) says you must implement mechanisms that record and examine activity in information systems that contain PHI. On Azure, this translates to a specific set of logging configurations that most teams only partially implement.

What you must capture:

Authentication events (success and failure), Microsoft Entra ID sign-in logs
Privileged operations, PIM audit logs and the Azure Activity Log
Data access to PHI storage, SQL audit logs, Storage diagnostic logs, and Cosmos DB audit logs (each must be explicitly enabled per service, they are not on by default)
Network flows, NSG flow logs
Key Vault access, critical for demonstrating that PHI encryption keys were accessed only by authorized parties and processes

How to centralize everything:

Route all diagnostic logs to a Log Analytics Workspace in Azure Monitor. From there, enable Microsoft Sentinel for SIEM capabilities. Sentinel is the most practical way to satisfy the examine activity part of the audit control requirement. Create alert rules for high-risk events: mass data export, new admin account creation, authentication failure spikes, and Key Vault access from unexpected IP ranges.

Configure Log Analytics data retention to 90 days active, then archive to Azure Blob Storage for the full 6-year HIPAA retention window. Skipping the archival step is one of the most common compliance gaps we see at audit time.

Microsoft Defender for Cloud gives you a compliance score mapped specifically to HIPAA/HITRUST controls. Enable it on your subscription and work through the recommendations in the Regulatory Compliance dashboard. It's the fastest gap analysis tool available to a hipaa compliant azure team.

The NIST SP 800-66 Rev. 2 implementation guide maps HIPAA Security Rule requirements to practical controls, and it aligns well with Azure's logging and monitoring capabilities.

For teams using CI/CD for their healthcare workloads, integrating compliance policy checks into the deployment pipeline matters just as much as the runtime controls. The post on Azure DevOps CI/CD pipelines covers how to gate deployments on security and compliance checks.

Backup, DR, and Data Retention for HIPAA Workloads

HIPAA's Contingency Plan standard (164.308(a)(7)) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan. This is the section most teams under-specify in their initial architecture, and it's the one most likely to surface as a finding during a covered entity audit.

Backup configuration for a hipaa compliant azure workload:

Azure Backup for VMs: Daily backups minimum, geo-redundant storage, 30-day short-term retention
Azure SQL automated backups: Full weekly, differential daily, transaction log every 5 to 15 minutes. Set 35-day short-term retention and configure long-term retention policies for 7 years, which exceeds HIPAA's 6-year requirement with a one-year buffer
Blob soft delete and versioning: Enable on all storage accounts holding PHI, with 90-day soft delete retention minimum
Quarterly restore tests: Document the results. Auditors will ask for this evidence specifically.

Disaster recovery targets:

HIPAA doesn't publish specific RTO and RPO numbers, but your covered entity clients will have contractual requirements. Most production healthcare systems target an RTO of 4 hours and an RPO of 1 hour. Achieving this on Azure requires deployment to two regions (primary and secondary), Azure Site Recovery for VM-level replication, SQL active geo-replication with a readable secondary, and Azure Front Door or Traffic Manager for application-level failover.

One practical note worth repeating: your disaster recovery plan is also a HIPAA document. Write it, test it, record the test results, and keep it updated. An untested DR plan is not a HIPAA-compliant DR plan.

HIPAA workload recovery objectives by data criticality tier comparing RTO and RPO targets with corresponding Azure backup and replication services for each tier - hipaa compliant azure

The HIPAA-Compliant Azure Architecture Checklist

Use this as your final review before moving PHI workloads to production. Each group maps to a specific HIPAA Technical or Administrative Safeguard.

Identity and Access:

BAA signed with Microsoft for your subscription
Dedicated Azure subscription for PHI workloads
Microsoft Entra ID P2 licensed and configured
MFA enforced via Conditional Access for all users
PIM enabled for all privileged roles (no standing admin access)
Session timeout configured (15 to 30 minutes for PHI interfaces)
Custom RBAC roles scoped to least privilege

Encryption:

TDE with customer-managed keys on all SQL databases
SSE with customer-managed keys on all Blob Storage accounts
Azure Disk Encryption on all VMs
TLS 1.2 minimum enforced across all services
HTTPS-only enforced on all web endpoints
All keys and secrets stored in Azure Key Vault, accessed via managed identities only

Network Security:

Hub-and-spoke VNet topology deployed
PHI workloads isolated in dedicated spoke VNet
Azure Firewall Premium deployed in hub with IDPS enabled
Private Endpoints configured for all PaaS services handling PHI
NSGs at subnet level with documented, explicit allow rules
Azure Bastion deployed (no public RDP or SSH)
DDoS Protection Standard enabled on hub VNet

Logging and Monitoring:

Diagnostic logging enabled on all PHI-handling services
All logs centralized in Log Analytics Workspace
Microsoft Sentinel enabled with HIPAA-specific alert rules configured
Log retention set to 6-plus years (90 days online, remainder archived)
Microsoft Defender for Cloud enabled and HIPAA compliance dashboard reviewed
NSG flow logs enabled and stored

Backup and DR:

Azure Backup configured for all VMs
SQL long-term retention policy set to 7 years
Blob soft delete and versioning enabled on all PHI storage accounts
DR environment deployed in secondary Azure paired region
RTO and RPO documented, tested, and results on file
Disaster recovery plan written, tested, and dated within the last 12 months

Conclusion

Building a hipaa compliant azure architecture is an ongoing discipline, not a one-time configuration project. Controls drift as teams add new services. New engineers disable settings that look unnecessary. Azure releases new capabilities that expand your audit scope before anyone realizes it.

The organizations we work with that maintain compliance long-term share three habits: a designated Security Officer reviews the Defender for Cloud compliance score monthly, the disaster recovery plan is tested at least once per year with documented results, and every new Azure service goes through a HIPAA scope review before it touches PHI.

If you're planning a hipaa compliant azure deployment and want a structured architecture review before go-live, our team at QServices helps healthcare organizations build the right controls from the start rather than retrofitting them after the fact. Start with our 5-Day Blueprint Sprint to map your architecture against HIPAA requirements before a single control is configured.

Written by Rohit Dabra

Co-Founder and CTO, QServices IT Solutions Pvt Ltd

Rohit Dabra is the Co-Founder and Chief Technology Officer at QServices, a software development company focused on building practical digital solutions for businesses. At QServices, Rohit works closely with startups and growing businesses to design and develop web platforms, mobile applications, and scalable cloud systems. He is particularly interested in automation and artificial intelligence, building systems that automate routine tasks for teams and organizations.

Talk to Our Experts

Frequently Asked Questions

What Azure services are covered under Microsoft's HIPAA BAA?

Microsoft’s HIPAA BAA covers most generally available Azure services including Azure SQL Database, Azure Blob Storage, Azure Virtual Machines, Azure Key Vault, Microsoft Entra ID, Azure Monitor, and Microsoft Sentinel. Preview services and certain developer tooling are typically out of scope. Microsoft maintains a current list of in-scope services in its Trust Center documentation, and you should verify any new service against that list before using it to process PHI.

Do I need a dedicated Azure subscription for HIPAA workloads?

A dedicated subscription is not strictly required by HIPAA, but it is strongly recommended. Placing PHI workloads in their own subscription clearly defines your audit scope, simplifies cost allocation, and reduces the risk that a misconfiguration in a non-healthcare workload affects your compliance posture. It also makes it easier to apply subscription-level Azure Policy controls without affecting other applications.

How long must PHI audit logs be retained under HIPAA?

HIPAA’s documentation requirements mandate a retention period of 6 years from the date of creation or the date when it was last in effect, whichever is later. For Azure, this means configuring Log Analytics Workspace active retention for 90 days and archiving the remainder to Azure Blob Storage in a cool or archive tier to manage cost over the full retention window.

Is Azure encryption at rest sufficient for HIPAA compliance?

Azure’s default encryption at rest (using Microsoft-managed keys) satisfies the basic encryption requirement, but most HIPAA auditors and covered entities prefer or require customer-managed keys stored in Azure Key Vault. Customer-managed keys give you control over key rotation, revocation, and access logging, all of which produce stronger audit evidence. For a production HIPAA environment, configure customer-managed keys on all storage services handling PHI.

What is the minimum TLS version required for HIPAA compliance on Azure?

HIPAA does not specify TLS versions explicitly, but NIST SP 800-52 Rev. 2 (referenced in HIPAA implementation guidance) requires TLS 1.2 as the minimum for transmitting sensitive data. Azure allows you to enforce TLS 1.2 minimums at the storage account level, App Service level, and Azure API Management tier. Configure this on every service that handles PHI, and disable support for TLS 1.0 and 1.1.

How do I document Azure HIPAA compliance for an auditor?

Auditors typically want four categories of evidence: configuration documentation (NSG rules, RBAC assignments, Conditional Access policies), access logs (PIM audit history, sign-in logs, Key Vault access logs), testing evidence (DR test results, penetration test reports), and policy documentation (disaster recovery plan, incident response plan). The Microsoft Defender for Cloud Regulatory Compliance dashboard generates a compliance report mapped to HIPAA controls, which is a practical starting point for your evidence package.

Can Azure PaaS services like Azure SQL be used to store PHI?

Yes, Azure SQL Database and SQL Managed Instance are both in scope for Microsoft’s HIPAA BAA and are widely used for PHI storage in production healthcare systems. The key requirements are enabling Transparent Data Encryption with customer-managed keys, configuring SQL Audit logging to a Log Analytics Workspace, restricting access via Private Endpoints rather than public internet connectivity, and setting long-term backup retention to at least 7 years.