Google Cloud Shared Responsibility Model: Who Secures What?

Introduction

Google Cloud secures the underlying infrastructure that powers its cloud services, including physical facilities, hardware, core networking and provider-managed components. But that does not mean Google automatically secures everything an organization deploys in Google Cloud.

Customers remain responsible for important security decisions involving identities, access policies, data, applications and customer-controlled configurations. This division is the foundation of the Google Cloud shared responsibility model: Google secures the cloud infrastructure, while customers secure what they bring to and configure within the cloud.

The exact boundary depends on the Google Cloud service being used. A Compute Engine virtual machine leaves the customer responsible for more of the technology stack than a fully managed service such as Cloud Run or BigQuery. However, using a managed service does not eliminate the need for identity management, data protection, secure configuration, monitoring and compliance.

Google Cloud also uses the concept of shared fate, which goes beyond simply dividing responsibilities. It emphasizes Google's role in helping customers achieve stronger security outcomes through secure foundations, guidance, recommended architectures and integrated security capabilities.

This guide explains what Google secures, what customers must protect, how responsibilities change across service models, and how organizations can use Google Cloud security services and best practices to reduce risk.

What Is the Google Cloud Shared Responsibility Model?

The Google Cloud shared responsibility model defines how security responsibilities are divided between Google and its customers. Google is responsible for securing the underlying cloud infrastructure and provider-controlled components used to deliver Google Cloud services. Customers are responsible for securing their data, identities, applications, workloads and customer-controlled configurations.

The exact division depends on the service, architecture and configuration. In general, the more infrastructure Google manages for a service, the less infrastructure the customer has to maintain. However, customers continue to control important areas such as data access, identity, permissions and how their applications and resources are configured.

Factors that can affect the responsibility boundary include:

• The Google Cloud service being used
• Whether the service is IaaS, PaaS or SaaS
• The workload architecture
• Customer-controlled configuration
• The sensitivity of the data
• Regulatory and contractual requirements
• Identity and access policies
• Network exposure and connectivity

How Shared Fate Expands the Model

Google Cloud uses shared fate to describe a security operating model in which Google aims to work more closely with customers toward common security and risk-management outcomes.

Traditional shared responsibility focuses on defining which security duties belong to the cloud provider and which belong to the customer. Shared fate adds a stronger emphasis on secure-by-design infrastructure, security guidance, recommended practices, blueprints, risk intelligence and other capabilities intended to help customers operate securely.

Shared fate does not remove customer accountability. Organizations must still identify their security requirements, configure controls appropriately, manage identities and permissions, protect data, monitor their environments and respond to security findings.

Who Is Responsible for Security in GCP?

Both Google and the customer are responsible for GCP security, but they control different parts of the environment.

Google secures the underlying cloud platform and provider-controlled infrastructure. Customers secure the data, identities, applications, workloads and configurations that they control.

Google provides capabilities such as IAM, encryption, logging, network security and security posture management. The customer must determine which controls are required and configure and operate them appropriately.

What Google Secures in Google Cloud

Google generally protects the provider-controlled infrastructure used to deliver Google Cloud services. This includes physical data centers, physical hardware, core networking, virtualization and other infrastructure components that Google operates.

Depending on the service, Google may also manage additional layers such as operating systems, runtimes, middleware and other platform components.

Customers therefore do not need to operate Google's physical data centers, replace its physical servers, maintain its facility infrastructure or manage the underlying provider-controlled network.

However, Google's infrastructure responsibility does not mean that Google makes every security decision for a customer's workload. Customers still determine who receives access, what data is stored or processed, how applications behave, and how customer-controlled resources are configured.

Google's own security documentation summarizes the principle broadly: the provider protects the cloud infrastructure, while customers are responsible for securing what they bring into the cloud.

What Customers Must Protect in GCP

Customers generally remain responsible for the security of the resources and configurations they control. This includes areas such as:

• IAM policies and permissions
• User and administrator access
• Service accounts and workload identities
• Customer data
• Application code
• Workload configurations
• Network and firewall configuration
• Secrets and credentials
• Logging and monitoring decisions
• Backup and recovery requirements
• Regulatory and contractual obligations

The exact boundary varies by service.

With Compute Engine, customers typically manage the guest operating system, installed software, patches, applications and workload configuration. With managed services such as Cloud Run and BigQuery, Google operates more of the underlying platform, but customers still control important areas such as data, permissions, application behavior and service configuration.

Common customer-side security problems include:

• Excessive IAM permissions
• Publicly exposed resources
• Poorly managed service account credentials
• Unnecessary firewall access
• Missing or insufficient monitoring
• Unprotected sensitive data
• Vulnerable application code
• Insecure workload configurations

Google provides security capabilities, but customers remain responsible for configuring and operating the controls that apply to their workloads.

A Practical GCP Security Example

Imagine a company stores customer records in BigQuery and uses Cloud Run to provide access through an application.

Google secures the physical infrastructure, managed service platform and provider-controlled components supporting those services.

