Does an Azure BAA make our ePHI workloads HIPAA compliant?
Your customer, contract or covered entity now asks you to host ePHI on Azure, and you want to know what Microsoft's paperwork already covers. Microsoft offers its HIPAA BAA by default through the Product Terms and Data Protection Addendum, with no separate contract to sign, but the BAA does not make your workloads HIPAA compliant. Microsoft states that using Azure does not automatically make a cloud solution compliant, that it does not inspect or approve customer applications, and that customers carry their own compliance program. There is also no HHS-approved certification for cloud providers acting as business associates, so any claim that Azure is "HIPAA certified" should be challenged. Microsoft's Azure HIPAA offering page is the right starting point for confirming the current terms.
The organization owns its controls. Its risk analysis, policies, access management, logging, encryption settings and workforce training remain its obligations under the Security Rule, and each business associate must perform its own risk analysis, with OCR noting that the cloud configuration affects the risk management plans of all parties. An implementation partner can prepare the Azure environment, configure services and assemble evidence, but it does not issue reports or attest to compliance. Only an independent auditor or assessor issues those, and HHS does not recognize private certifications as proof of Security Rule compliance. Confirm with Microsoft which services are in the HIPAA scope, because the BAA covers the services it lists, not every Azure product.
Three factors change the answer for each organization. First, which Azure services will store, process or transmit ePHI, since each service's configuration determines what safeguards you must document and test. Second, whether you are a covered entity or a business associate, because that sets the contract chain you must hold with your own customers. Third, whether you use SaaS vendors that run on Azure, since healthcare SaaS providers sign BAAs with you, not with Microsoft, and you need to see their BAAs and their own risk analyses before ePHI reaches their platform.
When a SaaS vendor on Azure needs its own BAA
If your organization builds its own ePHI system on Azure virtual machines, managed databases or app hosting, you are a covered entity or business associate using a cloud provider directly. Microsoft offers its HIPAA BAA by default through the Product Terms and Data Protection Addendum, so there is no separate contract to negotiate with Microsoft. Microsoft's position is that a BAA does not make your workload compliant. The compliance program around the workload remains yours.
- Microsoft's BAA scope: The BAA applies to the services Microsoft lists as covered. Confirm that each service in your architecture appears on the covered services list, not only the product family.
- Your compliance program: Microsoft says it does not inspect or approve customer applications. Your risk analysis, access controls, policies and workforce training remain your obligations.
- Shared configuration risk: OCR's cloud guidance states that the cloud configuration affects the risk analysis of every party. Document your network design, identity setup and encryption choices so they can be assessed.
- Encrypted ePHI without keys: A cloud provider that stores only encrypted ePHI and lacks the key is still a business associate under HHS guidance. The BAA remains necessary even if you hold the keys.
Before relying on the BAA, check the covered services list against your full architecture and confirm which controls your team operates.
If you buy a healthcare application that runs on Azure, you sign the BAA with the SaaS vendor, not with Microsoft. Microsoft states that healthcare SaaS customers sign BAAs with the SaaS provider. The vendor is your business associate, and it typically relies on Azure as its own hosting provider. That creates a subcontractor chain you did not contract for directly, so you need to see how it is governed.
- Your contract is with the vendor: The BAA defines permitted uses and disclosures, breach reporting duties, and the return or destruction of ePHI at termination.
- The vendor's agreement with Microsoft: The vendor should hold its own BAA covering the Azure services it uses to store or process your ePHI. Ask for confirmation that it is in place.
- Subcontractors beyond hosting: Ask for a list of every subcontractor that can access ePHI, including backup, logging, support tooling, email and analytics. Each one should be bound to the same restrictions.
- Services in use: Ask which Azure services the product depends on and whether each is covered under Microsoft's BAA.
- Your own risk analysis: A vendor's audit report or certificate does not replace your obligation to assess the risk of the arrangement.
Before any ePHI moves to the product, request the signed vendor BAA and the current subcontractor list.
If you build software that creates, receives, maintains or transmits ePHI for covered entities or other business associates, you are a business associate in your own right. Your customers need BAAs with you, and you need a BAA with Microsoft for the Azure services you run the product on. Because Microsoft cannot sign your customer-drafted BAAs, the Azure relationship runs on Microsoft's default terms while your customer contracts sit above it.
- Customer BAAs: Each covered entity or business associate customer needs a contract with you that reflects the Security Rule's organizational requirements for business associate arrangements.
- Microsoft's default BAA: You accept Microsoft's BAA as an Azure customer. Do not plan on a bespoke Microsoft contract, since Microsoft says it cannot sign customers' own BAAs.
- Direct liability: Business associates can face direct liability for Security Rule violations under HHS guidance, so your own safeguards and documentation are in scope for regulators.
- Your subcontractors: Your logging, support, monitoring and data tooling vendors that can reach ePHI need BAAs with you before they touch it.
- Encryption does not end the analysis: Holding only encrypted data without the key does not remove your status as a business associate.
Before accepting a customer BAA, map each contractual promise to the Azure services and subcontractors that deliver it.
Why your Azure configuration changes your risk analysis
Signing Microsoft's BAA does not replace your own risk analysis. Each business associate must perform its own, and OCR's cloud guidance states that the cloud configuration you use affects the risk analysis and risk management plans of all parties. Two organizations on Azure can hold the same BAA and face very different risks, because the risk depends on what they built, which services they turned on and how they configured them. Treat the BAA as the contract that allocates responsibility, and the risk analysis as the document that shows how you are managing the parts that stay with you.
A useful Azure risk analysis starts with an inventory of where ePHI is stored, processed and transmitted. For each workload, record the subscriptions and management groups that hold it, the regions where data is stored or replicated, the services that touch it (storage, databases, analytics, messaging, backup and logging), and every path in or out, including private endpoints, public endpoints, VPN or ExpressRoute links and integrations with other SaaS products. Ask your engineering team to confirm which services are covered by Microsoft's HIPAA offering for your configuration, since eligibility is a service-level question. Logs and backups often hold ePHI too, so they belong in the map.
OCR's HIPAA audit program treats risk analysis as one of the first things it requests, so an incomplete inventory is a visible gap. The proposed Security Rule revision published at 90 FR 898 would make risk analysis more prescriptive, and it would require covered entities and business associates to maintain a more detailed technology asset inventory and network map. That rule has not been finalized, so confirm its current status before you plan around specific requirements, but the inventory work you do now is useful under either version. Assign an owner to update the map whenever a subscription, region or service changes.
What Microsoft's mapped frameworks prove and what they do not
Microsoft points to several third-party frameworks and its own mapping as relevant to HIPAA requirements. Each one tests a different layer of the provider's environment, and none of them transfers your Security Rule obligations to Microsoft.
Azure and Azure Government FedRAMP High
FedRAMP High is a US federal authorization that assesses Microsoft's cloud infrastructure and operations against a defined control baseline. It shows that the provider's own controls were tested by an independent assessor, which supports the platform layer of your due diligence. It does not assess your tenant configuration, your applications, your staff training or your risk analysis. Confirm which services sit inside the authorization boundary before you place ePHI in them.
ISO/IEC 27001 certification
ISO/IEC 27001 is an information security management system certification issued by an accredited certification body after it audits Microsoft's management system and its stated scope. It evidences that Microsoft runs a documented security program for the scoped services. It says nothing about whether your ePHI workflows, access reviews or risk analysis meet the Security Rule. Ask for the current certificate and its scope statement, then confirm that the services you use fall within that scope.
Microsoft's HIPAA control mapping
Microsoft's published mapping relates its platform controls and certifications to HIPAA requirements, which helps you locate provider-side evidence for specific safeguards. The mapping is a reference and carries no attestation of your compliance. It does not show how you configured your services, and it does not cover administrative safeguards that stay with your organization, such as workforce training and designating a security official. Confirm the current version on Microsoft Learn before you cite it in your risk analysis.
HHS does not recognize private certifications
HHS states that no Security Rule standard requires certification, and it does not endorse or recognize private organizations' certifications for Security Rule purposes. A certification also does not prevent HHS from later finding a violation. For Azure, none of the three items above closes your obligation. Your duties as a covered entity or business associate stay with your organization, and your own risk analysis is the document OCR asks for first.
How to prepare an Azure HIPAA environment for assessment
This sequence takes an organization from accepting Microsoft's BAA to a body of evidence an independent assessor can test, with each step tied to a named output and an accountable role. It shows where Microsoft's responsibilities end and where the organization's own HIPAA program begins.
Confirm the BAA is in force for your subscriptions
Microsoft includes its HIPAA BAA in the Microsoft Product Terms and Data Protection Addendum, so no separate contract is signed with Microsoft. Your compliance lead or legal counsel should confirm that the agreement applies to the tenant and subscriptions that will hold ePHI, and that the signing administrator has the authority to accept it on behalf of the organization. The output is a signed-off BAA record that names the in-scope subscriptions and the date of acceptance, filed with your contract register. Ask Microsoft or your account team to confirm the current terms in writing, because the contractual text governs and this page does not replace it.
Map which services will hold ePHI
Before any workload is deployed, the security official and the architecture team list every Azure service that will create, receive, maintain or transmit ePHI, including backups, logs, analytics and support tooling. Each service is checked against Microsoft's current HIPAA covered services list, and anything outside that list is either excluded from the ePHI boundary or escalated for a decision. The output is a data map that names each service, the ePHI data types it touches, the region and the owner. Confirm the list with Microsoft's published documentation at the time of scoping, since service coverage changes.
Define the shared responsibility boundary
Microsoft secures the underlying cloud platform and its covered services, but it does not inspect or approve your applications, and your organization remains responsible for its own compliance program. The compliance lead and platform engineering agree in writing which safeguards Microsoft operates, which the organization configures, and which it runs as process, such as workforce training, sanctions and contingency planning. The output is a responsibility matrix that maps each Security Rule standard to a responsible party. Treat any gap between the matrix and the Microsoft documentation as an open item before moving on.
Complete the risk analysis and risk management plan
Each business associate, and each covered entity, must perform its own risk analysis, and OCR's cloud guidance notes that the cloud configuration affects the analysis for every party. The security official, with system owners and an independent reviewer where the organization has one, identifies threats and vulnerabilities to the mapped ePHI, rates them, and records decisions in a risk management plan. The output is a dated risk register with owners, treatment decisions and review dates. The analysis should be repeated when the architecture or the data map changes, so ask your partner how the register will be kept current after go-live.
Build and lock the configuration baseline
Engineers translate the risk decisions into configuration: identity and multi-factor authentication, role-based access, network segmentation, encryption at rest and in transit with managed keys, logging and monitoring, backup and recovery, and vulnerability management. Each setting is recorded in infrastructure as code so the state is reproducible and changes are versioned. The output is a configuration baseline with a reference to the template or policy that enforces each setting. Its closing check is a drift scan showing the deployed environment matches the baseline.
Write policies and collect operating evidence
Procedures for workforce access, incident response, contingency planning, device and media handling and business associate management must exist in writing and be followed in practice. The security official runs the controls for a defined period, and the team collects logs, access reviews, training records, change tickets, backup restore tests and incident drills. The output is an evidence pack indexed to each Security Rule specification, showing what was done, by whom and when. Assessors test operation over time, so gaps in the evidence period are usually the first thing to close.
Engage an independent assessor
The organization, not the implementation partner or Microsoft, selects the independent assessor who will test the environment and the program. The assessor reviews the BAA record, data map, risk register, baseline and evidence pack, then samples controls and tests them. The output is the assessor's own report, which only that independent party can issue. Ask prospective assessors for their scope, method and deliverables in a written, scoped quote, and ask for a timeline there rather than relying on general estimates. HIPAA has no certification, so a report should be read as a point-in-time assessment of specific controls.
Who does which Azure HIPAA task: in-house, partner or assessor
This table splits the core Azure HIPAA tasks among your own team, an implementation partner and an independent assessor. Read each row as a question of who owns the decision, who prepares the work and what an outside test can actually show. The main takeaway is that Microsoft's BAA covers its service commitments only, so the safeguards, configuration and documented risk analysis for your ePHI workloads stay with you.
| Task | Owned by | Typical partner role | What the assessor can and cannot show |
|---|---|---|---|
| Signing and tracking the Microsoft BAA | Your legal and compliance team, which accepts the terms in your Microsoft agreement | Confirms the BAA applies to your subscriptions and maps which services you use | Can confirm the BAA exists and is in force; cannot judge whether your contract terms are sufficient for your own obligations |
| Confirming services are covered | Your architecture owner, checked against Microsoft's current covered services list | Inventories resources and flags any service outside the covered list before ePHI reaches it | Can test a sample of resources against the list; cannot approve future services Microsoft adds or removes |
| Azure landing zone and network design | Your cloud platform team | Prepares the landing zone configuration, segmentation, private endpoints and encryption settings as written decisions | Can test whether configured controls match your stated design; cannot choose the design for you |
| Access control, identity and MFA | Your identity owners and security team | Implements role assignments, conditional access and MFA settings and documents them | Can sample accounts and privileges and check configuration; cannot prove no unauthorized access occurred without logs |
| Audit logging and monitoring | Your security operations team | Configures diagnostic settings, log retention and alert routing into a log store you control | Can verify logging is enabled and retained as documented; cannot review logs for threats it was not engaged to analyze |
| Enterprise risk analysis and risk management plan | Your security official and leadership, who sign off on decisions | Gathers Azure-specific inputs, maps where ePHI lives and drafts the plan for review | Can review whether the analysis is reasonable and complete; cannot perform or own your risk analysis |
| Policies, workforce training and incident response | Your privacy and security officials, with HR | Drafts Azure-specific procedures and runbooks for your review | Can check that written procedures exist and match practice; cannot make them effective for your workforce |
| Evidence collection and documentation | Your compliance lead, who keeps records current | Automates evidence capture and organizes it for review | Can test samples of evidence; cannot certify compliance, since HHS does not recognize private certifications |
Mistakes that leave Azure ePHI workloads outside the BAA
Most Azure HIPAA gaps come from assumptions rather than bad configuration: that the BAA covers everything in the account, that ePHI stays inside the systems the BAA names, and that vendors and Microsoft's own certifications settle questions that remain the customer's to answer. Each card below names one of these errors and the check that closes it.
Assuming the BAA covers every service
Microsoft's BAA applies to the Azure services it lists as in scope for HIPAA, not to every product in the portal. A workload that stores or processes ePHI in an unlisted service is outside the agreement even though the same subscription is covered. Before any ePHI moves, check the current covered-services list in Microsoft's HIPAA documentation and record which services your architecture uses, so the list can be matched against the design during your risk analysis.
Placing ePHI in previews or non-covered services
Preview features and services outside the covered list are a common route for ePHI to reach an environment without a BAA. A developer testing a new analytics feature with a patient extract can create exposure in minutes. Set an Azure Policy or governance rule that blocks unapproved services in subscriptions that hold ePHI, and require a written review before any preview is used with production data.
Missing ePHI in logs and backups
ePHI often reaches places no one designed for it: diagnostic logs, application traces, exported reports, storage snapshots and backup copies. Each of these is ePHI and must sit inside covered services, be protected, and be included in the risk analysis. Inventory where diagnostic settings, backup vaults and snapshots send data, and confirm each destination is in scope before turning logging on.
Leaving dev and test subscriptions unchecked
Non-production subscriptions are often built by copying production data or configuration, which brings ePHI into environments with looser access and fewer controls. The Security Rule applies wherever ePHI is created, received, maintained or transmitted, not only in production. Either keep real ePHI out of non-production subscriptions through de-identified or synthetic data, or bring those subscriptions under the same covered-service, access and audit controls.
Skipping SaaS vendors' BAAs
Microsoft says healthcare SaaS customers sign BAAs with the SaaS provider, not with Microsoft. A clinical app, transcription tool or analytics product running on Azure and handling ePHI needs its own signed agreement with its vendor, regardless of what Azure covers. Ask each SaaS vendor for its signed BAA and its subcontractor list, and confirm that vendor's own hosting is covered before go-live.
Treating Microsoft's certifications as your compliance
Microsoft maps its FedRAMP High and ISO/IEC 27001 certifications to HIPAA requirements, but these describe Microsoft's services, not your application, configuration or program. HHS does not recognize private certifications for the Security Rule, and there is no HIPAA certification for a cloud provider. Use Microsoft's documentation as inherited evidence for the provider's controls, then document your own risk analysis, access decisions and safeguards.
Questions buyers ask about HIPAA on Azure
Will Microsoft sign our own business associate agreement for Azure?
No. Microsoft says it cannot sign customers' own BAAs because its multi-tenant services run the same way for every customer. Instead, the HIPAA BAA is offered by default through the Microsoft Product Terms and Data Protection Addendum, so covered entities and business associates accept it without a separate contract. Your legal team should read that terms set against your own requirements, such as breach notification timing and subcontractor flow-down, and confirm in writing any gaps they find. The BAA is the starting point for the contract, not the end of the review.
Is Azure HIPAA certified?
No. There is no HHS-approved certification program for cloud providers acting as business associates, and HHS does not endorse or recognize private certifications for the Security Rule. Microsoft points to Azure and Azure Government FedRAMP High authorizations and ISO/IEC 27001 certification as frameworks mapped to HIPAA requirements. Those reports support your risk analysis, but they do not show that your workloads are compliant. Ask Microsoft for the current audit reports through its compliance resources, and ask your own independent assessor what they will accept as evidence.
What must we do beyond accepting the Azure BAA?
Accepting the BAA makes Microsoft a business associate for the services in scope. It does not configure anything. Your organization still owns its risk analysis, risk management plan, access control, encryption choices, audit logging, backup and recovery, workforce training, incident response and the policies that tie them together. Each business associate must perform its own risk analysis, and OCR's cloud guidance says the configuration you choose changes the risk picture for every party. Your team must also confirm which Azure services hold ePHI and that each one is covered by the BAA before you store data in it.
Does a healthcare SaaS product running on Azure need its own BAA?
Usually yes, with the SaaS provider, not with Microsoft. Microsoft states that healthcare SaaS customers sign BAAs with the SaaS vendor, which in turn has its own BAA with Microsoft for the Azure services it uses. When your organization buys a SaaS product that creates, receives, maintains or transmits ePHI, the vendor is a business associate and you need a BAA with that vendor. Ask the vendor to show its Azure BAA coverage, its subcontractor list and how its own risk analysis covers the Azure configuration it runs.
How much effort and time will the HIPAA work take our team?
The effort depends mainly on how many systems hold ePHI, how much of the environment is already documented, and how much your team has to build from scratch. The main drivers are the size of your Azure footprint, the number of integrations with clinical or billing systems, the state of identity and logging, and the policies that must be written or updated. Ask any consultant or implementation partner for a written scope that lists systems, deliverables, responsibilities and dependencies before agreeing a timeline. No general duration applies, so treat any figure you are quoted as something to test against your own inventory.
Can an implementation partner make our Azure environment HIPAA compliant?
No partner can make you compliant on its own, and none can issue a HIPAA certificate. An implementation partner such as DeployOpen can plan, configure, harden and document your self-hosted open-source platforms in your own cloud accounts, and prepare the controls and evidence an assessment will examine. Your organization still owns the controls, the risk decisions and the policies. Only an independent assessor can report on your compliance, so confirm early which assessor your organization will use and what evidence they expect to review.
Should a HIPAA assessor review our Azure setup before go-live?
A pre-go-live review is worth considering, because the configuration of your Azure environment changes the risk analysis for all parties. An independent assessor can test whether your controls match what your risk analysis says they do, which is a different question from whether Azure itself is compliant. Ask the assessor what they will test, what reports they will issue and whether they will use HHS and NIST SP 800-66 Rev. 2 as reference points. Any report comes from the assessor, not from Microsoft or from your implementation partner.
How DeployOpen prepares Azure ePHI environments for assessment
DeployOpen prepares the systems, configuration and evidence that an ePHI environment on Microsoft Azure needs before an independent assessment. Microsoft's BAA sets the contract, but the safeguards, risk analysis and documentation sit with your organization, and DeployOpen works on those parts within a written scope.
How we scope
- We agree the Azure subscriptions, workloads and ePHI data flows in writing before work starts.
- Scope defines which Azure services hold or transmit ePHI and which fall outside the HIPAA-covered service list.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work begins.
- We confirm which SaaS partners hold their own BAAs with your organization, so the scope does not assume Microsoft covers them.
How we build
- We configure Azure environments within your own subscriptions to match the safeguards your risk analysis calls for.
- Build work covers access control, logging, encryption, key management and backup settings, documented as configured.
- Where your architecture uses SaaS applications, we integrate them into the same identity, logging and access model.
- Security testing of applications, APIs and cloud configuration can be included to check the build before handover.
How we hand over
- You receive configuration records, architecture diagrams and a map of where ePHI is stored and processed.
- Documentation ties each configured safeguard to the Security Rule standard it supports, so an assessor can trace evidence.
- Policies and procedures are delivered as drafts for your security official and leadership to review and adopt.
- We agree handover acceptance criteria in writing, and your team operates the environment after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover configuration drift checks, evidence refreshes and updates when Azure services or your workloads change.
- Assessments are run by an independent auditor or assessor. DeployOpen prepares evidence but does not issue reports or attestations.
- Ask any provider to confirm in writing which HIPAA attestations or reports they can provide, and which they cannot.
