GDPR: The Dreaded DPIA (Part XV)

Today’s guest post is from Tony Bridger, an experienced provider of Procurement Consulting and Spend Analysis services across the Commonwealth (as well as a Lean Six Sigma Black Belt) who has been delivering value across continents for two decades. He is currently President of UK-based TrainingWorx Ltd, a provider of a wide range of Procurement and Analytic business training programs (inc. GDPR, spend analysis, project management, process improvement, etc.) and focussed short-term consulting solutions. Tony can be contacted at tony.bridger@data-trainingworx.co.uk.

One of the key changes in the GDPR legislation involves the creation of DPIAs or Data Protection Impact Assessments.

At first glance this appears to be what can only be termed as a “mindless piece of bureaucracy”.

However, perhaps not.

Historically, it may be hypothesised that many personal data breaches have been the result of “mindless planning” neatly followed by badly managed execution.    It has been incredibly easy to obtain data, endlessly spam individuals — and share that data around.   Often, little or no thought, planning or impact assessment has been conducted in the process of managing this type of data.

Conceptually, the DPIA is a very good idea.   However, like many EU regulations the “how” is more obtuse and intricate.

The United Kingdoms ICO site (Information Commissioners Office) states that:

“You must do a DPIA for processing that is likely to result in a high risk to individuals”.

High risk is hard to define in the procurement world.   Many hosted procurement technologies contain considerable volumes of personal data as we are all aware – both controllers and processors need to stop and carefully assess any new data management proposals.   A DPIA creates a structured approach and framework that can be used to help define if the targeted processing could breach the regulation.

A DPIA is effectively a combined project brief and risk assessment of any new data processing activity that an organisation intends to conduct.   The DPIA contains a variety of what appears to be simple requirements.   The DPIA must:

  • describe the nature, scope, context and purposes of the processing;
  • assess necessity, proportionality and compliance measures;
  • identify and assess risks to individuals; and;
  • identify any additional measures to mitigate those risks.

If you think about it carefully, it is eminently sensible in its approach.

However, deductively there are several core organisational processes that need to be in place to achieve the outcome.   In many respects, this is the point at which the DPIA becomes a little more complex in the implementation and management.   If the organisational processes do not currently exist – then these are likely to add to the complexity.

In response to this, supervisory authorities have attempted to provide guidance and checklists that can help organisations manage this process and reduce risk.   We have left the discussion on DPIAs until this stage as there are options to use the process to overcome some of the risks with personal data in this domain.  However, there may be some good news.

In our next post we will start to evaluate how procurement data could be managed through the DPIA process.

Thanks, Tony!