DORA Compliance: What Financial Websites Actually Need to Know (2026)

Aug 24, 2026 · 10 min read · ← All guides

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:

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 resilience scan

Our free scanner now includes a DORA/resilience check that looks for six categories of operational resilience signals in any website's public HTML:

The scan works on any website — WordPress, custom-built, or enterprise platform. No installation, no registration, no cost.

🛡️ Passed? Add a free compliance badge to your site — client trust plus a dofollow backlink.

6. Timeline & enforcement

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:

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:

1. ☐ Incident reporting channel — Can someone report an ICT incident from your website? Is the process clear? Does it reach the right team?
2. ☐ Business continuity reference — Is there any mention of BC/DR capabilities on your site or in your legal disclosures?
3. ☐ ICT risk framework mention — Does your website reference your information security or ICT risk management framework?
4. ☐ Third-party risk disclosure — If you use critical ICT providers (cloud, payments, analytics), is this disclosed?
5. ☐ Resilience testing — Do you reference security testing, penetration testing, or vulnerability management?
6. ☐ DORA-specific mention — Does your compliance page explicitly reference DORA (if you are a financial entity)?
7. ☐ 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.