apointoo.
Request access
HIPAA

A Google Cloud BAA Does Not Cover Google Ads

cmsapointoo··8 min read

A Google Cloud Business Associate Agreement applies to the Google Cloud services and conditions identified in that agreement. It does not travel with information when a workload sends an event to Google Ads. Google Ads is a separate product destination with its own terms, customer data policies, account configuration, and approval path.

This boundary matters because an architecture can be technically sound inside Google Cloud and still create an unapproved advertising disclosure at its final step. A covered runtime, database, queue, or secret store does not extend the provider agreement to an Ads API. Review each destination independently before connecting it.

What the Google Cloud BAA actually scopes

Google Cloud’s HIPAA compliance page states that customers subject to HIPAA who use Google Cloud with protected health information must review and accept Google’s BAA. The page describes coverage for Google Cloud’s infrastructure and the listed covered products. It also makes shared responsibility explicit: the agreement does not, by itself, make a customer’s application compliant.

That is a product boundary, not a corporate halo. Record the legal entity, billing account, organization, projects, named services, features, regions, support path, and agreement version. Then connect those provider facts to customer controls such as identity, tenant isolation, encryption, logging, backups, retention, incident response, and workforce access. The Google Cloud covered-product review explains how to preserve that evidence chain.

A useful statement is narrow: “This workload uses named Google Cloud services listed in the current provider scope under the accepted agreement.” It should not become “Anything this workload calls is covered.” Once information crosses to another product, the team must evaluate the new recipient and purpose.

Why Google Ads stays outside that boundary

Google Ads is an advertising platform, not a service added to the Google Cloud BAA because the same vendor operates both brands. The Google Cloud compliance page defines its own covered products. Google Ads publishes separate customer data policies. Procurement, credentials, support, data use, retention, and enforcement also follow different product systems.

Layer Question Evidence to preserve
Google Cloud Is the exact service in the current BAA scope? Agreement, covered-product page, project and feature list
Application Does configuration enforce the intended data boundary? Data-flow map, access tests, logs and retention settings
Google Ads Does policy permit this exact conversion use and field set? Current policy, destination configuration and written approval
Transfer What leaves Cloud, and why? Serializer allowlist, queue record and delivery evidence

Do not combine those rows into one compliance claim. A contract review can establish provider scope. A technical test can establish observed behavior. A policy review can establish whether an advertising use is permitted under the published rules at that date. Counsel can assess legal duties. None substitutes for the others.

Google’s customer data policy applies to features including enhanced conversions, store sales uploads, and other customer data uses identified on the page. It prohibits uploading conversion information related to sensitive categories. The policy lists health and medical information, including purchases of medical services, among those categories.

A generic event label does not necessarily remove the context. “Lead,” “booking,” or “qualified” may still represent a health-related interaction when joined to the source, campaign, account, timing, or destination. Hashing an email address does not change the purpose or sensitivity of the underlying conversion. An API success response proves transport, not policy permission.

This is why a health organization should start with internal measurement. Keep detailed outcomes inside the approved environment. Use aggregated reporting where it answers the business question. If any Ads conversion route is proposed, review the exact feature, event meaning, identifiers, timestamps, click references, consent state, account type, and current policy. The Google Ads health conversion policy review provides a focused checklist.

Where the Data Manager API fits

Google describes the Data Manager API as a way to send audience and conversion data to multiple Google advertising products. That makes it a transport and destination-management surface for advertising. It does not make Google Ads part of Google Cloud’s covered-product list, and it does not convert a Cloud BAA into permission for the event.

approved internal application
  -> explicit event decision
  -> minimum field allowlist
  -> policy and consent gate
  -> outbound queue
  -> Data Manager API
  -> named Google advertising destination

Every arrow after the internal application deserves its own owner. The event decision defines what the record means. The allowlist prevents a full operational object from leaking into advertising. The policy gate confirms a current written decision. The queue preserves suppression and retry state. The destination record shows where the API sent the event.

For a bounded implementation pattern, see the server-side clinic form architecture. Its central safeguard is fail-closed behavior: no external delivery when policy, approval, field eligibility, or destination is unknown.

A decision gate before any Ads connection

  1. Name the Google Cloud boundary. List services, features, projects, regions, agreement version, and administrative accounts.
  2. Name the advertising destination. Record the exact Google Ads customer, conversion action, API surface, data owner, and purpose.
  3. Describe the event in plain language. State what real-world action it represents. Do not rely on a generic technical label.
  4. Inspect every field. Include identifiers, hashes, click references, timestamps, values, URLs, metadata, logs, and retry payloads.
  5. Review current policy and law separately. Preserve retrieval dates, questions, approvals, and unresolved limits.
  6. Test suppression first. With synthetic events, prove that missing approval, unexpected fields, wrong destination, or denied consent stops before the outbound queue.
  7. Reconcile delivery. If the route is approved, distinguish queued, sent, accepted, rejected, suppressed, and reported states.

This gate should produce a bounded decision, not a permanent certificate. Reopen it when the form changes, an Ads feature changes, a new identifier is added, ownership moves, policy is revised, or the meaning of the conversion changes. The separate BAA scope evaluation method can be reused for the Cloud side without blurring the advertising side.

Common boundary failures

  • Treating “Google” as one product scope across Cloud, Analytics, Ads, support, and third-party integrations.
  • Assuming a Cloud Run or storage configuration controls what Google Ads does after receipt.
  • Sending the full form or operational record because the server already has it.
  • Calling hashed contact details anonymous without assessing linkability, purpose, and policy.
  • Using a successful Data Manager response as evidence of contractual or policy approval.
  • Leaving a browser tag active beside a reviewed server-side route.
  • Logging rejected payload contents instead of a safe reason code.

The smallest defensible design has one internal event definition, one explicit outbound gate, one allowed field set, one named Ads destination, and one reconciliation record. If the external use is not approved, stop at internal or aggregate measurement. Technical capability is not a reason to widen the flow.

What can be claimed after review?

Use evidence-specific language. You may be able to say that the provider page listed a Google Cloud service on a given date, that the organization accepted an agreement, or that a synthetic test blocked an unexpected field. You may separately document that counsel and the policy owner reviewed a named advertising use against current sources.

Avoid claiming that Google Cloud, Google Ads, the Data Manager API, or the architecture is compliant in the abstract. Product lists, policies, configurations, contracts, and uses change. Keep the source date beside the conclusion, preserve open questions, and make reapproval a deployment condition when the boundary changes.

Frequently asked questions

Does accepting Google Cloud’s BAA cover a Google Ads account?

No. The Google Cloud agreement applies to its stated Google Cloud scope. Google Ads is a separate destination with separate terms, policies, configuration, and review.

Does running the connector on Cloud Run change that answer?

No. The runtime may sit inside the reviewed Cloud boundary, but the API destination remains Google Ads. Assess the outbound event and recipient independently.

No. Its documentation describes how data reaches advertising products. Eligibility depends on current product policy, the exact use, contracts, consent requirements, and applicable law.

What should happen when the policy answer is unclear?

Keep external delivery disabled. Measure internally or in aggregate while qualified policy, privacy, security, and legal reviewers assess the exact event and field set.

References

Related articles