The Digital Operational Resilience Act (DORA) has been in force since January 17, 2025. Financial entities across the European Union are now legally required to maintain robust ICT risk management frameworks, including comprehensive testing of their digital operational resilience.
One requirement creates a practical paradox: you must test your systems with realistic data and scenarios, but using production data in test environments introduces the very operational risks DORA is designed to prevent.
This guide examines how synthetic data resolves that paradox, enabling thorough resilience testing that satisfies DORA requirements without compromising production data integrity.
What DORA Requires for ICT Testing
DORA establishes a layered approach to ICT testing that applies to nearly all regulated financial entities in the EU.
Article 24: General Requirements for ICT Testing
Article 24 mandates that financial entities establish, maintain, and review a sound and comprehensive digital operational resilience testing program. This program must:
- Be proportionate to the size, business, and risk profiles of the entity
- Include a range of assessments, tests, methodologies, practices, and tools
- Follow a risk-based approach prioritizing critical ICT systems
- Be conducted by independent parties (internal or external) free from conflicts of interest
- Cover all ICT systems and applications supporting critical or important functions
Article 25: Threat-Led Penetration Testing (TLPT)
For significant financial entities, Article 25 imposes advanced testing requirements:
- Threat-led penetration testing (TLPT) must be carried out at least every three years
- Tests must cover critical or important functions delivered through ICT systems
- TLPT must be performed on live production systems where applicable
- Testing must be conducted by qualified and reputable external testers
- Results must be validated by the competent authority and reported accordingly
Article 26: ICT Third-Party Risk
Article 26 extends testing obligations to third-party ICT service providers, requiring financial entities to ensure that their critical ICT providers are subject to adequate testing as part of the overall resilience framework.
Who Must Comply
DORA applies to a broad range of financial entities defined in Article 2. The scope is significantly wider than many institutions initially assumed.
| Entity Type | DORA Applies | TLPT Required (Art. 25) |
|---|---|---|
| Credit institutions (banks) | Yes | Yes (significant entities) |
| Investment firms | Yes | Depends on classification |
| Insurance and reinsurance undertakings | Yes | Yes (significant entities) |
| Payment institutions | Yes | Depends on classification |
| Electronic money institutions | Yes | Depends on classification |
| Central securities depositories | Yes | Yes |
| Central counterparties | Yes | Yes |
| Trading venues | Yes | Yes |
| Crypto-asset service providers | Yes | Depends on classification |
| ICT third-party service providers (critical) | Yes (indirect) | Subject to oversight framework |
The Regulatory Technical Standards (RTS) under DORA further specify which entities must conduct TLPT and the frequency of testing cycles.
Why Production Data in Test Environments Is a DORA Risk
Here is the fundamental problem: DORA requires realistic testing, but exposing production data during testing creates operational risk.
Data Breach During Testing
If a penetration test or stress test exposes real customer data, the resulting breach is itself an ICT-related incident under DORA Article 17. The entity must:
- Classify the incident according to Article 18 criteria
- Report it to the competent authority under Article 19
- Potentially notify affected data subjects under GDPR Article 34
- Document the incident and its root cause in the ICT risk management framework
Using real data to test resilience creates a scenario where the test itself can trigger the incident it is designed to prevent.
Cross-Environment Contamination
Production data copied to test environments often receives weaker security controls. Access controls may be broader, logging may be less comprehensive, and infrastructure may not match production hardening. This creates attack surface that DORA’s ICT risk management requirements (Articles 5-15) are specifically designed to minimize.
Third-Party Exposure
Article 25 TLPT must involve external testers. Providing real customer data to external parties for penetration testing creates:
- GDPR data processing obligations requiring a Data Processing Agreement
- Potential cross-border transfer issues if the testing firm operates outside the EEA
- Additional third-party risk under DORA Article 26
- Reputational risk if the testing firm experiences its own security incident
Regulatory Contradiction
Using production data in testing can simultaneously violate:
- GDPR Article 5(1)(b) — purpose limitation (data collected for service delivery used for testing)
- GDPR Article 5(1)(f) — integrity and confidentiality (weaker controls in test environments)
- DORA Article 6 — ICT risk management (introducing unnecessary risk through data exposure)
- PCI DSS 4.0 Requirement 6.5.4 — prohibiting real PANs in test environments
Synthetic data eliminates all four concerns simultaneously.
Types of Test Scenarios That Need Synthetic Data
DORA testing requirements span multiple scenario types. Each benefits from synthetic data in different ways.
Stress Testing
Financial stress tests require large volumes of realistic customer profiles under extreme conditions. Synthetic data enables generation of:
- Portfolios with concentrated exposure to specific sectors or geographies
- Customer profiles with extreme but plausible wealth distributions
- Cross-border relationships that test multi-jurisdictional processing
Failover and Recovery Testing
Business continuity and disaster recovery tests require:
- Realistic data volumes that match production scale
- Diverse record types that exercise all code paths in recovery procedures
- Data that can be freely shared across recovery sites without transfer restrictions
Third-Party Risk Scenarios
Testing the resilience of third-party integrations requires:
- Shareable datasets that can be provided to ICT vendors without GDPR constraints
- Multi-format data that tests API integrations, batch processing, and real-time feeds
- Edge cases that stress third-party systems without exposing real customer patterns
Cross-Border and Multi-Jurisdiction Scenarios
Financial entities operating across EU Member States must test:
- Cross-border transaction processing under different regulatory regimes
- Multi-currency, multi-jurisdiction customer profiles
- Complex ownership structures spanning multiple legal systems
Threat-Led Penetration Testing
TLPT requires realistic data that external testers can interact with:
- Customer profiles that simulate real attack targets
- Transaction patterns that penetration testers can use to test detection systems
- Account structures that reflect production complexity
How Born Synthetic Enables DORA Compliance
Born Synthetic data is generated from mathematical models without any real data input. For DORA compliance, this architecture provides specific advantages.
Realistic Complexity Without Real Data Risk
Born Synthetic UHNWI profiles include 19 fields spanning personal demographics, financial metrics, wealth structures, and geographic indicators. The KYC/AML enhanced dataset extends this to 29 fields including risk scores, PEP indicators, source-of-wealth documentation, and jurisdiction-specific compliance markers.
This complexity enables testing scenarios that reflect production reality without involving actual customer information.
6 UHNWI Niches Mapped to DORA Scenarios
Each of the six geographic niches available in Born Synthetic datasets maps to specific DORA testing requirements:
| Niche | DORA Testing Scenario |
|---|---|
| Silicon Valley (Founders & VC) | Tech-sector concentration risk, USD-dominated portfolios, startup equity valuation stress |
| Old Money Europe (Dynasties & Private Banking) | Multi-generational wealth structures, EUR/GBP/CHF cross-currency, EU-internal cross-border testing |
| Middle East (Sovereign Families & Merchant Houses) | Sovereign wealth interfaces, Islamic finance structures, AED/SAR currency handling |
| LatAm Barons (Agribusiness & Infrastructure) | Emerging market risk, commodity-linked wealth, BRL/MXN volatility stress testing |
| Pacific Rim (Semiconductor & Shipping Dynasties) | APAC cross-border complexity, KRW/TWD/SGD processing, supply chain concentration |
| Swiss-Singapore (Offshore Wealth & Multi-Family Offices) | Multi-jurisdiction structures, CHF/SGD dual-hub scenarios, complex beneficial ownership chains |
Zero Governance Overhead
Because Born Synthetic data contains no personal data:
- No Data Processing Agreement required with external testers
- No GDPR cross-border transfer assessment needed
- No purpose limitation issues when reusing data across test scenarios
- No data subject notification obligations if a test environment is compromised
- No retention period constraints on test datasets
Certificate of Sovereign Origin for Audit Trail
Every Born Synthetic dataset includes a Certificate of Sovereign Origin documenting that no real data was used in generation. This certificate provides auditors and regulators with direct evidence that test data governance does not create production data risk.
Checklist: DORA Testing Data Readiness
Assess your current testing data posture against DORA requirements.
- [ ] Testing program established — Article 24(1): You have a documented digital operational resilience testing program covering all critical ICT systems
- [ ] Test data isolated from production — Articles 6, 24: Test environments do not contain copies of production customer data
- [ ] Test data volume matches production scale — Article 24(4): Tests are conducted at a scale representative of actual operational conditions
- [ ] Cross-border scenarios covered — Article 24(1): Testing includes multi-jurisdiction data processing scenarios relevant to your operational footprint
- [ ] Third-party testing data shareable — Articles 25, 26: Data provided to external testers and third-party providers does not create GDPR obligations
- [ ] Edge cases and stress scenarios included — Article 24(4): Test data includes extreme but plausible scenarios (concentrated exposure, unusual ownership structures)
- [ ] Test data provenance documented — Article 24(6): You can demonstrate to regulators how test data was sourced and that it does not compromise production data
- [ ] Incident response testable without real data exposure — Article 17: Incident simulation exercises use synthetic data to avoid creating actual incidents
- [ ] Recovery testing uses realistic volumes — Article 11: Business continuity and disaster recovery tests use data volumes comparable to production
- [ ] TLPT data ready for external testers — Article 25: If subject to TLPT, you have datasets that external testers can freely use without additional legal agreements
Timeline and Enforcement Expectations
DORA is already in force. There is no grace period.
| Period | Expectation |
|---|---|
| January 17, 2025 | DORA application date. All provisions are enforceable. |
| Q1-Q2 2025 | Competent authorities begin supervisory activities. Initial focus on ICT risk management frameworks. |
| 2025-2026 | First cycle of TLPT for significant entities. Testing methodologies and data governance under scrutiny. |
| 2026 onwards | Mature enforcement. Entities expected to demonstrate established testing programs with documented results. |
European Supervisory Authorities (ESAs) have published Regulatory Technical Standards that further specify testing methodologies, TLPT frameworks, and ICT third-party oversight expectations. Financial entities should review these RTS documents alongside the primary DORA text.
Get Started with Compliant Test Data
Evaluate Born Synthetic data quality for your DORA testing requirements. Download a free sample of 100 UHNWI profiles with full documentation, including the Certificate of Sovereign Origin.
For a broader assessment of your data governance posture, the GDPR Risk Assessment tool provides an instant evaluation covering training data, test data, and operational data risks.
Frequently Asked Questions
Does DORA apply to financial entities headquartered outside the EU?
DORA applies to EU-authorized financial entities and their ICT service providers. If you are a non-EU entity operating through an EU-authorized subsidiary or branch, DORA applies to those EU operations. ICT third-party service providers designated as critical under Article 31 are also subject to the oversight framework regardless of location.
Can synthetic data fully replace production data for TLPT?
Article 25 requires TLPT to be performed on live production systems. However, the data used to seed test scenarios, simulate customer interactions, and test detection systems does not need to be real customer data. Synthetic data can populate test accounts, generate simulated transactions, and create realistic attack scenarios without exposing actual customer information.
How does DORA interact with GDPR for testing data?
DORA and GDPR apply simultaneously. Using real customer data for testing requires GDPR compliance (legal basis, DPIA, data subject rights). DORA adds operational resilience requirements on top. Synthetic data avoids the GDPR layer entirely, simplifying the compliance stack for test environments.
What happens if a data breach occurs during DORA testing?
If real customer data is exposed during testing, the entity must classify the incident under Article 18, potentially report it under Article 19, and manage it through the ICT incident management process. If only synthetic data is exposed, there is no personal data breach, no GDPR notification obligation, and no DORA incident to report.
How many synthetic records do I need for DORA testing?
This depends on your production scale and testing scope. A principle of proportionality applies: test data should reflect the volume and complexity of production operations. Born Synthetic datasets are available in packages of 1,000, 10,000, and 100,000 records across six geographic niches, allowing you to match your testing scale to your operational profile.
Last updated: March 2026
Learn more about DORA synthetic test data and how Born Synthetic data addresses this in our glossary and comparison guides.
