Contents
- 1. What is DORA?
- 2. Who needs to comply?
- 3. The five pillars of DORA compliance
- 1. ICT Risk Management (Art. 5–15)
- 2. ICT Incident Reporting (Art. 17–23)
- 3. Digital Operational Resilience Testing (Art. 24–27)
- 4. ICT Third-Party Risk Management (Art. 28–43)
- 5. Information Sharing (Art. 45)
- 4. What this means for your website
- Incident reporting contact
- Business continuity information
- Third-party risk disclosures
- ICT risk framework
- 5. Free DORA page-signal check
- 6. Timeline & enforcement
- 7. DORA vs GDPR vs NIS2 — how they fit together
- 8. DORA checklist for websites — what to review
DORA Compliance: What Financial Websites Actually Need to Know (2026)
1. What is DORA?
The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — is the EU's framework for ensuring financial entities can withstand, respond to, and recover from ICT-related disruptions and threats. DORA entered into force on 17 January 2025, making it one of the newest compliance requirements for financial-sector websites and services operating in or serving the EU.
Unlike GDPR (which protects personal data) or NIS2 (which secures critical infrastructure), DORA focuses specifically on operational resilience — the ability to keep critical functions running during ICT failures, cyberattacks, or system outages.
2. Who needs to comply?
DORA covers a broad range of financial entities under EU financial services legislation:
| Category | Examples | In scope? |
|---|---|---|
| Banks & credit institutions | Retail, investment, private banks | Yes |
| Payment institutions | Stripe, PayPal, Adyen, Wise | Yes |
| Investment firms | Brokers, wealth managers | Yes |
| Crypto-asset service providers | Exchanges, wallets, custodians | Yes (MiCA-licensed) |
| Insurance & reinsurance | Carriers, brokers | Yes |
| ICT third-party providers | Cloud services (AWS, Azure), data analytics, compliance SaaS | Yes — critical TPPs are designated by ESAs |
| Small / non-interconnected firms | Small investment advisors | Partial — simplified regime |
If your company provides ICT services to financial entities — even if you are not a financial entity yourself — DORA may apply to you through the third-party oversight framework.
3. The five pillars of DORA compliance
1. ICT Risk Management (Art. 5–15)
Establish a framework for identifying, classifying, and managing ICT risks. This includes business continuity management, incident response capabilities, and regular risk assessments documented and reviewed by the board.
2. ICT Incident Reporting (Art. 17–23)
Classify and report major ICT incidents to competent authorities. Initial notification within 4 hours for major incidents, intermediate report within 24 hours, and a final report within one month. Your website should clearly communicate how stakeholders can report incidents.
3. Digital Operational Resilience Testing (Art. 24–27)
Regular testing of ICT systems: vulnerability scans, penetration testing, and — for larger entities — threat-led penetration testing (TLPT) every 3 years. Testing scope includes web applications, APIs, and customer-facing digital services.
4. ICT Third-Party Risk Management (Art. 28–43)
Manage risks arising from outsourcing and third-party ICT providers. Maintain a register of contractual arrangements, assess concentration risk, and ensure contracts include DORA-required clauses for audit, termination, and performance monitoring.
5. Information Sharing (Art. 45)
Participate in threat intelligence sharing arrangements among financial entities — sharing cyber threat information to improve collective resilience. Your site may need to reference participation in such arrangements.
4. What this means for your website
While DORA is primarily an operational regulation (not a "put this on your website" regulation like GDPR), your public-facing website plays several important roles in DORA compliance:
Incident reporting contact
DORA Article 17 requires financial entities to have and communicate a process for ICT incident reporting. While the formal reporting goes to national competent authorities, your website should clearly indicate how stakeholders can report security incidents or ICT disruptions — whether through a dedicated email, a secure portal, or a contact form with appropriate classification.
Business continuity information
For larger financial entities, DORA expects published information about business continuity planning. This doesn't mean revealing your full DR plan, but your website should reference BC/DR capabilities and communicate expected service levels during disruptions.
Third-party risk disclosures
If you use critical ICT third-party providers (cloud infrastructure, payment processing, core banking systems), customers and regulators expect your website to disclose concentration risks and your approach to third-party oversight.
ICT risk framework
Financial entities subject to DORA must demonstrate board-level oversight of ICT risk. Your website should reference your information security management system (ISMS), risk framework certifications (ISO 27001, SOC 2), and how you manage ICT-related risk.
5. Free DORA page-signal check
Our free scanner includes a DORA page-signal check. It counts nine static text markers in any website's public HTML — the served page only, never DNS or the surrounding infrastructure:
| Signal | What it looks for |
|---|---|
| Incident response / SOC reporting | Text such as "incident-response", "SOC-report" or "security-incident" |
| BC/DR planning reference | Text such as "BCDR", "DR-plan" or "business-continuity" |
| Multi-server / failover / redundancy signals | Text such as "multiple-server", "failover", "redundant" or "multi-AZ" |
| CDN failover / multi-CDN | Text such as "CDN-failover", "multi-CDN" or "backup-origin" |
| Status page / uptime monitoring | Text such as "status-page" or "uptime-monitor" |
| SPF (email sender auth) | Text such as "SPF-record" or "v=spf" |
| DKIM (email signing) | Text such as "DKIM" or "domainkey" |
| DMARC (email policy) | Text such as "dmarc_record" or "_dmarc." |
| MX (mail exchange) | Text such as "MX-record", "MX 10" or "mail-exchange" |
Two or more markers count as a pass. The scan works on any website — WordPress, custom-built, or enterprise platform. No installation, no registration, no cost.
Three of the nine markers are email-authentication and mail-routing wording, which is worth knowing before you act on the result: text that merely names SPF, DKIM, DMARC or MX can add markers without describing any control you actually operate. The check reads the served page, so it is a signal about wording, not a DORA assessment — DORA conformity is established by documented controls, not by a keyword count.
Run a free scan →Passed? Add a free compliance badge to your site — client trust plus a dofollow backlink.
6. Timeline & enforcement
| Date | Milestone |
|---|---|
| 16 Jan 2023 | DORA entered into force |
| 17 Jan 2025 | Application date — DORA became legally enforceable |
| 2025–2026 | National competent authorities begin supervisory assessments; first enforcement actions expected |
| 2026–2027 | ESAs designate critical ICT third-party providers; first TLPT cycles completed |
| 2027 | First comprehensive DORA reviews by European Supervisory Authorities (EBA, EIOPA, ESMA) |
7. DORA vs GDPR vs NIS2 — how they fit together
If you're responsible for compliance across multiple EU frameworks, here is how DORA relates to the other big regulations:
| Regulation | Scope | Focus | Applies to websites? | Penalties |
|---|---|---|---|---|
| DORA | Financial entities + ICT TPPs | Operational resilience (ICT continuity, incident response, testing) | Yes — as a channel for disclosures | Up to 2% turnover |
| GDPR | All orgs processing EU personal data | Data protection, privacy, consent | Yes — cookies, forms, privacy notices | Up to €20M or 4% |
| NIS2 | Essential & important entities | Network & information security, incident reporting, supply chain | Yes — security headers, breach reporting | Up to €10M or 2% |
| EAA | Commerce/services websites | Digital accessibility (WCAG) | Yes — accessibility statement, alt text | Varies by member state |
DORA and NIS2 share some overlaps (both require incident reporting, risk management, and testing). The difference: NIS2 applies broadly to critical infrastructure (energy, transport, health, digital infrastructure), while DORA is specifically for financial-sector operational resilience.
8. DORA checklist for websites — what to review
Use this checklist to assess whether your financial-entity website meets DORA expectations:
- Incident reporting channel — Can someone report an ICT incident from your website? Is the process clear? Does it reach the right team?
- Business continuity reference — Is there any mention of BC/DR capabilities on your site or in your legal disclosures?
- ICT risk framework mention — Does your website reference your information security or ICT risk management framework?
- Third-party risk disclosure — If you use critical ICT providers (cloud, payments, analytics), is this disclosed?
- Resilience testing — Do you reference security testing, penetration testing, or vulnerability management?
- DORA-specific mention — Does your compliance page explicitly reference DORA (if you are a financial entity)?
- Accessibility — DORA doesn't mandate accessibility, but the EAA does — and a regulator checking compliance notices everything.
Or start with our full EU compliance checklist covering GDPR, NIS2, DORA, and EAA in one document.
Further reading
How does EUComply compare with the established tools? See our head-to-head comparison — pricing, features and where each one falls short.