Compliance and Privacy

What Is Compliance and Privacy in Google Cloud?

Compliance and privacy in Google Cloud is the bundle of certifications, regulatory attestations, control planes, and product features that lets a customer prove — to auditors, regulators, and their own board of directors — that data handled on Google Cloud meets the laws and standards that govern their industry and geography. For the Cloud Digital Leader (CDL) exam, this topic is not about the cryptographic mechanics of compliance (that lives under Data Encryption and Protection); it is about the business-level question of "how do we demonstrate to a regulator that our workload is compliant, and what does Google Cloud actually take off our plate versus leave on it?"

Compliance is one of the strongest reasons enterprises move to Google Cloud in the first place. Achieving and maintaining certifications like SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, PCI DSS, HIPAA, FedRAMP High, and CSA STAR independently is a multi-year, multi-million-dollar effort for any organization that tries to run its own data centers. Google Cloud has already invested in those certifications across its physical infrastructure, its hypervisor layer, and its managed services. When a customer builds a workload on Google Cloud, that workload inherits the underlying compliance posture — provided the customer configures and operates their own layers correctly. This is the inheritance side of the shared responsibility model.

Privacy, meanwhile, sits one layer above the certifications. Privacy regulations like the EU's General Data Protection Regulation (GDPR), Brazil's Lei Geral de Proteção de Dados (LGPD), California's CCPA/CPRA, China's Cybersecurity Law (CSL) and Personal Information Protection Law (PIPL), and Australia's Privacy Act govern not just whether data is encrypted but where it physically lives, which legal jurisdiction can subpoena it, how long it is retained, and what rights the data subjects have to erase or export their personal data. The CDL exam tests whether you understand the difference between data residency and data sovereignty, and which Google Cloud features address each.

Why Compliance Matters in the Cloud

Compliance is not a paperwork exercise; it is the lever that determines whether a company can legally operate in a market. A European fintech that cannot demonstrate GDPR compliance cannot offer accounts to EU residents. A US hospital that cannot sign a Business Associate Agreement (BAA) with its cloud provider cannot legally store Protected Health Information (PHI) there. A payment processor that fails a PCI DSS audit cannot process card transactions. Compliance is, in many industries, the license to operate.

The Business Stakes of Non-Compliance

Beyond losing the license, the financial penalties are severe. GDPR fines can reach 4 percent of global annual revenue or 20 million euros, whichever is higher. HIPAA fines for "willful neglect" exceed 1.9 million USD per violation category per year. PCI DSS non-compliance can lead to card-brand fines plus the loss of merchant processing privileges. CDL candidates are expected to recognize that compliance is a board-level concern, not a back-office checkbox.

Why the Cloud Helps (and Where It Does Not)

The cloud helps because the provider has already audited and certified the layers below the customer's application — physical security, hardware, hypervisor, network, default encryption, identity infrastructure. The cloud does not help when the customer misconfigures their own layer. A misconfigured Cloud Storage bucket that exposes PHI to the public internet is still a HIPAA breach, even though Google Cloud itself is HIPAA-eligible. The CDL exam loves to test this distinction.

Google Cloud's Compliance Posture

Google Cloud maintains one of the largest portfolios of compliance certifications and attestations in the industry, covering global, regional, industry-specific, and government regimes.

Global Standards

• ISO/IEC 27001 — the international information-security management system (ISMS) standard.
• ISO/IEC 27017 — cloud-specific security controls built on top of ISO 27001.
• ISO/IEC 27018 — protection of personally identifiable information in public clouds.
• ISO/IEC 27701 — privacy information management system extension.
• SOC 1, SOC 2, SOC 3 — American Institute of CPAs (AICPA) audit reports covering financial reporting controls (SOC 1) and security, availability, processing integrity, confidentiality, and privacy (SOC 2/3).
• CSA STAR — the Cloud Security Alliance's Security, Trust, Assurance, and Risk program.

Regional and National Regimes

