GDPR and its implications on testing

New EU data protection regulation raises tricky questions for businesses

The General Data Protection Regulation (GDPR) is due to be ratified in the near future. It is an EU regulation that applies to all EU member countries and it replaces the current Data Protection Directive from 1995. The point to note here is that a directive allows Member States to have some leeway to implement its provisions adapted to national circumstances, while a Regulation needs to be implemented as is, albeit with the usual potential for divergent interpretations and implementations.

The interesting thing for me are some of the implications around the nature of the consent that is required, which is somewhere between unambiguous consent and the stronger notion of explicit consent. There will still be an unambiguous consent model while on the other hand requiring such consent to be expressed“by a statement or by a clear affirmative action.”

This means there is no longer the possibility for an opt-out model. The related Right to Erasure also means that you or I could write to our bank or phone provider or anybody else that processes our data and explicitly state what they may or may not use that data for. Now, research reflects how there are people who do just this.* So, let’s consider the implications of the Right to Erasure in particular.

The first is that I might write to my bank and tell them that I do not want them to use my data – even if it is masked or otherwise obfuscated – for development and testing purposes. That’s going to be a headache. It means that if you take copies of your production database for testing purposes then you will have to filter out my data. Or if you take subsets, you will have to similarly filter out my data. And that’s not simply a single additional process, you will need some way of keeping track of the records that are not approved for use in testing. You could do this by inserting a new column into each relevant database table with a flag for read/don’t read or you could create a separate listing of all those customers whose data is not to be accessed. The problem with the latter approach is that, theoretically at least, you or I might object to being included in such a list. Which brings you back to flags, which means a lot of development and testing work just to support the process of development and testing. The alternative, of course, is to use synthetic test data generation and I can imagine this becoming increasingly popular precisely so that you don’t have to worry about who is in or out.

There’s another issue. Just as I might withdraw consent for my data to be used for testing I could potentially say that my data may not be used in analytic processes. That would reduce the rationale of your call centre if you cannot work out what my “next best offer” is. But there are actually two problems here. The first is in conventional data warehousing and CRM (customer relationship management) environments. Here you probably need to prevent my data getting into the warehouse in the first place. But how does your data integration tool know how to do that? Flags or lists again seem like the logical answer. Then there is operational analytics in HTAP (hybrid transactional analytic processing) or, worse, streaming analytics. If you are doing real-time analytics how do you exclude my data from the rest of the stream? Flags would have to be incorporated into the incoming data, which therefore means into the applications that the user is employing.

Finally, there are cross-border issues. Do you have one systems for the EU and one for the rest of the world? Or do you have one superset of applications that are deployed (parameterised) according to geography?

I don’t have the answers to all the questions I have raised here. I don’t even know if there are answers, and there will certainly be further questions surrounding the GDPR to come. What I do know is that, apart from appointing a DPO (data protection officer), you are going to have to think very seriously about the implications of GDPR.

Blog by Philip Howard, Research Director, Bloor Research


* Strategic Risk, Global businesses not ready for EU General Data Protection Regulation (January, 2016). Retrieved from on 12/04/2016


This blog was written by an external contributor. Any views held herein are not representative of CA Technologies, and are intended for informational purposes only.

New voices, thoughts and insights. This CA Technologies blog post features content written by an…


Modern Software Factory Hub

Your source for the tips, tools and insights to power your digital transformation.
Read more >
Low-Code Development: The Latest Killer Tool in the Agile Toolkit?What Are “Irresistible” APIs and Why Does Akamai's Kirsten Hunter Love Them?Persado's Assaf Baciu Is Engineering AI to Understand How You Feel