DORA's First Annual Cycle Just Closed: What Must Financial Entities Submit Now?

DORA (Regulation (EU) 2022/2554) entered application on 17 January 2025. The first full annual cycle has now run its course.

That changes the question for compliance officers. The work is no longer "are we DORA-ready." The work is "what do we submit, and can we defend each line of it against the source text."

This piece walks the closeout obligations that come due at the end of an annual cycle: the ICT third-party register, the yearly report to competent authorities, threat-led penetration testing planning, and the supervisory posture of the lead overseer. Every claim below traces to a parsed DORA article.

What did DORA's first full annual cycle actually require entities to close out?

DORA does not run on a single deadline. It runs on a set of recurring duties that compound across a year.

DORA requires financial entities to maintain a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system (Art. 6(1)).

That framework must be documented and reviewed at least once a year, and additionally upon the occurrence of major ICT-related incidents, and following supervisory instructions or conclusions from resilience testing or audit (Art. 6(5)). A report on that review must be submitted to the competent authority upon request.

ICT third-party risk is not a separate program. DORA obliges financial entities to manage ICT third-party risk as an integral component of ICT risk within that same framework (Art. 28(1)).

So the closeout of year one bundles three threads:

The framework review, due at least yearly under Art. 6(5).

The ICT third-party register and its yearly report to competent authorities under Art. 28(3).

TLPT planning, on the at-least-every-three-years cadence set in Art. 26(1).

The management body owns all of it. DORA requires the management body to define, approve, oversee and bear ultimate responsibility for the ICT risk management framework (Art. 5(2)). This is not a function you can fully delegate away.

What goes in the ICT third-party register, and how does a regulator read it?

The register of information is the spine of DORA's third-party regime.

DORA requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers (Art. 28(3)).

The contractual arrangements must be appropriately documented, distinguishing between those that cover ICT services supporting critical or important functions and those that do not (Art. 28(3)). That distinction is the load-bearing one. The whole supervisory machine sorts entries by whether they touch a critical or important function.

Then comes the reporting duty. DORA requires financial entities to report at least yearly to the competent authorities on the number of new arrangements on the use of ICT services, the categories of ICT third-party service providers, the type of contractual arrangements, and the ICT services and functions being provided (Art. 28(3)).

The register itself is provided on demand. DORA obliges financial entities to make available to the competent authority, upon request, the full register of information, or specified sections of it, along with any information needed for effective supervision (Art. 28(3)).

There is also a forward-looking notification. DORA requires financial entities to inform the competent authority in a timely manner about any planned contractual arrangement on the use of ICT services supporting critical or important functions, and when a function has become critical or important (Art. 28(3)).

How does a regulator read it. The ICT third-party register is the standardized template the ESAs were mandated to build. DORA tasked the ESAs, through the Joint Committee, with developing implementing technical standards establishing standard templates for the register, with submission to the Commission by 17 January 2024 (Art. 28(9)). The supervisor reads the register as a structured filing, not prose. Fields line up, or they do not.

And the register feeds the oversight tier. DORA requires competent authorities to transmit the Art. 28(3) yearly reports, on an aggregated basis, to the Oversight Forum, which assesses the ICT third-party dependencies of financial entities based on that information (Art. 31(10)). Your register entries roll up into the data that decides which providers get designated critical.

How does threat-led penetration testing (TLPT) planning fit the supervisory calendar?

Threat-led penetration testing is the advanced layer of DORA's resilience testing regime, and its calendar is multi-year.

DORA requires financial entities, other than those referred to in Art. 16(1) first subparagraph and other than microenterprises, that are identified by the competent authority, to carry out advanced testing by means of TLPT at least every three years (Art. 26(1)). Based on the entity's risk profile and operational circumstances, the competent authority may require that frequency to be reduced or increased.

Identification is supervisory, not self-selected. DORA requires competent authorities to identify the financial entities required to perform TLPT, based on impact-related factors, possible financial stability concerns, and the entity's specific ICT risk profile and maturity (Art. 26(8)).

