DORA · Banks and insurers

DORA requirements for SAP test data at banks and insurers

Since January 2025, DORA's rules on ICT risk expect EU financial entities to keep only anonymised, pseudonymised or randomised production data in non-production environments. Real production data needs approval, a time limit and reporting. Synthesized masks SAP data before it reaches test, so that exception stays rare.

Not legal advice: check the requirement with your compliance team. Auf Deutsch lesen

Refresh record · QA client 100Example
Scope
Company codes 1000 and 2000, last 18 months
Subset
Masking rules applied
Customers, vendors, employees and Z-tables
Applied
Connected systems
CRM test and payments test
Same values
Run by
Test data team · scheduled refresh
Recorded
Real production data in this client: none
Masked by default
Evidence for ICT risk
Results measured in live deployments outside SAP
30%
faster testing and development cycles
Global bank · self-service test data
20bn
rows masked and subsetted in hours
Digital health platform · replaced a legacy TDM tool · Read the case study
28M
production rows protected, 100% referential integrity
Global specialty insurer · 40+ core applications · Read the case study
200×
more test data, from 100K to 20M entries
Telecom operator · masking and synthetic generation

On SAP, we measure results on your own data in a 10-day validation.

What it says

Production data in test becomes the exception, not the rule

17 Jan 2025
The RTS on ICT risk management applies, alongside DORA
Art. 16(8)
The paragraph on data in non-production environments
3 conditions
For any exception: limited in time, approved and reported
Commission Delegated Regulation (EU) 2024/1774 · Article 16(8)

What non-production environments may hold

Non-production environments hold only anonymised, pseudonymised or randomised production data.

Production data is allowed only for specific testing occasions.

The integrity and confidentiality of data in non-production environments are protected.

Paraphrased from the regulation. Read the text for your own obligations.

Read the source: Commission Delegated Regulation (EU) 2024/1774 on EUR-Lex

When real production data is allowed

For a limited period
The exception ends when the testing occasion does.
Approved by the relevant function
Someone signs off before real data reaches test.
Reported to ICT risk management
The ICT risk management function knows about every exception.

In an SAP landscape

Where SAP test systems fall short today

01
System copiesRefreshing QA from production copies customer, vendor and employee data as it is.
02
Custom tablesMasking scripts often cover standard tables such as KNA1 and miss the Z-tables your team added.
03
Connected systemsThe CRM, payments and data warehouse test systems hold their own unmasked copies.
04
EvidenceAuditors ask what was masked, when and by which rule, and the answers sit in scripts and emails.

Platform

Mask SAP data before it reaches test

Find and mask personal data

A scan flags personal data in SAP tables and the systems around them, then masking replaces it with realistic values, the same way everywhere.

  • Sensitive columns found by the scan, including Z-tables
  • Same replacement values in SAP and the CRM
  • A record of every run
Automated masking with a sensitive data scan report

Copy only what your tests need

Choose company codes, date ranges or business objects, and the subset keeps every related record so tests still run end to end.

  • Business keys and date ranges in scope
  • Document chains kept whole
  • Smaller, faster test systems
Automated subsetting with system statistics

Create the data production doesn't have

Generate customers, orders and edge cases for scenarios production doesn't contain yet, configured as code or in the UI.

  • Edge cases on request
  • Configuration as YAML or in the UI
  • Runs from the API, CLI or a pipeline
Automated generation configured as YAML

How Synthesized helps

Masked by default, with the records to show it

SAP productionS/4HANA, real personal data
CRM and paymentsReal customer data
SynthesizedFinds, subsets and masks, inside your environment
QA and pre-productionMasked data only
CRM test systemSame masked values
Refresh recordScope, rules, time, who ran it
ICT risk functionEvidence on request
Production
Non-production
masked
Exception only: approved, time-limited and reported
Masked refreshes are the default route into test systems. Real production data takes the exception route.
What the rule expectsHow Synthesized supports it
Only anonymised, pseudonymised or randomised data in non-productionSAP data is masked, or replaced with generated values, before it's written to the test system
Exceptions approved, time-limited and reportedFewer exceptions to manage, because masked refreshes become the default
Integrity and confidentiality in non-productionThe same replacement values across SAP and connected systems, so integration tests still pass
Showing what was doneA record of every refresh: scope, rules applied, time and who ran it

Who it applies to

Most EU financial entities running SAP

DORA covers banks, investment firms, insurers and reinsurers, payment and e-money institutions and other financial entities. If your finance, HR or customer processes run on SAP, the SAP test systems count.

Credit institutionsBanksCustomer, vendor and employee data in S/4HANA finance and in banking processes.
Insurance and reinsuranceInsurersPolicyholder and claims data that reaches SAP finance and collections.
Delivery partnersOffshore testingTest teams outside the EU need masked data even more.Offshore testing

Synthesized for SAP: key facts

SAP systems
S/4HANA and ECC, including RISE with SAP (through OData); SAP HANA 2.0+ directly
Deployment
Inside your boundary: a server, Kubernetes or OpenShift, on-premise or private cloud, air-gap capable
Integrations
Tricentis Tosca, UiPath, API and CLI
Where to buy
SAP Store, AWS Marketplace and Google Cloud Marketplace, or direct

We've got you covered

Questions about DORA and test data

What does DORA require for test environments?

Under the RTS on ICT risk management, non-production environments should hold only anonymised, pseudonymised or randomised production data. Real production data is the exception: for specific testing occasions, time-limited, approved and reported to the ICT risk management function.

Is this the same as DORA resilience testing?

No. DORA's digital operational resilience testing, including threat-led penetration testing (TLPT), checks how your ICT systems hold up against incidents and attacks. This page is about the data inside non-production environments, which the RTS on ICT risk management covers.

Is pseudonymised data enough?

The rule allows anonymised, pseudonymised or randomised data. Under GDPR, pseudonymised data is still personal data, so GDPR duties still apply to it.

Does it cover SAP cloud products such as SuccessFactors?

The requirement covers your non-production environments wherever they run. See SuccessFactors anonymization.

Can you help with the audit?

We provide the refresh records and masking rules. Your compliance team decides what evidence the supervisor needs.

Next step

See how many test systems hold real data

A scan of one SAP test system shows where production data sits today, in standard and custom tables.

Runs in your environmentNothing installed in SAPRead-only access to SAPSecurity and deployment
Updated October 2026

SAP, S/4HANA, SAP HANA, SuccessFactors, Ariba, Concur and other SAP products and services mentioned herein, as well as their respective logos, are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.