Test data and GDPR when testing is outsourced

Why test data is a GDPR question

Testing needs realistic data. The quickest way to get it is to copy production, and that is where outsourced testing meets data protection law. Once a vendor's testers can see real customer records, the vendor is processing personal data on your behalf. You are the controller, the vendor is your processor, and GDPR sets out what must happen between you.

The European Data Protection Board's guidelines on controllers and processors describe a processor as a separate entity that processes personal data on the controller's behalf. A QA vendor running test cycles on your data fits that description.

What Article 28 requires

Article 28 requires a binding contract between controller and processor. Article 28(3) lists what it must cover. In plain terms, the vendor must:

• process the data only on your documented instructions;
• ensure its staff are bound by confidentiality;
• take appropriate security measures;
• use subprocessors only with your authorisation and pass the same obligations down;
• help you respond to data subject requests and meet your security and breach duties;
• delete or return the data at the end of the service;
• give you the information needed to show compliance, and allow audits.

The contract must also describe the subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects. The UK Information Commissioner's Office guidance on controller and processor contracts sets out the same list for UK GDPR. The contract clause builder includes a data processing clause and a subprocessor clause built on these points.

Transfers outside the EEA or UK

If the vendor's testers work from a country outside the EEA or UK, looking at your data from there is a transfer. You need a transfer mechanism, commonly the European Commission's standard contractual clauses, and an assessment of the risks in the destination country. Ask the vendor where each team member sits and where its tools store screenshots, logs and results. Tools hosted in another region can create a transfer even when the testers are local.

Masked, pseudonymised or synthetic

The strongest control is to not give the vendor personal data at all. The options differ in what they achieve under the law.

Approach	What it is	GDPR position
Production copy	Real records copied into a test environment	Personal data; Article 28 terms and security apply in full
Masked or pseudonymised	Identifiers replaced, but linkable back with a key or other data	Still personal data; lower risk, same legal obligations
Anonymised	Altered so that no one can be identified by means reasonably likely to be used	Outside GDPR, if the anonymisation holds
Synthetic	Generated data with the shape of production but no real people	Outside GDPR, provided it is not derived record by record from real people

GDPR's recitals explain that data which can be attributed to a person using additional information is pseudonymised and still personal, while anonymous information is outside its scope. Masking is a useful security measure, but do not treat a masked copy as if the law no longer applies. Test the masking by trying to re-identify a sample of records using what else a tester could see.

A default rule that works

Most buyers can use one rule: synthetic or anonymised data by default, production data only with written approval for a specific purpose and period. The framework's clause reads, in part:

[Supplier] will use only synthetic, anonymised or masked data for testing unless [Customer] approves in writing the use of specific production data for a specific purpose and period.

Pair it with an approval log that names the data set, the reason, the people with access and the deletion date. Some defects only show on real data, such as encoding issues in customer names. When that happens, grant a narrow, time-limited exception rather than a standing copy.

Places personal data hides

Personal data escapes into test artefacts in ways that are easy to miss:

• screenshots and screen recordings attached to defect reports;
• application logs copied into tickets;
• exported CSV files used to seed tests;
• chat messages pasting a customer record to explain a bug;
• device clouds and test tools that keep session recordings.

Include these in the vendor's data handling procedure and in the deletion confirmation at exit.

Checking it during due diligence

The due diligence checklist includes the data processing terms, subprocessor list, transfer mechanism and incident notification commitments. Ask for them before you score, not after you choose. Health data in the US brings separate rules; see HIPAA and testing vendors. For the wider security review, see a security questionnaire for a QA vendor.