Google Cloud Shared Responsibility by Service Model

Security demarcation across service delivery models is the division of security ownership between Google Cloud and the customer that shifts as services abstract more of the stack. This shared responsibility (opens in a new tab) model moves from customer-heavy in Infrastructure as a Service (IaaS) to Google-heavy in Software as a Service (SaaS). Data protection remains a customer duty in every model, even when Google Cloud supplies default encryption and infrastructure controls.

1.1Infrastructure as a Service (IaaS)

Infrastructure as a Service (IaaS) provides on-demand compute, storage, and networking with pay-as-you-go pricing for lift-and-shift migrations or custom virtual machine (VM), database, and network designs. Example services are Compute Engine, Cloud Storage, Cloud VPN, Cloud Load Balancing, and Cloud DNS. In IaaS the bulk of security responsibility belongs to the customer, including guest operating systems, applications, data, access configuration, and network controls deployed above the virtualization layer. Google Cloud responsibility is focused on the underlying infrastructure and physical security, including facilities, hardware, and the hypervisor foundation that hosts customer VMs.

1.2Platform as a Service (PaaS)

Platform as a Service (PaaS) provides the runtime environment for developing and running applications without managing underlying infrastructure. Example services are App Engine, Google Kubernetes Engine (GKE), and BigQuery. In PaaS Google Cloud is responsible for more controls than in IaaS, and exact ownership varies by service and features used. The customer shares responsibility with Google Cloud for application-level controls and Identity and Access Management (IAM) management, while the customer remains responsible for data security and client protection.

1.3Software as a Service (SaaS)

Software as a Service (SaaS) provides ready-to-use online applications purchased by subscription, for workloads the enterprise needs to process but does not want to build. Examples are Google Workspace, Google Security Operations, and third-party applications in Google Cloud Marketplace. In SaaS Google Cloud owns the bulk of security responsibilities across hardware, platform, and application layers. The customer remains responsible for access controls, such as who can sign in and what they can do, and for the data the customer chooses to store in the application.

1.4How Ownership Shifts Across Models

Ownership of the stack shifts predictably from customer-heavy to Google-heavy as abstraction increases. The customer configures Identity and Access Management (IAM) policies and selects Assured Workloads (opens in a new tab) controls that Google Cloud then enforces, including data storage location and limits on personnel access.

Data protection does not transfer to Google Cloud in any model. The customer must identify regulatory obligations, internal security standards, and customer and vendor requirements, then select and configure the matching Google Cloud controls for encryption, location, and access.

Shared operational and data protection controls are the split of day-to-day security work where Google Cloud protects the underlying platform while the customer configures access, data, and location controls on top of it. This shared responsibility (opens in a new tab) baseline applies even as more work moves to Google in higher-level services. Inherited controls such as default encryption can be used as audit evidence, but they do not remove the customer duty to configure and monitor what the customer owns.

2.1The Shared Responsibility Baseline Across Deployment Models

The shared responsibility baseline is the fixed split that applies across Software as a Service (SaaS), Function as a Service (FaaS), and container platforms. In SaaS the enterprise uses an online application without building it, but the customer still owns access controls and the data placed in the application. In FaaS or serverless, such as Cloud Run functions, small single-purpose functions run in response to events, for example classifying data when it is uploaded to Cloud Storage, and responsibility is similar to SaaS. A concrete split appears with Model Context Protocol (MCP) on Google Kubernetes Engine (GKE): Google secures the infrastructure and the MCP server itself, while the customer secures client credentials, defines Identity and Access Management (IAM) policies for those credentials, and monitors actions taken by the AI agent.

2.2Operational Responsibilities Retained by the Customer

Operational responsibilities retained by the customer are the day-to-day controls that determine who can reach data, from where, and with what posture. These controls stay with the customer even when Google hardens the platform underneath:

• Identity access management: the customer defines allow policies and deny policies, including combinations of principal, tool properties such as read-only attribute, service or tool name, and OAuth client ID.
• Network and access perimeter: Google protects data-center layers, machine identity, and service-to-service transport, while the customer controls access policies, regional placement, and context for its own users and workloads.
• Vulnerability and misconfiguration management: most cloud breaches result from misconfiguration while products change, so the customer must know which controls are its responsibility, which are available in the offering, and which are inherited by default.
• Incident response and continuous monitoring: Google runs internal investigation teams with machine learning, data pipelines, and threat intelligence fed by past incidents, traffic, access logs, anomalous behavior, and offensive exercises, while the customer must satisfy continuous monitoring for infrastructure it provisions.

