Book TOC · Previous · Chapter 6 of 7 · Next

Chapter 6: Regulatory Compliance & Sovereignty: Assured Workloads, Access Approval & Audit Descoping

Subsections Covered: 5.1 (5 Considerations · 10 Custom Visual Diagrams)

Chapter Focus: Assured Workloads (FedRAMP, CJIS, IL4, EU Data Boundary), Key Access Justifications, Access Transparency vs. Access Approval, PCI-DSS tokenization descoping, HIPAA, and Shared Fate.

Subsection 5.1: Adhering to regulatory and industry standards requirements for the cloud

Section 5: Supporting compliance requirements

The Big Picture

In Section 5 of the Architecture Stack, technical security controls meet legal and industry frameworks (PCI-DSS, HIPAA, GDPR, FedRAMP High, DoD IL4, CJIS, SOX/SEC Rule 17a-4). Organizations that treat compliance as a manual checklist rather than an automated cloud architecture fail audits in four ways:

1. Letting Raw Sensitive Data Pollute the Entire Cloud Footprint (5.1a, 5.1d, 5.1e): Under PCI-DSS, any project, VPC, or BigQuery dataset that stores, processes, or transmits cleartext Primary Account Numbers (PANs) or Cardholder Data (CHD) falls inside the Cardholder Data Environment (CDE) audit scope. If an ingestion pipeline dumps raw JSON payloads containing credit card numbers directly into a general analytics project, your entire analytics platform is dragged into PCI-DSS scope! The gold-standard architectural pattern is:
2. Isolate the CDE inside a dedicated Folder, dedicated Project, dedicated VPC, and dedicated VPC Service Controls perimeter.
3. At the CDE ingress boundary, use Sensitive Data Protection (Cloud DLP) (or a dedicated tokenization proxy) to tokenize / de-identify PANs before sending the records to downstream BigQuery analytics projects—descoping the downstream analytics environment from PCI-DSS!
4. Misunderstanding the Cloud Shared Responsibility Model (5.1b):
5. Google is always responsible for Security OF the Cloud: Physical data center security, biometric access, hardware maintenance, disk destruction, and the host hypervisor. (Note: Customers never get physical data center tours! To verify Google's physical controls for an auditor, download Google's independent SOC 2 Type II / ISO 27001 / PCI-DSS AOC reports from the Compliance Reports Manager).
6. Customer Responsibility Scales by Service Model (IaaS → CaaS → PaaS → SaaS):
7. On Compute Engine (IaaS), the Customer is 100% responsible for Guest OS kernel patching, local firewalls, and application security.
8. On App Engine Standard / Cloud Run / Cloud Functions (Serverless PaaS) and BigQuery / Cloud Storage, Google patches the underlying OS and managed runtime environment, while the Customer remains responsible for IAM policies, data classification, CMEK/VPC-SC configuration, and application logic.
9. Manual Sovereignty Setup vs. Assured Workloads (5.1c): When a government or regulated enterprise workload requires FedRAMP High, Department of Defense Impact Level 4 (IL4), CJIS, or EU Sovereign Controls—requiring data residency in specific regions, cryptographic FIPS 140-2 Level 3 CMEK, and restricting Google support operations to vetted US Persons or EU Personnel—manually configuring Organization Policies is incomplete because Organization Policies alone cannot restrict which Google support personnel handle support tickets! You must provision an Assured Workloads Folder, which automatically enforces regionalization (constraints/gcp.resourceLocations), CMEK, and sovereign support personnel controls in one turnkey boundary.
10. Confusing Access Transparency with Access Approval (5.1c):
11. Access Transparency (Detective / Audit Visibility): Generates near-real-time immutable audit logs whenever Google support or engineering personnel interact with your data, recording the business justification (e.g., your support case number), principal role, and resource accessed.
12. Access Approval (Preventive / Explicit Pre-Authorization): Requires Google support/engineering personnel to request explicit customer approval (approved manually in the Console, via email/Pub/Sub, or cryptographically signed with a customer-owned Cloud KMS key) before they can access your customer content!

