Google Cloud’s trust principles and compliance

Study guide for Cloud Digital Leader, Unit 5 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Describe how Google Cloud earns and maintains customer trust in the cloud.

Objectives, quoted from the exam guide:

Discuss how Google Cloud's trust principles are a commitment to our shared responsibility for protecting and managing an organization’s data in the cloud.
Describe how sharing transparency reports and undergoing independent third-party audits support customer trust in Google.
Describe why data sovereignty and data residency may be requirements and how Google Cloud offers organizations the ability to control where their data is stored.
Describe how Google Cloud compliance resource center and Compliance Reports Manager support industry and regional compliance needs.

Google Cloud's trust principles and compliance

Trust is a set of commitments, and each one comes with evidence

What Google commits to about your data. How you can check — transparency reports, independent audits, access logs. Where your data lives, and who controls it — residency and sovereignty. Where the evidence is kept — the compliance offerings and Compliance Reports Manager.

Topic one of this unit asked what security means in the cloud, and topic two looked at the infrastructure Google runs. This topic asks a different question: why should an organization trust a provider with its data at all? The guide's summary is to describe how Google Cloud earns and maintains customer trust. Its four objectives answer that in four steps. First, the commitments: what Google promises about customer data, and how those promises are Google's half of a shared responsibility. Second, verification: how anyone can check those promises, through published transparency reports and audits by independent third parties. Third, control over location and access: why some organizations must keep data in a particular place, and what Google offers them. And fourth, the evidence itself: where a compliance team finds the certificates and reports its own auditors will ask for. The thread through all four is that trust is not asked for, it is shown.

The trust principles: Google's side of the bargain

Your data is yours, and Google says what it will not do with it

Data you store on Google's systems is yours
No scanning for advertising, no selling, no AI training without permission
Processing only to meet contractual obligations; encrypted by default
Leave with your data, without penalty or additional cost

Worked example (synthetic). A hospital's legal team asks whether patient records could end up training a vendor's model. The answer it needs is a commitment in writing, not a reassurance — and Google publishes one.

The first objective frames Google's trust principles as a commitment to shared responsibility for protecting and managing an organization's data. Start with what Google actually commits to, in its own words from the security overview. Data that you store on our systems is yours. We don't scan your data for advertising purposes, we don't sell it to third parties, and we don't use it to train our artificial intelligence (AI) models without your permission. Google's Data Processing Addendum, the security overview says, states that Google won't process data for any purpose other than to meet its contractual obligations. By default, Google Cloud uses several layers of encryption to protect data stored in its production data centers. And there is an exit: if you choose to stop using the services, Google provides tools that let you take your data with you, without penalty or additional cost. Now the shared part. Google's framework describes the shared responsibility model as the tasks that you have for security in the cloud, and how those tasks differ for the provider. The trust principles are Google's half of that division. The customer's half does not disappear: Google's overview is explicit that, as the data owner, you are primarily responsible for responding to law enforcement data requests. A commitment from the provider is a floor under the customer's own obligations, not a replacement for them.

Each commitment, and what stays with the customer

A promise from Google is not a task removed from you

Google commits to	What still sits with the customer
Your stored data is yours; it is not sold or scanned for advertising	Deciding what data goes in, and who in the organization may use it
Processing only to meet contractual obligations	Agreeing those obligations — the contract is where the commitment lives
Employee access is monitored, audited and logged to you	Reading the logs, and approving access where it chose to require approval
Take your data with you if you leave	Planning the exit it may one day need
Publishing how it handles government requests	Responding to law enforcement requests, as the data owner

Worked example (synthetic). A bank's board asks who answers a court order for customer records held in Google Cloud. The right answer is the bank: Google's commitment is to redirect the request and notify, not to answer for the owner.

