Compliance and Regulatory Governance

Introduction to Compliance on Google Cloud

For a Professional Cloud Architect, compliance is not just a legal checkbox—it's a fundamental architectural constraint. Whether you are handling medical records in the US (HIPAA), personal data in the EU (GDPR), or financial transactions globally (PCI-DSS, SOC2), you must understand how Google Cloud helps you meet these requirements through a combination of platform security and documented proof.

The foundation of all compliance conversations is the Shared Responsibility Model.

Plain-Language Explanation:

Compliance is essentially "proving you are doing what you said you would do."

Analogy 1 — The Certified Safe (Shared Responsibility)

Imagine you rent a Safe at a world-class bank. The bank is responsible for the building's security, the vault's thick walls, and the security guards (Security of the Cloud). However, you are responsible for who you give a key to and what you put inside the safe (Security in the Cloud). If you leave the safe door wide open (bad IAM) or store something illegal inside (non-compliant data), the bank isn't at fault.

Analogy 2 — The Kitchen Inspection (SOC2/SOC3)

A SOC2 report is like a detailed health inspector's report for a restaurant. It looks at the processes: Are the chefs washing their hands? Is the meat stored at the right temperature? Is there a log of every delivery? A SOC3 is the "A-Grade" sticker in the window—a summary meant for the public, while SOC2 is the 50-page detailed report for the owners and auditors.

Analogy 3 — The Border Control (Data Residency)

Data Residency is like Visa Requirements. Some data (like EU citizen info under GDPR) needs a "visa" to stay within a specific geographic border. As an architect, you use Resource Location Restrictions (Organization Policies) to ensure that data "never leaves the country" (or region), just like a border agent ensures people don't cross without permission.

Key Regulatory Frameworks

1. GDPR (General Data Protection Regulation)

Focused on the privacy of EU citizens.

• Data Processor: Google Cloud (acting on your behalf).
• Data Controller: You (owning the data).
• Key requirement: Right to be forgotten, data portability, and breach notification.

2. HIPAA (Health Insurance Portability and Accountability Act)

Focused on US healthcare data (PHI).

• BAA (Business Associate Agreement): You MUST sign a BAA with Google before storing any PHI on GCP.
• Scoped Services: Not all GCP services are HIPAA-compliant. You must only use "HIPAA-covered" services.

3. SOC 2 and SOC 3

Service Organization Controls.

• SOC 2 Type II: Evaluates the effectiveness of controls over a period of time (usually 6-12 months). Highly confidential.
• SOC 3: A public summary of the SOC 2 report.

Tools for Compliance Management

Compliance Reports Manager

A central portal where you can download Google's third-party audit reports (SOC, ISO, PCI) and certificates. You provide these to your own auditors to prove Google is doing its part.

Cloud Asset Inventory

Allows you to export the state of all your resources at a specific point in time. Essential for "Snapshot" audits where you must prove your firewall rules were correct on a specific date.

Organization Policies

The most powerful tool for "Prevention as Compliance."

• Resource Location Restriction: Prevents users from creating resources outside of approved regions.
• Restrict Peerings: Prevents unauthorized network connections that could leak data.

Data Sovereignty and Residency

Architects must distinguish between:

• Data at Rest: Stored on disks. Controlled via bucket/disk location.
• Data in Transit: Moving over the network. Google encrypts all traffic between data centers by default.
• Data in Use: Data in RAM. Solved via Confidential Computing (Confidential VMs/GKE nodes), which encrypts data in memory.

GDPR Deep Dive — Article 28, Data Subject Rights, and 72-Hour Breach Notification

The General Data Protection Regulation (GDPR) applies whenever you process personal data of individuals in the EU/EEA, regardless of where your company is incorporated. As a PCA, you should know the three pillars Google addresses.

Article 28 — Data Processing Addendum (Cloud DPA)

Article 28 requires a written contract between the controller (you) and the processor (Google). Google offers the Cloud Data Processing Addendum (CDPA), automatically incorporated when you accept the Google Cloud Terms of Service. The CDPA covers Article 28 obligations including sub-processor disclosure, security measures, and audit rights. Google publishes its sub-processor list at cloud.google.com/terms/subprocessors.

Data Subject Rights (Articles 15–22)

You must support access, rectification, erasure (right to be forgotten), portability, and restriction. Architectural patterns:

• Cloud Storage / BigQuery erasure: Tag records with the subject's pseudonymous ID; run scheduled DELETE jobs or bq query --destination_table rewrites. Soft-delete buckets and Object Versioning must also be purged.
• Cloud SQL / Spanner: Use row-level DELETE plus PITR retention review — backups within the retention window still contain the data.
• Logging: Cloud Logging retains audit logs up to 400 days; you cannot delete _Required log buckets, but you can route _Default logs to short-retention sinks if they contain personal data.

Article 33 — 72-Hour Breach Notification

Google notifies you "without undue delay" via the Cloud Console and registered contacts. Your 72-hour clock to notify the supervisory authority starts when you become aware. Wire Security Command Center Premium findings and Cloud DLP scan results into a PagerDuty / ticketing pipeline so the legal team is paged immediately.

