On Google Cloud, Google secures the underlying network and infrastructure, and you always remain responsible for your access policies and your data. Everything between those two edges moves depending on whether you use IaaS, PaaS, SaaS or serverless services. Your first job is to find out where each service sits.
What does Google's own documentation say?
Google's architecture guidance says you decide which security controls your workloads need, based on your regulatory obligations, your organization's standards and the requirements of your customers and vendors. Responsibilities vary with the workload, the industry and regulatory framework, and where your data and customers are. One sentence summarizes the floor: customers always remain responsible for their access policies and data, and Google always remains responsible for the underlying network and infrastructure.
Google also describes "shared fate", its way of saying it wants to go beyond a simple split. Its stated parts include operating a trusted platform, publishing opinionated best practices and secured infrastructure code, and providing governance tools. Treat that as the vendor's description of its approach, and still verify your own controls.
How does the split move across service models?
- IaaS, for example Compute Engine, Cloud Storage and Cloud VPN: you carry most of the responsibilities. Google focuses on the underlying infrastructure and physical security.
- PaaS, for example App Engine, GKE and BigQuery: Google handles more controls. You share application-level controls and IAM management, and you stay responsible for data security and client protection.
- SaaS, for example Google Workspace: Google owns most responsibilities. You remain responsible for access controls and the data you store.
- Serverless functions, for example Cloud Run functions: responsibilities are similar to SaaS, according to Google's guidance.
What does that mean for a development team?
Even in the most managed service, the code you deploy and the identities you grant are yours. Constructed example: a team runs a service on a managed platform. Google patches the host and the runtime. The team's container image includes an old image-processing library with a known flaw, and the service account attached to the service can read every storage bucket in the project. Neither problem is Google's. The first is a dependency issue, the second an access policy issue, and both are exactly the category the guidance says stays with you.
Where do dependencies fit?
The documentation lists areas by service type, and your application's open source components fall under the code you ship. That is true in every service model, because the platform does not choose your packages. So the split does not remove the need for an inventory of components, a vulnerability process and a way to rebuild and redeploy quickly.
What to do
- For each Google Cloud service you use, write down which model it is (IaaS, PaaS, SaaS or serverless) and who owns each control.
- Review IAM: one service account per workload, minimal roles, no broad project-level grants.
- Treat data classification and encryption choices as yours, and record them.
- Keep a software bill of materials for every deployed image.
- Scan dependencies and images in CI, and block deploys that break your policy.
- Log administrative and data access, and send the logs where someone reads them.
- Re-check the split whenever you adopt a new managed service.
Safeguard covers the dependency and SBOM side with scanning, reachability analysis and policy gates. It does not replace cloud configuration tools.
Quick check
Who is responsible for my data in a fully managed Google service?
You are. Google's documentation says customers always remain responsible for their access policies and data.
Does Google patch the libraries in my container?
Google's responsibility covers the platform side. The packages you put in your own image are part of the code you ship, so plan to patch them yourself.
Sources
Last reviewed: 18 October 2026.
