To begin with a disclaimer. This post contains 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 is the second in the series. In part one I looked at key definitions to help you identify if your G Suite Add-on or Google Apps Script project needs to consider personal data protection. If from that post you concluded your add-on or Apps Script project needs to add personal data protection this post identifies 12 steps you can take now.
This post was also written with Steve Webster G Suite Senior Solutions Architect and Developer at SW gApps (also not a Google employee, lawyer, or a data protection expert).
- Limiting access
- Embracing GDPR
- Preparing your add-on for GDPR – 12 steps
- Additional Resources
In the previous post I looked how GDPR provides “data protection and privacy for all individuals within the European Union” including data from EU citizens even if it is used outside the EU. One option is to avoid the GDPR by preventing EU citizens using it. You could do this by selecting the regions when you publish your add-on. One issue with this is not all EU countries are individually listed (Croatia, Republic of Cyprus, Latvia, Luxembourg, Malta and Slovenia are not listed). I’m not sure if for example you just selected ‘United States’ this would prevent all EU citizens accessing your add-on. Another consideration is if you are updating publication settings for an existing add-on, does this prevent existing users from the EU from continuing to use your add-on?
Another option if you use personal data in your add-on is to use the GDPR as an opportunity to improve your data handling and transparency. A number of services based outside the EU have incorporated aspects of the GDPR in their privacy policies and working practices.
A good starting point is the UK ICO Preparing for the GDPR – 12 steps to take now (.pdf). The document contains more details on each of these steps and an annotated extract is contained below:
Preparing your add-on for GDPR – 12 steps
You should make sure that decision makers and key people in your organisation are aware that the law is changing to the GDPR. They need to appreciate the impact this is likely to have.
Hopefully this post is proving a useful starting point.
Information you hold
You should document what personal data you hold, where it came from and who you share it with. You may need to organise an information audit.
For the majority of add-ons I’d imagine the personal data is limited so this should take too long. For EU based developers this is something you should consider doing for your entire company.
Lawful basis for processing personal data
You should identify the lawful basis for your processing activity in the GDPR, document it and update your privacy notice to explain it.
The GDPR defines six lawful bases for processing personal data of which at least one has to be used when processing personal data from EU citizens:
- Consent: the individual has given clear consent for you to process their personal data for a specific purpose.
- Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
- Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations).
- Vital interests: the processing is necessary to protect someone’s life.
- Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.
- Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests.
In an add-on you may discover you need to handle lawful basis for the different types of personal data you use. For example, if you include Google Analytics or another tracking service to monitor your add-on usage you will probably require consent from the user, but if you have premium options in your add-on you may use a contract as lawful basis.
Within the context of add-ons and Apps Script projects in terms of lawful basis other than consent and contract you might want to spend time looking at ‘legitimate interest’. The UK ICO guidance on ‘legitimate interest’ states:
Legitimate interests is most likely to be an appropriate basis where you use data in ways that people would reasonably expect and that have a minimal privacy impact. Where there is an impact on individuals, it may still apply if you can show there is an even more compelling benefit to the processing and the impact is justified.
‘Legitimate interests’ can be conveyed in your user privacy notice and might be well suited to add-ons as you could argue that by installing and using the add-on there is reasonable expectation and compelling benefits. Using ‘legitimate interests’ comes with extra responsibilities including conducting and recording a legitimate interests assessment (LIA).
You should review how you seek, record and manage consent and whether you need to make any changes. Refresh existing consents now if they don’t meet the GDPR standard.
If using consent as a lawful basis for processing personal data you need to keep a record on an individual basis. The UK ICO note that “consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent”.
Communicating privacy information
You should review your current privacy notices and put a plan in place for making any necessary changes in time for GDPR implementation.
For existing add-ons you might want to use ‘legitimate interests’ as a lawful basis if you are processing personal data of existing users. The UK ICO’s guidance states:
If for example you have been processing on the basis of consent but you find that your existing consents do not meet the GDPR standard, and you do not wish to seek fresh GDPR-compliant consent, you may be able to consider legitimate interests instead. However you must be confident that you want to take responsibility for demonstrating that your processing is in line with people’s reasonable expectations and that it wouldn’t have an unjustified impact on them.
You must still ensure that your processing is fair. If you wish to move from consent under the 1998 Act to legitimate interests under the GDPR, you need to ensure that you clearly inform individuals of the change in your privacy notice. To ensure there is no unjustified impact on their rights, you should consider giving them a clear chance to opt out, and retaining any preference controls that were in place.
You should check your procedures to ensure they cover all the rights individuals have, including how you would delete personal data or provide data electronically and in a commonly used format.
The GDPR gives the following rights to EU citizens regarding personal data:
- The right to be informed
- The right of access
- The right to rectification
- The right to erasure
- The right to restrict processing
- The right to data portability
- The right to object
- Rights in relation to automated decision making and profiling
An important consideration is the lawful basis you choose for processing personal data affects the rights the user has to erasure, portability and objection summarized in the table below:
Image source – ICO Lawful basis for processing
Subject access requests
You should update your procedures and plan how you will handle requests within the new timescales and provide any additional information.
The new timescale for subject access requests is one month. As noted in the UK ICO’s 12 steps:
the right to data portability is new. It only applies: to personal data an individual has provided to a controller; where the processing is based on the individual’s consent or for the performance of a contract; and when processing is carried out by automated means.
You should start thinking now about whether you need to put systems in place to verify individuals’ ages and to obtain parental or guardian consent for any data processing activity.
This might be particularly important if you are developing add-ons for education.
You should make sure you have the right procedures in place to detect, report and investigate a personal data breach.
With data breaches the UK ICO highlight that:
the GDPR introduces a duty on all organisations to report certain types of personal data breach to the relevant supervisory authority. You must do this within 72 hours of becoming aware of the breach, where feasible.
It appears breaches should be reported to the appropriate authority in your jurisdiction. As knowing who this is isn’t always straightforward to find out you should have this documented. For US based developers here is a Summary of U.S. State Data Breach Notification Statutes (the 72 hour window applies to EU citizens data, you may discover your jurisdiction has additional requirements).
Additionally for add-on breaches you might want to contact Google directly. A contact address list on Google’s Privacy Shield is firstname.lastname@example.org.
Data Protection by Design and Data Protection Impact Assessments
You should familiarise yourself now with the ICO’s code of practice on Privacy Impact Assessments as well as the latest guidance from the Article 29 Working Party, and work out how and when to implement them in your organisation.
At the heart of this is having in place the appropriate workflows and policies. Having documented workflows is useful as doing Data Protection Impact Assessments are not always required.
Data Protection Officers
You should designate someone to take responsibility for data protection compliance and assess where this role will sit within your organisation’s structure and governance arrangements. You should consider whether you are required to formally designate a Data Protection Officer.
If you are the sole developer this will be easy… Depending on the circumstances, including the country you are based in, you might have to formally register a data protection officer. In the case of the UK the ICO has a self-assessment tool.
If your organisation operates in more than one EU member state (ie you carry out cross-border processing), you should determine your lead data protection supervisory authority. Article 29 Working Party guidelines will help you do this.
A common myth with the GDPR is data about EU citizens can’t leave the EU. This is not true. The UK ICO guidance on the GDPR Chapter V requirements is:
Transfers may be made where the Commission has decided that a third country, a territory or one or more specific sectors in the third country, or an international organisation ensures an adequate level of protection.
Whether a country provides an adequate level of protection is decided by the European Commision:
The European Commission has so far recognised Andorra, Argentina, Canada (commercial organisations), Faroe Islands, Guernsey, Israel, Isle of Man, Jersey, New Zealand, Switzerland, Uruguay and the US (limited to the Privacy Shield framework) as providing adequate protection. Adequacy talks are ongoing with Japan and South Korea.
In the case of transfers to the US this is on a company rather than country basis under the EU-US and Swiss-US Privacy Shield framework. Google is certified under the Privacy Shield so personal data on Google’s infrastructure should have the adequate level of protection. A consideration for developers is if your add-on sends personal data to other non-Google services is whether those services are in recognised countries or have been certified under the Privacy Shield.
Hopefully this post has highlighted some actionable steps you can take now. In writing this post both myself and Steve contacted Google asking for clarification for add-on developers. Unfortunately there has been no comment from Google, but you can learn more about how Google is committed to GDPR compliance across G Suite and Google Cloud Platform services.
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.
The GDPR is a big topic but sites like the UK’s Information Commissioner’s Office (ICO) have lots of useful resources to help with the GDPR.