DPIA on the use of Google Cloud Platform

DPIA on the use of Google Cloud Platform Data protection impact assessment on the processing of personal data with Google Cloud Platform (GCP) services Version 1. 3 Date 11 June 202 6 Status Public Page 1 of 142 Colo ph on DPIA by Ministry of Justice and Security Strategic Vendor Management Google , Google Cloud and AWS ( SLM Rijk ) Turfmarkt 147 2511 DP The Hague PO Box 20301 2500 EH The Hague www.rijksoverheid.nl/jenv Contact E SLM Rijk microsoft @minjenv.nl T 070 370 79 11 Project Name DPIA report on the use of Google Cloud Platform Authors Privacy Company Sjoera Nas and Floor Terra , senior advisors https:// www.privacycompany.eu / DPIA on Google Cloud Platform public version 11 June 2026 Change log Version Date Summary of input 0.1 2 7 January 2025 First draft of part A shared with SLM Rijk 0.2 28 January 2025 Comments in track changes after SLM Rijk review 0.3 28 January 2025 Clean version for review by Google 0.4 22 April 2025 New version with track changes after new input from Google 0.5 2 May 2025 Draft complete DPIA for SLM , with some track changes in part A 0.6 14 May 2025 Track changes input SLM processed 0.7 1 6 May 2025 Clean complete DPIA for SLM (with track changes in Part compared to version 0. 3 ) 0.8 1 October 2025 Track changes after input Google 0.9 6 November 2025 Version with track changes shared with Google 1.0 2 March 2026 Version with final track changes 1.1 2 March 2026 draft p ublic version for confidentiality DPIA on Google Cloud Platform public version 11 June 2026 Glossary Admin Console Google uses the term Cloud Console to refer to its GCP administration portal.

Privacy Company uses the term Admin Console as the generic terms for all administration portals across all DPIAs. Content Data All personal data uploaded by a customer (admin) to the Google Cloud Platform , including Feedback Data , and for example audit logs exported to BigQuery . According to the contract with Google, Feedback Data are part of the Service Data, but since Feedback is content provided by the customer, this DPIA continues to qualify Feedback Data as Content Data, in line with all other DPIAs . Customer ( Personal ) Data Google’s narrower contractual definition of Content Data CMA Cloud Master Agreement Diagnostic Data Term used in this report to address all personal meta data recorded as a result of the use of the Google Cloud Services. Includes Telemetry Data , Service Generated Server Logs ( including web server access logs) and Google’s security logs . DPA Data Protection Authority, officially named National Supervisory Authority in the GDPR DPIA Data Protection Impact Assessment EDPB European Data Protection Board , the body that unites the national DPAs in the EU, and the EDPS, the supervisory authority on the European Institutions GCP Google Cloud Platform GCPN Google Cloud Privacy Notice GDPR General Data Protection Regulation, EU Regulation 2016/679 SaaS Software as a Service, a cloud service that virtually delivers software applications over the internet.

SCC EU Standard Contractual Clauses Service Data Google’s term for Account Data, Diagnostic Data , Feedback Data , Support and Website Data, and contents of communication with Google. The term Service Data includes cloud settings and configuration. According to Google, Service Data can never include Content Data , but does include the contents of Feedback . This DPIA distinguishes between 5 categories of personal data, and does not use Google’s distinction between Customer Data and Service Data. Service Generated Server logs Diagnostic (personal) Data generated by Google on its cloud servers as a result of actions by admins. Can include Content Data (as defined in this report, see above). SLM Rijk abbreviated to SLM Rijk Strategisch Leveranciers Management (Strategic Vendor Management) Microsoft, Google Cloud , Amazon Web Services DPIA on Google Cloud Platform public version 11 June 2026 Page 7 of 142 and European Cloud Service Providers for the Central Dutch government , URL: https://www.slmmicrosoft.rijk.nl Telemetry Data Diagnostic Data sent from a user device or browser (in this case, administrators) to Google, different from service generated server logs .

VM Virtual Machine, called ‘ Compute Engine ’ by Google , part of the service Google Cloud Compute DPIA on Google Cloud Platform public version 11 June 2026 Summary Google provides many different cloud services , as infrastructure, as platform and as software. Together Google calls these services Google Cloud Platform (GCP). This Data Protection Impact Assessment (DPIA) assesses the risks of the use of f our services in combination : Compute Engine , Cloud SQL (MySQL), Cloud Storage , and BigQuery , with the corresponding A dmin C onsole . This report was commissioned by SLM Microsoft , Google Cloud and AWS Rijk ( the Strategic Vendor Management office housed at the Dutch Ministry of Justice and Security ) . Outcome: 11 low data protection risks The outcome of this DPIA is that there are 11 low data protection risks. These risks and mitigating measures are shown in more detail in the table at the end of this summary.

4 GCP - services by hosting a basic web application (NextCloud) on a Compute Engine (VM) that relied on the other tested services for a backend. Where possible, Privacy Company chose the Netherlands as location for the processing of the data ( europe - west - 4). Personal data This DPIA is based on a legal analysis of the available public documentation about the tested GCP - services , answers from Google to detailed questions from Privacy Company and a technical examination of the data processed by Google in its log files. T o better understand the data processing in log files by Google , a Privacy Company employee has performed a number of scripted scenarios and has accessed the available log file s from the Admin Console . In addition, a Data Subject Access Request was filed with Google to obtain the Diagnostic data relating to the behaviour of the test admin.

This report distinguishes between 5 categories of personal data processed by Google : 1. Content Data (customer uploaded Content Data in the Compute Engine , Cloud SQL database and Cloud S torage space) 2. Account Data ( of the admin ) 3. Diagnostic Data (including Telemetry Data of admin devices ) DPIA on Google Cloud Platform public version 11 June 2026 Page 9 of 142 4. Support Data for admins requesting support. 5. Website Data ( both the restricted access Admin Console and public access website for relevant documentation for admins ) Google only acknowledges two categories of data: Customer and Service Data (for categories 2 - 5), and objects to the distinction of five categories of personal data. Purposes, roles and legal grounds Based on the intention of Google and the Dutch government to negotiate an extension of the current enrolment framework for Google Workspace Enterprise, the Dutch government can instruct Google to process the five identified categories of personal data in two roles: as processor for 3 specific purposes, and as authorised data controller (minus the Content Data) for 7 legitimate business purposes, when necessary .

Analysis of the available legal grounds for government organisations shows that t he use of the te sted services results in 3 types of data processing f or which Google acts as unauthorised independent data controller. This is the case for (i) the processing of the Google Account Data outside of the GCP - context, (ii) for the processing of (some) Website Data relating to the Admin Console, (iii) for the publicly accessible GCP pages which admins have to visit . Google’s decisions about the data processing outside of the contractual instructions lead to a loss of control for the Dutch government organisations. Similarly Google’s lack of transparency also leads to a loss of control, resulting in several high data protection risks. International data transfers Based on the adequacy decision from the European Commission for US companies that participate to the EU US Data Privacy Framework , Dutch government organisations do not have to take extra measures when they transfer to participants such as Google.

However, in view of the turbulent geopolitical developments in the USA, government organisations have to prepare for annulment of the adequacy decision. In that case, they cannot rely on SCC but must conduct a Data Transfer Impact Assessment (also for the onward transfers to third countries from the USA ), and apply encryption with a self - controlled key. Such encryption is possible for all 4 services . . Dutch government organisations cannot control the data transfer of the Account, Diagnostic and Website Data, and are not able to apply encryption measures to these data . Government organisations also have to take the risk into account of sudden unavailability of personal data due to US American policy measures that may force Google to stop providing the services. Government organisations are advised to have back - ups availa ble outside of the tested GCP services for critical processes for which unavailability is unacceptable.

Table with risks and mitigating measures No. Low Risk Measures gov orgs Measures taken or announced by Google 1. Loss of control through lack of transparency Telemetry Data Study public documentation of the contents of telemetry events at https://support.google.com/ cloud/answer/16796043 . Google has published adequate documentation with relevant examples in Q1 2026, at https://support.google.com/cloud/ans wer/16796043 Use pseudonymous admin accounts. Google has listed 5 organisational and 6 technical measures it has in place to prevent collection, access and use of necessary Telemetry Data. These rules and policies prevent the collection of excessive personal and Content Data. DPIA on Google Cloud Platform public version 11 June 2026 Google has explained it has a policy not to collect user - defined resource identifiers as part of telemetry (for example, the chosen file names, virtual machine names, etc). 2.

Inability to exercise data subject access rights Inform admins how they can obtain access to the personal data about Admin log - in activities, and how they can access webserver access logs. Google commits to provide an appropriate response in reply to a DSAR, including data from web server logs relating to a user. Admins can also ask for the webserver access logs relating to specific users via a support ticket. Google commits to provide an explanation about the concept of such logs, and how they are typically used by GCP. Google will provide the reply as soon as possible and in compliance with GDPR timelines. 3. Loss of control through lack of transparency Website Data Follow the offline on - boarding process to ensure the government CMA applies. Google has changed the text in the cookie consent banner on the Cloud Console (console.cloud.google.com) to: " console.cloud.google.com uses cookies to deliver and enhance the quality of the services and to analyze traffic.

Learn more .” These purposes do not include advertising or profiling. Google is not allowed to further process any Service Data in a role as authorised data controller for advertising or profiling purposes. By the end of 2025 Google will add an explanatory sentence to its Cookie Policy about the NID - cookie. If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. 4. Loss of control over personal data in inaccessible security logs and small sample of network metadata If organisations want to see Google’s network sampling relating to their services, they can use the service VPC Flow Logs . There are no inaccessible security logs with personal data from visitors of webservices hosted on the tested Cloud - services. Google has confirmed that it does not collect additional logs about visits to a Dutch government website hosted on GCP other than the sampled packet metadata.

DPIA on Google Cloud Platform public version 11 June 2026 Page 11 of 142 5. Loss of control through lack of transparency profiling Follow the offline on - boarding process to ensure the government CMA applies. Google has explained that Dutch government organisations follow a specific offline onboarding process. They do not have to create a Google account, where it is mandatory to accept Google’s standard GCP Terms of Service (including advertising purposes ). Government admins can use non - google e - mail addresses. After SLM Rijk and Google have signed the amended CMA (incl. GCP Services Schedule) Google’s general privacy policy no longer applies, and Google can’t process the Account Data (part of the category of Service Data) for any advertising or profiling purpose s anymore. 6. Loss of control data transfer Content Data Use the existing option to choose the Netherlands/EU for processing of Content Data.

Google includes governing controls for Cloud EKM keys and Confidential Computing in the independent SOC - 2 Type II audit report. Google provided a copy of this report to SLM. Enable Access Transparency for the 3 tested services where that is available ( BigQuery is not fully supported ). Enable Assured workloads where possible. Google also organises independent annual pen tests on the two encryption services, but since these services were out of scope of the DPIA, Google did not provide information about the outcomes to SLM. Use Cloud EKM keys and Confidential Computing in case the EU US DPF is annulled. 7. Loss of control data transfer Account, Support, Diagnostic and Website Data No effective measures for Account, Diagnostic and Website Data No measures taken or announced. [ CONFIDENTIAL ] Enable Assured Workloads to be able to specify the geolocations from which Google may provide support.

Use pseudonymous admin accounts. 8. Reidentifica tion of pseudonymi sed Telemetry and Website Data Use pseudonymous admin accounts. Google retains the Telemetry and Website Data for a maximum period of 6 months (180 days). Google will publish information about the Telemetry Data retention periods as part of the announced new documentation. 9. Loss of control / confiden tiality due to Feedback Create a policy, and inform admins, not to provide Feedback to Google. No measures taken or announced. Google will not create a central option to disable Feedback. 10. Loss of control through lack Create a policy, and inform admins, that they are not allowed to use additional No measures taken or announced. Google will not change its practice of showing pop - ups about additional DPIA on Google Cloud Platform public version 11 June 2026 of privacy by default services Google may enable. Use of such services generally requires prior privacy and security approval. non - procured services such as Gemini. 11.

Chilling effects em ployee monitoring system. Complement internal privacy policy for the processing of employee (admin) personal data with rules for what specific purposes specific personal data in the log files may be (further) processed and analysed. This includes listing the specific risks against which the logs will be checked, and which measures the or ganisations will take to ensure purpose limitation. - no measures necessary - Conclusions If government organisations implement all recommended measures, and the EU US DPF remains in place, there are no more known high risks for the data processing. DPIA on Google Cloud Platform public version 11 June 2026 Page 13 of 142 Introduction This report, commissioned by Strategic Vendor Management Microsoft , Google Cloud and AWS ( SLM Rijk 1 ) housed at the Ministry of Justice and Security, is a data protection impact assessment (DPIA) about the processing of p ersonal data when using the Google Cloud Platform .

This DPIA report is written by the Dutch privacy consultancy firm Privacy Company. 2 Data Protection Impact Assessmen t (DPIA) Under the terms of the General Data Protection Regulation (GDPR), an organisation may be obliged to carry out a data protection impact assessment (DPIA) under certain circumstances . A ccording to Article 35, GDPR, a DPIA is required where the organisation is processing personal data on a large scale when it involves likely high risk to the rights and freedoms of the data subjects . The GDPR does not specify what constitutes a large scale. The DPIA is intended to shed light on, among other things, the specific processing activities, the inherent risk to data subjects, and to propose safeguards to mitigate these risks. The purpose of a DPIA is to ensure that any risks attached to the process in question are mapped and assessed, and that adequate safeguards have been implemented to mitigate those risks. 3 According to the GDPR a DPIA assesses the risks of data processing for the rights and freedoms of individuals.

Data subjects have a fundamental right to protection of their personal data and some other fundamental freedoms that can be affected by the processing of personal data, such as for example freedom of expression. The right to data protection is therefore broader than the right to privacy. Consideration 4 of the GDPR explains: “ This Regulation respects all fundamental rights and observes the freedoms and principles recognised in the Charter as enshrined in the Treaties, in particular the respect for private and family life, home and communications, the protection of personal data, freedom of thought, conscience and religion, freedom of expression and information, freedom to conduct a business, the right to an effective remedy and to a fair trial, and cultural, religious and linguistic diversity ” . This DPIA follows the structure of the DPIA Model mandatory for all Dutch governm ent organisations. 4 Umbrella DPIA versus individual DPIAs Pursuant to article 35 of the GDPR, a DPIA is mandatory if an intended data processing constitutes a high risk for the data subjects whose personal data are being processed.

The Dutch Data Protection Authority (Dutch DPA) has published a list of 17 types o f processing for which a DPIA is always mandatory in the Netherlands. 5 If a processing 1 SLM Rijk is the abbreviation of the Dutch words Strategisch Leveranciersmanagement (for the central government) Microsoft , Google Cloud and AWS . 2 https://www.privacycompany.eu/ 3 Google inaccurately replied that only high risks matter in a DPIA, not ‘any’ risks. 4 In Dutch only: Rapportagemodel DPIA Rijksdienst, 3.0, 25 July 2023, URL: https://www.kcbr.nl/sites/default/files/2023 - 08/Rapportagemodel%20DPIA%20Rijksdienst%20v3.0.docx 5 Dutch DPA, list of processings for which a DPIA is required, in Dutch only, Besluit inzake lijst van verwerkingen van persoonsgegevens waarvoor een gegevensbeschermingseffectbeoordeling (DPIA) verplicht is, URL: https://autoriteitpersoonsgegevens.nl/sites/default/files/atoms/files/stcrt - 2019 - 64418.pdf .

DPIA on Google Cloud Platform public version 11 June 2026 is not included in this list, an organization must itself assess whether the data processing is likely to present a high risk. The European national supervisory authorities (hereinafter referred to as the Data Protection Authorities or DPAs), united in the European Data Protection Board (EDPB) have also published a list of 9 criteria. 6 As a rule of thumb if a data processing meets two of these criteria a DPIA is required. In GDPR terms SLM Rijk is not the data controller for the processing of personal data via the use of Google Cloud Services . The data controller is the individual government organisation that decides to switch from on - premises IT to cloud services from Google or to combine the on - prem ises and cloud services. However, as central negotiator for many cloud services, SLM Rijk commissions the umbrella DPIA to detect common data protection risks and negotiate for a framework contract that complies with the GDPR.

The umbrella DPIA s assist the government organisations to select a privacy - compliant deployment . The government organisations must still conduct their own DPIAs. Only the organisations themselves can assess the specific data protection risks, related to the technical privacy settings, nature and volume of the personal data they process and vulnerability of the data subjects. This umbrella DPIA is meant to help the different government organisations with the DPIA they must conduct when they deploy Google Cloud Services , but this document cannot replace the specific risk assessments the different government organisations must make . Scope of this DPIA : Compute Engine , Cloud SQL (MySQL), Cloud Storage , BigQuery and Admin Console. This DPIA assesses the data protection risks of the use of a Compute Engine, Cloud SQL, Cloud Storage and Big Query and the use of the Admin Console . This DPIA covers: • Description of the Compute Engine , storage and database services , plus the related service s that are inextricably linked to the use of these services: the Google Cloud management console , the creation of a Google account to become admin and a Google Cloud Identity (admin) account ; • Role and purposes of Google as provider of the tested services • Transfer of personal data, both via content and log files, to countries outside of the European Economic Area ; • Exercise of data subject rights ; • Retention and backup periods.