Read the commitments as one column of a two-column arrangement, because that is how the exam will test them. Every commitment Google makes has a matching task that stays with the customer. Your data is yours and it is not sold or scanned for advertising — but deciding what goes in, and who may use it, is still yours. Processing is limited to meeting contractual obligations — and the contract is something the customer agrees to. Google's security, privacy and internal audit teams monitor and audit employee access, and provide audit logs to you through Access Transparency — but those logs protect no one unless someone reads them. You can take your data with you — but an exit plan is the customer's to make. And on government requests, Google's policy is to direct the government to request the data directly from the customer, which is the other side of the fact that the data owner is primarily responsible for responding. That is what the guide means by trust principles as a commitment to shared responsibility: each principle is a promise with a named counterpart, not a transfer of the whole problem.

Transparency reports and independent audits

A promise can be checked two ways: published data, and an outside auditor

Transparency Report: how Google responds to government data requests
Policy: notify you of requests unless prohibited by law or court order
Independent verification of security, privacy and compliance controls
Certifications, attestations and audit reports as the evidence

Worked example (synthetic). A procurement team scoring three cloud vendors gives no marks for a vendor's own claims about itself. It gives marks for a report signed by an auditor the vendor does not employ.

The second objective asks how transparency reports and independent third-party audits support trust, and they support it in two different ways. The transparency report is public data. Google says it believes the public deserves to know the full extent to which governments request information from it; it describes itself as the first company to start regularly publishing reports about government data requests, and says detailed information about those requests and its responses is available in its Transparency Report. Alongside that sits a stated policy: to notify you about requests for your data unless specifically prohibited by law or court order. Independent audits are a different kind of evidence. Google says Google Cloud regularly undergoes independent verification of its security, privacy and compliance controls, and receives certifications, attestations and audit reports to demonstrate compliance, and that an internal team supports independent audits and assessments by third parties. The difference is who is speaking. A transparency report is Google telling you what happened. An audit is someone Google does not control telling you whether Google's controls do what Google says. Trust needs both, because a claim nobody outside can test is only a claim.

Transparency you can switch on

Access Approval asks first; Access Transparency records what happened

Loading Diagram...

Figure 1 — Mermaid diagram

Figure: A flow chart. When Google support or engineering needs access to customer data, if Access Approval is enabled the customer gives or denies explicit approval first. Access then happens, and an Access Transparency log records who, what, when and why, which the customer reviews.

Worked example (synthetic). A regulator asks a payments firm to prove no provider employee read card data last quarter. The firm hands over its Access Transparency logs — and, because it enabled Access Approval, its own approval records too.

Transparency reports are about governments. For access by Google's own people, Google offers something a customer can turn on and read. Access Transparency, in Google's words, is part of its long-term commitment to transparency, user trust and customer ownership of data, and its logs record the actions that Google personnel take when accessing customer data. Access Approval goes one step earlier: it ensures that Cloud Customer Care and engineering teams require your explicit approval whenever they need to access your customer data, and Google describes it as an additional layer of control on top of the transparency that Access Transparency logs provide. So the flow has an order worth remembering. With Access Approval enabled, the request stops at the customer first. Either way, the access is logged by Access Transparency, and the customer can review who acted, on what, when and why. Approval is control before the fact; transparency is evidence after it. An exam item that offers the log as a way to prevent access has the order backwards.

Three kinds of evidence, three different speakers

Who produced it decides what it proves

Evidence	Who produces it	What it shows
Transparency Report	Google, publicly	How Google responds to government requests for data
ISO/IEC 27001 certificate	An accredited audit by an independent third party	Google's information security management system meets the standard
SOC 2 report	An objective third party attesting to Google's assertions	Controls protecting customer data, tested over a period
Access Transparency logs	Google, per customer	Each access to that customer's data by Google personnel

Worked example (synthetic). A risk officer asked whether controls actually operated all year reaches for the SOC 2 report, not the ISO/IEC certificate — the report covers operation over a period.