Consideration 5.1a: Determining technical needs relative to compute, data, network, and storage

• Storage Immutability (SEC Rule 17a-4, FINRA, HIPAA, CFTC): Configure a Cloud Storage Retention Policy for the required duration (e.g., 7 years) and Lock the Retention Policy (Bucket Lock) to enforce irreversible WORM (Write Once, Read Many) compliance. Even a Super Admin or Project Owner cannot delete an object or shorten a locked retention policy without deleting the entire project (and if an Object Hold is placed for legal discovery, the object stays protected even past the retention expiration!).
• Database RPO / RTO Compliance: When financial regulations require a Recovery Point Objective (RPO) of less than 5 minutes on Cloud SQL, enable Automated Backups AND Point-in-Time Recovery (PITR) (which archives continuous write-ahead transaction logs to Cloud Storage, allowing recovery to any specific second). For near-zero Recovery Time Objective (RTO) across zones, enable Cloud SQL High Availability (Regional HA) with synchronous standby replication.
• Data Residency: Enforce constraints/gcp.resourceLocations at the Organization or Folder node (e.g., in:eu-locations or europe-west3) so no compute disk, bucket, or BigQuery dataset can be provisioned outside the legally mandated jurisdiction.

Key Implementation Patterns

• Data Residency Enforcement: Use Define an Organization Policy using the gcp.resourceLocations constraint. specific the Frankfurt region as the only allowed value in the policy. The gcp.resourceLocations Organization Policy constraint is the standard method to enforce data residency and restrict resource creation to specific regions.
• WORM Compliance for Financial Records: Use Configure a Retention Policy on the bucket for seven years and lock the policy. Locking a retention policy enforces WORM compliance, preventing deletion or modification for the specified duration. (Avoid alternative: Versioning preserves history but does not strictly prevent permanent deletion by authorized administrators.)
• PCI DSS Scope Reduction: Use Create a dedicated Virtual Private Cloud (VPC) network for the CDE. Use tokenization to replace card data with non-sensitive tokens. Configure VPC Service Controls to define a security perimeter. A dedicated VPC ensures network isolation, and tokenization removes sensitive data from downstream scope, both of which are best practices for PCI DSS scope reduction.

Key Takeaways (5.1a)

• Organization Policies provide centralized control over resource configuration and location across the resource hierarchy.
• The gcp.resourceLocations constraint is used to enforce data residency by restricting resource creation to specific regions.
• Prefer preventative controls (blocking actions) over reactive controls (detecting and fixing) for strict compliance requirements.
• Retention Policies enforce how long data must be kept before it can be deleted.

Consideration 5.1b: Evaluating the shared responsibility model

• Who Patches What:
• Compute Engine (IaaS): Customer patches the Guest OS kernel and packages (using VM Manager OS Patch Management or golden image rebuilds).
• GKE Standard (CaaS): Google manages the Kubernetes Control Plane; Customer configures node auto-upgrade, container base images, and NetworkPolicies.
• App Engine Standard / Cloud Run / Cloud Functions (Serverless PaaS): Google patches both the host OS and the managed language runtime; Customer secures application code, dependencies, and IAM bindings.
• How to Satisfy Physical Security Auditors: Google never permits external auditors to physically tour Google data centers. Instead, open Compliance Reports Manager in the Google Cloud Console (Security > Compliance Reports Manager) and download Google's independent third-party SOC 2 Type II, ISO/IEC 27001, PCI-DSS AOC, or FedRAMP audit reports.

Key Implementation Patterns

• IaaS OS Patch Management for PCI DSS: Use Configure a patch management process to update the operating system, because you are responsible for the guest operating system security. In an IaaS model like Compute Engine, the customer is responsible for the security and patching of the guest operating system.
• Physical Security Verification for SOC 2: Use Download Google's latest SOC 2 Type II report from the Compliance Reports Manager and provide it to the auditor. In the shared responsibility model, you validate Google's physical security controls by reviewing their third-party audit reports.

