Personal data in test environments: can we test with real customer data?

It is half past three on a Friday. A developer needs to track down a bug in the invoicing module that only affects a handful of customers, and the quickest route is to copy the production database into the test environment. The bug is found before the weekend. The copy, with 40,000 customers, their payment history and customer service notes, stays where it is. The scenario is invented, but it is hardly unusual.

Is this lawful? For private businesses it can be, but only after a specific assessment that most never carry out.

What does the GDPR say about personal data in test environments?

The GDPR has no dedicated rule on testing and development. Using production data in a test environment is a further processing of the personal data, and it has to fit within the general rules of the General Data Protection Regulation, which applies as Norwegian law under the Personal Data Act (personopplysningsloven) § 1.

Three principles do the work. GDPR Art. 5(1)(b) lays down purpose limitation, so data collected to deliver a service and send invoices cannot be further processed in a way that is incompatible with that purpose. GDPR Art. 5(1)(c) requires data minimisation, meaning no more data than the purpose needs. And GDPR Art. 5(1)(e) limits how long the copy may be kept.

Testing a system that already processes the same data sits close to the original purpose. Developing a new product, or training an AI model on customer data, sits further away. Several of the basic rules are explained on the data protection topic page.

How do we carry out the compatibility assessment?

Where the processing is not based on consent or a specific statutory basis, the business must assess whether the testing purpose is compatible with the original one. GDPR Art. 6(4) sets out the factors.

• The link between the purpose of collection and the purpose of testing.
• The context in which the data was collected, in particular the relationship between the customer and the business.
• The nature of the data, and whether it includes special categories under Art. 9 or data on criminal convictions and offences under Art. 10.
• The possible consequences of the testing for the data subjects.
• Whether appropriate safeguards exist, such as encryption or pseudonymisation.

In practice the assessment often comes out in favour of testing existing functionality with a limited extract that is secured as well as production. It comes out in favour of moving the whole customer base into a development environment with broad access far less often, and almost never where health data or data about children is involved. If the purpose is compatible, the processing can rely on the original legal basis, according to Recital 50. We still recommend documenting the assessment in writing, because that is what the business will have to produce when the Norwegian Data Protection Authority (Datatilsynet) asks.

Why is the Financial Supervisory Authority asking for its own legal basis?

On 13 August 2026 the Norwegian Ministry of Finance put out to consultation a proposal to amend the Financial Supervision Act, with a deadline of 6 October 2026. The proposal comes from the Financial Supervisory Authority of Norway (Finanstilsynet), and its consultation paper is dated 1 June 2026.

Under the proposed new § 6-6 of the Financial Supervision Act (finanstilsynsloven), Finanstilsynet may further process personal data, including special categories and data on criminal offences, where this is necessary to develop and test IT systems and it is “impossible or disproportionately difficult” (our translation) to achieve the purpose with anonymous or fictitious data. The factors in the proportionality assessment include the complexity and scope of the work, timing, costs and expected benefits.

The consultation paper matters to private businesses for two reasons. Finanstilsynet considers that its current legal basis probably covers testing of existing systems closely linked to its supervisory tasks, but that it is unclear how far it extends to developing new systems and to the use of AI. And the authority states plainly that the GDPR’s requirements for anonymisation are very demanding to meet. The paper also notes that the Norwegian Tax Administration, Norwegian Customs and the State Educational Loan Fund (Lånekassen) already have such provisions in their own legislation.

Public bodies processing data in the exercise of official authority need a supplementary legal basis in national law under GDPR Art. 6(3). Private businesses have no equivalent rule to rely on. They have to carry out the compatibility assessment themselves, without a statute that has already weighed the interests for them.

When even a supervisory authority thinks it needs a statutory basis to test with real data, a private business should have a written justification before it does the same.

What does Datatilsynet say about test data?

The chapter on testing in Datatilsynet’s guidance on software development with data protection by design says that synthetic personal data should be used. Datatilsynet itself states that the guidance is no longer sufficiently up to date and that a new version is being prepared. The starting point of synthetic data is nonetheless supported by GDPR Art. 25, which requires data protection by design and by default.

Datatilsynet has also shown what happens when it goes wrong. In 2021 the Norwegian Confederation of Sports (Norges idrettsforbund) received an administrative fine of NOK 1,250,000. While a cloud solution was being tested, personal data on 3.2 million people, children among them, lay exposed on an open IP address for 87 days. Datatilsynet emphasised that the confederation had no legal basis for using real data when fictitious data would have been sufficient.

What are the alternatives to real data in test environments?

The choice is between four levels, and only the first takes the data outside the GDPR with certainty.

Pseudonymisation is defined in GDPR Art. 4(5). The data is processed so that it can no longer be attributed to a specific person without additional information, which is kept separately and secured. Pseudonymised data is still personal data for whoever holds the key. The EDPB has elaborated on this in its guidelines on pseudonymisation, so far only in a consultation version.

The line between pseudonymisation and anonymisation is harder to draw than many assume. Synthetic data generated from real customer data can also leak information about individuals. We cover this in the article on the EDPB’s new guidelines on anonymisation.

What security measures does the GDPR require in the test environment?

A test environment holding real personal data is a production environment in GDPR terms. GDPR Art. 32 requires a level of security appropriate to the risk and mentions pseudonymisation and encryption as examples. Test environments are often less well secured than production, with shared accounts, wider access and less logging.

In concrete terms, the business should limit access to the developers who need it, log look-ups, encrypt storage and set a fixed deletion date for each extract. The extract should contain only the fields the test requires. A free-text field with customer service notes is rarely needed to test an invoice calculation. Where the risk is high, for example with special categories or many data subjects, the business must consider whether a data protection impact assessment is required.

What should the data processing agreement say about test environments?

When a supplier develops or operates the system, the testing often takes place at the supplier. GDPR Art. 28(3) requires the processor to process the data only on documented instructions. Any use of the customer’s production data in the supplier’s test environment must therefore be covered by those instructions.

Read the data processing agreement with this in mind. It should state whether the supplier may copy production data into test, which security measures then apply, where the test environment is located, which sub-processors have access and when the copy is deleted. If the supplier uses the customer’s data to improve its own product for all customers, it is processing the data for its own purposes and becomes a controller for that part under GDPR Art. 28(10). There is more on this in the article on the data processing agreement for SaaS.

What should the business do?

1. Map all test, development and demo environments, and find out which of them contain copies of production data.
2. Make synthetic data the default, and require a written justification for exceptions.
3. Document the compatibility assessment under Art. 6(4) for each extract of real data.
4. Pseudonymise or mask direct identifiers, and remove free-text fields that are not needed.
5. Apply the same access control and logging in the test environment as in production.
6. Give each extract an owner and a deletion date, and check that deletion actually happens.
7. Review the data processing agreements and see whether the supplier’s test environment is regulated.

Start with step 1. A test copy that nobody remembers creating usually has neither an owner, a deletion date nor a compatibility assessment, and it is the first thing Datatilsynet will ask about.

Questions and answers

Next legal review: 1 March 2027