Everyone loves a quiz so we decided we would kick-off the new year with a bit of tongue-in-cheek fun.
When is a DPIA not a DPIA?
I had the pleasure recently of seeing someone else’s Data Protection Impact Assessment come across my desk. I can’t tell you how refreshing it is to dissect and analyse a DPIA that hasn’t caused me to earn a few more grey hairs while working on its substance. There’s also the upside of learning from someone else’s work, picking up a few tips and hints from their approach.
Wisdom without the ageing effects! If only I could bottle that one.
This particular DPIA gave me an insight into the perils of using tools to drive your compliance rather than support your compliance activities.
Let me explain what I mean.
Despite being a technologist – my primary degree is in electrical engineering, and I worked in Telecoms for more than one decade of my career – I have always been slow to adopt technology for technology’s sake. That has made me hesitant to adopt tools to drive compliance activities because sometimes the tools and not the compliance become the focus.
This particular DPIA was a prime example. It used a software tool with an embedded DPIA template. It was literally a tick-box exercise – the template had a lot of tick boxes all of which were ticked with aplomb.
The thing was, the DPIA failed to examine the fundamental thing that DPIAs are designed to do. With all the box ticking going on the author had failed to ask that one key question – what exactly is changing about the personal data processing?
In the case of my DPIA this led to a failure to identify any of the actual risks associated with the processing activity.
In my example DPIA the key change was the introduction of two new data processors into the mix of a processing activity who were sharing information with each other and with another new third-party.
In their haste to tick the boxes in the template the DPIA authors failed to document what data would be shared with whom and how – there was no examination of the types of interfaces. Two were manual, requiring a person to key in data into two different systems, lots of potential data processing risks surfacing from that one small fact!
The DPIA failed to examine the processor contracts and assess whether they were fit for purpose. In fact, the DPIA didn’t even recommend that processor contracts should be put in place or processors assessed. It turned out one processor was processing data in Asia with no SCCs in place and neither processor was able to produce a set of documented Technical and Organisational Measures.
I blame the technology I really do!
It was a good reminder for me that no matter what tool you use, the human input is the most important aspect of the exercise. Next time you use a tool to support your DPIA exercise, make sure to resist the fact that the tool is trying to work you through this process as quickly and as efficiently as possible, ticking off things as you go.
Think outside the tool. Start with that one fundamental DPIA question that will lead you always down the right path - what exactly is changing here and therefore what aspect of the processing do I need to examine? I promise you, that one piece of analysis will be better than all the pages of boxes you will tick as you work onwards.
Join Our Newsletter
Sign-up to receive news and information from Fort Privacy
Fort Privacy processes your personal data in order to respond to your query and provide you with information about our products and services. Please see our Data Protection Statement for further information
Continuing the tradition of the Fort Privacy Christmas blog this year we are thinking about Santa and AI. Well, we need to keep these articles topical after all!
I’ve seen a few suppliers make classic errors dealing with breaches in their client’s data. Here are the top three errors suppliers make and 5 suggestions to avoid them!