Google Data Processing Addendum for Products Where Google is a Data Processor

(a) Data Centres.

Infrastructure. Google maintains geographically distributed data centres. Google stores all production data in physically secure data centres.

Redundancy. Infrastructure systems have been designed to eliminate single points of failure and minimise the impact of anticipated environmental risks. Dual circuits, switches, networks or other necessary devices help provide this redundancy. The Processor Services are designed to allow Google to perform certain types of preventative and corrective maintenance without interruption. All environmental equipment and facilities have documented preventative maintenance procedures that detail the process for and frequency of performance in accordance with the manufacturer's or internal specifications. Preventative and corrective maintenance of the data centre equipment is scheduled through a standard process according to documented procedures.

Power. The data centre electrical power systems are designed to be redundant and maintainable without impact to continuous operations, 24 hours a day, and 7 days a week. In most cases, a primary as well as an alternate power source, each with equal capacity, is provided for critical infrastructure components in the data centre. Backup power is provided by various mechanisms such as uninterruptible power supply (UPS) batteries, which supply consistently reliable power protection during utility brownouts, blackouts, over voltage, under voltage, and out-of-tolerance frequency conditions. If utility power is interrupted, backup power is designed to provide transitory power to the data centre, at full capacity, for up to 10 minutes until the backup generator systems take over. The backup generators are capable of automatically starting up within seconds to provide enough emergency electrical power to run the data centre at full capacity typically for a period of days.

Server Operating Systems. Google servers use hardened operating systems which are customised for the unique server needs of the business. Data is stored using proprietary algorithms to augment data security and redundancy. Google employs a code review process to increase the security of the code used to provide the Processor Services and enhance the security products in production environments.

Business Continuity. Google replicates data over multiple systems to help to protect against accidental destruction or loss. Google has designed and regularly plans and tests its business continuity planning/disaster recovery programs.

Encryption Technologies. Google’s security policies mandate encryption at rest for all user data, including personal data. Data is often encrypted at multiple levels in Google’s production storage stack in data centres, including at the hardware level, without requiring any action by partners. Using multiple layers of encryption adds redundant data protection and allows Google to select the optimal approach based on application requirements. All personal data is encrypted at the storage level, generally using AES256. Google uses common cryptographic libraries which incorporate Google’s FIPS 140-2 validated module, to implement encryption consistently across the Processor Services.

(b) Networks & Transmission.

Data Transmission. Data centres are typically connected via high-speed private links to provide secure and fast data transfer between data centres. Further, Google encrypts data transmitted between data centres. This is designed to prevent data from being read, copied, altered or removed without authorisation during electronic transport. Google transfers data via Internet standard protocols.

External Attack Surface. Google employs multiple layers of network devices and intrusion detection to protect its external attack surface. Google considers potential attack vectors and incorporates appropriate purpose built technologies into external facing systems.

Intrusion Detection. Intrusion detection is intended to provide insight into ongoing attack activities and provide adequate information to respond to incidents. Google’s intrusion detection involves:

Incident Response. Google monitors a variety of communication channels for security incidents, and Google’s security personnel will react promptly to known incidents.

Encryption Technologies. Google makes HTTPS encryption (also referred to as TLS connection) available. Google servers support ephemeral elliptic curve Diffie Hellman cryptographic key exchange signed with RSA and ECDSA. These perfect forward secrecy (PFS) methods help protect traffic and minimise the impact of a compromised key, or a cryptographic breakthrough.

(a) Site Controls.

On-site Data Centre Security Operation. Google’s data centres maintain an on-site security operation responsible for all physical data centre security functions 24 hours a day, 7 days a week. The on-site security operations personnel monitor Closed Circuit TV (“CCTV”) cameras and all alarm systems. On-site security operation personnel perform internal and external patrols of the data centre regularly.

