DPIA – Friend, not Foe.

GDPR sets out the data privacy and security law which applies to most organisations handling the personal data of people in the EU. Our right to data privacy is front and centre of this law. It is therefore essential that we protect this right to privacy as we process personal data in our systems.  The 2018 GDPR EU regulation was transposed into Irish Law with the 2018 Data Protection Act (DPA). The punitive penalties for non-compliance made us all pay attention.

A Data Protection Impact Assessment (DPIA) is mandatory for many new (and some existing) systems. The Data Controller is responsible for the DPIA, so it is essential to be clear about your role on all aspects of a new system. Most of our systems have complex data architectures and information flows, so we need to carefully examine our relationship with the data.  Are you the sole controller, are there any joint or co-controllers, or data processors involved? Recent EU cases have revealed interesting outcomes when it comes to Controller vs Processor roles – see the EU Jehovah’s Witness case as a good example. We can’t assume that just because we don’t have access to data, we are not a controller.

While mandatory, the DPIA is actually a key ally to help ensure compliance with the DPA. While there is significant (and often overwhelming) guidance material available, see the Data Protection Commission guidelines, let’s simplify what it is, who does it, and when and how is it done.

So, what is a DPIA? In simple terms, it is reviewing the risks of your planned system to verify that you are protecting the data subject rights and securing their personal data, in line with your obligations as a Data Controller.

Who should do the DPIA? The project team for a new system is usually the best placed to do the DPIA. This is because they are the team with the best understanding of the system – from both technical and business perspectives.

When should it be done? A DPIA should be started as early as possible in the system development lifecycle. This will incorporate a ‘privacy by design’ mindset into the system.  Even in an agile world of incremental builds and evolving requirements, an early DPIA will positively impact design and reduce later re-work.

How should a DPIA be conducted? A useful way to think of it is under the headings of 1) Data Privacy : the proper handling, processing, storage, usage and deletion of personal data and 2) Data Security : protecting the data.

Let’s look at each one in turn.

  • Data Privacy. Consider the 7 key GDPR principles in relation to your planned processing. Include all data received from or shared with other organisations. What is the lawful basis for the processing? How long will you retain the data? Are you minimising the data? And so on.

 

  • Data Security. Evaluate the potential risks and how you will mitigate them. With an endless list of potential risks, try using the C-I-A approach. Confidentiality – identify the possible routes to unauthorised access to, or sharing of, the personal data. Integrity – how might unwanted modifications be made to the data? Availability – could the data be removed and therefore lost? For each risk, identify your relevant controls to mitigate them. You may spot gaps in your design or in your policies which you can address now. If you are left with unacceptably high risks, despite your controls, you must consult with the DPC. In this case, it may be preferable to re-think your plans.

 

Doing a DPIA may feel daunting, especially for smaller organisations with limited experience or resources. Try to think of the DPIA as your friend in the context of GDPR compliance. Play out the subject rights as you think through all the possible scenarios of what could go wrong. The cyber security industry is in constant catch up mode, so it is impossible to think of every risk –  “we don’t know what we don’t know”. Future data breaches and cyber hacks will reveal new sources of risk and we will respond with new controls to mitigate them. An on-going case with the HSE in Cork illustrates this point. Which of us has “do not use your mobile to take photos of personal data on your screen” in our Acceptable Usage Policy?

Make sure you keep records during your DPIA. In the event of an audit or breach, it will be the first thing you are asked for. Even the largest global organisations can fall foul of this, see the 2020 Facebook DPIA case where a dating service launch had to be halted ahead of a planned Valentine’s Day release.

Finally, your DPIA is a living document. You must keep it under review, especially with significant changes in your processing. Keep your focus on the controls you have in place for the DPIA. Remember that the DPIA is merely a statement of intent – it is not what you say will do, but what you actually do, that counts.

 

If your project requires a DPIA or you’re trying to figure out if you need a DPIA, get in touch and we’d be happy to talk!

 

This post was contributed by Sue Mateja, associate consultant with Clarion Consulting.