The essentials in 30 seconds
- DORA does not name leak testing, but it meets two of its requirements: checking that protection measures work and regularly testing ICT systems.
- Its most natural home: the scenario-based tests of Article 25.
- It complements audits and TLPT between two exercises; it does not replace them.
“Our DORA testing programme has its annual pentest, and perhaps a TLPT soon. Where do we put data leak testing?” We often hear this from risk managers at financial entities. And it is a fair question.
The DORA Regulation (EU) 2022/2554 requires financial entities to have an ICT risk management framework and a digital operational resilience testing programme, applicable since 17 January 2025. Data leak testing does not appear in it under that name. Yet it meets two of its requirements: checking that your protection measures work, and regularly testing your ICT tools and systems. Here is our answer: it complements the planned tests, without replacing either the audit or the TLPT.
DORA resilience testing: what the regulation requires
DORA does not talk to you about tools. The regulation wants to know whether you can withstand the shock, and whether you know how to recover. Two of its building blocks nevertheless concern data leakage.
The ICT risk management framework (Chapter II)
Articles 5 to 16 describe the framework the entity must put in place. Article 9 (protection and prevention) covers, among other things, the confidentiality and integrity of data, including data in transit. Article 10 deals with detecting anomalous activities. In plain terms, the regulator expects measures that prevent unauthorised data exfiltration, and mechanisms able to spot it when prevention fails.
This is often underestimated: your framework must also be documented, then reviewed and improved based on lessons learned (Article 13). A DLP rule that nobody has ever put to the test will be hard to defend in that cycle.
The testing programme (Chapter IV)
Article 24 requires a digital operational resilience testing programme that is proportionate and risk-based, with tests at least yearly on the systems and applications supporting critical or important functions. Article 25 lists the types of tests expected: vulnerability assessments, network security assessments, gap analyses, scenario-based tests, performance tests and penetration tests, among others. Article 26 governs threat-led penetration testing (TLPT), reserved for entities designated by the authorities, at least every three years.
It is in Article 25, under “scenario-based tests”, that data leak testing finds its most natural place. DORA does not apply in the United Kingdom, but UK firms have a close equivalent: under the FCA and PRA operational resilience rules (FCA PS21/3, PRA PS6/21), in force since 31 March 2022, firms in scope had until 31 March 2025 at the latest to complete the mapping and scenario testing that show they can remain within impact tolerances for each important business service in a severe but plausible disruption. A leak scenario fits there too.
Where exfiltration testing fits in this framework
A data exfiltration test replays, in a controlled way, the techniques an attacker or an insider would use to get information out, then observes what your controls block, detect or let through. With Enforcis, this scenario follows MITRE ATT&CK and chains discovery, collection, staging, automation and then exfiltration.
| DORA requirement | Question asked | What an exfiltration test brings |
|---|---|---|
| Art. 9: protection and prevention | Do your measures prevent data from leaving? | Evidence observed channel by channel, instead of a rule assumed to be active |
| Art. 10: detection | Does the SOC see an exfiltration attempt? | Measurement of what raises an alert, and how quickly |
| Art. 13: learning and evolving | Are your measures improving? | Posture compared over time, before and after fixes |
| Art. 24 and 25: testing programme | Do you test regularly, based on risk? | Attack scenarios replayed at a defined frequency on critical systems |
A concrete scenario: the asset manager and its portfolio extract
Picture a 120-person asset management firm, equipped with email DLP, a web proxy and a CASB. From the console, client positions cannot leave.
The security team replays 4 scenarios with synthetic data that mimics these position files: sending to Gmail, uploading to a personal Dropbox, pasting into an AI assistant such as Copilot, and exiting through an HTTPS stream. In practice, the result is often this: email blocks, the web partly blocks, and one channel gets through without a single alert. Nobody had noticed: that is the nature of DLP false negatives.
This finding, dated and documented, then goes into your DORA testing file and your remediation plan. Upcoming versions will bring multi-level reporting (leadership, CISO, operations), with MITRE ATT&CK mappings and, where the correspondence is established, MITRE D3FEND, as well as SIEM integrations.
Next step
Which channel gets through without an alert in your organisation?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
Checklist for adding leak testing to your DORA programme
- Start from critical or important functions. Identify the data that supports them and the systems that handle it.
- Map the exfiltration channels. Workstations, email, web, OneDrive or Google Drive, Teams, SaaS, generative AI assistants.
- Define realistic attack scenarios. Careless insider, malicious insider, compromised workstation. Stay on the defensive side: the goal is to validate your controls.
- Use decoys only. Testing in production with real data creates the very risk you are trying to measure.
- Measure blocking and detection separately. A channel that is not blocked but is quickly detected is not as serious as an invisible one.
- Prioritise fixes. Rank them by impact and effort, rather than in the order of the report.
- Retest after every fix and every major change. A migration to Windows 11 or an agent update can undo a rule.
- Keep the evidence. Date, scope, scenario, result, action taken. This is what your national competent authority will ask you for under DORA, applying common standards drafted by the European Supervisory Authorities (EBA, EIOPA and ESMA). UK firms in scope must already record the same kind of evidence in their operational resilience self-assessment for the FCA and the PRA.
One-off or continuous: the trade-off for a financial entity
DORA requires at least one test a year on the systems supporting critical or important functions. That is a minimum. Between two annual tests, your environment changes dozens of times: new SaaS applications, modified rules, migrated workstations. And a breach costs an average of $4.99 million worldwide, according to the IBM Cost of a Data Breach 2026 study (Ponemon, 602 organisations).
Diagram · three testing rhythms
Pentests and TLPT keep all their value: they test a complete attack chain, with the imagination of experienced humans. Continuous exfiltration testing, for its part, checks a specific control, replayed regularly between two exercises. Our comparison continuous validation, pentest or red team details this split. If another entity in your group falls under NIS2, the same results can feed both files.
FAQ
Does DORA explicitly require data leak testing?
No. The text does not name this test. It requires a risk-based testing programme, including scenario-based tests, and measures to protect data confidentiality. Exfiltration testing is one way to demonstrate the effectiveness of these measures.
Can exfiltration testing replace TLPT?
No. TLPT, provided for in Article 26, follows a specific framework, with testers meeting the requirements of Article 27 and validation by the authority. Exfiltration testing complements it between two exercises.
Are small financial entities concerned?
Yes, proportionately. Some entities fall under the simplified ICT risk management framework of Article 16. The principle of regular, proportionate testing remains; check your exact regime with your authority or your adviser.
Does the testing provider need to appear in the register of information?
A provider that runs these tests for you becomes an ICT third-party service provider within the meaning of DORA (Chapter V). Work with your compliance function on how to include it in your register of information, provided for in Article 28, and in your third-party risk monitoring.