GCP Shared Responsibility Model Explained: Who Secures What?

The simple version

Here is the clearest way to put it: Google secures the cloud. You secure what you put in the cloud.

That one-liner is accurate but incomplete. The real picture is more specific:

• Google always secures: physical hardware, data centres, the global network, hypervisor isolation between tenants, and the reliability of managed services

• You always secure: IAM and access control, your application code, your data, service account permissions, and how your resources are exposed on the network

• The split shifts by service type: with VMs you own the OS and installed software; with Cloud Run, Google owns the OS but you own your container image; with Cloud SQL, Google patches the database engine but you still own access control, network rules, and encryption choices

Most cloud security incidents do not happen because Google’s infrastructure was compromised. They happen because customers leave a storage bucket public, grant overly broad IAM roles, or skip patching a VM. The shared responsibility model is the framework that explains why those are the customer’s problem, not Google’s.

What Google secures

Google’s responsibility covers the infrastructure GCP runs on. You cannot configure, inspect, or audit any of this directly. Google manages it on your behalf:

• Physical data centre security: building access control, hardware, power, environmental systems, and physical surveillance

• Network infrastructure: the global fibre backbone, undersea cables, hardware routing, and DDoS mitigation at the network edge

• Hypervisor and hardware isolation: your VM cannot read memory from another customer’s VM running on the same physical host

• OS and runtime patching for managed services: when you use Cloud Run, App Engine, or Cloud SQL, Google patches the underlying OS and database engine

• Managed service reliability: uptime SLAs for Cloud SQL, Cloud Run, BigQuery, and other managed offerings

• Compliance certifications: ISO 27001, SOC 2, PCI-DSS, and others apply to Google’s infrastructure layer, not automatically to what you build on top of it

What you always secure

These responsibilities never shift to Google, regardless of which GCP service you use:

• IAM and access control: who has what permissions on which resources. A misconfigured IAM policy that grants roles/editor to everyone is your decision. Fixing it is your job.

• Service account permissions: what your workloads are allowed to do. Overly permissive service accounts are one of the most common cloud security problems and one of the easiest to prevent.

• Your application code: SQL injection vulnerabilities, insecure API endpoints, hardcoded credentials, and logic bugs. Google cannot inspect your application logic or identify those vulnerabilities for you.

• Data classification and handling: knowing which data is sensitive, where you store it, and whether it is encrypted appropriately.

• Regulatory compliance for your data: GDPR, HIPAA, or any regulation governing data you collect is your compliance obligation, not Google’s.

• Network exposure decisions: whether a VM, Cloud Run service, or database is reachable from the internet. GCP’s network is private by default. You make it public.

How responsibility shifts by service type

The core principle: the more managed the service, the more infrastructure Google handles. But you always retain ownership of identity, access, data, and application-level security, no matter which service type you choose.

Compute Engine (IaaS)

You manage the most here. Google secures the physical hardware and hypervisor, but everything inside your VM is your responsibility: the operating system, installed packages, patch schedule, firewall configuration, and the applications running on it. An unpatched kernel vulnerability on a Compute Engine VM is your risk. If someone breaks in through an outdated, unpatched service on your VM, that is a customer responsibility failure, not a GCP infrastructure flaw.

Cloud Run and App Engine (PaaS)

Google manages the OS and runtime underneath your container. Your responsibility shifts to what is inside the container: your application code, your base image choice, and the dependencies you bundle. A vulnerable base image (for example, node:18 with known CVEs) in a Cloud Run container is your responsibility even though Google manages the host OS. Rebuild images regularly, use minimal base images, and scan for vulnerabilities before deploying.

BigQuery and Cloud SQL (managed services)

Google runs the service. You are responsible for who can access it, which networks can connect, how data is encrypted at the application level, and what you store in it. A Cloud SQL instance with roles/editor granted to an overly broad group is a customer configuration mistake. Google guarantees availability. It does not configure your access controls.

Responsibility at a glance