Out of scope The following topics are outside of the scope of this DPIA: • Functional data (organisations need to send data , including personal data, to Google to communicate with a VM and database in the cloud . • The legal grounds for the processing of (special categories of) personal data by the individual government organisations . • Use of other Google Software - as - a - service (SaaS) and Platform - as - a - service (PaaS) in the cloud . 6 The EDPB has adopted the WP29 Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679, WP248rev.01, 13 October 2017, URL: https://ec.europa.eu/newsroom/article29/item - detail.cfm?item_id=611236 DPIA on Google Cloud Platform public version 11 June 2026 Page 15 of 142 • Use of any (Google Gemini) generative AI services as add - ons to the tested services, or as separate services. • Use of advanced technical support . • Use of Training Services. • Use of additional security logging and monitoring services . • S ingle Sign - On .

Methodology This DPIA is based on different sources of information and fact - finding strategies. Privacy Company has carefully studied all available public documentation from Google about the tested Google Cloud S ervices, including information about the different log files . To better understand the data processing in log files by Google, a Privacy Company employee has performed 7 scenarios , has intercepted outgoing data traffic to capture telemetry events, and has accessed the relevant available log files from the different Admin Console s . In addition, a Data Subject Access Request was filed with Google to obtain the Diagnostic data relating to the behaviour of the test admin. The technical findings are documented in detail in a separate Technical Appendix . Chronology This DPIA was conducted between August 20 24 and June 202 6 . On 14 and 15 August 2024, Privacy Company first tested the Google Cloud Services in a Dutch government tenant managed by Privacy Company.

Later, Privacy Company learned from Google many logs were only available if they were exported to BigQuery . Therefore, Privacy Company performed a retest on 29 and 30 October 2024, with all relevant logs enabled for export to BigQuery . After the first test round , the test admin from Privacy Company filed a DSAR for all personal data relating to his activities recorded by Google via the Data Access R equest Form . Google confirmed receipt the same day. The outcomes of the DSAR are discussed in Section 3.3 of this DPIA. In September 2025, th e outcomes of the dialogue with Google about mitigating measures were added as grey - coloured boxes in Part A with the commitments from Google, or the refusal to take a requested measure . The mitigating measures were also taken into account in the assessment in parts B, C and D. On 23 October 2025, Google provided comments on the completed DPIA and Technical Appendix.

Google provided some references to new information not previously available, for example related to encryption. Privacy Company analysed the new information, and upd ated the information in the DPIA. Google also asked to remove company confidential information. Privacy Company replaced all information that was disclosed confidentially by the words [CONFIDENTIAL]. Google proposed to rewrite many sentences in track chang es, adding extra conditions or limitations. Since Privacy Company is the author of this DPIA, and not Google, suggestions for rewriting were not copied, unless it was a grammatical improvement. Google also commented once it could not find a source for a quote. It turns out Google had replaced a quote from a public information source by a new text, and Privacy Company updated the quote. The majority of comments from Google was identical: Google disagrees with the legal analysis of authorised further processing.

Instead, Google qualifies itself as an independent data controller. Privacy Company incorporated these comments by DPIA on Google Cloud Platform public version 11 June 2026 adding a reference to a footnote every time Google asked to take formal note of its objection and added a new explanation about the necessity of the construction of authorised further processing in Section 6. 3, to prevent new high data protection risks. Mid November 2025 SLM shared a near - final version of the DPIA with Google in which all comments were processed. In December 2025 Google informed SLM Rijk about the publication of the information about the Telemetry Data. After verification and clarificatio n, this publication helped mitigated the single remaining medium risk. On 21 May 2026 SLM shared the draft public version of the Technical Appendix and the DPIA . On 1 June 2026 Google provided input on company confidentiality of the draft public version.

Outline of this DPIA F ollow ing the structure of the Dutch central government model DPIA, this DPIA report uses a structure of four main divisions, which are reflected here as “parts”. A. Description of the factual data processing B. Assessment of the lawfulness of the data processing C. Assessment of the risks for data subjects D. Description of mitigation measures Part A explains the data processing by Google and by governmen t organisations resulting from the use of a Compute Engine , Cloud SQL (MySQL), Cloud Storage , BigQuery and the Admin Console . Part A starts with a description of the main categories of personal data processed by Google , and an analysis of the standard contractual terms, compared with possible improvements that can be copied from the negotiated enrolment framework for Google Workspace for the Dutch government . S ection 2 describes the tested services, and the contents of the different log file s generated by Google .

This starts with a description of the way the data are collected and processed and describes the categories of personal data and data subjects that may be affected by the processing, the purposes of the data processing, the different roles of the parties, the different interests related to this processing, the locations where the data are stored , compliance with ePrivacy rules, and the retention periods. In this Section , factual contributions and intentions from Google are included. Part B provides an assessment by Privacy Company , with input from Google, of the lawfulness of th e tested GCP data processing . This part assesses conformity with the key principles of data processing, including transparency, data minimisation, purpose limitation, and the legal ground (s) for the processing, as well as the necessity and proportionality of the processing. T his s ection ends with an analysis how the rights of the data subjects are respected.

Part C assesses the risks to the rights and freedoms of the data subjects created by the processing activities identified in Part A of this DPIA . It identifies specific risks that may result from th e data processing by determining (1) the likeli hood that such a risk may occur, and (2) the severity of the impact on the rights and freedoms of the data subjects if the risk occur s . DPIA on Google Cloud Platform public version 11 June 2026 Page 17 of 142 Finally, Part D contains concrete measures that can be taken by either Google or the individual government organisations to mitigate the risks identified in Part C . These measures might either reduce the chance the risks occur , or the impact they might have, or both . Part D also contains an assessment of any residual risk (s) that cannot or will not be mitigated by applying the suggested measures . DPIA on Google Cloud Platform public version 11 June 2026 Part A. Description of the D ata P rocessing This first part of the DPIA provides a description of the characteristics of the personal data that can be generated and processed if a government organization uses a VM with a database in Google’s public cloud .

Specifically, the use of a Compute Engine (VM) , Google SQL database ( MySQL ) , a Cloud Storage bucket and Google’s BigQuery database service. This DPIA also addresses the personal data collected about admin activity in the cloud services, including data collected through use of the Admin Console. Part A continues with a description of the different categories of personal data that may be processed, the categories of data subjects that may be affected by the processing, the purposes of the data processing by Google , the locations where data may be stored, processed and analysed, and the role s of the government organisations , and of Google , as processor or as (joint) data controller s . Finally, this Section provides an overview of the different interests related to the processing, and of the retention periods. 1. Description of the tested Google Cloud Services Google offers many different services under the name Google Cloud Platform (GCP) . 7 This Section describes the four different GCP - services tested for this DPIA .

Figure 1 : Test set - up for this DPIA 7 The complete list is available at URL: https://cloud.google.com/terms/services . DPIA on Google Cloud Platform public version 11 June 2026 Page 19 of 142 1. Compute Engine ( V M) - Configured with webserver software and NextCloud, syncing with the Cloud Storage bucket with the help of Cloud Storage FUSE (File System User Space)). 8 2. Google SQL database instance (MySQL) . 3. Cloud Storage bucket . 4. BigQuery database to process large datasets . BigQuery was also used to store the exported audit logs . The data processing by these four services is described in more detail below, in Sections 1.1 to 1.4 . The data collected about the activity of admins using and managing these services is described in Section 3.3 , about the results of the technical investigation. 1.1 Compute Engine (VM) The starting point for the testing was the creation of a Compute Engine (Virtual Machine) in Google’s public cloud .

Privacy Company deployed a basic (non - GCP) web application (NextCloud) on the VM, that relied on the other tested services for a backend. A VM is an emulation or virtual representation of a computer system that provides the functionality of a physical computer (also known as bare metal server ). One physical cloud server can host many virtual machines, with different operating systems and applications. The different VMs are sandboxed , isolated from each other, and prevented from interfering with the physical computer. Customers can also choose a virtual private cloud (isolated from the GCP public cloud) called Virtual Private Cloud. 9 Google’s Compute Engine is a n Infrastructure as a Service (IaaS) offering, which provides scalable computing capacity using server instances in Google ’ s global data centres. The location of the VM was set to be in NL, by choosing Europe - west4 during set - up.

See Section 8 about the geolocation choices available for customers. Since VMs are usually used as web server, Privacy Company installed Debian 6.1.112 - 1 with Apache and ModPHP (free and open source software) as webserver software on the VM, and NextCloud on top of the web server. 8 Google asked to clarify that webserver means ‘government deployed webserver as installed by Privacy Company’ t hroughout the report. This is self - evident from the scope of this DPIA. Adding this explanatory line every time this DPIA mentions the word webserver, would decrease the readability of this report. 9 This service is out of scope of this DPIA. For more information, see: https://cloud.google.com/vpc DPIA on Google Cloud Platform public version 11 June 2026 Figure 2 : Admin dashboard with available resources for test project in the test tenant 1.2 Cloud SQL with MySQL database Cloud SQL offers a fully managed relational database service for PostgreSQL, MySQL, and SQL Servers.

Privacy Company chose MySQL. MySQL is an open source relational database. Open source databases are databases in which the underlying code can be freely viewed, downloaded, modified and re - used. Modifying the source code enables users to adjust it to match their preferences. Therefore , open source databases are more flexible and offer more freedom than traditional license models of closed source databases. Managing an open source database takes a lot of time. GCP offers preconfigured Relational Database Services to reduce time by automating the administration tasks of databases such as a MySQL database. This makes it easier for system administrators to set u p, operate, scale, patch and backup relational databases in the cloud. Google automates back - ups, replication, patches, encryption and on demand storage capacity increases. 10 The system administrator configures the access and authorisation policy and controls monitoring/logging.

In the test scenario a user account was created in NextCloud and stored in the MySQL database, including the authentication data. 1.3 Cloud Storage The third tested service, Cloud Storage , is a managed service to store unstructured data . 11 Privacy Company used this service as a local filesystem, and uploaded files in different formats, as images, CSV, txt, and markdown . 12 10 Cloud SQL , undated, URL: https://cloud.google.com/sql (page last visited 27 January 2025). 11 Cloud Storage , Object storage for companies of all sizes, undated, URL: https://cloud.google.com/storage (page last visited 27 January 2025). 12 Text with few lay - out rules. DPIA on Google Cloud Platform public version 11 June 2026 Page 21 of 142 In the VM, Privacy Company enabled sync with the Cloud Storage bucket, with the help of Cloud Storage FUSE (File System User Space). Google’s version of FUSE enables customers to mount Cloud Storage to the local filesystem. 13 From the perspective of the operating system the storage looks like any other local directory.

This means that NextCloud does not need to contain specific functionality to connect to Cloud Storage . Privacy Company tested what data Google collects if an external visitor visits a government website hosted on a VM in the Google Cloud. 1.4 BigQuery The fourth tested service is BigQuery , Google ’s data analytics platform . This service is a database service with which users can process large, structured datasets. 14 Different from more conventional database management systems like MySQL, customers don’t procure a single database on a single machine. Instead, BigQuery takes scaling concerns away from the customer, and enables data analysis on very large datasets. In t he test set - up from Privacy Company, BigQuery was used to query for specific (fictive) complaints from citizens. Google advised Privacy Company in September 2024 to use BigQuery, since many logs were only available if they were exported .

In reply to this sentence , Google later added that customers can also export logs to cloud storage and process it manually, or export to a third party SIEM solution. Privacy Company did not test these alternative options 2. Legal : personal data and enrolment framework The Dutch government DPIA model requires that this Section provides a list of the categories of personal data that will be processed, and per category of data subjects, what personal data will be processed by the product or service for which the DPIA is conducted. However, s ince this is an umbrella DPIA, only general descriptions can be provided of the categories of personal data and data subjects , in Sections 2.4 and 2.5 respectively . Section 3 describes t he specific personal data that Google processes via GCP , with a summary of the technical findings. This Section starts with an explanation of the legal definitions, followed by an explanation of the different categories of personal data processed by Google when a government organisation decides to use the tested GCP - services .

Section 2.3 describes the enrolment framework, based on the Google Cloud Master Agreement signed by the Dutch government for Google Workspace. In general, when analysing the data processing by a cloud provider, three main categories of data flows can be distinguished: 1. Content Data stored on the cloud provider’s servers, often called ‘Content’, ‘Customer Content’ or ‘Customer Data’. In this case: Content Data stored by the government organisation on the VM and in the databases. 2. Diagnostic Data . All data generated or collected by the cloud provider about the use of the public cloud services, including visits to its public website to look - up for example relevant help documentation and privacy policies, and the (restricted access) websites requiri ng log - in by an administrator. The 13 Cloud Storage , Cloud Storage FUSE, undated, URL: https://cloud.google.com/storage/docs/cloud - storage - fuse/overview (page last visited 27 January 2025). 14 Google Cloud BigQuery, From data warehouse to a unified, AI - ready data platform, undated, URL: https://cloud.google.com/bigquery (page last visited 27 January 2025).

DPIA on Google Cloud Platform public version 11 June 2026 term Diagnostic Data used in this DPIA as an overarching term for all metadata, and also includes the subcategory ‘Telemetry Data’. 3. Functional Data , data that are temporarily processed by the cloud provider to execute desired functionalities. The key difference between Functional Data and Diagnostic Data as defined in this report is that functional data are and should be transient. 15 This means that these data should be immediately deleted or anonymised upon completion of the transmission of the communication. Otherwise, they qualify as Content Data or Diagnostic Data. As long as the cloud provider does not store these Functional Data, they are not Diagnostic Data. Figure 3 : Content Data, Functional Data and Diagnostic Data Content Data Functional Data Diagnostic Data This DPIA is focussed on the data protection risks of the processing of Diagnostic Data, but also addresses the risks of transfer of personal data in Content, Account, Support and (restricted access) Website Data to the USA and third countries, and mitigat ing measures such as pseudonymisation and encryption. 15 Compare Article 6(1) of the EU ePrivacy Directive (2002/58/EC, as revised in 2009 by the Citizens Rights Directive) and explanation in recital 22: “ The prohibition of storage of communications and the related traffic data by persons other than the end users or without their consent is not intended to prohibit any automatic, intermediate and transient storage of this information in so far as this takes place for the sole purpose of carrying out the transmission in the electronic communications network and provided that the information is not stored for any period longer than is necessary for the transmission and for traffic management purposes , and that during the period of storage the confidentiality remains guaranteed. ” DPIA on Google Cloud Platform public version 11 June 2026 Page 23 of 142 2.1 Definition of personal data According to article 4(1) (a) GDPR, “‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a nam e, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”

The concept of processing is defined in Article 4(2) of the GDPR: “ ’processing' means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval , consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction. ” The GDPR explains that pseudonymised data are personal data, to which the GDPR applies. Recital 26 explains: “ Pseudonymised personal data that can be linked to a natural person through the use of additional data should be regarded as data relating to an identifiable natural person. In order to determine whether a natural person is identifiable, account must be taken of all means that can reasonably be e xpected to be used by the controller or by another person to directly or indirectly identify the natural person, for example selection techniques.

In determining whether any means can reasonably be expected to be used to identify the natural person, accoun t shall be taken of all objective factors, such as the cost and time of identification, taking into account available technology at the time of processing and technological developments. ” In its recent guidance on pseudonymisation the EDPB explains that “ the desired effect of pseudonymisation is to control the attribution of personal data to specific data subjects by denying this ability to some persons or parties. ” 16 The EDPB emphasises th at pseudonymous data are still personal data , and processing needs to comply with the GDPR. The EDP B takes an absolute stance with regard to identifiability when it states : [Pseudonymous data are personal data , addition Privacy Company ] “ This statement also holds true if pseudonymised data and additional information are not in the hands of the same person.

If pseudonymised data and additional information could be combined having regard to the means reasonably likely to be used by the contr oller or by another person , then the pseudonymised data is personal. Even if all additional information retained by the pseudonymising controller has been erased, the pseudonymised data becomes anonymous only if the conditions for anonymity are met. ” 17 16 EDPB, Guidelines 01/2025 on Pseudonymisation, 17 January 2025, consultation version, par. 4 , URL: https://www.edpb.europa.eu/system/files/2025 - 01/edpb_guidelines_202501_pseudonymisation_en.pdf 17 Idem , par. 2 2 . DPIA on Google Cloud Platform public version 11 June 2026 2.2 Five categories of personal data In order to provide a precise analysis of the different types of personal data processing and their impact, this DPIA distinguishes between five categories of personal data that Google can process as a result of the use of the tested set - up. • Content Data (called Customer Data by Google) • Account Data (called Service Data by Google) • Diagnostic Data (called Service Data by Google) • Support Data (called Service Data by Google) • Website Data (called Service Data by Google, in two types: o the restricted access websites, i.e. the Admin Console, and o the publicly available Google Cloud Platform pages that were linked from the Admin Console during testing. 18 Figure 4 : Five different categories of personal data Google itself only distinguishes between two types of personal data in the relevant legal documents: Customer (Personal) Data and Service Data (including Account, Diagnostic, Support and Website Data). 18 According to Google, public Google webpages should be out of scope of this DPIA because the agreement with the Dutch government doesn’t apply.

Privacy Company disagrees, since visits to public pages maybe necessary for admins to look up (technical or lega l) informati on to perform their work tasks. Restricted Access Website Data Public Website Data Contact Data: Procurement Support Data Content Data Diagnostic Data inc. security logs Google Cloud Admin Console Google Account Data DPIA on Google Cloud Platform public version 11 June 2026 Page 25 of 142 Google defines the term Customer Personal Data in its public data processing agreement for cloud services 19 as: ““Customer Personal Data” means the personal data contained within the Customer Data, including any special categories of personal data or sensitive data defined under Applicable Privacy Law. ” Google's category of Customer Data does not include the Account Data and contents of Support Requests, even though these personal data are provided by customers themselves. Google includes these two categories of personal data in the broad category of Serv ice Data.

See Figure 5 below. Figure 5 : Google description of Service Data 20 This DPIA does not follow Google’s division in these two categories of personal data , because there are differences in both the impact and the probability of unauthorised access to the different kinds of personal data. The distinction in five categories of personal data also make this DPIA more comparable with other public DPIAs for the Dut ch government on public cloud services. 2.2.1 Content Data Content data are the personal and non - personal data uploaded by customers to a Cloud Storage bucket, Google SQL database or Compute Engine (VM) in the Google Cloud . Content Data do not include the Account Data, and may also include non - personal data. Google may collect Content Data in for example screenshots if an admin reports a bug by sending Feedback to Google. However, Google explained that these data do not qualify as Content Data , but as Service Data for Google.

This specific processing is analysed in Section 3.1 below. To test the processing of possibly sensitive Content Data, Privacy Company created a note with fictive medical information, a photo of a user, and a csv file with a random 19 Google Cloud Data Processing Addendum (Customers), Last modified 15 October 2024, URL: https://cloud.google.com/terms/data - processing - addendum . 20 Screenshot from Google Cloud Privacy Notice, effective date 10 July 2024, URL: https://cloud.google.com/terms/cloud - privacy - notice?hl=en . DPIA on Google Cloud Platform public version 11 June 2026 combination of 71.498 (fictional) complaints from (fictional) citizens related to the public space , with names and generated telephone numbers. See the Technical Appendix for the details. This DPIA cannot provide a description of all possible kinds of Content Data that government organisations may process with the tested services on GCP , as this depends entirely on the nature and data processing purpose s of the organisations.

To help government organisations perform their own DPIA, Section 0 below contains a description of categories of personal data whose processing has a different impact on data subjects, and are therefore relevant for the risk assessment. Section 2.5 below similarly provides a high - over description of the different kind of natural persons involved by the data processing, the data subjects. 2.2.2 Account Data Account data primarily are account information about admins . Google defines the Admin Account in the Google C loud Master Agreement (CMA) with the Dutch government as: “ a type of End User Account that Customer (or Reseller, if applicable) may use to administer the Services. ” 21 As explained in the public DTIA on Google Meet for SLM Rijk , Google considers Account Data to be part of Service Data. 22 Google explains what Account information is: “ We collect the data you or your organization provide when creating an account for Cloud Services or entering into a contract with us (username, names, contact details and job titles). ” 23 The details of account creation are described in Section 3.1 below.

Google also processes a second category of Account Data: of commercial sales contacts that procure the licenses for an organisation ( C ommercial C ontact D ata). Google explains in the Google Cloud Privacy Notice that the term Account Data covers both the creation of an account for Cloud Services and data obtained when a customer enters into a contract with Google. It is possible (as in the test set - up by Privacy Company) that an admin and contract owner are identical, but with larger government organisations, the roles are likely assigned to different employees. Google does not define Commercial Contact Data in the CMA , nor does it distinguish between these roles i n its Cloud Privacy Notice . 2.2.3 Diagnostic Data Diagnostic D ata are the metadata that Google collects and stores about the behaviour of system administrators and performance of the VM and databases. This includes service generated server logs with personal data, Telemetry Data and Google’s own security logs .

The technical details are described in Section 3.3 below. 2.2.4 Support Data Support data are out of scope of this DPIA . If organisations want to file specific support requests with Google, they have to procure a separate support plan, ranging from 21 Confidential Google CMA with the Dutch government. 22 Google Cloud Privacy Notice, Effective Date: 10 July 2024, URL: https://cloud.google.com/terms/cloud - privacy - notice?hl=en 23 Idem. DPIA on Google Cloud Platform public version 11 June 2026 Page 27 of 142 Standard to Premium Support. 24 Only basic and billing support are included with the Google Cloud Services, but the basic support is limited to receiving automatic Services upgrades and Maintenance updates, support for billing inquiries. The rest of the support is Do It Yourself, by reading public documentation, white papers, online best practices guides, and participation in community forums such as Stack Exchange, Stack Overflow, Server Fault, news groups and the Google Cloud Community. 25 The category of Support Data is nonetheless included in this report to remind government organisations that they must include a risk assessment of the processing of these data when they procure support services from Google. 2.2.5 Website Data This report identifies two categories of Website Data : 1.

Restricted access Website Data (Admin C onsole) 2. Publicly accessible Google W ebsite Data Both categories of Website D ata include data collected by cookies , pixels , URL parameters and other similar technologies to read information from the end user browser . Technically, as described above, Website Data are a form of metadata on the behaviour of system administrators, and therefore part of the broad category of Diagnostic Data. However, for analytical clarity, and because of differences in inspection methods, this report separately analyses the data recorded through the use of the Google - website s . 2.3 Enrolment framework Google provides a useful overview of the standard enrolment framework for the Google Cloud Platform. 24 Google Cloud, Getting support with Cloud Customer Care, undated, URL: https://cloud.google.com/support/docs 25 Google Cloud Community, URL: https://www.googlecloudcommunity.com/gc/Google - Cloud/ct - p/google - cloud .

See also the General Support Service Terms, art. 2, URL: https://cloud.google.com/terms/tssg DPIA on Google Cloud Platform public version 11 June 2026 Figure 6 : Google overview of enrolment framework 26 Additionally , Google lists other relevant information sources (th e selection in this screenshot relevant for Dutch government customers). Figure 7 : Screenshot of additional GCP resources 27 In March 2022 SLM Rijk signed an improved agreement with Google for the use of Google Workspace Enterprise, but the agreement can be expanded to the use of Google Cloud Services. This analysis assumes that Google and the Dutch government will agree to apply similar amended conditions to the use of Google Cloud Services , most importantly, the inclusion of the commitment to become a processor of Service 26 Screenshot taken 2 7 January 2025 from Google Cloud Terms Directory, URL: https://cloud.google.com/product - terms 27 Idem.

DPIA on Google Cloud Platform public version 11 June 2026 Page 29 of 142 Data processed as processor and the application of Google's Cloud Data Processing Addendum to both Customer Personal Data and Service Data processed as processor. Google confirmed it is willing to adopt a processor role for Processor Service Data in accordance with the processing instructions (same as agreed for Workspace), and when acting as a controller, process Service Data only for the Legitimate Business Purposes for GCP . 28 The (renewed version of the) Google Cloud Master Agreement that will include GCP - specific contract terms (CMA incl. GCP ) with the Dutch government identifies two types of personal data: Customer (personal) Data and Processor Service Data. The CMA incl. GCP includes a list of legitimate business purposes for which Google may further process the (generally aggregated) personal data. See Section 6 for a detailed description of the roles of Google.

The CMA inc. GCP also includes limitative lists of agreed processing purposes. See Section 5 of this DPIA. 29 The (renewed version of the) CMA incl. GCP amend s Google’s public ly available versions of the Google Cloud Data Processing Addendum , 30 and includes GCP - specific contract terms . SLM must ensure that the (renewed) CMA prevails over other relevant parts of the enrolment framework, including both Cloud Specific and General Terms, as well as URL Terms . Google publishes Cloud Terms of Service page with a total of 6 . 674 different specific services that a customer may use, and per service, what terms of service apply, and if the a d min has accepted those terms . For the tested services, th e applicable terms were always the Google Cloud Platform Terms of Service , and an o ffline version as signed by SLM will be part of the CMA with the Dutch government . 31 When Google is contractually permitted to ‘further’ process some personal data as data controller in the CMA, 32 the Google Cloud Privacy Notice applies to the further processing of the Service Data, except for purpose limitations specifically mentioned in the CMA. 33 The Google Cloud Privacy Notice contains a separate paragraph about the Google Account.

“Your Google Account is your connection to all Google products and services, not just Cloud Services. When you choose to use Google products and services outside of Cloud Services, the Google Privacy Policy describes how your personal information (includin g your Google Account profile information) is collected and used. You and your administrator can control which other Google services you may use while logged into a Google Account managed by your organization. ” 34 When Google is not a processor, nor contractually permitted to ‘further’ process some personal data as data controller in the CMA (Account, Diagnostic, Support and 28 Google reply to questions SLM , 21 March 2025. 29 Google disagrees with the qualification of further processing. According to Google there is no other 'initial' processing of Service Data. Google considers itself an independent data controller for these data. .

Google reply to the DPIA, 23 October 2025 . 30 Google Cloud, Cloud Data Processing Addendum (Customers), last modified 15 October 2024, URL: https://cloud.google.com/terms/data - processing - addendum 31 Google Cloud Platform Terms of Service, last modified 17 October 2024. 32 See footnote 29 . 33 Google Cloud Privacy Notice, Effective Date: 6 February 2025 , URL: https://cloud.google.com/terms/cloud - privacy - notice?hl=en . 34 Idem. DPIA on Google Cloud Platform public version 11 June 2026 restricted access Website Data, 35 but not the Content Data), the rules from Google’s Privacy Policy apply. 36 According to this framework, Google is an independent data controller for the public website data, for the commercial contact data (of procurement officers), and for the creation of a Google account (to start using a Google cloud service). Figure 8 : Overview of Google Cloud (speci fic) Terms of service 37 In sum, the enrolment framework consists of two pillars , with different applicable contractual commitments for the personal data processing, depending on Google ’s role as a data processor or as a data controller . 2.4 Categories of personal data processed in and with GCP This section provides a general description of the types of personal data that can be processed with the tested services on GCP, distinguished by the impact of potential unlawful processing on data subjects (confidential, sensitive and special categories o f data).

As shown in Figure 9 below, there are no hard lines between the categories. Depending on the context, the same data may be regular, sensitive or special categories of data. 35 See footnote 29 . 36 Google Privacy Policy, Effective 16 September 2024, URL: https://policies.google.com/privacy?hl=en - US/ 37 Google Cloud Terms of Service, URL: https://console.cloud.google.com/terms?pli=1&inv=1&invt=Abnxtg . Screenshot made 25 January 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 31 of 142 Figure 9 : Categories of personal data and their impact 2.4.1 Classified information The Dutch government defines 4 classes of Classified Information, ranging from confidential within the ministry to extra secret state secret. 38 Dutch government employees will, depending on the capacity in which they work, often process Classified Information. Classified Information is not a separate category of data in the GDPR or other personal data legislation.

Nonetheless, information processed by the government that is qualified as classified information, whether it qualifies as personal data or not, must l egally be protected by special safeguards. The processing of this information can also have a privacy impact when it is related to an individual. If the personal data of an employee, such as unique user (account) ID, or unique device identifier, can be con nected to the information that this person works with Classified Information, the impact on the private life of this employee may be higher than if that person would only process ‘regular’ personal data. Unauthorised use of this information could for examp le lead to a higher risk of being targeted for social engineering, spear phishing and/or blackmailing. In reply to this observation, Google replied [CONFIDENTIAL] . Based on the enrolment framework with the Dutch government, Google is not allowed to combine personal data sets in the GCP - context to create profiles of people working with classified information. 2.4.2 Personal data of sensitive nature Some types of ‘normal’ personal data have to be processed with extra care, due to their sensitive nature.

Examples of such sensitive data are the contents of communication, web surfing behaviour, financial data, traffic and location data, but also, authent ication details of admins that may provide access to large datasets with such sensitive data. The sensitivity of the data is related to the level of risk for the data subjects in case the confidentiality of their data is breached. Risks may vary from spear - phishing admins, to capturing IP addresses of website visitors hosted on a VM if their IP 38 Defined in: Besluit Voorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie 2013 (VIRBI 2013). DPIA on Google Cloud Platform public version 11 June 2026 addresses should remain utterly confidential, such whistleblowing at “meldmisdaadanoniem.nl”. 2.4.3 Special categories of personal data Based on the GDPR, the processing of special categories of personal data is prohibited, unless one of the exceptions applies from the limitative list included in the GDPR.

According to Article 9 (1) GDPR, personal information falling into special categories of data are any: “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concernin g health or data concerning a natural person's sex life or sexual orientation”. With special categories of data, the principle is one of prohibition: special data may not be processed. There are exceptions to this rule, however, for instance when the data subject has explicitly consented to the processing, or when data have been made manifestly public by the data subject, or when processing is necessary for the data controller to exercise legal claims. It is possible to process any special categories of personal data with the tested services on GCP. 2.5 Possible categories of data subjects This umbrella DPIA can only indicate categories of data subjects that may be involved in the processing but cannot assess the specific risks of the actual data processing per organisation that uses or will use the Google cloud services .

As described in Sectio n 2.2.1 of this report, e ach government organisation determine s itself what personal Content D ata it wants to store in a storage bucket or database on a cloud server , relating to what natural persons. S uch buckets and databases may include lists of Customer’s customers, patients, clients, employees, suppliers and/or end - users. Specific types of data subjects are included in the Account and Diagnostic Data : the admins and commercial procurement officers of a government organisation. The government organisation must keep an overview of the different categories of data subjects in its data processing inventory ( Article 30 GDPR) , and must list t hese categories of data subjects in the Standard Contractual Clauses, when such clauses apply to the transfer of personal data to a third country . In the SCC from the European Commission , the Annex contain s a separate list of the category or categories of data subjects. 39 P ossible types of data subjects are : • Employees, contractors and temporary workers (current, former, prospective) of data exporter; • Dependents of the above; 39 European Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council, URL: https://eur - lex.europa.eu/legal - content/EN/TXT/HTML/?uri=CELEX:32021D0914&from=EN .

DPIA on Google Cloud Platform public version 11 June 2026 Page 33 of 142 • Data exporter's collaborators/contact persons (natural persons) or employees, contractors or temporary workers of legal entity collaborators/contact persons (current, prospective, former); • External persons (e.g., customers, citizens, clients, patients, visitors, etc.) and other data subjects that are users of data exporter's services; • Partners, stakeholders or individuals who actively collaborate, communicate or otherwise interact with employees of the data exporter and/or use communication tools such as apps and websites provided by the data exporter; • Stakeholders or individuals who passively interact with data exporter (e.g., because they are the subject of an investigation, research or mentioned in documents or correspondence from or to the data exporter); • Minors; or • Professionals with professional privilege (e.g., doctors, lawyers, notaries, religious workers, etc.). 3.

Results technical investigation In order to better understand the data processing in log files by Google , a Privacy Company employee has performed 7 test scenarios and has subsequently accessed the available log file s in the (web) Admin Console. In addition, a D ata S ubject A ccess R equest (DSAR) was filed with Google to obtain the Diagnostic data relating to the activities of the test admin. The results of the DS A R are discussed in Section 3.6 of this report. T his Section explains in detail what Diagnostic Data were observed in the technical inspection of the data, and why some of these stored Diagnostic Data on the use of the tested Google services are personal data as defined in article 4(1) of the General Data Protection Regulation (GDPR). 3.1 Content Data During testing Privacy Company observed two types of services through which Google can collect additional Content Data from customers a n announcement about the option to purchase Google’s AI service Gemini that could lead to processing of Content Data in a new way if an admin decides to accept Google’s offer to use Gemini for free , and a Feedback button. 3.1.1 Gemini generative AI As shown in Figure 10 below, Google showed an annou ncement in the Admin Console about the pricing of its generative AI - service Gemini in BigQuery .

It follows from the announcement that Google had enabled Gemini by default, without any request or order from the admin. Privacy Company referred to this banner as advertisement, because it encourages the admin to start using this new service for free, before having to pay for it. 40 Figure 10 : Google Gemini price announcement On 12 December 2024 Google responded with the following explanation: 40 In reply to this DPIA Google stated it no longer displa ys this specific banner to users. Google reply to this DPIA, 23 October 2025 . DPIA on Google Cloud Platform public version 11 June 2026 “ The referenced banner is neither an "advertisement" or a "recommendation". Instead, it provides a notice function because the pricing enforcement will be enabled on the specified date. For example, if feature X is currently available to everyone, but will no longer be free after date X, we have to warn users of the impending change.

If a user had already disabled the feature, they would not see the warning, i.e., the warning is only intended for users who still have the feature on. Further, the admin doesn't have central control of this notice function.” Privacy Company was unable to find a switch in the admin console to disable default enabling of new unprocured services that can process Content Data in a new way. Mitigating measure Google • Google has confirmed it will not develop an option for admins to disable such banners. Google states that customers can disable access to services or features that Google makes available for free. 41 3.1.2 Feedback Data Admins can voluntarily provide Feedback to Google through a link in the top bar of the Admin Console. During the limited testing, Privacy Company did not see an active request from Google for Feedback. The fact that Privacy Company did not observe an active request does not mean Google would not show such a request , or send a survey (as observed during testing of Google Workspace Enterprise 42 ) .

Privacy Company did not find a setting in the admin console to centrally disable access to Feedback Data. When asked, Google explained it will not develop such an option. “ Any perceived concern about feedback data can be controlled on the customer side; the customer can implement an organisational policy that requires users not to provide feedback to Google. ” 43 41 Idem. According to Google, c ustomers can enable/disable GCP services at their discretion as explained in public documentation, URL: https://cloud.google.com/service - usage/docs/enable - disable . 42 SLM Rijk , New findings verification review Google Workspace Enterprise , 15 May 2024, p. 3. 43 Google reply to questions SLM , 21 March 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 35 of 142 Figure 11 : Presence of Feedback button in Google Cloud console If the admin clicks on the question mark, Google shows a warning not to include ‘any sensitive information’, with a description of sensitive information , namely: “ passwords, credit card numbers and personal details .”

Figure 12 : Google warning about sensitive information In the ‘Feedback’ form, the admin is invited by default to send a screenshot to Google, but he/she can also send free text. In the text box, Google mentions that it can use the data to improve the services, and refers to its (consumer) Privacy Policy. DPIA on Google Cloud Platform public version 11 June 2026 The form also mentions that Google may also collect ‘some account and system information’ . If clicked, a sidebar appears that shows information about the URL of the user when submitting the Feedback. There is also a category called ‘experiments’. This category also appears in Telemetry Events, and will be discussed in Section 3.3.3 below. In reply to this report, Google explained [ CONFIDENTIAL ] . Mitigating measure Google • Google has confirmed it will not develop an option for admins to centrally block the option to provide Feedback.

According to Google customers can apply an organisational measure, that is, warning admins not to provide Feedback to Google . 3.2 Account Data In its public explanations about GCP, Google explains on its get - started page that users that want to start using Google Cloud services first have to create a Google account. Figure 13 : Google get started with Google Cloud 44 If the user doesn’t already have a Google account, Google asks the user to create a new (consumer) Google account. Figure 14 : Google log in or create new account screen 44 Google Cloud, Get started with Google Cloud, undated, URL: https://cloud.google.com/docs/get - started (page last visited 27 January 2025). DPIA on Google Cloud Platform public version 11 June 2026 Page 37 of 142 During the creation of this Google account, Google collects the following data: • First name • Last name (optional) • Date of birth • Gender • Phone number • E - mail address (on the domain of the employer) During the creation of this account, Google refer red with hyperlinks in each screen to its (consumer) Privacy Notice and General Terms.

As shown in Figure 15 below, Google asks for the date of birth and gender of the admin when creating a Google Account . In the hyperlinked text, Google explains: “ Some Google services have age requirements. (…) Besides making sure you’re old enough to use certain services and features, Google uses your birthday to: • Determine your age group to offer you a more personalized experience, including personalized recommendations and ads. You can turn off personalized ads. • Know when to show a birthday theme on the Google Search page. • Account security and personalization across Google services. ” 45 Google also explains that it is not necessary to provide gender. “ You can: • Specify your gender • Choose not to specify your gender • Add a custom gender and choose how Google refers to you .” 46 Figure 15 : Google request for date of birth and gender Once the admin account has been created, Google informs the admin that they have to accept the Google Cloud Platform Terms of Service (the box has to be ticked), and 45 Google, Why Google asks for certain info to create an account, undated, URL: https://support.google.com/accounts/answer/1733224?hl=en 46 Idem DPIA on Google Cloud Platform public version 11 June 2026 offers the admin a choice to opt - in to a mailing list with both product updates and ‘special offers’.

Figure 16 : Creation of admin account for GCP completed In reply to a question from Privacy Company about the se two types of mailing lists, Google replied: " To clarify, the activities described beside the tick - box in the screenshot you shared are all marketing - related. As such, we are not combining important communications about the operation of the services with marketing communications into a single tick box . The admin can choose not to tick the box if they do not wish to receive the kinds of marketing - related communications described beside it. Otherwise, the admin has other, granular controls they can use to tailor the specific communications they wish to receive, in the user preference/ communication section of the Admin Console. " 47 I n reply to this description of the account creation , Google explained that government admins should follow a different (offline) path to create an admin account , not the onboarding process of ‘online’ customers who will accept the standard GCP Terms of Service.

Google explained: [CONFIDENTIAL] . 48 Customers can use their own existing e - mail accounts. Such Account Information will be part of the Service Data in the contract with the Dutch government. 49 47 Google reply to questions SLM , 21 March 2025. 48 Google response 18 July 2025 to complete DPIA draft of 16 May 2025. 49 Idem. DPIA on Google Cloud Platform public version 11 June 2026 Page 39 of 142 Privacy Company did not test this option or other log - in options. Mitigating measure Google • Google will offer contractual wording to SLM Rijk that confirms that “Account information” qualifies as Service Data that Google processes as an independent controller, subject to the agreed contractual arrangements (including the Legitimate Business Purposes) and the GCPN, and, for clarity, not subject to the general Google Privacy Policy. 3.3 Diagnostic Data Diagnostic data are the metadata that Google collects and stores about the behaviour and performance of system s and services , including data about the system’s use by administrators and potentially by end - users (visitors to a website potentially hosted on a VM) .

Google collects Diagnostic Data about the individual use of its cloud services by end - users such as system administrators in in three different ways: • collecting system - generated logs on its own GCP servers about the activities of the administrators, including sign - in logs; • collecting two types of Telemetry Data (Google Analytics and cloud logs) • collecting samples of network metadata . These sample s may include activities by admins and external visitors to a website hosted on the VM. Additionally, Google collects Diagnostic Data about visits to its public and restricted access websites. These Website Data are described separately in Section 3.4 below. Google collects many monitoring data that are not personal data, and hence, not part of the category of Diagnostic Data described in this DPIA. The Technical Appendix describes some examples of metrics about service usage and costs (billing data). 3.3.1 Admin ( User ) log events Google offers access to sign - in logs from the admin of the Google Cloud services in a different admin interface (for the Google Workspace admin) , not in the specific Google Cloud audit logs.

Figure 17 : Screenshot audit logs user access The contents of these logs are directly identifiable personal data. DPIA on Google Cloud Platform public version 11 June 2026 3.3.2 System - generated server logs Logs Explorer is the main interface for Google Cloud services to allow admins to interact with audit logs with user (admin) activity. Google distinguishes between 4 main categories of audit logs: • Admin Activity audit logs • Data Access audit logs • System Event audit logs • Policy Denied audit logs 50 Google explains: “ Google Cloud services write audit logs that record administrative activities and accesses within your Google Cloud resources. Audit logs help you answer "who did what, where, and when?" within your Google Cloud resources with the same level of transparency as in on - premises environments. Enabling audit logs helps your security, auditing, and compliance entities monitor Google Cloud data and systems for possible vulnerabilities or external data misuse. ” 51 Google provides the following descriptions of these four types of logs: “ Admin Activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources.

For example, these logs record when users create VM instances or change Identity and Access Management permissions.” (…) “ Data Access audit logs contain API calls that read the configuration or metadata of resources, as well as user - driven API calls that create, modify, or read user - provided resource data. ” (… ) “ System Event audit logs contain log entries for Google Cloud actions that modify the configuration of resources. System Event audit logs are generated by Google Cloud systems; they aren't driven by direct user action. ” (…) “ Policy Denied audit logs are recorded when a Google Cloud service denies access to a user or service account because of a security policy violation. ” 52 Google provides an overview of available audit logs for its different GCP Services. 53 T here is a long list of read and write actions that may result in log entries, divided in Admin Activity and Data Access types of logging. 54 As documented in the Technical Appendix , the Logs Explorer shows logs from several different re sources that Google makes available to admins by default. 50 Google Cloud, Cloud Audit Logs overview, URL: https://cloud.google.com/logging/docs/audit#types 51 Idem. 52 Google Cloud, Admin Activity audit logs, undated, URL: https://cloud.google.com/logging/docs/audit#admin - activity 53 Google Cloud, Google Cloud services with audit logs, undated, URL: https://cloud.google.com/logging/docs/audit/services 54 Google, Compute Engine audit logging, undated, URL: https://cloud.google.com/compute/docs/logging/audit - logging .

DPIA on Google Cloud Platform public version 11 June 2026 Page 41 of 142 • Google made the following logs available in the cloud console in the test set - up: BigQuery • BigQuery Dataset • Cloud SQL Database • BigQuery Project • BigQuery DTS Config • VM Instance • GCP Location • Audited Resource • GCS Bucket 55 The logs are exportable as structured JSON - data. In the test set - up, the GCP - services were briefly tested for 2 days. The export contained 1.762 log events. The logs show detailed user activity and Content Data, such as an identifiable test user accessing a specific complaints table in BigQuery, or when the admin created a new VM instance , or a storage bucket . Examples of identifying data and Content Data are highlighted in yellow in Figure 18 below. 56 Figure 18 : Example of BigQuery log with admin activity { "protoPayload": { "@type": "type.googleapis.com/google.cloud.audit.AuditLog", "status": {}, "authenticationInfo": { "principalEmail": "floor@cloud.ivpoz.nl" }, "requestMetadata": { "callerIp": "185.213.106.92", "callerSuppliedUserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:131.0) Gecko/20100101 Firefox/131.0,gzip(gfe),gzip(gfe)", "requestAttributes": {}, "destinationAttributes": {} }, "serviceName": "bigquery.googleapis.com", "methodName": "tabledataservice.list", "authorizationInfo": [ { "resource": "projects/river - wave - 425319 - m8/datasets/klachten/tables/klachten", "permission": "bigquery.tables.getData", "granted": true, "resourceAttributes": {} } ], 55 Google repeatedly asked for correction, to remove this list and instead repeat the scope of the DPIA here, with the 4 tested services.

In reply Privacy Company has added a screenshot to the Technical Appendix showing the available logs in these resources i n the test set - up. 56 Google objects against the term ‘Content Data’. For Google all logs are part of Service Data. As explained in Section 2.2 above, Privacy Company continues to distinguish between 5 categories of personal data. DPIA on Google Cloud Platform public version 11 June 2026 "resourceName": "projects/river - wave - 425319 - m8/datasets/klachten/tables/klachten/data", "serviceData": { "@type": "type.googleapis.com/google.cloud.bigquery.logging.v1.AuditData", "tableDataListRequest": { "maxResults": 50 } } }, "insertId": "jzsd1ce3oif8", "resource": { "type": "bigquery_resource", "labels": { "project_id": "river - wave - 425319 - m8" } }, "timestamp": "2024 - 10 - 30T14:19:10.775613Z", "severity": "INFO", "logName": "projects/river - wave - 425319 - m8/logs/cloudaudit.googleapis.com%2Fdata_access", "receiveTimestamp": "2024 - 10 - 30T14:19:11.735646318Z" } The audit logs also show specific interaction with the database.

Privacy Company intentionally misspelled the name of a column, and Google registered its own correction suggestion as follows: "query": "SELECT * FROM `klachten.klachten` WHERE klagerr = \ "Coen De Jong \ ";", "code": 3, "message": "Unrecognized name: klagerr; Did you mean klager? at [1:41]" The contents of these service specific audit logs are personal data, and may contain personal data relating to (external) natural persons whose data are processed as part of the Content Data. 3.3.3 Telemetry Data Privacy Company has observed Telemetry Data sent to two domains, separated into two categories: 1. Event s sent to region1. analytics.google.com 2. Events sent to cloud.google.com/log . Telemetry sent to Google Analytics During the tests on 29 and 30 October 2024 Privacy Company observed 33 telemetry events sent to region1.analytics.google.com from the Admin Console (console.cloud.google.com).

This traffic contain s URL - parameters , but because the traffic is intercepted from the browser, the traffic also includes the cookies set and read via https . DPIA on Google Cloud Platform public version 11 June 2026 Page 43 of 142 As explained in the Technical Appendix , t he meaning of the URL - parameters is mostly unknown, besides a few parameters where the meaning can be guessed from context, like the language, screen resolution and the name and type of telemetry event ( for example, ‘fetchingRowsStarted’ ) . Some of the events describe loading of a font, opening of a user interface panel or starting or resuming a VM. None of the events apparently contain the name or e - mail address of the admin, or the names of databases, files or the name of the VM. However, Privacy Company assesses that the collected Telemetry D ata can be linked to the data subject by the cookie - identifiers sent with the same https traffic , in particular the SID, HSID and NID cookie , also because the IP - address of the admin is automatically being sent with each request.

Telemetry sent to Google cloud logs The outgoing data traffic from the Admin Console to cloud.google.com contained 94 POST - requests. On average this means Google has programmed the client web app to send a few events per minute while Privacy Company actively engaged with the Admin Console. Absent public documentation from Google, Privacy Company was not able to understand the contents of the collected data or categorise the data into specific types of log events. Figure 19 below shows the contents of a telemetry event with many cookie s. Google does not provide a Diagnostic Information Tool for admins to observe the outgoing data. 57 In reply to questions about the absence of documentation and absence of a tool to make these personal data accessible to end users , Google initially replied: “ Taking into account: 1. The significantly lower number of GCP users in a typical customer organization compared to Workspace (e.g. dozens compared to potentially thousands); 2.

The disproportionate level of time and effort that would be required to develop a new DIT tool for GCP, as well as develop and maintain comprehensive documentation; and 3. The fact that the appropriate benchmark for GCP is the GDPR itself (not the commitments given in the Workspace DPIA), and the GDPR does not mandate creation of specific tooling; we are not legally required and will not be able to commit to offer DIT for GCP, or to publish documentation dedicated to telemetry data on our website. We have carefully considered our obligations under the GDPR, primarily Articles 15 (for Service Data processed according to the LBPs) and 28(3)(e) (for Processor Service Data processed according to customer instructions). 57 Google does provide a Diagnostic Information Tool to users of Google Workspace Enterprise, as documented in the public Updated verification report data processing Google Workspace Enterprise for SLM Rijk .

DPIA on Google Cloud Platform public version 11 June 2026 With this in mind, we can commit that: 1. To comply with Article 15, we will provide a user with telemetry data relating to them on request via a DSAR. 2. To comply with Article 28(3)(e), we will provide an admin with telemetry data relating to users it identifies, on request via a support ticket. In each response, we will provide the user or admin (as appropriate) with a brief explanation about the concept of telemetry data, and how that data is typically used by GCP (including circumstances where it may be pseudonymised or anonymised). We consider this to be an appropriate level of transparency for both admins and users. ” 58 Later, Google agreed to publish adequate telemetry documentation. Google published the information on 22 December 2025. 59 With this publication, G oogle has fulfilled its commitment to explain that it collects telemetry, for what purposes, with what retention period, and to provide relevant examples.

Google does not publish an exhaustive list of the types of telemetry messages that it collects. Google provides examples, including purposes, but not an exhaustive list. This makes it more difficult to assess what Google does not collect. Google gives four examples of session and identification identifiers. These do not include any directly identifiable data; they are all randomly generated IDs during a browser session. Google also writes about messages in general: " Note that this structure does not contain information that specifically relates to the user (e.g. ID and IP address). This information is contained in the auth cookies stored on the server, after a successful authentication, and gets appended to the event record by the server. " SLM asked Google to clarify if it collects C ontent D ata via telemetry, either in the form of file or folder names, or in telemetry about searches in , for example, search queries.

As shown in Section 3.3.2 above, Google does collect such data as part of the system generated server logs. Google explained that it does not consider file or folder names or queries to be Content Data (Google uses the term Customer Data) , but part of Service Data . Go ogle explained: "For clarity, telemetry data excludes what we categorize as "Customer Data" under your organization's agreement for Google Cloud services (for example, object data in Cloud Storage; data contained within BigQuery tables; or container images in Compute Engi ne). Regarding “file and map names”, our existing terms are clear that we have always treated “resource identifiers” like these as Service Data (not Customer Data), and, therefore, it would not be appropriate to refer to them as Customer Data in this artic le [the publication about Telemetry Data, addition Privacy Company] . For example, the GCPN refers to “resource identifiers and attributes” as being Service Data, and, similarly, the GCP Service Specific Terms note that “For clarity, Customer Data does not include resource identifiers, attributes, or other data labels.” 60 58 Google reply to questions SLM , 21 March 2025. 59 Google, Telemetry Data in Google Cloud Console , undated but first published 22 December 2025, URL: https://support.google.com/cloud/answer/16796043 . 60 Reply Google to question SLM Rijk, 19 February 2026.

DPIA on Google Cloud Platform public version 11 June 2026 Page 45 of 142 Google agreed to add a clarification to the public information about the Telemetry Data: “ Additionally, we have a policy not to collect user - defined resource identifiers as part of telemetry (for example, your chosen file names, virtual machine names, etc). Furthermore, while telemetry may include queries submitted via the Console search bar, w e cannot identify the relevant user from their search activity. ” 61 Privacy Company did not perform new tests to check if Google provides the telemetry data in reply to a (new) DSAR request. Figure 19 : Example of Cloud logs telemetry event: http request and headers POST https://cloud.google.com/log?format=json&hasfast=true&authuser=0 HTTP/2.0 user - agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0 accept: */* accept - language: en - US,en;q=0.5 accept - encoding: gzip, deflate, br, zstd content - type: application/binary content - length: 5065 referer: https://console.cloud.google.com/ x - goog - authuser: 0 content - encoding: gzip origin: https://console.cloud.google.com sec - fetch - dest: empty sec - fetch - mode: cors sec - fetch - site: same - site authorization: SAPISIDHASH 6e2b2e7dbe9199be1bcb4c8352673e6f1a946b6e cookie: __Secure - ENID=23.SE=DClKSc9uZgpFt3kgQgy6UcrwfIiqRCi4tR7Ptnep9JNfXRXRQBJsm9bztpb6Qkajw8kq 0yIQF1u8aq9Gr1y9c2i9pdjLwqqlGyYdyShsDIeQWSkwR7J3eejVlD2uZuYJLc2 - z - a6yQWxuHV4SM1ZlSw - pLBCeMMVIwc9Y1w8i974anrA3VE8wD7kdLFzuezaokfOzyBdUpWPsw0gYXh1uqb42KMFjOtv3ePw FsyUB8bt6IJjSkQB9ya8qyTt7JeZIIAJJQjlN9NE40e2xpaMo4e1NGNHNZaLIBCr3lLsk37MFKe92LcC vxsJV0eyHGXvmMcLfQKmGBOSuItwVs8oBSNNjRc1HuBHT6lzdlpxC_EHyDMjA_zgEhjg9CYwNKpi c8yT46EZn - _7R - bPH7jij8lzDbCYLgS1zpE9xuQ9ik6PnnrrLjEFxA3TjpQLtGOEUqFQSAKl60uwMwbFskbjbv - 322wbM5kRc8I3 BXC2dsivfkvre7 - XIXlBbPDhchcnHG3_4Fo cookie: NID=519=OGNC6Fl4WQkkmL - P2OlXZ0h9FpO47sLspWSX814msPQ7efAe9dmuIkK4xq2YmlNqSqPHjO0bihEFj_GrdkbHElseyGZQ 06Lhud2yPRKz9u0tT2BqXk9lOgWy - 34M4iF3PM3P3rTmDI9ZB9RDoOgTiAxTHLUcB127OhH5iw2e - iAI_ - FhQpUbOnaxcjU - 8B99Tm01vuU30IErl0aOgnZxk1zIchEIxQl6z - FrnHAU5p_ZcReW qGCsvk9 - xcyIDPGoYKjYd6MRs3x1ejCJHr4VtuMyBWhfLzJZhkTXAc45e7JSxEt - rdYyPf9BpeiJFdMcc7BeCLU_ - CL65vrP0GBOo - G7eKuJncZxe3gukbAhlr9uEq_OBtLPQVnxKDkk0rJ - vUUqf4nGJmcsm44VnDh2 - vCITzx_EzLzHHYRKhxlkZkmwyXs9JHWXvuVqqzGToWHxAthou10t6bVsJlr - p983u531rxwO3w - x9UeaFVCd9HTZ - gB 5L_DMY9GQfUtLPsBTZzfOWm7FwJB07QbcLWaIJBqmYdHy8cGpVVhAh9X4vKv3CVQPl6OFKm QobG38XAblqgeYRWKLVLgkzNMZqDUY6Qqvtjiy5yUmuY0expn8ApGqdmtCDMEuDk6SX5gCretId ePXlI896Co2qC5vvzbNqCuS0BA7kPLer1EVbiS7TBfHBPMuqt4D9fDc0N6LU - fYQHpJe8Elnmqq6IXUWlybxaIczU6imw08zCZPggXN219zEEc 98MQJZPSnN1mb2JIlJW2gZcAoOIS QpiJcGA - _2LGTvpnotNMkndjNix4gwRbV7JVL_Jb1mDthImMY1U6 - On75tvB1 - z2AO0TSTaSAULj2jTe - 3nQdRvA45gRNzzwuohfh2zKeWIB5ELvSEoZX - 61 Google, Telemetry Data in Google Cloud Console , undated but first published 22 December 2025, URL: https://support.google.com/cloud/answer/16796043 DPIA on Google Cloud Platform public version 11 June 2026 VMdV3UR3T1AsPvM15YVh2LVCHewlXXApXIHFeJNIcWfrSWuWQ7ERZ3tzBUt_ - ehwXAu7U2aVsR4FshC0NvJn_YlWkPywmBtRg2FZTxqx5zQwgFr5wi_IxvvjU cookie: __utmz=utmcsr=(direct)|utmcmd=(none)|utmccn=(direct) cookie: _ga=GA1.1.1729489941.1717426816 cookie: _ga_WH2QY8WWF5=GS1.1.1731958128.44.1.1731959733.49.0.0 cookie: _ga_devsite=GA1.3.3761092984.1717426815 cookie: django_language=en cookie: AEC=AVYB7cqoGr6cxKYIS9xaAH2OJcz - iEGoZ9rduxaTsQBnnfGnWbqqhwlwa94 cookie: _ga_64EQFFKSHW=GS1.1.1728563030.7.1.1728563241.0.0.0 cookie: SID=g.a000qQiaMaMAwGMVSliFeG9XJ1MIB_U5zkGNKONKgBCYXWGwWoWBA8eYvjNqeZ02BE mdLpKLhwACgYKARsSARMSFQHGX2MiFIQOL - T2Yn8r0fAY7N5X9BoVAUF8yKoq2d54BW1XJ - H6jThl3LmV0076 cookie: __Secure - 1PSID=g.a000qQiaMaMAwGMVSliFeG9XJ1MIB_U5zkGNKONKgBCYXWGwWoWB2QdOPD2FFjBw TG5OnVgnQgACgYKAU0SARMSFQHGX2Mi - jy8og - G19zxtj_PcLB49BoVAUF8yKpPCaZPxO9LxkaXU0BpvTIT0076 cookie: __Secure - 3PSID=g.a000qQiaMaMAwGMVSliFeG9XJ1MIB_U5zkGNKONKgBCYXWGwWoWB0hEwiVs8XSq - ZGnLkQXARgACgYKARwSARMSFQHGX2MijVMGX - vQh0TfsIiAzLJq2hoVAUF8yKo_lKKSJ7 - MCwDw3pP - nbHT0076 cookie: HSID=ALKrvajLRX5sGMAAx cookie: SSID=AIKowhpEihrIAKXz - cookie: APISID=oAb2ll7bcJKqC7eS/A2qoMYDcrQPG0JiVQ cookie: SAPISID=pInJ7EzEL2OGXgPJ/AXL - mVIJhBgvnSgFV cookie: __Secure - 1PAPISID=pInJ7EzEL2OGXgPJ/AXL - mVIJhBgvnSgFV cookie: __Secure - 3PAPISID=pInJ7EzEL2OGXgPJ/AXL - mVIJhBgvnSgFV cookie: SIDCC=AKEyXzWqPp - 2IymfHwaT_Cw - MkqP2QNk7Ap0B8UrRU9EduqwzRBW09P5Gi7xUom8uxk2B8skNfc cookie: __Secure - 1PSIDCC=AKEyXzW6MH6f0Lv_Igxps6Qfc2VVfzzQEhYGPUBtq3PggGpG0SeKf19tLB2Uhahfql57G qlcIWYn cookie: __Secure - 3PSIDCC=AKEyXzUQxdXaBJ - LPb - PrtPRWlXkGVDq8dsVD8PAYYrO0iNq3B2PIqwRU2H24rbonJiIj2JgV1YX cookie: __Secure - 1PSIDTS=sidts - CjEBQT4rX11us1_sKqEnvxBvqsnCfRE5ZcOijxRGzRQNjaDWUqY9tGbDvrpzUotMXwmDEAA cookie: __Secure - 3PSIDTS=sidts - CjEBQT4rX11us1_sKqEnvxBvqsnCfRE5ZcOijxRGzRQNjaDWUqY9tGbDvrpzUotMXwmDEAA cookie: OTZ=7827050_52_52_123900_48_436380 priority: u=4 te: trailers These events also include long lists of numbers in the POST request.

Google explained that these numbers referred to experiments . Experiments are (highly granular) features of the tested service. Figure 20 below shows (a short excerpt of) these lists , in a version formatted by Privacy Company. Figure 20 : Excerpt of POST request with experiment numbers POST https://cloud.google.com/log?format=json&hasfast=true&authuser=0 HTTP/2.0 user - agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0 […contents removed by Privacy Company for readability] null, DPIA on Google Cloud Platform public version 11 June 2026 Page 47 of 142 "[null,null,[101434891,101803537,101766672,101418505,101803541,101766676,101508615 ,101434887,101418501,101508611,95135160,95135156,101475887,99390919,99390915,10 1475891,95094241,101471815,101766747,95094245,101766751,101471811,99313080,9931 3076,101787249,1 01787253,95278539,101500517,101537383,95278535,101500513,101537 379,99239314,94430682,99239318,94430686,102024855,102024850,95225145,95225141,9 9329355,95094024,101828274,99329359,95094020,101828260,101828265,71681276,10182 8269,101762782,95290751,13840385,95 290747,99321137,99321141,99370255,95266143,1 01762786,95266139,99370259,99435757,99443949,101680901,94725295,101680897,94725 291,101672733,101398303,101533460,13849032,99435761,99443953,101533456,71099682 ,94663812,99411150,94663808,101398307,95155328,9524544 1,99275995,95093914,95093 918,99402970,99402966,99275991,99411154,71681285,101418826,95151336,71681280,10 1418830,95151340,99398820,71681289,99398816,71284082,101545820,71284078,1018857 63,101517150,101885766,94520564,99329202,94520568,99329206,99460237,10151 7154,9 9251355,71476531,101484414,71476535,13832612,99460241,99251351,101484418,101377 945,101377949,99738729,95245364,99738733,95245360,101406636,101705639,99341377, 101705635,99259483,101517238,101406640,99259479,101517234,13852949,95130721,946 88372,9524543 7,94688368,99341373,101517274,95155324,101517270,101513197,1018900 38,101513193,95089740,101890043,71620015,71620011,101726180,95130717,101726184, 95089744,71296452,71296450,99436525,99436521,99330017,99416038,99416034,1018275 84,101827587,101651518,101651514 ,99330013,95057809,95057813,101749824,95250428, 101446746,95188991,101749828,101446750,95188987,94967757,101627004,101627000,94 967761,95262676,95262672,95094570,99297129,95233833,95291178,95094574,99297133, 95233829,95291174,99297127,99297137,95029000,101819 572,95029004,101819577,10143 8624,101438628,101495996,101495992,101438652,101524660,101524656,101672139,1016 72135,101438656,93874004,71354004,71354008,93873986,13861429,99251995,71194314, 101577976,99251999,101917931,101577972,71194311,101917928,13845039,101 602575,99 444460,99444456,101733660,101602591,94820020,101602589,94820016,101741831,10160 2582,101741835,101397801,95155840,101397797,101733664,101709108,71071490,101709 104,101414223,101565760,94598899,94598903,101414227,101729660,101729664,9939519 6,10176243 4,101504408,95290938,99395192,101762438,101504404,95290934,95225359,1 01569960,99292748,101569956,71555054,71555058,101655993,101655989,99292752,9522 5363,101483980,101569996,101483982,101569992,95155808,95188607,95241848,1015904 88,95155836,95188603,95241844 ,101590484,95155804,99402217 ,99402213,95273401,952 73397,101569047,101569043,99275201,99275205,101601853,95125994,101565003,101540 420,101397057,101564999,95117792,95125990,101540416,101397061,101601857,1014503 35,101450331,101835376 ,99373455,95199695,99373451,71409708,71409712,99373464 In the new article Google explains what experiment IDs are , and provides a specific example of such an event.

“ Experiment Exposure: When a user interacts with an experimental feature (i.e. a feature that is made available only to a fraction of users), the numeric ID for that experiment is recorded. This is used for aggregation to check success metrics or increased error rates relative to an experiment launch. ” 62 Google explains about the specific experiment telemetry event: “ This event logs an exposure to a specific experiment. The Console has a built in experimentation capability that allows Google to test new functionality with limited impact and gradually roll out new capabilities. ” 63 62 Idem. 63 Ibid. DPIA on Google Cloud Platform public version 11 June 2026 Privacy Company assesses that the collected data can be linked to the data subject by the included cookie - identifiers. In reply to a question from Privacy Company how Google assured the necessity of the collection of personal data via Telemetry Data, given the highly dynamic nature of this data collection, Google provided the following explanation about its technical and o rganisational measures: “Google implements and maintains a range of technical and organisational measures to ensure that engineers are only able to collect, access and use the minimum amount of telemetry data actually required to perform their roles, and avoid collection of telemetry not necessary for that purpose (including, for example, building/changing existing code to collect more and/or new telemetry than is actual ly required).

In terms of organisational measures : • We implement a mandatory, company - wide pre - launch review policy for all products to ensure adherence to robust privacy and security standards. This process is grounded in a ""Privacy by Design"" approach, embedding privacy safeguards into product architect ure. • Each review involves identifying, assessing, and mitigating potential risks before a new product launch or significant product update (for example, a proposed material change in scope of data collection, including telemetry). • As part of this review, dedicated privacy teams assess the specific types of data that will be processed to ensure that, among other things, the principle of data minimisation will be met. • This governance framework is supported by strict data classification, access controls, and encryption. • On coding specifically: any code creation/modification must go through a rigorous software development life cycle, which involves review by other engineers.

Additionally, when new features are being developed, design documents must be written and approved by appropriately senior engineers before code implementation can occur. In terms of technical measures : • Our engineers do not have ambient access to Service Data (including telemetry). • Our engineers are granted only a limited set of default permissions to access company resources. • Access rights and levels are based on an engineer’s job function and role, using the principles of least privilege and ‘need - to - know’ that match access privileges to defined responsibilities. • Requests for additional access – e.g. to telemetry – must follow a formal process that involves a request and an approval from the data or system owner, manager, or other executives, as dictated by our security policies. • Approvals are managed by workflow tools that maintain audit records of all changes. These tools control both the modification of authorization settings and the approval process to help ensure that approval policies are consistently applied.

This includes s cenarios where time - bound access is only granted on a temporary basis. At the end of the temporary access period, permissions are automatically removed and engineers must obtain approval for a new request to maintain access. DPIA on Google Cloud Platform public version 11 June 2026 Page 49 of 142 • An engineer’s authorization settings are used to control access to resources, including Customer Data, Service Data, and systems for Google Cloud products. Our security teams, privacy teams, and internal audit teams monitor and audit engineer access. • For completeness, and per our response shared on 21st March, we confirmed that “Google has not detected any unauthorised usage by engineers in the third countries in the past 2 years to a) Customer Data and b) Service Data from the 4 tested GCP services." 64 Google also provided an explanation on the identifiability and interpretation of the telemetry data: “ Google may process telemetry data that identifies a user to gain insights into system health and to identify optimization opportunities for the platform.

