How Long Does DORA Readiness Take?

The question has a trap in it. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025, and the Central Bank of Ireland's DORA FAQ says the rest in one sentence: "DORA does not provide for a transitional period." So as of August 2026 there is no readiness deadline to work back from, which is a different situation from every other timeline question on this site. What sets the duration instead is a set of recurring clocks the regulation runs regardless of when you started, and a short list of workstreams whose lead time belongs to someone else: your vendors, your competent authority, and the LEI issuers. The same FAQ tells you what the supervisor is measuring in the meantime. Gaps identified in 2025 "should now be substantially addressed", and the Central Bank will assess "the quality of their approach to addressing any gaps and their ongoing track record of the timely closing of any remaining gaps." Track record is a duration word. It means the timeline is judged, not granted.

What follows is the calendar DORA runs on its own, the four situations in which someone is asking this question in 2026 and how the answer differs for each, the workstreams that cannot be compressed by hiring more people, and the case for a smaller project than the one being proposed to you.

Key takeaways

• DORA has applied since 17 January 2025 and provides no transitional period, so a readiness plan started now is closing gaps under supervision rather than working toward a deadline.
• The regulation runs its own clocks: an ICT risk management framework review at least once a year, a register of information snapshot at 31 December reported by 31 March, annual business continuity testing, and a three-year norm for threat-led testing where it is required.
• Four readers ask this question for four different reasons, and a newly authorised entity, an entity still closing 2025 gaps, a vendor holding an addendum and a group adding an EU entity each get a different timeline.
• The workstreams that set the critical path have external lead times: LEIs for every entity in scope, contract remediation across the vendor population, independent testers, and the supervisory correspondence itself.
• If you already run a serious vendor risk programme and hold a current assurance report, the honest scope is weeks of mapping plus a handful of genuinely new artifacts, not a programme.

The calendar DORA runs whether or not you are ready

DORA's obligations are not a one-time bar to clear. Several of them recur, and the recurrence is what turns "how long" into "how long until the next one". These are the cadences stated by two competent authorities, the ESAs and the ECB.

Two things follow from reading that as a calendar rather than a checklist.

First, the annual review under Article 6(5) is where the supervisor will look for evidence of the "track record" the Central Bank describes. Its FAQ says that, DORA having "now been in full application for more than one year", the Central Bank expects entities to "readily be able to share a copy of their individual reports on the review of the ICT risk management framework required to be completed annually". A readiness project that has not yet produced one of those reports is, from the supervisor's side of the table, a project with no track record at all. Producing the first one is the earliest meaningful milestone, and it is a document you can date.

Second, the register is a snapshot with a fixed reference date. The ESAs' decision on reporting for the designation of critical providers sets the reference date at 31 December of the preceding calendar year and the submission from competent authorities to the ESAs by 31 March; the 30 April 2025 deadline most summaries quote was a derogation for the first submission only, with a 31 March 2025 reference date. So whatever your start date, the register has to be right as at the next year end, and your competent authority has to collect your file in time to submit its own by 31 March, so the national deadline it sets sits ahead of that date. The register of information article covers what the fourteen tables contain and where submissions break; the point here is only that the year-end snapshot is the first hard external date on any DORA readiness plan started in the second half of a year.

Four readers, four timelines

"How long does DORA readiness take" is asked by four different people in 2026, and giving them one number would be wrong for at least three of them.

The newly authorised entity. A payment institution, e-money institution or investment firm that received its EU authorisation after January 2025 is in scope from the day it is authorised, with no transitional period of its own. Its timeline is set by the recurring clocks above: the first annual framework review, the first year-end register snapshot, the first annual business continuity test. The useful framing is not "when will we be compliant" but "which of DORA's annual artifacts will exist at the next reference date". Whether DORA applies to you at all is the prior question, and for an authorised entity the answer is short.

The entity still closing 2025 gaps. This is the reader the Central Bank's FAQ is addressed to. The expectation stated there is that in 2025 entities "should have put in place a purposeful approach and clearly and comprehensively identify gaps to compliance", and that those gaps "should now be substantially addressed". The FAQ also names where the effort has been heaviest for entities that had less sectoral regulation before DORA: advanced threat-led penetration testing, a comprehensive ICT third-party risk management framework, and registers of information. For this reader the timeline is a remediation plan with dated milestones the supervisor can read, and the shape of the assessment is explicitly the quality of the approach and the track record of closing what remains.

The vendor holding an addendum. A technology provider is not a financial entity and carries none of the recurring clocks. Its timeline is the customer's signature deadline, and the work is the gap between what the addendum asks for and what the vendor can evidence today. What a DORA addendum actually asks you to sign is the clause-by-clause read; the duration question is answered by listing the terms with no artifact behind them, which in practice is a handful of items rather than a programme.

The group adding an EU entity. A non-EU group acquiring or establishing an EU-authorised subsidiary inherits the entity-level obligations for that subsidiary and, depending on where the parent sits, may be reported entity by entity rather than as a consolidated file. The long pole here is master data: every financial entity in scope needs a valid LEI, and the register joins on it. That is the one item on this page with a lead time no consultancy can shorten, because it is an external issuance process.

What actually sets the critical path

A readiness plan can be staffed, but four of its workstreams have lead times that do not respond to staffing.

Identifiers. The register of information requires the LEI for financial entities and a consistent identifier for every provider and every parent undertaking. Obtaining or renewing an LEI is an external process, and it has to be done for every entity inside the scope of the register before the year-end snapshot, not after.

