Data protection by design has been a core concept in privacy management for a long time now.  The idea is that, when you are designing a new system or changing a process, you consider data protection principles at the earliest possible stage. And in practice, as the change progresses, those decisions are reviewed against those principles.

The General Data Protection Regulation (GDPR) Article 25 has codified that – building in part on the excellent guidance issued by the UK Information Commissioner. It places concepts of minimization, accuracy and respect for data subject rights at the heart of good privacy practice – with decisions to be judged, where necessary, through a Data Protection Impact Assessment (DPIA).

As a privacy professional, it would be lovely to be involved in the very first conversations about a new process or major change. As security professionals will also know, that very rarely happens.  Instead it could be weeks or even months before the manager leading the change realizes that they will have to ‘tick the compliance box’.

At which point, the job is tough on everyone – the privacy compliance person has to break the news that the project has a few issues, and the change owner realises that their timeline is likely to be blown while data protection concerns are addressed. It’s this experience that leads to the common issue of compliance teams being seen as a business blocker – and blame sits on both sides; the manager who failed to follow the defined change process (assuming there is one of course!), and the data protection team for not being accessible or engaged enough to get its messages through.  Throw in delays and increased costs and suddenly there is a lot of explaining to do…

One way to head this off is to bed in some basic good practices that apply to any type of business change – primarily, getting the change owner to establish very early what outcome they are trying to achieve. Why are they doing it?  It could be to mitigate a risk, to develop a new product, improve process efficiency. In identifying the deliverable, you can start to work out with the change owner what the privacy issues will be – including whether they need to process personal data at all.

Chasing down that ‘why’ is, for data protection by design, even more important than the ‘what’ or ‘how’ to begin with. For a start, it establishes the purpose of the processing, but may also enable you to consider other means of getting to the outcome. The most obvious example here is anonymization. If the desired outcome is to produce management information for the board, even relating to HR data, there is a good possibility that you can drop out the personal data very early. If it’s for a financial analyst to detect anomalous payments, the data could be pseudonymised. If to detect IT threats, the IT analyst doesn’t need the username of the individual who was logged in.  

Beyond that, purposes underpin lawfulness, and acceptability to data subjects – if the ‘why’ is something incompatible with either your privacy notice, or the consent you have, then there is more work to do. So, ‘why’ sets the tone for the whole question of ‘what’ (the processing to be undertaken) and ‘how’ (the exact means of processing – whether technology, a filing cabinet, or a human interaction).

Of course, having established the ‘why’, the ‘what’ and ‘how’ quickly come into play too. The ‘what’ should be directly shaped by the ‘why’ – the most obvious considerations here are elements such as transparency and proportionality. Transparency because, whatever you’re planning on doing to meet the ‘why’, you need to make sure that data subjects are aware of it within your privacy notice.  Proportionality, because, while what you plan to do may be ok if targeting a small amount of data, applying it to a whole population or 24/7 might be considered excessive.

How processing will be delivered has clear impacts on data protection by design. If you’re engaging a third-party vendor, you’ll need to assess them, and their solution against security and privacy risks.  If you’re using a new (for you) technology, or combining data sets in a different way, you will have to start that balancing up of what you’re doing against the rights and freedoms of your data subjects.  Which, of course, is founded on why you’re doing things in the first place – and where the DPIA comes in.

You can, of course, sow ‘whys’ in throughout this process. Stealing from root-cause methodology, asking ‘why’ multiple times is the best way to get to the bottom of a decision quite quickly, and it may well get to positive outcomes – confirming that decision is the right one, as well as challenging it. As data protection professionals, understanding that Z happened because of Y and Z preceding it is a useful tool, and it can apply equally to pre-emptive assessment.

And don’t forget, EU regulators are looking closely at vicarious risks to individual rights. It was restated in the recent DPIA produced for the Dutch Government that, where there is a possible risk to individuals due to the types and quantities of data being collected, even if there is no immediate plan to use the data in a way which would realise that risk, the processing may still be considered high. A great example here is the collection of metadata on mobile technology users – a subject discussed in a recent blog post by one of our threat intelligence team.

There’s also the question of ‘what else’. Privacy by design is not just about not doing things, but also about ensuring that you can do certain things. You still need to think about individual rights – access, amendment and deletion – and ensuring these factors are considered up-front and built into the processing activities will save everybody from getting a nasty shock later, when you realise that gigabytes of data over multiple databases will be in scope. It may also act on a sense on the design itself. If the change owner is suddenly uncomfortable that individuals will be able to get to the data held, or may challenge the extent of the processing, that’s probably a great time to be revisiting at least the ‘what’, but probably the ‘why’ too.

And getting this all down on paper is key too. Evidencing the thought process that leads you from the ‘why’ through to the ‘how’ and ‘what else’ will stand you in good stead both with your data subjects and, should it come to it, with the regulators. It should also mean that you, and your business, have a far better handle on the types and, importantly, the reasons why you are processing the data you’re processing – and build the culture of data protection by design and default that will be a game-changer in a mature culture of compliance.