HIPAA-compliant hosting: what a hosting provider must sign

What makes a HIPAA-compliant hosting arrangement

If a customer, contract or internal decision now requires you to host electronic protected health information (ePHI), start with two facts. A hosting provider that creates, receives, maintains or transmits ePHI for you is a business associate, and it must sign a business associate agreement (BAA) with you. No HIPAA certification exists that proves a provider is compliant, so any vendor claiming one is offering a marketing label, not evidence. Under OCR's cloud guidance, this holds even when the provider stores only encrypted ePHI and never holds the key. Your first task is therefore contractual and factual: confirm the provider will sign a BAA, and confirm which of its services fall under that BAA.

The BAA does not transfer your obligations. OCR's cloud guidance says the customer and the cloud provider must both sign a HIPAA-compliant BAA, and that the provider is contractually liable under it and directly liable under the HIPAA Rules. Each business associate must still perform its own risk analysis, and the cloud configuration you choose affects the risk analysis and risk management plans of every party. Your controls stay yours: who gets access, how workforce accounts are managed, how audit logs are reviewed, and how incidents are handled inside your environment. The provider's duties sit alongside them, not in place of them.

Before signing, check the service level agreement against the topics OCR lists: availability and reliability, backup and data recovery, how data is returned after termination, security responsibility, and use, retention and disclosure limits. Ask the provider to show, in writing, which party handles each item. Also confirm the contract requires the provider to report security incidents it becomes aware of to you, including breaches of unsecured PHI, as the Security Rule requires of business associate contracts. Those reporting clocks drive your own notification duties, so agree them before you need them.

What a hosting provider must sign and do

A hosting provider that stores, processes or transmits ePHI for a covered entity or business associate takes on business associate duties, whatever the encryption arrangement. The cards below cover the contract, the liability, the risk analysis, the incident reporting and the downstream flow-down that a buyer should verify before signing.

Sign a HIPAA-compliant BAA

A cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is a business associate, even if it stores only encrypted ePHI and holds no key. OCR's cloud guidance says the customer and the provider must sign a HIPAA-compliant business associate agreement before ePHI is hosted. Check who the contracting party is, whether the agreement covers the specific services you will use, and whether a SaaS vendor on top of the host has its own BAA with you.

Accept direct liability under the Rules

A business associate is directly liable under the HIPAA Rules, not only contractually liable under its BAA. That means HHS can investigate and penalize the host itself for Security Rule failures. Buyers should not treat the BAA as the only lever for accountability, and should confirm which safeguards the provider is responsible for in its own environment.

Perform its own risk analysis

Each business associate must perform its own risk analysis, and the cloud configuration chosen affects the risk analysis and risk management plans of every party. A provider cannot rely on the customer's analysis to cover its own facilities, staff and platform. Ask for a summary of the provider's risk analysis scope, its update cadence, and how it maps the shared configuration to each side's responsibilities.

Report security incidents to the covered entity

Business associate contracts must require the associate to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI. The contract should name the reporting window, the content of the notice and the contact path, not leave them to the provider's standard practice. Confirm how the provider detects incidents in its own platform and how it hands off logs and findings to your incident response team.

Flow duties down to subcontractors

A business associate that uses subcontractors to create, receive, maintain or transmit ePHI must hold them to the same restrictions and safeguards through their own written agreements. For hosting, this covers data center operators, managed service firms and backup vendors. Ask the provider for its list of subcontractors that touch ePHI and confirm that each one is bound by an agreement that meets the same standard.

Define recovery and data return terms

OCR's cloud guidance lists service level agreement topics relevant to HIPAA: availability and reliability, backup and data recovery, how data is returned after termination, security responsibility, and use, retention and disclosure limits. Put each topic in writing with measurable terms. Confirm the provider's backup scope, recovery commitments and the format and timing of data return or deletion at contract end.

Why encrypted data does not remove the provider from HIPAA

A cloud provider that stores only encrypted ePHI, without holding the encryption key, is still a business associate. OCR's cloud guidance is explicit that a cloud service provider which creates, receives, maintains or transmits ePHI for a covered entity or business associate takes on that status, even when it cannot read the data. Buyers who assume that encryption moves the obligation off the hosting provider are working from a misreading, and the mistake usually surfaces late, during contract review or an assessment, when the gap is expensive to close.

The practical consequence is that the provider carries obligations you can test. Under OCR's guidance, the customer and the provider must sign a HIPAA-compliant business associate agreement, and the provider is both contractually liable under it and directly liable under the HIPAA Rules. Encryption does not change that analysis. It is a safeguard the provider and customer may both rely on, but it does not replace the agreement, the provider's own risk analysis or its duty to report security incidents to you. Under 45 CFR 164.314(a)(2)(i)(C), the business associate contract must require the provider to report security incidents it becomes aware of, including breaches of unsecured PHI. Note that the duty attaches to unsecured PHI, so the encryption design you choose determines which events trigger breach analysis.

Before you rely on any hosting arrangement, ask the provider to confirm its role in writing: that it is a business associate for the ePHI in the service, whether it can access keys or plaintext, which party manages key custody, and which BAA version applies. Confirm with your own counsel that the BAA terms match this description, and record the answers in your vendor file. Your organization still owns its risk analysis and the safeguards that depend on your configuration, because OCR's guidance says the cloud configuration affects the risk analysis of all parties.

Which SLA terms OCR says matter for ePHI

OCR's cloud guidance names five service level agreement topics that bear directly on ePHI. Each card below sets out what the buyer should have the provider define in writing before any PHI is loaded, because a general uptime promise does not answer these questions.

Availability and reliability

The SLA should state the availability the provider commits to, how it is measured, how outages are reported to you, and what credits or remedies apply when it is missed. For ePHI, ask how a prolonged outage affects clinical access and whether the provider's own dependencies are covered. Confirm the measurement window and exclusions in writing, since these decide whether the commitment means anything in practice.

Backup and data recovery

Ask the provider to define what is backed up, how often, where copies are stored, how long they are kept, and how quickly data can be restored. Your contingency plan depends on these answers, so the SLA should state recovery expectations rather than leaving them to the provider's default settings. Confirm whether backups are encrypted and whether restoration tests are performed and reported to you.

Return of data after termination

The SLA should describe how ePHI is returned to you at the end of the contract, in what format, within what period, and how the provider then deletes its copies, including backups. Without this, PHI can remain with a former vendor long after the relationship ends. Ask for written confirmation of deletion and how it is certified.

Security responsibility

Define in writing which safeguards the provider operates and which remain with you, such as identity management, configuration, encryption key handling and workforce access. OCR says the cloud configuration you choose affects the risk analysis of every party, so a shared responsibility matrix tied to your deployment is the document to request. Ask how the provider reports security incidents affecting your ePHI.

Use, retention and disclosure limits

The contract should limit how the provider may use, retain and disclose ePHI, which should be only what the business associate agreement permits. Ask whether the provider uses customer data for product development, analytics or model training, where data is stored geographically, and which third parties are subcontractors. Each subcontractor that touches ePHI must also be bound to equivalent terms.

Who owns which safeguards in a hosted ePHI system

A covered entity remains responsible for the Security Rule obligations that attach to its own operations, even when a business associate hosts or processes its ePHI. Hosting does not move the duty to perform the risk analysis, appoint a security official, train the workforce or decide which vendors receive PHI. The covered entity's job is to choose business associates with care, put the required terms in writing and check that those terms are being met.

Vendor selection and due diligence: Confirm that each hosting provider or SaaS partner will sign a business associate agreement before any ePHI moves, and document why the vendor was chosen.
Contract terms: Make sure the BAA requires the business associate to report security incidents it becomes aware of, including breaches of unsecured PHI, as 45 CFR 164.314(a)(2)(i)(C) requires.
Own risk analysis: Include every hosted system, data flow and vendor in the covered entity's risk analysis and risk management plan.
Workforce and access: Control which staff can administer the application, approve access requests and remove access when roles change.
Monitoring the relationship: Review the provider's audit reports, incident notices and SLA performance on a schedule the entity sets.

Before signing, ask which obligations the vendor's BAA and SLA assign to it, and which the entity must perform itself.

How to vet a hosting provider before signing

This sequence turns a hosting provider's HIPAA claims into written artifacts you keep: a signed business associate agreement, a service-level comparison against OCR's cloud topics, the provider's account of its own risk analysis, a confirmed list of covered services and an agreed incident notice path. Each step closes with a document you can show an auditor or regulator.