Google's side of operations is highly automated because its global Google infrastructure (opens in a new tab) is homogeneous. Automated systems keep servers on current software including security patches, detect hardware and software problems, verify boot and attestation, allow only machines running intended software and firmware to obtain production-network credentials, and remove or repair machines that fail integrity checks or are no longer needed.

2.3Data Protection, Encryption Tiers, and Sovereignty

Data protection tiers describe how much key control the customer assumes on top of Google-default encryption. Google-default encryption and infrastructure controls are inherited controls that can support Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), and other audits. Customer-Managed Encryption Keys (CMEK) move key governance to the customer, and Customer-Supplied Encryption Keys (CSEK) move it further, so responsibility for confidentiality and sovereignty increases from Google-default to CMEK to CSEK.

Enforcement is a customer task. Data Security Posture Management (DSPM) creates findings when CMEK protection is missing or broken, including:

• BIGQUERY_TABLE_CMEK_DISABLED
• VERTEX_AI_MODEL_CMEK_DISABLED
• DATA_SECURITY_POSTURE_CMEK_POLICY_MISCONFIGURED
• DATA_SECURITY_POSTURE_CMEK_POLICY_DELETED
• DATA_SECURITY_POSTURE_CMEK_VIOLATION

Location is also a customer control: a business serving European Union residents may need to meet General Data Protection Regulation (GDPR) rules by keeping customer data in Google Cloud regions in the EU. For FedRAMP High, the customer must choose the Assured Workloads Data Boundary for FedRAMP High (opens in a new tab), and FedRAMP Moderate can use FedRAMP High-authorized services inside its own authorization boundary with fewer controls to assess.

2.4Visibility Into Google Access and Customer Posture

Visibility into access and posture comes from separate log and finding systems for Google operations and customer configuration. Google enforces strong authentication for users and service identities, provisions cryptographic credentials at job start, secures service calls with Application Layer Transport Security (ALTS), applies context-aware access based on identity, location, device ownership and configuration, and fine-grained policy, and requires production software to pass review through Binary Authorization for Borg before deployment.

Access logging and posture monitoring divide as follows:

The customer views its own compliance drift in Security Command Center. Compliance Manager findings come from the Compliance Evaluation Service source, while DSPM findings surface access, flow, deletion, key-governance, public-exposure, and exfiltration violations on the Data Security and Compliance, Risk Overview Data tab, and Findings pages.

Regulatory compliance and audit responsibility is the process of determining which duties belong to Google Cloud and which remain with the customer, then proving each side with inherited controls and audit evidence. This shared responsibility (opens in a new tab) boundary does not change with the regulatory framework; frameworks define how each side demonstrates its part. Google Cloud always remains responsible for the underlying network and physical infrastructure, while the customer always remains responsible for access policies and data.

3.1Shared Responsibility Baseline Across Service Models

The shared responsibility baseline divides ownership by layer, with the provider owning lower layers and the customer owning data and access. In Software as a Service (SaaS), Google Cloud owns the bulk of security responsibilities and the customer remains responsible for access controls and the data stored in the application. Function as a Service (FaaS) carries a similar division, where Cloud Run functions provides the platform to run event-driven functions and the customer remains responsible for access and stored data.

This baseline means inherited controls flow upward from Google Cloud to the customer deployment. Default encryption and infrastructure controls are built into the platform, and the customer can cite those inherited controls as part of evidence to auditors and regulators. Misconfiguration remains a leading cause of breaches because cloud products change continuously, so the customer must still configure access, location, and service settings correctly even when the underlying control is inherited.

3.2Framework-Defined Duties for PCI DSS, HIPAA, and Location Rules

Regulatory and industry frameworks define which controls the customer must implement, which controls are available from the cloud offering, and which controls are inherited by default. The Payment Card Industry Data Security Standard (PCI DSS) splits payment-processor duties between the customer and Google Cloud, as detailed in the Google Cloud PCI DSS Shared Responsibility Matrix. The Health Insurance Portability and Accountability Act (HIPAA) similarly splits duties for electronic protected health information (PHI), with Google Cloud describing its implementation in its HIPAA compliance guidance.

Location-based regulations add a customer-owned duty to control where data is processed and stored. Under the General Data Protection Regulation (GDPR), a business serving residents of the European Union may be obligated to keep customer data in the European Union, and the customer is responsible for ensuring collected data remains in Google Cloud regions in Europe. The Compliance resource center and Compliance offerings describe how Google Cloud meets its own obligations, but selecting an in-scope region, restricting data movement, and proving correct handling remain customer responsibilities.

