DORA Articles 8 and 16: What They Mean for Your Test Data

Jun 8
7 min read

Financial entities in scope under DORA are looking to build stronger data privacy, security, and operational resilience controls into their ICT architectures while continuing to innovate at speed. Here’s a practical guide for financial innovators to protect the privacy of sensitive customer data in test environments in compliance with DORA.

Tokenization for secure non-production environments

Protecting sensitive data has become one of the hardest problems financial institutions face, and yet one of the most risky and overlooked sources of exposure results in customer data ending up in test environments. Your ICT environment is not fully resilient until customer data is protected across the full software lifecycle. Financial entities need to architect proactive test data protection controls into their environments to reduce exposure, preserve data utility, and support DORA compliance.

In this article, we’ll look at what DORA requires for test environments and how Bluemetrix SecureToken Vaultless Tokenization helps teams create secure, production-faithful test data without exposing raw customer information.

What DORA Requires for Test Environments

DORA has been applied across all 27 EU member states since January 17, 2025, and its enforcement powers have come with it. National authorities can now impose administrative fines of up to 2% of a financial entity's total annual worldwide turnover. Senior managers can be held personally liable, with individual penalties reaching €1 million. Critical ICT third-party providers face their own separate exposure on top of that.

Numbers like those move data protection out of the "we will get to it" onto the critical path. Beyond the fines, DORA spells out the level of specificity of the regulation regarding test data, which is where Articles 8 and 16 come in.

Article 8 makes “separation” a core requirement. Separating environments and desisting from using customer data in testing are foundational disciplines. Development and testing must take place in environments separated from production, and “separated” encompasses all components of full testing environments, i.e., user accounts, datasets, connections, APIs, integrations, and supporting infrastructure. If the test environment is still wired into production, it falls short of meaningful separation.

While Article 8 establishes the direction for environmental separation, Article 16 sets out the data rule in plain language. Non-production environments may only store anonymised, pseudonymised, or randomised production data, and the financial entities remain responsible for the integrity and confidentiality of the data in those environments. Where production data is used for specific testing occasions, this must be time-limited, approved by the relevant function, and reported to the ICT risk management function.

The table below summarises what Articles 8 and 16 cover for test environments:

Requirement	What DORA says	What it means in practice
Environment separation	Development and testing must be conducted in environments separated from production.	Test environments need clear boundaries from production systems, not just a different label or server name.
Scope of separation	Separation should consider the whole testing environment.	Financial entities need to review infrastructure, access, datasets, integrations, APIs, and system links together.
Testing and approval	ICT systems must be tested and approved before use and after maintenance, with testing based on criticality.	High-risk systems need stronger test controls, documentation, and approval before changes go live.
Test data protection	Non-production environments may only store anonymised, pseudonymised, or randomised production data.	Raw customer data should not sit freely in test environments.
Production data exceptions	Production data may only be used for specific testing occasions, for limited periods, with approval and reporting.	Any use of real production data must be temporary, justified, approved, and visible to ICT risk management.

Why Sensitive Data in Test Environments Creates Risk

Failing to meet DORA requirements is an immediate compliance risk. Just as concerning, test environments can turn into hidden points of exposure for sensitive customer data.

By design, most testing and development environments prioritise agility. There are sandboxes where teams can have broader access, more frequent iteration, and less mature controls than production systems. When production-like data containing sensitive or PII data is accidentally copied into test environments, financial institutions are still required to enforce the same protection, governance and audit controls as they do in production.

This becomes harder to manage at scale. Imagine a bank with hundreds of internal systems which will also have hundreds of associated testing environments. If each environment contains customer data, the organisation creates a wider attack surface and a more complex governance challenge. The problem is further compounded if the testing is carried out by 3^rd party providers under contract by the bank.

Many institutions try to solve this by using synthetic data. While synthetic data can reduce direct exposure to raw customer information, it can also introduce a different problem: the data may not fully reflect the structure, behaviour, relationships, and edge cases found in production. This can limit the accuracy of testing, performance validation, and data model training.

So, how can financial entities provide testing teams with usable, realistic data while keeping sensitive information safe in non-production environments?

4 Practical Ways to Protect Customer Data Privacy in Non-Production Environments