Interpreting this data allows us to understand and address latency, errors, and breakages in our produ cts, and to assess the stability, and usage of new features. As examples: • Google monitors the end - to - end performance of GCP - services and those monitoring systems identify crashes and errors when they happen. If a service crashes, information about that crash (including information that may identify the user that initiated the service request) is collected and aggregated into statistics about crashes occurring in the services. The Google engineers diagnosing the cause of service crashes would only have access to the aggregated statistics rather than information that would identify individual users, except when identification is required (e.g., to debug an issue raised by a customer). • Google uses telemetry data to run A/B testing where appropriate to determine whether a feature is ready for launch.

Per Google’s policy, this data is aggregated, anonymised or pseudonymised when identifiability is not required for the processing of that data.” 65 Google did not explain when, in what circumstances, identifiability is no longer required. In reply to questions about the timeline of pseudonymisation or anonymisation, Google repeated the same three options : “ Google’s policy is to aggregate, anonymise or pseudonymise telemetry data when identifiability is not required for the processing of that data. Under this policy, Google will do so after approximately 50 days. ” 66 Mitigating measures Google • Google commits to provide access to the Telemetry Data in reply to a DSAR (not re tested by Priva c y Company ) . • Google has publish ed adequate documentation about the Telemetry Data, with relevant examples , via https://support.google.com/cloud/answer/16796043 64 Google reply to questions SLM, 19 September 2025. 65 Google reply to the Technical Appendix, 13 December 2024. 66 Google reply to questions SLM , 21 March 2025.

DPIA on Google Cloud Platform public version 11 June 2026 including information about the retention period s - s ee Section 11.2 of this DPIA . • Google will not develop an option for admins to disable or minimise the collection of Telemetry Data. According to Google, all data are necessary to comply with the agreed 3 processing purposes agreed by SLM Rijk in the enrolment framework , and for the agreed Legitimate Business Purposes. • Google has provided an explanation about the technical and organisational measures it applies to supervise that only necessary personal data are collected as part of Telemetry Data (see long quote above). Google also confirmed it had not detected any unauthorised usage by engineers in the third countries in the past 2 years to a) Customer Data and b) Service Data from the 4 tested GCP services. • Google has confirmed it does not pseudonymise or anonymise Telemetry Data, but completely deletes them after 63 days, including from backups. • Google will not develop a Telemetry viewing tool like the DIT for Workspace Telemetry. 3.3.4 N etwork metadata samples Privacy Company created a website on the VM to test if Google collected the IP - addresses of visitors to this website in its own security logs.

Privacy Company checked all of the sources mentioned in Google’s reply to the DSAR, but none of the sources contained metadata about unauthenticated visitors ( without Google Enterprise accounts) to the service hosted on the VM. This could mean two things: either Google deletes such metadata before providing access, which approximately takes 30 days, or Google did not provide access for unknown reasons. Google later confirmed it does sometimes collect such IP addresses, but only in a very small percentage of cases: “ When a citizen visits a government website that sits on a Google Cloud VM, Google samples approximately [CONFIDENTIAL] of the network packets (across all VMs for all customers) and collects metadata relating to the packet, which includes the IP address. This metadata is used for (1) troubleshooting network connectivity issues for GCP customers, (2) preventing abuse of GCP - services, and (3) capacity planning GCP - services.” 67 On 8 July 2025, Google had a technical session with Privacy Company to provide more information about Google’s network packet sampling process.

Google gave helpful extra explanations during the meeting and in a document , and confirmed that the samples contain the source IP address and destination IP address, but no other data. This sampling collects only packet metadata, and not the contents of the packets. More specifically, we collect information that is available in the IP header for the packet (for example: source port, source address, destination port, destination 67 Google reply to Technical Appendix 13 December 2024. DPIA on Google Cloud Platform public version 11 June 2026 Page 51 of 142 address, IP protocol). These samples are collected and aggregated; and are used for: a. Capacity planning purposes (i.e. observe past trends of aggregate traffic and predict future capacity required to meet demand); and b. Real - time network monitoring (i.e. observe current aggregate traffic in order to answer operational questions related to operating the network).

The original source IP addresses of the packets are aggregated in an industry - standard way to protect user privacy - IPv4 addresses are aggregated to a /24 prefix, and IPv6 addresses are aggregated to a /48 prefix. This means the original source address is no longer present. We cannot identify an individual user from a sample because aggregated source IP is not sufficient, and we do not maintain, acquire or process additional information in order to identify them. On that basis, we do not consider there to be a GDPR requiremen t to provide packet metadata to users in response to a DSAR. 68 Google also wrote: " We can confirm that Google collects no more additional logs about visits to that website other than that which has already been shared with you - i.e. sampled packet metadata. ” 69 Google also explained that customer s can use a feature called VPC Flow Logs on a GCP Virtual Private Cloud (VPC) network to view a representation of the sampled packet metadata for traffic to and from their resources in a VPC. 70 In reply to this DPIA Google wrote: “Therefore, it is highly unlikely that Google ever randomly collects a sample relating to a Dutch public sector customer's VM.

Even if that ever happens, Google is bound by the contractual terms that we negotiated and cannot process any Service Data for any purpose beyond the already agreed Legitimate Business Purposes.” 71 Google added: “This means that, at any given point in time, it is extremely unlikely that Google has collected any packet pertaining to a Dutch Government customer’s use of Google Cloud services. It would also not be apparent to us if/ when we had done so. Additionally, the IP address cannot, in itself, identify a specific individual, and is collected without any other information in the packet that would enable Google to join it to other data. The purposes for which Google processes the data in the 68 Google reply to questions SLM, 18 July 2025. 69 Goog le answer to questions SLM 19 September 2025. 70 Idem, with a reference to Google Cloud, VPC logs, Last updated 2025 - 09 - 26 , URL: https://cloud.google.com/vpc/docs/flow - logs .

Google added that it collects more data if customers uses Google’s Cloud Load Balancing service (out of scope of this DPIA). 71 Google (second) reply to part A of this DPIA, dated 21 March 2025, made accessible to Privacy Company 25 March 2025. DPIA on Google Cloud Platform public version 11 June 2026 sample packets do not require or enable Google to identify an individual data subject, and we do not maintain, acquire or process additional information in order to identify them, in line with GDPR obligations .” 72 Mitigating measure Google • Google has confirmed that it does not have additional (security) logs in which IP addresses of visitors to websites hosted on GCP are processed. 3.4 Support Data The actual data processing through a support request was not tested for this DPIA, because this requires an extra subscription to Assu red Workloads. 73 3.5 Web s ite Data This Section describes Google’s data collection via both the GCP Admin Console, and via the publicly accessible cloud.google.com information pages.

Google has a general information page about the cookies it uses for all customers, both for consumers and Enterprise customers. 74 This cookie information page does not include or refer to a limitative list of cookies, of their specific purposes, and of the length of the retention period by Google (different from the expiry date in the cookie). Google describes on this page that it uses similar technologies next to cookies “ including unique identifiers used to identify an app or device, pixel tags, and local storage ”. Additionally, in the Google Cloud Privacy Notice, Google provides the following description of the data it collects: “ Technical and operational details of your usage of Cloud Services: (…) This information includes device identifiers, identifiers from cookies or tokens, and IP addresses. ” The third and final source of information about Google’s use of cookies is Google’s Privacy Policy.

In its Privacy Policy Google provides a description of the types of information it collects through apps, browsers and devices : “ The information we collect includes unique identifiers, browser type and settings, device type and settings, operating system, mobile network information including carrier name and phone number, and application version number. We also collect information a bout the interaction of your apps, browsers, and devices with our services, including IP address, crash reports, system activity, and the date, time, and referrer URL of your request. ” 75 72 Google reply to questions SLM, 21 March 2025. 73 Google Cloud Documentation, Assured Workloads, Assured Support, undated, URL : https://cloud.google.com/security/products/assured - workloads (page last visited 4 November 2025). 74 Google, How Google uses cookies, undated, https://policies.google.com/technologies/cookies (page last visited 27 January 2025). 75 Google Privacy Policy, Information we collect as you use our services DPIA on Google Cloud Platform public version 11 June 2026 Page 53 of 142 Google’s Privacy Policy contains a description of Google’s cookie usage across its domains and services, with some examples, but not a limitative list of the names of cookies either. 3.5.1 Google r estricted access website Privacy Company has analysed the cookies observed in the network traffic generated by the use of Google Cloud Admin Console and has tried to compare these observations with Google’s public cookie documentation.

Initially, n o cookie consent banner was observed in the Admin Console while GCP was tested . Google has introduced a cookie banner in Q3 2025 that mentions 3 purposes for the data processing . The hyperlink ‘Learn more’ leads to a Google page about cookies . 76 Google calls this page ‘Cookie Policy’, though the title is ‘How Google uses cookies’. Google does not offer an option to reject the cookies . Figure 21 : Cookie banner on console.cloud.google.com (since Q3 2025) Google did not set or read cookies from third parties. However, Google does set cookies for analytical purposes, and uses the quadruple - usage NID - cookie. Figure 22 : Screenshot G o ogle cookies from console.cloud.google.com Some cookies shown in Figure 22 are mentioned on Google’s public cookie information page , but most are not. The different cookies with the word ‘_Secure’ are not all mentioned. 77 N or are cookies with the names APISID, OSID , RAPT, SAPISID, SIDCC Your apps, browsers & devices, effective 16 September 2024, URL: https://policies.google.com/privacy#infocollect 76 Google Privacy Policy, section about cookies, URL: https://policies.google.com/technologies/cookies?hl=en 77 According to Google it mentions ‘Secure’ cookies 3 times in its Cookie information page.

PC could only find two mentions, for _Secure - YEC and _Secure - ENID. Google reply to the DPIA, 23 October 2025. DPIA on Google Cloud Platform public version 11 June 2026 and SSID. The contents of these cookies are long enough to contain a unique identifier. Google does provide an explanation to users about the NID - cookie it sets. Distributed over 4 different sections of its cookie information page Google describes four purposes for the NID - cookie : functional, analytics , advertising and personalisation . Figure 23 : Google 4 purposes for the NID - cookie (distilled from long text 78 ) Purpose Explanation Google Functionality These cookies [‘NID’ or ‘Secure - ENID’] are used to remember your preferences and other information, such as your preferred language, how many results you prefer to have shown on a search results page (for example, 10 or 20), and whether you want to have Google’s SafeSearch filter turned on.

Analytics Google services also use ‘NID’ and ‘_Secure - ENID’ cookies on Google Search, (…) Advertising The ‘NID’ cookie is used to show Google ads in Google services for signed - out users, while the ‘IDE’ and ‘id’ cookies are used to show Google ads on non - Google sites. Personali z ation the ‘NID’ cookie enables personalized autocomplete features in Search as you type search terms. Google did not provide access to its webserver access logs with information about the visits from the test admin to the Admin Console. Commonly, web server access logs collect and store the client IP addresses, user agent strings, date, time, server name, server IP and services running, among many others. These logs show who visited the website, where the visitors came from, what pages they visited, where they went to, and in case of access to the restricted access Admin Console, their authentication and se curity credentials. 79 Mitigating measure s Google • Google introduced a cookie banner on console .cloud.google.com that mentions 3 purposes of the data processing with cookies and similar technology: 1) deliver the service, 2) enhance the quality and 3) analyze traffic.

The banner does not mention the purpose of ‘advertising’. • Google is not allowed to further process any Service Data in a role as authorised data controller for advertising or profiling purposes. 80 • By the end of 2025 Google will add an explanatory sentence to its c ookie information page about the NID - cookie. If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. 78 How Google uses cookies, page last visited 4 November 2025. 79 Google wrote that its personal data processings of logging in this context is very limited. Google reply to the DPIA, 23 October 2025 80 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 Page 55 of 142 • Google commits to provide an appropriate response in reply to a DSAR, including data from web server logs relating to a user.

Admins can also ask for the webserver access logs relating to specific users via a support ticket. • Google commits to provide an explanation about the concept of such logs, and how they are typically used by GCP. • Google will provide the reply as soon as possible and in compliance with GDPR timelines. 3.5.2 Google public access websites When an admin visit s the cloud.google.com pages to look up technical information , or to look up information about the sub processor s, Google shows a cookie banner that describes three purposes of the processing. The ‘learn more’ hyperlink leads to the general cookie information page described above. Figure 24 : Cookie banner on public website cloud.google.com This banner is the same as on the console.cloud.google.com. The banner is different from the agreed banner with SLM Rijk in the context of visits to the Google Cloud Privacy Notice by Google Workspace Enterprise users.

After discussing the necessity for admins and legal staff of government organisations to visit this legal document without getting the impression that they would have to accept advertising cookies, Google agreed to change the cookie consent banner. In the new banner, Google explicitly excludes the use of cookies for advertising purposes (“ Deze website maakt geen ge bruik van cookies voor advertenties” ). This purpose limitation was extremely important, because Google does mention advertising as processing purpose, especially for the observed NID - cookie, in the general cookie information page shown to users when they click on ‘Learn more. When Privacy Company creat ed the initial Google account as the start of the tests , Google presented a longer explanation about the use of cookies, including advertising. See Figure 25 below. Privacy Company refused consent, to prevent processing for advertising purposes.

DPIA on Google Cloud Platform public version 11 June 2026 Figure 25 : Google information page about cookies (bottom half of page) As shown in Figure 17 in the Technical Appendix Google set similar undocumented cookies on accounts.google.com. In reply to these cookie observations Google provided the following explanation on the processing purposes of the observed cookies: “ As you may be aware from previous discussions on this topic, Google’s policy on cookies is set out here . 81 We believe this policy addresses your request for “documentation” about the cookies you observed during testing. For instance, figures 16 and 17 in the Technical Appendix each display a column showing cookie names such as NID (which are used to e.g. remem ber choices and preferences), SID and HSID (which are used to authenticate users), and AEC (which is used for security purposes, e.g. to detect spam, fraud, and abuse).

These (and other) cookies, and their purposes, are explained in more detail in our poli cy. We note you refer to “advertising” in your request. For clarity, GCP (including the Cloud Console) do not use cookies for advertising. This also applies to the NID cookie, which we discussed extensively with you during the Workspace DPIA.” 82 Google later added: “ console.cloud.google.com and cloud.google.com only use cookies for functional purposes in the Netherlands (to provide our service and to analyze traffic). Cookies deployed on these websites are not used for advertising purposes, so there is no need to have an option to decline advertising cookies. If we plan to use cookies for advertising purposes in the Netherlands in the future, we commit to updating our cookie banner to allow users to easily refuse these cookies (e.g., the accept/reject buttons would be equal weight so it’s as easy to accept as it is to reject). ” 83 81 Google, Types of cookies and similar technologies used by Google, undated, URL: https://policies.google.com/technologies/cookies (page last visited 27 January 2025). 82 Google reply to the Technical Appendix, 13 December 2024. 83 Google reply to questions SLM, 18 July 2025.

DPIA on Google Cloud Platform public version 11 June 2026 Page 57 of 142 Mitigating measures Google • Google refuse s to explicitly exclude the use of cookies for advertising purposes, because it is not obliged to inform about processing it does not perform. It is sufficient t he banner does not mention the purpose of ‘advertising’. • Google is not allowed to further process any Service Data in a role as authorised data controller for advertising or profiling purposes. 84 • By the end of 2025 Google will add an explanatory sentence to its Cookie Policy about the NID - cookie. If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. • Google commits to provide an appropriate response in reply to a DSAR, including data from web server logs relating to a user.

Admins can also ask for the webserver access logs relating to specific users via a support ticket. • Google commits to provide an explanation about the concept of such logs, and how they are typically used by GCP. • Google will provide the reply as soon as possible and in compliance with GDPR timelines. 3.6 Results Data Subject Access Request Privacy Company filed a Data Subject Ac cess R equest (DSAR) on 19 August 2024 , both by sending an e - mail to the relevant members of the Google project team, and by filing a DSAR via the web - form. Figure 26 : Google Cloud Platform DSAR form 85 84 See footnote 29 . 85 Form accessible for logged - in admins at URL: https://support.google.com/cloud/contact/dpo?hl=en . DPIA on Google Cloud Platform public version 11 June 2026 On 24 September 2024, Privacy Company received a standard reply. Privacy Company unintentionally registered an account with a non - functional e - mail address.

This caused a delay of a few days. Google noticed the problem, and alerted Privacy Company. Privacy Company does not assess the (short) delay caused by this misconfiguration. In its first reply to the DSAR , Google mention ed 15 online information sources . Google wr ote : “ Based on the wording of your request, and our understanding (following an internal outreach as suggested in your request) that you have submitted your request in the context of conducting a DPIA with respect to a specified and aligned GCP service scope, our response only relates to the service(s) in scope. ” Only some of the 15 mentioned sources offer some access to logs with relevant personal data . 1. “ Google Cloud Platform Data Privacy Inquiry In the console.cloud.google.com a signed - in user can navigate to the “IAM & Admin” option in the left - hand navigation panel, then select “Privacy & Security” and then select “Google Cloud Platform Data Privacy Inquiry form” under the “Data Privacy Inquirie s” heading. 2.

Export Data from IAM Role Recommender The IAM role recommender uses aggregated IAM access data, collected during the usage of services in Google Cloud, to provide recommendations. This page explains how to export that access data to BigQuery using the BigQuery Data Transfer Service. 3. Billing Export and Structure of Standard data export BigQuery export sends your billing data to a BigQuery dataset. Learn more about BigQuery and how to export data to BigQuery 4. Data export in Transparency and Control Center This function allows customers to export the data used to generate recommendations. 5. View logs by using the Logs Explorer Logs Explorer in the Google Cloud console, which you can use to retrieve, view, and analyze log data. The Logs Explorer lets you find and view your logs so that you can troubleshoot problems. 6. Cloud Audit Logs Google Cloud services like Compute write audit logs that record administrative activities and accesses within your Google Cloud resources.

Audit logs help you answer "who did what, where, and when?" within your Google Cloud resources with the same level of transparency as in on - premises environments. Enabling audit logs helps your security, auditing, and compliance entities monitor Google Cloud data and systems for possible vulnerabilities or external data misuse. 7. Cloud API Cloud APIs provide both JSON HTTP and gRPC interfaces to clients, enabling them to programmatically request customer data and service data from a given GCP service. 8. Cloud Asset Inventory Asset inventory keeps track of all the resources that are created in your project and allows you to query them based on attributes. 9. Export an Image to GCS DPIA on Google Cloud Platform public version 11 June 2026 Page 59 of 142 This feature allows users to export a Compute Engine boot disk data outside of your Compute Engine project to a GCS location. 10. Security Command Center Export findings to a Cloud Storage bucket This product allows users to export the findings on the security command center with multiple export storage options.

Export logs to Cloud Logging The second option allows for continuous export to cloud logging. 11. Chart Explorer Users can use Chart Explorer to create charts for their resources and also export the charts. 12. Vulnerability Report This report allows users to view a report of known vulnerabilities for the installed guest operating system for their VMs with the support of an installed agent that requires the customer permissions access. 13. Migration center Logs View and export data in Cloud Logs that would facilitate the creation of the same VM configuration in a different environment. This can be used to facilitate the creation of dev, test and staging environments. 14. BQ CLI The admin can use bq cli to query the INFORMATION_SCHEMA views. Some of the information schema views may contain user emails and change histories. E.g. RESERVATION_CHANGES and CAPACITY_COMMITMENT_CHANGES 15. Usage and Storage logs Cloud Storage offers usage logs and storage logs in the form of CSV files that you can download and view.

Usage logs provide information for all of the requests made on a specified bucket and are created hourly. Storage logs provide information about the s torage consumption of that bucket for the last day and are created daily .” 86 In this first reply to the DSAR Google als o explain ed that it may need 2 more months to reply in full: “ Certain documents which contain your personal data may also contain personal data of others. These documents will need to be reviewed in detail and, in certain cases, redacted of third party personal data prior to being provided to you. This will be a time consuming exercise . Following an initial scoping of potentially relevant data and for the above reasons we consider this a complex request. As such we will need to extend the timeframe for our response. This means that we will provide a response ultimately November 19, 2024. Of course, we will do our best to respond to your requests as quickly as possible. ” 87 Google has committed to SLM Rijk in the context of Google Workspace Enterprise to providing an individual answer if a user uses the DSAR form, after the initial reply.

On 19 October 2024, Google provided this individual answer, saying it was unable to retrieve any other information. 86 Google mail to test - admin, 24 September 2024 87 Idem . DPIA on Google Cloud Platform public version 11 June 2026 In reply to a question if Google could commit to provide a personalised answer to a DSAR sooner, instead of claiming to need 2 more months, Google answered it is “ committed to responding to DSARs without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. ” 88 Google later added: " We understand that in their test, Privacy Company believed that the response identifying self - help resources was provided too slowly. We are sympathetic to the concern expressed, however, that response was not simply ‘standard’ (we note that these types of requests in relation to GCP have historically been rare).

The respo nse was drafted to identify the relevant DIY sources while further internal checks were underway, intended to assist the requestor in the meantime. We expect our responses going forward to be provided as soon as possible and in compliance with GDPR timelin es. " 89 On 2 October 2024, Privacy Company downloaded the available logs . Some logs were empty, such as t he recommendation logs . Privacy Company wanted to check with the DSAR if Google would provide access to the IP address of the admin in its role as visitor of the website hosted on the VM. That was not the case. See Section 3.3.4 (about Google’s security logs) above for an explanation from Google. In the first reply to the DSAR Google refers to its Google Cloud Privacy Notice (when using Cloud Services) and the Google Privacy Policy for information about the data processing. “ Please read the Google Cloud Privacy Notice (when using Cloud Services) and the Google Privacy Policy and safety center (when using Google Products and services other than the Cloud Services) to find: • Explanations of the types of information we collect • How information is collected • Why we collect certain information • How information is used • When information is shared. ” 90 These notices contains general information about the purposes of the data processing.

However, as will be discussed in Section 5 about the purposes for the processing, nor the Google Privacy Policy, nor the Google Cloud Privacy Notice provide a list of what categories of personal data are processed for what specific purposes and the specific retention periods determined by Google for specific data such as telemetry events, cookie data and security logs. 88 Google reply to questions SLM , 21 March 2025. 89 Google reply to questions SLM, 18 July 2025. 90 Google reply to DSAR , 24 September 2024. DPIA on Google Cloud Platform public version 11 June 2026 Page 61 of 142 These references thus create a puzzle for the requesting data subject with regard to the categories of personal data, the purposes for which they are processed and how long Google retains these data. Additionally, the Dutch government only allows Google to (further) process personal data for specific purposes. Ideally, Google would refer to these agreed purposes in the reply to the DSAR. 91 A determined admin should be able to find some information in Google’s Privacy Policy and Cloud Privacy Notice about (article 15(1) sub f GDPR) the right to lodge a complaint with the DPA, (g) information about external sources and (h) automated decision - making, including profiling, in particular with regard to credit - scoring, but it is illogical that Google does not provide this information in the contents of the DSAR.

