HIPAA Compliance on Google Cloud

This guide covers HIPAA compliance on Google Cloud. HIPAA compliance for Google Workspace is covered separately.

Disclaimer

This guide is for informational purposes only. Google does not intend the information or recommendations in this guide to constitute legal advice. Each customer is responsible for independently evaluating its own particular use of the services as appropriate to support its legal compliance obligations.

Intended Audience

For customers who are subject to the requirements of the Health Insurance Portability and Accountability Act (known as HIPAA, as amended, including by the Health Information Technology for Economic and Clinical Health — HITECH — Act), Google Cloud supports HIPAA compliance. This guide is intended for security officers, compliance officers, IT administrators, and other employees who are responsible for HIPAA implementation and compliance on Google Cloud. After reading this guide, you will understand how Google is able to support HIPAA compliance as well as understand how to configure Google Cloud Projects to help meet your responsibilities under HIPAA.

Definitions

Any capitalized terms used but not otherwise defined in this document have the same meaning as in HIPAA. Furthermore, for the purposes of this document, Protected Health Information (PHI) means the PHI Google receives from a Covered Entity.

Overview

It is important to note that there is no certification recognized by the US HHS for HIPAA compliance and that complying with HIPAA is a shared responsibility between the customer and Google. Specifically, HIPAA demands compliance with the Security Rule, the Privacy Rule, and the Breach Notification Rule. Google Cloud supports HIPAA compliance (within the scope of a Business Associate Agreement) but ultimately customers are responsible for evaluating their own HIPAA compliance.

Google will enter into Business Associate Agreements with customers as necessary under HIPAA. Google Cloud was built under the guidance of a more than 700 person security engineering team, which is larger than most on-premises security teams. Specific details on our approach to security and data protection including details on organizational and technical controls regarding how Google protects your data, can be found in the Google Security Whitepaper and Google Infrastructure Security Design Overview.

In addition to documenting our approach to security and privacy design, Google undergoes several independent third party audits on a regular basis to provide customers with external verification (reports and certificates are linked below). This means that an independent auditor has examined the controls present in our data centers, infrastructure and operations. Google has annual audits for the following standards:

SSAE 16 / ISAE 3402 Type II. Here is the associated public SOC 3 report. The SOC 2 report can be obtained under NDA.
ISO 27001. Google has earned ISO 27001 certifications for the systems, applications, people, technology, processes and data centers serving Google Cloud. Our ISO 27001 certificate is available on the compliance section of our website.
ISO 27017, Cloud Security. This is an international standard of practice for information security controls based on the ISO/IEC 27002 specifically for cloud services. Our ISO 27017 certificate is available on the compliance section of our website.
ISO 27018, Cloud Privacy. This is an international standard of practice for protection of personally identifiable information (PII) in public cloud services. Our ISO 27018 certificate is available on the compliance section of our website.
FedRAMP ATO
PCI DSS v3.2.1

In addition to ensuring the confidentiality, integrity and availability of Google environment, Google’s comprehensive third party audit approach is designed to provide assurances of Google’s commitment to best in class information security. Customers may reference these third party audits reports to assess how Google’s products can meet their HIPAA compliance needs.

Customer Responsibilities

One of the key responsibilities for a customer is to determine whether or not they are a Covered Entity (or a Business Associate of a Covered Entity) and, if so, whether they require a Business Associate Agreement with Google for the purposes of their interactions.

While Google provides a secure and compliant infrastructure (as described above) for the storage and processing of PHI, the customer is responsible for ensuring that the environment and applications that they build on top of Google Cloud are properly configured and secured according to HIPAA requirements. This is often referred to as the shared security model in the cloud.

Essential best practices:

