Cloud Shared Responsibility for HIPAA: A Practical Map

Short answer: Cloud shared responsibility for HIPAA means the provider and customer each own different safeguards, evidence, and decisions. The provider may operate infrastructure and sign a BAA for a defined service boundary. The customer still owns application authorization, tenant isolation, data minimization, identities, configuration, logs, backups, incidents, and risk analysis. As of August 15, 2026, map both sides before storing protected data.

Vendor scope and BAA boundary

HHS cloud guidance explains that a cloud service can be a business associate when it handles protected health information for a covered entity or business associate, and that a BAA is required for the relationship. The agreement defines duties for a service boundary. HHS’s Security Rule material supplies the current safeguard context. Neither source says that cloud use transfers every obligation to the provider.

Write the boundary in plain language: provider operates named infrastructure and services; customer controls named applications, identities, fields, configurations, and processes; both coordinate on incidents, vulnerabilities, and evidence. Then test that statement against the real architecture. If an external database, analytics tool, support system, or backup receives data, add it to the matrix.

Use the source baseline retrieved August 15, 2026. Provider scope, feature eligibility, pricing, regions, and support terms are volatile. Keep an as-of date on every commercial or service claim.

Feature, region, and subprocessor review

Control area	Provider may own	Customer must prove
Infrastructure	Facilities, hardware, base service operations	Correct service, account, region, and configuration.
Identity	Identity service capabilities	Unique users, MFA, roles, termination, least privilege.
Data	Service encryption options and durability	Fields, tenant checks, retention, keys, backups, deletion.
Logging	Log service availability	Events, redaction, access, retention, alert response.
Operations	Provider incident process and notices	Customer incident runbook, restore, training, evidence.

Regions need the same split. A provider can expose a region selection while backups, support, control-plane metadata, keys, logs, or subprocessors follow separate paths. Map each location and remote access. If EU or Brazil data is involved, review the applicable transfer mechanism with counsel. A database region alone is not a complete residency solution.

For Google Ads, use only generic conversion data after tenant-specific legal approval. Never send patient name, email, phone, hashed identifiers, service or treatment details, or clinical text. Keep the outbound event off by default. Cloud responsibility does not answer platform policy or state-law questions.

Use the cloud BAA checklist, the subprocessor inventory, and the AWS eligibility checklist to apply the matrix.

Application, identity, and data controls

The customer application is usually where cross-tenant and minimum necessary failures occur. Enforce membership on the server, not from a browser-supplied tenant or region value. Review every query, background job, export, search, report, support view, and administrative route. Test the wrong-tenant request as intentionally as the successful request.

• Identity: unique accounts, MFA, least privilege, access reviews, and timely termination.
• Data: minimum fields, encrypted storage and transport, safe backups, deletion, and retention.
• Logging: structured outcomes and opaque IDs, not full request bodies or free text.
• Support: time-bound approval, audited reveals, and break-glass review.
• Deployment: reviewed changes, rollback, secrets management, and synthetic test evidence.

NIST SP 800-53 can help organize controls and evidence. It does not replace the HIPAA risk analysis or make an application certified. A provider BAA is one artifact among many.

Exit, support, and evidence questions

Build a responsibility matrix that includes proof, not only a checkbox. For each row, record owner, implementation, configuration, test, evidence location, review date, and failure action. Ask the provider how it supplies incident notices, audit information, support records, and return or destruction evidence.

Test	Expected result	Stop condition
Access denial	Wrong tenant and unapproved role receive no record.	Client input or shared account bypasses checks.
Log redaction	Representative requests contain no full payload.	Debug or error tool stores sensitive fields.
Restore	Backup restores to approved region and role boundary.	Restore creates unknown copies.
Support	Access is approved, time-bound, and audited.	Provider or customer support is invisible.
Exit	Export, revoke, delete, and verify work.	Logs, backups, or keys are omitted.

Escalate when the provider cannot document scope, when a feature is outside the agreement, when support crosses a jurisdiction, when the customer cannot operate a control, or when a legal disclosure is proposed. Keep the route disabled until the issue is resolved.

Comparison decision checklist

1. Map data, services, regions, identities, keys, logs, backups, support, and subprocessors.
2. Read current BAA and provider documentation for each service.
3. Assign provider, customer, and shared controls.
4. Attach configuration and test evidence.
5. Run access, redaction, restore, incident, support, and exit exercises.
6. Review after material feature, provider, region, contract, or incident change.

Stop when a provider document is being used as customer evidence. Shared responsibility is complete only when both sides’ controls and proof are visible.

Turn the map into a control contract

For every control, write four fields: owner, implementation, evidence, and failure action. “Provider” is not enough. Name the service or team, the configuration, the test or report, and what happens when it fails. For example, the provider may operate a log service, while the customer configures which events are enabled, redacts payloads, restricts readers, and reviews alerts.

Review boundaries at interfaces. A cloud identity service may authenticate a user, while the application must authorize that user for a tenant. A database may encrypt storage, while the application must select the right tenant. A backup service may retain a copy, while the customer must choose region, access, and deletion. Interfaces are where responsibility often disappears.

Use proof that can fail

Control	Runnable check	Evidence
Tenant authorization	Try wrong-tenant read, write, update, delete, search, and export.	Expected denial and test result.
Identity	Revoke a test identity and retry every path.	Access review and audit event.
Logging	Send a synthetic request and inspect all destinations.	Redacted samples and retention.
Recovery	Restore in an approved location and role boundary.	Exercise record and deletion proof.
Support	Request and close time-bound access.	Approval, audit, and expiry.

Do not let a passing provider status replace a failing customer test. Fix the control at the boundary where the failure occurs and update the risk analysis. A provider may need to answer a scope or evidence question, while engineering may need to change a query or log policy.

Keep data disclosure outside infrastructure proof

Cloud controls do not authorize a marketing disclosure. For Google Ads, allow only generic conversion data after tenant-specific legal approval. Exclude patient name, email, phone, hashed identifiers, service or treatment details, and clinical text. Keep the outbound route off by default, queue it server-side, and retain the approval reference.

If support or incident response crosses a country boundary, record that access as a data-flow event. Review the contract, transfer mechanism, least-privilege role, time window, and audit record. Database location alone does not answer remote-access questions.

Review changes and exit

Reopen the shared-responsibility map after a provider feature, region, subprocessor, plan, database, backup, support, or application change. At exit, prove export, credential revocation, data destruction, backup expiry, log handling, and key treatment. Keep the final map with the risk-analysis and contract records.

Keep the matrix versioned with the architecture and risk analysis. A provider feature or application release can move a control from customer-owned to shared or create a new open row.

FAQ

What is the first verification step for cloud shared responsibility HIPAA?

Draw the data flow and identify provider, customer, and shared controls for every service, copy, identity, region, and support path.

Which source or configuration detail could change the answer?

BAA scope, provider feature, region, backup, support, subprocessor, customer contract, or application configuration can change the matrix.

Does a BAA transfer responsibility to the provider?

No. It allocates contractual duties for a defined boundary. Customer application, identity, data, and operational controls remain.

What must be approved before a production claim or outbound action?

Approve the matrix, risk analysis, contracts, tests, regions, and exact payload. For Google Ads, require tenant-specific legal approval and keep the event off.

References

• U.S. Department of Health and Human Services, “Cloud Computing and HIPAA,” retrieved August 15, 2026: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
• U.S. Department of Health and Human Services, “Security Rule Laws and Regulations,” retrieved August 15, 2026: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
• National Institute of Standards and Technology, “SP 800-53 Revision 5 Update 1,” retrieved August 15, 2026: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final