5 GOLDEN RULES HOW TO TEST IF ITS REALLY DATA PROTECTION BY DESIGN

I spoke at the Annual DPO Conference in Dublin recently about Data Protection by Design. Apart from really enjoying getting the opportunity to talk for 30 minutes on my favourite topic, I also enjoyed the opportunity to have my “Hyde Park Corner Moment”

I got on my soapbox about Privacy by Design and I relished it!

Data Protection by Design seems to be the topic du jour – the great data protection bandwagon of 2020. Everyone claims to be doing it – and almost nobody knows what it means.

What is happening out there is that data processors and technology providers are claiming on one hand to be “implementing privacy by design” and controllers who are desperate for reassurance about the products or services they are sourcing don’t know how to challenge this broad and sweeping statement.

SWEEPING OVERSTATEMENTS

The red flag I used to watch out for was “We are 100% GDPR compliant”. That was a great indicator that the company didn’t understand that compliance is a journey where the destination is always that bit further away.

That was my signal to start asking a few extra hard questions and dive a bit deeper. More recently companies appear to have figured that out and the message has moved onto data protection by design.

I have been told on more than one occasion since the start of 2020 that “We take a privacy by design approach”. Great, this sounds very impressive. The first few times I was hooked. This is fantastic, companies taking data protection really seriously.

My bubble was very quickly burst when I asked the obvious follow up question – so are you willing to share your DPIA findings with prospective clients?

The answer to that – invariably – we haven’t carried out any DPIAs.

One company even thought that their ISO27001 Certification qualified as Data Protection by Design. I think they were gutted when I didn’t fall for that.

Another company challenged me saying I was the only person who every questioned them about this, ergo I must be wrong. I am sure that I will be very welcome when I rock up to the Data Protection Commission with the excuse – well I thought it was okay because everyone else is doing it.

---

THE KEY TO DATA PROTECTION BY DESIGN

A risk-based approach to product and service development is at the heart of Data Protection by Design. The DPIA is the key privacy risk identification, assessment and mitigation tool. If you haven’t carried out a DPIA you aren’t taking a data protection by design approach.

There’s lots more to taking a Data Protection by Design and Default approach – design patterns, design process documents that include data protection considerations, techniques for embedding data protection considerations into the design, test and rollout processes, checklists, approval processes, stakeholder consultations – but it all starts with a risk identification exercise.

Someone who claims to be carrying out data protection by design who has not carried out a DPIA is bandwagoning and your non-compliance antennae should be on high alert.

---

CONTROLLERS ROLES AND PROCESSORS ROLES

The European Data Protection Board (EDPB) states that “Processors and technology providers are also recognized as key enablers for DPbDD” and that the “obligation also extends to any processing carried out by data processors”.

There is a real challenge for controllers who are outsourcing processing activities. It can be difficult to question processors when you don’t have an in-depth technical knowledge of their product The requirement to carry out a DPIA rests firmly with the controller but the reality is that they need processors to contribute to this in a meaningful way.

Controllers should be looking to processors to support the controllers DPIA by providing one that covers their scope of processing, by providing detailed data flow diagrams and by providing meaningful information about how data protection is embedded into their design approach.

---

FIVE GOLDEN RULES FOR EVALUATING PROCESSORS FOR DATA PROTECTION BY DESIGN

1. Don’t accept sweeping statements: Look for real evidence that will enable you to demonstrate accountability.
2. Learn to spot the Bluff: If there is no DPIA then the claim to be taking a Data Protection by Design approach is a bluff.
3. Ask the right questions: Controllers should be evaluating processors competence in this area. Asking a few key questions like “May I see your DPIA” and “Can you outline your design process for me please?” will get the true picture.
4. Look for written proof: If the processor can’t back up the claim to be taking a Data Protection by Design approach with documented evidence, then their approach to data protection by design is probably aspirational at best.
5. If you are not satisfied, look elsewhere: If you are a controller engaging a processor who carries out high risk processing, you should insist on seeing a DPIA and if you don’t get one factor this into your decision.

   ---

Further reading

For any software product developers and service designers who truly want to differentiate their product and service offerings there are two key papers to read.

• The European Data Protection Board published its guidance on Data Protection by Design and Default for public consultation in November 2019.
• ENISA published its paper Privacy and Data Protection by Design – From Policy to Engineering in 2014. It predates GDPR but it is still relevant and well worth reading and incorporating into your design processes.

---

DO YOU NEED HELP WITH IMPLEMENTING DATA PROTECTION BY DESIGN?

Fort Privacy offers short term engagements (starting from 6 months) to help businesses get their core data protection program in place. We equip our clients with the artefacts and the knowledge they need to ensure their ongoing compliance efforts are robust and well informed and we provide ongoing support on demand.]