This guide covers general configuration and compliance-process guidance. It is not legal advice. Whether your organization is HIPAA compliant depends on your specific PHI handling, your own risk analysis, and your legal counsel. Use this as a starting point for that conversation, not a substitute for it.
You signed a Business Associate Agreement with Microsoft. That doesn’t mean your Azure environment would survive an audit, and most teams don’t find out until one happens.
Microsoft is upfront about why: a BAA “helps support your HIPAA compliance,” but compliance ultimately comes down to how you configure and use the platform, not the platform itself. This guide covers what Azure actually handles, what’s left to you, and where teams get it wrong.
The Shared Responsibility Model, Explained for Azure + HIPAA
Every HIPAA-on-Azure conversation eventually comes back to shared responsibility. Get this model straight and most of the rest of this guide is just detail.
What Microsoft is always responsible for: physical datacenter security, the physical network, the physical host hardware, and the hypervisor layer. Microsoft is explicit that it does not inspect, approve, or monitor the applications you deploy on Azure. That’s not a gap in their service. It’s the boundary of it.
What you are always responsible for: your data (how you classify it, protect it, encrypt it, and govern it), your endpoints, your accounts, and your access management (RBAC, MFA, Conditional Access). None of that shifts, no matter which Azure services you use.
How responsibility shifts by service model: as you move from infrastructure-as-a-service to platform-as-a-service to software-as-a-service, Microsoft absorbs more of the operating system and platform layer. You still never hand off data, identity, or access control. That stays yours at every tier. (If you’re still deciding which workloads to rehost, replatform, or rebuild, the 6 R’s of cloud migration maps directly to how much of this table stays on your plate.)
| Layer | On-premises | IaaS | PaaS | SaaS |
| Data & access management | You | You | You | You |
| Applications | You | You | Shared | Microsoft |
| Operating system | You | You | Microsoft | Microsoft |
| Network controls | You | Shared | Microsoft | Microsoft |
| Physical infrastructure | You | Microsoft | Microsoft | Microsoft |
If you take one thing from this section, take this: the BAA is a contract that helps support your compliance. It is not a guarantee of it.
The Business Associate Agreement Process With Microsoft
You don’t sign a separate contract. The HIPAA BAA is included by default in the Microsoft Product Terms (formerly the Online Services Terms), delivered through the Microsoft Products and Services Data Protection Addendum. Any customer that’s a covered entity or business associate under HIPAA gets it automatically with standard commercial licensing. There’s no extra signature step and no separate negotiation.
What’s actually covered. The BAA applies only to services Microsoft has designated as in-scope. Azure and Azure Government headline that list, alongside Microsoft 365, Dynamics 365, the Power Platform, Teams, and a set of other named services. Here’s the part most teams miss: preview and beta features, and most third-party Azure Marketplace offerings, generally fall outside BAA coverage. If your team spun up a newer Azure service to test something and PHI ended up flowing through it, you may have a coverage gap you don’t know about yet. This is especially common mid-migration, when workloads land wherever is fastest. Our Azure cloud migration FAQ covers how to plan a move so compliance scope doesn’t get lost along the way.
How to confirm your specific services are in scope. Don’t assume. Check. Microsoft publishes the authoritative in-scope service list in its “cloud services in audit scope” documentation, with the detailed appendix available through the Service Trust Portal. That’s also where you’ll find your organization’s copy of the BAA/DPA documentation for your own compliance records and for auditor requests.
Configuring Azure for HIPAA: The Technical Safeguards That Matter
This is where the BAA stops helping and your configuration decisions start mattering.
Encryption. Enforce TLS in transit. Use Azure’s built-in encryption at rest: Transparent Data Encryption for databases, disk encryption for VMs, Always Encrypted for sensitive database columns. For workloads actually touching PHI, prefer customer-managed keys through Azure Key Vault (or Managed HSM) over Microsoft-managed keys. You get granular control and a real audit trail. Enable soft-delete and purge protection so a key can’t disappear along with your ability to prove compliance.
Access controls. Microsoft Entra ID is your identity backbone here (our guide to Microsoft Entra ID for startups covers setup and licensing). Enforce MFA and Conditional Access. Use Privileged Identity Management for just-in-time admin elevation instead of standing admin rights. Apply Azure RBAC on least-privilege principles. Use managed identities for workloads instead of embedding secrets or keys in code. Run access reviews on a schedule. Dormant permissions are the access-control equivalent of an unlocked back door nobody remembers exists.
Audit logging. Enable Microsoft Defender for Cloud’s regulatory compliance dashboard, which maps directly to a built-in HIPAA/HITRUST Azure Policy initiative. Centralize activity logs, resource logs, and SQL/database audit logs through Azure Monitor and Log Analytics. Retain logs long enough to support both an incident investigation and a compliance evidence request. Those two needs don’t always have the same retention window, so plan for the longer one. (The same evidence-first approach applies across frameworks. Here’s how to walk into a SOC 2 audit already ready.)
Network isolation. Segment production, staging, and development environments. Use network security groups and private endpoints so PHI-handling resources aren’t sitting on the public internet by default. Monitor network flow logs for access patterns that don’t match how your team actually works.
Common Azure Misconfigurations That Cause HIPAA Violations
Most of these aren’t exotic. They’re the same handful of mistakes, repeated across environments:
- Storing PHI in an Azure service that isn’t actually BAA-covered, often a preview or beta feature a team adopted early without checking scope.
- Exposing PHI inadvertently through support tickets, diagnostic logs, or telemetry sent to Microsoft or third-party tools.
- Relying on default Microsoft-managed encryption keys where your own risk assessment calls for customer-managed key control and auditability.
- Skipping MFA or least-privilege enforcement on any account with PHI access. This is still one of the most common findings in real breach investigations, on any cloud platform.
- Inadequate logging of key vault operations and data-access events, which leaves no evidence trail when you actually need one.
- Replicating data or backups to a region that violates your own data-residency commitments, usually discovered during a disaster-recovery test that wasn’t run early enough to catch it.
And the biggest strategic mistake, sitting above all of these: treating the signed BAA as the finish line instead of the starting point.
Backup, Disaster Recovery & Data Residency Considerations
Your backup and disaster-recovery configuration needs to meet the same bar as production. Not a lower one, and not “we’ll tighten it up later.” Verify that backup and DR restore locations satisfy the same residency and access-control requirements you’ve committed to elsewhere. Include PHI-handling systems explicitly in your incident response and breach-notification runbooks, per the HIPAA Breach Notification Rule. And test recovery procedures on the same cadence as any other compliance-critical system. A DR plan that’s never been tested is a hypothesis, not a control. (For a deeper look, see what Azure disaster recovery actually covers, and what it doesn’t.)
When Azure Alone Isn’t Enough: Why Most Teams Need Managed Support
For a lean startup team without a dedicated security or compliance function, correctly configuring (and continuously monitoring) encryption, access control, audit logging, and network isolation across a live Azure environment isn’t a one-time setup task.
It’s ongoing operational work, and it competes for attention with everything else on your team’s plate. This is exactly where compliance drift creeps in: a key rotation policy that quietly lapses, an access review that gets skipped for a quarter, a new engineer added to a resource group with more permission than their role needs. None of that shows up until an auditor (or an incident) finds it.
Managed compliance support exists to catch that drift before it becomes a finding. For teams that need security leadership without a full-time hire, that often starts with a vCISO paired with managed cloud operations.
How Interlaced Helps
HIPAA is one framework Interlaced supports within a broader compliance-as-a-service practice that also covers SOC 2, ISO 27001, GDPR, and NIST CSF 2.0. We’re not a healthcare-specialized shop, and we won’t pretend otherwise. What we bring is the same compliance-program rigor we apply across every framework we support, pointed at the Azure environment you’re already running.
In practice, that means helping you configure, monitor, and maintain the technical safeguards HIPAA actually requires: identity and access management through Microsoft Entra ID, encryption key strategy through Azure Key Vault, centralized audit logging through Azure Monitor, and the ongoing access reviews and posture checks that keep all of it from quietly drifting out of compliance between audits.
If you’re running PHI on Azure and want a second set of eyes on your configuration (not a sales pitch about healthcare expertise we don’t have), start with a health check.
Book Your Free Azure Health Check →
For the broader HIPAA picture beyond Azure specifically (the Privacy Rule, the Security Rule, and general program requirements), see our complete guide to becoming HIPAA compliant.
FAQ
Is Microsoft Azure HIPAA compliant? Not as a blanket label. Azure has built the required safeguards into its in-scope services and offers a standard BAA to any eligible customer, but Microsoft is explicit that using Azure doesn’t automatically make your specific application or configuration compliant. That depends on how you configure and use it.
Do I need to sign a separate BAA with Microsoft for Azure? No. The HIPAA BAA is included by default in the Microsoft Product Terms through the Microsoft Products and Services Data Protection Addendum. There’s no extra contract to negotiate or sign for standard commercial licensing.
Which Azure services are actually covered by the Microsoft BAA? Only Microsoft-designated in-scope services, detailed in Microsoft’s published audit-scope documentation and Service Trust Portal appendices. Preview and beta features, along with most third-party Azure Marketplace add-ons, are generally not covered. Check before you store or process PHI in any newer or niche Azure service.
What is the shared responsibility model for HIPAA on Azure? Microsoft secures the physical infrastructure, network, hosts, and hypervisor. You’re always responsible for your data, endpoints, accounts, and access management (encryption choices, RBAC, MFA). How much of the operating system and application layer Microsoft manages shifts as you move from IaaS to PaaS to SaaS, but data and identity responsibility never transfer.
What are the most common Azure HIPAA compliance mistakes? Storing PHI in a service that isn’t BAA-covered, leaving default encryption keys and access controls in place instead of tightening them for PHI workloads, weak or missing MFA and least-privilege enforcement, insufficient audit logging of who accessed what and when, and (most fundamentally) assuming the signed BAA means you’re done.
Does having a BAA with Microsoft mean my app is HIPAA compliant? No. Microsoft states directly that it “doesn’t inspect, approve, or monitor your applications deployed on Azure,” and that a BAA “helps support” compliance without automatically imparting it. Your application’s own risk analysis, safeguards, and policies still determine whether you’re actually compliant.
What Azure services should a HIPAA-covered startup configure first? Start with identity (Microsoft Entra ID with MFA and Conditional Access), encryption (Key Vault-managed keys for PHI-handling storage and databases), and centralized audit logging (Azure Monitor and Log Analytics, plus Microsoft Defender for Cloud’s regulatory compliance dashboard). These three cover the safeguards teams most commonly miss.
Do I need help from a managed IT or compliance provider to be HIPAA compliant on Azure? Not strictly required, but for lean teams without a dedicated security function, correctly configuring and continuously monitoring encryption, access control, and audit logging across a live Azure environment is ongoing operational work, not a one-time setup. That’s exactly where managed compliance support closes the gap between “we have a BAA” and “we’re actually compliant.” Not sure where your environment stands? Book your free Azure Health Check.