The objective says transparency reports and independent third-party audits, and it helps to line up the evidence by who produces it. The Transparency Report is published by Google. The International Organization for Standardization and International Electrotechnical Commission standard 27001, written ISO/IEC 27001, is different: Google says its information security management system received an accredited ISO/IEC 27001 certification after undergoing an audit by an independent third party. A Service and Organization Controls, or SOC, 2 report is different again: Google says these reports are generated by an objective third party attesting to a set of assertions Google Cloud makes about the controls that protect customer data, and that customers may use the report to assess risks throughout the audit period; Google says its SOC 2 and SOC 3 reports are available to its customers. And Access Transparency logs are produced by Google for one customer about that customer's data. The exam likes to ask which of these an outsider vouches for. The two with a third party in the middle column are the audits.

Data residency and data sovereignty

Residency is where the data rests; sovereignty is who can reach it

Data residency: where your data is stored at rest
Required by regulations for data storage, key management and access
Some organizations must keep data within certain regions or countries
Some must also control Google personnel access to their data

Worked example (synthetic). A European health insurer is told its claims data must stay in the EU. That is residency. Its regulator then asks who at the provider could read the data, and who holds the keys. That is sovereignty.

The third objective asks why data sovereignty and data residency may be requirements, and how Google Cloud lets organizations control where data is stored. Google defines one of the two terms precisely: data residency describes where your data is stored at rest, and to help comply with residency requirements Google Cloud gives you the ability to control where that data is stored. Google does not publish a one-line definition of data sovereignty, so read it from what Google's sovereignty controls actually control. Assured Workloads, in Google's words, lets organizations configure a sovereign data and access boundary with residency, access and personnel controls. So sovereignty reaches past location, to who can access the data and who holds the keys. As for why these become requirements, Google names the organizations directly: those with strict regulations for data storage, key management and access, such as financial services, healthcare and governmental bodies; those that must store their data within certain regions or countries; and those that must control Google Cloud personnel access to their data. The first two lines are residency. The third is where sovereignty begins.

Two questions a regulator asks

Where is it? And who could get to it?

Figure. Two cards. Data residency answers where the data is stored at rest, through location choice and a location-restricting policy. Data sovereignty answers who can access the data and who holds the keys, through access, personnel and key controls.

Worked example (synthetic). An item says a company's data is already pinned to one country but its regulator is still unsatisfied because a foreign provider's staff could access it. The missing control is sovereignty, not residency.

Put the two terms side by side as the two questions a regulator actually asks. The first is where the data is stored at rest — that is residency, and it is answered by choosing locations. The second is who could get to the data, and who holds the keys to it — that is where sovereignty goes further. Google's strongest example of the second is Cloud External Key Manager: with it, you control the location and distribution of your externally managed keys, and those keys are never cached or stored within Google Cloud. A workload can satisfy the first question completely and still fail the second, which is exactly the trap in exam items that pin the data to a country and then ask why the regulator is still not satisfied.

How Google Cloud gives the control

From one policy constraint to a partner-operated boundary

Control	What it does	Answers
Resource Locations organization policy	Restricts where new resources can be created, at organization, folder or project level	Residency
Assured Workloads	A sovereign data and access boundary: residency, access and personnel controls	Residency and sovereignty
Cloud External Key Manager	Keys managed outside Google Cloud, never stored within it	Sovereignty
Sovereign Controls by Partners	A local, trusted partner manages encryption keys, access justification and audits	Sovereignty

Worked example (synthetic). A company sets a Resource Locations policy today and assumes its three-year-old databases have moved. They have not: the constraint applies only to newly created resources.

Google offers these controls in increasing strength. The simplest is a Resource Locations organization policy constraint, which, in Google's words, restricts the location of new in-scope resources at the organization, project or folder level. Note the word new: Google says that after you define resource locations, the limitation applies only to newly created resources, so it does not move what already exists. Assured Workloads bundles residency with access and personnel controls into one boundary, and Google says to use it if your organization must ensure compliance with specific regulatory, regional or sovereignty requirements. Cloud External Key Manager keeps the keys outside Google Cloud entirely. And Sovereign Controls by Partners lets you use a local, trusted partner to manage encryption keys, access justification and audits. Read the right-hand column when an item describes a requirement: a location rule points to the top row, a rule about who may reach the data points further down.