Data Centre Access Procedures. Google maintains formal access procedures for allowing physical access to the data centres. The data centres are housed in facilities that require electronic card key access, with alarms that are linked to the on-site security operation. All entrants to the data centre are required to identify themselves as well as show proof of identity to on-site security operations. Only authorised employees, contractors and visitors are allowed entry to the data centres. Only authorised employees and contractors are permitted to request electronic card key access to these facilities. Data centre electronic card key access requests must be made in advance and in writing, and require the approval of authorised data centre personnel. All other entrants requiring temporary data centre access must: (i) obtain approval in advance from authorised data centre personnel for the specific data centre and internal areas they wish to visit; (ii) sign in at on-site security operations; and (iii) reference an approved data centre access record identifying the individual as approved.

On-site Data Centre Security Devices. Google’s data centres employ an electronic card key and biometric access control system that is linked to a system alarm. The access control system monitors and records each individual’s electronic card key and when they access perimeter doors, shipping and receiving, and other critical areas. Unauthorised activity and failed access attempts are logged by the access control system and investigated, as appropriate. Authorised access throughout the business operations and data centres is restricted based on zones and the individual’s job responsibilities. The fire doors at the data centres are alarmed. CCTV cameras are in operation both inside and outside the data centres. The positioning of the cameras has been designed to cover strategic areas including, among others, the perimeter, doors to the data centre building, and shipping/receiving. On-site security operations personnel manage the CCTV monitoring, recording and control equipment. Secure cables throughout the data centres connect the CCTV equipment. Cameras record on-site via digital video recorders 24 hours a day, 7 days a week. The surveillance records are retained for at least 7 days based on activity.

(b) Access Control.

Infrastructure Security Personnel. Google has, and maintains, a security policy for its personnel, and requires security training as part of the training package for its personnel. Google’s infrastructure security personnel are responsible for the ongoing monitoring of Google’s security infrastructure, the review of the Processor Services, and responding to security incidents.

Access Control and Privilege Management. Partner's administrators and users must authenticate themselves via a central authentication system or via a single sign-on system in order to use the Processor Services.

Internal Data Access Processes and Policies – Access Policy. Google’s internal data access processes and policies are designed to prevent unauthorised persons and/or systems from gaining access to systems used to process personal data. Google aims to design its systems to: (i) only allow authorised persons to access data they are authorised to access; and (ii) ensure that personal data cannot be read, copied, altered or removed without authorisation during processing, use and after recording. The systems are designed to detect any inappropriate access. Google employs a centralised access management system to control personnel access to production servers, and only provides access to a limited number of authorised personnel. LDAP, Kerberos and a proprietary system utilising digital certificates are designed to provide Google with secure and flexible access mechanisms. These mechanisms are designed to grant only approved access rights to site hosts, logs, data and configuration information. Google requires the use of unique user IDs, strong passwords, two factor authentication and carefully monitored access lists to minimise the potential for unauthorised account use. The granting or modification of access rights is based on: the authorised personnel’s job responsibilities; job duty requirements necessary to perform authorised tasks; and a need to know basis. The granting or modification of access rights must also be in accordance with Google’s internal data access policies and training. Approvals are managed by workflow tools that maintain audit records of all changes. Access to systems is logged to create an audit trail for accountability. Where passwords are employed for authentication (e.g. login to workstations), password policies that follow at least industry standard practices are implemented. These standards include restrictions on password reuse and sufficient password strength.

(a) Data Storage, Isolation & Authentication.

Google stores data in a multi-tenant environment on Google-owned servers. Data, the Processor Services database and file system architecture are replicated between multiple geographically dispersed data centres. Google logically isolates each partner's data. A central authentication system is used across all Processor Services to increase uniform security of data.

(b) Decommissioned Disks and Disk Destruction Guidelines.