The customer, however, determines which users and workloads can access the BigQuery data, which IAM permissions are granted, how the Cloud Run application authenticates users, whether the service is publicly accessible, how audit logs are monitored, and which data-protection and compliance controls are required.

If an employee is given unnecessarily broad permissions and uses them to export sensitive information, the access-control problem is within the customer's area of responsibility.

The important lesson is that using a managed Google Cloud service reduces infrastructure-management responsibilities, but it does not eliminate workload security responsibilities.

How GCP Responsibilities Change Across IaaS, PaaS, and SaaS

Customer responsibilities generally decrease as the cloud service becomes more managed, but they do not disappear.

GCP IaaS Responsibilities

Compute Engine is a common IaaS example.

Google manages the underlying physical infrastructure, hardware, core networking and virtualization layer. The customer typically manages the guest operating system, operating system updates, installed software, applications, workload configuration, IAM permissions and other controls within the virtual machine.

For example, if a vulnerability exists in the guest operating system of a Compute Engine VM, the customer is generally responsible for patching or otherwise mitigating it.

This is why IaaS provides flexibility but also leaves customers with a larger security-management burden.

GCP PaaS Responsibilities

Services such as App Engine and Cloud Run reduce the amount of infrastructure customers have to manage. Google manages more of the underlying operating system, runtime and platform infrastructure.

Customers still remain responsible for application code, authentication and authorization, data, IAM permissions, secrets and service configuration.

A managed platform can reduce infrastructure-management work, but it cannot automatically correct insecure application logic, excessive permissions or poorly designed authentication.

GCP SaaS Responsibilities

Google Workspace is an example of SaaS, where Google manages the application platform and underlying infrastructure.

Customers still have important responsibilities involving user accounts, authentication, administrator privileges, data sharing, connected applications, tenant configuration, retention and compliance.

The SaaS model therefore transfers more infrastructure responsibility to Google, but organizations still need strong identity and information-governance practices.

The key principle across all three models is simple:

The more infrastructure Google manages, the fewer infrastructure tasks the customer performs. But customer responsibilities around data, identity, access and use of the service remain important.

How to Secure Workloads in Google Cloud

Effective cloud workload security starts with identity and access management and extends across network security, data protection, secure configuration, logging, monitoring and incident response.

Control Access With Google Cloud IAM

Google Cloud IAM controls which principals can perform actions on Google Cloud resources.

Organizations should apply least privilege by:

• Granting only the permissions required for a role
• Avoiding unnecessarily broad roles
• Reviewing inherited permissions
• Separating administrative responsibilities
• Removing inactive access
• Protecting privileged accounts
• Reviewing service-account permissions
• Monitoring changes to IAM policies

IAM should cover both human and non-human identities. Applications, automation systems, deployment pipelines, containers and external workloads may all require carefully controlled access.

Identity should be treated as a core security boundary rather than simply an administrative task.

Reduce Service Account Key Risk

Long-lived service account keys can create significant risk if they are copied, exposed or poorly managed.

For external workloads, Workload Identity Federation allows workloads to authenticate through supported external identity providers instead of relying on long-lived service account keys. Google documents support for environments such as AWS, Azure, GitHub, GitLab, on-premises systems and other identity providers.

For workloads running in Google Cloud and GKE, organizations can also use workload identity capabilities and attached service accounts where appropriate.

The goal is to minimize the use of long-lived credentials and grant workloads only the access they actually need.

Protect Sensitive Data With VPC Service Controls

IAM answers an important question:

Who is allowed to access a resource?

VPC Service Controls addresses a different part of the problem by helping create security perimeters around supported Google Cloud services and resources to reduce data-exfiltration risk.

VPC Service Controls can help mitigate risks involving stolen credentials, compromised workloads and unauthorized data movement. It should be viewed as an additional security layer rather than a replacement for IAM.

For sensitive environments, organizations should evaluate:

• Which services need perimeter protection
• Which projects should be included
• Required ingress and egress paths
• Access levels
• External integrations
• Data-sharing requirements
• Operational limitations and supported services

Configure Google Cloud Firewall Rules Carefully

Customers remain responsible for important network-security decisions, including firewall rules, ingress and egress controls, network segmentation, administrative access, public exposure and hybrid connectivity.

Google Cloud's current Cloud Next Generation Firewall capabilities include controls for traffic entering and leaving VPC networks as well as traffic between resources inside VPC networks.

A secure firewall strategy should:

• Permit only required traffic
• Restrict administrative interfaces
• Minimize unnecessary public exposure
• Control outbound traffic where appropriate
• Use segmentation for sensitive workloads
• Review rules regularly
• Remove temporary rules when they are no longer required

Temporary firewall rules should have a clear owner and, where practical, an expiration or review date.

Use GCP Security Services for Visibility and Control

Google Cloud provides a broad set of security capabilities, but customers still need to select, configure, monitor and act on the controls relevant to their environments.

Security Command Center

Security Command Center (SCC) is Google Cloud's centralized security and risk-management platform. Current capabilities include security posture management, vulnerability detection, threat detection, compliance and data-security capabilities, asset discovery and security findings. Available functionality depends on the service tier and configuration.

Security Command Center can help organizations identify issues such as:

• Cloud misconfigurations
• Publicly exposed resources
• Vulnerabilities
• Leaked credentials
• Excessive permissions
• Active threats
• Security-posture problems
• Compliance-related issues
• Sensitive-data risks

Current Google Cloud documentation describes Standard, Premium and Enterprise service tiers, with different levels of functionality.

A security finding does not automatically resolve the underlying problem. Security teams still need to:

1. Review the finding.
2. Determine its business and technical impact.
3. Assign ownership.
4. Remediate the issue.
5. Verify the remediation.
6. Document or track the outcome where required.

Google Cloud Audit Logs

Google Cloud Audit Logs help organizations answer a fundamental security question:

Who did what, where and when?

Cloud Audit Logs can record administrative activity, data access, system events and policy-denied activity.

Organizations should determine:

• Which audit logs are required
• Which Data Access logs are important
• How long logs should be retained
• Where logs should be routed
• Which events should generate alerts
• Who investigates suspicious activity
• How security evidence is protected

Collecting logs is only one part of security monitoring. Teams also need processes for analyzing important events and responding to suspicious activity.

GCP Compliance and Security Assessment

Google provides infrastructure security, compliance documentation and security capabilities, but a customer's workload does not automatically become compliant simply because it runs on Google Cloud.

A GCP security assessment should consider:

• IAM permissions
• Public exposure
• Data protection
• Network configuration
• Logging and monitoring
• Vulnerabilities
• Backup and recovery
• Service accounts
• Identity federation
• Regulatory requirements
• Data residency and location requirements
• Customer-controlled security processes

Compliance requirements vary according to the organization, industry, jurisdiction, contracts and type of information being processed.

The correct approach is to map the applicable requirements to the controls the organization actually operates.

Google Cloud Security Best Practices

The following steps turn the shared responsibility model into a practical security process.

1. Inventory Workloads and Owners

Maintain a current inventory of projects, applications, data stores, APIs, service accounts, workloads, networks and external integrations.

Every important workload should have clearly identified ownership so that security findings and configuration issues can be assigned to the right people.

2. Document the Responsibility Boundary

For every major Google Cloud service, document:

• What Google manages
• What the customer manages
• Which controls are shared or service-dependent
• Who owns each customer-controlled responsibility
• What evidence demonstrates that the control is operating

Do not assume that Compute Engine, GKE, Cloud Run and BigQuery have identical security responsibilities.

3. Apply Least-Privilege Access

Use narrowly scoped IAM roles and minimize unnecessary service account credentials.

Review permissions across the Google Cloud resource hierarchy, including organizations, folders, projects and individual resources.

Regular access reviews are particularly important for privileged identities and service accounts.

4. Follow Secure Architecture Guidance

Use the Google Cloud Well-Architected Framework, particularly its Security, Privacy and Compliance pillar, when designing and operating workloads. The current framework emphasizes principles such as security by design, zero trust and shift-left security.

Security should be considered during architecture and deployment rather than added only after a workload becomes operational.

5. Monitor Continuously

Combine appropriate Google Cloud security capabilities, including Security Command Center, Cloud Audit Logs, workload telemetry, network monitoring and IAM monitoring.

Monitoring should prioritize meaningful security risks rather than simply generating large volumes of alerts.

6. Test Controls Regularly

Conduct periodic GCP security assessments and cloud security audits.

Test whether the organization can identify and correct:

• Excessive permissions
• Publicly exposed resources
• Disabled or insufficient logging
• Vulnerable software
• Unsafe network paths
• Unmanaged service accounts
• Unapproved data movement
• Inadequate backup or recovery controls

Security controls should be tested in practice rather than assumed to work because they have been configured once.

Frequently Asked Questions

What Is the Google Cloud Shared Responsibility Model?

The Google Cloud shared responsibility model divides security responsibilities between Google and the customer. Google secures the underlying cloud infrastructure, while customers remain responsible for their data, identities, applications, workloads and customer-controlled configurations. The exact boundary changes depending on the service being used.

What Is Google Always Responsible For?

Google is responsible for the provider-controlled infrastructure used to deliver Google Cloud services, including physical infrastructure, hardware, core networking and other underlying components. The exact scope of Google's responsibility expands for more managed services.

What Are GCP Customers Always Responsible For?

Customers remain responsible for their data and access policies and for securing the customer-controlled parts of their workloads. This commonly includes identities, IAM configuration, applications and service configuration, although the precise boundary depends on the service.

What Is the Difference Between Shared Responsibility and Shared Fate?

Shared responsibility describes the division of security duties between Google and the customer. Shared fate is Google's broader operating model, which emphasizes working with customers toward better security and risk outcomes through secure foundations, guidance, recommended architectures and integrated capabilities. It does not eliminate customer responsibility.

Does Security Command Center Automatically Secure GCP?

No. Security Command Center can help identify vulnerabilities, misconfigurations, threats, posture issues and other security risks, but organizations must configure the service appropriately, review findings, perform remediation and verify that problems have been resolved.