Daily Archives: May 8, 2018

GDPR – still avoiding the problem? (Part V)

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.

In our last post we noted that those with extensive risk management experience know that avoidance is a key strategy for risk minimisation.

We also noted that this may well be a very feasible option f-or those analytics suppliers outside of the European Union.

The GDPR actively supports the anonymisation approach:

The principles of data protection should …. not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.”

By removing or replacing data elements this satisfies another element of the Regulation – pseudonymisation:

the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.” (Article 4).

Credit card or card account numbers can be used to identify a person – many card systems encrypt or hash the card number if expense managers are used. Once again, it pays to do the data homework.

The salvation for many spend analytics providers is to encourage the client to set data extract routines that eliminate these types personal data.

However, that still leaves us with the less easily manageable data component of personal data buried within invoice line descriptions or other ERP free text fields.

Once GDPR becomes recognised as the “new paradigm”, analytics providers are likely to claim that they have all sorts of (chargeable) capability to remove this data or anonymise it. This is more likely to revert to a line by line manual check as opposed to anything technically complex or ground breaking.

There is nothing intrinsically wrong with this approach. It may be time consuming but will follow the usual pattern of spend analytics data management. The first stage of the dataset build is historical data construction. If all historical spend data is checked and anonymised, then monthly refresh data is much lower volume – and patterns where personal data may exist may have already made their presence known – a pattern.

Vendors and clients are therefore taking all reasonable precautions with the data. If the data can have all personal elements removed, then GDPR does not apply. The “shotgun approach” for web providers is to use full access encryption…but this could be prohibitive in cost terms.

So, what is the risk? Spend data with personal data content has to align with the Regulation both within the EU — and transferring data outside of the EU. The use of surgical data techniques can reduce the risk and perhaps even reduce the data to non-personal in nature.

The alternative option is to leave the personal data and adhere to the range of controls that are required to manage that information. We have yet to cover these controls in any detail.

As we will discuss later in a later post, staff, employee data and personal data may also be subject to consents. A considerably more complex issue under GDPR. With new elements like right to be forgotten it may be simpler just to remove the data components.

No one said this was going to be easy.

Thanks, Tony.