What is DORA and when does it apply?

DORA (Digital Operational Resilience Act) is an EU regulation (Regulation 2022/2554) that establishes a unified framework for managing ICT risk across the financial sector. It entered into force on 16 January 2023 and applies from 17 January 2025. DORA covers banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and critical ICT third-party service providers operating in the EU. The regulation introduces binding requirements for ICT risk management, incident reporting, resilience testing, third-party risk oversight, and information sharing.

Who must comply with DORA?

DORA applies to over 22,000 financial entities across the EU, including credit institutions (banks), insurance and reinsurance undertakings, investment firms, payment institutions, electronic money institutions, crypto-asset service providers (CASPs), central securities depositories, trading venues, fund managers (UCITS and AIFMs), credit rating agencies, and crowdfunding service providers. It also designates critical ICT third-party service providers (CTPPs) who serve these entities. If your organisation holds a financial services licence in an EU member state or provides critical ICT services to those that do, DORA applies to you.

What is the DORA Register of Information?

The Register of Information is a mandatory structured record of all contractual arrangements with ICT third-party service providers, required under DORA Article 28(3). Financial entities must maintain this register at entity, sub-consolidated, and consolidated levels. It must document every ICT service provider relationship including the nature of the service, whether it supports critical or important functions, data processing locations, subcontracting chains, and exit strategies. The register must be reported to competent authorities upon request. Venvera generates this register automatically from your provider and contract data and exports it in the EBA-mandated xBRL-CSV format across all 15 required tables.

What is xBRL-CSV and why does DORA require it?

xBRL-CSV (Extensible Business Reporting Language in CSV format) is the technical reporting format mandated by the European Banking Authority (EBA) for submitting the DORA Register of Information. It consists of 15 interconnected CSV tables covering entity identification, ICT third-party providers, contractual arrangements, functions supported, data locations, and subcontracting chains. Each table follows strict field definitions, controlled vocabularies, and cross-referencing rules defined in the EBA ITS. Building these files manually in spreadsheets is error-prone due to the cross-table dependencies and validation rules. Venvera generates all 15 xBRL-CSV tables automatically from your platform data with built-in validation.

How do you pass a DORA supervisory assessment?

Supervisory authorities assess DORA compliance by examining five pillars: your ICT risk management framework (Article 6), incident reporting capabilities (Article 19), digital operational resilience testing programme (Article 24), third-party ICT risk management including the Register of Information (Article 28), and information sharing arrangements (Article 45). To pass, you need documented policies, a complete and current Register of Information, evidence of incident classification and reporting within required timeframes, a testing programme proportionate to your risk profile, and board-level oversight with documented accountability. Venvera provides structured workflows, audit trails, and exportable evidence packages for each pillar.

What are the DORA incident reporting deadlines?

DORA requires financial entities to report major ICT-related incidents to their competent authority using a three-stage process: an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours after detection), an intermediate report within 72 hours of the initial notification with updated information on impact and root cause, and a final report within one month of the intermediate report with full root cause analysis, impact assessment, and remediation actions. Classification criteria include the number of clients affected, data loss, duration, geographic spread, and criticality of services impacted. Venvera tracks these deadlines automatically and generates pre-formatted reports for each stage.

What is DORA Article 5(2) personal liability for board members?

DORA Article 5(2) places direct responsibility on the management body (board of directors or equivalent) to define, approve, oversee, and be accountable for the implementation of the ICT risk management framework. This means individual board members can face personal liability if the organisation fails to establish or maintain adequate ICT risk management. Board members must demonstrate they have approved ICT risk policies, allocated sufficient resources, reviewed ICT risk reports regularly, and ensured adequate training. Venvera tracks board-level approvals, policy sign-offs, and oversight activities so you can demonstrate Article 5(2) compliance with a clear evidence trail.

DORA compliance

DORA is law. And the fine has your name on it.

The Register of Information, ICT risk, self-starting incident clocks and resilience testing - the whole Digital Operational Resilience Act kept permanently audit-ready. Your NCA submission and your board’s personal liability under Article 5, covered before anyone asks.

ICT risk managementIncident reportingResilience testingThird-party riskInformation sharing