Looking through the lens of how data gets built and shipped, Bluemetrix recommends carrying out these 4 steps to provide effective data privacy and security for any sensitive data that is handled in testing, model environments and DevOps pipelines:

1. Use Format-Preserving Tokenisation for Production-Faithful Test Data

Testing teams need data that behaves like production data. The closer test data remains to production behaviour and structure, the more useful it is for application testing, performance validation, and model training.

SecureToken Vaultless Tokenization, built on NIST-approved FF1 algorithm, uses a format-preserving approach to test data protection that improves both security and efficiency. Each sensitive value is replaced with reversible tokens that look like the original data type and length. For example, a 9-digit SSN becomes a 9-digit token. An IBAN stays IBAN-shaped. An email address becomes something that still looks like an email. The token preserves referential integrity that downstream systems in the test environment and the user never see structurally familiar data.

Production-faithful test data protected through vaultless tokenization

In other words, the result is a better equilibrium between compliance and usability. Developers get realistic, production-faithful data to test with, while raw customer records stay out of the test environment and comply with DORA.

2. Create a protected digital twin for internal IT testing

As explained above, large banks rarely have one test environment. They have dozens to hundreds of non-production environments in operation, each of which can host hundreds of systems where a copy of customer data can reside. Tokenizing production data once lets teams replace all of that with a single production-like digital twin that every team tests against before deployment.

Financial institution using tokenized production data for secure data testing

Consolidating to one protected environment pays off in several ways at the same time:

Teams test on data that behaves like production, so model training and performance testing stay accurate.
The effort of generating and maintaining synthetic or one-off test datasets disappears.
Fewer environments need securing, and fewer people have any route to raw customer data.

The last point is the one DORA cares about most, because it turns the separation principle in Article 8 into a reality rather than an aspiration. SecureToken is what makes the twin viable, since the tokenized data filling it does not expose recoverable customer data to unauthorised users.

3. Implement fine-grained access control for non-production data

Tokenisation reduces exposure, but strong access control is still essential. Non-production environments should not become open-access copies of production. SecureToken manages the core trade-off by enforcing user authorisation via two role-based policies and key control permissions. By doing so, we allow financial institutions to apply least-privilege access. Authorised users can recover the original value from the token, while users without that authorisation can only see the token. This asymmetry is intentional for 4 default reasons:

Reading tokens and reading plaintext are different permissions. Read access to a table lets users see the tokenized data, but recovering the real value of the data needs separate authorisation at the cryptographic layer. A table grant is not a detokenization grant.
Tokens are scoped to the environment. A token produced in production cannot be reversed in non-production, etc. The mapping is bound to the environment, which is another environmental separation enforced at the data layer.
Reading tokens does not require additional permission. Having read access to a table is sufficient to read the tokenized data, no additional authorization is required.
Tokens are deterministic within their boundary. The same input produces the same token every time; as long as it goes through the same configuration, it can be used as a join key.

This is important for DORA because non-production environments should not become open-access copies of production. Access to the operation of security activity should be governed by role, policy, and approved use case.

4. Maintain auditability and compliance evidence

Once the protective controls are in place, evidence is indispensable. Articles 8 and 16 set out a rationale that any testing development involving production data must be clearly identified, justified, time-limited, approved, and reported to the ICT risk management function. The obligations make a defensible record non-negotiable when it comes to the allegations of breaches.

Auditability can help financial institutions ease the burden of demonstrating DORA compliance. SecureToken records tokenization, detokenization, key operations, policy changes, and access events in an immutable audit trail before the result is returned to the caller. These events are then surfaced through a real-time monitoring dashboard (what we call the SecureToken audit portal). It provides security, operations, and governance teams with visibility into how protected data is used across non-production environments.

DORA Compliance Quickly Without Compromising on Privacy

Building best-in-class tokenization, fine-grained access controls, and key management in-house is a pricey and long-drawn process when trying to achieve DORA-compliance at enterprise scale. For most teams, the choice between buying a data protection solution or building your own deserves careful thought.

Instead of building a data protection solution yourself, you can use Bluemetrix SecureToken, a vaultless tokenization solution, to save you several years of engineering and security effort and start preserving customer data privacy in secure testing today.