Execute a Google Cloud BAA. You can follow the instructions in the HIPAA Business Associate Addendum to review and accept the BAA.
Disable or otherwise ensure that you do not use Google Cloud Products that are not explicitly covered by the BAA (see Covered Products) when working with PHI.
Do not use Pre-GA offerings (products or services offered under the Google Cloud Pre-General Availability Program or other pre-GA offerings as defined in Google's Service Specific Terms) in connection with PHI, unless expressly noted otherwise in a notice or other terms of the offering.

Recommended technical best practices:

Use IAM best practices when configuring who has access to your project. In particular, because service accounts can be used to access resources, ensure access to those service accounts and service account keys is tightly controlled.
Determine whether your organization has encryption requirements beyond what is required by the HIPAA security rule. All customer content is encrypted at rest on Google Cloud, see our encryption white paper for further details and any exceptions.
If you are using Cloud Storage, consider enabling Object Versioning to provide an archive for that data and to allow for undelete in the case of accidental data deletion.
If you are using BigQuery, be aware that Gemini in BigQuery is not ready to support HIPAA workloads. For more information about how to turn off Gemini in BigQuery, see Turn off Gemini in BigQuery.
Configure audit log export destinations. We strongly encourage exporting audit logs to Cloud Storage for long term archival as well as to BigQuery for any analytical, monitoring, and/or forensic needs. Be sure to configure access control for those destinations appropriate to your organization.
Configure access control for the logs appropriate to your organization. Admin Activity audit logs can be accessed by users with the Logs Viewer role and Data Access audit logs can be accessed by users with the Private Logs Viewer role.
Regularly review audit logs to ensure security and compliance with requirements. As noted above, BigQuery is an excellent platform for large scale log analysis. You may also consider leveraging SIEM platforms from our third-party integrations to demonstrate compliance through log analysis.
When creating or configuring indexes in Cloud Datastore, encrypt any PHI, security credentials, or other sensitive data, before using it as the entity key, indexed property key, or indexed property value for the index. See the Cloud Datastore documentation for information on creating and/or configuring indexes.
When creating or updating Dialogflow agents, be sure to avoid including PHI or security credentials anywhere in your agent definition, including Intents, Training Phrases and Entities.
When creating or updating resources, be sure to avoid including PHI or security credentials when specifying a resource’s metadata as that information may be captured in the logs. Audit logs never include the data contents of a resource or the results of a query in the logs, but resource metadata may be captured.
Use Identity Platform practices when using Identity Platform for your project.
When using Cloud Build services for continuous integration or development, avoid including or storing PHI within build config files, source control files, or other build artifacts.
If you are using Looker (Google Cloud core), individuals designated by Customer to administer the instances or resources should review the security configurations for third-party applications and integrations as well as any corresponding security and privacy documentation provided by the third-party application.
If you are using Looker (Google Cloud core) to structure queries, avoid including or storing PHI in the business logic used to configure such queries. See the Documentation for information on structuring queries.
If you use Cloud CDN, ensure that you do not request caching of PHI. See the Cloud CDN documentation for information on how to prevent caching.
If you are using Cloud Speech-to-Text, and you have entered into a BAA with Google covering any PHI obligations under HIPAA, then you should not opt into the data logging program.
If you are using Google Cloud VMware Engine, it is your responsibility to retain the application level access logs for an appropriate period as needed to meet the HIPAA requirements.
When configuring Sensitive Data Protection jobs, ensure that any output data is written to storage targets that are configured as part of your secure environment.
Review and follow guidance provided by Secret Manager Best Practices when storing secrets in Secret Manager.
Artifact Registry encrypts data in repositories using either Google default encryption or customer-managed encryption keys (CMEK). Metadata, such as artifact names, is encrypted with Google default encryption. This metadata could appear in logs and is visible to any user with permissions in the Artifact Registry Reader role or Viewer role. Follow guidance in Securing artifacts to help prevent unauthorized access to PHI.
Container Registry encrypts data in the storage buckets of your registries using either Google default encryption or CMEK. Follow best practices for containers to help prevent unauthorized access to PHI.
If you are using Filestore, use IP based access control to restrict which Compute Engine VMs and GKE Clusters can access the Filestore instance. Consider using backups to allow data recovery in the case of accidental data deletion.
If you use Cloud Monitoring, do not store PHI in metadata in Google Cloud, including metric labels, VM labels, GKE resource annotations, or dashboard titles/content; anyone authorized through IAM to view your monitoring console or use the Cloud Monitoring API could see this data. Do not place PHI in Alerting configurations (e.g., display name or documentation) which could be sent to alert recipients.
When using reCAPTCHA Enterprise, avoid including PHI in URIs or actions.
If you are using API Gateway, headers should not have any PHI or PII information.
For Database Migration Service, use Private IP connectivity methods, in order to avoid needing to expose a database containing PHI to the Internet.
If you are using Dataplex, values of the google.cloud.datacatalog.lineage.v1.Process.attributes and google.cloud.datacatalog.lineage.v1.Run.attributes fields should not have any PHI or PII.
When using Vertex AI Search, use regional APIs and resource locations for PHI.
When using Application Integration and Integration Connectors, don't include any PII, PHI, or other sensitive information in the Integration Parameter, Connection Name or Connection Configuration, because this information can get logged. Configure access control for logs if the requested payload contains sensitive data. Some file-based connectors and webhook-based events that are offered by Integration Connectors store the data transiently. Customers are given the control of encrypting this data with a key of their choice using CMEK.
When deploying Google Distributed Cloud Connected, customers bear the responsibility for certain security aspects, particularly physical security. To ensure the security of your GDC deployment, you must understand the security responsibilities outlined on the Security Best Practices page.

Covered Products

The Google Cloud BAA covers Google Cloud's entire infrastructure (all regions, all zones, all network paths, all points of presence), and the following products:

Access Approval
Access Context Manager
Access Transparency
AI Platform Training and Prediction
AlloyDB for PostgreSQL
API Gateway
Apigee
App Engine
Application Integration
Artifact Registry
Assured Workloads
AutoML Natural Language
AutoML Tables
AutoML Translation
AutoML Video
AutoML Vision
Backup for GKE
Bare Metal Solution
Batch
BigQuery
BigQuery Data Transfer Service
BigQuery Omni
Bigtable
Binary Authorization
Certificate Authority Service
Certificate Manager
Cloud Asset Inventory
Cloud Backup and DR
Cloud Build
Cloud CDN
Cloud Composer
Cloud Data Fusion
Cloud Deploy
Cloud Deployment Manager
Cloud DNS
Cloud Endpoints
Cloud Filestore
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud Identity
Cloud IDS
Cloud Interconnect
Cloud Key Management Service
Cloud Life Sciences (formerly Google Genomics)
Cloud Load Balancing
Cloud Logging
Cloud Monitoring
Cloud NAT (Network Address Translation)
Cloud Natural Language API
Cloud Profiler
Cloud Router
Cloud Run (fully managed)
Cloud Scheduler
Cloud Shell
Cloud Source Repositories
Cloud SQL
Cloud Storage
Cloud Tasks
Cloud Trace
Cloud Translation
Cloud Vision
Cloud VPN
Colab Enterprise
Compute Engine
Connect
Contact Center AI
Contact Center AI Agent Assist
Contact Center AI Insights
Contact Center AI Platform
Container Registry
Database Migration Service
Data Catalog
Dataflow
Dataform
Dataplex
Dataproc
Datastore
Datastream
Dialogflow
Document AI
Document AI Warehouse
Eventarc
Firestore
Generative AI on Vertex AI
GKE Enterprise Config Management
GKE Hub
Google Cloud Armor
Google Cloud console
Google Cloud Identity-Aware Proxy
Google Cloud NetApp Volumes
Google Cloud VMware Engine (GCVE)
Google Distributed Cloud connected
Google Kubernetes Engine
Healthcare Data Engine
Looker (Google Cloud core)
Looker Studio*
Identity & Access Management (IAM)
Identity Platform
Integration Connectors
Key Access Justifications (KAJ)
Knative serving
Managed Service for Microsoft Active Directory (AD)
Memorystore
Network Service Tiers
Persistent Disk
Pub/Sub
Risk Manager
reCAPTCHA Enterprise
Resource Manager API
Secret Manager
Security Command Center
Sensitive Data Protection
Service Directory
Service Mesh
Spanner
Speech-to-Text
Storage Transfer Service
Text-to-Speech
Traffic Director
Transfer Appliance
Vertex AI Platform (formerly Vertex AI)
Vertex AI Search
Video Intelligence API
Virtual Private Cloud
VPC Service Controls
Web Security Scanner
Vertex AI Workbench instances
Workflows

* Provided that Customer has opted to have Looker Studio governed under their Google Cloud Agreement.

This list is updated as new products become available to the HIPAA program.

Unique Features

Google Cloud's security practices allow us to have a HIPAA BAA covering Google Cloud's entire infrastructure, not a set aside portion of our cloud. As a result, you are not restricted to a specific region which has scalability, operational and architectural benefits. You can also benefit from multi-regional service redundancy as well as the ability to use Preemptible VMs to reduce costs.

The security and compliance measures that allow us to support HIPAA compliance are deeply ingrained in our infrastructure, security design, and products. As such, we can offer HIPAA regulated customers the same products at the same pricing that is available to all customers, including sustained use discounts. Other public clouds charge more money for their HIPAA cloud, we do not.

Conclusion

Google Cloud is the cloud infrastructure where customers can securely store, analyze and gain insights from health information, without having to worry about the underlying infrastructure.