T he following data were missing from the DSAR reply : 1. Admin log - in activities – the recipient is not warned that the admin user logs are only available in the admin.google.com portal, under reporting / audit and investigation. According to Google this is a conscious design choice, that account logs exist in Workspace. However, if a government organisation follows the offline onboarding process with its existing e - mail accounts, and does not have Workspace, it is unclear if the organisation has access to the sign - in logs of that admi n in GCP. 2. Telemetry Data – both types of observed events . 3. Information recorded in Google’s webserver access logs about admin activities in the console, and visits to cloud.google.com, with for example IP address, end user , device , activities and the Cookie Data . 4. Personal data collected by Google about network metadata ( sampling) , that may include IP addresses from visitors to the test - website hosted on the VM. 5.

T he necessary extra information elaborated in Article 15 (1) GDPR, in particular the provisions c ( specific recipients including sub processor s ) and d ( specific retention period s ) 6. A n explanation what personal data Google does not provide , and why . Google replied with the following replies and commitments : 1. " Admins unfamiliar with that functionality can always find the information [via our public Google Cloud Platform documentation] . ” 2. “ Google commits to provide admins with the telemetry data relating to them , with a brief explanation about the concept of telemetry data, and how that data are typically use d by GCP (including circumstances where it may be pseudonymised or anonymised). ” 3. No answer – Google erroneously referred to the possibility of the government creating its own website logs about a website hosted on a VM, instead of answering the question about Google’s own logging of visits to the Admin Console and publicly accessible GCP - pages (later explained as ‘network data sampling) . 91 See footnote 29 .

DPIA on Google Cloud Platform public version 11 June 2026 4. Google initially did not answer, but later provided information about network metadata sampling, and assured it does not collect IP addresses from website visitors in any other (security) logging. See Section 3.3.4 above. 5. No information about recipients – only a reference to Google’s public Cloud Privacy Notice (which should be amended by the CMA with the Dutch government) 6. “We will add the link to responses for future DSARs. ” 92 In reply to observations in the Google Workspace DPIA and update and verification reports about missing information from the DSAR reply, Google replied that it does not provide access to certain personal data in reply to a data subject access request for 2 reasons , because (i) it is impossible to reliably verify the identity of the data subject as that of the requester and (ii) in some cases such transparency would hurt Google’s efforts to protect the security of its systems.

In 2024 Google published a general explanation about information not provided in response to an access request. 93 Privacy Company assume d this explanation also applies to the results of DSARs filed for GCP - services . In reply to this observation, Google agreed to provide the link to this information in future replies to DSARs. T he 2024 Updated Verification Report on Google Workspace Enterprise concluded that Google had mitigated the risk of lack of data subject access with improved audit log exports, publication of detailed telemetry information, and by providing a tool for admins to download historical Telemetry Data , next to developing a Diagnostic Information Tool for users. 94 The status for GCP will be assessed in Section 15 of this DPIA. Mitigating measures Google • Google commits to provide an appropriate response in reply to a DSAR, including Telemetry Data and data from web server logs relating to a user.

Admins can also ask for the webserver access logs relating to specific users via a support ticket. • Google commits to provide an explanation about the concept s of Telemetry Data and of web server logs, and how they are typically used by GCP. • Google will provide the reply as soon as possible and in compliance with GDPR timelines. In sum , S ections 3 . 2 to 3 . 5 show that all Account, Diagnostic , Support and Website Data should be treated as personal data. Google explained its network metadata sampling in a technical session. Google confirmed that it captures [CONFIDENTIAL] of the network packets resulting from the use of (websites hosted on) VMs. These logs contain “ metadata relating to the packets, which includes the IP address” . Privacy Company was not allowed to inspect the ( A dmin C onsole) webserver access logs with personal data Google processes about the use of Google services and website , but 92 Google reply to questions SLM , 21 March 2025. 93 Google, information not provided in response to an access request, undated, URL; https://support.google.com/policies/answer/10972441 (page last visited 27 January 2025). 94 SLM Rijk , Updated verification report on Google Workspace Enterprise, 15 May 2024, URL: https:// SLM Rijk microsoftrijk.nl/wp - content/uploads/2024/07/Updated - verification - report - Google - Workspace - Enterprise. - Verification - of - agreed - remediation - measures.pdf DPIA on Google Cloud Platform public version 11 June 2026 Page 63 of 142 Google does acknowledge these logs contain personal data, and Google will provide access to these data in reply to a DSAR . 4.

Data processing controls Google offers several privacy options to admins of GCP - services . Privacy Company has not tested these measures, except for the EU Data Residency, but provides a description for government organisations to decide if they can and want to implement these options. 4.1 EU Data Residency Data Location Dutch government customers can choose data centres in the Netherlands as location for the four tested services (Compute Engine, Cloud SQL, Cloud Storage and BigQuery ). Google publishes a list with the GCP - services with data residency options. 95 Google explains that it will also host the back - up Customer Data in the chosen region: “ Google will store Customer Data for that Service at rest only within the selected Region or Multi - Region. Google may replicate that Customer Data within any other Region located within the country of the selected Region or within the country or countries o f the selected Multi - Region (as applicable) for backup, reliability, debugging, support, maintenance, or security purposes. ” 96 4.2 Access Transparency and Cryptograp hic control Content Data Google provides GCP customers with Access Transparency .

Google writes that customers can use ‘Access Approval’ for access by Google to Customer Data . 97 This service “ let’s you authorize requests from Google personnel to access Customer Data, Access Transparency helps you discover information about when Customer Data is accessed. ” 98 As explained in Section 2.1 , Google use s the term Customer Data for a limited set of Content Data : “ data provided to Google by Customer or End Users through Google Cloud Platform under the Account, and data that Customer or End Users derive from that data through their use of Google Cloud Platform . ” 99 The access controls therefore do not apply to access to the Account, Diagnostic, Support and Website Data. 95 Google Cloud Platform Services with Data Residency, unda ted, URL: https://cloud.google.com/terms/data - residency (page last visited 27 January 2025). 96 Google Cloud, General Service Terms , URL: https://cloud.google.com/terms/service - terms 97 Google Cloud, Overview of Access Approval, undated, URL: https://cloud.google.com/assured - workloads/access - approval/docs/overview (page last visited 27 January 2025). 98 Google Cloud Documentation, Overview of Access Transparency, undated, https://cloud.google.com/assured - workloads/access - transparency/docs/overview (page last visited 27 January 2025). 99 Google Cloud Data Processing Addendum, Appendix 4, last modified 15 October 2024, URL: https://cloud.google.com/terms/data - processing - addendum .

DPIA on Google Cloud Platform public version 11 June 2026 Access Transparency is available for the four tested GCP - services (and for Cloud KMS, if customers would use that for disk encryption) , but with regard to BigQuery Google provides the following limitation: “Some information about your queries, tables, and datasets might not generate an Access Transparency log entry if viewed by Google Cloud Support. Viewing query text, table names, dataset names, and dataset access control lists might not generate Access Tra nsparency log entries; this access pathway gives read - only access. Viewing query results and table or dataset data generates Access Transparency log entries. Some Access Transparency logs for BigQuery might not contain the accessApprovals field.” 100 In reply to a follow - up question from Privacy Company about the probability of acces s by engineers in third countries to the Content Data that may be part of the logs stored in BigQuery, Google explained that (even though Support Data are out of scope of this DPIA) : “If the customer does raise a support ticket, third party sub processor s providing technical support do not by default have access to Customer Data stored or processed by the services, and will only have access if the customer explicitly elects to share Customer Data in the course of a support case.

“ and “In the alternative, a resold customer has the option to procure support services from their reseller if such customer does not want to use Google support options.” 101 Dutch government organisations can use the A ccess Transparency logs to view any actions taken by Google personnel when accessing Customer Data. Google explains: “ Access Transparency log entries include details such as the affected resource and action, the time of the action, the reason for the action, and information about the accessor. The information about the accessor includes details about the physical location, employing entity, and job category of the Google emplo yee. ” 102 Privacy Company is not able to assess the effectiveness of Access Transparency measures against decisions from Google not to inform the customer about the access, for example when a gag order is put in place. To increase control over the access to Customer Data , Google also offers cryptographic controls with the use of a Cloud External Key Manager (EKM).

Google writes that this even prevents access by Google itself in case it receives third party (government authority) requests: 100 Google Cloud Documentation, Supported services, https://cloud.google.com/assured - workloads/access - transparency/docs/supported - services, table, row ‘Bigquery’. 101 Google reply to questions SLM , 21 March 2025. In addition, in their response to this DPIA on 23 October 2025 , Google explained that Google is an (authorised) data controller for the personal data in support tickets and support requests, but a processor for the providing of technical support services. 102 Google Cloud Documentation, Overview of Access Transparency. DPIA on Google Cloud Platform public version 11 June 2026 Page 65 of 142 “ the option to deny Google administrators access to their data for any reason, even in situations typically exempted from customer control, such as outages or responses to third - party data requests.

It does this by providing customers a clear reason why dat a is being decrypted, which they can use to programmatically decide whether to permit decryption and thus allow access to their data .” 103 Google offers a way for customers to ask for support on their encrypted data , called Key Access Justification 104 , but since these Enhanced and Premium Support services are out of scope of this DPIA, this policy is not analysed in this DPIA. 4.3 Geo controlled access for Enhanced and Premium support Google offers customers of the (extra) Enhanced and Premium Support services the option to define the geolocations from which Google may provide support. Google explains that this service ensures “ only Google support personnel meeting specific geographical locations and personnel conditions support their workload when raising a support case or needing technical assistance. ” 105 Use of these services does not guarantee that the data are exclusively processed with the EU .

Google explains: “ As explained in the Google Cloud Privacy Notice, “Service Data may be processed on servers located outside of the country where our users and customers are located because Service Data is typically processed by centralized or regionalized operations like billing, support, and security”. [CONFIDENTIAL] . ” 106 These extra support services are out of scope of this DPIA, and therefore not tested. 4.4 Pseudonymisatio n Government organisations can pseudonymise the account data of admins. The technical details are discussed in Section 9.4 . 5. Purposes of the P rocessing Under the GDPR, the principle of ‘purpose limitation’ dictates that personal data may only be collected for specified, explicit and legitimate purposes, and may not be further processed in a manner that is incompatible with the initial purpose. The purpose s are qualified and assessed in part B of this DPIA.

103 Google Cloud Blog, New data sovereignty controls for EU customers, 7 October 2021, URL: https://cloud.google.com/blog/products/identity - security/new - sovereign - controls - for - gcp - via - assured - workloads 104 Google Cloud Blog, 7 October 2021, Cryptographic Control Over Data Access, URL: https://cloud.google.com/blog/products/identity - security/new - sovereign - controls - for - gcp - via - assured - workloads 105 Google Cloud Documentation , Assured Workloads, Assured Support, undated, URL : https://cloud.google.com/security/products/assured - workloads?hl=nl (page last visited 27 January 2025). 106 Google reply to questions SLM, 21 March 2025. DPIA on Google Cloud Platform public version 11 June 2026 factual description of the purposes of the processing of Customer Data and Diagnostic Data by government organisations and by Google . 5.1 Purposes government organisations The general interests government organisations may have to use GCP are described in Section 7.2 below.

The specific purposes government organisations may have to process Content Data are out of scope of this umbrella DPIA. Government organisations have access to some Diagnostic Data collected by GCP about the individual behaviour of system administrators through the admin authentication logs and the system - generated server logs that admins can export to BigQuery and access via the Log Explorer ( Section 3.3.2 above). Government organisations may need to process these data to comply with information security requirements, to verify access authorisations, to investigate and mitigate data security breaches and to comply with data subject right s requests. As data controllers, government organisations must determine when they need to access the audit log files generated by GCP , what extra applications they want to use to get a better view of the available data and set security alerts, determine what retention periods are necessary to comply with security requirements while still complying with the data minimisation principle from t he GDPR , and for what specific purposes specific personal data in the log files may be (further) processed and analysed.

The se spe cific purposes are not in scope of this umbrella DPI A . 5.2 Purposes Google as processor Google has agreed to only process the five categories of personal d ata (for Google: personal data in Customer and Service Data) resulting from the use of the GCP - services for three purposes 107 : 1. to provide, maintain and improve the Services and Technical Support Services (TSS) subscribed to by Customer; 2. to identify, address and fix security threats, risks, bugs and other anomalies; 3. to develop, deliver and install updates to the Services subscribed to by Customer (including new functionality related to the Services subscribed to by Customer). Though the Google Cloud Master Agreement with the Dutch government uses the term ‘Customer (personal) Data’, the CMA specifies that this purpose limitation also applies to the Service Data for which Google is a data processor , i.e., the Account, Diagnostic , Support and the restricted access Website Data (GCP Admin Console) processed by Google to provide the subscribed GCP - services .

The CMA proh i bits Google from processing personal data for a dvertising purposes; o r for profiling, data analytics and market research if not explicitly requested by a customer , and with the exception of the agreed legitimate business purposes for the Account, Diagnostic, Support and Website Data . The CMA contains a limitative list of 107 Privacy Company has denied Google’s request to rename the word ‘purpose’ into ‘instruction’. This may be the wording in the data processing agreement, but the DPIA focusses on data protection risks that may be caused by purposes of the processing. DPIA on Google Cloud Platform public version 11 June 2026 Page 67 of 142 7 agreed legitimate business purposes for which Google may further process the processor Service D ata, when necessary. See Section 5.3 below. 108 As explained in Section 2.3 t he CMA overrules conflicting provisions in the Google Cloud Privacy Notice , in which Google lists different processing purposes for the Service Data , such as ‘ providing information about new or related products and features. ’ The CMA also prohibits Google from asking admins for consent to share Service Data with third parties if those services are disabled by the government admin s, contrary to the phrasing in the GCPN, in the subparagraph ‘With your consent’ in the paragraph ‘How we share data ’ of the GCPN. 109 5.3 A greed further processing purposes Google in its role as data processor is authorised by the Dutch government in the CMA to further process some personal data as data controller for 7 agreed compatible legitimate business purposes , when necessary (See Section 6.3 for an explanation of this legal construction of ‘further processing’). 110 These 7 purposes are: 1. billing and account management and customer relationship management and related correspondence with Customers; 2. improving and optimizing the performance and core functionality of accessibility, privacy, security and IT infrastructure efficiency of the Services and TSS; 3. internal reporting, financial reporting, revenue planning, capacity planning and forecast modelling (including product strategy); 4. abuse and security threat detection, prevention and protection (such as automatic scanning for and reporting of cryptocurrency mining, scanning for viruses, phishing, malware and other indicators of security threats, that may affect any of Google’s service s and to detect AUP violations); 5. processing of Personal Data in support tickets and support requests (including corresponding with Customers) and any attachments thereto sent by Customers; 6. receiving and using Feedback; and 7. complying with legal obligations . 111 Three of these purposes may not appear self - evident, and are explained in more detail below. 5.3.1 Complying with legal obligations Google may be ordered to disclose personal data pursuant to Legal Process, broadly defined in the CMA as: 108 See footnote 29 . 109 Privacy Company notes Google’s claim that these specific purpose limitations would be company confidential .

However, s ince Goog le is known as an advertising company, the contractual exclusion of the data processing for these purposes is an essential element of the data processing, that Google has to make available to data subjects as part of the legally required information in Articles 13 and 14 of the GDPR . If these purpose exclusions were confidential, the DPIA cannot refer to these measures . This would result in new data protection risks. 110 See footnote 29 . 111 Agreed purposes with SLM for GCP. Privacy Company notes Google’s claim that these specific purposes would be company confidential. See Privacy Company’s assessment in footnote 109 . DPIA on Google Cloud Platform public version 11 June 2026 “ request made under law, governmental regulation, court order, subpoena, warrant, governmental regulatory or agency request, or other valid legal authority, legal procedure, or similar process . ” It follows from the CMA that Google will only disclose the personal data from its Dutch government customers if strictly necessary to comply with Legal Process .

Google will take the following steps: 1. Attempt to redirect the third party to request the data from the customer directly 2. N otify its customer prior to the disclosure, unless legally prohibited from doing so. 3. If a customer reasonably objects against such disclosure, Google will oppose the disclosure. 112 Google publicly explains how it handles requests from government agencies for end user information: it reviews the requests, tries to narrow the request down and sometimes objects to the requests. 113 Google also explains that it (i) requests that the relevant authority obtains the requested data directly from the customer, (ii) reviews each request for legal validity and appropriate scope, (iii) notifies customers of a request, unless prohibited from doing so by law and (iv) provides technical tool s to give customers more visibility and control on access to data. Google has opposed indefinite non - disclosure orders and filed a legal challenge in the US challenging gag orders. 114 See Section 8.3.4 below for more information about disclosures by Google . 5.3.2 Abuse Detection One of the agreed legitimate business purposes is abuse and security threat detection, prevention and protection (such as automatic scanning for and reporting of cryptocurrency mining, scanning for viruses, phishing, malware and other indicators of security threats, that may affect any of Google’s service s and to detect AUP violations); 115 T he Google Cloud Platform Acceptable Use Policy (AUP) 116 is part of the enrolment framework .

In this document, Google describes what type of use of the services it considers abusive. This includes ‘any unlawful, invasive, infringing, defamatory or fraudulent purpose’ , ‘illegal activity, including child sexual exploitation, child abuse, or terrorism or violence’ and for example spam. Based on the CMA, Google can scan Content Data to detect violations of the AUP. Google explains that it uses “ algorithms to identify projects that appear to display 112 Idem. 113 Google, How Google handles government requests for end user information, URL: https://policies.google.com/terms/information - requests?hl=en - GB 114 Google, Advancing customer control in the cloud, URL: https://cloud.google.com/blog/topics/inside - google - cloud/advancing - customer - control - in - the - cloud 115 Ibid. 116 Google Cloud Platform Acceptable Use Policy, last modified 6 February 2023, URL: https://cloud.google.com/terms/aup?hl=en DPIA on Google Cloud Platform public version 11 June 2026 Page 69 of 142 malicious or spammy behavior, and for projects violating the Google Cloud Terms of Service or Acceptable Use Policy . ” 117 Google writes that it will send a warning mail to the e - mail address of the project owner , and the recipient can file an appeal if the content is incorrectly flagged.

However, in case of a security emergency Google may also suspend a project without warning: “ If the Acceptable Use Policy or Terms of Service violation creates an emergency security issue, your project might be suspended without any advance warning. ” 118 To prevent any misunderstanding about proactive scanning of customer Content Data for Child Sexual Abuse Material (CSAM) Google explained that it only scans for known CSAM, and has unequivocally confirmed that it does not scan for unknown CSAM (not itself, but also not indirectly through a partner like NCMEC) to discover new cases. 119 5.3.3 Improving the s ecurity of the GCP Infrastructure As described in Section 5.2 above, Google acts as data processor when processing personal data across its customer database for security purposes. Every data processor is obliged under Article 28 of the GDPR to “ implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject .”

However, when Google collects IP - addresses in its own SIEM logs from visitors to a VM, in a scenario where the government organisation has chosen to host a website on the VM, Google processes these data as data controller . This is part of the second legitimate business purpose, namely: “ Improving and optimizing the performance and core functionality of accessibility, privacy, security and IT infrastructure efficiency of the Cloud Services and TSS .” Google also publishes an explanation h ow it detects and responds to incidents. 120 Google defines a data incident as: “ a breach of Google’s security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Data on systems managed by or otherwise controlled by Google. ” 121 117 Google claimed this sentence was company confidential, but the sentence is quoted from Google’s public documentation, namely: Google Cloud Platform Console help, Policy violations FAQ, undated, URL: https://support.google.com/cloud/answer/7002354 (page last visited 27 January 2025). 118 Idem. 119 Google claimed this was confidential, but this information was published by SLM Rijk in the New findings verification review Google Workspace Enterprise, 15 May 2024, p. 13, URL: https:// SLM Rijk microsoftrijk.nl/wp - content/uploads/2024/07/New - findings - verification - review - Google - Workspace - Enterprise.pdf . 120 Google Cloud, Data incident response process, last updated May 2024, URL: https://cloud.google.com/docs/security/incident - response 121 Idem.

DPIA on Google Cloud Platform public version 11 June 2026 Google explains that this does not include unsuccessful login attempts, pings, port scans, denial of service attacks, and other network attacks on firewalls or networked systems. 122 Google explains that its incident response program is managed by teams of expert s across many speciali s ed functions . “ Depending on the nature of the incident, the professional response team might include experts from the following teams: • Incident and escalation management • Product engineering • Site reliability engineering • Cloud security and privacy • Digital forensics • Global investigations • Detection and response • Security, privacy, and product counsel • Trust and safety • Counter - abuse technology • Cloud Customer Care ” 123 Google describes 8 sources how it detects data incidents: • “Automated network and system logs analysis: Automated analysis of network traffic and system access helps identify suspicious, abusive, or unauthorized activity and escalates to security staff. • Testing: The security team actively scans for security threats using penetration tests, quality assurance (QA) measures, intrusion detection, and software security reviews. • Internal code reviews: Source code review discovers hidden vulnerabilities, design flaws, and verifies if key security controls are implemented. • Product - specific tooling and processes: Automated tooling specific to the team function is employed wherever possible to enhance our ability to detect incidents at product level. • Usage anomaly detection: We use layers of machine learning systems to differentiate between safe and anomalous user activity across browsers, devices, application logins, and other usage events. • Data center and workplace services security alerts: Security alerts in data centers scan for incidents that might affect our infrastructure. • Google employees: A Google employee detects an anomaly and reports it. • Google’s vulnerability reward program: Potential technical vulnerabilities in Google - owned browser extensions, mobile, and web applications that affect the confidentiality or integrity of user data are sometimes reported by external security researchers.”

Additionally, in a whitepaper about its Infrastructure Security, Google explains it also creates reports and signals to mitigate DoS attacks and protect against intrusion detection, both network and services based. 124 122 Ibid. 123 Ibid. 124 Google Cloud, Google Infrastructure Security Design Overview, June 2024, URL: https://cloud.google.com/static/docs/security/infrastructure/design/resources/google_infrastru cture_whitepaper_fa.pdf DPIA on Google Cloud Platform public version 11 June 2026 Page 71 of 142 As described in Section 3.3.4 Google did not provide access to any of its own network and system logs , or machine learning tot detect anomalous user activity , to Privacy Company . 5.4 Purposes Google as data controller Google processes two other categories of personal data as independent data controller : the public google cloud Website Data and the personal data necessary to create a Google Account. 125 5.4.1 Purposes google cloud Website Data With regard to the public Website Data, Google displays a banner on the publicly accessible cloud.google.com pages that shows the following 3 purposes : 1.

To deliver services 2. To enhance the quality of services 3. To analyze traffic 5.4.2 Purposes Google Account The CMA does not provide specific purposes for the proce s sing of the Google account that can b e used to create a GCP admin account. An earlier version of this DPIA described the risk that government admins would have to accept Google’s Terms of Service and the (consumer) Privacy Policy during the creation of the Google Account . In view of Google’s explanation that government organisations should follow an offline onboarding process, and can use their own e - mail accounts, this section of the DPIA is no longer relevant. 6. P rocessor or controller This section assesses the data protection roles of Google and government organisations in the context of the tested GCP Services. 6.1 Definitions The GDPR contains definitions of the different roles of parties involved in the processing of data: (joint) controller, processor and sub - processor.

Article 4(7) of the GDPR defines the (joint) controller as: "the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Membe r State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.” Article 26 of the GDPR stipulates that where two or more data controllers jointly determine the purposes and means of a processing, they are joint controllers. Joint controllers must determine their respective responsibilities for compliance with 125 Google objects against the distinction between the purposes in Sections 5.3 and 5.4 because Google considers itself an independent data controller for all data processing mentioned in these two sections . Reply Google to part A of this DPIA, dated 21 March 2025, made accessible to Privacy Company 25 March 2025.

DPIA on Google Cloud Platform public version 11 June 2026 obligations under the GDPR in a transparent manner, especially towards data subjects, in an arrangement between them. Article 4(8) of the GDPR defines a processor as: “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.” A sub processor is another processor engaged by a processor that assists in the processing of personal data on behalf of a data controller. Article 28 GDPR sets out various obligations of processors towards the controllers for whom they process data. Article 28(3) GDPR contains specific obligations for the processor. Such obligations include only processing personal data in accordance with doc umented instructions from the data controller and cooperating with audits by a data controller. Article 28(4) GDPR stipulates that a data processor may use sub processor s to perform specific tasks for the data controller, but only with the prior authorisat ion of the data controller.

When data protection roles are assessed, the formal contractual division of roles is not leading nor decisive. The actual role of a party must primarily be determined on the basis of factual circumstances. 6.2 Data processor and sub processor s 6.2.1 Legal role a s data processor Based on the (new) CMA with the Dutch government, Google will become a data processor for specific personal data in and about the use of the 4 tested services ( Compute Engine , Cloud SQL, Cloud Storage and BigQuery), as well as for the restricted access GCP Admin Console. Formally, through the new CMA Google will be come a data processor for three categories of personal data: Content (but not Feedback) , Account and Diagnostic , Data. The Dutch government instructs Google to only process the personal data for the three agreed purposes (see Section 5.2 above) . Section 12.1.4 contains an assessment if Google also factually behaves as a data processor.

As described in Section 5.3 above, the Dutch government and Google will also agree on a limitative list of agreed compatible purposes for which Google may 'further' process ( some ) personal data in the Account, Diagnostic, Support and restricted access Website Data as controller , when necessary for Google’s legitimate business purposes. 126 Googl e explains it qualifies itself as controller for the Support Data (requests and tickets and communication) , but acts as a data processor when it provides technical support service s . 127 The distinction remains unclear. Th is will be discussed in Section 6.3 below. 126 See footnote 29 . 127 Google reply to the DPIA, 23 October 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 73 of 142 6.2.2 Sub processor s In its publicly available list of sub - processors 128 Google describes three categories of sub - processors: 1. Third party sub processor s, with their affiliates that help provide Google cloud services 2.

Google Group sub processor s 3. Sub processor s for Cloud Identity Services This list is dynamic (may change monthly), but at the bottom of this page Google provides access to earlier versions of this documentation, back in time to 20 June 2017. For each sub processor , Google describes 8 or 9 aspects: 1. Entity name 2. Relevant Google Cloud Platform Service(s) 3. Applicable Cloud Region(s) 4. Activity 5. Country where processing is performed 6. Registered address 7. Country of registration 8. Company number 9. Parent company [always Google in the second category]. Google only describes processing of Content Data (called Customer Data by Google) by these sub processor s (including Content Data accessed for support purposes), but not the other four identified categories of personal data. Google normally does not process the Service Data as processor, and hence, in this global communication Google only addresses access to Customer Data (for which it is a data processor for all of its global Enterprise customers ).

As described in the Update Verification Report on Google Workspace Enterprise (from May 2024), Google has clarified that sub processor s and subsidiaries that are given access to Content Data (Customer Data) also have access to Service Data (Account, Diagnostic, Support and Website Data). Google has explained the limitations of access to Service Data in the dialogue about Google Workspace Enterprise. For support issues, employees can access error logs impacting Customer's projects, account or environment, or Customer's settings and configur ations for the Services, but only in reply to a reported problem. This type of access is out of scope of this DPIA. With regard to maintenance, generally staff only gains access to aggregated data. The probability of such access to personal data by sub processor s in third countries was assessed in the separate DTIA on Google Meet. Google has agreed (but has not provided a timeline) to provide the Dutch government organisations with updated information about the access from sub processor s (and 128 Google Cloud Platform Sub processor s, last modified 14 August 2025 , URL: https://cloud.google.com/terms/ sub processor s .

DPIA on Google Cloud Platform public version 11 June 2026 hired personnel in third countries) to personal data in the Google Cloud Platform, in a similar way as for Workspace. 129 The first category of sub processor s contains third parties that help provide optional services such as technical support , data labelling or voice transcription . For Dutch government customers , based on the applicable Cloud Regions and assuming Dutch government organisations will choose to store personal data within the Netherlands , sub processor s performing technical support are only relevant if the customer procures the (extra) Enhanced or Premium Support Services. In that case, if the customer files a support request, employees of these sub processor s can access personal data (Account, Diagnostic , Website Data and the contents of the support ticket). They can only access the Content Data if the admin consents.

“ The Sub processor does not have access to Customer Data stored or processed by the Services. The Sub processor only has access to Customer Data if Customer explicitly elects to share Customer Data in the course of a support case (e.g. screenshots). ” 130 Privacy Company did not test Enhanced or Premium Support . The second category describes in what countries Google engineers are located, and for what purposes they can access personal data . Some of the se sub processor s can process data from all global GCP customers for purposes such as service maintenance and technical support , other Google group members only perform local data processing, such as Green Box Computing B.V. , responsible for data center operations in the Netherlands. The third category describes sub processor s for Google Cloud Identity, a service out of scope of this DPIA. For this DPIA it is relevant whether customers have meaningful control over the engagement of sub processor s by Google and the processing of their personal data by such sub processor s. Based on the CMA Google will inform customers at least [ confidential ] days prior to engaging a new sub processor .

C ustomers can object to the engagement of a new sub processor , but they can only object by terminating the agreement. 6.2.3 Right to audit Based on the current CMA relating to Google Workspace , SLM Rijk has the right to conduct an audit on Google’s compliance with the agreed data processing terms for all personal data for Workspace . SLM Rijk can exercise that right once a year on behalf of all public entities, customer and education institutions. This right should be extended to include GCP , as the right to audit is an important guarantee for the Dutch governme n t organisations that they can verify the effective data processing, and hence, can factually exercise their role as data controllers. 129 Google (second) reply to part A of this DPIA, dated 21 March 2025, made accessible to Privacy Company 25 March 2025. Google referred to the detailed Workspace information at the URL: https://workspace.google.com/terms/ sub processor s - service - data/ . 130 Idem, top of page, under ‘Technical Support: Customer - initiated technial support’.

DPIA on Google Cloud Platform public version 11 June 2026 Page 75 of 142 6.3 Further processing by Google as authorised data controller Only data controllers may take decisions about the purposes and means of the data processing, including the decisions to process the data for additional purposes. T he Dutch government has authorised Google to 'further' process some personal data for the list of 7 agreed compatible purposes , when necessary. Th e list includes for example Support and Feedback Data. See Section 5.3 above. In reply to this DPIA, Google has explained that it disagrees with the qualification of authorised further processing and asked to include a formal note of this objection every time the word ‘further processing’ is mentioned in this DPIA. 131 According to Google, it acts as independent data controller. However, if that were indeed the case, this DPIA would have to conclude that there are additional high risks due to loss of control over the processing purposes.

If Google were an independent data controller, it could unilaterally change the purposes of th e processing. This , however, is not the case, since the Dutch government and Google agree on a limitative list of purposes for which Google may further process the data it obtains as a result of the processing in its role as data processor. Since this agre ement is included in the (future) CMA for GCP, the purposes cannot be unilaterally changed by Google. The French National Supervisory Authority CNIL has published a useful explanation of how data controllers can allow data processors to process personal data for operations that are necessary for the processor’s own legitimate business purposes. 132 The CNIL explains that a processor may further process data as an independent data controller, provided that the controller has assessed the processing is compatible, and that the controller explicitly authorises the processor in writing to process for these purposes.

The CNIL writes [informally translated by Privacy Company]: “ A data processor may only reuse personal data on its own behalf if such reuse is compatible with the initial processing and if the controller has authorised this processing in writing. (…) The controller may, under the conditions set out below, authorise its processor to reuse the personal data on its own behalf. The processor then becomes the data controller for this new processing. (…) The data controller must determine whether such further processing is compatible with the purpose for which the data were originally collected, if the processing is not based on the data subject's consent or on a specific legal obligation. ” 133 Therefore, the provisions in the CMA about processing for Google’s legitimate business purposes do not prejudice Google’s role as data processor for GCP. 134 6.4 Assessment of Google as independent data controller Additionally, Google acts as an independent data controller for the processing of personal data relating to the visits to its public website s .

131 See footnote 29 . 132 CNIL, Sous - traitants : la réutilisation de données confiées par un responsable de traitement, 12 January 2022, URL : https://www.cnil.fr/fr/sous - traitants - la - reutilisation - de - donnees - confiees - par - un - responsable - de - traitement. 133 Idem. 134 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 from Google about the Google account required to create a GCP admin account, Google is also assumed to be an independent data controller for the Google account. 7. Interests in the D ata P rocessing This paragraph outlines the d i fferent interests of Google and of the Dutch government organisations in general . The interests of the Dutch government organisations may align with the interests of their employees , but this is not always the case. This section does not include an analysis of the fundamental data protection rights and interests of the employee - admins as data subjects.

How their rights relate to the interests of Google and the Dutch government organisations is analysed in part B of this DPIA. 7.1 Interest s of Google Google competes with other big global players with similar offerings such as AWS, Microsoft , IBM, SAP, Oracle and Alibaba . According to estimates from Synergy Research Group, Google had a global market share of 11% in the third quarter of 2024 , while Microsoft Azure was at 20%, and AWS lead with 31%. 135 Figure 27 : Worldwide market shares of cloud infrastructure providers in Q3 2024 136 According to a comparison with AWS and Microsoft Azure, Google ’s main priority is security and compliance with regulations. Google distinguishes itself with tools for big data processing, AI features, and machine learning for advanced analytics and more data - driven insights. 137 Though the providers do not seem to compete heavily on price, u se of GCP may come at a lower cost than use of AWS. 138 As the no. 3 Google has a clear financial interest in increasing its market share. 135 As quoted by Statista, Amazon Maintains Cloud Lead as Microsoft Edges Closer, 1 November 2024, URL: https://www.statista.com/chart/18819/worldwide - market - share - of - leading - cloud - infrastructure - service - providers/ 136 Idem. 137 Medium, AWS vs. Azure vs. Google Cloud: Comparison, Benefits, and Use Cases, 8 August 2023, URL: https://medium.com/@IntelliSoft/aws - vs - azure - vs - google - cloud - comparison - benefits - and - use - cases - fafdd873a77c . 138 Idem.

DPIA on Google Cloud Platform public version 11 June 2026 Page 77 of 142 Like its competitors, Google has strong business ethical interests to compl y with international privacy and security standards . In a world where many government organisations are still hesitant to entrust personal data to a global cloud service provider, Google has taken three measures to increase trust. Firstly, Google has stepped up on its transparency on its disclose of personal data in response to government requests by splitting statistics about disclosures to government authorities between consumer and Enterprise accounts. Secondly, Google offers data residency choices for stored Content Data to customers . Thirdly, Google continues to develop different encryption options, including options for government organisations to manage their own encryption key outside of the Google Cloud. Google provides a lot of documentation to show its compliance with the GDPR .

Google writes that it employs “ security and privacy professionals that include some of the world’s foremost experts in information, application, and network security . ” 139 Google explains that it has evolved its privacy terms based on feedback from customers and regulators. In a whitepaper on Google Cloud , Google explains that it invests in independent verification of security, privacy and compliance controls. “ Some of the key international standards we are audited against are: • ISO 27001 (Information Security Management) • ISO 27017 (Cloud Security) • ISO 27018 (Cloud Privacy) • ISO/IEC 27701 (Privacy - Data Processor) • SOC 2 and SOC 3 reports • NIST 800 - 53 • PCI DSS • CSA Star • GxP ” 140 On Google’s compliance offerings page dedicated to EU customers, Google additionally mentions its verification of compliance with the second level of compliance of the EU Cloud of Conduct and the SWIPO Data Portability Code of Conduct. 141 7.2 Interests of government organisations Dutch government organisations potentially have economic and financial interests in switching from hosting in local government datacentres to hosting of data on cloud servers.

