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 practices can provide the realistic but safe data needed for resilience testing and the governance controls required under DORA’s ICT risk management rules.
What is DORA?
For compliance, financial organizations must perform regular resilience testing – and sometimes even advanced threat-led penetration testing (TLPT) – of any systems supporting critical or important functions.
At the same time, as part of its Information and Communication Technology (ICT) risk management and governance framework, DORA demands high standards for the availability, integrity, and confidentiality of data in every environment – not just production.
But what exactly is 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 cyber attack.
It also requires firms to show that, when incidents occur, they can contain the impact and return to normal operations quickly.
Why is test data management relevant to DORA?
Good test data management (TDM) practices will help 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 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.
Enhance your data security with an automated masking approach
What does DORA require?
DORA, the common name for Regulation (EU) 2022/2554, establishes the overall digital operational resilience requirements for EU financial entities 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.
DORA also includes strict requirements for ICT risk management and testing, with Articles 5–9 and 24–27 explaining data governance and resilience testing. The subsequent Commission Delegated Regulation (EU) 2024/1774 sets out the more detailed technical requirements for how organizations implement DORA’s ICT risk-management framework.
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). This is where test data management has the clearest and most direct role.
How does test data management (TDM) help achieve DORA compliance?
Test data management helps organizations meet DORA’s requirements for resilience testing (Articles 24-27) by supplying test datasets that mirror production data while containing only anonymized or synthetic data.
TDM also helps to protect personal and sensitive data, minimizing the overall surface area of risk (Articles 5–9).
Here’s a bit more on how it all works, in detail.
TDM delivers safe production-like data for test systems
This is through:
- Static data masking for irreversible replacement of sensitive data that preserves referential integrity and realistic data distributions.
- Synthetic data generation, using statistical/rule-based or AI-based techniques, to create test datasets that mimic the characteristics and distribution of production data, while containing no real records.
TDM minimizes the ‘attack surface area’ of test environments
This is through:
- Subsetting for minimal but representative datasets, excluding anything outside the scope of the test.
- Synthetic datasets for especially sensitive data domains, e.g., using generative AI models trained to match production’s statistical distributions.
- Automated provisioning and teardown, often using containerized or virtualized database clones, to ensure test environments are created, refreshed and removed in a controlled way. Meanwhile, role-based controls restrict access to only those who need it.
TDM gives auditors traceable evidence of data governance
This is through:
- Standardized masking policies stored as configuration and tracked in version control.
- An end-to-end audit trail with centralized logs showing who accessed which environment, evidence of how data was classified, masked, and delivered, and that controls were applied consistently across environments
TDM supports the full spectrum of DORA tests (Arts. 24–27)
This is through:
- Consistent, known datasets for resilience tests such as performance under surge, end-to-end process integrity tests, and rollback routines. AI-based generation is useful for specific test cases, such as resilience tests that simulate corrupt or unusual conditions.
- Rehearsing detection and response procedures safely before live penetration tests (for Financial entities in TLPT scope).
How TDM supports DORA article 24-27 testing requirements
“Financial entities shall, on a regular basis, conduct appropriate tests of their ICT systems, including tests on operational resilience.” — DORA, Article 24(1)
A TDM approach will enable financial institutions to build realistic yet safe test systems – critical in operational resilience testing, one of the most demanding parts of DORA. 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).
Automated and controlled preparation of test databases
What does good operational resilience testing look like with test data management?
Databases that hold core financial records, customer data, and transaction histories are among the most critical ICT systems in any financial organization, so 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? Effective TDM practices will support this and several other types of critical tests.
The critical tests that effective test data management can help with
| 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. While TDM doesn’t replace recovery testing, it does provide 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 – teams can rehearse TLPT scenarios in anonymized environments before engaging live systems, helping validate detection rules and response playbooks safely.
- Remediation testing – once vulnerabilities are identified, TDM environments allow repeatable retesting and validation of fixes using realistic, anonymized data.
How does TDM help manage ICT risk (DORA articles 5-9)?
“Financial entities shall ensure the maintenance of high standards of availability, authenticity, integrity, and confidentiality of data.” — DORA Article 5(2)
Beyond testing resilience, DORA requires strong governance and control over how data is handled across all ICT environments, including non-production.
You may also be interested in…
DORA in Practice: What Two Roundtables with Technical Leaders Revealed
Insights from senior technology, data and security leaders across banking, insurance, payments and trade finance on the operational gaps that DORA compliance planning often misses, and how to close them.
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 DORA 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, this means resilience testing must not create new risks. It must use realistic but safe data, achieved through TDM practices such as masking, subsetting, or synthetic data generation.
Standardized TDM practices are a critical element of a Financial Entity’s risk management framework. This is because they will:
- Prevent PII and sensitive data exposure during testing.
- Enforce policy-driven masking with audit trails showing consistent application of controls.
- Control access to test environments, ensuring only authorized personnel can access or refresh test datasets.
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. An auditable TDM approach is one that records when and how sensitive data is masked, moved, or used in testing. It also provides tangible evidence that ICT-risk and data protection controls are working as intended.
Mapping DORA requirements to test data management practices
Here’s a summary of how DORA requirements map to test data management (TDM) practices:
| 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; test data 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 |
In summary: how test data management helps meet DORA’s resilience testing requirements
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 (TDM) can provide the realistic but safe data needed to test effectively – and the governance, masking, and auditability to do so without increasing risk.
Because sensitive data remains protected, teams can test effectively without increasing risk or expanding the attack surface. For many financial entities, TDM 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 TDM practices will help financial institutions not only meet compliance goals but also strengthen the reliability and integrity of their data practices in the long term.
Move fast. Govern at scale.
FAQs: How test data management helps meet DORA's resilience testing requirements
1. What is DORA, and who does it apply to?
The Digital Operational Resilience Act (DORA) is an EU regulation that has applied since January 2025 to any organization working with or providing services to an EU-based financial entity. It requires firms to withstand, respond to, and recover from ICT disruptions.
2. Why is test data management important for DORA compliance?
DORA requires resilience testing that can’t run on empty databases, but it also prohibits using live customer data in test environments. Test data management provides realistic, production-like data through masking, subsetting, and synthetic generation — satisfying both testing and data protection requirements at once.
3. Which DORA articles relate most to test data management?
TDM most directly supports Articles 5–9 (ICT risk management and data governance) and Articles 24–27 (operational resilience testing, including threat-led penetration testing).
4. Does a test data breach count as a DORA incident?
Not necessarily. A test environment breach exposing personal data may not trigger DORA’s incident-reporting rules if it doesn’t disrupt services — but it would still qualify as a GDPR personal data breach and a failure of DORA’s data governance obligations under Articles 5 and 9.
5. What TDM techniques help meet DORA requirements?
Key techniques include static data masking (irreversible anonymization preserving referential integrity), synthetic data generation (statistically realistic but non-real datasets), subsetting (minimal representative data), and automated provisioning/teardown with audit trails.
This document contains proprietary information and is protected by copyright law.
Copyright © 2026 Red Gate Software Limited. All rights reserved
Load comments