/ gdpr

The GDPR and "Privacy By Design"

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.

Castle on remote rise in a forest, accessible by a single road.
Photo by Steije Hillewaert / Unsplash

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:

  1. Proactive not Reactive; Preventative not Remedial
  2. Privacy as the Default Setting
  3. Privacy Embedded into Design
  4. Full Functionality - Positive-Sum not Zero-Sum
  5. End-to-End Security - Full Lifecycle Protection
  6. Visibility and Transparency - Keep it Open
  7. 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".

When placed in such stark terms the business of reviewing data storage and processing practices risks a descent into banality. There are, however, less obvious actions that can be taken such as explicit specification of what, how and why data will be collected (perhaps something to be recorded in a plain-English privacy policy easily accessible via your website).

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.

Leo Stableford

Leo Stableford

Code Wrangler, self-publisher and content enthusiast. Leo wants to get everyone talking, although everyone occasionally has to tell him the best way to achieve that would be for him to shut up.

Read More