This table shows who owns each layer depending on the service type. “Google” means Google handles it automatically. “You” means it is your responsibility to configure and maintain. “Shared” means Google provides the mechanism and you decide how to use it.

Shared areas: where both sides play a role

Encryption

Google encrypts all data at rest by default using Google-managed keys. You decide whether to use customer-managed encryption keys (CMEK) via Cloud KMS for tighter control over key lifecycle and access. Application-level encryption (encrypting specific fields before writing to a database) is entirely your responsibility. See Encryption in Google Cloud and Customer-Managed Encryption Keys for the full picture.

Audit logging

GCP generates Admin Activity audit logs automatically and for free. You decide what else to enable: Data Access logs for services handling sensitive data, how long to retain logs, and whether to export them to Cloud Storage or BigQuery for compliance. Leaving Data Access logs disabled for services that handle regulated data is a customer oversight, not a platform default. See Cloud Audit Logs for what to enable and how to query it.

Network configuration

GCP provides the network fabric via VPC. You configure which resources are reachable from the internet, which subnets connect to what, and which firewall rules apply. The network is private by default. It only becomes exposed when you configure it to be.

When you need to think about shared responsibility

The shared responsibility model is not abstract theory. It has direct practical implications at specific moments in any GCP project:

• Deploying your first workloads: before you put anything in production, you need to know which security tasks are yours. Defaulting to “Google handles security” is how misconfigurations happen.

• Choosing between VMs, containers, and managed services: the service type determines your security surface. Running a Compute Engine VM means you own the OS patch cycle. Cloud Run shifts that to Google, but you now own your container image. Make the trade-off deliberately.

• Granting IAM roles: IAM is always your responsibility. Every time you add a binding, you are making a shared responsibility decision.

• Using managed databases: Cloud SQL and BigQuery remove infrastructure management, but access control, network exposure, and encryption configuration are still yours.

• Preparing for audits or compliance reviews: auditors will ask what Google is responsible for versus what your team is responsible for. The shared responsibility model is the direct answer to that question.

• Responding to a security incident: knowing which layer an incident occurred in tells you whether Google’s infrastructure team is responsible or whether your team must remediate it.

How to apply this in practice

For every project you deploy in GCP, run through these checks. These are the customer-side responsibilities that are most commonly skipped.

For every GCP service

• Apply IAM least privilege: grant only the roles actually needed, scoped to the narrowest resource possible

• Create dedicated service accounts per workload; do not share the default Compute Engine service account across services

• Enable Data Access audit logs for any service handling sensitive or regulated data

• Store secrets in Secret Manager, not in environment variables, source code, or configuration files

• Review IAM bindings periodically. They accumulate over time, and stale access is a real risk.

For Compute Engine VMs

• Enable OS patch management or schedule manual patching for the guest OS. This is fully your responsibility, not Google’s.

• Use Shielded VMs to protect against boot and firmware-level attacks

• Use OS Login or Identity-Aware Proxy (IAP) for SSH access instead of opening port 22 to the internet

• Review firewall rules and remove any that allow broader access than the workload actually needs

For containerised workloads (Cloud Run and GKE)

• Keep base images up to date and rebuild on a regular schedule. Outdated container images are your responsibility, not Google’s.

• Scan container images for known vulnerabilities before deploying (Artifact Registry can do this automatically)

• Set Cloud Run ingress to “Internal only” or “Load balancer” for services that are not intended to be public

• For GKE, review GKE cluster security settings, including node pool service accounts and Workload Identity configuration

For managed databases and storage

• Configure authorised networks and use private IPs for Cloud SQL. Do not leave database instances with a public IP unless you have a specific reason and strict firewall rules.

• Review Cloud Storage bucket IAM and confirm no bucket has allUsers access unless that is explicitly intentional

• Enable customer-managed encryption keys for data that requires it under your compliance requirements

• Use VPC Service Controls to restrict access to managed services to traffic from within your VPC perimeter