DORA entered application on 17 January 2025. A year on, most financial entities have a register of information and a testing programme. The harder question is whether either one is a living control surface or an artefact that gets rebuilt under deadline pressure every reporting cycle.
The register of information and threat-led penetration testing scope look like separate obligations. They are not. Both stand on the same foundation: an accurate, current map of which ICT third-party arrangements support which critical or important functions. Get that map wrong, and you fail twice — an incomplete register and a mis-scoped test.
This is the deep-dive a chief compliance officer or ICT risk lead needs after the first supervisory cycle: what the register must contain contract by contract, how the supervisory cycle turns it from a filing into continuous evidence, what falls inside TLPT scope, and why the two obligations share a single point of failure.
What did the first supervisory cycle actually surface?
DORA obliges financial entities to report to competent authorities at least yearly on their ICT third-party arrangements, and to make the full register of information available to the competent authority on request (Article 28(3)). The European Supervisory Authorities developed the standardised templates for that register through implementing technical standards, which DORA required them to submit to the Commission by 17 January 2024 (Article 28(9)).
The supervisory-cycle framing matters because the register is not a one-time submission. It is a structured dataset that authorities aggregate to assess sector-wide ICT third-party dependencies. Where the first wave of feedback has bitten, qualitatively, is on structural data quality rather than narrative gaps: inconsistent provider identification, arrangements that cannot be reliably linked to a named critical or important function, and registers that describe contracts as they were signed rather than as they operate today.
The lesson is not "fill in more fields." It is that the register is machine-read and cross-referenced. A register assembled by hand once a year drifts out of alignment with reality the moment a contract changes.
What does DORA require the register of information to contain, contract by contract?
DORA requires financial entities to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers, at entity level and, where relevant, at sub-consolidated and consolidated levels (Article 28(3)).
The register must be appropriately documented and must distinguish between arrangements that cover ICT services supporting critical or important functions and those that do not (Article 28(3)). That distinction is the spine of the whole framework. It decides which contracts carry the heavier obligations, which dependencies feed concentration-risk analysis, and which arrangements are candidates for TLPT scope.
DORA also obliges financial entities to inform the competent authority in a timely manner about any planned contractual arrangement on the use of ICT services supporting a critical or important function, and when a function has become critical or important (Article 28(3)). So the register is not only retrospective. It must reflect classification changes as they happen.
The contract terms the register has to be able to evidence
DORA requires the rights and obligations of the financial entity and the ICT third-party service provider to be clearly allocated and set out in writing, in a single complete document including the service level agreements (Article 30(1)). Every arrangement, critical or not, must include at least a clear description of the functions and ICT services provided, the locations where functions are performed and data is processed, provisions on availability, authenticity, integrity and confidentiality of data, service level descriptions, and termination rights with minimum notice periods (Article 30(2)).
For arrangements supporting critical or important functions, DORA requires more (Article 30(3)): full service level descriptions with precise quantitative and qualitative performance targets, reporting obligations on developments that could materially affect service delivery, requirements to implement and test business contingency plans, unrestricted rights of access, inspection and audit for the entity and the competent authority, defined exit strategies with a mandatory adequate transition period, and — directly tying the two halves of this article together — the obligation of the provider to participate and fully cooperate in the financial entity's TLPT (Article 30(3), point (d)).
A register that records "vendor name, service, critical: yes/no" is not enough to demonstrate any of this. The register has to be the index into the evidence that each of these contractual provisions actually exists for each critical-or-important arrangement.
How does the supervisory cycle turn the register from a filing into a continuous control surface?
DORA frames the register as an instrument of ongoing supervision, not an annual return. Financial entities must make the full register, or specified sections of it, available to the competent authority upon request, along with any information needed for effective supervision (Article 28(3)).
That single sentence changes the operating posture. "Upon request" means the register must be defensible at any moment, not just at the reporting date. The yearly report on new arrangements, provider categories and contract types (Article 28(3)) is the floor, not the ceiling.
There is a sector-level mechanism behind this too. Competent authorities transmit the reports on financial entities' ICT third-party arrangements to the Oversight Forum on a yearly, aggregated basis, and the Forum assesses ICT third-party dependencies of financial entities across the market (Article 31(10)). The aggregated dependency picture is what supports designation of critical ICT third-party service providers under the criteria in Article 31 — including systemic impact, the number of systemically important institutions relying on a provider, and the provider's degree of substitutability (Article 31(2)).
So your register feeds a Union-level concentration view. Sloppy entity-level data degrades the supervisory picture for the whole sector, which is exactly why data-quality feedback has been pointed.
What is threat-led penetration testing scope, and who falls in it?
DORA requires financial entities — other than microenterprises and certain entities under the simplified regime — that are identified by their competent authority to carry out advanced testing by means of threat-led penetration testing at least every three years (Article 26(1)). The competent authority may, based on the entity's risk profile and operational circumstances, require that frequency to be reduced or increased.
Competent authorities identify which financial entities must perform TLPT based on an assessment of impact-related factors (the extent to which the entity's activities affect the financial sector), possible financial-stability concerns including systemic character at Union or national level, and the entity's specific ICT risk profile and level of ICT maturity (Article 26(8)). After the first cycle, the answer to "are we in scope" is not a guess — it is a determination your competent authority makes against those criteria.
The scope of a TLPT is not arbitrary. DORA requires each threat-led penetration test to cover several or all of the entity's critical or important functions and to be performed on live production systems supporting those functions (Article 26(2)). The entity must identify all relevant underlying ICT systems, processes and technologies supporting critical or important functions — including those that have been outsourced or contracted to ICT third-party service providers — and must assess which critical or important functions need to be covered. That assessment determines the precise scope of the TLPT and is validated by the competent authority (Article 26(2)).
Where ICT third-party providers are in scope, DORA requires the financial entity to take the measures and safeguards needed to secure their participation, while retaining full responsibility for compliance (Article 26(3)). This is the mechanism behind the contractual TLPT-cooperation clause in Article 30(3). Where a provider's direct participation would adversely affect other customers outside DORA's scope, the regulation permits pooled testing across several financial entities served by the same provider (Article 26(4)).
This sits on top of the broader testing obligation. DORA also requires financial entities, other than microenterprises, to ensure at least yearly that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions (Article 24(6)), drawing on the methods listed in Article 25 such as vulnerability assessments, network security assessments, source code reviews where feasible, and penetration testing.
Why register completeness and TLPT scoping share one dependency map
Read Article 26(2) and Article 28(3) side by side and the overlap is unmistakable. The register must distinguish arrangements supporting critical or important functions. TLPT scope must cover the systems supporting critical or important functions, including those outsourced to ICT third-party providers. Both obligations resolve to the same question: which provider supports which critical or important function, today.
If your register misclassifies an arrangement as non-critical, that provider's systems drop out of the population you assess for TLPT scope. If a function silently becomes critical and the register is not updated, both the timely-notification obligation (Article 28(3)) and the TLPT scoping assessment (Article 26(2)) are wrong at the same time.
The concentration dimension binds them tighter still. DORA requires entities, before entering an arrangement supporting a critical or important function, to assess whether it would reinforce ICT concentration risk — including contracting a provider that is not easily substitutable, or holding multiple arrangements for critical functions with the same or closely connected providers (Articles 28(4) and 29). That substitutability and concentration analysis runs off the same dependency map. One map, three obligations: register classification, TLPT scoping, concentration assessment.
Where finserv teams fail: stale registers, untraceable mapping, and scope drift
Three failure modes recur, and all three trace back to treating the dependency map as a document rather than a query.
Stale registers. A register populated by spreadsheet export drifts the moment a contract is amended, a subcontractor changes, or a function is reclassified. DORA's "upon request" standard (Article 28(3)) does not accept "accurate as of last January."
Untraceable critical-function mapping. When an auditor asks why a given arrangement is marked non-critical — or why a system was excluded from TLPT scope — the answer must trace to the criticality assessment, not to institutional memory. Article 26(2) makes the scoping assessment an auditable artefact validated by the competent authority.
TLPT scope drift. Because TLPT runs at least every three years (Article 26(1)) while the business changes continuously, the function-to-system-to-provider map captured at the last test goes stale. New critical functions, migrated workloads, and added providers fall outside a scope frozen years earlier.
Every one of these is a synchronisation failure between living reality and a static snapshot.
How do you make the register a query instead of an annual reconstruction?
The fix is structural, not procedural. Stop maintaining the register, the TLPT scope, and the concentration analysis as three separate documents that each go stale on their own schedule. Maintain one source of truth — the function-to-system-to-provider dependency graph — and derive all three from it on demand.
When the critical-or-important classification of a function lives in one place, the register section that distinguishes critical arrangements is a query against it. The population of systems for TLPT scoping is a query against it. The substitutability and multi-arrangement concentration view is a query against it. Update the graph once, and every downstream artefact reflects the change.
That is the difference between an audit project and a standing query. The audit pack is a query, not a project. Answer once. Assess everything.
FAQ
How often must the register of information be submitted? DORA requires financial entities to report to competent authorities at least yearly on their ICT third-party arrangements — the number of new arrangements, provider categories, contract types and the services and functions provided — and to make the full register, or specified sections, available to the competent authority upon request at any time (Article 28(3)). Treat "upon request" as the binding standard: the register must be defensible continuously, not only at the annual reporting point.
What makes a function "critical or important," and why does the threshold matter? DORA's framework turns on whether an ICT service supports a critical or important function, and DORA requires the register to distinguish those arrangements from the rest (Article 28(3)). The classification drives which contractual provisions apply (Article 30(3)), whether the arrangement feeds concentration-risk assessment (Article 29), and whether the supporting systems fall within TLPT scope (Article 26(2)). DORA also requires entities to notify the competent authority in a timely manner when a function becomes critical or important (Article 28(3)).
How frequently is threat-led penetration testing required? Financial entities identified by their competent authority must carry out TLPT at least every three years, though the authority may require a reduced or increased frequency based on the entity's risk profile and operational circumstances (Article 26(1)). Separately, DORA requires at least yearly testing of all ICT systems and applications supporting critical or important functions (Article 24(6)).
Do ICT third-party providers have to participate in our TLPT? Where providers support in-scope critical or important functions, DORA requires the financial entity to ensure their participation while retaining full responsibility for compliance (Article 26(3)), and requires contracts for critical-or-important arrangements to include the provider's obligation to participate and fully cooperate in TLPT (Article 30(3), point (d)). Where direct participation would harm the provider's other customers, pooled testing is permitted (Article 26(4)).
Aegis treats your DORA register of information, TLPT scope, and concentration analysis as queries over one live dependency map — source-grounded, traceable to the contract and the regulation. See how Aegis turns your DORA register of information into a live query — answer once, assess everything — at aegis-grc.com. For the wider third-party picture, see third-party risk.
