apointoo.
Request access
HIPAA

How to Check Google Cloud HIPAA Product Coverage

cmsapointoo··7 min read

Short answer: Google Cloud’s covered-product page can narrow which services may be considered for a protected workload, but it does not approve a project, region, application, tenant boundary, or data flow. As of 2026-08-15, Google Cloud documents product scope and regional endpoint controls, while HHS explains cloud shared responsibility. Review the provider list, agreement, service configuration, identity, logs, backups, and application controls together.

GCP service fit and regional boundary

A covered-product list answers only one question: whether a named Google Cloud product is in the provider’s stated scope. Google Cloud’s HIPAA Compliance page describes covered products and shared responsibility. HHS Cloud Computing and HIPAA guidance explains that a cloud provider can handle protected information under an appropriate agreement while the customer remains responsible for its configuration and use.

Record the exact Google Cloud organization, folders, projects, services, regions, endpoints, keys, logs, backups, workers, and vendors. A product can appear on a covered list while a selected feature, beta capability, region, or integration needs separate verification. Do not use the product list as a substitute for a data-flow diagram or risk analysis.

Set the regional policy before provisioning. A tenant home region should determine compute, database, object storage, keys, backups, logs, queues, and support procedures. A global control plane should contain only opaque tenant and deployment metadata. If a service uses a global endpoint, document whether that endpoint can create an unapproved access or data path.

Review layer Question Evidence
Provider Is the named product in the current covered list? Provider page and retrieval date
Agreement Is the correct agreement accepted and applicable? Agreement record and counsel review
Configuration Are project, region, feature, identity, and logs correct? Configuration snapshots
Application Are tenant, minimum necessary, and incident controls tested? Negative tests and runbook

Use what a BAA does not prove to keep the contract claim narrow. For region controls, compare Cloud Run home zones and regional KMS keys.

Request, data, key, and identity path

Map the customer-controlled path after confirming provider scope. Trace caller identity, membership, region, endpoint, compute, database, object store, key, queue, log, backup, and support access. Browser input cannot authorize a tenant or region. The server must resolve membership and home zone from trusted records.

Minimize every field. An approved generic conversion record may use generic event name, time, currency, value, and an opaque internal reference when the tenant and counsel approve the exact use. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising destinations.

Identity roles should reflect the data path. Separate application access, deployment, key administration, backup, restore, support, and audit review. HHS shared-responsibility guidance is a useful reminder that provider infrastructure does not replace customer authorization, workforce controls, audit, or incident response.

tenant membership
  -> immutable home region
  -> regional endpoint and workload
  -> authorized data operation
  -> approved key, log, and backup path

Test alternate hostnames, direct service endpoints, scheduled jobs, administrative APIs, exports, and restores. A public request that passes through the intended route does not prove that a privileged worker uses the same region and membership policy.

Jobs, audit, backup, and failure handling

Secondary systems often determine whether the product claim is true. Inspect scheduled jobs, queues, dead letters, logs, error reports, traces, backups, snapshots, keys, support exports, and test projects. Make sure failed operations return a safe error and do not copy a full request into an uncontrolled log.

Create synthetic tenants in each approved region. Run reads, writes, retries, exports, restore, support access, and wrong-tenant requests. Verify actual resource location, not only a project label. If the provider exposes regional endpoint or organization-policy controls, test both allowed and denied locations.

Keep audit evidence minimum necessary. Record principal, tenant, operation, decision, timestamp, and reason code. Review access changes, key policy changes, export, restore, and emergency access. Set retention from customer contract and risk analysis. A six-year documentation obligation does not mean every application payload belongs in an audit log for six years.

Incident handling should identify provider notice, customer notice, technical containment, restore, and evidence owners. Keep current rules separate from proposed changes and state the retrieval date for product lists, pricing, service behavior, and region claims.

Cost and proof gate

Covered products can still create very different operating floors. Estimate compute, database, ingress, backups, logs, keys, secrets, DNS, support, and three-region duplication separately. Mark prices as planning estimates with region, workload, retention, and date. Do not call the lowest cloud estimate a complete compliance budget.

  • Verify product and feature scope before provisioning.
  • Record agreement, project, account, and role boundaries.
  • Keep regional data and operational copies inside the approved policy.
  • Test denied tenant, region, export, restore, and support paths.
  • Reopen volatile provider pages before production or pricing claims.

Product coverage proof

Use a bounded non-production deployment to connect provider claims to customer evidence.

  1. List every service and feature in the intended data path.
  2. Check each against the current Google Cloud covered-product page.
  3. Record agreement scope, project, region, endpoint, identity, key, log, and backup.
  4. Run synthetic tenant and wrong-region tests.
  5. Review export, restore, support, and incident roles.
  6. Record open contract or legal questions for counsel.

The conclusion should state what Google Cloud documents, what the customer configured, what engineering tested, and what remains unresolved. Do not collapse those categories into a platform guarantee.

A useful coverage review has four columns: provider statement, customer configuration, observed test, and open question. For example, a covered product page can support the provider statement, a project and region policy can support configuration, a synthetic restore can support observation, and a counsel question can remain open. Never fill an open question with an assumption based on a product name.

Review control-plane and data-plane paths separately. A control plane may contain opaque tenant metadata while the data plane holds protected records. Deployment, billing, support, logging, monitoring, key management, and backups can touch both. Document which path is global, which is regional, and who can access each one.

Use a change trigger for rechecking sources: provider list change, new region, new feature, new subprocessor, price change, customer contract, incident, migration, or proposed rule. The retrieval date is part of the claim. If a fact cannot be reproduced, make it qualitative or remove it. The custom-domain review shows why an apparently small ingress choice can add a new control and cost path.

Before protected data, complete a synthetic proof that exercises tenant mismatch, region mismatch, secret failure, export, restore, support, and deletion. Preserve the result with the agreement and configuration record. The goal is a bounded statement about this deployment, not a permanent statement about Google Cloud.

Frequently asked questions

Does a covered-product list approve a project?

No. It supports a provider-scope statement. Project configuration, region, identity, data minimization, logs, backups, application controls, and agreements remain separate.

Does a Google Cloud agreement make an application compliant?

No. It defines a contract boundary. The customer still owns configuration, authorization, risk analysis, workforce access, incident response, and legal review.

What should be rechecked before deployment?

Recheck covered products, BAA or agreement terms, regions, endpoints, features, pricing, quotas, logging, backups, and any proposed rule or policy change. Record the date of each check.

What is the minimum useful proof?

Deploy a synthetic slice, test tenant and region denial, inspect logs and backups, restore in isolation, and review support and export paths. Preserve the evidence and open questions.

References

Related articles