3.3FedRAMP Authorization Boundary and Customer ATO Duties

The Federal Risk and Authorization Management Program (FedRAMP) authorization for Google Cloud does not automatically authorize a customer system. Google Cloud maintains a comprehensive FedRAMP High provisional authorization to operate (P-ATO) covering more than 150 cloud services, which lets a customer inherit platform controls and pursue its own Authorization to Operate (ATO) with a third-party assessment organization (3PAO). Under current Rev. 5 guidance, the available path is the Agency ATO completed jointly by the customer, Google, and the 3PAO.

Data residency and service selection are explicit customer decisions inside that boundary. To meet FedRAMP High (opens in a new tab) obligations, the customer must use Data Boundary for FedRAMP High, which enforces the FedRAMP High data residency requirements including control SA-9(5). The FedRAMP Moderate control baseline is a subset of the FedRAMP High control baseline, so any Google Cloud service that is FedRAMP High authorized can be placed inside a FedRAMP Moderate authorization boundary with fewer controls to assess than a High ATO requires.

Artificial intelligence (AI) and large language model (LLM) workloads follow the same service-boundary rule. Individual LLMs are not independently authorized in the FedRAMP Marketplace; authorization applies to cloud services such as Generative AI on Agent Platform and Agent Platform Inference. Google authorizes the serving infrastructure and custom-built containers for Google-managed models, including Google first-party models such as the Gemini family and supported partner models, while security of open-source models and continuous monitoring for customer-provisioned LLM infrastructure remain customer responsibilities for the ATO.

3.4FedRAMP Compliance Documentation for Audit Evidence

FedRAMP compliance documentation separates Google-owned platform descriptions from customer-owned implementation duties. Google can provide FedRAMP High documentation under a non-disclosure agreement (NDA) through the sales team or Google Cloud representative, and federal agencies can also request the package through the FedRAMP package access request process.

Control mapping guides and implementation guides make the handoff explicit: Google Cloud describes coverage, and the customer applies the technical configuration in its own tenant. Because implementation-guide settings are not enforced by default, an auditor will expect evidence that the customer applied and monitors those settings rather than assuming the platform applied them.

3.5Platform Monitoring and Logs That Support Customer Audits

Platform monitoring and logs that support customer audits show how Google controls access to customer data while giving the customer evidence for its own duties. Google controls and monitors access through pervasive infrastructure-wide controls, continuous detection and remediation, and regular audits by an internal audit team and independent third-party auditors. Strong authentication requires production jobs to prove identity with cryptographic credentials for service-to-service calls using Application Layer Transport Security (ALTS), with deployment restricted to service owners such as Site Reliability Engineers (SREs). Context-aware access evaluates user identity, location, device ownership and configuration, and fine-grained policy instead of trusting the corporate network alone, while Binary Authorization for Borg requires production software to be reviewed and approved before deployment so no single person or compromised account can unilaterally run code against user data.

Audit evidence flows from Google Cloud logging systems to customer and auditor review:

• Cloud Audit Logs exposes customer-visible logs of data access and administrative activity for customer investigation and audit evidence.
• Access Transparency exposes logs of Google personnel administrative access to customer content, including Google-initiated reviews for security, fraud, abuse, compliance, and production reliability.
• Deployment integrity logs are internal exception logs monitored by a central security team to ensure unreviewed or unsubmitted code does not run in privileged environments (opens in a new tab).

Incident detection connects these logs to response through threat intelligence fortified by past incidents, network traffic, system access logs, anomalous behavior, and offensive security exercises. Together, inherited platform controls plus customer-owned logs, region choices, and service configurations form the complete audit story: Google Cloud proves the infrastructure, and the customer proves access, data handling, and continuous monitoring of what it provisioned.

Key Facts

• In Infrastructure as a Service (IaaS) Google Cloud secures facilities, hardware, and the hypervisor, while the customer secures guest operating systems, applications, data, and network and access configuration above virtualization.
• In Platform as a Service (PaaS) the customer shares application-level controls and Identity and Access Management (IAM) management with Google Cloud but retains data security and client protection.
• Confidentiality responsibility increases from Google-default encryption to Customer-Managed Encryption Keys (CMEK) to Customer-Supplied Encryption Keys (CSEK).
• Google Cloud maintains a FedRAMP High provisional authorization to operate covering more than 150 services, but the customer must obtain its own Authorization to Operate and use Data Boundary for FedRAMP High to enforce data residency including control SA-9(5).
• Cloud Audit Logs records customer-visible data access for customer audit, while Access Transparency records Google administrative access to customer data for customer review.