Get my free gap report →Book a 15-min demo See what you already have ↓

How much of DORA do you already have?

Pick the framework you already run. Every control domain that appears in both is listed with the requirement reference on each side, so you can see the reusable part of your existing programme before you scope any new work.

You already run

You have been asked to add

27 of the 43 domains in this crosswalk appear in both NIS2 and DORA.

Domain	NIS2	DORA
Encryption	Art. 21(2)(h)Are policies and procedures in place governing the use of cryptography, including encryption standards for data at rest and in transit?	Art. 9(4)(d)Is data encrypted at rest and in transit using industry-standard cryptographic techniques, with documented key management procedures?
Access Control	Art. 21(2)(i)Is there a formal access control policy enforcing least privilege principle, with documented procedures for access provisioning and de-provisioning?	Art. 9(4)(c)Is there a formal identity and access management policy enforcing least privilege, multi-factor authentication for critical systems, and regular access recertification?
Identity Management	Art. 21(2)(i)Is there a formal access control policy enforcing least privilege principle, with documented procedures for access provisioning and de-provisioning?	Art. 9(4)(c)Is there a formal identity and access management policy enforcing least privilege, multi-factor authentication for critical systems, and regular access recertification?
Authentication & MFA	Art. 21(2)(j)Is multi-factor authentication or continuous authentication deployed for access to critical systems, remote access, and privileged accounts?	Art. 9(4)(c)Is there a formal identity and access management policy enforcing least privilege, multi-factor authentication for critical systems, and regular access recertification?
Network Security	Art. 21(2)(g)Are basic cyber hygiene practices established and enforced, including patching, password policies, device management, and network segmentation?	Art. 9(4)(b)Are network security controls (segmentation, firewalls, intrusion prevention) implemented to protect ICT systems, with regular review and hardening?
Vulnerability Management	Art. 21(2)(e)Is there a vulnerability handling and disclosure process that ensures timely identification, assessment, and remediation of vulnerabilities?	Art. 9(4)(a)Is there a formal patch and vulnerability management process that ensures timely remediation of identified vulnerabilities in all ICT systems?
Logging & Monitoring	Art. 21(2)(f)Are security metrics and KPIs defined, tracked, and reported to management to measure the effectiveness of cybersecurity controls?	Art. 10(1)–(4)Do you operate continuous monitoring and detection capabilities (SIEM, IDS/IPS, anomaly detection) to promptly identify ICT-related incidents and anomalous activities?
Incident Management	Art. 21(2)(b)Is there a documented incident handling procedure covering detection, analysis, containment, eradication, and recovery phases?	Art. 17(1)–(2)Do you have a documented ICT incident management process covering detection, recording, classification, escalation, response, and closure?
Incident Classification	Art. 23(3)Are incident classification criteria documented, distinguishing significant incidents based on impact on service provision, affected users, duration, and geographic scope?	Art. 18(1)Are incidents classified as major or non-major using documented criteria aligned with DORA thresholds? Art. 18(1)(a)–(g)Does classification consider all DORA quantitative criteria: number of clients affected, transaction value, duration, geographic spread, data losses, criticality of affected services, and economic impact?
Incident Reporting	Art. 23(4)(a)–(b)Can your organisation submit an early warning to the CSIRT within 24 hours and an incident notification within 72 hours of becoming aware of a significant incident?	Art. 19(4)(a)Can your organisation submit initial incident notifications to the competent authority within 4 hours of classifying an ICT incident as major? Art. 19(4)(b)–(c)Do you have processes and templates to submit the intermediate report (within 72 hours) and final report (within 1 month) for major ICT incidents?
Incident Response Team	Art. 21(2)(b)Is there a documented incident handling procedure covering detection, analysis, containment, eradication, and recovery phases?	Art. 17(2)Is a dedicated incident response team established with defined roles, escalation paths, on-call procedures, and authority to act during ICT incidents?
Post-Incident Review	Art. 21(2)(b)Do you perform post-incident reviews for significant incidents, with root cause analysis and lessons learned fed into risk management improvements?	Art. 17(3)Do you perform formal post-incident reviews with root cause analysis for all major ICT incidents, with findings fed back into the risk management framework?
Business Continuity	Art. 21(2)(c)Are business continuity and disaster recovery plans documented, covering all critical services, with defined RTO/RPO targets and tested at least annually?	Art. 11(1)–(11)Are ICT business continuity and disaster recovery plans documented, tested at least annually, approved by management, and covering all critical business functions?
Backup & Restoration	Art. 21(2)(c)Are backup procedures implemented with defined scope, frequency, and secure off-site storage, with regular restoration testing?	Art. 12(1)–(7)Do you maintain backup and restoration policies specifying scope, frequency, and secure storage locations, with regular restoration testing?
Crisis Management	Art. 21(2)(c)Is there a crisis management framework with defined escalation procedures, communication plans, and designated crisis management team?	Art. 14(1)–(2)Are ICT crisis communication plans documented, defining internal and external notification procedures, roles, and responsible disclosure policies?
Third-Party Risk Management	Art. 21(2)(d)Is there a documented supply chain security policy covering ICT product and service procurement, with security requirements for suppliers?	Art. 28(2)Has the management body approved an ICT third-party risk strategy that is aligned with the overall ICT risk management framework and reviewed at least annually?
Supplier Due Diligence	Art. 21(2)(d)Do you assess the cybersecurity posture and practices of direct suppliers and service providers before entering into agreements?	Art. 28(4)Is thorough due diligence and risk assessment performed before entering into new ICT third-party arrangements, particularly for critical or important functions?
Supplier Contracts	Art. 21(2)(d)Do supplier contracts include cybersecurity requirements, incident notification obligations, and audit/assessment rights?	Art. 30(2)(a)Do ICT third-party contracts include clear service level agreements (SLAs) with quantitative performance targets, monitoring measures, and consequences for non-compliance? Art. 30(3)(e)Do contracts for critical or important ICT services include unrestricted rights of audit and inspection, including on-site access and use of pooled audits?
Supplier Monitoring	Art. 21(2)(d)Are supply chain risks and supplier cybersecurity performance monitored on an ongoing basis, with periodic re-assessment?	Art. 28(5)Are critical or important ICT third-party providers subject to continuous monitoring and formal performance reviews at least annually?
Risk Assessment	Art. 21(2)(a)Is there a formal, documented risk analysis methodology that identifies and assesses cybersecurity risks to network and information systems?	Art. 8(2)–(6)Is there a formal ICT risk identification and assessment process performed at least annually, after significant changes, and after major ICT incidents?
Information Security Policy	Art. 21(2)(a)Has the management body approved a comprehensive information security policy covering all network and information systems, reviewed at least annually?	Art. 9(1)–(2)Are comprehensive ICT security policies and standards documented, approved by management, communicated to all staff, and reviewed regularly?
Security Awareness Training	Art. 20(2), Art. 21(2)(g)Is there a cybersecurity awareness and training programme for all staff, including management body members, with regular refresher sessions?	Art. 13(6)Is there an ICT security awareness and training programme covering all staff (including management) that is updated regularly and includes DORA-specific obligations?
Change Management	Art. 21(2)(e)Is there a formal change management process for network and information systems that includes security impact assessment and testing?	Art. 9(4)(e)Are ICT change management procedures in place to ensure controlled, tested, and approved modifications to ICT systems and applications?
Security Testing	Art. 21(2)(f)Are there defined policies and procedures to assess the effectiveness of cybersecurity risk-management measures, including regular security testing?	Art. 24(1)–(2)Have you established a digital operational resilience testing programme that is risk-based, covers critical ICT systems, and is reviewed at least annually?
Penetration Testing	Art. 21(2)(f)Are there defined policies and procedures to assess the effectiveness of cybersecurity risk-management measures, including regular security testing?	Art. 25(1)Are penetration tests conducted at least annually on critical ICT systems, simulating real-world attack scenarios?
Breach Notification	Art. 23(4)(a)–(b)Can your organisation submit an early warning to the CSIRT within 24 hours and an incident notification within 72 hours of becoming aware of a significant incident?	Art. 19(4)(a)Can your organisation submit initial incident notifications to the competent authority within 4 hours of classifying an ICT incident as major?
Human Oversight	Art. 20(1)Does the management body receive regular (at least quarterly) reports on cybersecurity risk posture and treatment progress?	Art. 5(1)–(2)Has the management body defined, approved, and assumed ultimate responsibility for an ICT risk management framework with clear roles, responsibilities, and reporting lines?

