GDPR – avoiding the problem? (GDPR Part IV)

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

For those with extensive risk management experience, avoidance is a key strategy for risk minimisation.

For those analytics suppliers outside of the European Union, this may well be a very feasible option. If we assume that spend data could contain P Card holder names, personal data in staff reimbursements and personal details in invoices – what are the avoidance options?

A myriad of options exist that analytics providers can deploy to avoid the personal data problem in risk terms. The first, and most obvious option (and least acceptable) is to refuse to take data from clients that that may contain personal data. However, the old adage applies that “some will always take the business, and someone will always do it cheaper”. Its also not a tenable under the GDPR, the fact that the client says the data is “personal data free” may not stand up if a breach occurs.

There is an old English adage that simply states that “you can’t eat a horse at one sitting”. If we start to break the problem up in to manageable components the potential issues become less intimidating.

One of the major areas of concern is P Card data. In the UK, many local councils and authorities publish their P card data for public access (in Excel files) on their websites – but with no personal cardholder data. It really focuses on the core question – does the client really need the name of the cardholder/Card number – or is the supplier spend the key focus? If the card data is extracted post reconciliation (if an Expense Manager is used for card management), the data will contain a cost centre. If the cost centre structure is loaded as a hierarchy it can be relatively easy to see where spend is occurring within the organisation – but not who incurred the cost.

The second key area is staff reimbursements. Many companies still set staff up as vendors to pay reimbursements. This spend too is quite insightful and may deliver several sourcing opportunities. However, it still leaves the personal data in the file that may be extracted from the ERP. For this element of the data, it may be far simpler to create a data mechanism that identifies those vendor master entries on the client ERP with a data flag of some kind. For statutory tax reporting purposes, many corporate clients are required to account for reimbursements for staff (for taxation purposes e.g. Fringe Benefits). So, if the client can remove staff names or attributable identifiers– then that will eliminate or avoid the data issue. In effect, there is the possibility that the problem can be eliminated on the client extract, but you must ask the client more about how they are extracting their data and guide them as to how they can better manage their data for GDPR compliance to prevent getting data you don’t want. .

In many respects, spend analysis providers have had it really easy up until now. They simply give the client a data extract request, the client provides what they can, and the provider builds the dataset. GDPR for EU clients makes this process less simple from 25th May. Why?

To be continued!

Thanks, Tony.