Data protection by design and default – what does that mean really?

It’s an obligation in GDPR, but it can still be confusing to get to the heart of what ‘data protection by design and default’ really means, and what you need to do as a result.

It’s often used as a proxy for ‘do a DPIA’ but it’s so much more than that. I’ve seen it described as building or baking in data protection from the start. That’s more accurate but still leaves the question “yes but what does that actually mean?”

What does GDPR say?

It helps to go back to the source, not just article 25 GDPR (1) and (2) but also recital 78. These tell you what the legislators were concerned about, namely implementing the principles. They specifically call out the following.

• Data minimisation
• Purpose limitation
• Retention
• Wide disclosure / accessibility of the data
• Transparency
• Making sure individuals know what’s going on
• Allowing organisations to set up and improve security measures.

Both the article and the recital mention pseudonymisation as one way to implement the data minimisation principle. It’s an example though, not a mandatory requirement.

The end of recital 78 seems to be directed at those producing software and systems, as well as public tender processes. My take on this is that the legislators were keen to make sure that organisations needing to comply with GDPR didn’t fall at the first hurdle due to a lack of thought for data protection compliance in systems and software. Their expectation is clear for those designing these things for organisations, and I think their hope was that it would lead to software and systems producers having to raise their game to stay competitive.

How to put data protection by design and default into practice

To put this obligation into practice, people often jump to PETs (privacy-enhancing technologies, not Charlie the golden retriever). There have been loads of studies, reports and articles on a range of specific technical measures, too much to go into here. In reality, and in my experience, these more sophisticated methods and third-party software solutions tend to only be available to those with deep pockets and an internal tech team.

The reality for many organisations is to embed DP compliance into processes and policies. When I work with clients on this, I tend to start by looking at how things get done in their organisation.

• How do you go from “I’ve had a great idea” to “it’s gone live today”?
• Where are the gatekeepers and / or the decision makers for ideas and projects?
• How do you manage and record the different steps, phases or tasks needed?
• How do you identify who needs to be involved, and then involve them?

Once you understand the process and who’s involved, look at what already exists. Many organisations use certain tools to project manage, to assign tasks to people, to report and manage bugs or other issues and so on. Many organisations already have a form or process to suggest ideas, ask for approvals, and to get items on the to do list.

I have found an effective approach is to build on what is already there. No-one will thank you for introducing a new 4-page form on data protection stuff. No-one will fill it in. Where are the points in the processes, or on the forms, or in the tool template to add the DP stuff? Can you add in questions, checklists, templates, approval points and the like?

Examples of data protection by design and default solutions

Speaking of checklists and templates, one of the most effective DP by design ‘solutions’ was where the organisation created a ‘standard build template’ that incorporated key DP principles. So anytime anything needed building or expanding, the build requirements already included things like specific security measures, elements of data minimisation and controls for the end users.

With another organisation there was a two-part solution. One part was for those developing the idea and deciding on the data collection. This involved adapting their project documentation to include key elements from a DPIA and a way to check each data field requested was actually necessary, as well as identify where it might be sensitive or need greater care. The other part was a checklist for those implementing the new thing that set out some core requirements such as the ability for the end user to take certain actions with their data, and what settings or controls had to be off by default. This approach also encouraged better communication between the two groups, as they worked together on which solutions would best implement the core requirements.

Think of the people

Getting to a practical implementation of DP by design and default involves taking a people-centred approach. Both in terms of collaborating with the relevant people internally, as well as thinking about impacts on and risks to the individuals whose personal data you are doing things with.

You also need to consider your organisation’s position on DP compliance. The law might want everyone to do the gold standard, but that’s not the reality we live in. How far you go in implementing DP by design and what your measures look like will be influenced by things like your organisation’s risk appetite, their approach to risk management, any relevant vision or principles they have, or any frameworks or internal committees in place covering compliance, ethics, and so on.

Your colleagues can also be a great asset. Your business development people will have information on what corporate customers are asking for, your end user support people will have intel on what the users complain about. How far do these overlap and where do they conflict?

For example, I have seen the same transparency issue in multiple organisations where both corporate customers and end users want to understand how the product or software works. The corporate customers need to do compliance diligence, and the end users want to know if they can trust the organisation with their data. Producing something for both audiences on how it all works not only helps implement the transparency point of article 25, it also checks if different parts of the organisation have the same understanding of how it works, and flags up discrepancies.

Sometimes, doing something because it leads to a good consumer experience or higher levels of satisfaction gets you to the right place, and can be an easier sell than labelling it a ‘DP compliance requirement’.

Some organisations have the resources to do user research and surveys, and the results of these can be very useful to the DP people. If you can work with and understand the objectives and the pain points of colleagues (such as those managing infrastructure, information security, compliance, risk management, customer support and even the executive team), you’ll be in a good place to see where you slide in your DP stuff, and piggyback on other initiatives.

This is one area of GDPR that takes an outcome-based approach. And the joy that is that it is scalable and adaptable to each situation, and to each organisation’s resources and capabilities. So by focusing on the required outcomes, and putting people at the centre, achieving data protection by design and default can be a lot easier than it first appears.