A row means the two requirements cover the same ground, so one implementation and one set of evidence can usually serve both. It does not mean satisfying one certifies the other: each framework keeps its own scope, wording and assessment, and some requirements have no counterpart at all. Treat this as a starting map for planning, then confirm each row against the requirement text.

DORA compliance software, from ICT risk to the Register of Information

Venvera is DORA compliance software for the financial entities in scope of Regulation (EU) 2022/2554: banks, insurers, investment firms, payment institutions, crypto-asset service providers and the ICT third-party providers they rely on. It holds 21 tracked controls across ICT risk management, incident reporting, resilience testing and third-party risk, keeps the Register of Information in the ESA xBRL-CSV shape your National Competent Authority asks for, starts the incident clocks on classification, and names the evidence each control needs. Board oversight under Article 5 is evidenced in the same place.

What is DORA, and why can you not ignore it?

The Digital Operational Resilience Act (Regulation 2022/2554) is EU law, in force since 17 January 2025, binding over 22,000 financial entities: banks, insurers, investment firms, payment institutions and crypto-asset service providers. It is not a certificate you choose to pursue - your National Competent Authority expects your Register of Information submitted in the ESA xBRL-CSV format, and under Article 5 your management body is personally accountable for the ICT risk framework. Miss a filing or an incident deadline and the exposure lands on named individuals, not just the company.

