What does GDPR actually mean to product agencies, and why does it seem so scary
It seems scary because it is. But, at it's crux in can be summarised as "dealing with other people's data? Be nice about it" .
Hold Up. What is GDPR?
The GDPR (General Data Protection Regulation) is a legal framework guideline set out by the EU which comes into law in 25 May 2018 and contains a set of regulations centred around providing a clearer set of personal protection for how people have their data stored, accessed and removed by companies and what those companies can and can’t do without explicit consent.
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance)
Why was GDPR Introduced, and why should I care about it?
Over recent years, the way and amount of data businesses collect has changed significantly, existing legislation was not up to scratch and did not offer sufficient user/customer rights, This new legislation has been introduced to give users' more rights over what data is collected and how this data is used.
You really should care because the fines are quite significant.
It also gives them the power to issue administrative fines on controllers or processors up to EUR 20 million, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.
Anyone who does business within the single market will have to comply with it. That also includes non-EU businesses who deal with EU customers.
How does this affect me in a digital product workspace?
Most of the articles you will see written about GDPR are from a “big corporate” point of view, so seem very scary.
In really GDPR is only very scary for these big corporations because they have been abusing customer data for a very long time and over the years, this has become a key part of how they do business.
What do I need to do?
You're not a lawyer, but you do need to be aware of these new rules and how they affect design and technology decisions you make or any recommendation you make to a client.
Whilst the product you are developing may not be directly collecting data, depending on the arrangements, you might be deemed as the "collecting agent" so need to be careful.
What are the key things I need to know ?
First of all:
Don't be scared of any of the legal wording, the GDPR Document "REGULATION (EU) 2016/679" is actually written using very concise language, so if you need more detail on a section, you should read through it in the document.
Many of the Articles you will find are long winded and don't provide direct examples, One of the few existing articles that provided such detail was from IAPP written by Gregory Ried which I have shamelessly based the below on, with extra points and commentary added.
@Gregory Ried - If you read this, I owe you a beer 🍺.
Implementing data protection in the system and the organisation, by design and by default, is a legal requirement:
Recital 78 and Article 25
Data encryption shall be used, when possible:
Recitals 83 and Articles 6-4(e), 32-1(a)
Many of the articles and resources you will see are treating Articles like this as a new and game changing requirement, but in reality, you should have been storing any client data in a secure and encrypted nature for a while now, using secured gateways and VPC and IP whitelisting, all connecting over SSL.
One of the main considerations here is that this applies to ALL collected user data, so this would also apply to any spike or validation work that collects real world data, and not just your production environments.
Data is secured, and integrity and confidentiality are maintained, using technical and organizational means under the management of the controller:
Recital 49 and Articles 5-1(f), 32-1(b-d)
You must adequately secure any personal data against incoming attack vectors, this outlines much of what is already standard security practise. You should continue to ensure your systems are PEN and Integration tested to ensure there are no data leaks and services cannot be compromised, whilst still being able to support any law enforcement data requests.
Data pseudonymization shall be used, when possible:
Recitals 26, 28, 29, 78 and Articles 6-4(e), 25-1, 32-1(a)
Data shall be anonymized, when possible:
When storing any user related data that is publicly accessible, or data that can be indirectly assessed by an non-admin agent, ensure that data returned does not unnecessarily present in a manner identifiable to a single individual. This could also speak to off-site implementations such as analytics or any marketing (consented cookie) tracking to which you should store data so granular as to identity a single individual.
Processing attributes and (the processing) steps shall be provided to the data subject in an easy to understand form at the time of data collection, electronically or in writing:
Recitals 39, 58 and Articles 12-1, 13-2(a-f)
Data subjects shall have the right to access and review the processing of their data at any time:
Recitals 58, 61, 63 and Articles 12, 15-1(a, d)
Disparate data elements that could be considered personal data or considered personal profiling if processed or combined separately or together resulting in illegal activities:
The ability to reference a "Natural Person" may not only derive from their name, and could also come from cookies, IP or MAC addresses or geolocation etc... . You must still adhere to Recitals and Articles mentioned above even if not identifying people in a traditional "named" sense.
Data regarding a data subject shall be portable to another provider (or perhaps even your competitor):
Recital 68 and Articles 13-2(b), 14-2(c), 20
The data subject shall have a right to a copy of their data in a commonly used format:
When developing systems that process data in a standard format, consider allowing users to export their own data (using an interoperable format if available), and at a minimum, provide them with the option to request a manual export of any of their own data.
Recital 68 also has some very specific wording around financial and legal contractual consent, due to not being a lawyer I am consciously not touching on this information, but please read it yourself for further clarification.
The data subject shall have the right to have their data updated, free of charge, if there is an error:
Recitals 59, 65 and Article 16, and, the data subject shall have the right to request this update electronically, Recital 59
If your service does not provide an area for users' to edit their own stored data, provide a mechanism or support email to assist in this process.
The data subject shall have the right to have their data erased without undue delay:
Recitals 59, 65 and Articles 13-2(b), 14-2(b), 17, and, the data subject shall have the right to request this deletion electronically, Recital 59 (Note: There are special exceptions to this right provided in the GDPR.)
The data controller must notify other IT organiazations that hold the data subject’s data that the data subject has requested data erasure:
Recital 66 and Article 19 (Therefore, the IT department must know where all the data subjects’ data is being stored by third parties so that these third parties can be notified of erasure request. Up-to-date internal and external data inventories are critical.)
The data subject shall have the right to object to processing, withdraw consent to processing and opt-out of processing. And the data subject can object to or withdraw their consent is these processing matters electronically:
Recitals 59, 63 and Articles 7-3, 18, 21 (And with technical recommendation from the EU Council: Recital 67)
Unless stored for regulatory or contractual reasons (see note above), you must allow a user to either delete, or request manual deletion of their data, with this triggered or manual deletion propagating to 3rd parties.
If data is shared between instances using caches or global delivery networks, cache should not need to be invalidated as this would not be an "undue delay", but when designing infrastructure you should take care not to store identifiable "Natural Person" date in a service with a long cache expiry.
Data is stored only for the time necessary to meet the objectives of the data subject. Out-of-date personal data shall not be stored. (Part of an Electronic Records Management strategy). And the data subject shall be notified of this time period or its calculation approach at the time of the data capture:
Recitals 39, 45 and Articles 13-2(a), 14-2(a), 25-2
This requirement speaks more to campaign and single-use content, and rightly states that any data should no longer be stored after the campaign has finished. The main changes to existing "best practices" is that a user must be made aware of how long data will be stored at the point of collection.
A determination must be made, almost immediately, whether a data breach is likely to have been a “high risk to the rights and freedoms of the natural person” as such a technical environment must be in place to identify, track and assess such breaches:
Recitals 85, 86 (regarding notification obligations), 87 (Note: Many articles, e.g. 33, 34) in the GDPR addressing the reporting obligations to the data subject and the authorities on this matter.
Beyond ensuring any data stored on "natural persons" is anonymised, and that all available steps have been taken to avoid a data breach, if unfortunately a breach does occur that transmits identifying data, it is disclosed to affected parties immediately.
When a "child is below the age of 16 years" or when "Member States may provide by law for a lower age for those purposes provided that such lower age is not below 13 years" the "processing of the personal data of a child shall be lawful"
Article 6(1a), Article 8 (Conditions applicable to child's consent)
For the purposes of GDPR, the age of data collection consent is deemed to be 16 (or a minimum of 13) years old. To ensure you are complying with the legislation, if you are targeting your service at people below this age it parental consent should be directly stipulated.
To to ensure legal collection of data, any terms and conditions agreed to by data providing parties should contain parental agreement stipulations to avoid accidental unlawful data collection.
How does this affect my client interactions?
Hopefully your clients have had their own independent legal advice tailored specifically to how GDPR will affect their business and how it applies to any data they collect.
Our role is not only to design and deliver the best product experience, but also to give industry leading advise, so we need to be aware of the appropriate regulations.
It is important to ensure and design, code and infrastructure deliverables, especially those dealing with personal data adhere at a minimum to the guidance in the previous section, and potentially cater for any extra requirements when dealing with and financial, medial or data pertaining to minors.
What about Brexit?
Whilst we may foresee more expensive holidays and a shift in finance, higher data protection from GDPR is here to stay, and will be retained and eventually transitioned into UK law.
During the Queen's Speech (21 June 2017) , The Queen noted that the UK would retain its "world-class" data protection regime, and continue to implement GDPR rules to ensure that the UK was compliant during it's transitional period and also so that there was a consistent set of guidelines between the UK and the EU allowing "ability to share data with other EU members states and internationally after we leave the EU".
Due to the wider reach and more detailed overall nature, the GDPR will (most likely) replace the UK Data Protection Act 1998.
Regardless of how the law is transitioned, the UK will be deemed as a "third country" party (post-Brexit March 2019) when it comes to dealing with transferal of data into and out of the EU, so even if these policies change between now (March 2018) and then, we as an industry will still need to know and ensure the correct processes are in use to best service our customers and their users.
Any existing "Safe Harbour" style agreements ( Invalidated  in 2015) will need to re-negotiated in accordance with GDPR data transfer rules and regulations.
Get your office a GDPR champion
Or at least ensure your IT and operations staff follow some key principles
Sarah Caseberry from hp.com wrote a great article on how IT departments should prepare for GDPR and it covers some great essentials that you should already be doing, but with GDPR coming up fast, you should really consider re-visting or updating any policies that may be out of date.
I've copied a summary of her points below, but I strongly recommend reading Sarah's article for her full write up.
Stage One: Audit your Situation
- Audit your data
- Audit your service partners
- Audit all authorised and unauthorised devices with access to personal data
Stage Two: Access Control
- Ensure administrative privilege control
- Ensure tiered access to personal data
- Ensure remote access and erasure rights for company data
Invest in new, more secure devices, if necessary
- Implement a regular scan and security software update policy
- Ensure tiered access to personal data
- Implement real-time detect and response software
- Conduct employee training in cyber security
Articles I wish were published when I had started writing this: