Cloud Technology Partners
gcp healthcare compliance hipaa

GCP for Healthcare: Compliance Shortcuts, Gotchas, and Where You Have to Do the Work Yourself

What Google's HIPAA BAA actually covers on GCP, what it doesn't, and the implementation patterns that hold up under audit. Written for engineers who have to ship, not auditors.

· Cloud Technology Partners

Google Cloud is a credible platform for healthcare workloads. The HIPAA-eligible service list is long, the BAA is straightforward, and the data and AI tooling is genuinely better than the alternatives for several common healthcare use cases. The problem is that the marketing makes it sound easier than it is, and the official documentation is organized for compliance teams rather than the engineers who have to actually build the system.

This post is for engineers and architects who own GCP healthcare workloads. It covers what the BAA actually does, where the gaps are, and the patterns we keep arriving at across engagements.

What the BAA Covers, Practically

When you sign a BAA with Google, what changes is contractual, not technical. Google agrees to treat PHI processed by HIPAA-eligible services with specific safeguards, and you become responsible for everything else.

The eligible services list moves. Check it before you design. As of writing, the relevant ones for most builds are:

  • GCS, BigQuery, Cloud SQL, Spanner, Firestore (Native and Datastore modes)
  • Cloud Run, GKE, Compute Engine, Cloud Functions
  • Pub/Sub, Dataflow, Cloud Composer
  • Healthcare API (FHIR, HL7v2, DICOM stores)
  • Vertex AI training and prediction
  • Cloud Logging, Cloud Monitoring

Notable gaps that catch teams:

  • Workflows has been HIPAA-eligible in some regions but not others — verify per region
  • Document AI general processors are eligible; specialized processors vary
  • Apigee is eligible but with specific configuration requirements
  • Several Gemini API surfaces have a separate eligibility status from Vertex-hosted Gemini — do not assume parity

If you use an ineligible service in your PHI data path, your BAA does not cover it. This is the single most common audit finding.

The CMEK Conversation

Google encrypts data at rest by default. For most non-healthcare workloads, Google-managed keys are fine. For HIPAA, most security teams want customer-managed encryption keys (CMEK) via Cloud KMS.

What you actually get from CMEK:

  • A control plane you own — you can rotate, disable, or destroy a key, which renders the data unreadable even to Google
  • An audit trail of every key use, which maps cleanly to the access-control sections of a HIPAA audit
  • The ability to host the key in a specific region for data-residency commitments

What CMEK does not give you:

  • Protection from a compromised IAM identity in your own project. CMEK is not a substitute for least-privilege IAM.
  • Performance parity in every case. KMS calls are not free, and high-throughput Dataflow or BigQuery jobs can show measurable latency overhead.
  • Automatic protection on every resource. CMEK has to be configured per-resource (per bucket, per dataset, per CloudSQL instance) and per-region. Drift is real.

For high-sensitivity workloads, the next step up is Cloud HSM (FIPS 140-2 Level 3) or External Key Manager if the security team wants keys outside Google entirely. EKM is operationally heavy and we generally recommend it only when there is a specific contractual or sovereignty requirement.

Audit Logging That Actually Holds Up

Cloud Audit Logs has four streams:

  • Admin Activity — always on, free, 400-day retention
  • System Event — always on, free, 400-day retention
  • Data Access — off by default for most services, billable, configurable retention
  • Policy Denied — off by default, useful for detecting access attempts blocked by VPC SC or IAM Conditions

For HIPAA, you need Data Access logs on every service that touches PHI. This is not optional and it is not the default. A common configuration pattern:

auditConfigs:
  - service: storage.googleapis.com
    auditLogConfigs:
      - logType: DATA_READ
      - logType: DATA_WRITE
  - service: bigquery.googleapis.com
    auditLogConfigs:
      - logType: DATA_READ
      - logType: DATA_WRITE
  - service: healthcare.googleapis.com
    auditLogConfigs:
      - logType: DATA_READ
      - logType: DATA_WRITE

Apply this at the organization level via gcloud organizations set-iam-policy or org policy, not per-project. Per-project configuration drifts within six months in our experience.