The test runs against real systems. DORA requires each threat-led penetration test to cover several or all critical or important functions and to be performed on live production systems supporting those functions (Art. 26(2)). The entity assesses which critical or important functions the TLPT must cover, and that scope is validated by the competent authorities (Art. 26(2)).

Third parties are pulled into scope. Where ICT third-party service providers are included in the scope of the TLPT, DORA requires the financial entity to take the necessary measures to ensure their participation, while retaining full responsibility for compliance (Art. 26(3)). This is why the contractual layer matters: DORA requires contracts for critical-or-important functions to include the provider's obligation to participate and fully cooperate in the entity's TLPT under Articles 26 and 27 (Art. 30(3)(d)).

Closeout produces filings. At the end of testing, after reports and remediation plans are agreed, DORA requires the financial entity and, where applicable, the external testers to provide the authority with a summary of the relevant findings, the remediation plans, and documentation demonstrating the test was conducted to the requirements (Art. 26(6)). The authority then issues an attestation confirming the test met the requirements, to allow mutual recognition between competent authorities (Art. 26(7)).

For calendar planning this means the TLPT clock is rarely the same as the register clock. The register reports yearly; TLPT lands at least every three years on a scope the supervisor validates in advance. Treating both as one "annual scramble" is how scope slips.

What does 'live supervision' change about how lead overseers query your filings?

The oversight tier moved from setup to operation, and that changes the texture of supervision.

DORA tasks the ESAs, through the Joint Committee and on recommendation from the Oversight Forum, with designating the ICT third-party service providers that are critical for financial entities, and with appointing a Lead Overseer for each one (Art. 31(1)). The list of critical ICT third-party service providers is established, published and updated yearly at Union level (Art. 31(9)).

Once designated, a critical provider faces an annual oversight rhythm. DORA requires the Lead Overseer to adopt a clear, detailed and reasoned individual oversight plan describing the annual oversight objectives and main oversight actions for each critical provider, communicated yearly (Art. 33(4)).

The Lead Overseer's assessment is broad. It covers, among other areas, ICT security and continuity, physical security, ICT risk management processes, governance, incident reporting to financial entities, portability and interoperability mechanisms, testing, and ICT audits (Art. 33(3)).

And the information power is direct. DORA gives the Lead Overseer the power to request all relevant information and documentation from critical ICT third-party service providers (Art. 35(1)(a)), and to conduct general investigations and inspections (Art. 35(1)(b)).

What "live supervision" changes for you, the financial entity, is the directionality. The Lead Overseer queries the critical provider directly. But your register is the data that placed that provider on the critical list in the first place (Art. 31(10)). When your filing and the provider's reality diverge, the gap surfaces on the supervisory side, not yours. The defensible position is one where your register, your contracts, and the provider's oversight record describe the same arrangement.

Where do most financial entities fail the register-to-evidence trace?

The recurring failure is not a missing register. It is a register that does not trace to evidence.

The most common breaks:

The critical-or-important flag does not match the contract. DORA requires the register to distinguish arrangements supporting critical or important functions from those that do not (Art. 28(3)), and requires the enhanced contractual provisions of Art. 30(3), including TLPT participation and audit rights, precisely for those critical-or-important arrangements. A register row flagged critical whose contract lacks the Art. 30(3) clauses is an immediate trace failure.

The yearly report numbers do not reconcile to the register. The Art. 28(3) report covers new arrangements, provider categories, contract types, and services. If the count of new arrangements in the report does not reconcile against dated register entries, the supervisor sees an unreconciled filing.

Locations are undocumented. DORA requires contracts to specify the regions or countries where functions and services are provided and where data is processed, including storage location, with advance notice of changes (Art. 30(2)(b)). Registers that name a provider but not its processing locations cannot answer a concentration-risk query.

Planned critical arrangements were not pre-notified. DORA requires timely notification of any planned contractual arrangement supporting a critical or important function, and when a function becomes critical or important (Art. 28(3)). A critical arrangement that appears in the register without a corresponding prior notification is a gap with a timestamp.