/ DORA · every pillar, one audit-ready screen

xBRL-CSV tables generated automatically

Incident classification deadline tracked

5(2)

Board liability article evidenced

5 min

Gap assessment completion time

Article 28 · exclusive

One-click xBRL-CSV export. No other platform has it.

This is the piece the US-built compliance platforms simply do not have. They map DORA onto their existing control library and stop there - none of them generate the EBA xBRL-CSV file your National Competent Authority actually requires. Venvera does. Your register is built from the providers and contracts you already track - every ICT third-party provider, contractual arrangement, supporting function and subcontracting chain, held as structured fields that map straight onto the EBA’s 15 tables. When the submission window opens, export all 15 tables, cross-references validated, in seconds - in the exact format your regulator ingests. No manual CSV assembly, no broken foreign keys, no last-minute scramble.

Native xBRL-CSV export in the EBA format - unique to Venvera, not offered by US-built tools
All 15 EBA tables generated automatically from your platform data
Cross-table validation catches errors before you submit
Entity, sub-consolidated and consolidated level registers
Subcontracting chain tracking with n-th party visibility

/ xBRL-CSV EXPORT · 15 validated tables, one click - only on Venvera

Article 6

An ICT risk register that runs Article 6 for you.

A centralised risk register purpose-built for DORA Article 6. Every ICT risk scored on a 5x5 likelihood-by-impact matrix with automatic classification from Low through Critical. Assign ownership, set review dates, track treatment decisions and generate board-ready reports in one click - with a full audit trail on every change to satisfy supervisory evidence requirements.

Automated 5x5 risk scoring with inherent and residual risk tracking
9 ICT risk categories aligned to the DORA taxonomy
Risk appetite thresholds with automatic escalation triggers
Cross-framework control mapping to NIS2, ISO 27001 and GDPR
Quarterly risk snapshots for trend analysis and audit evidence

/ ICT RISK · 5x5 scoring, full audit trail

Article 19

Incident clocks that start themselves.

DORA gives you 4 hours to classify a major ICT incident and start reporting. Venvera enforces the timeline with built-in classification criteria, automatic deadline tracking and pre-formatted templates for all three reporting stages - initial notification, intermediate report and final report. The clock starts the moment the incident does, so a regulatory deadline is never something someone had to remember.

Automatic incident classification against DORA severity criteria
Countdown timers for the 4-hour, 72-hour and 1-month deadlines
Pre-formatted templates for initial, intermediate and final reports
Escalation workflows when deadlines approach
Complete incident timeline with audit trail for supervisory review

