Test Data Management and DORA Compliance in Financial Organizations

DORA requires financial institutions to run tests that prove their systems can withstand operational disruption, without exposing sensitive data. This article explains how Test Data Management (TDM) provides the realistic but safe data needed for resilience testing and the governance controls required under DORA’s ICT risk management rules.

Why DORA?

“The purpose of [DORA] is to strengthen the digital operational resilience of the financial sector.”Recital 1, DORA

The Digital Operational Resilience Act (DORA) has been in force across the EU since January 2025 and applies to any organization that works with, or provides services to, an EU-based Financial Entity (FE).

DORA is designed to strengthen the ability of financial institutions such as banks, insurers, and investment firms to withstand operational disruption, whether caused by technology failures, data corruption, human error, or a cyberattack. It also requires firms to show that, when incidents occur, they can contain the impact and return to normal operations quickly.

For compliance, financial organizations must perform regular resilience testing of any systems supporting critical or important functions, and in some cases, advanced threat-led penetration testing (TLPT). At the same time, as part of its ICT risk management and governance framework, DORA demands high standards for the availability, integrity, and confidentiality of data in every environment, not just production

Why Test Data Management?

A modern Test Data Management (TDM) solution helps organizations satisfy both sides of DORA’s mandate. Resilience tests can’t run on empty databases, but they also can’t use live customer data. To comply with both DORA and GDPR, testing must use data that behaves like production data, but without exposing personal or sensitive information.

With techniques such as static data masking, synthetic data generation, and subsetting, a TDM system allows teams to run resilience tests with data that is realistic enough for meaningful results, but without expanding the attack surface or breaching DORA’s data governance requirements.

What DORA Requires (Exec Summary)

DORA sets out a broad set of obligations across more than 60 articles. Larger organizations are subject to more stringent obligations, penalties for non-compliance can reach 2% of annual turnover, and accountability can extend to individuals as well as organizations.

To determine where TDM fits with DORA, it helps to understand which of the core parts of DORA are the ones that matter most for IT and data teams:

  • Governance and ICT Risk Management (Arts. 5–9):
    Establish a framework for governance, accountability, and security controls that protect the confidentiality, integrity, and availability of data across all ICT environments, including test systems.
  • Incident Reporting (Arts. 17–23):
    Detect and report major ICT-related incidents promptly, with the evidence needed for regulatory assessment.
  • Operational Resilience Testing (Arts. 24–27):
    Regularly test critical business services under realistic conditions. Some financial entities must also perform advanced threat-led penetration testing (TLPT).
  • ICT Third-Party Risk (Arts. 28–44):
    Ensure oversight, contract controls, and monitoring of any external ICT providers supporting critical functions.
  • Information Sharing (Art. 45):
    Voluntarily exchange cyber-threat information to improve sector-wide detection and response.

This article focuses specifically on the testing and data governance requirements (Arts. 5–9 and 24–27), where Test Data Management has the clearest and most direct role.

The Practical Ways TDM Helps with DORA Compliance

By supplying test datasets that mirror production data, but contain only anonymized or synthetic data, TDM helps organizations meet DORA’s requirements for resilience testing (Articles 24–27), while protecting personal and sensitive data and minimizing the overall surface area of risk (Articles 5–9).

TDM supports DORA compliance in the following ways.

1) Delivers production-like, but safe data for test systems

  • Static data masking for irreversible replacement of sensitive data that preserves referential integrity and realistic data distributions.
  • Synthetic datasets to generate edge cases or specific test cases that simulate corrupt or unusual conditions, without touching PII.

2) Minimizes the ‘attack surface area’ of test environments

  • Subsetting for minimal but representative datasets, excluding anything outside the scope of the test.
  • Automated provisioning and teardown to ensure test environments are created and refreshed in a controlled way and removed when no longer needed

3) Gives auditors traceable evidence of data governance

  • Standardized masking policies stored as configuration and tracked in version control.
  • An end-to-end audit trail showing how data was classified, masked, and delivered and demonstrating that controls were applied consistently across environments

4) Supports the full spectrum of DORA tests (Arts. 24–27)

  • Consistent, known datasets for resilience tests, such as performance under surge, end-to-end process integrity tests, and rollback routines
  • Rehearse detection and response procedures safely before live penetration tests (for Financial entities in TLPT scope)

Automated and controlled test data preparation

A TDM solution such as Redgate Test Data Manager automates all these processes. It applies consistent data masking and subsetting policies, while maintaining an audit trail, to show that masking and data-handling controls are applied correctly.

How TDM supports DORA’s testing requirements (articles 24-27)

“Financial entities shall, on a regular basis, conduct appropriate tests of their ICT systems, including tests on operational resilience.” — DORA, Article 24(1)

By enabling financial institutions to build realistic yet safe test systems, a TDM solution becomes critical in one of the most demanding parts of DORA: operational resilience testing. It allows teams to create controlled test environments that mimic production workloads, dependencies, and failure scenarios.

These safe test systems can also be used in preliminary checks of certain operational recovery procedures before live-system testing, which is useful for organizations required to perform threat-led penetration tests (TLPT).

What good operational resilience testing looks like with TDM

Databases that hold core financial records, customer data, and transaction histories are among the most critical ICT systems in any financial organization, and testing their resilience safely is a regulatory priority.