• GDPR (European Union) — Google Cloud offers Standard Contractual Clauses (SCCs), data-processing addenda, and EU-region storage to support GDPR compliance.
• LGPD (Brazil), PIPEDA (Canada), PIPL (China), PDPA (Singapore, Thailand, Malaysia), APP (Australia) — Google Cloud publishes mappings to each regime.
• IRAP (Australian government — Infosec Registered Assessors Program) at the Protected level.
• C5 (Germany — Cloud Computing Compliance Criteria Catalogue).
• MTCS Tier 3 (Singapore).

Industry-Specific Regimes

• HIPAA / HITECH — for US healthcare. Google signs a Business Associate Agreement (BAA) that covers a defined list of "HIPAA-eligible products."
• PCI DSS Level 1 — Google Cloud is certified as a Level 1 service provider for handling cardholder data.
• FedRAMP Moderate and FedRAMP High — for US federal agencies.
• DoD Impact Levels (IL2, IL4, IL5) — Department of Defense workloads via Assured Workloads.
• CJIS — Criminal Justice Information Services for US law enforcement.
• FFIEC, SOX, GLBA — US financial services.
• NHS DSPT (UK National Health Service), HDS (France's Hébergeur de Données de Santé for health data hosting).

The Compliance Reports Manager

The Compliance Reports Manager is a self-service portal inside the Google Cloud Console where customers can download current audit reports — ISO certificates, SOC 2/3 reports, PCI DSS Attestation of Compliance (AoC), HIPAA mappings, and many more — without filing a support ticket. Auditors love this because it eliminates the back-and-forth of requesting evidence; Customers love it because they can pull fresh evidence at audit time. For CDL scenarios where the question is "how does the compliance team get the latest SOC 2 report for our cloud provider?", the answer is the Compliance Reports Manager.

Data Residency vs Data Sovereignty

This is the single most tested conceptual distinction in the compliance and privacy section of the CDL exam, and the two terms are often confused even by technical practitioners.

Data Residency — Where the Data Physically Lives

Data residency is a question of physical geography: in which country, region, or data center is the data actually stored? Google Cloud lets a customer pin data residency by choosing a region (e.g., europe-west4 in the Netherlands, asia-east1 in Taiwan, us-central1 in Iowa) for each storage resource. Multi-region buckets pin residency to a continent rather than a specific data center, while single-region resources guarantee the data never leaves that region's physical footprint.

Residency matters when a regulation says, "personal data of our citizens must be stored within our borders." Germany, Russia, China, India, and several other countries have explicit residency requirements for certain data classes. Setting residency in Google Cloud is usually as simple as picking the right region at resource-creation time and, for stronger guarantees, layering organization policy constraints like constraints/gcp.resourceLocations to prevent accidental creation of resources outside the approved regions.

Data Sovereignty — Which Country's Laws Govern the Data

Data sovereignty is a question of legal jurisdiction: which country's laws can be used to compel disclosure, demand access, or prosecute over the data? Even if data is physically stored in Frankfurt, if the cloud provider is a US-headquartered company, the US CLOUD Act can — in principle — compel the provider to hand over the data to US law enforcement. Sovereignty is therefore a function of the provider's corporate domicile, the personnel who can access the data, and the legal agreements in place between the provider and the customer.

Google Cloud addresses sovereignty concerns through several mechanisms: regional Sovereign Cloud partnerships (e.g., with T-Systems in Germany for the Sovereign Cloud by T-Systems offering, with Thales/S3NS in France for the Bleu offering, with Telecom Italia / TIM in Italy), Assured Workloads controls that restrict personnel access to in-region Google employees only, and Access Transparency logs that record every time a Google employee touches customer data.

Why Both Matter for GDPR

GDPR is the textbook example of why residency alone is insufficient. Article 44 of the GDPR restricts transfers of personal data to "third countries" that lack adequate data protection. The Schrems II ruling by the Court of Justice of the European Union invalidated the EU-US Privacy Shield in 2020, making it harder for EU data to flow to US-based providers. The 2023 EU-US Data Privacy Framework partially restored these flows, but enterprise customers — especially in heavily regulated sectors like banking, healthcare, and government — increasingly demand both residency-in-EU and sovereignty-from-EU-controlled-entities. Google Cloud's response is the Sovereign Cloud product line plus Assured Workloads with the EU Regions and Support control package.

Assured Workloads: The Control Plane for Regulated Workloads

Assured Workloads is the Google Cloud product that takes the heavy lift of regulatory configuration off the customer's plate. Instead of manually configuring region restrictions, IAM constraints, personnel access controls, CMEK requirements, and approved-product lists for every project, the customer picks a compliance regime at folder-creation time, and Assured Workloads enforces the matching controls automatically.

Supported Compliance Regimes

Assured Workloads currently supports control packages for:

• FedRAMP Moderate and FedRAMP High (US federal civilian agencies).
• DoD IL2, IL4, IL5 (US Department of Defense impact levels).
• CJIS (US Criminal Justice Information Services).
• HIPAA (US health care).
• HITRUST (healthcare-adjacent industry framework).
• ITAR (US International Traffic in Arms Regulations) — sensitive defense-related data.
• EU Regions and Support with Sovereignty Controls — for GDPR and EU sovereignty concerns.
• IL4 (UK Government), Canada Protected B, Israel Regions, Saudi Arabia Regions, Kingdom of Saudi Arabia data boundary.

What Assured Workloads Enforces

Once a folder is enrolled in an Assured Workloads regime, Google Cloud automatically:

• Restricts resource location to approved regions for the regime.
• Restricts personnel access so only Google employees who meet the required citizenship, background checks, and physical-location criteria can support the workload (e.g., US-persons-only for ITAR).
• Restricts product selection to a curated list of compliance-approved Google Cloud services.
• Enforces CMEK with HSM-backed keys for stronger cryptographic posture.
• Enables Access Transparency and Access Approval automatically.
• Logs every compliance-relevant configuration change to Cloud Audit Logs.

For the CDL exam, Assured Workloads is the answer whenever a scenario mentions a regulated US federal workload, a defense contractor, a healthcare provider that wants a turnkey HIPAA environment, or an EU enterprise that needs sovereignty controls — and the question asks "what is the fastest way to spin up a compliant environment?"

白話文解釋（Plain English Explanation）

Compliance, residency, and sovereignty are areas where the formal language obscures simple ideas. The analogies below each highlight a different facet of how Google Cloud's compliance and privacy story actually works.

Analogy 1 — The Food Safety Certification (HACCP, SGS, and Inherited Trust)

Imagine you open a Taiwanese-style beef noodle restaurant in a busy night market. Before customers will trust your food, your kitchen needs to pass HACCP (Hazard Analysis and Critical Control Points) inspection, the local Department of Health's hygiene audit, and ideally an SGS third-party certification stamped on the front window. These audits inspect refrigerator temperatures, ingredient sourcing, employee hand-washing logs, oil-change frequency, and incident-response procedures.

Now suppose you do not run your own kitchen — instead you rent a certified central kitchen that has already passed HACCP, the Health Department audit, and SGS. That central kitchen is Google Cloud's infrastructure. The day you move in, your operation inherits the certified storage temperatures, the certified ventilation, the certified sanitation procedures, and the audit logs the kitchen has been keeping for years. You do not need to re-certify the freezers — those are the central kitchen's responsibility. SOC 2, ISO 27001, PCI DSS, HIPAA, and FedRAMP work exactly this way: Google Cloud has certified the kitchen, and your workload inherits that foundation.

But — and this is the critical point — the certification only covers the kitchen, not your dish. If you use ingredients from an uncertified supplier, mishandle your noodles, or fail to wash your hands, the central kitchen's HACCP stamp does not save you. The Health Department will still fine you, the SGS auditor will still note the issue against your restaurant, and customers will still get sick. In Google Cloud terms, this is why a misconfigured public Cloud Storage bucket can still be a HIPAA breach, even though Google Cloud itself is HIPAA-eligible. The platform certification gives you a head start; the rest is on you. The Compliance Reports Manager is the wall of laminated certificates the central kitchen shows to inspectors — you can copy those certificates into your own audit binder, but you still need your own restaurant-specific records.

Analogy 2 — The Hospital Fire Marshal and Hygiene Inspection (Multiple Overlapping Audits)

A modern hospital does not pass just one audit; it passes a stack of overlapping audits simultaneously. The fire marshal inspects exits, sprinklers, smoke detectors, and evacuation plans. The public health inspector checks for hospital-acquired infection rates, sterilization logs, and biohazard disposal. The Joint Commission (or local equivalent) accredits the hospital's clinical practice. The medical board licenses the doctors. Each audit comes from a different authority, covers different controls, and is renewed on a different cycle.

Google Cloud's compliance portfolio is the same picture but for digital infrastructure. SOC 2 is the fire marshal — it inspects how you handle availability, confidentiality, and security incidents. ISO 27001 is the public health inspector — a broader management-system audit that asks "do you have policies, are you following them, and are you continuously improving them?" PCI DSS is the cardiology accreditation — only relevant if you handle payment cards, but extremely specific in what it requires. HIPAA is the medical-records audit. FedRAMP is the security clearance for treating government patients. GDPR is the patient-privacy ombudsman who can fine you up to four percent of revenue for releasing the wrong record to the wrong party.

The hospital analogy also clarifies why the Compliance Reports Manager is so valuable. Imagine if every time a patient asked, "Is this hospital safe?", the receptionist had to file a request with the city, wait three weeks, and then mail a paper copy. Instead, the lobby has a glass case with current certificates from the fire marshal, the health inspector, and the Joint Commission, all visible at a glance. That is what the Compliance Reports Manager does: ISO 27001 certificate, SOC 2 Type II report, PCI DSS Attestation of Compliance, HIPAA mapping — all downloadable, current, on demand. Auditors and customers can self-serve, and the security team is freed from playing receptionist.

Analogy 3 — The Airport TSA Security Audit (Assured Workloads and Personnel Restrictions)

Picture the security checkpoint at Taoyuan International Airport. Most areas use a standard security process — bag X-ray, walk-through metal detector, standard TSA-equivalent staff. But certain flights (diplomatic, military, head-of-state) move through a separate, fortified checkpoint with stricter rules: only personnel with specific clearance levels can staff that lane, only certain equipment is allowed through, every passenger and bag is logged in a special manifest, and the checkpoint operates only in a designated secured zone of the airport. The standard checkpoint is Google Cloud's general-purpose regions; the fortified checkpoint is Assured Workloads.

When a US Department of Defense workload needs to run in Google Cloud at Impact Level 4 (IL4), the customer does not configure dozens of individual controls. Instead, they create an Assured Workloads folder with the IL4 control package. Google Cloud then automatically restricts:

• The regions the resources can be created in (only DoD-approved regions).
• The products that can be used (only the curated list of IL4-approved services).
• The personnel who can troubleshoot or support the workload (only US persons with the required background checks).
• The encryption posture (HSM-backed CMEK with stronger controls).
• The audit logging (Access Transparency and Access Approval are mandatory).

This is the airport's special-clearance lane: everything is pre-configured, the staff is pre-vetted, the equipment is pre-approved, and the customer does not have to wire it all up themselves. The same model applies to FedRAMP High, CJIS, HIPAA, ITAR, and the EU Sovereignty package. For the CDL exam, the takeaway is: when a scenario says "we need to deploy a regulated workload quickly without manually configuring every guardrail," the answer is Assured Workloads with the matching control package.

Privacy Controls: From Detection to Exfiltration Prevention

Compliance frameworks like GDPR, HIPAA, and PCI DSS all share a common requirement: prevent unauthorized disclosure of regulated personal data. Google Cloud bundles several services that, together, form a defense-in-depth privacy stack.

Cloud DLP (Sensitive Data Protection) — Detect and Redact PII

Cloud DLP, officially rebranded as Sensitive Data Protection, scans data at rest in BigQuery and Cloud Storage and in transit through Pub/Sub or API streams. It recognizes more than 150 built-in infoTypes — credit card numbers (with Luhn validation), Taiwan ID card numbers, US Social Security numbers, EU IBAN account numbers, HIPAA medical record numbers, ICD-10 codes, email addresses, and more. Once detected, the data can be redacted, masked, tokenized, or format-preserving-encrypted before it flows into analytics dashboards, log aggregators, or partner exports. For the CDL exam, Cloud DLP is the canonical answer whenever a scenario mentions "PII leaking into logs" or "credit cards in BigQuery."

VPC Service Controls — Prevent Cross-Perimeter Exfiltration

VPC Service Controls draws an exfiltration-resistant perimeter around sensitive Google Cloud services — BigQuery, Cloud Storage, Spanner, Cloud KMS, and dozens more — so that even an authenticated user with valid IAM permissions cannot copy data out of the perimeter to an unapproved destination. Many compliance regimes (HIPAA's contingency rule, GDPR's transfer restrictions, PCI DSS network segmentation) explicitly call for boundary controls beyond IAM; VPC Service Controls is the answer.

Customer-Managed Encryption Keys (CMEK) — Proof of Cryptographic Control

CMEK lets the customer hold the Key Encryption Key inside Cloud KMS rather than letting Google generate it. From a compliance standpoint, CMEK provides the auditable evidence that the customer — not the provider — controls the cryptographic root of trust. Most regulated workloads require CMEK, and Assured Workloads mandates HSM-backed CMEK in many of its control packages. See Data Encryption and Protection for the full encryption story.

Access Transparency — Audit Logs of Google Employee Access

Access Transparency produces near-real-time audit logs every time a Google Cloud support engineer or operations employee accesses your data — including the justification, the resource, the action, and the employee's identity. For regimes like HIPAA, FedRAMP, and EU sovereignty, this is the evidence the auditor wants: "Show me a log of every time the provider's staff touched our data." Access Approval, a related feature, goes one step further by requiring you to explicitly approve the access before it happens.

Industry-Specific Compliance

Healthcare: HIPAA, the BAA, and Cloud Healthcare API

For US healthcare workloads, Google Cloud signs a Business Associate Agreement (BAA) that covers a specific list of HIPAA-eligible services. The BAA is mandatory under HIPAA for any vendor that processes Protected Health Information (PHI) on behalf of a covered entity. Customers cannot legally store PHI on Google Cloud without first executing the BAA and restricting workloads to HIPAA-eligible products.

The Cloud Healthcare API is purpose-built for healthcare data formats — HL7v2 messages, FHIR resources, DICOM medical imaging. It normalizes incoming clinical data, applies de-identification using infoTypes specific to healthcare, and stores it in a HIPAA-compliant manner. Cloud Healthcare Data Engine layers analytics on top, letting healthcare organizations run population-health analytics and clinical research on de-identified data while preserving compliance.

Financial Services: Sovereign Cloud Partners and Sector Frameworks

Financial services workloads frequently combine multiple regimes: PCI DSS for cardholder data, SOX for financial reporting controls, GLBA for US consumer financial privacy, FFIEC guidance for examiner expectations, plus regional regimes like MAS TRM (Singapore), APRA CPS 234 (Australia), or EBA Cloud Guidelines (Europe). Google Cloud's Sovereign Cloud partnerships address jurisdictions where the regulator additionally demands national-control of the operating personnel — Bleu in France, T-Systems Sovereign Cloud in Germany, and TIM-operated infrastructure in Italy are key examples.

Government and Defense

Government workloads use Assured Workloads with the matching control package — FedRAMP Moderate for civilian agencies, FedRAMP High for higher-sensitivity workloads, DoD IL2/IL4/IL5 for defense, CJIS for criminal justice, ITAR for arms-related data. Each package automatically restricts personnel access (often to US-persons-only), region availability, product selection, and audit posture.

How Compliance and Privacy Connect to Other CDL Topics

Compliance is the connective tissue between several CDL domains — security, identity, data, and shared responsibility.

• Shared responsibility — Compliance inheritance only works if the customer correctly understands which controls Google operates and which the customer operates. See Shared Responsibility Model for the boundary lines for IaaS, PaaS, and SaaS.
• Identity and Access Management — Most compliance regimes mandate least-privilege access, separation of duties, multi-factor authentication, and access reviews. See Identity and Access Management (IAM) for how IAM principals, roles, and conditions implement those mandates.
• Data Encryption and Protection — Almost every regulation (HIPAA, PCI DSS, GDPR, ISO 27001) requires encryption at rest and in transit; see Data Encryption and Protection for CMEK, Cloud DLP, VPC Service Controls, and Confidential Computing.
• Cloud Audit Logs — Auditors will ask for proof: who accessed what, when, and from where. Cloud Audit Logs (Admin Activity, Data Access, System Event, Policy Denied) plus Access Transparency form the evidence trail.

Common Compliance and Privacy Mistakes to Avoid

For the CDL exam, recognize these anti-patterns when they appear in scenarios.

1. Treating Google Cloud's certifications as the customer's certifications. Inheritance covers the infrastructure layer only; you still need your own application-layer audit.
2. Confusing data residency with data sovereignty. Residency is geographic, sovereignty is legal. Pinning a bucket to europe-west4 does not automatically address GDPR sovereignty concerns.
3. Storing PHI on Google Cloud without signing the BAA. Even with strong encryption, this is a HIPAA violation. The BAA must be executed first, and workloads restricted to HIPAA-eligible services.
4. Skipping Cloud DLP scans on data exports. PII can sneak into free-text fields, customer-service notes, log lines, and analytics outputs. Always scan before exporting to partners or analytics warehouses.
5. Granting broad IAM roles to satisfy compliance "just in case." Compliance frameworks generally penalize over-permissioning. Use the least-privileged predefined or custom role.
6. Forgetting the Compliance Reports Manager exists. Customers waste time filing support tickets for SOC 2 reports that they could have downloaded in 30 seconds.

Frequently Asked Questions

Does Google Cloud being SOC 2 certified mean my application is SOC 2 compliant?

No. Google Cloud's SOC 2 Type II certification covers the infrastructure Google operates — physical data centers, network, hypervisor, default encryption, identity infrastructure, and the managed services Google runs. It does not cover your application's user authentication, your access-control logic, your change-management process, your incident-response runbooks, or your audit logs. To claim SOC 2 compliance for your own application, you must engage a SOC 2 auditor, design and document your own controls, and produce your own evidence. Google Cloud's SOC 2 report is a useful subservice organization report that your auditor can rely on for the platform layer, but the application-layer audit is still your responsibility.

What is the difference between data residency and data sovereignty?

Data residency is geographic: in which country or region is the data physically stored? You control this in Google Cloud by selecting the region for each resource and enforcing it with organization policies like constraints/gcp.resourceLocations. Data sovereignty is legal: which country's laws can be used to compel disclosure of the data? Sovereignty is a function of the provider's corporate domicile, the personnel who can access the data, and any cross-border legal frameworks like the US CLOUD Act. A workload can have its residency pinned to the EU while still being subject to US legal process if the provider is a US company. To address sovereignty, you typically need Assured Workloads with the EU Sovereignty control package, a Sovereign Cloud partner (T-Systems, Bleu, TIM), or Access Transparency with EU-only personnel restrictions.

When do I need Assured Workloads versus standard Google Cloud?

Use Assured Workloads when your workload falls under a specific regulated regime that has prescriptive requirements — FedRAMP Moderate or High, DoD IL2/IL4/IL5, CJIS, HIPAA, ITAR, the EU Sovereignty package, or one of the regional packages (UK, Canada, Israel, Saudi Arabia). Assured Workloads automatically enforces region restrictions, personnel access controls, product allowlists, CMEK with HSM backing, and Access Transparency. If your workload is general-purpose with no specific regulated-regime requirement, standard Google Cloud projects with manually configured IAM, CMEK, and VPC Service Controls are usually sufficient. The trigger phrase for Assured Workloads in CDL scenarios is "we need a turnkey environment that meets X regulation without manual configuration."

How do I prove to an auditor that Google Cloud is compliant with ISO 27001?

Use the Compliance Reports Manager inside the Google Cloud Console. It lets you download current copies of Google Cloud's ISO 27001 certificate, SOC 2/3 reports, PCI DSS Attestation of Compliance, HIPAA mappings, FedRAMP authorizations, and many more — all without filing a support ticket. Provide the downloaded artifact to your auditor as evidence of the subservice organization's controls. Your auditor will then assess whether your application-layer controls, layered on top of the certified platform, meet the relevant standard. The Compliance Reports Manager is updated continuously as new audits complete, so you always pull the latest version at audit time.

What is Access Transparency, and why do regulators care about it?

Access Transparency is a near-real-time audit log of every action that Google Cloud personnel (support engineers, operations staff) take on your data — what they accessed, when, for what reason, and which employee performed the action. Regulators care because most compliance regimes (HIPAA, FedRAMP, GDPR sovereignty packages) require the customer to be able to prove that provider access to regulated data is monitored, justified, and reviewable. Without Access Transparency, the customer would have to trust the provider's word that staff did not snoop on the data; with Access Transparency, the customer has the evidence trail. Access Approval goes one step further by letting the customer explicitly approve the access before it happens, providing a real-time gating control. Both are mandatory under several Assured Workloads control packages.

Is signing the HIPAA BAA enough to store Protected Health Information on Google Cloud?

No — signing the Business Associate Agreement (BAA) is necessary but not sufficient. After signing, you must additionally:

1. Restrict your workloads to the HIPAA-eligible products list (not every Google Cloud service is in scope).
2. Configure those workloads correctly — enable encryption at rest with CMEK if your security review requires it, enable audit logging, lock down IAM to least privilege, and consider VPC Service Controls for the PHI perimeter.
3. Use the Cloud Healthcare API for HL7v2, FHIR, and DICOM workloads to get the purpose-built compliance behavior.
4. Operate your application-layer HIPAA controls — workforce training, breach-notification procedures, business-continuity plans, and your own audit logs.

A misconfigured public Cloud Storage bucket containing PHI is still a HIPAA breach even with a signed BAA in place. The BAA is the legal foundation; the technical configuration is the customer's responsibility.

Summary: Compliance as the License to Operate

For the Cloud Digital Leader exam, compliance and privacy is the topic that translates regulatory pressure into Google Cloud product choices. Remember the three tiers: global standards (ISO 27001, ISO 27017, ISO 27018, SOC 2, CSA STAR), regional regimes (GDPR, LGPD, PIPL, IRAP), and industry-specific frameworks (HIPAA, PCI DSS, FedRAMP, CJIS, ITAR). Remember that Google Cloud certifies the infrastructure layer, and customers inherit that foundation — but the application layer is always the customer's responsibility.

Remember the residency-versus-sovereignty distinction: residency is geographic, sovereignty is legal, and addressing both often requires Assured Workloads or a Sovereign Cloud partnership. Remember the privacy-control stack: Cloud DLP / Sensitive Data Protection to detect PII, VPC Service Controls to prevent exfiltration, CMEK to prove cryptographic control, and Access Transparency to witness provider access. Remember the Compliance Reports Manager as the self-service portal for downloading audit evidence.

A CDL who can map a business requirement ("we need to onboard EU healthcare customers without losing FDA-equivalent oversight") to the right combination of Google Cloud features — Cloud Healthcare API plus a signed BAA plus Assured Workloads EU Sovereignty plus VPC Service Controls plus CMEK plus Access Transparency — is exactly the strategic advisor that modern enterprises need at the table when compliance and growth collide. Compliance is not a tax on cloud adoption; in Google Cloud, it is a feature set that, used correctly, becomes a competitive advantage.