What is purpose binding of personal GDPR protected data & what this means for IT professionals

Table of Contents▾

Over time I noticed a common pattern when speaking to people in the community at conferences and meetups over and over and over again: “Production data is copied over to Acceptance for better UAT testing”. If you work with GDPR-protected personal data in the EU you should be very careful with doing that, as it is more likely than not that you are breaking the law here. In this short piece I will take the GDPR directive and show:

1. Why you are non-compliant / breaking the law if you do that

2. One way to do it correctly

---

Why “copying production data over” is very problematic & must be avoided#

When working in IT we navigate very complex problems, requirements and implementations. However, very often projects tab into dangerous waters without anyone noticing. In my experience in a room full of IT professionals legal compliance, especially GDPR, EU AI Act & NIS2, are often overlooked or not thought about. Why this is dangerous we will see by a typical use-case: “To improve UAT testing the business demands production data in the acceptance environment, or they will otherwise not test”. And to be fair, this has a point. We as IT are service providers to the business and must enable them to do the core business of the organisation’s better, more efficient, cheaper etc. In the end IT is not there for IT sake but to be used as a tool. So, just straight up rejecting this claim is, in my humble opinion, no option for a service oriented IT development team.

However, what happens far too often is the following: Someone from the IT team copies over PROD data into the ACC environment and marks the ticket as “done”. This is highly critical as can be seen in Art. 6 of the GDPR directive and/or the respective local implementations of this legislation. So Art. 6(1) & Art. 6(1)(a) state (in plain English):

1. Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;

What does this tell us: Data is given by natural people to our organization for a specific purpose! So say it in blunt English: “Customer wants to buy a service and get the invoice, therefore provides email, first-and last name, IBAN”. He did not give us his data to do testings of our software (except in some very very rare cases where legitimate interest can be claimed in controlled environments that can otherwise technically not be tested - like certain banking systems - and in this case super strict IT security measurements must be adhered), AI training, testing of a random API integration and so on and so forth. Art. 6(1) (b) then goes on and states this again in plain English:

(…) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

So, you are allowed to - let’s stick with the example - use the personal information of a person for: Managing the purchase order, organizing the shipment, and send the invoice. This is the reason that in most CRM systems you have this small button “GDPR opt-in” that gets ticked if the person agrees his data being used for marketing purposes for example. Now, what happens if you copy over production to acceptance environment “for better UAT testing”? Well, you violate GDPR and perform a non-compliant action that might cost you dearly in a non-compliance cases. Companies paid millions of EUR for similar mistakes in the near past, so it’s for sure not peanuts. Besides this, you really do not want to see your organization (or IT partners name) in the news for an incident like this.

---

One way to do minimize compliance risks#

Ideally, if you have the need to use production data available in non-production environments you should have a data-pipeline of some sort ready that does the anonymization automatically for you (some Azure Data Factory or similar tools). There are a lot of tools available and it’s not rocket science by any stretch of the imagination. One tool I like it the Microsoft Presidio tool I recently shared in a post: microsoft.github.io

What we need to achieve is filter out so called PII, so personal identifiable information. Important to note is that you must anonymize in a way that a person cannot be re-identified. For example: Hans Muller, Born 01.01.1990 in Berlin, IBAN BL3828273, Street Address Hans Wurst str. 1, 83394 Wursthausen. This record you would need to anonymize to a degree that Hans cannot be back tracked for example by checking who was born 1st of January 1990 as a boy, and has first name “Hans”.

Let’s try this Presidio quickly with some demo data to see if that works or not. Lets assume we have a couple of data points that contain PII: With the Microsoft tooling which has an NLP model behind it we can scan data and dynamically anonymize them.

For simplicity sake we have data that looks like this:

Sample Raw Data

We would like to use this data but potentially anonymize it to a degree acceptable to the CISO and/or legal department. With a little bit of code you can transform the data above into something like this:

Data after putting PII away

Whether this is enough in terms of anonymization depends on your requirements. For guidance you can read recital 26 of the GDPR directive which provides more detailed guidance of what to do and how to do it:

The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore 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.

One last thing: Just be aware this approach is ML based, so it’s not 100% bulletproof. That is why I said at the top “minimize compliance risks”. If you need 100% you need to map every single field manually and erase the data with an appropriate tool - or develop a way more sophisticated AI tool. So, next time you are sitting in a meeting and those kinds of topics are discussed… think about it! There is a difference in IT between “can I do something” and/or “how to do something” and “should I do something”

---

Disclaimer#

This post is for informational purposes only & only constitutes the opinion of the author - not the companies the author might be employed and/or connected with in any manner! Also this does not constitute legal advice. For specific guidance related to the topics discussed or other legal matters, please consult a qualified professional / lawyer and/or audit firms tech consultancy advisory for qualified and legally binding answers.