HIPAA on GCP — BAA Scope and Covered Services

HIPAA governs Protected Health Information (PHI) in the United States. You must execute a Business Associate Agreement (BAA) with Google before any PHI lands in GCP.

Signing the BAA

The BAA is requested through the Google Cloud Console → IAM & Admin → Settings, or via your account team for Enterprise contracts. It applies at the Organization level and covers all projects under it, provided you only use HIPAA-eligible services.

HIPAA-Eligible Services (representative, not exhaustive)

• Compute: Compute Engine, GKE, Cloud Run, App Engine standard/flex, Cloud Functions.
• Storage / Database: Cloud Storage, Persistent Disk, Cloud SQL, Spanner, Firestore, Bigtable, BigQuery.
• Networking: VPC, Cloud Load Balancing, Cloud Interconnect, Cloud DNS.
• Operations: Cloud Logging, Cloud Monitoring, Cloud Trace.
• Healthcare-specific: Cloud Healthcare API (FHIR, HL7v2, DICOM stores) — purpose-built for PHI.
• Security: Cloud KMS, Cloud HSM, Secret Manager, Cloud IAM, VPC Service Controls.

NOT in the BAA scope (PHI must not flow through these)

At various times services like certain preview / GA-pending features, third-party Marketplace SaaS, and some Workspace-adjacent tools have been excluded. Always check the current published list at cloud.google.com/security/compliance/hipaa-compliance before architecting.

SOC 2 Type II, ISO 27001/27017/27018, and FedRAMP

Architects often need to demonstrate that the underlying platform meets specific certifications.

SOC 2 Type II

Google undergoes annual SOC 2 Type II audits performed by an independent CPA firm against the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). The report covers a 12-month window. You download it from Compliance Reports Manager under NDA.

ISO/IEC 27001, 27017, 27018

• ISO 27001 — Information security management system (ISMS).
• ISO 27017 — Cloud-specific controls (extension of 27002 for cloud providers).
• ISO 27018 — Protection of PII in public clouds (aligns well with GDPR).

Google publishes its ISO certificates and Statement of Applicability via the Compliance Reports Manager. As an architect, you inherit those controls for infrastructure but must implement your own ISMS for the application layer.

FedRAMP Moderate and High

For US Government workloads, GCP holds FedRAMP High authorization for an Assured Workloads boundary in us-central1 and other authorized regions. To run a workload under FedRAMP:

1. Enable Assured Workloads and select the FedRAMP Moderate or FedRAMP High compliance regime.
2. The created folder enforces personnel controls (US persons), data residency, and approved CMEK key locations.
3. Only FedRAMP-authorized services can be enabled inside that folder — guardrails are applied automatically.

PCI DSS v4.0 and Tokenization Patterns

For payment workloads, PCI DSS v4.0 is the current standard (mandatory March 2025). GCP is a PCI DSS Level 1 Service Provider, attested annually by a QSA. You inherit infrastructure controls, but scope reduction is your responsibility.

Tokenization to reduce PCI scope

Storing the raw Primary Account Number (PAN) pulls every service that touches it into PCI scope. GCP patterns to shrink the cardholder data environment (CDE):

• Sensitive Data Protection (Cloud DLP) — Cryptographic Tokenization: Use FPE (Format-Preserving Encryption) or deterministic encryption transformations with a wrapped key in Cloud KMS. The PAN is replaced with a token of the same format; downstream BigQuery / analytics systems operate on tokens and stay out of CDE scope.
• Third-party token vault on GKE: Run a tokenization service in a dedicated project behind VPC Service Controls, with PAN storage only on CMEK-encrypted Persistent Disks. Other application projects only see tokens.
• Payment gateway pass-through: Use a PCI-validated processor (Stripe, Adyen) with hosted fields so the PAN never enters your GCP project at all — the recommended pattern when feasible.

PCI-required controls you must implement

• Network segmentation — separate VPC for the CDE, with Hierarchical Firewall Policies at the Organization or Folder level.
• Cloud KMS with annual key rotation (--rotation-period=31536000s).
• Cloud Logging audit trail retained ≥ 12 months (PCI Req. 10.7), exported to a write-once Cloud Storage bucket with Bucket Lock.
• Quarterly vulnerability scans via Web Security Scanner and external ASV.

Enforcing Data Residency with Organization Policies

Many regulations (GDPR, German BDSG, Australia IRAP, Korea PIPA) require data to physically stay in specific regions. The PCA-level tool is the Organization Policy Service.

Key constraint: constraints/gcp.resourceLocations

A list constraint that defines which Google Cloud locations are allowed for resource creation. You can use value groups for convenience:

gcloud resource-manager org-policies set-policy \
  --organization=123456789012 policy.yaml

# policy.yaml
constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - in:eu-locations          # all EU regions
    - in:europe-west4-locations
  inheritFromParent: false

