Digital Operational Resilience Act for financial entities.
See your DORA readiness in 60 seconds. Free, no signup.
DORA (Regulation (EU) 2022/2554) is in force since 17 January 2025. It imposes uniform ICT risk management, incident classification and reporting, resilience testing, and third-party risk management obligations on virtually every financial entity in the EU.
Banks, payment institutions, e-money institutions, insurers, asset managers, crypto-asset service providers, CCPs, trading venues and their critical ICT third-party service providers.
Periodic penalty payments + competent authority enforcement; ICT third parties can be designated 'critical' with direct EU oversight.
Each row links a DORA clause to the external check we perform and the evidence it produces. Mappings are reviewed by our compliance team and updated when standards change.
| DORA clause | What it requires | How we evidence it |
|---|---|---|
REP-1 Art. 6 ICT risk management framework | A sound, comprehensive and well-documented ICT risk management framework using up-to-date threat intelligence. | Reputation & threat intelligence We cross-check the domain and its IPs against VirusTotal, Shodan, Spamhaus, URLhaus and Google Safe Browsing. |
DNS-1 Art. 9 Protection and prevention | ICT systems must be designed, procured and maintained to minimise the impact of ICT risk, including network controls. | DNS hygiene & DNSSEC We resolve A, AAAA, MX, NS, CAA and DNSSEC records and flag anomalies, dangling records and missing controls. |
BREACH-1 Art. 10 Detection | Mechanisms to promptly detect anomalous activities, including ICT-related incidents and credential exposure. | Credential exposure monitoring We query Have I Been Pwned for breaches involving the monitored domain and surface affected accounts. |
WEB-1 Art. 9(2) Security of network and information systems | Implement policies, procedures, protocols and tools that provide a high level of resilience for web-facing systems. | Secure HTTP response headers We test for HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy and X-Content-Type-Options on the live site. |
TLS-1 Art. 9(4)(b) Encryption | Use of strong authentication mechanisms and encryption based on relevant leading practices. | Encrypted transport (TLS 1.2+) We verify the certificate chain, expiry, supported TLS versions and cipher suites on every public hostname. |
EMAIL-1 Art. 9(4)(c) Secured information transfer | Secured information-transfer mechanisms that ensure authenticity and integrity of communications. | Email authentication (SPF / DKIM / DMARC) We resolve and validate SPF, DKIM and DMARC records, including DMARC enforcement policy and reporting addresses. |
EXP-1 Art. 8 Identification of all ICT-supported business functions | Identification, classification and documentation of all ICT-supported functions and information assets. | Exposed files & admin panels We probe for publicly accessible .env, .git, backups, admin panels and other sensitive paths that should never be reachable. |
SUB-1 Art. 28 ICT third-party risk & register of arrangements | Maintain a register of all contractual arrangements on the use of ICT services. The third-party data flow map gives outside-in evidence of which ICT third parties are actually loaded on your public surface — a frequent gap between the register and reality. | Third-party data flow map (subdomains & external services) We enumerate subdomains via Certificate Transparency logs, fingerprint every third-party service they load (analytics, payments, chat, CDNs, tag managers, ad networks, fonts) and map where browser-side data flows. This is the externally-observable evidence regulators ask for under supplier, supply-chain and processor-inventory clauses. |
External monitoring is one part of compliance. These areas need other evidence — typically from your GRC platform, HR system, or internal logging:
One scan. Every clause on this page evaluated against your live domain. Auditor-ready PDF in your inbox.
Annex A controls auto-evidenced from the public attack surface.
Article 21 cybersecurity measures + Article 23 incident reporting.
Information security in Dutch healthcare — technische maatregelen.
Continuous evidence for CC6 (logical access) and CC7 (system operations).
Article 32 security of processing + Article 33 breach notification.
External requirements for any business handling cardholder data.
We use strictly necessary cookies to run the site, and — only with your consent — analytics and marketing cookies (Google Analytics, Google Tag Manager) to improve the product. You can change your choice anytime via "Cookie preferences" in the footer. Privacy Policy · Sub-processors