Some of the possible benefits of a switch to cloud VMs are: 1. Increased flexibility , because creating a VM and using a preconfigured database is faster and easier than installing an OS or database on a physical server . Admins can clone a VM with the OS already installed. Developers and 139 Google Cloud, Google Cloud & the General Data Protection Regulation (GDPR), undated, URL: https://cloud.google.com/privacy/gdpr?hl=nl (page last visited 27 January 2025). The FAQ stil refers to Privacy Shield, annulled in July 2020. 140 Google Cloud Whitepaper, Trusting your data with Google Cloud, December 2022, URL: https://services.google.com/fh/files/misc/google_cloud_trust_whitepaper_dec2022.pdf 141 Google Cloud, Compliance Offerings EMEA privacy, URL: https://cloud.google.com/security/compliance/offerings#/regions=EMEA&focusArea=Privacy DPIA on Google Cloud Platform public version 11 June 2026 software testers can create new environments on demand to handle new tasks as they arise. 2.

Cost saving , because organisations may need less staff to manage the infrastructure, and are generally less effective in maximising the number of VMs run on a single physical computer (bare metal server). Google writes: “ Also, you only pay for the resources that you use, and there are no up - front costs .” 142 3. Increased reliability and availability , because it is easy to scale up computing capacity when necessary in the cloud databases , a nd to deploy multiple copies of the same virtual machine to better serve increases in load. Typically, it is much easier with virtualization software to reallocate hardware resources dynamically between one virtual machine and another. Google writes: “ This [scalability of Compute] is useful for businesses that experience sudden increases in traffic, because you can quickly add more instances to handle the increase and remove the instances after they are no longer needed. ” 143 Google adds: “ Google's infrastructure is highly reliable, with a 99.9% uptime guarantee .” 144 4.

Increased security and recovery , because the cloud VM provider has such a wide range of customers that it is able to faster detect new risks than engineers of local data centres. A globally operating cloud provider typically has more security engineers available, and 24/7, to mitigate risks. Additionally, the easy creation of VMs and databases also makes it possible to completely delete a compromised VM and then recreate it from a snapshot of the VM, hastening recovery from malware infections. 5. Easier GDPR compliance . As described in Sections 3.3.1 (authentication logs) and 3.3.2 (audit logs ), most cloud providers offer extensive logging possibilities that enable government organisations to regularly inspect the files for unauthorised access to personal data, and detect possible data breaches. Additionally, with VMs, because they are isolated from each other, it is easier to create independent user environments, for example a separate environment for software testing.

Government organisations have a strong interest in transparency, to be able to compare different services, forecast costs, to easily create an overview of different technical capacities and to assess the different privacy and security risks, including the risks of unlawful further processing through access by authorities in foreign countries, malicious state actors and hackers. Additionally, government organisations need to prevent the possibility of ‘legacy’ and ‘vendor lock - in’. Government organisations need to have the organisational and technical ability to easily transfer their data to other suppliers over time. Many Dutch government organisations use services from Microsoft. It may make se nse to choose a different provider for cloud infrastructure services , also in view of the risk that Microsoft is likely to attract more threats due to its near monopoly for Office services. The Dutch government Audit Office has explicitly warned the Dutch government about this risk. 145 Not only nearly the entire central government uses M365 cloud services, but also many foreign governments and companies worldwide.

142 Google, Compute Engine overview, URL: https://cloud.google.com/compute/docs/overview 143 Idem. 144 Idem. 145 Auditdienst Rijk, Onderzoeksrapport Bevindingen onderzoeksopdracht 'Evaluatie public cloudbeleid Rijksoverheid' , 3 juli 2024, URL: https://www.tweedekamer.nl/downloads/document?id=2024D38837 DPIA on Google Cloud Platform public version 11 June 2026 Page 79 of 142 large collection of confidential data that gives state actors an important motive for developing attack capabilities on M365. 146 Finally, it is in the government organisations’ interest that the platform is easy to use, so that employees who have little knowledge of IT can work with it. From a cost saving interest, it is important that the platform offers many good standard options, so that the government organisation does not need to develop much of its own functionality. 7.3 Joint interests The interests of Google and the Dutch government align when it comes to the protection of the integrity, availability, and reliability of Content Data in the cloud VM servers, databases and storage , as well as high scalability and flexibility of the deployment of the cloud services .

The interests of Google and the Dutch government also align with regard to the Cloud Policy of the Dutch government. Based on this policy 147 , and implementation guidance 148 Dutch government organisations are allowed to use public cloud services , based on a risk assessment, compliance with BIO and in accordance with C2000 criteria for risks regarding espionage, influencing or sabotage by state actors or other third parties. 149 According to the Cyber Security Assessment Netherlands 2024 : “ state actors are intensifying their cyber activities and broadening their - capabilities. The pace and complexity of state cyber campaigns is being stepped up. They are also deploying hacker groups to carry out digital attacks. ” 150 As part of the shared security interest, Google’s creation and use of ne twork metadata samples and webserver access log files to detect security risk s also concurs with the interests of the Dutch government organisations, provided that Google performs the monitoring based on aggregated data , and does not store the personal data in these logs longer than strictly necessary for these security purposes.

The interests of Google and Dutch government organisations do not align when it comes to strategical issues of sovereignty and autonomy. The three most popular hyperscalers that offer combined Infrastructure, Software and Platform services are all based in the USA, and their use always involves international data transfers to data centres and engineers in third countries. 146 Idem, p. 5. 147 Brief van de Staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties, Rijksbreed cloudbeleid 2022, 29 augustus 2022, URL: https://open.overheid.nl/documenten/ronl - a79331dc7c088f2cb6259f591c3b4f2fbcc9b5f1/pdf . 148 Rijksoverheid, Implementatiekader risicoafweging cloudgebruik, versie 1.1, 5 januari 2023, URL: https://open.overheid.nl/documenten/ronl - 734f947ec6465e4f75a56bed82fe64a1135f71a8/pdf . 149 Kamerstukken II 2018/19, 25 124, nr. 96. 150 NCTV, News item, Cybersecurity Assessment Netherlands 2024, URL: https://english.nctv.nl/documents/publications/2024/10/28/cybersecurity - assessment - netherlands - 2024 .

DPIA on Google Cloud Platform public version 11 June 2026 The Dutch parliament has initiated a n initiative about digital sovereignty 151 and the Algemene Rekenkamer has published a report about public cloud usage . 152 The Dutch government replied to the parliamentary initiative with the commitment to tighten requirements for the use of public cloud services, with frameworks for digital autonomy. In the translation of Privacy Company: “ This has the consequence that fewer central government digital services may be developed in the public cloud, depending on the interests to be protected. For such services it s hould be investigated whether a sovereign government cloud can be set up . ” 153 On 4 July 2025, the Dutch government published the ‘national digitisation strategy’ . This includes exploring the possibility of creating a government - wide sovereign cloud service in collaboration with existing government service providers and the market , as well as a central market place for cloud technology for the Dutch government. 154 8.

Transfer of personal data outside of the EU Google publishes a list of cloud services with Data Residency choices for admins. 155 This list includes Compute Engine (VM), BigQuery and Cloud SQL . Google also publishes a second list of services for which ‘Assured Workloads’ is available. The difference with the regular data residency choices is that Assured Workloads also guarantees the geolocation for the data in use (not only stored) , and prevents access by Google personnel outside of the customer selected region. Google writes: “ in addition to Google's data location commitments under that Section 1 (Data Location), Google will process Customer Data in use by the configured Service (not including in any user interface) only within the country of the selected Region or within the country or countries of the selected Multi - Region (as applicable). If the selected Region or Multi - Region is located in the European Union, Google will proc ess Customer Data in use by the configured Service only within the European Union (but not necessaril y in the same country).

Further, Assured Workloads enables Customer to prevent Google personnel located outside the Customer - selected Region or Multi - Region from accessing 151 Six Dijkstra en Kathmann, Wolken aan de horizon, URL: https://www.rijksoverheid.nl/documenten/publicaties/2024/06/18/initiatiefnota - wolken - aan - de - horizon 152 Algemene Rekenkamer, Het Rijk in de Cloud, Donkere wolken pakken samen, 15 januari 2025, URL: https://www.tweedekamer.nl/downloads/document?id=2025D01084 153 Kamerbrief staatsecretaris en minister van Economische Zaken over de Initiatiefnota ‘Wolken aan de horizon’ , 17 January 2025, p . 1 - 2, URL: https://open.overheid.nl/documenten/71103a99 - b696 - 42fd - b34a - c83f979b3201/file . 154 In Dutch only: Digitale Overheid, De Nederlandse Digitaliseringsstrategie Samen versnellen, 26 November 2025, URL: https://www.digitaleoverheid.nl/nederlandse - digitaliseringsstrategie - nds/6 - prioriteiten - voor - een - overheid/prioriteit - 1 - cloud/ . 155 Google Cloud Platform Services with Data Residency, undated, URL: https://cloud.google.com/terms/data - residency (page last visited 27 January 2025).

DPIA on Google Cloud Platform public version 11 June 2026 Page 81 of 142 Customer Data in an Assured Workloads environment, as specified in the Documentation . ” [underlining added by Privacy Company] 156 Privacy Company could not find a definition of what Google means with ‘in use’, if this includes for example back - ups and/or (some) logs. Both options allow customers to geographically limit the processing of their Content Data to within the EU availability zone . However, Google does not offer such a geolocation choice for the other categories of personal data (Account, Diagnostic, Support and restricted Website Data). Google can transfer these personal data from its EU customers to the USA , and via sub processor s to third countries . Mitigating measure Google • [ CONFIDENTIAL ] 8.1 Available zones and regions for Content Data for Dutch government customers Google provides an overview of t he locations of Google Cloud Platform data centers . 157 .

Google works with Regions , independent geographic areas that consist of zones . Google has 11 Regions in the EU. Each Google Region consists of a minimum of three, isolated, and physically separate zones, housed in three or more physical data centers. Customers of Google ’s Compute Engine, Cloud SQL, Cloud Storage and BigQuery services can decide for themselves within which availability zone ( geographic area) they want to store their Content D ata. Figure 28 provides a map of geographic regions, Figure 29 sums up the available zones and regions. 156 Google Cloud Service Terms, section 33 Assured Workloads, URL: https://cloud.google.com/terms/service - terms . 157 Google Cloud, Cloud Locations, undated, URL: https://cloud.google.com/about/locations/ (page last visited 27 January 2025). DPIA on Google Cloud Platform public version 11 June 2026 Figure 28 : Google available geographic regions 158 Figure 29 : Google table s of regions , countries and direct connect locations 159 For Dutch government customers, the most logical storage location is europe west=4, for processing in a Dutch data centre.

This choice was available for the VM and the MySQL database, but not for the cloud storage (only multiple locations in the EU). During testing Privacy Company did not see an option to select Europe - West - 4 for Cloud Storage. Therefore, it selected multiple locations in the EU. In reply to this DPIA Google mentioned that such an option does exist. For users to see the west - 4 region they should select the ‘Region’ and then se lect the desired location (i.e. eu - west - 4). 160 158 Idem, s creenshot made 27 January 2025. 159 Idem, screenshot made 27 January 2025. 160 G oogle reply to the DPIA, 23 October 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 83 of 142 Figure 30 : Location of Cloud SQL i nstance in the test set - up Figure 31 : Location of Compute Engine in the test set - up DPIA on Google Cloud Platform public version 11 June 2026 Figure 32 : Cloud Storage hosted in the EU Figure 33 : Location of BigQuery data for fictive complaint data in the Netherlands 8.2 Transfers of other categories of personal data Google does not offer any data residency choices for three of the four categories of personal data (Account, Diagnostic, and restricted access Website Data).

As described DPIA on Google Cloud Platform public version 11 June 2026 Page 85 of 142 in Section 4.2 Google’s encryption services and access controls only apply to Content Data. As replied by Google, [CONFIDENTIAL] 161 Google explicitly describes that access to metadata about queries in BigQuery is not covered by Access Transparency and Access Approval, since the pathway is read - only. However, Google does offer customers of the (extra) Enhanced and Premium Support services the option to specify the geolocations from which Google may provide support. Google explains: “Assured Support is a value - added service to Premium or Enhanced Support to ensure only Google support personnel meeting specific geographical locations and personnel conditions support their workload when raising a support case or needing technical assistance. ” 162 This service was not tested for this DPIA . Whenever Google mentions ‘Technical Support’ as activity, this only refers to customer - initiated support requests .

These types of transfers are thus also out of scope of this DPIA. In the context of Google Workspace Enterprise, Google explained that Diagnostic Data are generated in the Google Region where the service is used, and depending on the scope of the customer's interactions with Google Offerings, may be stored in or accessed from multiple countries, including the United State s, in case of maintenance or troubleshooting . Website Data are generated in the USA, while Account Data are always transferred to the USA. Such details are not publicly available for Google’s cloud platfo rm services. In the context of the DPIA on Google Workspace Enterprise, Google explained that personal data can be accessed by Google Group Sub processor s , when authorized, for 2 purposes: (1) service and infrastructure maintenance and (2) troubleshooting of all kinds of technical issues, releasing new code, making configuration changes or emergency maintenance purposes (besides mitigation of customer - initi ated support requests, out of scope of this DPIA).

This DPIA assumes that this same access logic applies to the three relevant categories of data (Account, Diagnostic and Website Data) . The relevant data transfers for Dutch government customers are selected from Google’s list of sub processor s for Cloud Services, based on use of one or more of the tested GCP - services (column 2), type of activity (column 4, but excluding all parties that offer Technical Support Services) and if the Applicable Cloud Region(s) is set to the Netherlands, or to all regions. 163 161 Google reply to questions SLM , 21 March 2025. Confirmed 162 Google Cloud Documentation, Assured Workloads, Assured Support, undated, URL : https://cloud.google.com/security/products/assured - workloads?hl=nl (page last visited 22 April 2025). 163 Google Cloud Platform Sub processor s, last modified 9 December 2024, URL: https://cloud.google.com/terms/ sub processor s . The p age resulted in a 404 on 21 April 2025, but a capture from 5 April 2025 is still available via the Internet Archive, URL: https://web.archive.org/web/20250405090343/https://cloud.google.com/terms/ sub processor s DPIA on Google Cloud Platform public version 11 June 2026 Additionally, Google engineers may need to access Content Data.

In Google’s description of the data processing by Google Group sub processor s, Google explains that engineers may require access to Customer Data to remediate technical issues: “Service Maintenance: Software and systems engineering, maintenance and troubleshooting. In the course of performing this activity the Sub processor may require limited, authorized access to Customer Data e.g. to remediate technical issues.” 164 Google does not narrow down the transfers to countries where the processing is performed if a sub processor operates in multiple countries. Therefore, sub processor s engaged to perform the activities ‘managing the hosting environment’ and ‘data center operations’ are also included in the list. Google mentions these names of activities in the fourth column of its table. This results in th e data transfers to the USA and to 13 third countries . Table 1 : Overview of relevant data transfers for Dutch government customers of the tested services Sub processor Activity Transfers to the USA and/or third countries Eviden USA, Inc. (formerly known as Atos) Managing Hosting environment Bra s il, Singapore, USA Google Australia Pty Ltd. Service Maintenance Australia Google Brasil Internet LTDA.

Service Maintenance Brasil Google Chile Limitada Service Maintenance Chile Inversiones y Servicios Dataluna Limitada Data Center Operations Chile Allied Trade Holdings Limited Data Center Operations Hong Kong Google Cloud India Private Limited Service Maintenance India Raiden Infotech India Private Limited Data Center Operations, Service Maintenance India PT Google Cloud Indonesia Data Center Operations, Service Maintenance India Google Malaysia Sdn. Bhd. Service Maintenance Malaysia Google Cloud Mexico, S. de R.L. de C.V. Service Maintenance Mexico 164 Google Cloud Platform Sub processor s, last modified 27 March 2025 , URL: https://cloud.google.com/terms/ sub processor s?e=0&hl=en . DPIA on Google Cloud Platform public version 11 June 2026 Page 87 of 142 Opal Computing, S. de R.L. de C.V. Data Center Operations Mexico GOC Philippines, Inc. Service Maintenance Philippines Google Cloud Qatar QFZ LLC Data Center Operations Quatar Google Cloud Arabia Limited Data Center Operations Saudi Arabia Google Asia Pacific Pte Ltd. Data Center Operations, Service Maintenance Singapore Google Cloud South Africa (Pty) Limited Data Center Operations South Africa Charter Investments Limited Data Center Operations Taiwan Google Taiwan Limited Service Maintenance Taiwan Apigee Corporation Service Maintenance United States Design, LLC Data Center Operations United States Firebase, Inc. Service Maintenance United States GOC International LLC Service Maintenance United States Google LLC Data Center Operations Service Maintenance United States Looker Data Sciences, Inc. Service Maintenance United States Orbitera Inc. Service Maintenance United States 8.3 GDPR rules for transfers of personal data The GDPR contains specific rules for the transfer of personal data to countries outside the European Economic Area (EEA).

In principle, personal data may only be systematically transferred to countries outside the EEA if the European Commission has taken a so - called adequacy decision or if the exporting organisation can provide approp riate safeguards . Art. 46 of the GDPR offers multiple ways to provide such safegua r ds. Since 10 July 2023, based on the (third) adequacy decision from the European Commission for the USA, the USA no longer have to be treated as a third country, for participants to the EU US Data Privacy Framework. SLM Rijk has been informed by Google that it has self - certified as participant to the EU US Data Privacy Framework (DPF). 165 However, i n view of measures taken and announced by the new president of the United States in January 2025 , the Dutch government has to seriously consider the probability that the EU US Data Privacy Framework will be annulled. The consequences and political follow - up of (a possible annulment of) the adequacy decision for the USA are discussed in Section 8.3.2 below.

The two most commonly used instruments by US based multinationals for transfers to the USA absent an adequacy decision are Binding Corporate Rules or the EU Standard Contractual Clauses (SCC s ). Section 8.3.3 below addresses Google’s use of the SCC s . 165 Data Privacy Framework list of active participants, search ‘Google LLC’, URL: https://www.dataprivacyframework.gov/list DPIA on Google Cloud Platform public version 11 June 2026 8.3.1 Adequacy decisions An adequacy decision means that the country or category of organisations has a level of protection comparable to that applied within the EEA. On 10 July 2023, the European Commission issued an adequacy decision for participants in the USA to the EU US Data Privacy Framework. On 3 September 2025 the European Court of Justice (part of the Court of Justice of the European Union) confirmed the validity of this decision based on the circumstances in the USA when the framework agreement was signed.

The French member of parliament Philippe Latombe had asked the court (in 2023 already) to annul the decision. 166 Currently, there are adequacy decisions with respect to Andorra, Argentina, Canada (commercial organisations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, the United Kingdom under the GDPR and t he LED, the United States (commercial organisations participating in the EU - US Data Privacy Framework) and Uruguay. With the exception of the United Kingdom, these adequacy decisions do not cover data exchanges in the law enforcement sector . These are gove rned by the Law Enforcement Directive (Article 36 of Directive (EU) 2016/680). 167 8.3.2 Possible end of Adequacy D ecision for the USA The adequacy decision for the USA is based on an Executive Order from the previous president of the United States (EOP) . On 7 October 2022, Biden signed EOP 14086 with new binding safeguards for the data collection by US intelligence agencies, and introducing a new redress procedure. 168 Following this EOP, the European Commission prepared a new adequacy decision for the USA 169 that entered into force 10 July 2023.

applies Directive 2016/680 Art. 36

Two key issues that were solved by the commitments in this EOP were the lack of privacy restrictions to mass surveillance, and lack of independent redress in case of complaints of EU citizens about the personal data processing. The USA agreed to let the (existing congressional) Privacy and Civil Liberties Oversight Board certify annually if the new Data Protection Review Court adequately fulfilled its investigation and judgment tasks. On 22 January 2025 President Trump has asked the 3 democrat members of this 5 person board to resign the next day , thus rendering this board powerless to take decisions. 170 The PCLOB website currently lists only one board member. 171 This new circumstance was not part of the facts assessed by the European Court of Justice in the Latombe case quoted above . 166 ECJ Case T - 553/23, Latombe v Commission, URL: https://curia.europa.eu/juris/document/document.jsf?docid=279601&doclang=EN 167 European Commission, Adequacy decisions, URL: https://commission.europa.eu/law/law - topic/data - protection/international - dimension - data - protection/adequacy - decisions_en (p age last visited 2 7 January 2025) . 168 US Department of State, Executive Order 14086 – Policy and Procedures, 3 July 2023, URL: https://www.state.gov/executive - order - 14086 - policy - and - procedures/ 169 Press release European Commission, Commercial sector: launch of the adoption procedure for a draft adequacy decision on the EU - U.S.

Data Privacy Framework, 12 December 2022, https://commission.europa.eu/law/law - topic/data - protection/international - dimension - data - protection/eu - us - data - transfers_en . 170 New York Times, Trump Seeks to Paralyze Independent Privacy and Civil Liberties Watchdog , 22 January 2025, URL: https://www.nytimes.com/2025/01/22/us/trump - privacy - civil - liberties - oversight - board.html 171 https://www.pclob.gov/Board/Index . DPIA on Google Cloud Platform public version 11 June 2026 Page 89 of 142 H is first ground of appeal is the rejection of his complaint about the non - functioning of PCLOB. 172 If Trump revo kes EOP 14086 from Biden (or has already secretly revoked 173 ) , and hence, removes the privacy restrictions for mass surveillan ce , the conclusions from the European Court of Justice in Schrems - II revive, that the restrictions on privacy arising from the U.S. regulations are insufficiently defined and disproportionate and therefore constitute too great an invasion of privacy. 8.3.3 Standard Contractual Clauses Personal data may be transferred from the EEA to third countries outside of the EEA using Standard Contractual Clauses (SCC s , also known as EU model clauses) .

These clauses (hereinafter: SCC s ) contractually ensure a high level of protection. Google uses the SCC drafted by the European Commission in June 2021. 174 As part of the data processing agreement with the Dutch government t he scope of the SCC i s expanded to include the Account, Diagnostic Data, Support and restricted Website Data. Dutch government customers (only) contract with Google Cloud EMEA Limited , a Dublin - based Google entity. Although the European Court of Justice in Schrems - II recognizes the validity of the decision of the European Commission with which it adopted the SCC, and data transfers on the basis of the SCC are therefore still permitted in principle, this validity cannot be assumed for systematic transfers of personal data to the United States if they are no longer deemed to offer adequate data protection for personal data from EU customers . The ECJ clarifies that o rganisations cannot just rely on the SCC if they transfer data to a third country (different from the current ‘adequate’ status of the USA) .

They also have to assess if the recipient country provides an adequate level of data protection as defined in EU law. Article 46(1) of the General Data Protection Regulation (GDPR) explains that this means that data subjects must have adequate safeguards, enforceable rights and effec tive legal remedies at their disposal. Whether this is the case, according to the Court, must be determined by the data controllers and cloud providers themselves. The Court writes: “The assessment required for that purpose in the context of such a transfer must, in particular, take into consideration both the contractual clauses agreed between the controller or processor established in the European Union and the recipient of the tran sfer established in the third country concerned and, as 172 See: https://eur - lex.europa.eu/eli/C/2025/6610/oj/eng . The question of whether the Court will hear this case is still pending, URL: https://infocuria.curia.europa.eu/tabs/affair?lang=EN&usualName=Latombe+v+Commission&s earchTerm=”Latombe+v+Commissiom ” 173 Tal Feldman, Schrödinger’s Executive Order: Could Executive - Made Intelligence Law Be Secretly Rescinded?

In Yale Journal on Regulation, 30 October 2025, https://www.yalejreg.com/nc/schrodingers - executive - order - could - executive - made - intelligence - law - be - secretly - rescinded - by - tal - feldman/ . 174 Google publishes the different SCCs (depending on Google’s role) at https://cloud.google.com/terms/sccs?hl=en DPIA on Google Cloud Platform public version 11 June 2026 regards any access by the public authorities of that third country to the personal data transferred, the relevant aspects of the legal system of that third country. As regards the latter, the factors to be taken into consideration in the context of Article 46 of that regulation correspond to those set out, in a non - exhaustive manner, in Article 45(2) of that regulation.” 175 In addition to these specific surveillance powers in FISA 702 and with National Security Letters , the USA legal regime enables law enforcement authorities and secret services to compel electronic communications services providers or remote computing service providers (such as cloud providers) that operate in the US to disclose personal data stored ou tside of the US.

This includes disclosure of data from European customers stored in EU data centres. The US CLOUD Act ( Clarifying Lawful Overseas Use of Data ) was specifically designed to obtain access to data stored in data centres in the EU. This act extends the jurisdiction of North American courts to all data under the control of companies operating in the USA, even if those data are stored in data centres outside the territory of the United States. In its whitepaper about government requests for Cloud Customer Data, Google explains th at (different from FISA 702 and National Security Letters) it can oppose requests under the US CLOUD Act: “ In addition, cloud providers can challenge a U.S. government data request on the basis of conflict of law related to a qualifying foreign government, provided the foreign government’s law allows for a reciprocal right to challenge in the event of a request that conflicts with U.S. law ” 176 As explained by the EDPB and the European Data Protection Supervisor (EDPS) in their opinion on the CLOUD Act to the LIBE Committee of the European Parliament, transfers of personal data from the EU must comply with the Articles 6 (lawfulness of processing) and 49 (derogations for specific situations) of the GDPR.

In case of an order based on the US CLOUD Act, the disclosure and transfer can only be valid if recognised by an international agreement between the EU and the USA. The EDPB and EDPS write: " Unless a US CLOUD Act warrant is recognised or made enforceable on the basis of an international agreement, and therefore can be recognised as a legal obligation, as per Article 6(1)(c) GDPR, the lawfulness of such processing cannot be ascertained, without prejudice to exceptional circumstances where processing is necessary in order to protect the vital interests of the data subject on the basis of Article 6(1)(d) read in conjunction with Article 49(1)(f). " 177 In their cover letter, the data protection authorities emphasise 175 ECJ, Schrems - II, par. 104. 176 Google Cloud Whitepaper, Government Requests for Cloud Customer Data, February 2022, p . 5 , URL: https://services.google.com/fh/files/blogs/government_access_technical_whitepaper.pdf 177 Annex EDPB and EDPS joint response to US CLOUD Act, 10 July 2019, p. 8.

URL: https://edpb.europa.eu/sites/default/files/files/file2/edpb_edps_joint_response_us_cloudact_a nnex.pdf . DPIA on Google Cloud Platform public version 11 June 2026 Page 91 of 142 “ the urgent need for a new generation of MLATs to be implemented, allowing for a much faster and secure processing of requests in practice. In order to provide a much better level of data protection, such updated MLATs should contain relevant and strong dat a protection safeguards such as, for example, guarantees based on the principles of proportionality and data minimisation. ” 178 The existing MLAT between the EU and the USA from 2003 and the umbrella agreement from 2016 on law enforcement personal data protection applies to collaboration between law enforcement bodies, not to orders from law enforcement directly aimed at companies. 179 Additionally, the data protection authorities refer to the ongoing negotiations since 2019 about an international agreement between the EU and the US on cross - border access to electronic evidence for judicial cooperation in criminal matters and negotiating directives. 180 Negotiations with the USA are still ongoing. 181 Only the UK has so far signed a specific agreement with the USA for the CLOUD Act.

Negotiations between the EU and the US about updated MLATs did not produce any results yet. 8.3.4 Data Transfer Impact Assessment As long as the adequacy decision for the USA is not annulled, Dutch government organisations can rely on the EU US DPF, or alternatively, on the SCCs with Google for transfers to the USA , without having to take extra data protection measures . SLM Rijk has recently published an extensive analysis from law firm Greenberg Traurig (GT) about the applicable US law an d the probability of 1) sudden unavailability due to sanction decisions and 2) compelled disclosure of data to US authorities. The advice is for the specific EU sovereign cloud offer of another US American company (AWS), but the legal analysis is equally relevant for Google and other US American suppliers. 182 Even though GT assesses the likelihood of disclosure of the metadata (Diagnostic, Support, Website Data) in the range from unlikely to improbable, the risk is not zero.

SLM Rijk concludes that the occurrence of these risks cannot be excluded, and hence the offer does not grant the Dutch government full sovereignty. 183 178 EDPB - EDPS Joint Response to the LIBE Committee on the impact of the US Cloud Act on the European legal framework for personal data protection, URL: https://edpb.europa.eu/sites/default/files/files/file1/edpb_edps_joint_response_us_cloudact_c overletter.pdf . 179 EU - US agreement on (law enforcement) personal data protection https://eur - lex.europa.eu/EN/legal - content/summary/eu - us - agreement - on - personal - data - protection.html . 180 Council Decision authorising the opening of negotiations, 6 June 2019, URL: https://data.consilium.europa.eu/doc/document/ST - 10128 - 2019 - INIT/en/pdf and https://data.consilium.europa.eu/doc/document/ST - 10128 - 2019 - ADD - 1/en/pdf . 181 European Commission , E - evidence - cross - border access to electronic evidence, URL: https://commission.europa.eu/law/cross - border - cases/judicial - cooperation/types - judicial - cooperation/e - evidence - cross - border - access - electronic - evidence_en (last visited 30 September 2025). 182 SLM Rijk, Onderzoeksrapport AWS ESC, 26 February 2026, URL: https://www.rijksoverheid.nl/documenten/rapporten/2026/02/26/onderzoeksrapport - aws - esc 183 Memo SLM Rijk (in Dutch) about the GT analysis, 24 February 2026, URL: https://open.overheid.nl/documenten/5e0e9f2e - 1fe7 - 48f8 - bed8 - 974f055d65dd/file DPIA on Google Cloud Platform public version 11 June 2026 I f the adequacy decision is annulled, Dutch government organisations will have to perform a Data Transfer Impact Assessment (DTIA) , but not limited to the risks of (un)lawful access 184 by government authorities in the USA.

Similar risks may occur in the 13 third countries in which personnel hired by Google sub processor s can incidentally and structurally access (some) Account, Diagnostic and restricted access Website Data. See Section 8.2 above. If all personal data were exclusively processed and stored in the EU, performance of a DTIA would not be necessary to assess the probability of a disclosure order from a foreign government authority that exercised cross - boundary jurisdiction. [CONFIDENTIAL] . The EDPS has explained in its decision about Cisco Webex that the mere risk of an order for compelled disclosure for data stored in the EU cannot be qualified as a data transfer: “ However, in the EDPS opinion, the mere risk that remote access by third country entities to data processed in the EEA may take place, does not constitute a transfer subjected to Chapter V of the Regulation. The EDPS considers that transfers resulting from unauthorised access by third country entities, which are merely potential and in no way foreseeable in light of the content or purpose of a contract or another stable relationship between the parties, do not fall under the scope of Chapter V of the Regulation.

The unlikely and unplanned character of such risks of such unauthorised access renders them unsuitable to be ex ante subjected to regime of Chapter V of the Regulation. It follows that for such potentia l and unplanned transfers a transfer tool under that Chapter is not required [underlining added by Privacy Company] . ” 185 This reasoning was confirmed by the European Court of Justice in January 2025. 186 The court reasons: “While it is indeed the case that access by the authorities of a third country, under the legislation of that country, to personal data processed in the EEA constitutes a transfer of personal data to a third country, within the meaning of Article 46 of Regulation 2018/1725, the fact remain s that it has not been established that any such access took place in this instance. The applicant has neither demonstrated nor claimed that any of his personal data were transmitted to the US authorities, nor has he demonstrated or claimed that a request was made by those authorities in respect of the data that were transferred to that Amazon CloudFront server in Munich.

applies Regulation 2018/1725 Art. 46

Accordingly, the applicant’s argument does not relate to a direct infringement of the provisions of Chapter V of Regulation 2018/1725, but only to the risk of such 184 Though for Google compliance with government requests could be lawful, for the Dutch government such access by a government authority in a third country would be unlawful access, in breach of the GDPR. 185 EDPS Decision on the Court of Justice of the EU’s request to authorise the contractual clauses between the Court of Justice of the EU and Cisco Systems Inc. for transfers of personal data in the Court’s use of Cisco Webex and related services 13 July 2023 (Case 2023 - 0367), par 34 and 35, URL: https://www.edps.europa.eu/system/files/2023 - 07/2023 - 07 - 13 - edps - cjeu - cisco - decision_en.pdf . 186 ECJ, Case T - 354/22, ECLI:EU:T:2025:4, Thomas Bindl v. European Commission, 8 January 2025, paras 132 - 135. DPIA on Google Cloud Platform public version 11 June 2026 Page 93 of 142 an infringement, should AWS EMEA, because of its status as a subsidiary of a US undertaking, be unable to object to a request from the US authorities concerning access to data stored in servers located within the EEA.

As it is, the mere risk of access to personal data by a third country cannot amount to a transfer of data, within the meaning of Article 46 of Regulation 2018/1725 , as interpreted in paragraph 93 above, since it has not been demonstrated that the applicant’s personal data were transmitted or otherwise made available to a recipient established in a third country. In other words, the risk of an infringement of Article 46 cannot be treated as being akin to a direct infringement of that provision [ underlining a dded by Privacy Company].” 187 In the summer of 2024 SLM Rijk performed a Data Transfer Impact Assessment (DTIA) for the use of Google Meet (the videoconferencing tool in Google Workspace Enterprise ) . The DTIA contains an elaborate calculation of the probability of access in a third country in relation to the impact of unauthorised access on the data subject. To perform a specific DTIA, the EDPB recommends taking six steps. 188 These steps are not repeated here, but some highlights are mentioned that are relevant to assess the risks for organisations that want to use the tested four GCP - services .

applies Regulation 2018/1725 Art. 46

The risk assessment must include: • The relevant laws • The purposes for which the data are processed • The categories of transferred data and their sensitiveness • Whether the data will be stored in the third country or whether there is remote access to data stored within the EU/EEA • Role of the parties (public/private, processor/controller) • All actors, including sub processor s • The format of the data • Possibility of onward transfers 189 Though contested by the Dutch DPA in a decision about the use of Google Analytics 190 , the EDPB Recommendations on measures to supplement transfer tools do allow for a risk - based approach in a DTIA. The EDPB writes: "You may decide to proceed with the transfer without being required to implement supplementary measures, if you consider that you have no reason to believe that relevant and problematic legislation will be applied, in practice, to your transferred data and /or importer". 191 187 Idem. 188 EDPB, Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, Version 2.0, Adopted on 18 June 2021, URL: https://edpb.europa.eu/system/files/2021 - 06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf 189 Idem, p. 15. 190 Decision Autoriteit Persoonsgegevens published by GDPRhub.eu to ‘reprimand’ Takeaway Group B.V, 20 August 2024, URL: https://gdprhub.eu/images/e/eb/2024.08.20_ - _Courtesy_translation_ - _redacted.pdf , 191 EDPB, Recommendations 01/2020, Version 2.0, par. 43.3.