Certain disks containing data may experience performance issues, errors or hardware failure that lead them to be decommissioned (“Decommissioned Disk”). Every Decommissioned Disk is subject to a series of data destruction processes (the “Data Destruction Guidelines”) before leaving Google’s premises either for reuse or destruction. Decommissioned Disks are erased in a multi-step process and verified complete by at least two independent validators. The erase results are logged by the Decommissioned Disk’s serial number for tracking. Finally, the erased Decommissioned Disk is released to inventory for reuse and redeployment. If, due to hardware failure, the Decommissioned Disk cannot be erased, it is securely stored until it can be destroyed. Each facility is audited regularly to monitor compliance with the Data Destruction Guidelines.

(c) Pseudonymous Data. Online advertising data are commonly associated with online identifiers which on their own are considered ’pseudonymous’ (i.e. they cannot be attributed to a specific individual without the use of additional information). Google has a robust set of policies and technical and organisational controls in place to ensure the separation between pseudonymous data and personally identifiable user information (i.e. information that could be used on its own to directly identify, contact, or precisely locate an individual), such as a user’s Google account data. Google policies only allow for information flows between pseudonymous and personally identifiable data in strictly limited circumstances.

(d) Launch reviews. Google conducts launch reviews for new products and features prior to launch. This includes a privacy review conducted by specially trained privacy engineers. In privacy reviews, privacy engineers ensure that all applicable Google policies and guidelines are followed, including but not limited to policies relating to pseudonymisation and data retention and deletion.

2.1 In this Appendix 3A:

“Adequate Country” means:

in each case, other than on the basis of an optional data protection framework.

“Data Transfer Solution” means a solution that enables the lawful transfer of personal data to a third country in accordance with European Data Protection Legislation, including the EU-US Data Privacy Framework, UK Extension to EU-US Data Privacy Framework, Swiss-US Data Privacy Framework (collectively, the “Data Privacy Framework”), or another valid data protection framework recognized as providing adequate protection under Applicable Data Protection Legislation.

“EEA” means the European Economic Area.

“European Laws” means, as applicable: (a) EU or EU Member State law (if the EU GDPR applies to the processing of Partner Personal Data); (b) the law of the UK or a part of the UK (if the UK GDPR applies to the processing of Partner Personal Data); and (c) the law of Switzerland (if the Swiss FDPA applies to the processing of Partner Personal Data).

“Partner SCCs” means the SCCs (Controller-to-Processor), the SCCs (Processor-to-Controller), and/or the SCCs (Processor-to-Processor), as applicable.

“SCCs” means the Partner SCCs and/or SCCs (Processor-to-Processor, Google Exporter), as applicable.

“SCCs (Controller-to-Processor)” means the terms at business.safety.google/gdprcontrollerterms/sccs/eu-c2p-dpa.

“SCCs (Processor-to-Controller)” means the terms at business.safety.google/gdprprocessorterms/sccs/p2c.

“SCCs (Processor-to-Processor)” means the terms at business.safety.google/gdprprocessorterms/sccs/eu-p2p-dpa.

“SCCs (Processor-to-Processor, Google Exporter)” means the terms at business.safety.google/gdprprocessorterms/sccs/eu-p2p-intra-group.

“Supervisory Authority” means, as applicable: (a) a “supervisory authority” as defined in the EU GDPR; and/or (b) the “Commissioner” as defined in the UK GDPR and/or the Swiss FDPA.

2.2The terms “data importer” and “data exporter” have the meanings given in the applicable SCCs.

6.1Partner’s Audit Rights.

6.2 Additional Business Terms for Audits.

7.1 Restricted European Transfers. The parties acknowledge that European Data Protection Legislation does not require SCCs or a Data Transfer Solution to transfer Partner Personal Data to an Adequate Country. If Partner Personal Data is transferred to any other country, and European Data Protection Legislation applies to the transfers (“Restricted European Transfers”), then:

7.2Supplementary Measures and Information. Google will provide Partner with information relevant to Restricted European Transfers, including information about supplementary measures to protect Partner Personal Data, as described in Section 7.5 (Verifying Compliance), Appendix 2 (Security Measures) and other materials concerning the nature of the Processor Services and the processing of Partner Personal Data (for example, help centre articles).