The compliance resource center and Compliance Reports Manager

One tells you what Google meets; the other hands you the proof

Resource	What it is for
Compliance offerings (the resource center)	Which certifications and compliance standards Google satisfies, plus general information on region- and sector-specific regulations
Compliance Reports Manager	On-demand access to the documents themselves — ISO/IEC certificates, SOC reports and self assessments
Sign-in	Some resources require a Google Cloud or Google Workspace account

Worked example (synthetic). A school district's auditor asks for the provider's current ISO/IEC 27001 certificate. The offerings page confirms Google holds it; Compliance Reports Manager is where the district downloads it.

The fourth objective names two resources, and the exam separates them by what they give you. The guide calls the first the compliance resource center; Google's page for it is titled compliance offerings, and describes itself as containing information about Google's certifications and the compliance standards it satisfies, as well as general information about certain region- or sector-specific regulations. Google says its products regularly undergo independent verification of security, privacy and compliance controls, achieving certifications against global standards, and that the page exists because, to help you with compliance and reporting, it shares information, best practices and easy access to documentation. The second is Compliance Reports Manager, which Google says provides easy, on-demand access to these critical compliance resources, and whose key resources include the latest International Organization for Standardization and International Electrotechnical Commission certificates, Service and Organization Controls reports, and self assessments. Some of them require signing in with a Google Cloud or Google Workspace account. So the offerings page answers the question does Google meet this standard, and Compliance Reports Manager answers the question can I have the document that proves it.

From an auditor's question to the customer's own certification

Google's certificate is an input to yours, not a substitute

Loading Diagram...

Figure 2 — Mermaid diagram

Figure: A flow chart: an auditor asks whether the provider is certified; the compliance offerings page shows which standards Google meets; Compliance Reports Manager provides the certificate or report; the customer uses it to understand how Google implemented the controls; and the customer completes its own implementation and certification.

Worked example (synthetic). A fintech assumes that running on a certified provider makes the fintech itself ISO/IEC 27001 certified. The last box in the figure is the one it skipped.

Drawn as a flow, the fourth objective ends somewhere candidates do not expect. An auditor asks whether the provider is certified. The compliance offerings page shows which standards Google meets, and Compliance Reports Manager supplies the document — Google says, for example, that its International Organization for Standardization and International Electrotechnical Commission 27001 certificates may be requested using Compliance Reports Manager. But the flow does not stop at Google's certificate. Google is explicit: your organization will have to seek out and obtain its own certification, but you can leverage the Google Cloud certificate to understand how Google has implemented the requirements for its products. That is the shared responsibility from objective one, arriving again as a compliance fact. Google's audits, certifications, documentation and contract commitments, in its own words, help support your compliance. They support it; they do not confer it.

What this topic actually tests

Four discriminations, four objectives

Whose task is it? each commitment has a customer counterpart. Who is vouching? Google publishes the Transparency Report; a third party audits. Where, or who? residency is location; sovereignty is access and keys. Is it, or can I have it? the offerings page says what Google meets; Compliance Reports Manager hands over the proof — and your own certification is still yours.

Close on the four discriminations this topic tests. First, whose task is it: every trust principle is a commitment from Google with a counterpart that stays with the customer, such as responding to law enforcement requests as the data owner. Second, who is vouching: a transparency report is Google speaking, while a certification against the International Organization for Standardization and International Electrotechnical Commission standard, or a Service and Organization Controls, SOC, 2 report, is an independent third party speaking — both come from auditors Google does not control. Third, where, or who: residency is where data rests; sovereignty adds who can access it and who holds the keys. Fourth, is it, or can I have it: the compliance offerings page says which standards Google meets, and Compliance Reports Manager hands over the document — which helps your own certification but never replaces it. Unit 6 turns from trust to operations, and the shared responsibility idea comes with it.

Unit 5.3 study guide — Google Cloud’s trust principles and compliance