DPIA on Google Cloud Platform public version 11 June 2026 This means data controller s can take into account the amount of received and/or honoured requests and orders. The EDPB recommends reading the transparency reports from the importing organisation. However, " Documented practical experience of the importer with relevant prior instances of requests " alone cannot be relied on. 192 Google publishes statistics about government disclosure requests in three types of semi - annual transparency reports: 1. Disclosure of consumer data 193 , 2. Disclosure of Enterprise data 194 3. Disclos ure via United States national security requests 195 . (Regular) Disclosure Enterprise data According to Google’s public transparency reporting Google complied with 3 regular (contestable) requests from courts or government agencies for data from Dutch Enterprise customers between July 2019 and June 2024. Google does not specify the country from which these requests originated, (which could also be the Netherlands), or the type of customer (business or government customers).

Google does not specify if this includes orders based on the US Cloud Act , for data stored in a data centre in the Netherlan ds. However, in reply to a question from SLM to specify disclosures related to the tested GCP - services , Google assured it has not disclosed any personal data from Dutch public sector customers to law enforcement agencies in the 13 identified third countries and the USA: “ With respect to the 4 assessed GCP - services only, we confirm that, in the past 2 years, we have not disclosed any Customer Data or Service Data belonging to public sector enterprise customers located in the Netherlands in response to requests from law enforcement agencies (such as requests made under warrant or subpoena) based in Australia, Brazil, Chile, Hong Kong, India, Malaysia, Mexico, Philippines, Qatar, Saudi Arabia, Singapore, South Africa, Taiwan or the USA [ underlining added by Privacy Company] . ” 196 Google wrote in its 2022 Whitepaper on government requests for cloud customer data that the number of Enterprise Cloud - related requests was extremely low compared to its Enterprise Cloud customer base, “ and therefore that the likelihood of Enterprise Cloud customer data being affected by these types of requests is low. ” 197 Disclosure to secret services The Google Meet DTIA did not set t he probability of unauthorised access to zero, since Google did (and does) not disclose statistics about disclosure to security services/intelligence agencies in the USA or the third countries. 192 Idem, para 47. 193 Google Transparency Report, Requests for end user information, URL: https://transparencyreport.google.com/user - data/overview 194 Google, Enterprise cloud requests for customer information, URL: https://transparencyreport.google.com/user - data/enterprise 195 Google, United States national security requests for user information, URL: https://transparencyreport.google.com/user - data/us - national - security 196 Google reply to questions SLM , 21 March 2025 . 197 Google Cloud whitepaper, Government Requests for Cloud Customer Data, February 2022, p. 8.

DPIA on Google Cloud Platform public version 11 June 2026 Page 95 of 142 By law, cloud providers may only report t he information about disclosures of content and non - content data to US American secret services under FISA and via National Security Letter s in aggregate, in ranges of 500 . Google does not distinguish between disclosure of consumer and Enterprise data to secret services . The statistics are also global, not split in countries where the customers reside. In the year 2023 Google was asked to provide non - content information under FISA about 65 . 0 0 0 to 65 . 498 accounts, content data under FISA about 233.000 to 233.998 accounts and contact data about 4.000 to 4.998 accounts with a National Security Letter. Because of the lack of specific information relating to Dutch public sector customers, i t i s impossible to estimate the probability for Dutch government customers that secret services will order Google to provide access to their personal data .

However, in reply to a series of questions about the probability of forced disclosure of personal data from Dutch government organisations to security services by engineers located in the 13 identified third countries, Google replied: “ Following internal review, and with respect to Google service maintenance engineers supporting the 4 assessed GCP - services from the 13 countries you have listed, we have identified one instance of an engineer - located in India - accessing Service Data (but not Customer Data) belonging to a public sector enterprise customer located in the Netherlands in the past two years. For clarity, this was a legitimate access for debugging purposes in accordance with our contractual arrangements [ underlining added by Privacy Company].” 198 Additionally, Google described the measures it has taken to prevent access to personal data by its engineers: Google engineers, located in the 13 identified countries, can incidentally be tasked to look at problems from Dutch customers with the tested 4 GCP - services , but they cannot 'search' for any customers' personal data, including Diagnostic Data.

Access is entirely dependent on the specific activity they need to perform and only occurs where absolutely necessary to e.g. address the specific technical issue they are investigating. Google has taken many access control measures to control access to the data. An employee's authorization settings are used to control access to all resources, including Customer Data, Service Data and all Google systems that may process personal data from the tested 4 GCP - services . Even if an employee has the appropriate authorization to access Customer Data or Service Data, they must still provide a justification tied to a specific technical issue otherwise access to that data will be rejected. All technic al issues are individually tracked using a unique case ID, and employee justifications are periodically reviewed. This means that it is not technically possible for an employee to access Customer Data or Service Data that is not required for them to invest igate and resolve specific technical issues tasked to them.

Access is monitored by our dedicated security teams as a check on the effectiveness of our controls. The security teams actively monitor access patterns and investigate unusual events ." 199 198 Google reply to questions SLM , 21 March 2025. 199 Idem. DPIA on Google Cloud Platform public version 11 June 2026 Google also explicitly confirmed that it has not built in backdoors, or provided any government with direct access to any data processed by the 4 tested GCP - services : “We confirm that Google has not provided any government with direct access to any information stored in its data centers, including data stored or processed by the 4 tested GCP - services (including direct access for security services).” 200 “with respect to the 4 assessed GCP - services , Google did not and currently does not disable security features or alter systems to allow third parties to gain access to Customer Personal Data that would otherwise be unavailable to a third party in clear text.” 201 Google has also confirmed “ it has not detected any unauthorised usage by engineers in the third countries in the past 2 years to a) Customer Data and b) Service Data from the 4 tested GCP - services ." 202 Relevant other information for the DTIA In the dialogue with SLM Rijk about Google Workspace Enterprise Google provided many assurances about the very low probability of compelled disclosure of personal data of Dutch public sector customers to government agencies (excluding the security services), also in view of the very h igh uptime of Google Meet in the Netherlands.

For the SLA guarantees an uptime of 99,99%. Privacy Company could not find historical up time statistics for the VMs. Based on the SLA the VM can be down for an average of 4 minutes and 23 seconds per month in the Netherlands. This translates to a maximum availability of the Content D ata of 1 hour and 45 minutes in total in 2 years. For the other three tested services the uptime was similarly high . Table 2 : Overview of uptime for the tested 4 GCP - services per SLA Covered Service Monthly Uptime Percentage Cloud Compute Engine 203 > = 99,99%. Cloud SQL Enterprise Plus edition with high availability (HA) 204 >= 99.95% Cloud Storage - Standard storage class in a multi - region or dual - region location of Cloud Storage 205 >= 99.95% BigQuery (except BigQuery Standard edition) 206 >= 99.99% In the most recently available SOC - 2 audit report on GCP 207 , EY found no deviations on the relevant criteria P6.1, P6.2, P6.4 and P6.7.

This means that based on the sample tested by EY, Google complied with its policy to register all requests from 200 Ibid. 201 Id. 202 Id. 203 See documentation on SLA for Cloud Compute Engine , https://cloud.google.com/compute/sla 204 See documentation on SLA for Cloud SQL , https://cloud.google.com/sql/sla 205 See documentation on SLA for Cloud Storage, https://cloud.google.com/storage/sla?hl=en 206 See documentation on SLA for BigQuery , https://cloud.google.com/bigquery/sla?hl=en 207 Access to audit reports is available for (Dutch government) customers via https://cloud.google.com/security/compliance/compliance - reports - manager DPIA on Google Cloud Platform public version 11 June 2026 Page 97 of 142 government agencies, limit disclosure to what is necessary to fulfil the request and inform its customers, unless notification is prohibited (gag order). Google does not publish, and has not confidentially shared its legal analysis of applicable laws and their compliance with the EU fundamental right guarantees offered to data subjects in the 13 third countries in which some personal data relating to the GCP - services can be accessed for service maintenance .

Absent detailed information from Google about the applicable laws in the 13 third countries, Dutch government organisations have to assume there are laws in the third countries that do enable government t o order compelled disclosure, as well as laws that prohibit Google from informing its customers about such orders. In reply to this DPIA, Google explained that Google cannot share a privileged legal analysis . Google also stated that , with reference to the EDPB, that government organisations do not have to take supplementary measures as long as they can rely on the EU US Data Privacy Framework, also for the onward transfers. 208 The conclusion of the Google Meet DTIA ( based on adequacy of the US data protection regime including onward transfers ) was that the data transfers did not lead to high data protection risks for users of Google Meet, except when they exchange d sensitive or special categories of data.

This specific risk follows from the guidelines of the EDPB on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data. 209 Unauthorised access to these special categories of data in readable format (in the third countries) has a very high impact on the data subjects. Therefore, the data protection risk must be qualified as high, in spite of the very low probability that the risk will materialise. This same risk applies to sensitive and special categories of data stored on the Compute Engine , in the tested Google SQL database, Cloud Storage and BigQuery. Supplementary measures that can be applied The EDPB recommends strong encryption as the best supplementary measure to mitigate the risks of unlawful processing when the data are transferred to a third country , with a self - controlled key . The EDPB writes: “ Demonstrating that problematic legislation is not applied in practice to your transferred data and importer, also taking into account the experience of other actors operating within the same sector and/or related to similar transferred personal data, does not exempt you from providing for the necessary supplementary measures to protect personal data during its transmission and processing in the third country of destination ( e.g. end - to - end encryption of data – see examples of technical supplementary measure s in Annex 2 - ) if your analysis of the applicable legislation of the third country of destination indicates that access to data may also take place, even in the absence of the importer’s 208 Google (second) reply to part A of this DPIA, dated 21 March 2025, made accessible to Privacy Company 25 March 2025. 209 EDPB, Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, Version 2.0, Adopted on 18 June 2021, URL: https://www.edpb.europa.eu/system/files/2021 - 06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf .

DPIA on Google Cloud Platform public version 11 June 2026 intervention, at this moment of the transfer. [underlining added by Privacy Company]. ” 210 Google offers two relevant encryption - related service s called Cloud EKM keys and Confidential Computing. 211 Section 9.2 below describes some more details of these two types of encryption . However, these encryption services were not tested in this DPIA. T he EDPB also acknowledges that end - to - end encryption with customer - held keys is not always possible for cloud providers. In certain cases (e.g., where access to data in the clear is required) the cloud provider may need access to unencrypted data during the processing to provide certain services. This is the case for database services offered as SaaS by the provider, in this case, Cloud SQL and BigQuery. These services are examples where it’s generally not possible to encrypt data before uploading data to Google’s service while keeping relevant encryption keys fully under the control of the customer.

Google’s two database ser vices in scope of this DPIA do support encryption measures via customer managed keys (External Key Manager, EKM) . This means Google has restricted access to key material and the machine that manages the key material can stay outside of Google’s control . Anticipating a possible end of the EU US DPF, g overnment organisations can also minimise the risks of bulk searches for identifying data by th i rd country government authorities of the Diagnostic and admin Account Data by using pseudonymised admin accounts. This will ensure that the se Google logs generated in the USA and onward transferred to the 13 identified third countries only contain pseudonymised personal data of government employees. These possible technical measures are described in more detail in Section 9 , about encryption and pseudonymisation . In sum , government organisations must assess on a case by case basis if they can apply technical measures such as encryption and pseudonymisation to the different categories of personal data to lower the likelihood of unauthorised further processin g in the 13 identified third countries . 9.

Data minimisation: e ncryption and pseudonymisation Google offers its customers different encryption options , both for the Content Data and for the customer - managed log files (as exported to BigQuery) . Enterprise customers are also advised to pseudonymise the Admin Account Data. The techniques behind encryption and pseudonymisation are explained in more detail below. 9.1 Stored data e ncryption functionality Google offers several types of encryption for data at rest . For the tested services Google provides different encryption types on top of the default storage encryption 210 Idem, footnote 55 and Annex 2, in particular use case s 1 and 6. Use case 1 specifies as condition: “ the keys are retained solely under the control of the data exporter, or by an entity trusted by the exporter in the EEA or under a jurisdiction offering an essentially equivalent level of protection to that guaranteed within the EEA. ” 211 Google Cloud, Confidential Computing, undated, URL: https://cloud.google.com/security/products/confidential - computing (page last visited 27 January 2025).

DPIA on Google Cloud Platform public version 11 June 2026 Page 99 of 142 where Google m anages the keys . 212 The bottom two options are highlighted in blue to emphasise they enable customers to encrypt Content Data with external self - managed keys. Table 3 : Overview of available encryption - related security measures for the 4 tested GCP - services Security measure Compatible Services Google - owned and Google - managed encryption keys (Google Cloud default encryption) All Google Cloud services that store customer data Customer - supplied encryption keys ( Customer - generated key provided to Google) Compute Engine and Cloud Storage , BigQuery, Cloud SQL Customer - managed encryption keys – software (Cloud KMS keys) Compute Engine (Persistent disks, Snapshots, Custom Images, Machine Images), BigQuery, Cloud SQL, Cloud Storage Customer - managed encryption keys – hardware (Cloud HSM keys) Compute Engine (Persistent disks, Snapshots, Custom Images, Machine Images), BigQuery, Cloud SQL, Cloud Storage Customer - managed encryption keys – external (Cloud EKM keys) Compute Engine (Persistent disks, Snapshots, Custom Images, Machine Images), BigQuery, Cloud SQL, Cloud Storage Confidential Computing Compute Engine Google writes: “ Encryption at rest is encryption that is used to help protect data that is stored on a disk (including solid - state drives) or backup media.

All data that is stored by Google is encrypted at the storage layer using the Advanced Encryption Standard (AES) alg orithm, AES - 256. We use a common cryptographic library, Tink, which includes our FIPS 140 - 2 validated module (named BoringCrypto) to implement encryption consistently across Google Cloud. We own and manage the keys used in default encryption at rest. If you use Google Cloud, Cloud Key Management Service lets you create your own encryption keys that you can use to add envelope encryption to your data. Using Cloud KMS, you can create, rotate, track, and delete keys .“ 213 212 Google Cloud documentation “ Cloud Key Management Service overview ”, URL: https://cloud.google.com/kms/docs/key - management - service#choose 213 Google Cloud documentation “ Default encryption at rest ”, undated, URL: https://cloud.google.com/docs/security/encryption/default - encryption (page last visited 27 January 2025).

DPIA on Google Cloud Platform public version 11 June 2026 9.2 C onfidential C omput ing / EDPB - proof storage encryption To protect personal data against unauthorised access by government authorities in third countries, key management by the customer is not a sufficient measure . According to the EDPB Recommendations on additional measures for data transfers, encryption can only be considered a sufficient measure if the importer does not have access to the keys. 214 The EDPB writes that it only considers the encryption performed on storage of personal data by a hosting provider in a third country an effective supplementary measure if six criteria are met. In reply to the DPIA, Google confirmed that this norm creates a fundamental problem for all suppliers, because to comply with this norm, the customer needs to use compute and run all its own systems and not use managed services. Google wrote: “ there is no way for us to run a managed service and not have access to the keys. ” 215 For the use of GCP - services , the most relevant criterion is that the importer does not have access to the key.

“the keys are retained solely under the control of the data exporter, or by an entity trusted by the exporter in the EEA or under a jurisdiction offering an essentially equivalent level of protection to that guaranteed within the EEA” 216 The EDPB similarly explains in Use case 6 of the Guidelines that transport encryption and data - at - rest encryption are not sufficient to ensure an essentially equivalent level of protection if the data importer (in this case Google) is in possession of the cryptographic keys. 217 This means that a scenario where Google stores the master key in an HSM, where Google still manages the authentication to the HSM, cannot qualify as EDPB - proof, since Google can still control the key on the HSM to decrypt data (even though Google cannot access or export the key). However limited the exposure with Google’s other encryption options , the key material is only solely under customer or trusted third party control with the bottom two highlighted options in the table Google offers for encryption, Cloud EKM keys and Confidential Computing.

Only with these options government organisations can manage the keys externally, the absolute norm imposed by the EDPB. C onfidential Computing 218 has as main use the Confidential VM. 219 While the cloud EKM keys help protect against access to stored data (data at rest) , C onfidential Computing protects against access to the VM images while they are being executed 214 EDPB, Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data , 18 June 2021, URL: https://www.edpb.europa.eu/our - work - tools/our - documents/recommendations/recommendations - 012020 - measures - supplement - transfer_en . 215 Google reply to the DPIA, 23 October 2025. On 1 June 2026 Google asked to add a footnote:” Google prefers to express the contnt of this paragraph with more nuance. ” Privacy Company assumes Google means the EDPB norm itself is not nuanced enough. 216 Idem, par. 84, p. 30. 217 Idem, par. 95, p. 35. 218 Google Cloud, Confidential Computing, undated, URL: https://cloud.google.com/security/products/confidential - computing (page last visited 27 January 2025). 219 Google Cloud, Confidential Computing, Confidential VM, Confidential VM overview, undated, URL: https://cloud.google.com/confidential - computing/confidential - vm/docs/confidential - vm - overview (page last visited 27 January 2025).

DPIA on Google Cloud Platform public version 11 June 2026 Page 101 of 142 (data in use). During set - up of the test environment, Google offered the choice to enable ‘Confidential VM service’. Figure 34 : Option to enable Confidential VM during set - up Google describes that the encryption keys “ are generated by — and reside solely in — dedicated hardware, inaccessible to the hypervisor. ” 220 Customers can also “ verify the identity and the state of the VM, to make sure that key components haven't been tampered with. ” 221 Together Google calls these two measures (hardware isolation and attestation) a “ Trusted Execution Environment .” 222 Google Confidential VM relies on AMD SEV , AMD SEV - SNP and Intel TDX to pro vide i solation and attestation of VMs . That means use of hardware designed to isolate the encryption keys within the CPU ( comparable to an HSM) , separation and encryption of system memory and measures to prevent tampering with the code running on the system from booting .

Though Google with this type of encryption has physical access to CPU, it commits it cannot control the key within the CPU. Privacy Company initially did not find a single whitepaper or audit report that supported the conclusion that the combination of these mechanisms effectively prevents access to the decrypted Content Data in the Compute Engine (VM) via the Hypervisor or physical access to the hardware. However, in reply to this DPIA, Google mentioned a whitepaper, and referred to an attestation and a technical analysis. The whitepaper and d o cumentation describe that the Titan system that Google uses provides a confidential computing enclave . That enclave is functionality to check the integrity of the system , and to offload encryption and key management functionality from the main system. Google explicitly describes three different types of threats the Titan architecture is designed to protect against: 1.

Rogue insider with physical access 2. Rogue insider with logical access 3. External attacker with logical access . 223 220 Google Cloud documentation, Confidential VM overview, undated, URL: https://cloud.google.com/confidential - computing/confidential - vm/docs/confidential - vm - overview (page last visited 27 January 2025). 221 Idem. 222 Ibid. 223 Titanium hardware security architecture at Google , 5 November 2025, url: https://cloud.google.com/docs/security/titanium - hardware - security - architecture#infrastructure - threats . DPIA on Google Cloud Platform public version 11 June 2026 Google does not describe the effectiveness of the measures in a scenario where Google is forced to provide access to customer data by, for example, secret services . Since Confidential Comput ing is out of scope of this DPIA and was not tested , this DPIA can only refer to documents provided by Google .

Government organisations that want to deploy Confidential Computing will have to assess themselves if Google’s infrastructure provides adequate protection against the risk of compelled disclosure of key material of Customer Content Data. In reply to this description, Google referred to its GCP SOC 2 type II report. 224 However, the only mention in this audit report of encryption uses a different product name, and only contains one mention of Google’s Confidential VM service: “ Additionally, customers can enable Shielded VMs to provide advanced platform security. ” The audit does not contain a statement of the effectiveness of this measure against specific risks. 9.3 Encryption during transport Google applies different types of transport encryption. 225 Google distinguishes between two different contexts: 1. t raffic within a physical security boundary and 2. traffic that transits outside of such a boundary.

Where Google has physical control of all hardware, including network fibres , and encrypts all data in transit within and outside of its data centres, Google has (and logically must have) access to those encryption keys. To prevent access in the clear, Google relies on physical security measures such as access control. For data in transit where Google cannot app ly the same physical controls , Google commits it applies encryption to all data in transit. The type of encryption Google use s depends on the specific context . For public facing systems Google mostly relies on TLS/HTTPS or QUICK . For communication between Google internal systems Google relies on ALTS , a protocol similar to TLS specifically designed for GRPC , that enforces mutual authentication of both sides with short lived certificates. For ALTS Google uses AES - 128 - GCM or AES - 128 - VCM with short live d certificates (6 - 28 hours) .

For externally facing connections more cipher suite variations are supported for TLS communication. 224 Google reply to questions SLM, 21 March 2025. Google wrote: “ While Confidential Computing and Cloud External Key Management (EKM) are outside the scope of your assessment, the controls governing them are included within the scope of the Google Cloud Platform SOC 2 Type II report, which we have provided. This report addresses the Trust Services Criteria relevant to these services, thereby addressing your request for an independent assessment of Cloud EKM and Confidential Computing services. " 225 Google Cloud documentation: Encryption in transit, last updated in September 2022 , URL: https://cloud.google.com/docs/security/encryption - in - transit . DPIA on Google Cloud Platform public version 11 June 2026 Page 103 of 142 Figure 35 : Google protocols used for encryption 9.4 Pseudonymisation Admins can create pseudonymous identities in Google Cloud Identity , by creating new accounts at admin . google.com.

Figure 36 : Example s of creation of pseudonymous account Google also enables organisations to limit the exposure of directly identifiable information from admins by using Workload Identity Federation . What that means in practice is that the administrator user - accounts can be stored in a user database outside of Google and Google can be instructed to authenticate users against that external database through the OpenID Connect or SAML 2.0 protocols . 226 With this single sign - on government organisations could reuse existing pseudonymous accounts in their Microsoft Entra ID to create pseudonymous accounts to administer GCP - services . As quoted in Section 2.1 o f this report, pseudonymised data are still personal data. The ‘exporter’ (Dutch government organisation) has a realistic possibility to re - 226 Google Cloud documentation, IAM, Workload Identity Federation (undated), URL: https://cloud.google.com/iam/docs/workload - identity - federation DPIA on Google Cloud Platform public version 11 June 2026 identify individuals based on a look - up table of the original identifying data stored with the identity provider and the aliased data provided to Google .

While th e use of pseudonymous accounts or single sign - on does not prevent the processing of personal data of admins in Google logs, the pseudonymisation can lower the data protection risk s for the system admins. A s described in Use case 2 of the EDPB Recommendations on measures that supplement transfer tools , pseudonymisation may be an effective supplementary measures to lower transfer risks , provided that the exporting organisation can also ensure that the pseudonymised data cannot be reidentified: “by means of a thorough analysis of the data in question - taking into account any information that the public authorities of the recipient country may be expected to possess and use - that the pseudonymised personal data cannot be attributed to an identif ied or identifiable natural person even if cross - referenced with such information.” 227 In its new Guidelines on Pseudonymisation, the EDPB has included a secti on about data transfers.

The EDPB writes: “ The conditions include that • the attribution of pseudonymised data to a specific data subject requires the use of additional information that public authorities of the recipient country neither possess, nor are able to obtain with reasonable effort, • additional information is held exclusively by the data exporter and kept separately in a Member State or in a third country, by an entity trusted by the exporter in the EEA or under a jurisdiction offering an essentially equivalent level of protection to t hat guaranteed within the EEA, • the authorities are not able to single out a data subject in the course of an interaction with members of a group of persons based on the pseudonymised data and information they are able to obtain with reasonable effort. This implies that the public authorities, who would be able to have access to the pseudonymised data based on foreign law or practice, need to be framed within the pseudonymisation domain. ” 228 10.

Additional legal obligations: e - Privacy Directive This S ection only describes the additional obligations arising from the current ePrivacy Directive. This Section does not discuss the ePrivacy Regulation, proposed by the European Commission in 2017. 229 The European Commission has withdrawn 227 EDPB Recommendations, Use case 2, p. 31. 228 EDPB, Guidelines 01/2025 on Pseudonymisation, 17 January 2025, consultation version, par. 4, URL: https://www.edpb.europa.eu/system/files/2025 - 01/edpb_guidelines_202501_pseudonymisation_en.pdf 229 European Commission, Proposal for a Regulation on Privacy and Electronic Communications, 10.1.2017 COM( 2017) 10 final, URL: https://ec.europa.eu/digital - single - market/en/proposal - eprivacy - regulation DPIA on Google Cloud Platform public version 11 June 2026 Page 105 of 142 the proposal in March 2025 . This means Google will have to comply with the current ePrivacy rules.

In view of the limited scope of this DPIA, other legal obligations or frameworks (for example in the area of information security, such as BIO) are not included in this report. The act of reading or placing information (through cookies or similar technology), or enabling third parties to read information from the devices of end users triggers the applicability of Article 5(3) of the ePrivacy Directive, regardless of who places or reads the information, and regardless of whether the content is personal data or not. Consent is required prior to the retrieval or storage of information on the devices or browsers of end users, unless one of the exceptions applies, such as the necessity to deliver a requested service, or necessity for the technical transmission of information. Based on article 3(1) of the GDPR, because the data processing takes place in the context of the activities of data controllers (Dutch government organisations), the GDPR applies to all phases of the processing of these data.

Applicability of the GDPR rules does not exclude applicability of the ePrivacy rules or vice versa. The European Data Protection Board writes: “Case law of the Court of Justice of the European Union (CJEU) confirms that it is possible for processing to fall within the material scope of both the ePrivacy Directive and the GDPR at the same time. In Wirtschaftsakademie, the CJEU applied Directive 95 /46/EC notwithstanding the fact that the underlying processing also involved processing operations falling into the material scope of the ePrivacy Directive. In the pending Fashion ID case, the Advocate General expressed the view that both set of rules may be applicable in a case involving social plug - ins and cookies . 230 As confirmed by the EDPB in its guidelines on the Technical Scope of Article 5(3) of the ePrivacy Directive, both telemetry events and URL parameters are in scope of the provisions. 231 “Additional examples would include JavaScript code, where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted information.

Such access clearly falls within the scope of Article 5(3) ePD, as the accessing entity explicitly instructs the terminal equipment to send the information. ” 232 230 EDPB, Opinion 5/2019 on the interplay between the ePrivacy Directive and the GDPR, in particular regarding the competence, tasks and powers of data protection authorities, adopted on 12 March 2019, Paragraph 30. URL: https://edpb.europa.eu/sites/edpb/files/files/file1/201905_ edpb_opinion_eprivacydir_gdpr_interplay_en_0.pdf In footnotes the EDPB refers to: CJEU, C - 210/16, 5 June 2018, C ‑ 210/16, ECLI:EU:C:2018:388. See in particular paragraphs 33 - 34 and the Opinion of Advocate General Bobek in Fashion ID, C - 40/17, 19 December 2018, ECLI:EU:C:2018:1039. See in particular paragraphs 111 - 115. 231 EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, Version 2.0, Adopted on 7 October 2024, URL: https://www.edpb.europa.eu/system/files/2024 - 10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf 232 Idem, par. 33, p. 10.

DPIA on Google Cloud Platform public version 11 June 2026 And for URL parameters: “The addition of tracking information to URLs or images (pixels) sent to the user constitutes an instruction to the terminal equipment to send back the targeted information (the specified identifier) .” 233 The most frequently used exception in the Netherlands is the processing of such information for analytical purposes, literally: “to obtain information on the quality or effectiveness of a delivered information society service provided that it has no or little impact on the privacy of the subscriber or user concerned.” Article 5(3) of the ePrivacy Directive was transposed in article 11.7a of the Dutch Telecommunications Act. The consequences of the cookie provision are far - reaching, since it requires clear and complete information to be provided *prior* to the data processing, and it requires consent from the user, unless one of the legal exceptions applies.

The consent is ide ntical to the consent defined in the GDPR. Google uses its own Google Analytics cookies when admins interact with the GCP - services through the Admin Console . As described in Section 3.3.3 Google collects these and other cookie data as part of Telemetry Data. During the tests on 29 and 30 October 2024 Privacy Company observed 33 telemetry events sent to region1.analytics.google.com from the Admin Console . Th ese telemetry events contained cookies and URL - parameters. Privacy Company also observed 94 Post Requests sent to cloud.google.com, events that also included cookies. On average Google collected a few events per minute while Privacy Company actively engaged with the Admin Console. Google does not provide documentation for all observed cookies. Not all of the observed different cookies with the word ‘_Secure’ are mentioned. Nor are cookies with the names APISID, OSID, RAPT, SAPISID, SIDCC and SSID.

It is not clear how (for what purposes) Google uses its own Google Analytics cookies, or which of the other cookies it uses for analytical purposes. Google explained that the cookies set via the Admin Console are used for functional purposes, including analytics ‘ how people use our services’ : “ The cookies set on console.cloud.google.com (i.e. the Cloud Console) are only used for functional purposes such as to provide and maintain our services and to analyze how people use our services . The NID cookie could be used for multiple purposes, but with respect to the Cloud Console, it is only used for the aforementioned purposes and not for advertising. [underlining added by Privacy Company],” 234 Based on Dutch legislative history, use of cookies for analytical purposes can only be exempted from the consent requirement if Google ensures that the processing has little or no impact on the privacy of the visitors.

The legislative history distinguishes between high impact for cookies used to analyse people, versus low impact for 233 Idem, par. 51, p. 13. 234 Google reply to questions SLM 21 March 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 107 of 142 analysis of the functioning of webpages. In the informal translation of Privacy Company: “ If these analytical cookies that track the use of multiple websites are not only used to improve the quality of the website, but are also used to create interest profiles of unique users , the consequences for the privacy of users are more than minor. In that case, these ‘analytical’ cookies are also tracking cookies. These cookies are not covered by the exception. " 235 Under both the GDPR and the Telecommunications Act, parties that read information from user devices must inform visitors in a clear and understandable manner what data is collected about them, for what purposes.

The information must be accessible before the data are read from the visitor's/user's device. The requirement to inform users about all cookies and similar information was specified in the Planet 49 ruling from the European Court of Justice . 236 The ECJ explains that parties that set cookies have to inform visitors of the names of all cookies, their purpose, and the time period the party setting these cookies retains the data. The ECJ writes: “ 77 That information includes, inter alia, under Article 10 of Directive 95/46, in addition to the identity of the controller and the purposes of the processing for which the data are intended, any further information such as the recipients or categories of recipients of the data in so far as such further information is necessary, having regard to the specific circumstances in which the data are processed, to guarantee fair processing in respect of the data subject. 78 Although the duration of the processing of the data is not included as part of that information, it is, however, clear from the words ‘at least’ in Article 10 of Directive 95/46 that that information is not listed exhaustively.

applies Directive 95/46 Art. 10 → GDPR Art. 13

Information on the duration of the operation of cookies must be regarded as mee ting the requirement of fair data processing provided for in that article in that, in a situation such as that at issue in the main proceedings, a long, or even unlimited, duration means collecting a la rge amount of information on users’ surfing behaviour and how often they may visit the websites of the organiser of the promotional lottery’s advertising partners. ” One of the observed cookies (both on the Admin Console and on Google’s publicly accessible GCP - pages ) is the NID - cookie. In its general cookie information, Google describes 4 purposes for the use of the observed NID - cookie: functional, analytics, advertising and personalisation. This means the NID - cookie is a so - called quadruple - use cookie, with a unique identifier. Google can use this unique identifier to recognise the specific browser profile (including corresponding cookie jar) of a user, until the NID c ookie is deleted.

When Google uses the NID - cookie for the purpose of following a specific browser profile (including the corresponding cookie jar) across sites, it is a 235 Kamerstukken II, 2013/14 , 33 902, nr. 3, p. 10. 236 ECJ, Case C - 673/17, ECLI:EU:C:2019:801, Bundesverband der Verbraucherzentralen und Verbraucherverbände — Verbraucherzentrale Bundesverband eV versus Planet49 GmbH, 1 October 2019, URL: https://curia.europa.eu/juris/document/document.jsf?docid=218462&doclang=EN . DPIA on Google Cloud Platform public version 11 June 2026 tracking cookie. Based on the Dutch implementation of the ePrivacy Directive, the reading of such a cookie requires consent. 237 Google replied to this finding with a reference to a commitment it made for Google Workspace Enterprise users not to use the NID - cookie for advertising. Later, Google also committed to add an explanatory sentence to its Cookie Policy about the NID - cookie in Q3 2025.

If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. In reply to the finding that Google does not provide a limitative list of all cookies it sets and reads, with their purposes and retention period (different from expiry date), Google wrote: “ Google believes it already satisfied the request to publish detailed documentation ab out the cookies it uses, including a list of cookies, their purpose, and data retention periods. Google provides this information in Google’s Cookie Policy but in a manner which is easy to read and provides context for our users. Google believes the narrative style naming the cookies within the explanatory text is far more meaningful (and therefore more helpful) to users than a simple list or table of cookie names. Google i s satisfied that its cookies notice page provides full transparency as to the purposes for which cookies are used and how long they are retained.

Google believes it carefully delivers this information in a manner which is meaningful to users, without overw helming them with technical detail (such as a list of cookies). This approach is consistent with the GDPR requirement to be concise, easy to understand and to use “clear and plain language” (Recital 39). Google is cognizant of its very broad user base, and so has put considerable effort into drafting policies which are easy to understand, even for those with no technical background. ” 238 In reply to the DPIA, Google repeated this same comment, and suggested the quote above was not sufficient: “ We address purposes, retention periods and easily understandable information about the cookies we use, as explained in more detail in writing. However, you seem to not consider our input in your analysis. ” 239 Privacy Company has however taken notice of this comment, but disagrees with the content, based on the factual and verifiable omission of complete cookie information.

As quoted in Sect ion 3.5.2 , Google has explained that it may want to set advertising cookies in the future. In that case, Google will add a ‘reject’ button to its banner. Mitigating measures Google • Google refuses to provide a limitative list of the cookies it sets and reads on cloud.google.com and on console.cloud.google.com, with their purposes and retention period. 237 New findings verification review Google Workspace Enterprise, 15 May 2024, p. 8, URL: https:// SLM Rijk microsoftrijk.nl/wp - content/uploads/2024/07/New - findings - verification - review - Google - Workspace - Enterprise.pdf 238 G oogle reply to questions SLM , 21 March 2025. 239 Google reply to the DPIA, 23 October 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 109 of 142 • In Q3 2025 Google will add an explanatory sentence to its Cookie Policy about the NID - cookie. If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. 11.

Retention Period s 11.1 R etention periods Content Data Government organisations themselves determine to a large extent the retention periods of Content Data in the four tested GCP - services . Customers can delete specific Content Data, or for example, terminate an entire VM. However, Google applies a default fail - safe retention period of 7 days to the Cloud Storage and BigQuery data. Customers can choose between ‘hard’ and ‘soft ’ delete of Content Data . In case of a hard delete, Google still needs some time to remove back - ups. On 12 December 2024 Google provided the following explanation on the availability of the temporary table: “ After a query finishes, the temporary table exists for up to 24 hours for customers (as shown here 240 ), but it may take up to 10 days for the data to be deleted from Google's systems. During this time, the data is only accessible internally via debugging mechanisms subject to multi - user authorization.

Access rights and levels are based on job function and role, using the concepts of least privilege and need - to - know that match access privileges to defined responsibilities. ” Soft delete of the Cloud Storage buckets offers a default grace period of 7 days . In this period the only supported action is to list or restore them. 241 240 Google Cloud, BigQuery, Writing query results, undated, URL: https://cloud.google.com/bigquery/docs/writing - results (page last visited 27 January 2025). 241 Google Cloud, Cloud Storage, Soft Delete, undated, URL: https://cloud.google.com/storage/docs/soft - delete (page last visited 27 January 2025). DPIA on Google Cloud Platform public version 11 June 2026 Figure 37 : Back - up cloud storage 7 days Similarly, customers can choose a ‘graceful shutdown’ for a VM, or hard deletion. 242 The default grace period is 10 minutes, but this can be changed from one second up to one hour.

