DORA Compliance Roadmap: Six-Stage Implementation Plan 2026

Before sequencing implementation work, it helps to know what examiners are actually checking. Based on supervisory communications and enforcement activity through the first half of 2026, four areas are drawing the most scrutiny.

The enforcement escalation ladder shapes where to focus first. National competent authorities progress through a desk review and data request, a supervisory letter with a three to six month remediation window, an on-site inspection reserved for significant institutions or material gaps, a formal remediation order, a daily compulsion payment and, eventually, an administrative fine or public censure.

Article 50 sets the EU ceiling for financial entities at 2% of total annual worldwide turnover or €10 million, whichever is higher, with individual management body members personally liable for up to €1 million. Article 50 leaves the actual penalty regime to national law, though, and the divergence between member states is real: Italy's ceiling reaches €20 million or 10% of annual turnover, while Ireland allows up to €10 million or 10% of turnover, according to DLA Piper's analysis of DORA penalty regimes. Critical ICT third-party providers face a separate regime of up to €5 million plus 1% of average daily worldwide turnover for each day of non-compliance.

The third-party dimension became concrete in November 2025, when the ESAs designated the first 19 Critical ICT Third-Party Providers, including AWS, Microsoft, Google Cloud, Oracle, SAP and IBM. Designated providers now answer directly to an ESA Lead Overseer, and financial entities that depend on them face closer scrutiny of their own Article 30 contracts and exit planning. SureCloud's DORA Critical ICT Third-Party Providers guide covers what that means for contract terms in detail.

The Register of Information and incident reporting remain the two areas most likely to trigger a supervisory letter today. That's why the roadmap below tackles them inside the first three stages.

Use these six stages as a repeatable implementation plan. Each stage has defined inputs, work to complete and a checklist so your team knows what “done” looks like. Run them in sequence for the first cycle, then loop through them annually.

Stage 1: Assess and Inventory

The goal is a single, accurate picture of critical business services, systems, data and third parties, because risk management, testing and incident processes can only attach to reality if the register reflects it. Build one consolidated register keyed by business service, with owners, criticality ratings, recovery targets and CTPP flags, then map supply-chain dependencies including subcontractors and concentration points.

1. Services, systems, data and vendors captured in a single register
2. Owners and criticality assigned and visible
3. CTPPs and subcontractors flagged consistently, including cloud providers and data analytics firms
4. Recovery time and recovery point targets captured for critical services

Supervisors' first wave of reviews found systemic gaps in ICT third-party registers, particularly missing sub-contracting chain and data residency fields, and incomplete registers have triggered formal letters requiring remediation within 60 days. Treat the register as a living document that needs a named owner well past go-live.

Stage 2: Build Governance and the Control Framework

This stage defines how DORA runs day to day: roles, committees, policies and a control library, so everyone knows who does what and which controls prove compliance. Securing management body approval for the ICT risk management framework is a board-level obligation under DORA Article 5 and Article 6, owned by the management body itself; SureCloud's DORA ICT risk management framework board approval guide sets out what that approval needs to cover. Establish evidence cadences and an exceptions process too, so findings keep moving once they're logged.

Cross-map the control library to ISO/IEC 27001 and NIS2 as you build it. Firms using SureCloud's Continuous Controls Monitoring capability, built on the 10-in-1 SureCloud Controls Framework, test a control once and reuse the evidence across every framework that shares it, cutting audit preparation time by 75%.

Stage 3: Map Risk Management and Testing

Run risk and testing as a closed loop: assess, test, fix and retest, while keeping proof current. Establish baseline testing calendars across access controls, backup and restore, logging, change management, vulnerability scanning and continuity scenarios, and track findings, fixes and retests on one plan so nothing goes stale.

For entities likely to be designated significant, TLPT planning needs to start now. The TLPT Regulatory Technical Standard (Commission Delegated Regulation (EU) 2025/1190) became directly applicable on 8 July 2025 and points to the TIBER-EU methodology. The first mandatory cycle is due by 17 January 2028, and a full cycle runs around six months from provider procurement to certification, so scoping by mid-2026 and selecting a TIBER-EU qualified provider in the second half of 2026 is mandatory if you're in scope.

A finding only closes once there's evidence of the retest alongside it, and supervisors check for both. That discipline in testing is the same one incident reporting depends on, which is where Stage 4 picks up.

Stage 4: Align Incident Reporting to RTS/ITS

Make incident reporting accurate and on time. The RTS 2025/301 and ITS 2025/302 standards, published on 20 February 2025, define the exact fields, clocks and templates your intake forms and response tooling need to mirror. The first 24 to 72 hours of a major incident should run on rehearsed, practised process.

