GDPR Article 25: Data Protection by design and by default – what does it all mean?
Opinion Piece by Paul Gillingwater, MBA, CISM, CISSP
Most developers I know are not specialists in data protection, and most data protection experts I’ve met aren’t really developers, which is why it’s not surprising there is some confusion in the GDPR world about Article 25.
The first paragraph is a doozy, so let’s have a crack at picking it apart for meaning.
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
Privacy by design is not new in the field of data protection, however, it is new to see it as a legal obligation.
The drafters consulted with developers and wrote law that they felt would best encapsulate their thinking on privacy design. They start with citing “state of the art”, then go on to mention the cost of implementation, the various attributes of processing, and the risks to rights and freedoms of individuals.
This provides a clear context for making design decisions — they should be practical, affordable, and grounded in analysis of the potential risks.
It’s important to note that the legislation is not only talking about software design (which is important), but relates to all aspects of processing personal data, from its initial capture, through to processing, transmission, storage, archiving and eventual deletion.
The key point is that privacy considerations have to be considered from the outset.
How does a designer take privacy into account?
A great place to start is purpose and data minimisation. Articles 5(1)(b) and 5(1)(c) require processing activities to limit the processing of personal data to the minimum required by the purpose, and to limit the data in the same way.
Let’s take an example. Imagine you are signing up to an online gambling web site, governed by the UK Gambling Commission laws. Such a site will typically ask for your name, address and email address, along with bank payment or credit card details. They’ll also ask for your birthday, as gambling is age-restricted.
But how do they know the information you’ve provided isn’t fake?
That’s a real issue, so they ask for additional information, such as proof of identity and proof of address. The former means providing them with a scan of government-issued ID (like a passport or driver’s license), while the latter is normally satisfied by a recent utility bill, showing your name and address.
All of the above is legitimate and proportionate, with the information requested being dictated by the appropriate laws (UKGC and AML regulations.)
Now imagine an online supermarket asking for the same data. Do they have the right to demand identification? Or proof of address? Somehow, that doesn’t seem proportionate.
Purpose Minimisation or Data Minimisation
Purpose minimisation means using the data collected only for the purpose stipulated at the time of collection. If the gaming web site decides that you are a high roller, and starts selling your details to other gaming sites or luxury goods sellers, they are violating this principle.
Data minimisation means that the personal data that was collected is all necessary to achieve the stated purpose. As an example, consider the collection of the date of birth. Some businesses require this, to verify that the customer is over 18, and thus able to sign a contract.
Data minimisation may mean that it’s enough to capture the entered birth date, then perform a quick date calculation to confirm age, then record the success or failure of that calculation. This would allow the birth date to be deleted.
Sensitive or Special Data
One specific area where privacy professionals must remain vigilant is in terms of the classification of sensitive or special categories of data, and the required protections they demand.
For example, location information by itself is not considered to be sensitive, however when correlated with other information, it can become so.
Similarly, a person’s sexual orientation might become apparent when the name and gender of their spouse is associated with the record, thus becoming special category data. It’s essential that this level of analysis is associated with any development, especially where profiling might be involved.
In any case, when considering the user interface design for internal administrators, it’s a basic privacy tenet to hide information which is not strictly required to carry out the job. That implies the use of a sufficiently granular role-based access control mechanism, and the use of interface elements that properly mask sensitive or unnecessary data elements.
Appropriate use of pseudonymisation
Another area that developers should pay attention to is the use of pseudonymisation as a protective measure. Normally used in the health-care industry during clinical trials, pseudonymisation means that identifying elements should be removed from data sets before secondary processing is performed.
The ability to properly pseudonymise data is essential in protecting the privacy of individuals involved in clinical trials, and special attention should be given to this due to the sensitive nature of health data. Ideally, the Data Controller should be taking the lead in insisting on the minimisation of personal data storage or retention, under the guidance of the DPO or other privacy professionals.
Another helpful guideline for pseudonymisation may be found in HIPAA advice, which lists 18 data elements that should be removed in order to reduce the chances of re-identification.
A great resource for such privacy professionals is a recent opinion from the European Data Protection Supervisor (EDPS), available here. This opinion explains the history of DPbDD principles, and shows how they inform best practices in privacy software engineering.
The bottom line is that developers need to take into account key principles of data protection from the initial stages of collecting requirements, making them part of the minimum viable product (MVP.)
This can only be done by educating your designers, architects, business analysts and programmers in core privacy concepts, and submitting design documentation to privacy practitioners as soon as possible in the SDLC.