Request and review the business associate agreement
Ask the provider for its business associate agreement before you move any ePHI, and have your privacy or legal lead review it. Under OCR's cloud guidance, the customer and the cloud provider must sign a HIPAA-compliant business associate agreement, and the provider is contractually liable under it and directly liable under the HIPAA Rules. Check that the agreement requires the provider to report security incidents it becomes aware of, including breaches of unsecured PHI, as the Security Rule requires for business associate contracts. Confirm how the provider handles subcontractors that touch ePHI, including whether they must sign equivalent terms. You are done when you hold a countersigned copy with the breach reporting and subcontractor clauses marked for your file.
Confirm which services the agreement covers
Get a written list of the services the business associate agreement covers and compare it against the services your architecture will use. Coverage is often limited to named services or regions, and a service outside that list can put ePHI outside the agreement even when the parent account is covered. Ask the provider how it expects customers to keep ePHI within covered services and how it notifies customers when the covered list changes. Where you are a SaaS company passing ePHI through a hosting provider, confirm whether your own customers sign their agreement with you or with the provider. You are done when you hold a dated list of covered services that matches your data flow diagram.
Read the service level agreement against OCR's topics
Read the service level agreement alongside the business associate agreement and check it against the topics OCR's cloud guidance lists: availability and reliability, backup and data recovery, how data is returned after termination, security responsibility, and use, retention and disclosure limits. Mark any topic the agreement leaves silent and ask the provider to address it in writing. Pay close attention to who is responsible for which security controls, because the split decides which safeguards you must evidence yourself. You are done when you hold a marked-up copy of the service level agreement with each OCR topic mapped to a clause or to a written provider answer.
Request the provider's account of its risk analysis
Ask the provider for a written summary of its own Security Rule risk analysis and risk management approach, since each business associate must perform its own risk analysis. OCR's cloud guidance notes that the cloud configuration used affects the risk analysis and risk management plans of all parties, so ask how the provider's findings apply to your configuration. Request evidence of the scope and date of its most recent review and how it treats the controls it has told you it owns. Expect the provider to share a summary, not its full internal analysis, and ask for that limitation in writing. You are done when you hold the summary, a list of the controls the provider says it owns, and a record of which of your own risk analysis items depend on the provider's answers.
Map your own safeguards to the shared responsibility split
Using the written artifacts from the earlier steps, draft a responsibility matrix that assigns each Security Rule safeguard to the provider, to you, or to both. Cover access control, unique user identification, audit logging, encryption and key management, backup testing and workforce training at minimum. The matrix is an internal planning document, so ask the provider to confirm each row in writing where it claims a responsibility. Note that no certification will settle these assignments, so the matrix is your evidence of how you reasoned about them. You are done when the matrix is signed off by your security official and each shared row has a provider confirmation attached.
Agree incident notification timing and contacts
Turn the breach reporting clause into an operating procedure. Agree in writing how and when the provider notifies you of a security incident, who receives the notice on each side, and how the provider will share the information you need for your own breach risk assessment. The Security Rule requires business associate contracts to address reporting of security incidents, so the agreed mechanism should be documented in the agreement or an addendum signed by both parties. Test the path with a tabletop exercise before go-live if you can. You are done when you hold a signed notification addendum or schedule with named contacts and a tested escalation path.
Record the decision and set a review point
Assemble the artifacts into a single vendor file: the countersigned business associate agreement, the covered services list, the marked service level agreement, the provider risk analysis summary, the responsibility matrix and the notification addendum. Record who approved the decision and on what date, and note any gaps you accepted with a documented reason. Because the proposed Security Rule revision was published in January 2025 and no final rule has been issued, schedule a review of the file against any final rule and against changes in the provider's services. Keep the file where your auditor and OCR could ask for it. You are done when the vendor file is complete, approved and filed.

Why HIPAA-certified hosting does not exist

No HIPAA certification exists for hosting providers, and no Security Rule standard requires any organization to certify compliance. HHS states that it does not endorse or recognize private organizations' certifications, and that a certificate does not stop HHS from later finding a violation. So when a hosting vendor advertises HIPAA certification, treat the claim as a prompt for questions, not as evidence. Ask the vendor what body issued the certificate, what was assessed, against which criteria, over what period, and whether the scope covers the specific service you would buy. Confirm in writing what the vendor means by the term, because marketing language often means a self-attestation or a generic security report.

The evidence that actually matters for a hosting arrangement is a signed business associate agreement covering the services you will use, the provider's own risk analysis, and any independent third-party assessment reports the provider holds. The BAA is the contract that makes the provider contractually and directly liable under HIPAA, so it should be reviewed by your legal and compliance staff before any ePHI moves. Ask for the risk analysis summary and the scope of any third-party report, and check whether the report covers the regions, services and data flows you will actually use. Remember that a report describes the provider's controls, while your own configuration and risk analysis still determine your exposure.

Plan for this in procurement. Add a clause requiring the vendor to disclose any certification or attestation it relies on, and to notify you if its scope or status changes. Record the answers in your vendor file alongside the signed BAA. If a vendor cannot produce a signed BAA, or will only describe its security in general terms, treat that as a gap to resolve before go-live rather than a detail to revisit later.

Questions buyers ask about HIPAA hosting

