Prepare and test your skills
Prepare and test your skills
The shared responsibility model is the division of security and compliance duties between Google Cloud and the customer. Google Cloud (opens in a new tab) secures the physical infrastructure and enforces the controls the customer configures, while the customer decides which data is regulated and keeps that data inside a controlled boundary. The compliance boundary is the set of folders, projects, services, regions, and data types where customer controls for residency, access, and service use apply.
Shared responsibility for data means the customer decides what level of protection each workload and dataset requires. That decision depends on regulatory obligations such as HIPAA, PCI DSS, FedRAMP, and GDPR, plus organizational security standards, risk plans, and customer and vendor requirements. Google Cloud provides baseline protection for Customer Data and Service Data, including default encryption and infrastructure controls. When workloads carry regulated data, defaults are not enough and the customer must add elevated controls and keep that data inside the selected boundary.
Customer-managed obligations are the configuration and governance actions that only the customer can perform for its data and applications. Google Cloud is responsible for physical and network security of the underlying infrastructure, while the customer is responsible for securing data and applications, configuring access control, and configuring security services. The customer must understand which data has special requirements and enforce those requirements through placement and configuration.
Regulated data in scope can include account information, health information, personal identifiers, cardholder data, and ID numbers. Because only data inside the boundary inherits residency, personnel-access, and service restrictions, moving regulated data outside removes those protections.
Google-managed obligations are the foundational infrastructure, enforcement, and tooling that Google Cloud provides for the customer to build on. These responsibilities work only when the customer completes its own configuration to protect data. Google applies default encryption and infrastructure controls and then enforces the policies the customer defines.
For EU regimes, Google Cloud adds controls such as an EU data boundary, routing of support to EU persons in EU locations including subprocessors, visibility into administrative access, policy-driven access approvals for Sovereign Controls, and custom encryption and key management with Cloud Key Management Service (Cloud KMS).
An Assured Workloads folder is a regulatory boundary inside a Google Cloud organization that identifies regulated data types and applies guardrails to everything beneath it. The resource hierarchy flows from the Organization resource to folders to Google Cloud projects to service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints. Any project created under an Assured Workloads folder inherits the folder-level guardrails, so new resources automatically fall under the same controls.
Architectural isolation minimizes audit scope because only folders and projects that contain regulated data carry the full compliance burden. The customer selects a program such as FedRAMP High or IL2, IL4, IL5 for the folder, and Assured Workloads applies resource-location and resource-usage restrictions that reflect the services compliant with that program at that point in time. The customer remains responsible for its own network and IAM policies, for using infrastructure as code for consistent deployment, and for validating controls through Security Command Center posture templates for ISO 27001 and NIST 800-53.
Data residency, service scope, and network design determine whether a workload stays inside its claimed compliance boundary. Geography controls where data is stored and processed, so the customer must use resource location constraints to allow deployment only in pre-approved regions and must account for the regionality of each service. For FedRAMP High and DoD IL4 and IL5, data must generally remain within a United States geographical boundary, so subnets are created only in US regions even though Virtual Private Cloud (VPC) (opens in a new tab) itself is global in definition.
Private connectivity keeps traffic inside the region and inside the boundary through Private Service Connect, Private Google Access (PGA), and Private Service Access (PSA) to Google managed services and APIs. Regional load balancers with regional Google Cloud Armor policies support US-only deployments, while global constructs do not meet jurisdictional requirements. Third-party producer-consumer services and non-production environments must be verified separately so both the producer service and data in transit meet the same requirements.
Exam tip: Global External Application Load Balancer, Global External Proxy Load Balancer, and Global Google Cloud Armor do not meet FedRAMP High or DoD IL2, IL4, and IL5 jurisdictional boundary requirements; use regional load balancers and regional Armor policies for those workloads.
FedRAMP authorization (opens in a new tab) is a US government assessment and authorization program based on NIST SP 800-53, with impact levels Low, Moderate, and High assigned under NIST FIPS 199. FedRAMP requires assessment plus continuous monitoring, not a one-time certification, and the number of controls grows with impact level. Google Cloud holds a FedRAMP High Provisional Authority to Operate (P-ATO) for Google Cloud and the underlying Google Common Infrastructure covering more than 150 services, which lets a customer inherit platform controls and pursue its own agency authorization for applications built on those services.
| Authorization level | Control baseline | Data-residency rule |
|---|---|---|
| FedRAMP Moderate | 325 NIST SP 800-53 controls; subset of High baseline | No FedRAMP residency mandate; Assured Workloads Data Boundary for Moderate has no residency controls |
| FedRAMP High | 421 NIST SP 800-53 controls; highest bar | Residency mandated; customer must use Assured Workloads Data Boundary for High and configure regional services to store data in a US region without movement outside the US |
A FedRAMP High authorized service can be used inside a Moderate authorization boundary, but the customer must still assess its own application controls. Google Cloud supports that assessment with the Customer Responsibility Matrix and System Security Plan under non-disclosure agreement, plus service-specific mapping guides and implementation guides that identify which APIs and data fields are suitable for protected data. The Compliance resource center and in-scope service lists map certified infrastructure against scoped obligations, so the customer can confirm every service, API, and region is covered before claiming compliance.
Common metadata and configuration fields sit outside the Assured Workloads technical control boundary and must not carry sensitive or regulated data. These fields may not be protected by the same residency, access, or encryption controls as Customer Data, so placing health information, cardholder data, identifiers, or account data in them breaks the boundary even when the workload is correctly placed. The boundary holds only when regulated content flows from compliant folders and projects to in-scope regional services through private regional connectivity, while names, labels, logs, and policies carry only non-sensitive values.
Delineating and isolating a regulated data environment means identifying exactly which data is subject to regulation and placing only that data inside a hardened organizational, network, and identity boundary. The goal is to reduce the footprint subject to audit by keeping general commercial workloads outside the boundary while regulated workloads inherit residency, access, and exfiltration controls by default. On Google Cloud, that boundary is built from an Assured Workloads (opens in a new tab) folder, dedicated projects, Virtual Private Cloud (VPC) perimeters, and restrictive access policies.
Identifying regulated data assets is the customer responsibility to decide which portions of data carry higher compliance obligations. Most environments mix general commercial data with data that needs elevated protection, such as health data under HIPAA or HITECH, cardholder data under PCI DSS, or personal data under GDPR. The decision depends on regulatory duties, organizational risk plans, and customer and vendor requirements. Once identified, sensitive data with specific access or residency needs must be placed inside appropriate Assured Workloads folders or projects and kept there, including during troubleshooting and support.
The scope of regulated data varies by regime but commonly includes account information, health information, personal identifiers for customers or users, cardholder data, and ID numbers. Keeping only these data types inside compliant folders is what minimizes scope and focuses audit evidence, logging, and hardening on the smaller enclosed set. Data that remains outside does not inherit residency and personnel-access restrictions, so clean separation is essential.
An Assured Workloads folder is a regulatory boundary inside a Google Cloud organization (opens in a new tab) that marks where regulated data types live. The Google Cloud resource hierarchy flows from the Organization resource at the apex to folders to Google Cloud projects to service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints. Any project created under an Assured Workloads folder inherits the security and compliance guardrails set at that folder, so new resources automatically fall under the same controls.
Isolation depends on regional and service alignment as well as hierarchy placement. For FedRAMP High and Department of Defense Impact Level 2 (IL2), Impact Level 4 (IL4), and Impact Level 5 (IL5), data must generally stay within a United States geographical boundary, and Assured Workloads enforces this with a resource-restriction Organization Policy that limits selectable regions. The customer must also confirm product-level compliance, because Assured Workloads maintains a point-in-time resource-usage restriction that reflects only the services in scope for the chosen program. Choosing a non-compliant region or service expands scope or breaks compliance, even if the folder boundary is correct.
VPC Service Controls (opens in a new tab) is the network control that defines a trusted service perimeter around Google-managed services and data to block access from untrusted locations and mitigate exfiltration. The perimeter policy applies to API calls between projects and services, so traffic that attempts to flow from a protected project to a service outside the perimeter is denied unless an explicit exception allows that intended pattern. This enforcement reduces audit scope to flows inside the perimeter, but it adds operational overhead because existing integrations can break until exceptions are defined.
For FedRAMP High and DoD IL2, IL4, and IL5, the landing-zone network keeps data paths inside United States regions. VPC networks are global in definition, but subnets must be created only in approved United States regions, and only regional load balancers paired with regional Google Cloud Armor policies are used. Private access to Google APIs and managed services must stay within the region through the relevant private option for the use case — Private Service Connect, Private Google Access (PGA), or Private Service Access (PSA) — so traffic flows from workload subnets to Google services without traversing the public internet. Third-party producer-consumer services and non-production environments must be validated separately to ensure both the producer and data in transit meet the same jurisdictional requirements.
Exam tip: Global External Application Load Balancer, Global External Proxy Load Balancer, and Global Google Cloud Armor do not meet FedRAMP High or DoD IL2, IL4, and IL5 jurisdictional boundary requirements; use regional load balancers with subnets only in United States regions.
Identity and Access Management (IAM) (opens in a new tab) is the control that restricts who can administer workloads and read regulated data inside the isolated hierarchy. The customer configures IAM with least-privilege, granular role-based access control so only appropriate personnel can access or modify organization contents, and Google enforces the policies the customer sets. Organization Policy Service constraints then enforce where those identities can act, including resource location constraints that allow deployment only in pre-approved regions and resource-usage restrictions tied to the compliance program.
Supporting controls tighten the boundary further when risk justifies the cost. Policy Intelligence tools provide insight into account and resource access, Access Approval requires explicit customer approval before Google support accesses customer content, and Key Access Justifications with Cloud External Key Manager (Cloud EKM) lets the customer control use of encryption keys. Data residency choices, data-access audit logs for sensitive services, and infrastructure-as-code definitions for security configuration make the boundary consistent and auditable across projects.
Scope creep occurs when regulated data leaks into fields that sit outside the Assured Workloads technical control boundary and therefore expands what an auditor must review. Common input fields such as names, labels, and logs are not protected by the same residency and personnel-access controls as Customer Data stored in compliant resources. Customers must therefore design naming, observability, and support processes so personal or regulated values never flow from protected projects to these unprotected fields.
Avoid placing sensitive or regulated data in the following common fields, because the organizational hierarchy itself must also avoid exposing personal data:
Support troubleshooting must not share regulated content outside compliant folders. When metadata, hierarchy design, and support flows stay clean, the compliance perimeter remains the Assured Workloads folder and its projects, rather than spreading to logging systems, billing exports, and administrative tools.
Assessing resource configurations and continuous auditing for in-scope assets is the practice of proving that every resource in a regulated boundary stays on its approved baseline and produces complete audit evidence. In Google Cloud, Organization Policy (opens in a new tab) prevents non-compliant configuration at deployment time, Security Command Center (SCC) (opens in a new tab) continuously checks deployed resources against compliance benchmarks, and logging services record who did what for later review. Together they cover the organization, folder, and project levels where in-scope data lives.
Organization Policy is the preventive control that constrains how resources in an organization, folder, or project can be configured. A policy attaches to a node in the resource hierarchy and inherits downward, so a rule set at the organization or Assured Workloads folder automatically applies to all child projects unless overridden. This inheritance lets teams shrink compliance scope by placing sensitive data only inside designated folders or projects and keeping it there.
Data flows from the policy definition at the parent node to enforcement at resource creation time in each child project. The constraint constraints/gcp.resourceLocations is central for data residency because it allows deployments only in pre-approved regions, accounting for the regionality of multiregional services. Google enforces the customer-defined policy, while the customer owns choosing the correct locations, services, and encryption rules for its regime.
Common preventive constraints for regulated baselines include Restrict Resource Locations to allow resources only in approved regions, Require CMEK Protection with customer-managed encryption via Cloud Key Management Service, Restrict TLS Versions to enforce minimum transport security, and Disable Creation of Global Load Balancers and global Cloud Armor policies. They also include Restrict Service Usage to disable Spanner multi-region instances, Pub/Sub message transforms, and non-compliant Cloud SQL creation, plus Define Locations for Cloud Logging Buckets and for technical support services to keep audit data and support access inside the boundary.
Security Command Center is the detective control that provides continuous monitoring and a unified interface for security insights across in-scope environments. SCC posture management applies templates mapped to standards such as ISO 27001 and NIST 800-53, plus prescriptive baselines such as CIS GCP Foundations Benchmark v3.0, FedRAMP High and Low, and DoD IL5. When a resource drifts from the baseline, SCC generates a finding with severity, finding category, revision number, and supported targets of organization, folder, or project.
Findings flow from the SCC detector to the security team for triage and remediation in the affected project or folder. Enforcement mode distinguishes Detective findings that check live configuration from Audit findings that require manual evidence review and attestation. Both modes support the same hierarchy targets, so coverage can be verified centrally even when workloads span many projects.
Representative benchmark checks for in-scope assets include RESOURCE_LOCATION_NOT_ALLOWED with HIGH severity when a resource is outside allowed regions, STORAGE_BUCKET_LOCKED_RETENTION_POLICY_NOT_SET with MEDIUM severity when Bucket Lock retention is missing, and API_KEY_APPS_UNRESTRICTED when API keys allow any untrusted application. They also include MISSING_REVIEW_OF_COMPUTE_IMAGES, MISSING_REVIEW_OF_CLOUD_RUN_IMAGES, and MISSING_REVIEW_OF_ARTIFACT_REGISTRY_IMAGES with HIGH severity when hardened images are not verified, plus MISSING_RESOURCE_INVENTORY, INGRESS_EGRESS_CONTROLS_NOT_SET, and RESOURCE_ISOLATION_NOT_MAINTAINED for inventory and isolation gaps.
| Framework | Primary focus | Example controls from documentation |
|---|---|---|
| CIS GCP Foundations Benchmark v3.0 | Secure baseline for IAM, Logging, Networking, and Storage | Block public IPs on Cloud SQL, block project-wide SSH keys, enable VPC flow logs, enforce uniform bucket-level access |
| ISO 27001 and NIST 800-53 posture templates | Broad information-security management and federal controls | Continuous monitoring in SCC, vulnerability disclosure program, separation of user and administrator roles, review of log and alert configuration |
| FedRAMP High and IL5 | US federal data boundaries and elevated protection | Restrict resource locations, require CMEK, enable Access Transparency, restrict TLS, disable global load balancing |
Cloud Audit Logs (opens in a new tab) are the authoritative record of administrative activity and data access inside in-scope projects, folders, and the organization. Audit entries flow from the Google Cloud service that handled the request to Cloud Logging, where they can be viewed in Logs Explorer, analyzed with log-based metrics, and tied to alerting policies. Access Transparency (opens in a new tab) extends this traceability across the trust boundary by logging Google administrator access to customer content, including access requests, approvals, and EU personnel routing for sovereign controls.
The customer owns enabling, protecting, and reviewing these logs, while Google owns producing the underlying infrastructure and Access Transparency events and enforcing the IAM policies the customer sets. Audit information and tools must be protected from unauthorized access, modification, and deletion, and access to audit logs themselves must be managed. A complete review cycle for in-scope environments follows a repeatable order:
Controlled export and retention ensures that audit evidence survives tampering, deletion, and regional drift for the full period regulators require. Log data flows from the source organization, folder, or project to a sink destination such as a Cloud Logging bucket, Cloud Storage bucket, or BigQuery dataset, and the destination bucket location must itself be constrained to an approved region. Because the destination is a separate resource, its own Organization Policy, IAM allow policies, and retention settings determine whether evidence remains trustworthy.
Preservation depends on storage controls that lock data in place after it arrives. Retention policies define how long objects must be kept, and Bucket Lock makes that retention permanently locked so records cannot be shortened or deleted early. Versioning and inventory complete the chain by proving what existed and when it changed.
Key preservation controls for in-scope evidence include defining permitted locations for Cloud Logging buckets so audit copies do not leave the boundary, setting the log-bucket flag on Cloud Storage buckets to enable usage and storage logging, and locking retention policies with Bucket Lock for regulated buckets. They also include enabling object versioning to prevent loss from overwrite or deletion and maintaining a current resource inventory with Cloud Asset Inventory (opens in a new tab), including deployed assets, software, services, and the infrastructure-as-code that defines them.
Exam tip: Do not place sensitive or regulated data in resource names and IDs, project or folder names, description fields, labels, log-based metrics, URIs, firewall rules, or IAM policies, because those common fields sit outside the Assured Workloads technical control boundary.
The shared responsibility model assigns physical and infrastructure security to Google Cloud and data, application, access, and residency configuration to the customer. Customers must decide what level of protection each workload and dataset requires based on obligations such as HIPAA, PCI DSS, FedRAMP, and GDPR and keep regulated data inside an Assured Workloads folder boundary with elevated controls because default encryption and infrastructure controls are not enough.
An Assured Workloads folder is a regulatory boundary inside a Google Cloud organization that applies residency and service guardrails to everything beneath it. Any project created under the folder inherits the folder-level guardrails so new resources automatically fall under the same controls, and only data inside that folder inherits residency, personnel-access, and service restrictions.
FedRAMP High requires 421 NIST SP 800-53 controls with mandated United States residency, while FedRAMP Moderate requires 325 controls with no FedRAMP residency mandate. For High the customer must use Assured Workloads Data Boundary for High and configure regional services to store data in a United States region without movement outside the United States, and must use regional load balancers with regional Google Cloud Armor policies because global constructs do not meet the jurisdictional boundary requirements.
An organization is migrating its financial transaction processing workloads to Google Cloud and preparing for an upcoming PCI DSS and SOC 2 Type II compliance audit. The target environment includes:
To establish the compliance boundaries and satisfy auditor requirements, which approach correctly maps the shared responsibility model across these service tiers and identifies the appropriate compliance artifact retrieval process?
Manage guest OS patching, network firewalls, and application configurations on Compute Engine; configure database access controls and schema encryption on Cloud SQL; enforce identity and user access policies in Google Workspace; and obtain Google's PCI Attestation of Compliance (AOC) and SOC 2 Type II reports from the Compliance Reports Manager.
Enforce customer-managed operating system patch cycles on Cloud SQL instances, configure VPC Service Controls across Google Workspace user identities, and rely on Cloud Logging without obtaining third-party compliance reports.
Delegate the physical data center audits and hypervisor vulnerability remediation to the internal security team, and execute manual on-site inspections of Google Cloud facilities to satisfy PCI DSS physical security requirements.
Rely on Google's PCI DSS certification to inherit full compliance across Compute Engine guest operating systems and Cloud SQL database engines, and submit a customer penetration test exemption request through the Google Cloud console.
Last updated