Key Takeaways (5.1b)

• In an IaaS model (Compute Engine), the customer is responsible for the Guest OS, including patching and security configuration.
• Google is responsible for the physical security and the underlying infrastructure (hardware and hypervisor).
• Compliance standards like PCI DSS often require strict patching timelines that the customer must actively manage in IaaS environments.
• Do not assume automatic security for components you have administrative control over, such as the OS.

Consideration 5.1c: Configuring cloud security controls to support compliance such as Assured Workloads and regionalization

• Assured Workloads (Turnkey Sovereign Compliance Folders):
• Automatically creates a dedicated Folder pre-configured with strict Organization Policies (gcp.resourceLocations, CMEK enforcement), VPC/encryption templates, and Google Support Personnel Access Controls for regimes including FedRAMP Moderate/High, DoD Impact Level 4 (IL4), CJIS, ITAR, and EU Regions and Support.
• Whenever an architecture reviews mentions FedRAMP, IL4, CJIS, or requiring US-citizen / EU-resident Google support personnel, the answer is Assured Workloads!
• Access Transparency vs. Access Approval:
• Access Transparency: Provides near-real-time audit logs of actions taken by Google personnel when accessing customer content (detective visibility).
• Access Approval: Requires Google personnel to obtain explicit prior approval from the customer before accessing customer data during a support case (preventive gate).

Key Implementation Patterns

• FedRAMP High Environment Setup: Use Use Assured Workloads to create a new folder with the FedRAMP High settings and US location. Assured Workloads automatically configures the folder, policies, and support routing needed for FedRAMP High compliance. (Avoid alternative: Manual policies do not automatically enable compliant support routing or the full suite of FedRAMP High controls.)
• EU Data Sovereignty and Residency: Use Create an Assured Workloads folder using the "EU Regions and Support" control package. Create your projects within this folder. Assured Workloads automatically configures the necessary Organization Policies and compliance controls for data residency in specific regions.
• Personnel Access Controls for DoD Data: Use Create an Assured Workloads folder and select the Department of Defense IL4 compliance regime. Assured Workloads with the IL4 regime automatically enforces US Support, restricting support access to US Persons in the US. (Avoid alternative: VPC Service Controls manage network perimeters and data exfiltration, not the personnel restrictions of Google support staff.)

Key Takeaways (5.1c)

• Assured Workloads simplifies compliance by creating a secure folder with pre-configured settings.
• It enforces data residency by restricting resource locations via Organization Policies.
• It provides Assured Support to ensure technical support meets regulatory personnel requirements.
• Always prefer automated compliance tools over manual configuration for regulatory environments.

Consideration 5.1d: Determining the Google Cloud environment in regulatory scope

• Minimizing Audit Scope via Segmentation & Tokenization (Descoping):
• Never mix regulated workloads (PCI-DSS Cardholder Data, HIPAA ePHI) with unregulated dev/test or marketing workloads in the same Project or VPC!
• Isolate regulated workloads into a dedicated CDE Folder / Project / VPC / VPC-SC Perimeter, and use Sensitive Data Protection (Cloud DLP) to tokenize or redact sensitive identifiers before data leaves the regulated boundary. Downstream BigQuery or Vertex AI projects that receive only irreversible tokens or de-identified surrogates are descoped from the audit!
• HIPAA Business Associate Agreement (BAA) & Pre-GA / Beta Services: Before introducing any new or Beta / Preview Google Cloud service into a HIPAA-regulated workload, you must verify that the service is explicitly listed on Google Cloud's HIPAA Included Products (BAA-covered) list—never process ePHI on a Beta feature that is not covered by the BAA!

Key Implementation Patterns

