There is no DORA certificate and no regulator sign-off. Compliance is a file you can put in front of your competent authority. This page lists what goes in it, the article behind each item, the order that actually works, and where to get help if you need it.
DORA has applied since 17 January 2025, with no transitional period written into it. Being compliant does not mean holding a certificate: no competent authority issues one, and no auditor can grant one. It means being able to show, on request, that the framework exists, that it is approved at board level, that the register of information is current, that incidents would be reported inside the deadlines, and that the contracts supporting your critical or important functions carry the clauses Article 30 requires. The work below is what that file contains.
DORA is a regulation, so it binds directly and there is no national transposing law to wait for. What it does not have is a conformity assessment procedure. Nothing in the text creates a DORA certificate, a registration, a declaration of conformity or an approval step. That has a practical consequence worth stating plainly, because a lot of marketing says otherwise: no firm can certify your institution as DORA-compliant, and any offer that says it can is selling something else.
What does exist is evidence. Article 6(5) requires the ICT risk management framework to be documented and reviewed at least once a year, and again after a major incident or following supervisory instructions. Article 5(2) makes the management body responsible for defining, approving and overseeing it. Your competent authority supervises against that, through the ordinary supervisory dialogue, through the register of information you submit, and through what you report when something breaks.
Two things people mean by "DORA certification". One is certifying the institution, which does not exist. The other is certifying the people: professional certification that an individual understands the framework and can run the work. That exists, and it is what our certification programmes and the Academy do. Article 13(6) makes training compulsory anyway, so it is one of the few deliverables you can close quickly.
If you are not sure the regulation reaches you at all, settle that before anything else. The list in Article 2(1) is closed, and it works by legal category, not by size or activity: the scope tool asks for your authorisation for that reason. Entities outside the EU are a separate question, handled in the non-EU guidance.
The regulation is not written in the order you can implement it. Numbers below are the order that works: you cannot write a third-party policy before you know which functions are critical or important, and you cannot run a meaningful test programme before you know what you are protecting. Each item links to the article it comes from, in the article index.
Which legal category you fall into under Article 2(1), and whether Article 4 proportionality or the Article 16 simplified framework changes what you owe. The list in Article 2(1) is closed: the answer comes from your authorisation, not from your size or your sector.
The definition sits in Article 3(22), and almost every obligation downstream is scoped by it. Get this wrong and the register, the testing programme and the contractual clauses are all wrong with it. This is the single most consequential document of the whole programme.
Article 6(1) requires a sound, comprehensive and well-documented framework. Article 5(2) puts the management body in charge of defining, approving and overseeing it, so an unapproved framework is not a framework. Article 6(5) requires it to be documented and reviewed at least once a year, and again after a major incident or following supervisory instructions.
Article 9(4) sets out what the framework must contain on protection and prevention: information security policy, identity and access management, encryption, change management, network segmentation. Delegated Regulation (EU) 2024/1774 fills in the detail, and it is prescriptive enough to be used as a checklist.
Article 11(1) requires a comprehensive ICT business continuity policy, built on the identification work of Article 8. Article 12(1) requires backup and restoration procedures to be developed and documented, with recovery objectives that stand up to being tested rather than asserted.
A documented process under Article 17, the classification criteria of Article 18 and Delegated Regulation (EU) 2024/1772, and the reporting chain of Article 19. The part teams get wrong is not the process: it is knowing when the clock starts, and being able to produce the initial notification inside it on a bad day.
Article 28(3) requires a register of information covering all contractual arrangements on the use of ICT services, at entity level and, where relevant, on a sub-consolidated and consolidated basis. Implementing Regulation (EU) 2024/2956 fixes the templates and the taxonomy, so this is a data exercise with a defined output format, not a free-form spreadsheet.
Article 28(2) requires a strategy on ICT third-party risk including a policy on the use of ICT services supporting critical or important functions, with Delegated Regulation (EU) 2024/1773 on its content. Article 30 lists the clauses every contract must carry, with more required where the service supports a critical or important function. Article 28(8) adds exit strategies for those services.
Article 24(1) requires a testing programme from every financial entity other than microenterprises, and Article 25 covers the tests of tools and systems. Article 26 threat-led penetration testing is different: it binds only entities their competent authority has identified, and it is not a universal obligation however often it is presented as one.
Article 13(6) makes ICT security awareness programmes and digital operational resilience training compulsory modules in staff training schemes, applicable to all employees and to senior management. Combined with the Article 5(2) accountability of the management body, this is the part of the file that is easiest to produce and most often missing.
Supervisory practice differs between authorities, but the documents requested converge, because they are the ones the regulation names. The table below is the file to be able to produce without a scramble.
| Document | What makes it acceptable | Article |
|---|---|---|
| ICT risk management framework | Documented, board-approved, reviewed within the last twelve months, with the review trail visible | Art. 6(1), 6(5) |
| Register of information | Complete across all ICT contractual arrangements, in the Implementing Regulation (EU) 2024/2956 templates, reconcilable with procurement and the general ledger | Art. 28(3) |
| CIF inventory and mapping | Each critical or important function mapped to the systems and providers that support it, with the reasoning for the classification | Art. 3(22) |
| Third-party strategy and policy | Adopted and reviewed, covering ICT services that support critical or important functions | Art. 28(2) |
| Contracts and exit strategies | Article 30 clauses present, and exit strategies in place for CIF-supporting services | Art. 30, Art. 28(8) |
| Incident process and evidence | Classification criteria applied consistently, with the notifications actually sent and their timestamps | Art. 17 to 19 |
| Testing programme and results | A programme, not a set of ad hoc tests, with findings tracked to closure | Art. 24, Art. 25 |
| Continuity and recovery documentation | Continuity policy, backup and restoration procedures, recovery objectives that have been tested | Art. 11, Art. 12 |
| Training records | Awareness and resilience training delivered as compulsory modules, covering staff and senior management | Art. 13(6) |
| Board minutes | Evidence that the management body approved the framework and received reporting on it | Art. 5(2) |
On penalties, the regulation does something people find surprising: Article 50 leaves administrative penalties to Member State law rather than setting a European ceiling for financial entities. What you are exposed to therefore depends on your national regime, which is set out in the enforcement guide.
Any single figure quoted for this is wrong, because the two things that drive it are specific to you: how many critical or important functions you have, and how many ICT contractual arrangements support them. A payment institution with eleven providers and two critical functions is a different programme from an insurer with four hundred contracts across three countries.
Rather than publish an average, we built the estimate from your own numbers. The cost calculator works from entity type, headcount and provider count. The resource estimator converts that into internal days by role. Both are free and neither asks for an email to show the result.
The item that always takes longer than planned is the register of information, and not for technical reasons. Article 28(3) wants every contractual arrangement on the use of ICT services, which means reconciling procurement records, legal files and what teams are actually using. Starting it late is the single most common reason a programme slips, because the register also feeds the CIF mapping and the contract remediation.
All three work, and the honest answer depends on the size of the register rather than on anyone's preference.
| Approach | Where it holds | Where it breaks |
|---|---|---|
| Spreadsheets and documents | A small register, a single entity, one annual submission cycle. The Implementing Regulation templates are spreadsheets, so this is not a workaround | Group structures, versioning, and the moment two people maintain the same register |
| Your existing GRC platform | You already have one, and the control framework and audit trail are reusable | The Register of Information taxonomy rarely fits a generic data model, so you end up with a parallel spreadsheet anyway |
| Specialised DORA software | Large or multi-entity registers, recurring submission, contract and incident workflow in one place | Cost, and procurement time you may not have before the next submission |
If you are evaluating the third option, the software page sets out the modules to ask about and the five criteria that separate a DORA platform from a generic GRC tool with a DORA label. If you want to produce the submission file without buying anything, the register builder validates against the taxonomy and exports what your authority expects.
The framework is the same for everyone. What changes is which functions are critical or important, which providers concentrate your risk, and which authority supervises you. These pages start from the sector rather than from the regulation.
Five things come back repeatedly, and none of them is a technical control.
Two of the five are documentation problems rather than resilience problems, which is good news: they are the cheapest to fix. The audit preparation page goes through the review itself, and the gap analysis covers the same ground item by item.
If you have ten minutes, settle scope and get a score. If you have a day, work the checklist and the gap analysis. If the register is the problem, start there: everything else depends on it.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.