Does a hosting provider need a BAA if the data is encrypted?

Yes. A cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is a business associate, even when it stores only encrypted ePHI and does not hold the encryption key. HHS's cloud computing guidance says the customer and the provider must sign a HIPAA-compliant business associate agreement. Encryption reduces risk and may affect breach analysis, but it does not remove the contract requirement. Confirm with your provider which services process ePHI in your configuration, because that scope determines which terms apply to which data.

Can a cloud or hosting provider be HIPAA certified?

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that a certification does not prevent HHS from later finding a violation. AWS and Microsoft both say no HHS-approved certification program exists for cloud providers acting as business associates. Treat any vendor claiming HIPAA certification as a marketing claim and ask for its signed BAA, its security documentation and the scope of any independent attestation it holds. DeployOpen does not issue audit reports or certificates; independent auditors do.

What must a business associate agreement contain for hosting?

A business associate contract must require the business associate to safeguard ePHI as the Security Rule requires and to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI under 45 CFR 164.410. For hosted systems, OCR's cloud guidance points to service level topics that should also be addressed:

Availability and reliability
Backup and data recovery
How data is returned or deleted after termination
Security responsibilities of each party
Limits on use, retention and disclosure

Review the agreement against these topics and against your own data flows. Have counsel confirm the final wording.

Who performs the HIPAA risk analysis for hosted systems?

Each party performs its own risk analysis. The covered entity must analyze risk for the ePHI it holds, and each business associate must analyze risk for the systems it operates. OCR's cloud guidance adds that the cloud configuration chosen affects the risk analysis and risk management plans of all parties, so a shared-responsibility diagram is not a substitute for either analysis. Ask the provider which controls it operates, which you operate, and how it will share the findings that affect your configuration. Your own analysis should map where ePHI is stored, processed and transmitted, including backups and logs.

Do we need outside help to vet a hosting provider?

Not always, but many organizations use outside help for the parts that need specialist skill. Your team can review the BAA, the provider's shared responsibility documentation, its incident reporting commitments and its SLA terms against the topics OCR lists. An outside consultant or implementation partner can help map data flows, build the configuration evidence and test the controls you own. Outside parties cannot issue a HIPAA certification, and a third-party assessment shows only what it tested at the time. Define in writing what the outside party will deliver before the work starts.

What does the buyer's team have to do for a hosted ePHI system?

The buyer keeps accountability for its own controls, even when a provider runs the infrastructure. Typical work includes:

Executing the BAA and keeping a register of which services hold ePHI
Completing and maintaining the risk analysis and risk management plan
Managing workforce access, multi-factor authentication and audit log review
Writing policies, training staff and maintaining incident response and breach procedures
Testing backups and restoration on a schedule

The effort depends on how many systems, integrations and users touch ePHI. Ask any consultant or partner for a written scope and a quote that separates one-time setup from recurring work.

How much does HIPAA hosting compliance cost?

No supplied figure exists for a specific provider, and hosting fees are not a compliance price. Costs fall into three groups: the provider's service fees, your internal staff time for the BAA, risk analysis and policies, and any outside help you buy. Costs rise with the number of systems holding ePHI, the number of integrations, and the depth of testing and documentation required. Ask providers whether the BAA carries any additional fee, which services are HIPAA-eligible, and what evidence they supply on request. For implementation work, request a fixed-scope quote from DeployOpen based on a written scope. DeployOpen does not publish prices.

How DeployOpen helps prepare a HIPAA hosting arrangement

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. We help you prepare the systems, controls and evidence that a hosting arrangement depends on, while your organization signs the business associate agreement and owns its controls, and any independent assessor issues the reports.

How we scope

Written scope lists which ePHI systems, environments and hosting locations are covered before work starts.
Scope names the provider roles, contracts and business associate agreements your team must obtain and sign.
Scope records the shared responsibility split so each party's safeguards and evidence are assigned in writing.

How we build

We configure the platform and hosting environment to match the safeguards your provider terms describe.
We set up access control, audit logging, encryption and backup settings, then document how each is configured.
We run security testing on the hosted systems and record findings, fixes and retests for your risk analysis.

How we hand over

Handover includes configuration documentation, runbooks and an evidence map linking each safeguard to its artifact.
We document incident and breach reporting paths so your team can meet the timing in your business associate contracts.
Deliverables are listed in the written scope, so you know what you receive and can check it against the agreement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover platform patching, backup restore tests and periodic review of the shared responsibility split.
Confirm with your legal and compliance teams which provider terms apply before relying on any hosting arrangement.

HIPAA-compliant hosting: what a hosting provider must sign and do