BAA & GCP Project Setup
Overview
Before any Protected Health Information (PHI) is stored, transmitted, or processed on Google Cloud Platform, you must have a signed Business Associate Agreement (BAA) with Google. This is a non-negotiable requirement under HIPAA 45 CFR § 164.308(b).
1. What Is a BAA?
A Business Associate Agreement is a legal contract between a HIPAA-covered entity (your client) and a business associate (Google) that:
- Confirms the business associate will protect PHI appropriately
- Defines permitted uses and disclosures of PHI
- Requires the business associate to report breaches
- Establishes liability for non-compliance
Google's BAA covers a specific list of HIPAA-eligible GCP services. Services not on that list cannot be used with PHI.
2. How to Sign the Google Cloud BAA
Step-by-step
- Log in to the GCP Console as an Organization Admin or Project Owner.
- Navigate to IAM & Admin > Compliance.
- Select the HIPAA compliance tile.
- Review and accept the Google Cloud HIPAA Business Associate Amendment.
- The BAA applies at the Organization or Project level — confirm which scope applies.
Tip: The BAA must be signed by a legally authorized representative of your organization. Coordinate with your legal team before accepting.
Verification
After signing:
- Download and retain a copy of the executed BAA.
- Record the signing date, signatory name, and GCP Organization/Project ID in your compliance log.
- Review the BAA annually or whenever Google updates its terms.
3. HIPAA-Eligible Services Relevant to This Stack
Only use PHI with the following services (confirm current list with Google's official documentation):
| Service | Notes |
|---|---|
| Cloud Run | Managed serverless containers |
| Cloud SQL | MySQL and PostgreSQL |
| Cloud Memorystore for Redis | TLS and AUTH must be configured |
| Cloud KMS | Customer-Managed Encryption Keys |
| Secret Manager | For credentials and secrets |
| Cloud Storage | For backups and audit log exports |
| Cloud Audit Logs / Cloud Logging | Must enable Data Access logs |
| Virtual Private Cloud (VPC) | Network isolation |
| Cloud Armor | WAF / DDoS protection |
Important: Services outside this list (e.g., BigQuery if not on the eligible list, or Firebase free tier) must never contain PHI.
4. GCP Project Architecture for HIPAA
4.1 Dedicated PHI Project
Create a separate GCP project exclusively for PHI workloads. Do not share a project with non-PHI applications.
GCP Organization
├── project-prod-phi ← PHI workloads (Cloud Run, Cloud SQL, Redis)
├── project-prod-non-phi ← Non-PHI services
└── project-dev ← Development (NO real PHI — use synthetic data only)
4.2 Organization Policy Constraints
Apply the following Organization Policies to the PHI project:
# Restrict resource locations to US regions only
gcloud org-policies set-policy resource_locations.yaml \
--project=YOUR_PHI_PROJECT_ID
resource_locations.yaml:
name: projects/YOUR_PHI_PROJECT_ID/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:us-locations
Additional recommended constraints:
| Constraint | Purpose |
|---|---|
constraints/gcp.resourceLocations | Keep PHI in approved regions |
constraints/iam.disableServiceAccountKeyCreation | Prevent service account key sprawl |
constraints/compute.requireShieldedVm | Require Shielded VM for compute |
constraints/compute.skipDefaultNetworkCreation | Prevent default VPC creation |
constraints/storage.uniformBucketLevelAccess | Enforce uniform bucket access |
4.3 Resource Labeling
Tag all PHI-related resources consistently:
# Example: Label a Cloud SQL instance
gcloud sql instances patch YOUR_INSTANCE \
--update-labels=data-sensitivity=phi,environment=production,owner=cloud-team
Standard labels for PHI project:
| Label Key | Example Value | Purpose |
|---|---|---|
data-sensitivity | phi | Identify PHI resources |
environment | production | Environment identification |
compliance | hipaa | Compliance framework |
owner | cloud-team | Ownership for audits |
5. VPC Service Controls
VPC Service Controls create a security perimeter around GCP resources to prevent data exfiltration.
Enable VPC Service Controls
# Create an access policy (once per organization)
gcloud access-context-manager policies create \
--organization=YOUR_ORG_ID \
--title="PHI Security Policy"
# Create a service perimeter
gcloud access-context-manager perimeters create phi-perimeter \
--policy=YOUR_POLICY_ID \
--title="PHI Service Perimeter" \
--resources=projects/YOUR_PHI_PROJECT_NUMBER \
--restricted-services=storage.googleapis.com,sqladmin.googleapis.com,redis.googleapis.com
What VPC-SC Protects Against
- Unauthorized data copy from Cloud Storage buckets
- API calls from outside the perimeter
- Lateral movement between projects
6. Security Command Center
Enable Security Command Center (SCC) to continuously monitor your PHI project for vulnerabilities and misconfigurations.
# Enable SCC at the organization level
gcloud services enable securitycenter.googleapis.com \
--project=YOUR_PHI_PROJECT_ID
Configure SCC to:
- Send findings to your security team via Pub/Sub notifications
- Integrate with your SIEM (Splunk, Chronicle, etc.)
- Enable premium tier for Event Threat Detection and Container Threat Detection
7. Compliance Verification Checklist
Before going live with PHI:
- BAA signed and copy stored in compliance records
- Dedicated GCP project created for PHI workloads
- Organization Policy constraints applied
- All resources labeled with
data-sensitivity: phi - VPC Service Controls perimeter created
- Security Command Center enabled
- Only HIPAA-eligible services configured for PHI
- Development environments use synthetic data only
Next: IAM & Access Control →