TL;DR
DORA’s regulatory ecosystem spans 27+ documents across Level 1 legislation, Level 2 RTS/ITS, and Level 3 guidelines — scattered across EUR-Lex, EBA, ESMA, EIOPA, and ECB portals.
doralib.fromciso.com is a free, searchable index that centralises all of them with filtering by category, keyword search, and a capability map view.
This guide walks through five real compliance scenarios where the library saves time: gap assessments, incident reporting setup, contract reviews, audit evidence, and TLPT preparation.
Includes a quick-reference checklist: which DORA documents you actually need, by pillar.
The library is a research accelerator, not legal advice. Always validate applicability with your Legal and Compliance stakeholders.
Last quarter, a compliance lead at a mid-sized EMI asked me a simple question: “Where’s the final version of the DORA incident reporting RTS?”
She’d been looking for twenty minutes. She had three browser tabs open — EUR-Lex, the EBA website, and a Google search that kept returning the 2023 consultation draft instead of the adopted version (RTS 2025/301). Her legal team had sent her a different link the week before. Neither of them was sure they were reading the current text.
This is a compliance professional. She knows what she’s looking for. The problem isn’t knowledge — it’s that DORA’s regulatory sources are scattered across at least five EU institutional portals, published on different dates, with confusing version histories. And the documents themselves don’t make it easy: “Commission Delegated Regulation (EU) 2024/2956” doesn’t exactly roll off the tongue when you’re trying to explain to Procurement what the Register of Information template requires.
I built doralib.fromciso.com to fix that specific problem. Not a content library. Not a compliance platform. Just a fast, searchable index of every DORA regulatory source, organised so you can find the right document in under 30 seconds instead of twenty minutes.
Here’s how to get the most out of it.
What’s actually in the DORA regulatory ecosystem (and why it’s hard to navigate)
Before the “how-to” part, some context on why a library like this is necessary.
DORA (Regulation (EU) 2022/2554) entered into force on 17 January 2025. But the regulation itself — the Level 1 text — is just the framework. The operational detail lives in a growing set of Level 2 technical standards and Level 3 guidelines developed by the European Supervisory Authorities (ESAs: EBA, EIOPA, and ESMA).
As of early 2026, the DORA ecosystem includes roughly 27 documents:
2 Level 1 texts — the core DORA regulation and the amending directive
~8 RTS (Regulatory Technical Standards) — defining what “good” looks like for ICT risk management, incident classification, third-party contractual policies, TLPT methodology, and subcontracting
~3 ITS (Implementing Technical Standards) — standard templates and forms for incident reporting, the Register of Information, and related submissions
Guidelines, opinions, and supporting reports — from the ESAs, ECB, and ENISA, covering everything from oversight cooperation to the TIBER-EU framework alignment
These documents were published in batches across 2023–2025. Some went through multiple consultation rounds. The subcontracting RTS (2025/532) was adopted as late as March 2025 after the European Commission removed a provision that exceeded the original mandate. New guidance continues to appear.
The practical problem: if you’re building a DORA control framework, writing policies, or preparing for an audit, you need to reference the right version of the right document — and the EU portals don’t make that easy. EUR-Lex has the legal text but no operational context. The ESAs publish final reports alongside the standards, but on separate pages. Google returns consultation drafts mixed with final versions.
DORA isn’t one PDF. It’s an ecosystem of 27+ documents, published across five portals, over three years. If you’re not sure you’re reading the current version, you’re not alone.
How to use doralib.fromciso.com in your workflow
The library is at doralib.fromciso.com. No login, no paywall, no email gate. Bookmark it and share the link with your team — consistency in sources matters more than most people realise.
Here are five ways I use it (and recommend clients use it) in real DORA work.
1. Running a DORA gap assessment
When you start a gap assessment, you need to know which documents define the requirements for each DORA pillar. The library’s category filter (Regulation / RTS / ITS / Reports & Opinions) lets you pull up just the Level 2 standards relevant to your scope.
How I do it: I filter by RTS, scan the titles, and map each one to a DORA pillar in my assessment template. For ICT risk management alone, the relevant RTS prescribes 20 policies and procedures. I learned this the hard way — my first DORA gap assessment was scoped entirely from the Level 1 text, and I missed about half the required controls. The Level 2 detail is where the real implementation effort hides.
If you’re building a gap assessment from scratch, I wrote a step-by-step DORA compliance roadmap that walks through the full process, starting with governance and ownership.
Start your gap assessment from the RTS, not the regulation. The Level 1 text tells you what to do. The RTS tells you how much — and that’s where most teams underestimate the work.
2. Setting up incident reporting
Incident reporting is where DORA gets operationally demanding. The reporting timeline is tight — initial notification within 4 hours for major incidents, intermediate report within 72 hours, final report within one month. The classification criteria use six dimensions (clients affected, duration, geographic spread, data losses, economic impact, criticality of services).
The library groups the incident-related documents together:
RTS 2025/301 — content and timelines for incident reports
ITS 2025/302 — the actual templates and forms
The incident classification RTS — how to determine if an incident is “major”
The ESA final report (JC 2023 83) — the rationale and worked examples behind the classification thresholds
Most teams I work with start by reading the regulation text (Article 19), then try to build their own reporting templates from scratch. One fintech client spent three weeks designing custom forms before discovering that the ITS provides standard templates. Three weeks of wasted work. The library links the RTS, ITS, and supporting report together so you can pull up all three in one search instead of navigating three separate ESA publication pages.
3. Reviewing vendor contracts for DORA compliance
Third-party risk management (DORA Articles 28–30) requires specific contractual clauses: audit rights, data location provisions, exit strategies, subcontracting controls, and service level descriptions. The RTS on contractual policies adds detail. The subcontracting RTS (2025/532), adopted in March 2025, adds further constraints on how ICT services supporting critical functions can be subcontracted.
How I use the library here: Before a contract review session with Legal and Procurement, I pull up the relevant RTS entries and share direct links. In a recent contract renegotiation with a cloud infrastructure provider, linking directly to Section 3 of the contractual policy RTS cut the back-and-forth from three review rounds to one — because everyone was reading the same text, not paraphrasing from memory.
When Legal, Procurement, and Security work from the same source links, the debate shifts from “which version are we reading?” to “how do we implement this clause?” That’s a better use of everyone’s time. For more on the vendor side of DORA compliance, I covered the CTO-CISO coordination model for vendor oversight in a separate piece.
4. Building audit evidence packs
Auditors want to see that your controls trace back to regulatory requirements. The library helps you build a “Regulatory Sources” appendix in your evidence pack — a list of which documents you referenced, which version, and where the specific expectation comes from.
How I did it last quarter: When I built an evidence pack for a PI client’s first DORA readiness review, the “Regulatory Sources” appendix took me about 15 minutes to compile. For an ICT risk management control like “annual risk assessment,” the appendix referenced:
DORA Article 6 (Level 1 requirement)
The ICT Risk Management RTS (Level 2 detail on what the assessment must cover)
The ESA final report explaining the regulatory rationale
Each entry included a library link. The auditor later told me this was the first evidence pack they’d reviewed where every regulatory reference was a working link to the current version. That shouldn’t be unusual, but it is.
5. Preparing for threat-led penetration testing (TLPT)
TLPT is the most operationally complex DORA requirement. Significant financial entities must complete their first TLPT exercise before 17 January 2028, with ongoing tests every three years thereafter.
I’ve started scoping TLPT for two significant entities this year. The first thing you discover is that the documentation is split between multiple institutions — the ESAs, the ECB, and the Official Journal — each publishing different parts of the puzzle. The library connects all three key documents:
RTS 2025/1190 — scope, methodology, and assessor criteria for TLPT
The TIBER-EU framework (updated by the Eurosystem in February 2025) — detailed phase-by-phase guidance for what is typically a 9–14 month process
The ESA final report on TLPT — regulatory rationale and expectations
Having all three accessible from one place — instead of navigating the ECB publications page, the Official Journal, and the ESA reports separately — saves real time during scoping. For entities tracking the relevant resilience KPIs, the TLPT section of the library maps directly to your testing pillar metrics.
The DORA Capability Map
The library includes what I call the DORA Capability Map — a view that organises documents by operational pillar rather than document type.
This matters because DORA programs are usually structured around capabilities (ICT risk management, incident reporting, third-party risk, resilience testing, information sharing), not around document categories. The capability map lets you:
Assign document ownership — “Who in the team is responsible for the incident reporting pillar? Here are the four documents they need to know.”
Spot coverage gaps — if your implementation backlog doesn’t have work items for TLPT, the capability map makes that visible immediately.
Structure steering committee updates — report progress by capability area, with links to the relevant standards for each.
If you take one thing from this guide: organise your DORA program by capability, not by document type. The DORA Capability Map is there to make that easier.
Quick reference: which documents do you actually need?
Not every entity needs every document. Here’s a checklist by DORA pillar — find your scope, pull the relevant entries from the library, and ignore the rest.
ICT Risk Management (all entities)
Core DORA regulation (Articles 5–16)
ICT Risk Management RTS (full or simplified framework)
ESA final report on ICT Risk Management (JC 2023 86) — for rationale and interpretation
Incident Reporting (all entities)
Incident Classification RTS — the 6 criteria for “major” incidents
RTS 2025/301 — reporting content and timelines
ITS 2025/302 — standard templates and forms
ESA final report (JC 2023 83) — worked examples and thresholds
Third-Party Risk Management (all entities with ICT outsourcing)
Contractual Policy RTS — 8 mandatory clauses
Subcontracting RTS (2025/532) — constraints on sub-outsourcing critical functions
Register of Information ITS (2024/2956) — templates for the mandatory ICT provider register
Resilience Testing (all entities; TLPT for significant entities only)
RTS 2025/1190 — TLPT scope and methodology
TIBER-EU framework (updated Feb 2025) — phase-by-phase guidance
ESA final report on TLPT — regulatory expectations
Oversight & Cooperation (awareness — primarily for entities with designated CTPPs)
Oversight Harmonisation RTS — conditions for oversight activities
ESA Guidelines on cooperation and information exchange
Use this checklist to build your initial reading list. Then link the relevant library entries to your controls, your evidence, and your steering committee slides. Consistency in sources across Legal, Risk, IT, and Procurement is half the battle.
What this isn’t
A library speeds up research, but it doesn’t replace governance, gap analysis, or the hard operational work of implementing controls. It indexes regulatory sources — it doesn’t interpret them. Always validate applicability with your Legal and Compliance teams for your specific entity type, jurisdiction, and operating model. And check your document versions — the DORA ecosystem is still developing, with new ESA guidance arriving periodically.
Where to start
If you’re early in your DORA program:
Bookmark doralib.fromciso.com. Share the link with Legal, Risk, IT, and Procurement — get everyone on the same reference point.
Use the capability map to identify which documents are relevant to your entity type and operating model.
Start your gap assessment from the RTS, not the regulation. The Level 2 detail is where most of the implementation effort hides.
If you’re mid-program:
Link the relevant library entries to your controls and evidence packs.
Use direct document links in audit responses to reduce back-and-forth on “which version are you referencing?”
Check the TLPT and subcontracting sections — these are the most recent additions and often the least mature in existing programs.
Open the DORA Documents Library →
Which DORA pillar is giving your team the most trouble right now? Tell me in the comments — I read every reply.