With safe and realistic test data in place, teams can perform many of the resilience tests identified in Article 25(1) that are designed to demonstrate that databases, and the critical services they support, can continue to function in the face of software faults, deployment mistakes that affect data, or abnormal transaction loads.

Imagine a deployment to update a risk-calculation process that accidentally deletes or alters critical data, resulting in incorrect results. Can the problem be detected immediately, and can the deployment be rolled back safely without affecting live systems? A TDM solution like Redgate Test Data Manager can support this and several other types of critical tests:

Type of test Example Test data requirements
Scenario-based testing Simulate a failed deployment to validate rollback process. Realistic datasets including unpredictable values to reflect incident conditions.
Performance testing Validate that a card-processing platform handles transaction surges. Data volumes and distributions that mirror live production traffic
End-to-end testing Verify that trade capture, risk calculation, and settlement workflows operate correctly after database failover Realistic business datasets that capture a workflow and where values remain consistent for sign-off and validation.

Support for other DORA testing requirements

In some cases, the same safe test environments can also be used for controlled rehearsals of operational processes that interact with data systems. For example, teams may validate that deployment rollbacks, failover routines, or certain parts of backup-and-restore workflows behave as expected, without touching live systems or exposing customer data. TDM doesn’t replace recovery testing, but it provides a safe environment for practicing the data-related steps of these procedures.

TDM also supports the advanced testing activities required under Article 26, particularly for larger financial entities:

  • Threat-led penetration testing (Art. 26(6)) – teams can rehearse TLPT scenarios in anonymized environments before engaging live systems, helping validate detection rules and response playbooks safely.
  • Remediation testing (Art. 26(8)) – once vulnerabilities are identified, TDM environments allow repeatable retesting and validation of fixes using realistic, anonymized data.

How TDM helps manage ICT Risk (articles 5-9)

“Financial entities shall ensure the maintenance of high standards of availability, authenticity, integrity, and confidentiality of data.” — DORA Article 5(9)

Beyond testing resilience, DORA requires strong governance and control over how data is handled across all ICT environments, including non-production.

Data protection during testing

Resilience testing can expose customer data if test environments aren’t properly controlled. A test data breach that leaks personal data but doesn’t disrupt services may not trigger DORA’s incident-reporting rules (Articles 17–23), but would still qualify as a personal data breach under GDPR and a failure of ICT governance under Arts. 5 and 9.

GDPR protects personal data; DORA protects operational continuity. They meet in Article 9, which requires firms to maintain the confidentiality, integrity, and availability of data across all ICT environments, including test systems. In practice, it means resilience testing must not create new risks. It must use realistic but safe data, achieved through masking or synthetic datasets delivered by a TDM solution.

A TDM solution like Redgate Test Data Manager is a critical element of a Financial Entity’s risk management framework, because it will:

  • Prevent PII and sensitive data exposure during testing.
  • Govern test environments, ensuring only authorized personnel can access or refresh test datasets.
  • Maintain confidentiality and integrity of all replicated or synthetic datasets.
  • Enforce policy-driven masking with audit trails showing consistent application of controls.

Auditability and traceability

While DORA doesn’t require financial entities to maintain the same type of detailed records of data processing activities mandated by GDPR, it does require comprehensive documentation of ICT risks, incidents, and resilience testing results. These records must demonstrate that systems and their data are governed, protected, and recoverable under defined controls.

Articles 5 and 9 place responsibility on financial entities to demonstrate this control. A TDM platform’s auditability, its ability to record when and how sensitive data is masked, moved, or used in testing, provides tangible evidence that ICT-risk and data-protection controls are working as intended.

Mapping DORA Requirements to TDM Capabilities

DORA expectation What auditors look for How TDM helps
Data confidentiality, integrity, and availability in all environments (Arts. 5 & 9) Policies, controls, and evidence that non-prod systems don’t expose personal/sensitive data Masking/synthetic data by policy; preserved referential integrity; audit logs
Annual testing of critical/important functions (Art. 24) Risk-based testing program; reproducible test conditions Deterministic, versioned test datasets; subsetting per test case; pipeline integration
Advanced TLPT every three years (where scoped) (Art. 26) TLPT scope, governance, remediation tests & evidence Safe pre-production rehearsals using masked/synthetic data
Board accountability & documentation Clear ownership; traceable artifacts supporting assertions to supervisors End-to-end logs from source → masking → provisioning → use → cleanup

Conclusions

DORA doesn’t dictate how financial institutions should test their resilience, but it does make them responsible for proving that their systems and data are resilient to stress, recoverable quickly in the event of failure or attack, and well governed and protected.

Test Data Management can provide the realistic but safe data needed to test effectively, and the governance, masking, and auditability to do so without increasing risk. Teams can test effectively without increasing risk or expanding the attack surface, because sensitive data remains protected. For many financial entities, Test Data Management solution is not just a testing convenience but an essential part of their ICT risk and compliance framework.

As DORA reshapes expectations around digital resilience, implementing a TDM solution helps financial institutions not only meet compliance goals but also strengthen the reliability and integrity of their data practices in the long term.

Tools in this post

Redgate Test Data Manager

Reliable and secure test data provisioning

Find out more