HIPAA Cloud Storage Vendor Checklist

Cloud storage looks like a commodity. From a HIPAA standpoint, it is not. Two clinics using the same vendor logo can have very different compliance postures depending on which tier they bought, which service they enabled, and whether the BAA was actually executed.

This is a checklist for practice administrators evaluating cloud storage vendors before any PHI lands there. It does not replace a security risk analysis under 45 CFR § 164.308(a)(1), but it covers the questions you should be able to answer before that analysis even begins.

Why this vendor category needs HIPAA review

Cloud storage is one of the most common places PHI ends up: scanned intake forms, exported EHR reports, imaging studies, billing spreadsheets, signed authorizations. Once PHI is in the bucket, the vendor is a business associate under 45 CFR § 160.103, and your clinic is responsible for the chain of custody.

HHS guidance on cloud computing closed the door on a few common arguments. The provider is a business associate even if the data is encrypted with keys the provider does not hold. The provider is a business associate even if it does not view the contents. Mere storage of PHI on behalf of a covered entity is enough to require a BAA.

That makes vendor selection a compliance decision, not just an IT one.

Required BAA terms for cloud storage

Per 45 CFR § 164.504(e), every BAA needs to spell out:

• Permitted and required uses and disclosures of PHI
• Appropriate safeguards to prevent unauthorized use or disclosure
• Reporting of security incidents and breaches
• Subcontractor flow-down: any subcontractor handling PHI must agree in writing to the same restrictions
• Return or destruction of PHI at termination, where feasible
• Books and records access for HHS

For cloud storage specifically, look for explicit language on which services are in scope, on encryption obligations, and on who controls the keys. A BAA that says “Vendor will implement appropriate safeguards” without naming the products is too thin to rely on.

Specific risks for cloud storage vendors

Three risks recur with cloud storage:

1. Service scope mismatch. The BAA covers object storage but the team has started using a new analytics service that is not HIPAA-eligible.
2. Tier mismatch. Someone signs up for a free or personal tier “to test something” and PHI gets uploaded before the BAA-eligible tier is provisioned.
3. Subprocessor sprawl. The vendor uses a CDN, a search index, or a backup vendor that is not on the published subprocessor list, and PHI flows there without a flow-down BAA.

A 2025 OCR enforcement settlement involved a covered entity that left an unsecured cloud storage bucket exposed to the public internet for over a year. The lesson is not that cloud storage is risky in the abstract — it is that misconfiguration plus weak access logging plus no BAA is a compounding failure.

Evaluation checklist

Walk through every question before you send PHI to a cloud storage vendor. If you cannot answer “yes” or “documented,” do not migrate.

1. Is there a signed BAA in place, dated and countersigned by both parties?
2. Does the BAA explicitly name the services we plan to use (for example, S3, Blob Storage, Cloud Storage, Box Enterprise, Dropbox Business Advanced)?
3. Is encryption at rest enabled with a documented key management approach (KMS, customer-managed keys, or BYOK)?
4. Is TLS 1.2 or higher enforced in transit, with weak ciphers disabled?
5. Are detailed access logs available (object reads, writes, deletes, permission changes), and how long are they retained?
6. Can we restrict which geographic regions store the data and the backups?
7. Is there a published list of subprocessors that may touch PHI, and does the vendor commit to BAA flow-down?
8. Does the vendor commit to breach notification within a defined timeframe, and what triggers it?
9. Are public-access defaults disabled, and is there guardrail tooling (block public access, sensitive data scanners) we should turn on?
10. Are MFA and SSO available, and can we enforce them for all users with PHI access?
11. What is the vendor’s data residency policy for support engineers — can offshore support staff view our data, and under what controls?
12. Does the vendor support immutable backups or object lock for ransomware protection?
13. What is the documented process for return or destruction of PHI at termination, and what proof is provided?
14. Has the vendor produced a recent SOC 2 Type II or HITRUST report we can review?

If you sell or support multi-tenant SaaS yourself, add a fifteenth: confirm the vendor’s tenant isolation model.

Common mistakes

• Treating “HIPAA compliant” marketing copy as a BAA. A landing page is not a contract. Ask for the actual BAA, signed.
• Assuming encryption is automatic. On most cloud platforms encryption at rest is the default, but key rotation, customer-managed keys, and bucket-level enforcement are not. Check.
• Skipping the subprocessor list. If the vendor uses a third-party CDN, image processor, or analytics service that touches PHI, that vendor needs a flow-down BAA. The minimum necessary standard does not stop at your direct vendor.
• Using consumer tiers. Personal Google Drive, Dropbox Basic, free Box accounts. None of these come with a BAA. Migrate to a business tier with a signed BAA before PHI moves.
• Forgetting termination. When the contract ends, where does the data go? A BAA without a clear destruction or return clause leaves PHI in limbo.

For a deeper walk-through of when a vendor crosses into business-associate territory, see when a vendor needs a BAA. For the broader vendor program, the vendor management hub collects the checklists, BAA templates, and review cadences. If you want a HIPAA-native task system to track all of this in one place, PHIGuard is built for it.