DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), is the EU regulation that requires financial entities to withstand, respond to and recover from ICT disruptions and cyber threats. It has applied since 17 January 2025 and, unlike a directive, it is directly binding in every member state without national transposition.
Key facts:
- DORA covers roughly the entire EU financial sector: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and more, plus critical ICT third-party providers serving them. Sector-specific guidance is issued by the European Supervisory Authorities: EBA, ESMA and EIOPA.
- It is built on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management and information sharing.
- Management bodies carry explicit responsibility for ICT risk. Proportionality applies: obligations scale with entity size and risk profile.
- DORA acts as lex specialis for financial entities: where it overlaps with NIS2, DORA's rules generally take precedence.
The five pillars
| Pillar | What it requires | Where email sits |
|---|---|---|
| ICT risk management | A documented framework covering identification, protection, detection, response and recovery | Email and identity are in-scope ICT assets |
| ICT-related incident management | Classify, log and report major incidents to the regulator within fixed deadlines | A successful phishing or BEC event can be a reportable incident |
| Digital operational resilience testing | Regular testing, including threat-led penetration testing for the largest firms | Phishing resistance is tested, not assumed |
| ICT third-party risk | Contractual and oversight requirements for providers, plus a register of arrangements | Your email security vendor is a third-party ICT provider under DORA |
| Information sharing | Voluntary exchange of threat intelligence between financial entities | Cross-customer signal on campaigns and lookalike domains |
Why email matters under DORA
Most operational disruption in finance does not start with exotic malware; it starts with a message. Phishing, business email compromise and OAuth consent fraud are the entry points regulators see repeatedly. DORA's detection and monitoring requirements (anomalous activity, prompt incident identification) therefore reach the mailbox directly, and its third-party pillar reaches the SaaS and AI tools connected to it, including the unsanctioned ones: shadow IT with OAuth access to a financial entity's mail and files is exactly the kind of unmanaged ICT dependency DORA expects entities to know about.
Where Sentaro fits, honestly
No product delivers DORA compliance. The regulation demands governance, documentation, testing and contracts far beyond technology. What Sentaro contributes to the framework:
- Detect: AI-native blocking and flagging of phishing, BEC and consent phishing in Google Workspace and Microsoft 365, the attack surface where most incidents begin.
- Part of the incident reporting chain: for email-borne incidents, detection is what triggers classification, and Sentaro supplies the who/what/when/scope that initial, intermediate and final reports require, so the reporting clocks (verify exact current timelines against the applicable technical standards) start with facts, not archaeology.
- Third-party visibility: every app and AI service holding OAuth access to mailboxes and files, feeding the ICT register and concentration-risk picture with what is actually connected, not just what procurement recorded.
- Control support: continuous monitoring instead of point-in-time audits, which is the operating mode DORA assumes.
What remains yours: the risk framework, incident process and reporting, testing program, contracts and registers, and governance. Sentaro informs and monitors; your organization decides and documents.
This page is general guidance, not legal advice. Consult qualified counsel and your supervisor's guidance for your obligations.