Value groups include in:us-locations, in:eu-locations, in:asia-locations, plus single-region groups like in:europe-west4-locations. You can attach the policy at Organization, Folder, or Project level — child resources inherit unless overridden.

What it blocks

Cloud Storage bucket creation outside the list, Compute Engine VMs / disks, BigQuery datasets, Cloud SQL instances, Spanner instances, Pub/Sub message storage policy (when set), Cloud Functions, etc. The policy is enforced at admission time — existing resources are not moved.

Companion constraints

• constraints/storage.uniformBucketLevelAccess — forces uniform IAM (no per-object ACLs that can leak data outside region intent).
• constraints/compute.restrictVpcPeering — blocks peerings that could exfiltrate traffic to non-compliant networks.
• constraints/iam.allowedPolicyMemberDomains — restrict IAM grants to your verified Cloud Identity domain.

Sensitive Data Protection (Cloud DLP) for PII Discovery and De-identification

Sensitive Data Protection (formerly Cloud DLP) is the GCP-native service for finding, classifying, and de-identifying PII / PHI / PCI data.

Discovery — find what you have

• Inspection jobs scan Cloud Storage, BigQuery, and Datastore for infoTypes like EMAIL_ADDRESS, US_SOCIAL_SECURITY_NUMBER, CREDIT_CARD_NUMBER, PERSON_NAME, MEDICAL_RECORD_NUMBER. Over 150 built-in detectors plus custom regex and stored infoTypes (dictionary-based).
• Discovery service runs continuously across BigQuery, automatically profiling new tables and flagging sensitive columns into Data Catalog / Dataplex tags.

De-identification transformations

• Redaction / masking — replace with * or a fixed string.
• Pseudonymization — CryptoReplaceFfxFpeConfig (format-preserving), CryptoDeterministicConfig (joinable across tables), CryptoHashConfig (one-way).
• Date shifting — preserves intervals for analytics while obscuring exact dates.
• Generalization / bucketing — convert age 34 to 30-40.
• k-anonymity / l-diversity risk analysis — verify a dataset cannot be re-identified.

Re-identification with KMS-wrapped keys

For FPE / deterministic transforms, store the wrapped key reference (kmsWrapped.cryptoKeyName) so only authorized service accounts can reverse the token. This is the building block behind the PCI tokenization pattern above.

Compliance Reports Manager — Proving Google's Side

When your auditor asks "show me proof that Google is doing what they claim," the answer is the Compliance Reports Manager at cloud.google.com/security/compliance/compliance-reports-manager.

What you can download

• SOC 1, SOC 2, SOC 3 reports (Google Cloud + Workspace).
• ISO/IEC 27001, 27017, 27018, 27701 certificates and Statements of Applicability.
• PCI DSS Attestation of Compliance (AoC).
• HIPAA / HITECH implementation guides.
• FedRAMP package (under controlled access).
• C5 (Germany), IRAP (Australia), MTCS (Singapore), and region-specific reports.

Access workflow

1. Sign in with a Cloud Identity user that has the roles/compliancecenter.viewer (or be the Organization Admin).
2. Accept the NDA / confidentiality terms displayed in the portal — SOC 2 and FedRAMP reports are confidential.
3. Download PDFs and hand them to your external auditor as inherited control evidence.

Pairing with Cloud Asset Inventory

Auditors typically ask: "Prove that on 2025-Q4-end your firewall rules permitted only TLS 1.2+." Combine the Compliance Reports Manager (Google's side) with a Cloud Asset Inventory export at that timestamp (your side):

gcloud asset export \
  --organization=123456789012 \
  --asset-types=compute.googleapis.com/Firewall \
  --snapshot-time=2025-12-31T23:59:59Z \
  --output-path=gs://audit-evidence/2025-q4/firewalls.json

The combination is the gold-standard answer for "snapshot audit" exam questions.

Security vs. Compliance

FAQ — Compliance (GDPR, HIPAA, SOC2)

Q1. Where do I sign the HIPAA BAA?

The BAA is typically signed via the Google Cloud Console under the "Security" or "Legal" sections, or through your account representative.

Q2. Is my data on GCP GDPR-compliant by default?

No. GCP provides the tools to be compliant (encryption, location controls), but you are responsible for how you handle the data and your own privacy policies.

Q3. What is the difference between SOC 2 Type I and Type II?

Type I is a "point in time" snapshot of controls. Type II tests the controls over a period of time (e.g., 6 months). Type II is much more valuable for audits.

Q4. Can I store data anywhere in the world?

Technically yes, but legally maybe no. Use Organization Policies to enforce "Resource Location Restrictions" to ensure data stays within specific geographic boundaries.

Q5. Does Google have access to my data?

Google employees do not have access to your data except in rare support cases, which are logged and can be controlled via Access Transparency and Access Approval.

Final Architect Tip

For the PCA exam, remember: Google provides the certification for the infrastructure, but you are responsible for the application's compliance. If a question asks about "proving" Google's security to an auditor, the answer is always Compliance Reports Manager. If it asks about "preventing" resources from being created in a specific region for legal reasons, the answer is Organization Policies.