Regulation · Financial services · European Union
DORA compliance means meeting the Digital Operational Resilience Act, which applies to EU financial entities since 17 January 2025. You need an ICT risk management framework, major-incident reporting within hours, resilience testing, a register of ICT third-party contracts, and contract terms that critical providers must accept.
DORA applies directly in every EU member state, so the question is whether your entity type is listed.
QULDEX helps here first: the readiness check shows where you stand before you commit budget.
DORA requires financial entities to manage ICT risk under board oversight, report major ICT incidents fast, test their resilience, and control ICT third-party risk through registers, contracts and exit plans.
A board-owned framework covering identify, protect, detect, respond, recover.
In QULDEX: Framework mapped to evidenceClassify incidents; report major ones within 4 h, 72 h and 1 month.
In QULDEX: Deadline timers per incidentYearly testing of critical systems; TLPT every 3 years where required.
In QULDEX: Testing programme and resultsRegister of information, contract terms and exit strategies.
In QULDEX: Register and contract checksDirect ESA oversight of designated critical providers.
In QULDEX: Provider status trackedVoluntary threat-intelligence sharing.
In QULDEX: Sharing arrangements recordedThese 24 articles carry the obligations most financial entities work on, grouped by pillar. Select any article to see what it requires, typical evidence and the matching ISO 27001, ISO 22301 or NIS2 reference.
Showing up to 6 per group. Search, filter, or open a group to see all 24.
Art. 5Governance and organisationThe management body defines, approves and oversees the ICT risk framework and is ultimately responsible for it.
In QULDEXBoard approvals and training are recorded as evidence.
Art. 6ICT risk management frameworkKeep a documented framework of strategies, policies, procedures and tools, reviewed at least yearly.
In QULDEXThe framework and its yearly review run as a recurring task.
Art. 8IdentificationIdentify and classify ICT-supported business functions, assets and dependencies, and keep the inventories current.
In QULDEXAsset and dependency inventories link to each critical function.
Art. 9Protection and preventionApply security policies, access controls, encryption and change management to protect ICT systems.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 10DetectionDetect anomalous activity promptly, with defined alert thresholds.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 11Response and recoveryKeep an ICT business continuity policy and response and recovery plans, tested regularly.
In QULDEXContinuity plans and test results reuse ISO 22301 evidence.
Art. 12Backup and restorationSet backup policies and restoration methods, with segregated systems.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 13Learning and evolvingReview incidents and tests, run ICT security awareness and digital resilience training, including for the management body.
In QULDEXLessons learned become CAPA items.
Art. 16Simplified ICT risk frameworkSmall and non-interconnected investment firms and some other entities apply a lighter framework.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 17ICT incident management processDetect, manage, log and classify ICT-related incidents and notify them.
In QULDEXEvery incident is logged with classification and owner.
Art. 18Classification of incidents and threatsClassify incidents by clients affected, duration, geography, data loss, criticality and economic impact.
In QULDEXClassification criteria from the RTS are built into the incident form.
Art. 19Reporting of major incidentsReport major incidents to the competent authority: initial notification, intermediate report and final report.
In QULDEXReporting deadlines (4 h / 24 h, 72 h, 1 month) are timers on each major incident.
Art. 19(2)Significant cyber threatsYou may voluntarily notify significant cyber threats.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 24Digital operational resilience testing programmeKeep a risk-based testing programme as part of the ICT risk framework.
In QULDEXThe testing programme is a schedule with results and findings.
Art. 25Testing of ICT tools and systemsRun vulnerability assessments, scans, scenario tests, performance and penetration tests; test critical systems at least yearly.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 26Threat-led penetration testingEntities identified by authorities run TLPT at least every three years, covering critical functions.
In QULDEXTLPT scope, providers and remediation are tracked as an engagement.
Art. 28ICT third-party riskManage ICT third-party risk as part of the ICT risk framework, with a strategy and policy for critical services.
In QULDEXEach provider is assessed and linked to the functions it supports.
Art. 28(3)Register of informationRegisterKeep a register of all ICT third-party contractual arrangements and report it to the competent authority.
In QULDEXThe register is maintained in QULDEX and exported for the ESAs' templates.
Art. 28(8)Exit strategiesHave exit strategies for ICT services supporting critical or important functions.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 30Key contractual provisionsContracts must cover service descriptions, locations, security, access and audit rights, incident support and termination.
In QULDEXContract clauses are checked against Art. 30 per provider.
Art. 31Critical ICT third-party providersThe ESAs designate critical providers, which then fall under direct EU oversight.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 35Periodic penalty payments for CTPPsLead Overseers can impose daily penalty payments of up to 1% of a critical provider's average daily worldwide turnover.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 45Information-sharing arrangementsFinancial entities may share cyber threat information within trusted communities.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Art. 50Administrative penaltiesMember States set administrative penalties and remedial measures; competent authorities can publish them.
In QULDEXQULDEX gives this requirement an owner, evidence requests and a review date, and reuses ISO 27001 and ISO 22301 evidence where it fits.
Nothing matches that search.
Article numbers follow Regulation (EU) 2022/2554. Reporting timelines follow the incident-reporting RTS and ITS. Summaries are QULDEX paraphrases, not legal advice.
There is no DORA certificate. You build the ICT risk framework, set up incident reporting, test, and control third parties, then prove it to your supervisor. Entities still closing gaps typically need 4 to 9 months.
Identify the business functions, ICT assets and providers that support them.
Board-approved strategy, policies and tools for identify, protect, detect, respond and recover.
Apply the RTS criteria and meet the 4-hour, 72-hour and one-month deadlines.
Record every ICT third-party arrangement in the ESAs' templates and fix Art. 30 contract gaps.
Yearly tests of critical systems, and TLPT every three years if your authority requires it.
DORA has applied since 17 January 2025. Durations are QULDEX planning ranges for closing remaining gaps.
Supervisors ask for these records in DORA reviews.
| Document | Article | Where it lives in QULDEX |
|---|---|---|
| ICT risk management framework | Art. 6 | Policy library |
| Digital operational resilience strategy | Art. 6(8) | Policy library |
| ICT asset and dependency inventory | Art. 8 | Risk register |
| ICT business continuity policy and plans | Art. 11 | Evidence vault |
| Backup and restoration procedures | Art. 12 | Evidence vault |
| Incident log and major-incident reports | Art. 17–19 | CAPA automation |
| Testing programme and results | Art. 24–25 | Audit workspace |
| TLPT attestation (if required) | Art. 26 | Audit workspace |
| Register of information | Art. 28(3) | Vendor register |
| Exit strategies and contract checklist | Art. 28(8), 30 | Vendor register |
Document names follow DORA and its technical standards; storage locations are QULDEX recommendations.
Closing remaining DORA gaps typically takes 4 to 9 months. The register of information and contract remediation usually take longest, especially with many ICT providers.
Bars show the upper end of each range on one scale (9 months = full width); testing is continuous.
Check these eight things first. Nothing you enter leaves this page.
DORA is the sector-specific law for finance, so it takes precedence over NIS2 for financial entities. ISO 27001 and ISO 22301 evidence covers much of its ICT risk pillar.
| DORA | NIS2 | ISO 27001:2022 | ISO 22301 | Shared evidence |
|---|---|---|---|---|
| Art. 5 Governance | Art. 20 | 5.1, 5.3 | 5.1 | Board approvals |
| Art. 6 Framework | Art. 21(2)(a) | 6.1 | 6.1 | Risk framework |
| Art. 8 Identification | Art. 21(2)(i) | A.5.9 | 8.2 | Asset inventory |
| Art. 11 Response and recovery | Art. 21(2)(c) | A.5.29–A.5.30 | 8.4 | Continuity plans |
| Art. 17–19 Incidents | Art. 23 | A.5.24–A.5.26 | 8.4.3 | Incident log |
| Art. 25 Testing | Art. 21(2)(f) | A.8.8 | 8.5 | Test reports |
| Art. 28 Third parties | Art. 21(2)(d) | A.5.19–A.5.22 | 8.3 | Vendor register |
Indicative mapping for planning, not legal advice. DORA vs NIS2 is compared in full on the blog.
QULDEX is DORA compliance and audit management software built from EGV Group's audit delivery, used by financial entities, their advisors and the internal and external auditors who test them. Pick your role to see who does what.
For banks, insurers, payment firms and investment firms.
For DORA consultants and internal audit.
For external auditors and TLPT testers.
Requirements with owners, test steps and the crosswalk to 50+ frameworks.
Explore →EvidenceEvidence linked to controls and findings, with upload, review and approval history.
Explore →RiskRisk assessment and treatment, with decisions traced to the controls they drive.
Explore →FindingsFindings from internal and external audits tracked to closure with due dates.
Explore →DORA entered into force on 16 January 2023 and has applied since 17 January 2025 across the EU, without national transposition.
An initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within one month.
A register of every ICT third-party contractual arrangement, kept at entity and group level in the ESAs' templates and submitted to the competent authority each year.
Indirectly through contracts with financial entities, and directly for providers the ESAs designate as critical, which fall under EU oversight. The first list of 19 critical providers was published in November 2025.
Member States set administrative penalties for financial entities. Critical ICT providers can face periodic penalty payments of up to 1% of average daily worldwide turnover.
Reviewed by
Answer a short readiness check and get a gap summary by pillar. No sales call needed to see the result.