How to Handle PHI on Google Cloud Run: Best Practices for HIPAA Compliance

Handling protected health information (PHI) on Google Cloud Run requires a deliberate mix of contractual safeguards, platform configuration, and operational controls. This guide shows you how to align Cloud Run workloads with HIPAA expectations by combining Business Associate Agreement coverage, HIPAA‑eligible services, network isolation, encryption with Customer‑Managed Encryption Keys, strong TLS, Identity‑Aware Proxy, and disciplined IAM roles and policies.

Configuring Business Associate Agreement

A Business Associate Agreement (BAA) is the contractual foundation that permits processing PHI with Google Cloud. Before you deploy any Cloud Run service that can touch PHI, ensure your organization has an executed BAA covering the relevant Google Cloud services and usage patterns.

Key actions

• Execute a Business Associate Agreement with Google Cloud and confirm Cloud Run and all dependent services you plan to use are listed as HIPAA‑eligible within your agreement.
• Scope PHI to specific projects under the BAA. Use separate projects for non‑PHI workloads to prevent accidental commingling.
• Document your shared‑responsibility model, including incident response, workforce training, and vendor management. HIPAA compliance is programmatic, not just technical.
• Restrict use of preview/beta features unless they are explicitly covered under your BAA and HIPAA‑eligible services list.

Using HIPAA-Eligible Services

Only deploy PHI workloads on HIPAA‑eligible services. Cloud Run typically fronts stateless containers, but your data will often live in adjacent services, which must also be eligible and configured correctly.

Service selection checklist

• Confirm HIPAA eligibility for every integrated service (for example, Cloud Storage, BigQuery, Pub/Sub, Secret Manager, Cloud SQL, Cloud Healthcare API).
• Enable regionalization and data residency controls that align with your compliance requirements; keep PHI in a single region where feasible.
• Disable public access paths by default. For Cloud Storage, enforce uniform bucket‑level access and IAM‑only permissions.
• Use Secret Manager for credentials, API keys, and configuration; never bake secrets into images or environment variables.

Map each data flow. If a downstream service is not HIPAA‑eligible, exclude PHI from that path or redesign the integration. Tight data lineage protects you from accidental disclosure.

Implementing VPC Service Controls

VPC Service Controls (VPC SC) add a powerful perimeter around Google APIs to reduce the risk of data exfiltration. For Cloud Run, pair VPC SC with serverless VPC connectivity and restricted Google API endpoints to keep PHI traffic inside defined boundaries.

Perimeter design

• Create a service perimeter around projects that process or store PHI. Include only HIPAA‑eligible Google services and PHI projects in that perimeter.
• Use Access Context Manager to define ingress/egress rules, allowing only trusted networks, device posture, and identities.
• Route egress from Cloud Run to Google APIs via Private Service Connect for Google APIs (or Restricted Google Access) and block access to public endpoints.
• Connect Cloud Run to your VPC using Serverless VPC Access and restrict egress to approved subnets and destinations with firewall rules.

Operational safeguards

• Enforce DNS policies to resolve Google APIs to restricted or private VIPs, preventing accidental use of public API endpoints.
• Test the perimeter by attempting disallowed operations from within Cloud Run and validating that requests are denied.

Managing Encryption with CMEK

Encryption is mandatory for PHI. While Google encrypts data at rest by default, Customer‑Managed Encryption Keys (CMEK) give you control over keys, rotation, and separation of duties across Cloud Run dependencies.

CMEK strategy

• Create Cloud KMS key rings and keys in the same region as your workloads. Enforce key rotation (for example, 90–365 days) and dual control for key administration.
• Use CMEK wherever supported: Cloud Storage buckets, BigQuery datasets, Pub/Sub topics, Secret Manager, and Cloud SQL. Confirm CMEK coverage for Cloud Run–related artifacts where available.
• Grant only the runtime service accounts the minimal Cloud KMS permissions (cryptoKeyEncrypterDecrypter). Separate key admins from data admins.
• Back up critical keys securely and monitor key usage; alert on unexpected decrypt operations or policy changes.

For data in transit, combine strong TLS with application‑level protections. For data at rest, apply CMEK consistently across every store that can contain PHI, including backups and exports.

Enforcing TLS for Data Transmission

All PHI in transit must be encrypted using modern cryptography. Enforce TLS 1.2+ for inbound and outbound connections and disable weak ciphers. Prefer TLS 1.3 where supported.

Inbound to Cloud Run

• Use HTTPS endpoints only. For custom domains, terminate TLS at a Google Cloud HTTPS Load Balancer with an SSL policy requiring TLS 1.2+ and strong ciphers.
• Enable HSTS on custom domains to prevent protocol downgrade and force secure transport.
• If you need client authentication, place a load balancer in front of Cloud Run and use mTLS with client certificates for high‑assurance callers.

Service-to-service and outbound

• Use library settings to require TLS 1.2+ for all SDKs and database drivers. Reject plaintext and self‑signed endpoints unless intentionally pinned.
• For Cloud SQL, prefer private IP and enforce TLS to the proxy or connector as applicable.
• Continuously scan dependencies for TLS regressions and certificate issues; automate certificate renewals and validation.

Applying Identity-Aware Proxy

Identity‑Aware Proxy (IAP) provides centralized, identity‑based access to HTTP(S) apps without exposing them publicly. For PHI, it lets you authenticate users, apply context‑aware access, and keep origin services private.

Deployment guidance

• Place Cloud Run behind an HTTPS Load Balancer protected by Identity‑Aware Proxy when you need end‑user access. Require organizational accounts and enforce MFA.
• Use context‑aware policies to restrict access by device posture, IP ranges, and user groups. Deny unknown or high‑risk contexts by default.
• For service‑to‑service calls, prefer OIDC identity tokens with the run.invoker permission instead of long‑lived credentials.
• Log all IAP decisions and feed them into your Audit Log Monitoring pipeline for anomaly detection.

Enforcing IAM Best Practices

Least privilege is non‑negotiable for PHI on Google Cloud Run. Build around tightly scoped IAM roles and policies, short‑lived credentials, and strong separation of duties.

Role design and access hygiene

• Assign the smallest necessary roles (for example, run.invoker, run.developer) instead of broad roles. Avoid primitive roles like Owner, Editor, Viewer.
• Create dedicated service accounts per Cloud Run service. Block service account key creation and use Workload Identity Federation for CI/CD.
• Apply conditional IAM with resource‑level conditions (time, IP, device) to further limit powerful roles.
• Use organization policies to enforce constraints such as disabling serial port access, restricting external IPs, and limiting domain‑wide sharing.

Secrets, images, and supply chain

• Store secrets only in Secret Manager with CMEK and granular IAM. Enable automatic rotation and least‑privilege access paths.
• Adopt binary authorization and trusted builder patterns. Scan images for vulnerabilities before deploying to Cloud Run.

Audit Log Monitoring

• Enable Admin Activity and Data Access logs for Cloud Run and all dependent services. Route logs to centralized storage with immutable retention.
• Create log‑based metrics and alerts for risky events: policy changes, permission grants, failed logins, anomalous data reads, and egress to unapproved destinations.
• Integrate Access Transparency and Access Approval where available, and reconcile logs with ticketing systems for change control.
• Retain audit artifacts per your risk management program; many organizations align retention with HIPAA documentation timelines.

Conclusion

Achieving HIPAA compliance for PHI on Google Cloud Run hinges on contract coverage, HIPAA‑eligible services, network perimeters, CMEK, TLS 1.2+, Identity‑Aware Proxy, and rigorous IAM roles and policies. Combine these controls with continuous Audit Log Monitoring and disciplined operations to maintain a defensible, least‑privilege posture.

FAQs

What is required to handle PHI on Google Cloud Run?

You need an executed Business Associate Agreement, use of HIPAA‑eligible services only, strong encryption at rest and in transit (TLS 1.2+), network isolation with VPC Service Controls, identity‑centric access via IAM and Identity‑Aware Proxy, and continuous Audit Log Monitoring with alerting. Document your processes and perform regular risk assessments.

How does a Business Associate Agreement support HIPAA compliance?

The Business Associate Agreement defines Google’s responsibilities as a business associate and outlines which services are HIPAA‑eligible. It clarifies the shared‑responsibility model and establishes required safeguards, enabling you to process PHI on covered services when you implement the appropriate technical and administrative controls.

What encryption methods are recommended for PHI on Cloud Run?

Use TLS 1.2+ (preferably TLS 1.3) for all data in transit, enforce strong cipher suites, and require mTLS for high‑assurance clients when needed. For data at rest, apply Customer‑Managed Encryption Keys through Cloud KMS across dependent services such as Cloud Storage, BigQuery, Pub/Sub, Secret Manager, and Cloud SQL, with strict key rotation and access controls.

How can audit logs help in HIPAA compliance on Cloud Run?

Audit logs provide traceability for administrative and data‑access events. Enabling Admin Activity and Data Access logs, creating log‑based alerts, and retaining logs immutably help you detect misuse, investigate incidents, and demonstrate compliance. Centralized Audit Log Monitoring also supports continuous risk management and reporting.