1. Initial notification within 4 business hours of classification, and no later than 24 hours from detection
2. Intermediate report at 72 hours, with root cause analysis included from the outset
3. Final report within one month, plus a model evidence pack drafted and drilled before an incident happens

Several investment firms have already had initial notifications rejected for landing outside the 4-business-hour window, and intermediate reports flagged for missing root cause analysis. SureCloud's DORA Incident Response Governance guide sets out how to build forms that capture every RTS/ITS field at intake, so nothing needs reconstructing under pressure.

Stage 5: Strengthen Third-Party and CTPP Oversight

Prove shared accountability with critical suppliers through contracts, evidence and exit options, so risk keeps moving through the supply chain. Add flow-down clauses for incident cooperation, drill participation, reporting timelines, artefact delivery and right-to-audit, and set a supplier evidence calendar with a named owner and an automated collection cadence.

The subcontracting RTS (Commission Delegated Regulation (EU) 2025/532) was published in the Official Journal on 2 July 2025 and entered into force on 22 July 2025, specifying what a financial entity must assess before subcontracting ICT services that support critical or important functions. With 19 CTPPs now under direct ESA oversight, document and test exit and substitution plans for high-exposure services now, before a lead overseer asks for one.

Stage 6: Prove and Improve

Make evidence and improvement the default operating mode, so audits and supervisory reviews stay repeatable and fast. Produce a consolidated DORA programme pack for leadership and regulators covering coverage status, open exceptions, test results and incident history, and trend time-to-fix and time-to-retest so progress is visible and evidenced over time.

Board reporting built this way compounds: SureCloud customers report a 90% improvement in the time it takes to turn platform data into a board-ready pack, so progress stays visible and evidenced over time. Fold lessons from incidents and tests back into the Stage 1 register, and the loop is ready to run again next quarter.

Use this timeline to align regulatory milestones with your internal planning cycle. The dates below are fixed; the internal checkpoints are your responsibility to set.

The Register of Information deadline moved earlier for the 2026 cycle. Luxembourg's CSSF, for example, set its submission window between 11 February and 31 March 2026, which the CSSF's published submission notice. Check your own NCA’s current notice for the live window; the original 30 April 2025 date applied only to the first submission cycle.

Different organisations move at different speeds. SMEs with a well-scoped programme reach a steady cadence in 3 to 6 months: register and owners in the first 30 days, baseline tests and a drafted incident evidence pack by day 90, and a closed first test cycle with a leadership-ready programme pack by day 180.

Enterprises take 6 to 9 months, because consolidating registers and dependency maps across divisions, standardising incident forms across geographies, and running supplier flow-down at scale simply takes longer. TLPT sits on its own clock either way, set entirely by the competent authority.

The most common mistake at both scales is treating Stage 1 as a one-off exercise. Supervisors run automated queries against submitted register data, so a register that drifts between annual updates creates exactly the inconsistency that triggers a desk review.

A roadmap without an operating rhythm stalls after the first cycle. Assign a programme owner or steering forum for overall accountability, control owners for testing and exception triage, an incident commander for classification decisions and reporting-clock management, supplier managers for flow-down obligations, and an internal audit liaison for independence checks.

1. Monthly: control status review, supplier artefact review, incident log review for classification accuracy
2. Quarterly: retest closure check, leadership report, review of new RTS/ITS guidance or NCA communications
3. Annually: programme refresh, TLPT readiness check, and the Register of Information update

None of these cadences work if they live in someone's head. Put them on a shared calendar with named owners before the programme goes live.

Each of the following has cost real teams months of remediation. They're avoidable, and they tend to repeat across organisations of every size.

1. Parallel inventories that never reconcile: One register, one control library, no exceptions.
2. Tests without retests: A finding only closes once there's evidence of the retest alongside it, and supervisors check for both.
3. Incident forms that don't match RTS/ITS fields: Rebuilding a submission from incomplete intake data mid-incident is a compliance failure waiting to happen.
4. Vendor artefacts without a cadence or owner: A supplier evidence calendar nobody is responsible for chasing is decoration.
5. No tested exit plan for a critical supplier: Article 28 requires documented exit strategies, and supervisors ask to see them in practice.

Run through this list before your next internal review, and you'll catch most of what turns a routine desk review into a formal remediation order. Gracie AI Agents with Personas and Skills can run that check continuously across your register, control library and supplier calendar, surfacing drift before an examiner does. See how it works below, or explore SureCloud's DORA resource hub for guides on each stage in more depth.