For the tested MySQL database on Cloud SQL, even if a customer chooses hard delete, Google writes: “ it can take up to a week for the underlying resources related to an instance to be completely deleted, with the exception of read replicas, which are often deleted within a few minutes. ” 243 11.2 Retention periods Account, Diagnostic and restricted access Website Data Google describes a retention period of max 180 days for all personal data it calls GCPP usage data . Figure 38 : Google explanation retention period usage data 244 In reply to a question from Privacy Company, Google wrote that it considers the term GCP usage data to be extremely vague, even though it is Google itself that uses this term in its own public documentation (as shown in Figure 38 above). “ As we have discussed with you numerous times, Google does not follow the same data classifications you have set out in your question, which means it is 242 Google Cloud, Compute Engine, Graceful shutdown overview, undated, URL: https://cloud.google.com/compute/docs/instances/graceful - shutdown - overview (page last visited 27 January 2025). 243 Google Cloud, Cloud SQL, Delete instances, undated, URL: https://cloud.google.com/sql/docs/mysql/delete - instance (page last visited 27 January 2025). 244 This information was shown to the admin in the menu IAM & Admin, Privacy & Security, Transparency & Control .

DPIA on Google Cloud Platform public version 11 June 2026 Page 111 of 142 very difficult to provide precise, granular retention timeframes; especially where classifications like “GCP usage data” are extremely vague. Therefore, while we have provided information about retention periods for specific data types in our responses to other questions where it has been reasonably possible to do so, we would otherwise refer you to the retention commitments in the Google Cloud Privacy Notice, which state that we retain most types of Service Data for a set period of up to 180 days, but some Service Data may be retained for longer periods in limited circumstances ." 245 Google’s Cloud Privacy Notice mentions three of these circumstances. “ We generally have longer retention periods (which can be over a year) for Service Data that is kept for the following purposes: • Security, fraud and abuse prevention.

We retain Service Data when it is necessary to protect against fraudulent attempts to gain access to user accounts, or to investigate violations of applicable Cloud Services agreements. Usually, the Service Data retained where there is reason to suspect fr aud or abuse would include device identifiers, identifiers from cookies or tokens, and IP addresses, as well as log data about usage of the Cloud Services. • Complying with legal or regulatory requirements. We retain Service Data when required by an enforceable legal process, such as when Google receives a lawful subpoena. • Complying with tax, accounting or financial requirements. When Google processes a payment for you, or when you make a payment to Google, we retain Service Data about those transactions (including billing information), typically for a minimum of five years, as required for tax or accounting purposes, or to comply with applicable financial regulations. ” 246 Google confirms on a public page with information about retention periods for Workspace that the retention period for reports and log events generally is 6 months.

The events in the first 4 rows are likely also relevant for GCP. Figure 39 : Google log retention periods Google Workspace 247 245 Google reply to questions SLM , 21 March 2025. 246 Google Cloud Privacy Notice, ef fective Date 6 February 2025 , URL: https://cloud.google.com/terms/cloud - privacy - notice . 247 Google Workspace Admin help , Data retention and lag times Reports, security investigation tool, & audit and investigation page , undated, URL: https://support.google.com/a/answer/7061566 . DPIA on Google Cloud Platform public version 11 June 2026 As a result of the DPIA and verification reports on Google Workspace Enterprise, Google publis h ed more details about the different retention periods. " We retain most types of Service Data for a set period of up to 180 days. ( . .) In practice, diagnostic information is retained for shorter periods of between 30 to 63 days. Google also refers to its Google Cloud Privacy Notice.

This describes the 3 criteria Google applies to retain Service Data longer. These are: 1. Security, fraud and abuse prevention, 2. Complying with legal or regulatory requirements and 3. Complying with tax, accounting or financial requirements ” 248 Google does not publish a similar explanation about the retention periods for GCP related personal data, nor for the data it collects in its own infrastructure and security event logs. Google has explained in reply to this DPIA that it generally retains Telemetry Data for 50 days but did not specify when it pseudonymises and when it anonymises Telemetry Data: “ Google’s policy is to aggregate, anonymise or pseudonymise telemetry data when identifiability is not required for the processing of that data. Under this policy, Google will do so after approximately 50 days. ” 249 Google added (with underlining added by Google): “ The GCPN states that “We retain Service Data for different periods of time depending on the type of data, how we use it, and how you configure your settings”, and “We retain most types of Service Data for a set period of up to 180 days (the exact number depends on the specific type of data)”.

As such, the GCPN clearly sets the expectation with data subjects that certain Service Data may be retained for periods that are shorter than 180 days; as is the case for telemetry data. We did not state that the retention period for telemetry data was fix ed at 180 days specifically. ” (…) Additionally, the notice sets out the circumstances in which Service Data may be retained for longer than the 180 day timeframe : for security, fraud and abuse prevention; for complying with legal or regulatory requirements; and for complying with tax, accounting or financial requirements. [emphasis added by Privacy Company]” 250 On the new page with inf or mation about telemetry events, Google explains that Telemetry Data are completely deleted within 63 days. Google explained: “ When considering the full lifecycle of telemetry data, from collection to its final deletion from 248 As quoted in Table 1 in the published Updated Verification Report on Google Workspace for SLM Rijk , 17 May 2024, URL: https:// SLM Rijk microsoftrijk.nl/?sdm_process_download=1&download_id=11708 . 249 Google reply to questions SLM , 21 March 2025. 250 Google reply to questions SLM, 19 August 2025.

DPIA on Google Cloud Platform public version 11 June 2026 Page 113 of 142 all our active and backend systems, this (the 63 days) is the definitive, upper - bound limit that is consistently applied across our infrastructure. ” 251 Privacy Company understands that the retention period for most of the Telemetry Data is 50 days, but Google needs some time to ensure final deletion, including from back ups. Figure 40 : Google new public explanation retention period Telemetry Data 252 251 Google reply to this DPIA, 1 June 2026, referring to mail of 22 December 2025. 252 Google Telemetry Data in Google Cloud Console, bottom of the page, URL: https://support.google.com/cloud/answer/16796043 . DPIA on Google Cloud Platform public version 11 June 2026 Part B. Lawfulness of the data processing The second part of the DPIA assesses the lawfulness of the data processing. This part contains a discussion of the legal grounds, an assessment of the necessity and proportionality of the processing, and of the compatibility of the processing in relation t o the purposes. 12.

Legal Grounds To be permissible under the GDPR, processing of personal data must be based on one of the grounds mentioned in Article (6) (1) GDPR. Essentially, for processing to be lawful, this article demands that the data controller bases the processing on the consent of the user, or on a legally defined necessity to process the personal data. The assessment of available legal grounds (sometimes called ‘lawful bases’) is tied closely to the principle of purpose limitation. The EDPB notes that “ The identification of the appropriate lawful basis is tied to principles of fairness and purpose limitation . [.] When controllers set out to identify the appropriate legal basis in line with the fairness principle, this will be difficult to achieve if they have not first clearly identified the purposes of processing, or if processing personal data goes beyond what is necessary for the specified purposes. ” 253 Thus, in order to determine whether a legal ground is available for a specific processing operation, it is necessary to determine for what purpose(s), the data was or is collected and will be (further) processed.

There must be a legal ground for each of these purposes. 254 T he appropriate legal ground furthermore depends on Google’s role as authorised or independent controller, or as processor. As described in Section 2.2 , Google processes 5 relevant categories of personal data : 1. Content Data (incl. Feedback Data) 2. Account Data 3. Diagnostic Data 4. Support Data 5. Website Data The sections below discuss the appropriate legal ground for each category of personal data from the perspective of the Dutch government organisation. They have to rely on a different legal ground when Google acts as processor, as an authorised controller, or as a third party. Based on a compatibility assessment, t h e Dutch government has allowed Google to further process some personal data as controller for seven specific purposes in the existing CMA with Google. However, i f Google processes personal data for other purposes, or collects personal data outside of the CMA, Google acts as independent data controller .

As analysed in 253 EDPB, Guidelines 2/2019 on the processing of personal data under Article 6(1)(b) GDPR in the context of the provision of online services to data subjects - version adopted after public consultation, 16 October 2019, URL: https://edpb.europa.eu/our - work - tools/our - documents/guidelines/guidelines - 22019 - processing - personal - data - under - article - 61b_en . 254 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 Page 115 of 142 Section 6.4 , Google processes two types of personal data for which it qualifies as independent data controller: 1. the processing of personal data relating to the visits to Google’s public websites, and 2. the creation of a Google account to become a GCP admin (if that is still necessary if an organisation follows the offline onboarding process). Section 12.1.4 below argues that Google also acts as independent data controller for (part of the) Website Data relating to use of the Admin Console.

Government organisations that use the tested GCP - services enable Google to process personal data for these two different purpose s , and hence can be qualified as joint controllers. 255 However, as analysed in Section 2.3 about the enrolment framework, Google does not have a joint controller agreement with the Dutch government. Absent such an agreement, Google has to be qualified as third party for these two types of data processing. 256 Therefore, government organisations have to assess the compatibility of this ‘further processing’ by Google . Table 4 : Types of personal data and purposes of the processing in relation to Google’s role Purposes/personal data Google as processor Google as authorised controller 257 Google as independent data controller Content Data 1. t o provide, maintain and improve the Services (…) and (TSS) 2. to identify, address and fix security threats, risks, bugs and other anomalies; 3. to develop, deliver and install updates to the Services (…) n/a n/a Account Data 1.

Billing and account management (…) 2. Improving and optimizing the performance and core functionality of (…) and security (…) of the Cloud Services and TSS; 3. Internal reporting (…) 4. Abuse and threat detection, (…) 5. Processing of Personal Data in support tickets and support requests (…) 6. Receiving and using Feedback; 7. Complying with legal obligations n/a Diagnostic Data n/a Support Data n/a Website data Processing of Cookie Data publicly accessible GCP web pages, including pages with tech and legal information for 3 purposes mentioned in cookie banner + See Section 12.1.4 for Admin Console Below, only the potentially valid legal grounds for government organisations will be discussed. The legal ground of vital interest (Article 6 (1) (d) GDPR) is not discussed, since nor Google nor Dutch government organisations have a vital (lifesaving) interest 255 Idem. 256 Google disagrees with the analysis that absent a joint controller agreement, Google would qualify as third party.

Google reply to this DPIA, 23 October 2025. 257 Google disagrees with this point of view. See footnote 256 . DPIA on Google Cloud Platform public version 11 June 2026 in processing personal data for the identified purposes via the tested four GCP - services. 12.1 Legal grounds for government organisations 12.1.1 Consent Article 6 (1) (a) GDPR reads: “ the data subject has given consent to the processing of his or her personal data for one or more specific purposes” Government organisations generally should not ask for consent from inhabitants if personal data are processed for public tasks, or as part of a task primarily exercised under private law. T he fact that government organisations are public sector organisations makes it difficult to rely on consent for processing. In the context of Recital 43 of the GDPR, the EDPB explains: “ whenever the controller is a public authority, there is often a clear imbalance of power in the relationship between the controller and the data subject.

It is also clear in most cases that the data subject will have no realistic alternatives to accepting the processing (terms) of this controller. The EDPB considers that there are other lawful bases that are, in principle, more appropriate to the activity of public authorities. ” 258 Dutch government organisations do not rely on consent for the 3 agreed processor purposes, nor for the 7 agreed further processing purposes. Google will only process the GCP admin data for the agreed compatible processing purposes for the Service Data. Google is willing to add a description of Account Information to the definition of Service Data in the enrolment framework with the Dutch government . Google has also assured it will not use the NID - cookie to show ads to signed out admins. As quoted in Sections 3.5.2 and 10 , Google wrote that it will ask for consent if it starts using cookies for advertising purposes in GCP .

This information creates a problem with regard to the applicable legal ground for government organisations . A potential future request from Google to admins for consent for tracking purposes is unlikely to lead to validly given consent. Government organisations must protect the personal data of employees when they perform work tasks against processing for unauthorised purposes. If an admin hastily clicks ‘accept’ (to prevent the hassle of opting - out), t he resulting data processing for Google’s own purposes can potentially lead to security and data breaches since admins are generally not mandated to provide consent on behalf of their organisation. 12.1.2 Necessary for the performance of a contract Article 6 (1) (b) GDPR reads: “processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract.”

Government organisations may require employees with admin roles to work with the tested GCP - services to carry out the tasks included in their job description. As described in Section 7.2 , Dutch government organisations have various potential interests in using the GCP - services , including increased flexibility, cost saving and security reasons . 258 EDPB, Guidelines on consent , paragraph 3.1.1. DPIA on Google Cloud Platform public version 11 June 2026 Page 117 of 142 To be able to successfully invoke the legal ground of ‘performance of a contract’ with respect to the admin employees , the processing of the personal data via the tested GCP - services has to be strictly necessary for the performance of the contract with each individual data subject ( admin ). If a government organisation choose s to use the tested services, the a dmins must necessarily use the Admin Console for the configuration and management of the GCP - services , and their admin activities will have to be recor ded in audit logs .

They must also necessarily visit some of the publicly accessible cloud.google.com pages to look up technical and legal information. As quoted in Section 5.4.1 , Google has committed to only process these data for the same 3 purposes mentioned in the cookie banner on the admin console . 12.1.3 Legal obligation Article 6 (1) ( c ) GDPR reads: “ processing is necessary for compliance with a legal obligation to which the controller is subject ” Government organisations are required by the GDPR and other specific security rules to secure data. They may rely on t he legal ground of Article 6(1) c of the GDPR for the processing of admin activity logs , system - generated server logs and Google’s security logs , including storing these data for the period necessary “ to ensure a level of security appropriate to the risk ” (Article 32 GDPR) . 12.1.4 Necessary for a task in the public or a legitimate interest Article 6 (1) (e) GDPR reads: “processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller”.

Article 6 (1) (f) GDPR reads: “processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child . Public sector organisations are excluded from relying on legitimate interest when processing personal data for public services. The last sentence of Article 6 (1) of the GDPR explains: “Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks.” This excludes the application of the legitimate interest ground for processing carried out by public sector organisations in the performance of their tasks. However, the choice to use GCP - se rvices to host Content Data will usually be secondary to the performance of public tasks by government organisations and can therefore be considered as a task primarily exercised under private law, for which the legitimate interest of the organisation can be a valid legal ground for processing.

The legal ground of necessity for a legitimate interest as defined in Article 6(1) f of the GDPR can for example be used in relation to necessary functional and analytical cookies. This follows from the specific Dutch legislative history. As described in Section 10 there is a specific exception in the Dutch Telecommunications Act on the consent - requirement for ‘innocent’ analytical cookies, that is for cookies with no, or relatively small impact on the private life of website visitors. 259 To determine this impact, the Dutch legislator has explicitly referred to the elements of the legitimate interest test 259 Kamerstukken II 2013/14, 33902 (Wijziging van de Telecommunicatiewet (wijziging artikel 11.7a)), nr. 3 (Memorie van Toelichting). DPIA on Google Cloud Platform public version 11 June 2026 in Article 6(1) f of the GDPR (at the time, the similar test in Article 8(f) of the Data Protection Directive).

applies Data Protection Directive Art. 8(f)

Both legal grounds (public interest and legitimate interest) require an assessment of the necessity of the personal data processing, of the proportionality and availability of alternative, less infringing means to achieve the same legitimate purposes (subsidiarity). As described in Sections 3.3.3 , 3.5.1 a nd 10 since Q2 2025 Google shows the same cookie consent banner on the Admin Console and on the publicly accessible cloud.google.com pages. Google does not provide a limitative overview of the information it reads from admin devices through telemetry events, cookies and URL parameters. It follows from the technical analysis that these data are personal data relating to an identifiable admin. Though Google has published new documentation about the Telemetry Data , it has refused to expand its cookie information . In t he absence of a consent request from Google for this personal data processing , government organisations have to assess if Google is exempted from the consent requirement for the reading of information from end user device in the Dutch Telecommunications Act and if Google can rely on the necessity of this personal data processing for its own legitimate interest.

Though Google has introduced a cookie banner that mentions 3 purposes for the processing on the Admin Console, and uses the same text on the publicly accessible cloud.google.com, Google fails to adequately inform admins about the reading of information from their devices . Even if admins use tools to inspect the cookie traffic, and actively look up Google’s general C ookie P olicy, documentation is missing about many cookies that Google sets and reads . The available descriptions in Google’s cookie policy do no t meet the specific requirements detailed by the ECJ in the Planet 49 ruling. 260 Finally, Google does not provide explicit assurances that the processing of personal data resulting from the use of Google Analytics cookies is limited to measuring website performance, as opposed to measuring people. As quoted in Section 10 Google explained that the cookies set via the Admin Console are used for analytics ‘ how people use our services’ .

However, Google has committed to provide a reassuring explanation to its Cookie Policy that it won’t use the NID cookie for advertising if set by advertising free websites such as cloud.google.com. Google has also assured that it will not use cookies set by both types of site to show ads to admins . Since this is a DPIA that assesses the data protection risks for data subjects, and not an ePrivacy compliance audit, government organisations that are in doubt about the legal ground for Google’s data processing with cookies should consult the Dutch Data Protection Authority. In sum , government organisations can rely on an appropriate legal ground for most of the tested and contracted GCP data processing with Google in a role as processor. If government organisations are concerned about Google’s l ack of information about the personal data it process es with cookies, and the proportionality of the processing, they should consult the Dutch Data Protection Authority . 260 ECJ, Case C - 673/17, ECLI:EU:C:2019:801 .

DPIA on Google Cloud Platform public version 11 June 2026 Page 119 of 142 12.2 Compatibility of processing by Google as authorised controller As described in S ection 6.3 and visualised in Table 4 above, through the (amended) CMA the Dutch government authorises Google to further process the Account, Diagnostic, Support and Website Data for a limitative list of 7 specific purposes. In the list the purpose descriptions are abbreviated by Privacy Company to improve readability. The full purpose descriptions are listed in Section 5.3 . 261 1. Billing and account management (…) . 2. Improving and optimizing the performance and core functionality of (…) and security (…) the Cloud Services and TSS . 3. Internal reporting (…) . 4. Abuse detection, prevention and protection (…) . 5. Processing of Personal Data in support tickets and support requests (…) . 6. Receiving and using Feedback . 7. Complying with legal obligations .

The Dutch government has assessed the legitimacy of the further processing purposes by taking the following 5 criteria into account (following Article 6 (4) of the GDPR ) : a) any link between the purposes for which the personal data have been collected and the purposes of the intended further processing; b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller; c) the nature of the personal data , in particular whether special categories of personal data are processed, pursuant to Article 9, or whether personal data related to criminal convictions and offences are processed, pursuant to Article 10; d) the possible consequences of the intended further processing for data subjects; e) the existence of appropriate safeguards , which may include encryption or pseudonymisation. The nature of the personal data ( criterion c ) is non - sensitive (never Content Data , and not special categories of data) .

The possible consequences of the processing ( criterion d ) are limited, because Google contractually commits to only process these personal data when necessary for the agreed specific legitimate business purpose s. There is a clear link between Google’s activities as a processor, and the need to perform some data processing to be able to offer paid processor services to Enterprise customers . Google cannot perform this data processing as a processor based on (revokable) instructions from its customers ( criterion a ). Additionally, the processing is limited to specific circumstances ( criterion b ) . Some of these specific circumstances are elaborated in Sections 5.3.1 , 5.3.2 and 5.3.3 , for purposes 7, 4 and 2 respectively. For example, i n case of a request to disclos e these personal data to government authorities, Google contractually commits to only disclose when strictly necessary to comply with Legal Process , following specific steps to attempt to inform the Dutch government organisation and assure legitimacy of the request.

Below, the compatibility of the remaining four purposes is analysed, purposes no. 1, 3, 5 and 6 , specifically relating to criteria b and e . 261 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 For the first purpose , b illing and a ccount m anagement, besides the necessity to use some personal data to send invoices, Google can process Contact Data from its commercial contact persons for its own legitimate customer relationship purposes , separate from its role as data processor . In practice, this processing of Commercial Contact Data will be limited to the handful of persons involved with procurement of IT services ( criteria b and c ), and the consequences are negligible , as it is the job task of procu rement officers to maintain relations with suppliers ( criterion d ). For the third purpose , the creation of internal (financial and forecast) reports (including use for product strategy), Google will aggregate and anonymise ‘ Service Data ’ to eliminate personal details (i.e. from the Account, Diagnostic, Support and Website Data).

This is an appropriate safeguard under criterion e to ensure compatibility of the processing for this purpose. The fifth purpose is the processing of Support Data. Though Google is a processor for the provision of Technical Support Services, Google has insisted on a role as data controller for th e further processing of the Diagnostic and Account Data in the se personal data . 262 The re is a clear link between the initial collection purposes and the further processing to improve services for all customers ( criterion a ) . The context is a voluntary request for assistance from Google. Organisations can also engage another party/implementation partner for support questions ( criterion b ). The sixth purpose is the processing of Feedback Data. As described in Section 3.1.2 Google enables admins to share Feedback Data through a web form . Google does not have a direct contractual relationship with admins ( criterion b ).

If an admin submits such a request, Google adds Telemetry Data to the request. Even though Google considers Feedback Data to be part of Service Data (and never as ‘Content Data’) , the submitted data can include screenshots or descriptions of sensitive or confidential personal data ( criterion c ). Google never actively asks for such Feedback, and does show a warning to admins not to upload sensitive data. Government organisati ons may warn admins never to provide Feedback, but Google does not allow , and will not develop an option for government organisations to centrally disable the Feedback form ( criterion e ). In sum the processing for 6 of the 7 agreed legitimate business purposes is compatible with the agreed processor purposes. In relation to the processing of Feedback Data though, the processing by Google does not pass the compatibility test . G overnment organisations will have to take organisational measures to prevent the processing. 12.3 Compatibility of processing by Google as third party controller 263 As described in Section 6.4 , Google acts as an independent data controller for the processing of personal data relating to the visits to its public GCP web pages .

Admins may necessarily have to visit some of the se pages to look - up essential technical or legal information. 264 Google can only obtain the publicly accessible Website Data as a result of the decision of a government organisation to use the tested GCP - services with Google in a role as 262 A ccording to Google, its role as data controller is fact based, not an opinion from Google. Google reply to this DPIA, 23 October 2025. 263 See footnote 29 . 264 Google believes the publicly accessible webpages should be out of scope of the DPIA. Google reply to this DPIA, 23 October 2025. This is a non sequitur. See the explanation about the need to assess data processing via the publicly accessible webpages in Section 3.5.2 . DPIA on Google Cloud Platform public version 11 June 2026 Page 121 of 142 data processor. However, for this data processing Google factually determines the purposes and means .

Based on Article 28 (10) of the GDPR, this means that Google qualifies as controller. Article 28 (10) GDPR reads: “Without prejudice to Articles 82, 83 and 84, if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing.” G overnment organisations have to assess the compatibility of th is ‘further’ processing of personal data by Google as independent data controller. As explained above, in Section 12.2 the assessment must be based on at least the 5 criteria mentioned in Article 6(4) of the GDPR. There is a clear link between Google’s activities as a processor, and the need to process some publicly accessible Website Data ( criterion a ) to provide legal and technical information . The context in which Google collects the public Website Data ( criterion b ) is of an involuntary relation ship .

Google does not have a contractual relationship with admins, only the government organisation does . A Dutch government organisation that decides to use the tested GCP - services may oblige an admin to be subjected to this data processing. As described in Section 12.1.2 government organisations can only invoke th e legal ground of necessity to perform a (job) contract if they are in control that the data processing is strictly necessary in relation to each admin. Though Google has committed to only process these data to deliver services, to enhance the quality of services and to analyze traffic (as mentioned in the cookie banner), Google does not disclose what cookies and personal data it processes for these purposes, with what retention period. The nature of the personal data collected by Google as publicly accessible Website Data ( criterion c ) is non - sensitive (never Content Data, and not special categories of data).

The possible consequences of the processing of the publicly accessible Website Data ( criterion d ) are hard to assess . Google has explained it will not use the NID - cookies set in the context of GCP usage (Admin Console and public GCP - pages ) to show ad s. However, Google also applies processes personal data through other analytical cookies that can potentially be qualified as tracking cookies. As quoted in Section 12.1.4 , Google does not limit the processing to the measurement of pages instead of measuring activities of (identifiable) people. Finally, in relation to criterion e, Google provides a cookie information banner on the GCP - pages describing three purposes of the processing. These purposes are linked to the agreed processing purposes . Google will also add an explanation to its Cookie Policy that it will not use the NID - cookie set on the GCP pages to show ads. In sum , the data processing related to visits to t he publicly accessible GCP - pages can be compatible with the authorised processing purposes if government organisations use this DPIA to explain to admins how they should read the banner and Google’s explanation.

If they are in doubt about the compatibility of the processing, they should consult the Dutch Data Protection Authority. DPIA on Google Cloud Platform public version 11 June 2026 13. Special categories of personal data Special categories of data are “ data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, data concerning a natural person's sex life or sexual orientation ” (Art. 9(1) GDPR). Additionally, based on Article 10 GDPR, the processing of personal data relating to criminal convictions and offences or related security measures is similarly restricted. As explained in S ection 2.4 of this DPIA, government organisations can process classified information, personal data of a sensitive nature and special categories of data in the tested GCP - services as part of the Content Data .

It is up to the individual government organisation to assess the legal ground , purposes and impact of this data processing. Even though government organisations cannot technically prevent admins from sharing Content Data, including special categories of data, through Google’s Feedback form, Google does warn admins not to upload sensitive data. If government organisations also structurally warn admins not to use this form, it is unlikely that admins will share special categories of d ata through this form. As explained in Section 3.3.2 , Google can process some Content Data such as names of tables and admin queries in the Diagnostic Data, as part of the audit logs. Government organisations can prevent the secondary data processing by Google as authorised controller of these Diagnostic Data by adopting a policy not to us e special categories of data to name files, storage and databases. The analysis of the telemetry events in Section 3.3.3 shows that Google did not collect any Content Data in the intercepted telemetry events , nor e - mail addresses or names of admins .

In sum , Dutch government organisations can decide (based on currently valid government cloud policy) if they want to upload special categories of data to the tested GCP - services (C ontent Data ) . They can prevent Google from further processing special categories of data in the Diagnostic Data . 265 14. Purpose limitation The principle of purpose limitation is that data may only be “ collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statis tical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes ” (Article 5 (1) (b) GDPR). Essentially, this means that the controller must have a specified purpose for which he collects personal data, and can only process these data for purposes compatible with that original purpose. 265 See footnote 29 .

DPIA on Google Cloud Platform public version 11 June 2026 Page 123 of 142 Data controllers must be able to prove, based on Article 5(2) of the GDPR, that they comply with this principle (accountability). If follows from the definition of data controller, quoted in Section 6.1 of this report that that only controllers may take decisions about the purposes and means of the data processing, including the decisions to process the data for additional purposes . This section does not provide a list of possible purposes for which government organisations may want to use the tested GCP - services . This is up to the government organisations. This section only assesses if government organisations are in control of the purposes for which Google processes the personal data . As data processor, Google may not process the personal data for other than the three authorised purposes . The Dutch government also authorises Google to process some personal data for 7 authorised further processing purposes as controller , when necessary for Google’s legitimate business purposes .

Government organisations should be able to rely on the contractual guarantees and privacy controls to prevent any personal data from being processed beyond these ( 3 + 7 ) authorised purposes. As more extensively analysed in Sections 12.1.4 and 12.3 , this DPIA flags shortcomings in Google’s compliance with ePrivacy law . If government organisations are in doubt about their legal ground for this data processing, they should consult the Dutch Data Protection Authority. That analysis is not repeated here. 15. Necessity and proportionality 15.1 The concept of necessity The concept of necessity is made up of two related concepts, namely proportionality and subsidiarity. The personal data which are processed must be necessary for the purpose pursued by the processing activity. Proportionality means the invasion of privacy and the protection of the personal data of the data subjects is proportionate to the purposes of the processing.

Subsidiarity means that the purposes of the processing cannot reasonably be achieved with other, less invasive means. If so, these alternatives have to be used. Proportionality demands a balancing act between the interests of the data subject and the data controller. Proportionate data processing means that the amount of data processed is not excessive in relation to the purpose of the processing. If the purpose c an be achieved by processing fewer personal data, then the controller needs to decrease the amount of personal data to what is necessary. Therefore, essentially, the data controller may only process the personal data that are necessary to achieve the legitimate purpose but may not process personal data he or she may do without. The application of the principle of proportionality is thus clos ely related to the principles of data protection from Article 5 GDPR. 15.2 Assessment of the proportionality The key questions are: are the interests properly balanced?

And does the processing not go further than what is necessary? To assess whether the processing is proportionate to the interest pursued by the data controller(s), the processing must first meet the principles of Article 5 of the GDPR. Data controllers have to comply with this legal conditions in order to make the dat a protection legitimate. Below, these conditions are elaborated in three subsections: 1. Lawfulness, Fairness and Transparency DPIA on Google Cloud Platform public version 11 June 2026 2. Data minimisation and privacy by design 3. Storage limitation 15.2.1 Lawfulness, Fairness, and Transparency Data must be ‘ processed lawfully, fairly and in a transparent manner in relation to the data subject ’ (Article 5 (1) (a) GDPR). This means that data subjects (in this case the admins) must be informed about the processing of their data, that all the legal conditions for data processing are adhered to, and that the principle of proportionality is respected.

Lawfulness As assessed in Section 12.3 of this DPIA, Google Cloud ‘further’ processes (including with the help of Google Analytics) personal data relating to the publicly accessible Website Data for three specific purposes closely related to the agreed processor purposes . In view of Google ’s information about these 3 purposes in its new cookie banner, and Google’s commitment to explain that it will not use the cookie data to show ads to admins, the processing is not clearly unlawful. Transparency The principle of transparency requires controllers to provide complete transparency about the data processing. This transparency also ensures that data subjects can exercise their rights. As analysed in Sections 10 and 12.1.4 Google as a processor fails to provide the required transparency about the cookies it sets and reads (including where it collects Cookie Data through the Telemetry Data).

Cookies As described in Section 3.5 Privacy Company observed many different cookies set through use of the Admin Console and accounts.google.com that are not documented by Google. This is the case for some observed cookies with the word ‘_Secure’ and the names APISID, OSID, RAPT, SAPISID, SIDCC and SSID, while the contents of these cookies are long enough to contain a unique identifier. Google has refused to document these cookies (as quoted at the end of Section 3.5.2 ). According to Google, its current descriptions in its Cookie Policy suffice. Google does commit to explain in its Cookie Policy that it will not use the (quadruple use) NID - cookie to show ads to admins. Google has refused to add the sentence that is has added in the cookie banner for Google Workspace Enterprise, namely, that it does not use cookies for advertising purposes. As th e EDPB explains , information about the data processing must minimise surprises: “ the first layer/ modality should also contain information on the processing which has the most impact on the data subject and processing which could surprise them.

Therefore, the data subject should be able to understand from information contained in the f irst layer/ modality what the consequences of the processing in question will be for the data subject ( … ). ” 266 Since Google is known as an advertising company, Google should inform admins both on the Admin Console and on the publicly accessible GCP - pages in the cookie banner that it will not use any of the cookies it sets and reads on the Admin Console and on the publicly accessible GCP - pages for any advertising purposes, including for combining or advertising outside of the GCP - context. 266 EDPB transparency 2018 DPIA on Google Cloud Platform public version 11 June 2026 Page 125 of 142 Recital 60 of the GDPR explains: “ The controller should provide the data subject with any further information necessary to ensure fair and transparent processing taking into account the specific circumstances and context in which the personal data are processed. ” Omission of th e essential purpose limitation information is not fair to admins.

However, government organisations can mitigate this risk by using this DPIA to inform admins. Telemetry Data As described in Section 3.3.3 Privacy Company observed 33 + 94 different types of telemetry events. Google has refused to develop a Diagnostic Information Tool for admins to observe the Telemetry Data Google collects in a more accessible way than having to intercept the outgoing network traffic. Google initially refused to document the Telemetry Data “ because of the disproportionate level of time and effort that would be required to develop and maintain comprehensive documentation. 267 Another argument Google used was: “ because of the significantly lower number of GCP users in a typical customer organization compared to Workspace (e.g. dozens compared to potentially thousands) and the disproportionate level of time and effort that would be required to develop and maintain comprehensive documentation. ” 268 Privacy Company assessed that these two arguments did not result in valid exceptions on the transparency obligations from Article 13 of the GDPR, not for Google as a data controller for the publicly accessible GCP - pages, nor for a Dutch government organisation as controller for the Admin Console.

A low number of users does not change the impact of a lack of transparency on each individual data subject. And for a global company the size of Google, with a global employee headcount of approx.180.000 employees 269 the required level of time and effort to document Telemetry Data is unlikely to qualify as a disproportionate effort, especially in view of Google’s technical capacity to develop automated tools to document the personal data it processes. 270 Google does not publish statistics how many employees it hires per division (Services, Google Cloud, other). At the end of 2025, Alphabet is expected to hire 190.000 employees. According to an in - depth analysis, it is plausible that most employees work fo r the Services Division, but also a very high number for Google Cloud. 271 267 Google reply to questions SLM , 21 March 2025. 268 Idem. 269 Source: Number of Google Employees (2024 ), 6 March 2025, URL: https://explodingtopics.com/blog/how - many - people - work - at - google 270 “ Soweit die Beklagte meint, es sei für Großunternehmen, die wie sie einen umfangreichen Datenbestand verwalten würden, mit den ihr zur Verfügung stehenden Ressourcen wirtschaftlich unmöglich, Dateien auf personenbezogene Daten zu durchsuchen und zu sichern, verfängt dies nicht.

Es ist Sache der Beklagten, die sich der elektronischen Datenverarbeitung bedient, diese im Einklang mit der Rechtsordnung zu organisieren und insbesondere dafür Sorge zu tragen, dass dem Datenschutz und den sich hieraus ergebenden Re chten Dritter Rechnung getragen wird. ”, OLG Köln, Urteil vom 26.07.2019 - 20 U 75/18 271 0Deep Research, Alphabet's Human Capital: An Analysis of Headcount Distribution and Workforce Dynamics, 20 May 2025, URL: https://0deepresearch.com/posts/2025 - 05 - 20 - alphabet - s - human - capital - an - analysis - of - headcount - distribution - and - workforce - dynamics/ DPIA on Google Cloud Platform public version 11 June 2026 Google later agreed to publish adequate documentation about the Telemetry Data, including relevant examples. As described in Section 3.3.3 the new information is adequate, even though it does not include an exhaustive list of the events.

Absent detailed documentation about the information Google c ollects as Website Data , it is difficult for government organisations to assess the proportionality of the data processing by Google . This difficulty to assess the proportionality applies to the processing of these personal data by Google in all three GDPR roles: as processor , as authorised controller for the agreed legitimate business purposes , and as independent data controller . 272 15.2.2 Data minimisation and privacy by default The principles of data minimisation and privacy by default require that the processing of personal data be limited to what is necessary. The data must be 'adequate, relevant and limited to what is necessary for the purposes for which they are processed' (Article 5(1)(c) of the GDPR). This means that the controller may not collect and store data that are not directly related to a legitimate purpose.