The pattern underneath all four: the register is treated as a document assembled once a year, rather than a projection of facts that already live in the contracts, the scope decisions, and the function inventory. When the register is hand-assembled, it drifts from its own sources. The trace fails because the trace was never built.

How do you turn the DORA submission from a project into a standing query?

The fix is architectural, not clerical.

The register, the yearly report, the TLPT scope, and the framework review all draw from the same underlying facts: which providers you use, which functions are critical or important, what the contracts say, where data is processed. DORA itself treats them as one framework. Art. 28(1) places third-party risk inside the Art. 6(1) framework, and Art. 5(3) requires a role to monitor the ICT third-party arrangements.

If those facts live in one source-grounded model, every DORA artifact becomes a view over that model rather than a separate manual build.

This is the principle Aegis GRC is built on: answer once, assess everything. You record the underlying facts about your ICT estate and your third-party arrangements once. The ICT third-party register, the critical-or-important classification, the contractual-clause coverage check, and the TLPT scope inventory each render as a query against that single source. The audit pack is a query, not a project.

Because every requirement maps to the parsed source article, the trace is built in. No AI hallucinations, no invented article numbers. Each register field, each contractual obligation, each TLPT scoping decision points back to the DORA text that requires it. That is a posture you can defend in front of a regulator, a board, or a plaintiff.

For how this maps across the broader financial-services and third-party-risk obligations, see our work on DORA compliance, financial-services GRC, and third-party risk.

When DORA is one of 245+ regulations across 28 jurisdictions in the same model, the marginal cost of the next framework's filing collapses too. Answer once. Assess everything. See how at aegis-grc.com.

What should you fix before the next annual cycle opens?

Five concrete checks, each grounded in a DORA obligation:

Reconcile the register against the contracts. Every row flagged critical or important must have a contract carrying the Art. 30(3) provisions, including TLPT participation (Art. 30(3)(d)) and audit and access rights (Art. 30(3)(e)).

Reconcile the yearly report against the register. The Art. 28(3) report figures, new arrangements, provider categories, contract types, services, must tie back to dated register entries.

Confirm processing locations are captured. Every provider entry should carry the locations and data-processing and storage locations the contract is required to specify (Art. 30(2)(b)).

Confirm the framework review is documented and dated. DORA requires the at-least-yearly review under Art. 6(5), with a report available to the competent authority on request.

Confirm TLPT scope and cadence. If you are identified for TLPT, confirm the at-least-every-three-years cadence (Art. 26(1)), that scope covers critical or important functions on live production systems (Art. 26(2)), and that in-scope providers are contractually bound to participate (Art. 26(3), Art. 30(3)(d)).

Fix these as standing queries over one model, and next year's cycle stops being a project.

FAQ: DORA annual cycle, ICT register, and TLPT deadlines

How often must the ICT third-party register be reported to competent authorities? DORA requires financial entities to report at least yearly to the competent authorities on the number of new arrangements, the categories of ICT third-party service providers, the type of contractual arrangements, and the ICT services and functions provided (Art. 28(3)). The full register must also be made available on request.

How frequently is threat-led penetration testing required? DORA requires identified financial entities to carry out TLPT at least every three years, though the competent authority may reduce or increase that frequency based on the entity's risk profile and operational circumstances (Art. 26(1)). Entities are identified for TLPT by the competent authority (Art. 26(8)).

Who designates a critical ICT third-party service provider and appoints the lead overseer? The ESAs, through the Joint Committee and on recommendation from the Oversight Forum, designate critical ICT third-party service providers and appoint a Lead Overseer for each (Art. 31(1)). The list is published and updated yearly at Union level (Art. 31(9)).

Does outsourcing ICT services transfer DORA responsibility to the provider? No. DORA requires financial entities with contractual arrangements for ICT services to remain, at all times, fully responsible for compliance with and discharge of all obligations under the Regulation (Art. 28(1)(a)). Responsibility stays with the financial entity.