7.3Termination. If Partner concludes, based on its current or intended use of the Processor Services, that the Data Transfer Solution and/or SCCs, as applicable, do not provide appropriate safeguards for Partner Personal Data, then Partner may immediately terminate the Agreement for convenience by notifying Google in writing.

7.4Data Transfer Solution Adoption and Certification. Information about Google and/or its Affiliates’ adoption of, or certification under, a Data Transfer Solution can be found at https://policies.google.com/privacy/frameworks. The parties acknowledge that Google has certified under the Data Privacy Framework on behalf of itself and certain wholly-owned US subsidiaries. Google’s certification is available at https://www.dataprivacyframework.gov. The Data Privacy Framework will apply to any Restricted European Transfer to a certified Google entity in the US.

(a) collect and maintain records of certain information, including: (i) the name and contact details of each processor and/or controller on behalf of which Google is acting and (if applicable) of such processor’s or controller's local representative and data protection officer, and (ii) if applicable under the Partner SCCs, Partner’s Supervisory Authority; and

(b) make such information available to any Supervisory Authority. Accordingly, Partner will, where requested and as applicable to Partner, provide such information to Google via the user interface of the Processor Services or via such other means as may be provided by Google, and will use such user interface or other means to ensure that all information provided is kept accurate and up-to-date.

10.1Order of Precedence. If there is any conflict or inconsistency between the Partner SCCs and this Appendix 3A, the remainder of this Data Processing Addendum or the remainder of the Agreement, then the Partner SCCs will prevail.

10.2No Modification of SCCs. Nothing in the Agreement (including these Data Processing Terms) is intended to modify or contradict any SCCs or prejudice the fundamental rights or freedoms of data subjects under the European Data Protection Legislation.

(a)“Deidentified Data” means data information that is “deidentified” or “de-identified data” (as defined by U.S. State Privacy Laws), when disclosed by one party to the other.

(b) the terms “business”, “consumer”, “personal information”, “sale(s)”, “sell”, “service provider”, and “share” as used in this Appendix 3B have the meanings given in the applicable U.S. State Data Protection Law.

3.1To the extent that one or more of the U.S. State Data Protection Laws applies to the processing of Partner Personal Data:

3.2Instruction Notifications. Google will immediately notify Partner if, in Google’s opinion: (a) U.S. State Data Protection Laws prohibit Google from complying with an Instruction; (b) an Instruction does not comply with U.S. State Data Protection Laws; or (c) Google is otherwise unable to comply with an Instruction or U.S. State Data Protection Laws, in each case unless such notice is prohibited by U.S. State Data Protection Laws. This paragraph 3.2 of this Appendix 3B (Instruction Notifications) does not reduce either party’s rights and obligations elsewhere in the Agreement.

3.3Partner’s Audit Rights.

3.4Subcontractors. When engaging any Subprocessor, Google will ensure via a written contract that

4.1Deidentified Data. To the extent that one or more of the U.S. State Data Protection Laws applies to the processing of Partner Personal Data, each party will comply with the requirements for processing Deidentified Data set out in the U.S. State Data Protection Laws, with respect to any Deidentified Data it receives from the other party pursuant to the Agreement. For purposes of this paragraph 4.1 (Deidentified Data), Partner Personal Data means any personal data that is processed by a party under the Agreement in connection with its provision or use of the Processor Services.

5.1To the extent that CCPA applies to such processing of Partner Personal Data, Google will act as Partner’s service provider, and as such, unless otherwise permitted for service providers under CCPA, as reasonably determined by Google:

In addition to Section 15 of the Data Processing Terms (Changes to this Data Processing Addendum), Google may change this Appendix 3B without notice if the change (a) is based on applicable law, applicable regulation, a court order, or guidance issued by a governmental regulator or agency or (b) does not have a material adverse impact on Partner under the U.S. State Data Protection Laws, as reasonably determined by Google.