According to this principle, the default settings for the data collection should be set in such a way as to mi nimise the data collection by using the most privacy friendly settings. Google’s design choice to use a mixed use NID - cookie on both types of websites, is the opposite of privacy by default . 273 To ensure the data protection rights of admins, Google has to create work - arounds and offer contractual assurances that it will not combine data from the work environment with externally collected data . For example, data about visits to other websites with advertisements that may read Google cookies set in the work environment. Absent complete cookie documentation government organisations cannot assess if the data are limited to what is necessary for the authorised purposes. 274 Google has also by default enabled the collection of Feedback Data , and has refused to provide an option to centrally disable this data collection.

As mentioned in Section 12.2 , the processing of Feedback Data is open ended and opaque : admins can include any personal data, and Google also automatically adds a selection of Telemetry Data to the Feedback . As analysed in Section 12.1.1 admins cannot provide valid (authorised and informed ) consent to Google to process these data. As described in Section 3.1.1 , Google had enabled its Gemini generative AI - service . Privacy Company was unable to find a switch in the A dmin C onsole to disable default enabling of new unprocured services that can process Content Data in a new way and Google has refused to create an option for organisations to prevent this kind of messaging to admins . 15.2.3 Storage limitation The principle of storage limitation demands that personal data are only retained as long as necessary for the purpose in question. Data must be “ kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed ” (article 5 (1) (e), first sentence GDPR).

This principle therefore demands that personal data are deleted as soon as they are no longer necessary to achieve the purpose pursued by the controller. The text of this p rovision goes on to clarify that “ personal data may be stored for longer periods 272 See footnote 29 . 273 According to Google it is sufficient that the company has agreed and will document publicly that it will not use the NID - cookie for advertising purposes. Reply Google to this DPIA, 23 October 2025. 274 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 Page 127 of 142 insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject ” (article 5 (1) (e), second sentence, GDPR).

As described in Section 11 of this report, Google has explained that it retains the Telemetry Data for a maximum period of 63 days, after which they are completely deleted (not anonymised) . Google has explaine d it retains most types of Service Data for a set period of up to 180 days , with longer periods for security, fraud and abuse prevention; for complying with legal or regulatory requirements; and for complying with tax, accounting or financial requirements. Since Google has refused to disclose the criteria it uses to determine the retention periods shorter than 180 days , this DPIA assumes that Google retains all personal data in Diagnostic Data for the maximum period of 180 days ( except for the Telemetry Data which are completely deleted after 63 days, and barring the exceptions for longer retention periods mentioned above). In sum, based on the current lack of transparency about the cookies Google sets and reads , including where it collects Cookie Data through the Telemetry Data, government organisations cannot assess the proportionality of the data processing by Google.

By using a mixed use NID - cookie in the Admin Console and on the GCP - pages , Google ignores the obligation for data controllers to apply privacy by design / privacy by default . Similarly, by creating a Feedback form and refusing to give government organisations a choice to disable this data processing , Google prevents government organisations from applying effective technical privacy by design / privacy by default measure s . Google refuses to specify the retention periods of the personal data in the Account , Support and (restricted access) Website Data , other than a general indication of 180 days for Service Data (including Telemetry Data) , which may be exceeded in unknown circumstances. In spite of Google’s commitments to become more transparent about the NID - cookie, t hese circumstances lead to the conclusion that the current Website D ata processing via Google does not comply with the proportionality requirements. 15.3 Assessment of the subsidiarity The key question is whether the same goals can be reached with less intrusive means.

The tested four GCP - services were selected in order to help government organisations compare these DPIA results with the outcomes of similar umbrella DPIAs on other c ommonly available public cloud services from AWS and Oracle. SLM Rijk has also commissioned a DPIA on similar cloud service s from the German provider Stackit and the French provider OVH Cloud. Dutch government organisations can use th is DPIA on the Google Cloud Platform services to decide if they can take sufficiently effective organisational measures to ensure GDPR - compliant processing of personal data from the admins . In relation to the decision to proces s Content Data in a public cloud environment managed by a US American company , government organisations have to follow the Dutch government cloud policy. As quoted in Section 7.3 , the Dutch government has announced a DPIA on Google Cloud Platform public version 11 June 2026 tightening of the current “ Ye s if ” policy , and the creation of a national government cloud . 275 16.

Rights of data subjects The GDPR grants data subjects the right to information, access, rectification and erasure, object to profiling, data portability and file a complaint. It is the data controller’s obligation (in this case, a Dutch government organisation) to provide informa tion and to duly and timely address these requests. If the data controller has engaged a data processor (in this case: Google ), the GDPR requires the data processing agreement to include that the data processor will assist the data controller in complying with data subject rights requests. As discussed in Section s 6.2 and 6.3 , Google aims to qualify as data processor for all data processing , with the specific exceptions where the Dutch government allows Google to 'further’ process limited personal data for its own legitimate business purposes. 276 However, as described in Section 6.4 , and analysed in Section 12.3 , Google acts as data controller for the public GCP - pages .

In these situations, Google must honour the GDPR data subject rights directly . 16.1 Right to information Data subjects have a right to information. This means that data controllers must provide people with easily accessible, comprehensible and concise information in clear language about, inter alia, their identity as data controller, the purposes of the data processing, the intended duration of the storage and the rights of data subjects. One of the purposes of this umbrella DPIA is to help government organisations that wish to use the tested GCP - services to better inform their employees about the agreed scope and purposes of the data processing. However, as assessed in Section 15.2.1 above, the information Google provides to its Enterprise customers in the framework contract, and directly to admins , about the processing of personal data through the tested services is incomplete. The identified information omissions are: • T he cookies used on the Admin Console • The cookies used on the public GCP - pages. • The effective retention periods (including retention of pseudonymised personal data) in all three of Google’s GDPR roles (excluding the new information about the Telemetry Data).

Without this information, admins can not fully understand what personal data are processed and for what purposes. In sum , a bsent exhaustive documentation from Google about the cookies and effective (not maximum) retention periods, result in a situation where Dutch government organisations cannot fully comply with their obligation to inform employees about the authorised further processing by Google (scope, nature and purposes of the processing). 275 Kamerbrief staatsecretaris en minister van Economische Zaken over de Initiatiefnota ‘Wolken aan de horizon’, 17 January 2025, p. 1 - 2, URL: https://open.overheid.nl/documenten/71103a99 - b696 - 42fd - b34a - c83f979b3201/file . 276 See footnote 29 . DPIA on Google Cloud Platform public version 11 June 2026 Page 129 of 142 16.2 Right to access Secondly, data subjects have a (fundamental) right to access personal data concerning them. Upon request, data controllers must inform data subjects whether they are processing personal data about them (directly, or through a data processor).

If this is the case, they must provide data subjects with a copy of the personal data processed, together with information about the purposes of processing, recipients to whom the data have been transmitted, the retention period(s), and information on thei r further rig hts as data subjects, such as filing a complaint with the Data Protection Authority. Google undertakes as a data processor to assist its customers with such requests. As described in Section 3.6 Google provided a unsatisfactory reply to the DSAR with reference to 15 sources accessible for the admin to download personal data. Google also automatically asked for a potential delay of 2 months to provide more information. 2 months after the DSAR was submitted, Google informed Privacy Company that the delay was unnecessary, that it could not provide more access. Privacy Company accessed the referred source s . Only some of these sources contained relevant personal data.

Below, this DPIA assesses if t he reply is complete. Incomplete As Section 3.6 notes, the access Google provide d, was incomplete . However, Google has committed to provide a full and timely reply to future DSARs, with more context. Google has commit t ed to “ provide admins with the telemetry data relating to them, with a brief explanation about the concept of telemetry data, and how that data are typically used by GCP (including circumstances where it may be pseudonymised or anonymised). ” 277 Google has also committed to “ provide a user with web server logs relating to them, on request and in accordance with GDPR, via a DSAR. ” And “ provide an admin with web server logs relating to the users those logs identify, on request and in accordance with GDPR, via a support ticket . ” “ In each response, we will provide the user or the admin (as appropriate) with an explanation about the concept of such logs, and how they are typically used by GCP. ” 278 Google also committed to provide a link to its general explanations of exceptions to the data provided to a DSAR . 279 277 Google reply to questions SLM , 21 March 2025. 278 Google reply to questions SLM, 18 July 2025. 279 Idem .

This is a link to the page “I nformation not provided in response to an access request ” , undated, URL; https://support.google.com/policies/answer/10972441 (page last visited 2 May 2025). DPIA on Google Cloud Platform public version 11 June 2026 Privacy Company has not retested the GCP services to file a new DSAR. Two aspects that were missing from the DSAR output w ere (i) information about the retention periods of the different categories of personal data, and (2) information about the recipients. It is unclear if Google will provide this information to data subjects as well. In sum , it requires a new test to assess if Google (both as processor and as authorised controller) enables government organisations to ful ly comply with their obligations to provide their admin - employees with comprehensible access to the personal data relating to their use of the tested GCP - services . 16.3 Right of rectification and erasure Thirdly, data subjects have the right to have inaccurate or outdated information corrected, incomplete information completed and - under certain circumstances - personal information deleted or the processing of personal data restricted.

Google does not offer any options for customers or admins to erase Diagnostic and Website Data. In view of security obligations, organisations need to be able to access the Admin user logs and system generated server logs to detect violations of their security and privacy policies, and mitigate the consequences of possible resulting data breaches. However, organisations do not have access to the Telemetry Data, even though a data subject (admin) may rightfully want to ask for deletion. Google does not commit to delete these data if a government organisation terminates the individual job contract with an admin - employee. However, in view of the relatively short effective retention period of 63 days, it is questionable if it is worthwhile for an employee to file a complaint with the Dutch Data Protection Authority. Whether this merits complaint handling is up to the Dutch DPA. 280 16.4 Right to object to profiling Fourthly, data subjects have the right to object to an exclusively automated decision if it has legal or similar significant effects.

When Google acts as processor and as authorised data controller, it contractually commits not to use the personal data from its customers ( the admins ) for profiling purposes, unless the admin has provided specific instructions. 16.5 Right to data portability Employees have a right to data portability if the processing of their personal data is carried out by automated means and is based on their consent or on the necessity of a contract. As explained in Section 12.1.2 the processing of the Admin Console Website Data by Google on behalf of government organisations should generally be based on the necessity of performing a (employment) contract with that employee. However, even if employees would have the right to data portability, t he exercise is generally problematic in relation to government - internal documents and data. Admins cannot use t his right to demand export of confidential data and personal data from the government organisation (Article 20(4) of the GDPR) . 280 According to Google admins can contact the Google privacy team or file a support ticket if they have a question about erasure of personal data.

Google reply to this DPIA, 23 October 2025. DPIA on Google Cloud Platform public version 11 June 2026 Page 131 of 142 16.6 Right to file a complaint Finally, government organisations as controllers must inform their employees about their right to complain, internally to their Data Protection Officer (DPO), and externally, to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens). In sum , a retest will have to be performed to assess if Google puts government organisations in a position to (fully) honour the rights of data subjects. DPIA on Google Cloud Platform public version 11 June 2026 Part C. Discussion and Assessment of the Risks This part concerns the description and assessment of the risks for data subjects. This part starts with an overall identification of the risks to the rights and freedoms of data subjects as a result of the processing of the ir personal data as part of the Content Data, and risks for admins resulting from the processing of Account, Diagnostic , Support and Website Data .

The risks will subsequently be classified according to the likelihood they might occur, and the impact on the rights and freedoms of the data subjects when they do. 17. Risks 17.1 Identification of risks Below, a general distinction is made between the risks of the processing of Content Data on the one hand, and the metadata on the other hand. Subsequently, 13 specific data protection risks are identified . 3 of these ( currently low ) risks relate to the processing of Content Data , namely data transfer to third countries , collection of Feedback Data and potential unavailability of essential services. The remaining 10 risks relate to the processing of the Account, Diagnostic, Support and Website Data. Generally speaking, data protection risks can appear in the following categories: • inability to exercise rights (including but not limited to privacy rights) • inability to access services or opportunities • loss of control over the use of personal data • discrimination • identity theft or fraud • financial loss • reputational damage • physical harm • loss of confidentiality • re - identification of pseudonymised data or • any other significant economic or social disadvantage 281 These risks have to be assessed against the likelihood of the occurrence of these risks (the probability) and the severity of the impact.

The UK data protection commission ICO provides the following guidance: “ Harm does not have to be inevitable to qualify as a risk or a high risk. It must be more than remote, but any significant possibility of very serious harm may still be enough to qualify as a high risk. Equally, a high probability of widespread but more minor harm might still count as high risk. ” 282 In order to weigh the severity of the impact, and the likelihood of the harm for these generic risks, this report combines a list of specific risks with specific circumstances of the specific investigated data processing. 281 ICO, How do we do a DPIA? , Step 5: How do we identify and assess risks? , URL: https://ico.org.uk/for - organisations/uk - gdpr - guidance - and - resources/accountability - and - governance/data - protection - impact - assessments - dpias/how - do - we - do - a - dpia/ 282 Idem . DPIA on Google Cloud Platform public version 11 June 2026 Page 133 of 142 17.2 Assessment of risks 17.2.1 Loss of control through lack of transparency Telemetry Data As described in Section 3.3.3 Privacy Company observed two different types of Telemetry Events, 33 telemetry events sent to region1.analytics.google.com and 94 POST - requests with telemetry data sent to cloud.google.com/log .

After an initial refusal, since 20 December 2025 Google publishes adequate documentation about this data processing, with relevant examples, and context such as the retention period. Initially, Google’s information about the retention periods was not entirely clear. Google explained to SLM it will “ aggregate, anonymise or pseudonymise telemetry data (….) after approximately 50 days. ” 283 In the new public documentation, Google writes that Telemetry Data are completely deleted after 63 days. In view of Google’s new documentation, the probability of the occurrence of the loss of control for Dutch government organisations is minimal. Even though the observed telemetry events do not contain Content Data , t he impact of a lack of transparency is not negligible, since pseudonymous data are still personal data and can be reidentified. However, based on the new documentation admins and compliance officers at Dutch government organisations can compare the documented data processing with the factual data processing.

This results in a minimal probability of occurrence of the loss of control. In spite of the medium impact of this risk, the risks for data subjects are low . 17.2.2 Inability to exercise data subject access rights As assessed in Section 16.2 Google commits to provide access to the Telemetry Data and the Webserver access logs in the future, with context, and to refer to documentation why it does not provide access to specific data . It requires a retest to verify if Google provides t he necessary extra information elaborated in Article 15 (1) GDPR, in particular the provisions c (specific recipients including sub processors) and d (specific retention periods). Government organisations can write a manual for admins explaining what sources they must look - up in addition to Google’s reply if they file a DSAR. This measure can mitigate the omissions. In view of Google’s commitments to provide full and timely access to the Telemetry and Website Data, the probability of occurrence is remote.

Even though t he impact of an access limitation is high, because access to personal data is a fundamental right , the risks for data subjects (admins) have to be qualified as low . 17.2.3 Loss of control through lack of transparency Website Data As described in Section 3.5 Privacy Company observed many different cookies set through use of the Admin Console and accounts.google.com that are not documented by Google. Google has refused to publish the full list of cookies , purposes and retention periods relevant for admins that have to perform their work duties on the Admin Console, or visit public GCP pages with relevant help information. According to 283 Idem. DPIA on Google Cloud Platform public version 11 June 2026 Google, the current descriptions of some of the cookies in its Cookie Policy should suffice. As analysed in Section 15.2.1 , Google has taken measures to inform admins about the three purposes of the processing in a new cookie banner.

Google has also committed to better explain in its general Cookie Policy that it will not use the quadruple use NID - cookie to show ads if the cook ie is set on cloud.google.com or the Admin Console. These measures help lower the probability of occurrence of the loss of control for government organisations, and help lower the impact on the admins (no advertising purposes). The consequences of the potential violation of ePrivacy rules by Google can only be assessed by a data protection authority, but do not automatically lead to data protection risks. Google’s mitigating measures lead to a remote probability of a loss of control, and to a low impact of the processing . Therefore, the risks for data subjects are low . 17.2.4 Loss of control over personal data in inaccessible security logs and small sample of network metadata To protect the security of its services and customers, Google collects its own security logs.

This is one of the agreed legitimate business purposes for which Google may further process personal data, when necessary. Google does not collect IP - addresses (or other personal data) from visitors to websites hosted on GCP in its security logs. Google does take samples of packet metadata. These samples contain source port, source address, destination port, destination address and IP protocol). The sample size is [CONFIDENTIAL] %. However, “ it is extremely unlikely that Google has collected any packet pertaining to a Dutch Government customer’s use of Google Cloud services. It would also not be apparent to us if/ when we had done so. ” Google’s explanations ensure that the probability of this data processing is remote, and the impact is low. Therefore, the risks for data subjects are low . 17.2.5 Loss of control through lack of transparency about profiling Google has explained that government organisations should sign - up via an offline onboarding procedure, not by creating a (consumer) Google Account .

Google has also explained admins can use non - Google accounts. This explanation reduces the probability of profiling via the consumer account to remote, and also reduces the impact to negligible. Therefore the risks for data subjects can be qualified as low . 17.2.6 Loss of control due to data transfer of Content Data Google offers data residency choices for the Content Data in the four tested GCP - services. Dutch government organisations can choose to store these data in the Netherlands and multiple other locations within the European Union. However, Google engineers outside of the EU may need to access Content Data to remediate technical issues: “Service Maintenance: Software and systems engineering, maintenance and troubleshooting. In the course of performing this activity the Sub processor may DPIA on Google Cloud Platform public version 11 June 2026 Page 135 of 142 require limited, authorized access to Customer Data e.g. to remediate technical issues.” 284 As shown in Table 1 in Section 8.2 , this access results in potential data transfers to the USA and to 13 third countries.

Based on Google’s participation to the EU US Data Privacy Framework, the Dutch government can currently rely on an adequate level of data processing in the USA. The EU US DPF also applies to onward data transfers by Google to sub processors in third countries. Even if the probability of disclosure was high, legally, based on the adequacy decision from the European Commission, the impact of disclosure should also be quali fied as low to medium (not in practice though). Therefore the current risks of the data transfer for data subjects whose data are part of the Content Data can be qualified as low . However, in view of the unstable relation with the United States, the Dutch government has to seriously consider the probability that the EU US Data Privacy Framework will be annulled. In that case Dutch government organisations have to perform a Data Transfer Impact Assessment for the use of the 4 tested GCP - services.

This DPIA provides the elements for such a future DTIA, based on Google’s input. If the USA becomes a third country, government organisations cannot rely on SCC. They will have to analyse the probability that Google is forced to disclose personal data in the Content Data to government authorities, in contravention of the GDPR, and take technical measures to prevent access to the personal data in the clear. Probability assessment Google has explained that it has not disclosed any Content Data from the 4 tested GCP - services from Dutch public sector customers to law enforcement agencies in the USA and the 13 third countries . Google is prohibited from providing information about disclosure to secret services, but Google did explain that in the past two years there has not been a single instance of factual data transfer of Content Data from Dutch public sector customers of the tested GCP - services to the 13 third countries.

Google has also assured the Dutch government that it has never provided direct access to any government to any information stored in its data centers, including secur ity services. The most recently SOC - 2 audit confirms that Google complies with its own policy rules to register all requests from government agencies. Google has provided many other assurances that lower the probability of forced disclosure. Googles has technical access restrictions in place, access is actively monitored by security teams, and Google periodically reviews employee justifications for acces s. Google has confirmed it has not detected any unauthorised access by engineers in the third countries in the past 2 years to the Content Data in the tested 4 GCP - services. Content Data are only accessed by engineers in third countries for troubleshooting . If an engineer has to manually intervene, the odds are very small that specific Dutch government data are part of the data accessed by that engineer.

And the probability that a government agent will patiently wait next to an engineer until such data appe ar and will then compel disclosure, is extremely small. Based on the uptime guarantees in Google’s SLAs, Privacy Company has calculated that Content Data from Dutch public sector customers hosted on Compute Engine s (VMs) were only available for 1 hour and 45 minutes in total in the last 2 years. For the other three tested services the uptime was similarly high. Last but not least, Google publicly state s 284 Google Cloud Platform Sub processors, last modified 27 March 2025, URL: https://cloud.google.com/terms/ sub processor s?e=0&hl=en . DPIA on Google Cloud Platform public version 11 June 2026 [it] “ n ever give [s ] any government entity backdoor access ” 285 In the DTIA performed by SLM on Google Meet, Google gave a much stronger statement, also relating to the past, namely, that it did not and currently does not disable security features or alter systems to allow third parties to gain access to Customer Personal Data that would otherwise be unavailable to a third party in clear text. 286 In sum , based on Google’s statistics and technical measures, the probability of unauthorised disclosure of the Content Data to government authorities in the USA and third countries is remote.

Technical measures According to the EDPB, even if the probability of unauthorised access in a third country is (extremely) remote, organisations have to take additional technical supplementary measures. As analysed in Section 9.2 , Google only offers two encryption services that allow customers to comply with the EDPB requirement that the key material is solely under customer or trusted third party control: Cloud EKM keys and Confidential Computing with customer supplied keys . Google has provided an audit report that reviews t he design of Confidential Mode for Hyperdisk that supports the conclusion that there are measures in place to protect data at rest . 287 Google did not provide a security audit that supports the conclusion that these two encryption options effectively prevent access to the decrypted Content Data in the Compute Engine (VM) from com pelled disclosure . Though these two solutions seem effective in preventing unauthorised access to the decrypted Content Data, this DPIA can not technically assess the effective security protection.

Government authorities need to anticipate on a potential invalidation of the EU US DPF. B ased on the guidance from the EDPB, the impact of disclosure of personal data to government authorities in third countries has to legally be assessed as (very) high, especially in case of sensitive and special categories of personal data. Government author ities can only apply encryption with a self - managed key to reduce the probability of access in the clear to remote, but this solution is not available for the combinat ion of the 4 tested GCP - services, and has not been audited. 17.2.7 Loss of control due to data transfer of Account, Diagnostic and Website Data Different from the analysis above about the transfer risks for the Content Data, Dutch government organisations cannot make Data Residency choices for the Account, Diagnostic and Website Data processed by the 4 tested GCP - services, or use ‘Assured Workloads’ to ensure data processing within the EU.

Google does offer a choice to have engineers located in the EU provide Enhanced or Premium Support, but that data processing does not guarantee processing of the Support Data within the EU, and is out of scope of this analysis . Google has provided the same technical and organisational assurances for the Account, Diagnostic and Website Data as for the Content Data as quoted in Section 17.2.6 above. Different from the zero - disclosure statistic for the Content Data, one Google engineer in India has had access in the past 2 years to the data Google calls 285 Google, Creating trust through transparency , 6 th trust principe, URL: https://cloud.google.com/transparency?e=48754805 . 286 SLM DTIA on Google Meet, URL: https://open.overheid.nl/documenten/cb332310 - a0b2 - 4323 - 97ba - d59ffdd18bd2/file . 287 Public Report – Confidential Mode for Hyperdisk – DEK Protection Analysis , 5 November 2025, url: https://www.nccgroup.com/research - blog/public - report - confidential - mode - for - hyperdisk - dek - protection - analysis/ DPIA on Google Cloud Platform public version 11 June 2026 Page 137 of 142 Service Data (i.e., Account, Diagnostic, Support and Website Data) from the tested services as used by Dutch public sector customers, for debugging purposes.

Also different from the Content Data, Dutch government organisations cannot set alerts or prevent Google engineers in third countries from accessing these personal data. Google does not offer a service like ‘Access Transparency’ for these three categories of personal data. Google’s SOC - 2 audit report only assesses Google’s compliance with its own policy rules for the Content Data. Google has refused to conduct a C5 - audit on the Service Data. Instead, Google has referred to the option the Dutch government ha s to conduct its own audit. Finally, Google does not offer any encryption options that customers can control for these personal data. However, b ased on Google’s participation to the EU US Data Privacy Framework, the Dutch government can currently rely on an adequate level of data processing in the USA. The EU US DPF also applies to onward data transfers by Google to sub processors in third countri es.

Based on Google’s assurances and statistics, the probability of forced disclosure to government authorities is remote. Legally, based on the adequacy decision from the European Commission, the impact of disclosure should also be qualified as low to medium (not in practice though). Therefore the current risks of the data transfer for data subjects whose data are part of the Account, Diagnostic and Website Data can be qualified as low . As explained above, government organisations have to anticipate on possible annulment of the EU US DPF. For these personal data, they cannot take technical measures to lower the (remote) probability of access in the clear. Dutch government organisations can use pseudonymous admin accounts, b ut this does not technically prevent Google from (being compelled to) combining personal data about specific individuals related to a specific government organisation, regardless of contractual and GDPR obligations.

Addi tionally, the admin remains identifiable for the Dutch government organisation. See the analysis of currently applicable US American law by law firm Greenberg Traurig and probability of an order for compelled disclosure in Section 8.3.4 . 17.2.8 Reidentification of pseudonymous Telemetry and Website D ata Google has explained it retains Service Data (Account, Diagnostic, Support and Website Data) on average for 180 days , with three exceptions . As shown in Sections 3.3.1 and 3.3.2 Diagnostic Data logs contain names, e - mail addresses and IP - addresses of admins , plus also Content Data from queries and names of files. Google also collects IP - addresses and unique identifiers through Telemetry and Website Data. Google has explained that it has a policy to “ aggregate, anonymise or pseudonymise ” personal data “ when identifiability is not required for the processing of that data. ” 288 Specifically for the Telemetry Data, Google describes in its new public documentation Google that it will anonymise or delete Telemetry Data after 63 days in practice, though it can retain events with personal data for a maximum period of 180 days.

As quoted in Section 3.3.3 Google applies many technical and organisational measures to prevent unnecessary access to the Telemetry Data, and has different procedures to prevent the collection of unnecessary data. T he probability of reidentification of pseudonymised data becomes higher if the data are retained for a longer period, because the dataset increases over time. In this case, the retention period of (pseudonymous) Telemetry and Website Data is assumed to 288 Google reply to questions SLM , 21 March 2025. DPIA on Google Cloud Platform public version 11 June 2026 be maximum 180 days, except in cases where Google suspect s fraud or abuse, or where Google is required by an enforceable legal process. In view of Google’s strict access controls and monitoring of the access to personal data , the probability of reidentification is estimated to be remote . The impact of such reidentification can be high , especially if the reidentification concerns an admin with access to credentials to access sensitive and confidential data.

However, in view of the remote probability, the risks for data subjects can be qualified as low . 17.2.9 Loss of control / loss of confidentiality due to Feedback Google has refused to develop a control for root admins to disable the use of the Feedback Form. G overnment organisations can advise admins n ever to provide Feedback to Google. In combination with Google’s pop - up warning to admins not to upload sensitive data, t his organisational measure can lower the probability to remote. The impact of the disclosure of personal data can be high if an admin were to provide sensitive or confidential Content Data as part of Feedback. Assuming government organisations apply the recommended measure, the risk s for data subjects can be qualified as low. 17.2.10 Chilling effects employee monitoring system Government organisations have access to different logs with information on the specific admin actions, as described in Section s 3.3.1 and 3.3.2 .

The logs contain directly and indirectly identifying data. These logs can provide some insights about individual working behaviour of admins. Based on the logs, and time of activities, managers could (try to) assess the productivity and effectivity of an employee. The probability of such use is remote, because GCP admins spend relatively little time per day on the Admin Console , and access to these logs therefore only provides limited insights . Other logs from commonly used work tools ( text, e - mail, online calling etc) provide more detailed information about employee activities. If an employer would add the (limited) Diagnostic Data about the GCP - services to an employee monitoring system, the impact could be very high. The knowledge that an employer can process work activity data for evaluation purposes can have a chilling effect on government employees . They may fear that the monitoring could be used for a negative performance assessment if such processing is not specifically excluded in an (internal) privacy policy for the processing of employee personal data.

In the context of the Dutch government, the probability that t he Diagnostic Data are used for an employee monitoring system and that the data processing leads to chilling effects is remote . This DPIA assumes government organisations will implement an internal privacy policy with rules and legitimate, specific purposes for the (further) processing of the Diagnostic Data. Therefore, the risks for data subjects can be qualified as low. 17.2.11 Loss of control through lack of privacy by design / privacy by default Google by default has enabled access to its generative AI - service Gemini (See Section 3.1.1 ) , and showed a banner to admins encouraging them to use this service while it was still available for free. Google explained that this banner was “neither an "advertisement" or a "recommendation". Instead, it provides a notice function because the pricing enforcement will be enabled on the specified date .”

DPIA on Google Cloud Platform public version 11 June 2026 Page 139 of 142 As explained in Section 15.2.2 , the principles of data minimisation and privacy by design / privacy by default require that the default settings for the data collection should be set in such a way as to minimise the data collection by using the most privacy friendly settings. Google does not enable Dutch government organisations to comply with this principle if it enables new functionalities by default . Processing of personal data with generative AI functionalities outside of the agreed enrolment framework may have a very high impact on data subjects (both the admins, and people whose dat a are processed or generated as part of the dialogue) . Privacy Company was unable to find a switch in the admin console to prevent default enabling of new unprocured services that can process Content Data in a new way. This DPIA assumes Dutch government organisations have security and privacy policies in place that prohibit admins from using uncontracted functionalities , and require them to wait for a positive assessment by relevant compliance officers .

In view of such policies, the probability can be set to remote. Even though the impact can be high, the risks for data subjects can be qualified as low. Table 5 : Calculated high and low data protection risks Severity of impact Serious harm Low risk 8, 9, 10, 11 High risk High risk Some impact Low risk 1 Medium risk High risk Minimal impact Low risk 2, 3 , 4, 5, 6, 7 Low risk Low risk Remote Reasonable possibility More likely than not Likelihood of harm (occurrence) DPIA on Google Cloud Platform public version 11 June 2026 Part D. Description of risk mitigating measures The following section contains a table of the mitigating technical, organisational and legal measures that need to be taken by the government organisation or by Google to reduce or solve the identified 1 medium and 10 low risks for the data subjects. Risks are qualified as low, medium or high risks based on a multiplication of the probability of occurrence with the impact on data subjects.

The 11 risks below are qualified as low because the government organisations can take effective measures to reduce the probability of occurrence to remote (or zero), even though the impact may still be high. This DPIA assumes that the Dutch government organisations will adopt these measures. 18. Risk mitigating measures 18.1 Measures to be taken to mitigate medium and low risks No. Low Risk Measures gov orgs Measures taken or announced by Google 1. Loss of control through lack of transparency Telemetry Data Study public documentation of the contents of telemetry events at https://support.google.com/ cloud/answer/16796043 . Google has published adequate documentation with relevant examples in Q1 2026, at https://support.google.com/cloud/answe r/16796043 Use pseudonymous admin accounts. Google has listed 5 organisational and 6 technical measures it has in place to prevent collection, access and use of necessary Telemetry Data.

These rules and policies prevent the collection of excessive personal and Content Data. Google has explained it has a policy not to collect user - defined resource identifiers as part of telemetry (for example, the chosen file names, virtual machine names, etc). 2. Inability to exercise data subject access rights Inform admins how they can obtain access to the personal data about Admin log - in activities, and how they can access webserver access logs. Google commits to provide an appropriate response in reply to a DSAR, including data from web server logs relating to a user. Admins can also ask for the webserver access logs relating to specific users via a support ticket. Google commits to provide an explanation about the concept of such logs, and how they are typically used by GCP. Google will provide the reply as soon as possible and in compliance with GDPR timelines. 3. Loss of control through lack of transparency Website Data Follow the offline on - boarding process to ensure the government CMA applies.

Google has changed the text in the cookie consent banner on the Cloud Console (console.cloud.google.com) to: " console.cloud.google.com uses cookies to deliver and enhance the quality of the services and to analyze traffic. Learn more .” These purposes do not include advertising or profiling. DPIA on Google Cloud Platform public version 11 June 2026 Page 141 of 142 Google is not allowed to further process any Service Data in a role as authorised data controller for advertising or profiling purposes. By the end of 2025 Google will add an explanatory sentence to its Cookie Policy about the NID - cookie. If the NID - cookie is set on google.cloud.com or console.cloud.google.com or other advertising - free website, Google will not use this cookie to show advertising to admins when they log out. 4. Loss of control over personal data in inaccessible security logs and small sample of network metadata If organisations want to see Google’s network sampling relating to their services, they can use the service VPC Flow Logs .

There are no inaccessible security logs with personal data from visitors of webservices hosted on the tested Cloud - services. Google has confirmed that it does not collect additional logs about visits to a Dutch government website hosted on GCP other than the sampled pa cket metadata. 5. Loss of control through lack of transparency profiling Follow the offline on - boarding process to ensure the government CMA applies. Google has explained that Dutch government organisations follow a specific offline onboarding process. They do not have to create a Google account, where it is mandatory to accept Google’s standard GCP Terms of Service (including advertising purposes). Gov ernment admins can use non - google e - mail addresses. After SLM Rijk and Google have signed the amended CMA (incl. GCP Services Schedule) Google’s general privacy policy no longer applies, and Google can’t process the Account Data (part of the category of Service Data) for any advertising or profiling purpose s anymore. 6.

Loss of control data transfer Content Data Use the existing option to choose the Netherlands/EU for processing of Content Data. Google includes governing controls for Cloud EKM keys and Confidential Computing in the independent SOC - 2 Type II audit report. Google provided a copy of this report to SLM. Enable Access Transparency for the 3 tested services where that is available ( BigQuery is not fully supported). Enable Assured workloads where possible. Google also organises independent annual pen tests on the two encryption services, but since these services were out of scope of the DPIA, Google did not provide information about the outcomes to SLM. Use Cloud EKM keys and Confidential Computing in case the EU US DPF is annulled. 7. Loss of control data transfer No effective measures for Account, Diagnostic and Website Data No measures taken or announced. [ CONFIDENTIAL ] DPIA on Google Cloud Platform public version 11 June 2026 Account, Support, Diagnostic and Website Data Enable Assured Workloads to be able to specify the geolocations from which Google may provide support.

Use pseudonymous admin accounts. 8. Reidentifica tion of pseudonymi sed Telemetry and Website Data Use pseudonymous admin accounts. Google retains the Telemetry and Website Data for a maximum period of 6 months (180 days). Google will publish information about the Telemetry Data retention periods as part of the announced new documentation. 9. Loss of control / confiden tiality due to Feedback Create a policy, and inform admins, not to provide Feedback to Google. No measures taken or announced. Google will not create a central option to disable Feedback. 10. Loss of control through lack of privacy by default Create a policy, and inform admins, that they are not allowed to use additional services Google may enable. Use of such services generally requires prior privacy and security approval. No measures taken or announced. Google will not change its practice of showing pop - ups about additional non - procured services such as Gemini. 11.

Chilling effects em ployee monitoring system. Complement internal privacy policy for the processing of employee (admin) personal data with rules for what specific purposes specific personal data in the log files may be (further) processed and analysed. This includes listing the specific risks against which the logs will be checked, and which measures the or ganisations will take to ensure purpose limitation. - no measures necessary - Conclusions If government organisations implement all recommended measures, and the EU US DPF remains in place, there are no more known high risks for the data processing.