/ INCIDENTS · 4h / 72h / 1mo, tracked to the minute

Article 28

Find your concentration risk before your regulator does.

Article 28 makes you manage ICT third-party risk across the whole provider relationship. Venvera scores each provider on five weighted dimensions - criticality, geographic risk, concentration, contract health and data sensitivity - and flags single points of failure before a supervisor asks about them. Exit strategies, substitutability assessments and subcontracting chains all live in one place.

Five-dimension automated risk scoring per provider
Concentration risk alerts at country and provider level
Exit strategy documentation with substitutability scoring
Sub-outsourcing chain mapping with n-th party tracking
Contract lifecycle monitoring: expiry, SLAs, audit rights

/ THIRD-PARTY RISK · concentration surfaced, exits documented

Article 5(2)

The evidence file that protects your board.

Article 5(2) makes board members personally accountable for the ICT risk management framework - so the question is not whether they governed, but whether you can prove it. Venvera tracks every element of board oversight: policy approvals, risk report reviews, resource allocation decisions, training completion and meeting attendance, all in one dashboard with a liability evidence package exportable per board member.

Policy approval tracking with digital sign-off records
Board meeting attendance and agenda item logging
Resource allocation documentation for ICT risk budgets
Training completion records for management body members
Personal liability evidence package exportable per board member

/ BOARD · Article 5(2) oversight, evidenced

Readiness

Know exactly where you stand in five minutes.

A gap assessment that evaluates your organisation against all five DORA pillars - ICT risk management, incident reporting, resilience testing, third-party risk and information sharing - and hands back a scored maturity assessment with a prioritised remediation roadmap, effort estimates and owners. Track progress from first assessment through full compliance instead of guessing.

Five-pillar assessment covering all DORA requirements
Maturity scoring: Not Started, Partial, Implemented, Effective
Auto-generated remediation roadmap with priority and effort estimates
Ownership assignment and deadline tracking per remediation item
Progress dashboard showing compliance trajectory over time

/ GAP ASSESSMENT · five pillars, scored and prioritised

Why switch

The spreadsheet or Venvera.

Spreadsheets

Venvera

Manual CSV assembly, broken cross-references

Auto-generated 15 xBRL-CSV tables with validation

ICT risk scoring

Spreadsheet formulas, inconsistent methodology

Automated 5x5 matrix with audit trail

Incident reporting

Email chains, manual deadline tracking

4h/72h/1mo countdown timers with auto-escalation

Third-party risk

Vendor list without scoring or concentration view

5-dimension auto-scoring with concentration alerts

Board oversight

No evidence trail for Article 5(2)

Digital sign-offs, training records, oversight log

Gap assessment

One-off consultant engagement, static PDF

Living assessment with roadmap and progress tracking

DORA, answered.

DORA guides

How long does DORA compliance take?
Four to six months from a mature programme, nine to twelve from spreadsheets, and why.
DORA compliance cost: a line-by-line model
The eight work items every DORA programme pays for, and what multiplies each one.
The complete guide to the DORA Register of Information
All 15 templates from Implementing Regulation 2024/2956 and how they connect.
DORA major incident classification: the 7 criteria
The exact test in Delegated Regulation 2024/1772 and the 4h, 72h and 1-month clocks.
DORA ICT third-party risk: building a compliant vendor register
The contract clauses, the sub-outsourcing RTS and the exit tests.
DORA TLPT: threat-led penetration testing
Who gets designated, the TIBER-EU phases, and how to plan the engagement.
Why your Register of Information keeps getting rejected
The seven ESA rule codes that actually reject a submission, and how to clear them.

Know where you stand on DORA before your NCA does.

Start with a free gap report across all DORA domains - 10 minutes, no email to start.

Get my free gap report →Book a 15-min demo

✓ Every paid plan: audit-ready in 90 days, or your money back^*

10 minutes · no email to start · no credit card · yours to keep

Compliance operations

Risk & incidents

Intelligence & reporting

EU financial

Privacy & security

Regional

By industry

By role

Learn

Free tools & offers