To begin with a disclaimer. This post has information related to the new EU GDPR regulations that comes into effect on the 25 May 2018 which might be of interest to Google Apps Script and Add-on developers. I’m not a Google employee, lawyer, or a data protection expert and I’m only sharing my interpretation of information I’ve gathered for your consideration and is not legal advice. As this is a complex area the post is in two parts. This part looks at key definitions to help you find out if your G Suite Add-on or Google Apps Script project needs to consider personal data protection. The second part identifies 12 steps you can take if your add-on processes personal data.
The General Data Protection Regulation (GDPR) (EU) 2016/679 is a regulation in EU law on data protection and privacy for all individuals within the European Union. It also addresses the export of personal data outside the EU. The GDPR aims primarily to give control to citizens and residents over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU. – Wikipedia
GDPR compliance isn’t just required by EU based organisations. Any ‘enterprise’ processing ‘personal data’ from EU citizens needs to be GDPR compliant or they can face “penalties of up to 4% of worldwide turnover or €20 million, whichever is higher”. This means if your add-on or Apps Script project has EU citizens using it you might need to comply with the GDPR.
Before going further let’s look at the definition of ‘personal data’ which is covered in Article 4(1):
‘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 name, 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;
So the first question you might want to ask yourself is does your add-on use any personal data. It is important to remember here that the definition of personal data is broad and can include data that has been hashed:
Personal data that has been pseudonymised – eg key-coded – can fall within the scope of the GDPR depending on how difficult it is to attribute the pseudonym to a particular individual. – UK ICO Key Definitions
For example, within Google Apps Script you can use
.getTemporaryActiveUserKey(), which is a temporary key that is unique to the active user but does not reveal the user identity. Using this by itself would probably not fall within the GDPR as it is pseudonymised, but if this is combined with other data like location you could argue that it is indirectly identifying a person and if this person was an EU citizen you would need to be GDPR compliant.
Data controller/Data processor
Within the context of add-ons depending on how personal data is being used you might also be a ‘data processor’ and/or ‘data controller’. The UK ICO defines controllers and processors as:
A controller determines the purposes and means of processing personal data.
A processor is responsible for processing personal data on behalf of a controller.
The Irish Data Protection Commissioner provides further guidance on how to identify if you are a data controller:
In essence, you are a data controller if you can answer YES to the following question:
Do you keep or process any information about living people? – IE DPC
For example, if your add-on or Apps Script project in some way lets you collect and store user email addresses you would be a data controller.
Let’s consider another example where you as a developer created a Google Sheets add-on which allows email addresses entered by the user to be used to send emails from their Gmail account. In this scenario the add-on only uses Google services available in Google Apps Script to programmatically read data from the user’s Google Sheet and send emails from the user’s Gmail account. At no point in this process would the developer have direct access to the user’s Google Sheet or Gmail account and this functionality would be entirely executed within Google services and servers. Is the developer the ‘data processor’?
I would argue that if at no point the developer accesses personal data entered by the user that they are not a ‘data processor’.
Update: This opinion is supported by Kim Nilsson (also not a lawyer):
If the code’s access of data never leaves the user’s computer, and isn’t stored away from he user’s computer or user’s own account then you don’t process data. Now, there’s a small twist… you also have to assert that you can not, and/or will not access user data.
If that is the case write it clearly on your info page about your software. Like in the Chrome Web Store, or G Suite Marketplace.
Then everyone knows that your code is safe and legal to use without having to put up a data processing agreement with the dev.
Kim’s example of the Reading Ruler Chrome Extension Listing
The distinction is important because:
If you are a processor, the GDPR places specific legal obligations on you; for example, you are required to maintain records of personal data and processing activities. You will have legal liability if you are responsible for a breach – (UK ICO – Key definitions)
If your add-on interacts with the users data in a way that it’s accessible to you e.g. temporarily storing personal data like an email address in a Firebase Realtime Database, I would argue this does make you a ‘data processor’ and for data from EU citizens places GDPR requirements on you. But as mentioned I’m not a lawyer and you might want to seek further advice on that.
Enterprise and economic activity
You might argue that you provide your add-on for free or you are not incorporated as a legal entity so regardless of whether you are a data controller or processor you are exempt from the GDPR. Article 4(18) provides a definition of ‘enterprise’ which is:
a natural or legal person engaged in an economic activity, irrespective of its legal form, including partnerships or associations regularly engaged in an economic activity
Your next question might be what is defined as “economic activity”. Robert Madge writes on MyData:
economic activity is ‘offering goods or services’ (even if no payment occurs). The case law shows a broad interpretation of ‘offering goods or services’ to cover sales, supply and even purchasing.
So even if your add-on is free you are offering goods or services and therefore, with EU citizens, you need to be GDPR compliant. An exception to this is if processing is carried out by individuals purely for personal/household activities as covered in Recital 18, however, even if your add-on purely personal or household activity the GDPR still applies “to controllers or processors which provide the means for processing personal data for such personal or household activities”
If you’ve concluded from the information provided that your add-on is processing personal data from EU citizens you can find out 12 steps to take now.
As noted at the start I’m not a lawyer or a data protection expert so if you have any corrections or additional information please share in the comments or get in touch.