Three things that bite teams later:

  1. Cost. Data Access logs on a high-traffic BigQuery dataset can produce tens of GB per day. Route them to a dedicated logging bucket with a tiered retention policy (90 days hot, the rest in archive) and exclude any non-PHI noise.
  2. Retention. HIPAA requires six years for documentation of policies and procedures. The audit log retention itself is a risk-based decision; most healthcare clients settle on 18 months hot and 6 years cold.
  3. Tamper resistance. Logs in the same project as the workload are not tamper-evident in any meaningful sense. Sink to a separate logging project with restricted IAM, ideally owned by a different team than the workload.

The Healthcare API: Use It

Most teams building greenfield healthcare workloads on GCP should use the Healthcare API rather than rolling their own FHIR or HL7v2 storage on Cloud SQL. The Healthcare API gives you:

  • FHIR R4 (and STU3) stores with native search, _history, and conditional updates
  • HL7v2 store with parser, schema validation, and Pub/Sub notifications on receive
  • DICOM store with DICOMweb API
  • De-identification API that handles structured and unstructured PHI with configurable transformations
  • Direct, low-friction streaming to BigQuery for analytics

The tradeoff is cost. The Healthcare API is not cheap at scale. For workloads in the low millions of FHIR resources, it is the right answer. For workloads in the billions, run a real cost model before committing.

The de-identification API is the feature most teams underuse. A common pattern:

  1. Raw PHI lands in a FHIR store in a locked-down project
  2. A scheduled de-identification job writes a de-identified copy to a separate FHIR store in an analytics project
  3. Analysts and ML workloads work against the de-identified store and never touch raw PHI

This pattern dramatically reduces the audit scope of the analytics environment.

Network Boundaries

The HIPAA-eligible service list does not relieve you of network design. Two patterns that hold up:

VPC Service Controls around the PHI perimeter. VPC SC is operationally awkward (it breaks things in surprising ways during setup) but it is the only GCP control that prevents data exfiltration through legitimate service APIs. A user with valid GCS credentials cannot copy a PHI bucket to a personal project if the bucket is inside a service perimeter.

Private Service Connect or Private Google Access for any compute that touches PHI. PHI workloads should not transit the public internet between Google services. PSC and PGA cost effectively nothing and remove an entire class of exfiltration risk.

A trap: VPC SC ingress and egress rules are not the same as firewall rules. Configuring one and not the other gives a false sense of security. Both need to be modeled together.

Where You Are Still on the Hook

The BAA does not cover:

  • Application-layer access control. If your app authorizes a user to see another patient’s record, that is on you.
  • Workforce training, BAAs with subprocessors (your auth provider, your error monitoring vendor, your email service), incident response process, sanction policy.
  • Patch management on Compute Engine instances and GKE node pools.
  • Configuration of the eligible services. CMEK off, public bucket, no audit logs — that is your finding, not Google’s.
  • Anything in your CI/CD pipeline that handles PHI test fixtures. Almost every team we audit has PHI or PHI-shaped data in a staging environment with weaker controls than production. This is the second most common audit finding.

A Reference Architecture That Audits Well

For a typical HIPAA workload on GCP, the shape we keep arriving at:

  • A resource hierarchy with a dedicated folder for healthcare workloads, org policies enforcing CMEK and disabling external IP allocation
  • A PHI project containing the Healthcare API store, GCS buckets for raw documents, and the services that ingest and process PHI
  • An analytics project containing the de-identified copies and the BI tooling
  • A logging project receiving all audit log sinks, with IAM restricted to a small security team
  • VPC SC perimeter around the PHI project, with explicit ingress rules for the CI/CD service account and engineers’ break-glass access
  • Cloud KMS in a separate security project, with key rings per workload and rotation every 90 days
  • Workload Identity Federation for CI/CD — no long-lived service account keys
  • Binary Authorization on GKE if running containers, with attestations required from the CI pipeline

None of this is exotic. All of it is work, and most of it has to be in place before the first PHI byte lands or you will be retrofitting under audit pressure.

Cloud Technology Partners places senior GCP and healthcare-cloud practitioners into HIPAA, HITRUST, and regulated-industry engagements. Explore our compliance services or contact us to discuss your healthcare cloud staffing needs.