Contract remediation. The Article 30 terms have to be in every ICT contract, and the enhanced set has to be in every contract supporting a critical or important function. That is a renegotiation across a vendor population, at the vendors' pace, one signature at a time. The number of contracts and the number of vendors that push back set this duration, and the function determination for each contract has to be made before the negotiation starts, because it decides which set applies.

Independent testing. The testing programme needs testers without conflicts of interest, and where an entity has been identified for threat-led testing, the process runs under the competent authority with the ECB describing three-year intervals as the norm. Does DORA require threat-led penetration testing covers who is identified and how; the timeline consequence is that TLPT is not something you schedule, it is something you are scheduled for, and the Central Bank runs its identification exercise annually.

Supervisory correspondence. Your competent authority sets the level it expects your register at, the national deadline that precedes the ESAs' 31 March, and its own expectations on the annual review report. One written question to the authority at the start of the plan removes the most expensive class of rework, and the answer arrives on the authority's clock.

The incident reporting clocks are deliberately not on this list. They are regulatory deadlines that run from the moment an incident is classified, not project durations, and the DORA incident reporting article owns them. What belongs on a readiness plan is the classification worksheet and the rehearsed template that make those clocks achievable, and that is days of work rather than months.

The case for a smaller project

Here is the part that costs us engagements.

If you hold a current SOC 2 Type II report or an ISO 27001 certificate, a good deal of the control evidence DORA's framework asks for exists already, and the honest first step is a mapping exercise rather than a programme. What is usually genuinely missing is narrower than the fear: the register in its fourteen-table shape, the function-level criticality assessments with their recovery objectives, the documented exit strategies, the annual review report in the form the RTS specifies, and the contract terms. Those are real deliverables with real lead times, and they are a list, not a transformation.

If you are a single authorised entity with a contract population in the tens and a supervisor that has told you the level and deadline it expects, the register is a competent internal project and the money is better spent getting the LEIs issued. The ESAs publish the templates, the validation rules and the FAQ.

And if the real blocker is that nobody has decided which functions are critical or important, no timeline is honest until someone does. That is a governance decision, it gates the contract work and the register alike, and buying a readiness engagement before it is made produces a well-formed plan built on contested judgments.

Where Top Floor fits

Our DORA practice builds the pieces that have lead times: the criticality assessments and recovery objectives the register depends on, the identifier remediation, the contract review across the vendor population with the function determination made first, the testing programme with the independence the regulation requires, and the annual review report in the shape the RTS asks for, so the supervisor's first request for it has an answer. Where the exposure runs wider, because you are authorised in several jurisdictions or answering NIS2 and DORA from one control environment, that is international compliance work scoped as one programme. Where the recurring clocks are the problem, because the annual review, the year-end snapshot and the annual tests keep arriving with nobody owning them, compliance as a service is the honest answer, and it is a standing function rather than a project.

We do not designate anyone for threat-led testing, we do not set your national deadline, and we will say in the first meeting when a mapping exercise is all you need.

How to decide this week

Write down the next four dates DORA hands you: the year-end register reference date, your national submission deadline that precedes 31 March, the date of your next annual framework review, and the date of your last business continuity test plus one year. If any of the four has no owner, you have found the project.

Then check the LEI of every financial entity in scope. It is the item with the longest external lead time and the least glamour, and it is the one the supervisor's validation checks first.

Then ask your competent authority, in writing, which level it expects your register at and by when, and whether it wants to see your annual review report. The answers set your calendar better than any consultant can.

Frequently asked questions

Is there a grace period for DORA compliance?

No. DORA has applied since 17 January 2025, and the Central Bank of Ireland's FAQ states that "DORA does not provide for a transitional period." Supervisors have said what they expect instead: gaps identified in 2025 should now be substantially addressed, and the assessment is of the quality of an entity's approach and its track record in closing what remains. A readiness plan started in 2026 is therefore a supervised remediation plan, and its milestones should be written to be read by a supervisor.

What are the recurring deadlines under DORA?

The ones stated by competent authorities and the ESAs are an ICT risk management framework review at least once a year with a report whose contents the RTS specifies, an annual risk assessment of legacy ICT systems, annual testing of ICT business continuity plans and on any significant change to systems supporting critical or important functions, an annual report to the management body on findings from incidents and tests, and a register of information with a 31 December reference date submitted by competent authorities to the ESAs by 31 March. Threat-led penetration testing, for entities identified by their authority, follows the ECB's TIBER-EU norm of three-year intervals.

How long does it take to build the DORA register of information?

The duration is set by two things no consultancy controls: how many legal entities and contracts sit in scope, and how long it takes to obtain valid LEIs for every financial entity in it. The register is a snapshot as at 31 December, so the practical question is whether the entities, identifiers, function assessments and contract records will be right by the next year end. Firms already running a serious vendor risk programme find it mostly a reformatting exercise; firms whose third-party process is a procurement workflow find it asking for the underlying risk judgments for the first time.

Does a SOC 2 report or ISO 27001 certificate shorten DORA readiness?

Considerably, for the control evidence, and not at all for the artifacts that are specific to DORA. The access, change, logging and vendor management evidence behind a SOC 2 Type II report or an ISO 27001 management system covers much of what the ICT risk management framework asks about, so the first step should be a mapping rather than a rebuild. What it does not produce is the fourteen-table register, the function-level criticality and recovery assessments, the documented exit strategies, the Article 30 contract terms or the annual review report, and those are what a readiness plan is actually scheduling.