Compliance crosswalk · DORA
DORA (EU Regulation 2022/2554) - email + domain controls, mapped to Wiredepth
Framework version: In force since 17 January 2025; full application across all EU financial entities
Who this is for.Financial entities operating in the EU: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers (under MiCA), central counterparties, trading venues, central securities depositories, fund managers (UCITS, AIFMD), insurance + reinsurance undertakings, and crowdfunding service providers. Plus ICT third-party providers designated as "critical" under DORA - they face direct oversight by the European Supervisory Authorities.
Where email + domain controls fit. DORA covers ICT risk management (Articles 5-16), ICT incident management (17-23), digital operational resilience testing (24-27), and ICT third-party risk (28-44). Email-auth + domain-posture controls show up across all four pillars - most heavily under ICT risk management (sensitive data protection, identification of cyber threats) and ICT third-party risk (authorised email-sending vendors).
Why now. DORA came into force January 2025, but EU financial supervisors (ESMA, EBA, EIOPA) began full enforcement cycles in 2025 H2. Penalties for non-compliance can reach 1% of average daily worldwide turnover for critical ICT providers + similar scales for financial entities. EU-domiciled or EU-operating financial entities are in active gap-remediation right now.
Clause-by-clause mapping
Each row maps a specific DORArequirement to the Wiredepth surface that addresses it. The clause ids are the framework's own naming - verify them against the official text. We use precise language: "addresses" (the tool directly satisfies the control), "supports" (the tool contributes evidence the auditor will need), and "evidence for" (the artifact is part of the attestation package).
| Clause | Requirement | Wiredepth response |
|---|---|---|
Art. 5 (Governance + organisation) Reporting | The management body of a financial entity is responsible for the ICT risk management framework. Includes regular reporting + audit-committee oversight of ICT risk posture. | Email-auth scorecard PDF is the management-board-readable artifact for the ICT risk posture summary. Timestamped + watermarked for governance records. |
Art. 8 (Identification) Inventory | Identify, classify + document ICT-supported business functions, information assets + ICT assets. Includes the domains + email-sending services supporting customer operations. | Vendor consolidation audit inventories every third party authorized in SPF / DKIM / MX / DMARC. Subdomain inventory + change-history evidence the broader ICT-asset register. |
Art. 9 (Protection + prevention) Authentication | Implement ICT security policies, procedures, protocols + tools that maintain a high level of digital operational resilience. Email authentication is identified by EBA as a core protective control. | DMARC + SPF + DKIM analyzer scores authentication posture. MTA-STS check validates transport encryption. Spoofability check provides the composite verdict for the policy review. |
Art. 10 (Detection) Monitoring | Detect anomalous activities, including ICT network performance issues + ICT-related incidents. Establish prompt-alert mechanisms for breach detection. | Continuous monitoring of DMARC / SPF / DKIM / MTA-STS posture + brand-watchlist + leak-site appearance. Alert-on-regression history is the DORA detection-mechanism evidence. |
Art. 17-23 (ICT incident management + reporting) Reporting | Classify ICT-related incidents based on criteria including their priority + severity. Major incidents must be reported to the competent authority within 4 hours of classification (provisional) and final report within 1 month. | Continuous monitoring + change-history snapshots provide the timeline-reconstruction evidence for incident classification + reporting. Wire-fraud monitor (Wiredepth Prove) covers the customer-impersonation incident vector specifically. |
Art. 24-27 (Digital operational resilience testing) Monitoring | Conduct testing of ICT systems at least annually. Larger entities must perform threat-led penetration testing every 3 years. Tests must cover all critical ICT systems supporting critical or important functions. | Continuous-monitoring posture-change records provide the always-on testing evidence for the email/domain-controls subset of "critical ICT systems". Pairs with annual external pentests for the broader scope. |
Art. 28-30 (ICT third-party risk) Inventory | Maintain a register of all contractual arrangements on the use of ICT services provided by ICT third-party service providers, kept up-to-date and at the disposal of competent authorities. Email-sending vendors are explicit examples. | Vendor consolidation audit produces the DNS-attested inventory of email-sending vendor relationships. De-authorization guides cover the exit-arrangement side (Article 28(8) exit strategy requirement). |
Art. 33 (Pre-contractual assessment) Inventory | Before entering into a contractual arrangement with an ICT third-party service provider, assess whether the contractual arrangement covers an ICT service supporting a critical or important function. | Vendor scoring (batch) for the diligence step. Pairs with the customer's broader vendor-onboarding process. |
What auditors actually look at
From early DORA enforcement patterns (2025) + EBA/ESMA guidance, here's what supervisors are testing on:
- ICT third-party register completeness. Article 28(3) - your register must be up-to-date AND at the disposal of competent authorities. Vendors in your DNS that aren't in your register = direct finding. Conversely, register entries with no DNS footprint = stale data.
- Exit strategies for material ICT providers (Article 28(8)). Often missing - DORA explicitly requires documented exit arrangements. Our de-authorization guides fill the technical-execution half.
- Major incident reporting timeline. 4-hour provisional notification + 72-hour intermediate + 1-month final. An audited detection + escalation workflow shortens time-to-classification.
- Continuous-monitoring evidence. Article 10 detection-mechanism requirement. Posture- regression alert history (DMARC, MTA-STS, vendor changes) is direct evidence.
- Threat-led pentest scope.Article 26 expects critical-function scoping. Email-as-critical- function appears in most financial entities' scope + needs documented testing - continuous monitoring provides the baseline tests can measure against.
- Subcontracting awareness. Article 30 extends third-party risk to sub-outsourcing. SendGrid uses AWS, Mailchimp uses AWS, etc. - the supply chain extends. Our vendor inventory makes the first-level relationships visible.
Generate a DORA-tagged evidence pack (Wiredepth Prove)
Prove subscribers can generate a ZIP of all five workpapers + a DORA README in one click. Single domain, single click, ready to file in your audit binder. See pricing at /pricing#prove ($499/mo standalone, bundled in Enterprise).
Other compliance crosswalks
Disclaimer. This crosswalk is provided for informational purposes. It is not legal advice, audit guidance, or a substitute for engagement with a qualified assessor (QSA for PCI, accountant or QSA for SOC 2, lawyer for HIPAA / NIS2 / SEC). Framework clause ids and language may have been updated since publication; verify against the official text. Wiredepth does not guarantee compliance based on the use of any tool or page on this site.