In this series of articles I will be looking at the new data protection regulation (GDPR) that come into force in the UK and Europe in the spring. I will be examining how GDPR will affect the development and design of organisational information to comply with the GDPR's "data protection by design" requirement.
In the last article in this series I talked about data controllers and processors and the responsibilities they hold under the GDPR. As a data processor for our clients, one especially involved with the provision of new systems, we have to be focused on the principle of "Privacy By Design".
In their guide to the GDPR the ICO points to privacy by design as an "essential tool in minimising privacy risks and building trust."
The roots of privacy by design can be found in Canada, the framework now generally adopted under the banner of “privacy by design” was developed by the Information and Privacy Commissioner of Ontario in the 1990s. The IPC of Ontario website provides access to a handy primer for the framework.
The primer describes the "7 Foundational Principles" of the framework, namely:
- Proactive not Reactive; Preventative not Remedial
- Privacy as the Default Setting
- Privacy Embedded into Design
- Full Functionality - Positive-Sum not Zero-Sum
- End-to-End Security - Full Lifecycle Protection
- Visibility and Transparency - Keep it Open
- Respect for User Privacy - Keep it User-centric
Although these principles do give visibility of goals to aim for in systems design they also provide their own share of headaches. Especially when it comes to weighing up system design priorities.
Part of the intention of the GDPR is to re-focus organisations on this framework. It's essentially a method of telling people that "Privacy By Design" should be one of their top priorities whenever they are looking to design a system.
Having something to shoot for in your system design is great, but if you're going to be designing a system you don't also want to analyse meaning in the principles guiding your design decisions.
Thankfully there are some resources available to guide your hand in a more purposeful direction. OWASP's site points to some concrete examples of the principles in action, such as "Anonymization of test data" and "Encryption of consumer data".
It may also be of benefit to appoint someone to attempt to limit data collection in a system design; making it someone's job to query every item of personally identifiable data collected and grouped ensures an extra layer of confidence that you've collected the bare minimum. The same person can be entrusted with the documentation of why you've collected the data you have.
The key aim here is to have respect for the privacy of parties whose data is stored, this is embodied in the final principle of the framework. Ring-fencing respect for privacy can be tricky, and is associated with the notion of obtaining consent from data subjects.
Best practice in the area of obtaining consent, particularly for the purposes of marketing, outlines some essentials in this area. Requests for consent should be:
- Separated from all other terms and conditions
- Explicitly opt-in, never defaulting to an opt-out state
- Consent for processing for different purposes should be siloed into separate requests
- Explicit in stating who will be obtaining and processing the data requested
- Fully reversible, data subjects should be crystal clear on their right to withdraw consent and how to do so.
Something that will help on the path to achieving Privacy by Design nirvana is the provision of a Privacy Impact Assessment (PIA) when looking at building a new system or introducing major modifications to an existing one.
The final article in this series will examine PIAs and provide some tools you will need on your journey towards GDPR compliance.