HIPAA on Google Cloud
On Google Cloud, the risk is in how easily data is copied
Google Cloud's managed data services make it simple to load, join and share large datasets. For ePHI that ease is the risk. This page covers the BAA, the idea of covered products, and the controls that keep patient data from spreading: the resource hierarchy, your own keys and service perimeters.
Back to HIPAA services01 · Worked scenario
Illustrative: a health-data analytics start-up
Count the copies before you count the controls.
Illustrative only. A start-up takes claims and clinical extracts from US provider groups, loads them into a managed data warehouse, runs pipelines that clean and join them, and gives analysts notebooks to build models. Customers see dashboards. Six months in, nobody can say how many copies of the raw data exist.
| Where the data goes | Why a copy appears | What to decide |
|---|---|---|
| Landing bucket | Raw files arrive from customers | Retention and who can list objects |
| Warehouse tables | Loaded for querying | Which datasets hold identifiers |
| Pipeline temp storage | Jobs stage intermediate data | Where temp data lives and when it is cleared |
| Analyst notebooks | Query results pulled into memory and files | Whether notebooks may see identified data at all |
| Exports and extracts | CSV files for a customer or a model | Who may export, and to where |
| Dashboards | Aggregates shown to customers | Small-number rules so a person cannot be singled out |
02 · Accepting the BAA
How the Google Cloud BAA is accepted
In the console, or already inside your agreement.
Google's support instructions describe accepting the Google Cloud HIPAA Business Associate Addendum from the privacy page under IAM and Admin in the console, with a project selected; accepting in one project covers the account. Some customers' Google Cloud agreements already include the BAA by reference, and those customers do not accept it again.
Whichever route applies, record who accepted, when, and for which billing and organisation set-up. A reviewer will ask, and the console is not an easy place to find the history later.
03 · Covered products
Covered products, and the platform underneath
Google lists supported services. Read the list on the day you design.
Google publishes the products its BAA supports, with a last-updated date, and states that the BAA also covers the infrastructure those products run on. It keeps separate lists for some product families, such as Google Workspace. Use only listed products for PHI, and check again when you adopt something new, especially preview features.
04 · Hierarchy and policy
Use the resource hierarchy to fence ePHI
Organisation, folders, projects: rules set high flow down.
- OrgOrganisationCompany-wide rules, such as which regions may host resources and whether service account keys may be created.
- FolderePHI folderHolds only projects that touch patient data, with tighter access and logging.
- ProjectWorkload projectsSeparate projects for landing, warehouse and analysis, so access can differ by stage.
Organisation policies set constraints that project owners cannot override. Put the hard limits there. Grant people roles on the ePHI folder through groups, not as individuals, so leavers drop out in one place.
05 · Keys and perimeters
Customer-managed keys and service perimeters
Keys decide who can read. Perimeters decide where data can go.
Default encryption
Google encrypts customer content at rest by default with keys it manages.
- No set-up
- Protects storage media
- No separation of duties you control
Customer-managed keys (CMEK)
Keys you create in Cloud Key Management Service and grant to specific services.
- Key admins separate from data users
- Disabling a key makes the data unreadable
- Check each product supports it and which metadata stays outside it
Google notes that some metadata, such as resource names, may sit outside customer-managed keys. Keep identifiers out of names.
VPC Service Controls draw a service perimeter around a set of projects. Calls to supported Google services from outside the perimeter are refused, even with valid credentials. For an analytics company this is the main defence against an analyst, or stolen credentials, copying a table into a personal project.
- Perimeter covers every ePHI project. Landing, warehouse and analysis projects sit inside one perimeter.
- Dry-run first. Run the perimeter in a mode that logs violations before you enforce it.
- Named exceptions. Every ingress or egress rule has an owner and a reason.
06 · Analytics risk
Why managed data services need extra care
Analytics products are built to share. ePHI needs the opposite.
- Identified data in every dataset. Keep identifiers in one restricted dataset and give analysts tokenised keys.
- Notebooks outside the perimeter. A notebook in an unprotected project can read data out of a protected one if it is allowed through.
- Calling data de-identified too early. HIPAA recognises two methods, safe harbor and expert determination. Removing names alone meets neither.
- Unlimited exports. Restrict who can export tables and to which buckets, and log every export.
- Query logs holding PHI. Query text with patient names lands in logs. Treat those logs as ePHI.
Sources: 45 CFR 160.103; 45 CFR 164.312 (technical safeguards); 45 CFR 164.514(a) and (b) (de-identification); HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing; Google Cloud's public HIPAA compliance page and its support article on accepting the BAA.
Questions about HIPAA on Google Cloud
Where do we accept the Google Cloud BAA?
In the console's privacy settings, unless your agreement already includes it.
Google's instructions point to the privacy page under IAM and Admin, with a project selected. If your agreement already incorporates the BAA, there is nothing more to accept. Record which applies.
Do we need customer-managed keys for HIPAA?
Not by rule. It is a decision your risk analysis should record.
Encryption is addressable, and Google encrypts at rest by default. Customer-managed keys add separation of duties and a way to cut off access, which many analytics teams want for raw ePHI.
Are VPC Service Controls required?
No rule names them. They answer a risk most analytics firms have.
The Security Rule asks you to manage risks you identify. If copying data out of your projects is one of them, a service perimeter is a strong, testable control for it.
Is de-identified data still subject to HIPAA on Google Cloud?
Not if it truly meets a HIPAA de-identification method.
Data de-identified by safe harbor or expert determination is no longer PHI. Data that only had names removed still is, wherever it is stored.
Map every copy before a customer asks.
A HIPAA risk assessment traces ePHI through your Google Cloud projects, pipelines and exports. Counsel should confirm how Google's BAA applies to your contracts.