• PCI DSS Scope Reduction via Tokenization: Use Replace the credit card numbers with tokens using a dedicated tokenization service before you upload the data. Tokenization replaces sensitive data with non-sensitive tokens before ingestion, effectively removing the storage environment from PCI DSS scope.
• HIPAA BAA Service Eligibility: Use Verify if the Beta service is included in the list of products covered by the BAA. You must verify if a specific service is listed as a covered product under the BAA before using it for PHI. (Avoid alternative: A BAA does not cover all services automatically, especially those in Beta.)
• Geographic Scope Enforcement: Use Configure the Organization Policy constraint constraints/gcp.resourceLocations to allow only European Union regions. The Resource Location Restriction Organization Policy specifically limits the regions where resources can be created.

Key Takeaways (5.1d)

• Tokenization is a key strategy for reducing regulatory scope (descoping) by replacing sensitive data with non-sensitive tokens.
• To descope a system, sensitive data must be transformed before entering that system.
• Encryption protects data but does not necessarily remove it from regulatory scope.
• IAM and access controls are compliance requirements but do not reduce the scope itself.

Consideration 5.1e: Mapping compliance requirements to Google Cloud services and controls

Use this direct mapping whenever an production scenarios describes a regulatory requirement in plain English:

• "Prevent cardholder data from being copied outside the CDE" → VPC Service Controls (VPC-SC) + Dedicated VPC.
• "Ensure no single administrator can both manage encryption keys and read encrypted data" → IAM Separation of Duties (roles/cloudkms.admin vs. roles/cloudkms.cryptoKeyEncrypterDecrypter).
• "Mask PANs in BigQuery while preserving join keys across tables" → Sensitive Data Protection (Cloud DLP) with Deterministic Encryption (AES-SIV) or FPE.
• "Ensure every read and write to sensitive health records is captured in an immutable 7-year audit trail" → Enable Data Access Audit Logs (DATA_READ, DATA_WRITE) + Aggregated Log Sink to a Cloud Storage Archive bucket with Locked Retention Policy (Bucket Lock).

Key Implementation Patterns

• PCI-DSS Data De-identification: Use Use Sensitive Data Protection to de-identify the PANs before ingesting the data into BigQuery. Sensitive Data Protection modifies the data (e.g., masking) to protect PII before storage, meeting the requirement to not store raw PANs. (Avoid alternative: IAM restricts access but does not modify the underlying data storage, leaving raw PANs exposed on disk.)
• FedRAMP High Configuration: Use Use Assured Workloads to create a folder configured with the FedRAMP High and IL4 compliance regime. Assured Workloads automatically configures a folder with the necessary policies to enforce specific regulatory compliance. (Avoid alternative: Manual configuration is error-prone and requires constant maintenance to track compliant services.)
• Data Residency Enforcement: Use Define a Resource Location Restriction constraint in the Organization Policy Service allowing only europe-west3, and apply it to the organization. Organization Policies provide central control over resource configuration, including restricting physical resource locations.

Key Takeaways (5.1e)

• Sensitive Data Protection (Cloud DLP) is the primary tool for inspecting and de-identifying PII/sensitive data.
• Compliance standards like PCI-DSS often require masking or tokenizing sensitive fields, not just encrypting the storage.
• Encryption at rest (CMEK) protects against physical theft but does not obscure data values from authorized applications.
• Assured Workloads is the primary tool for applying regulatory compliance controls (like FedRAMP, CJIS, IL4) to a folder automatically.

Quick Decision Cheat Sheet (Subsection 5.1)

Further Reading (Subsection 5.1)

• Restricting resource locations — This page explains how to use the Organization Policy Service to restrict the physical location of new resources.
• Retention policies and Bucket Lock — Documentation on how to configure retention policies and lock them to achieve WORM compliance.
• PCI DSS on Google Cloud — Refer to the section on 'Network segmentation' and 'Tokenization' to understand how to architect for scope reduction.
• Shared Responsibility Model — This page explains the division of responsibilities between Google and the customer across different service models (IaaS, PaaS, SaaS).
• Compliance Reports Manager — This page details Google Cloud's compliance offerings and explains how customers can access reports like SOC 2 to verify compliance.
• Assured Workloads Overview — Documentation explaining how Assured Workloads helps you comply with regulatory requirements by creating a controlled environment.

Book TOC · Previous · Chapter 6 of 7 · Next