Implementing Regulation (EU) 2024/2956 register of information ITS

What the DORA register of information ITS asks you to produce

A financial entity has to be able to hand its supervisor a structured register of every ICT third-party arrangement it holds, and an ICT provider serving those entities may be asked to supply the data behind it. Implementing Regulation (EU) 2024/2956 is the instrument that fixes the shape of that register. It sets 15 standard templates, grouped by subject: the entity and its consolidated group, contractual arrangements and intra-group links, the signing entities and providers, the entities using the services, the providers and their supply chain, the functions supported, the assessment of critical services, and a terminology sheet. Your task is not to write a free-form inventory. It is to populate each template with the values the templates expect, for every relevant arrangement, so that supervisors can compare entities on the same basis.

The supervisory purpose is to close blind spots. Outsourcing chains often run several layers deep, and a bank may know its direct cloud or software vendor while having no visibility of the subcontractors that actually run the service. The regulation therefore asks for a supply chain ranking: the direct provider is always rank 1, and subcontractors that effectively underpin services supporting critical or important functions are recorded at higher ranks. It also requires a valid and active LEI or EUID, where available, for legal-person providers and relevant subcontractors, so that a supervisor can match the same entity across different firms' registers. Data quality principles of accuracy, completeness, consistency, integrity, uniformity and validity apply to the whole exercise, and each data element must hold a single value.

The data is hard to assemble because it lives in several teams. Procurement holds contracts, IT holds configurations and asset records, legal holds subcontracting clauses, and the providers themselves hold the subcontractor chain. Before starting, confirm with your supervisor or your own compliance function which reporting format and submission route apply to you, and check the current version of the templates and validation rules, since they are published in the Official Journal and supporting material may change. Then run a pilot on a small set of critical arrangements to find where identifiers are missing, where a subcontractor is unknown to your provider, and where one field needs several values. Those gaps, not the templates themselves, usually decide how long the first complete register takes.

Which arrangements and entities the register must cover

The register of information only works if the scope is settled before anyone fills in a template. Each card below is a scoping decision that changes how much data is collected, who owns it and which identifiers must be validated. Settle them in writing with the people who own contracts, legal entities and group structure.

Which ICT services count

Start with the broad inventory. The register covers all ICT services delivered by direct ICT third-party providers, so a contract that looks non-technical, such as a managed print or data feed, may still fall in scope. Check each service against the contract register, procurement records and business owner interviews, and record why any excluded item is out. Ask the auditor which exclusion logic they will accept before you finalize the list.

Direct providers versus underpinning subcontractors

Direct providers are rank 1 in the supply chain. Subcontractors are rank higher than 1, and Article 3(2) brings in those that effectively underpin ICT services supporting critical or important functions. Map each critical or important function to its full chain, including hosting and support subcontractors, because a rank 2 or 3 entry is often the one that is missing. Confirm with the direct provider in writing what it subcontracts.

Legal persons needing an LEI or EUID

Every ICT third-party provider that is a legal person needs a valid and active LEI or EUID, and both where available. The same rule applies to subcontractors that underpin critical or important functions. Individual freelancers and sole traders need separate handling, and many suppliers hold identifiers under different legal names than their trading names. Validate each identifier against the public registries and record the date checked.

Intra-group ICT arrangements

Services bought from sister companies, parent entities or shared service centers are still ICT third-party arrangements when they support ICT services. Decide whether each one is recorded as an intra-group link, a third-party arrangement, or both, and make sure the same provider is not counted twice under different identifiers. Contracts and service descriptions often sit in group legal functions, so ask them for the signed documents rather than summaries.

Branches and entities in the consolidation

The register must show the financial entity itself, the entities included in the consolidation and any branches. Each one can use the same provider under a different contract, so the register must tie every arrangement to the entity that signed it. Build the entity list from the group's consolidation scope, not from the org chart, and confirm branch status with local legal counsel where the answer is unclear.

Group-level registers

Where a group keeps a consolidated register, decide which entity is the holder, how each subsidiary's arrangements are submitted, and who resolves conflicting records. Assign data owners for each entity so that a single provider record does not carry different values from different subsidiaries. Agree the governance, submission cadence and sign-off route in writing before the first submission cycle.

How to build the register from inventory to submission

This sequence turns scattered records of ICT services and providers into one register that follows the Implementing Regulation's templates, identifiers and data quality rules. Each step produces an artifact the next step depends on, so gaps surface before submission rather than during supervisory review.

Confirm the in-scope population
Start by deciding which legal entities, branches and ICT arrangements the register must cover. Scope follows DORA's rule that the register covers all ICT services from direct ICT third-party providers, plus subcontractors that effectively underpin services supporting critical or important functions. Compliance or risk owners sign off the scope, and the finance and legal teams confirm the entity list against the consolidation perimeter. The step is done when every in-scope entity and arrangement has a named owner and a written scope decision that can be shown to an assessor.
Map arrangements to the templates
Assign each in-scope arrangement to the templates in Article 5: entity and branch data (B_01), contractual arrangements and intra-group links (B_02), signing entities and providers (B_03), entities using the services (B_04), providers and supply chain (B_05), functions (B_06), and assessment of critical services (B_07). Terminology is captured in B_99. The output is a mapping sheet that shows, for each contract, which template rows it populates and which fields remain empty for a documented reason. Confirm the mapping against the official template definitions in the Implementing Regulation rather than internal shorthand.
Collect and validate LEI or EUID identifiers
For every ICT third-party provider that is a legal person, and for subcontractors underpinning services that support critical or important functions, collect a valid and active Legal Entity Identifier (LEI) or European Unique Identifier (EUID), and both where available. Procurement or vendor management usually holds the first request, but validation should be done against the public registry records by the team that owns the register. Record the check date and the source for each identifier. The step closes when every required provider carries a validated identifier or an open exception with a named owner and remediation plan.
Establish the provider supply chain ranking
Rank every provider in each ICT service supply chain. The direct provider is always rank 1, and each subcontractor sits at a rank higher than 1. Build this from contract documents, subcontracting disclosures and the provider's own answers, and check it with the people who run the service. The output is a supply chain tree per critical or important function that shows each link, its rank and the contract that governs it. Gaps found here often reveal subcontractors that were never recorded, so this step should be finished before data quality checks begin.
Apply single-value and data quality rules
Check the populated templates against the data quality principles in Article 3(4): accuracy, completeness, consistency, integrity, uniformity and validity. Under Article 4, each data element must hold a single value, so any field with several values moves to additional rows rather than a combined cell. Run cross-checks such as matching provider names and identifiers across B_03 and B_05, and confirming that every contract referenced in B_02 exists in the contract repository. Record each defect, its fix and the reviewer. The step is complete when a second person has reviewed the register and the open defect log is empty or explained.
Set the maintenance cycle and approvals
Define who updates the register, how changes to contracts, providers and subcontractors trigger updates, and who approves each version before it leaves the organization. Document the cycle in the policy that governs the register, and assign the management body or delegated owner the duty to review it. The output is a version-controlled register with a change log, an approval record and a named owner for each template. Ask your competent authority or internal audit function which evidence they expect to see for approvals before you finalize the process.
Prepare the submission package
Export the register in the format the competent authority requests and confirm the submission channel, file naming and any transmission requirements with that authority before the deadline. Keep the approved version, the validation log, the supply chain tree and the change history together so the figures in the submission can be traced to source records. Assign one person to answer questions after submission. The step is complete when the package is filed, a copy is stored under the retention rules the organization applies, and the next maintenance review is scheduled.

How a supervisor tests the register

This table compares what a competent authority is likely to test in the register of information, the evidence it will ask for, and the gaps that most often surface. Read each row as a test a supervisor can run on your files, and use the findings column to decide where to check before the first submission.

Test area	Evidence requested	Common findings
Completeness against asset and contract inventory	Reconciliation of the register to the ICT asset inventory, contract repository and list of ICT services supporting functions	Services present in procurement or cloud accounts but missing from the register; free or open-source components omitted because no contract exists
Identifier validity	Current LEI or EUID records for each legal-person provider and each relevant subcontractor, with the date of the last check	Lapsed or mistyped LEIs; EUID used where an LEI is available; blank fields with no explanation
Supply chain ranking consistency	Chain diagrams showing rank 1 direct providers and higher ranks for subcontractors, matched to the contract and subcontracting records	Subcontractors listed as direct providers; rank values that conflict with the chain described in contracts
Single-value compliance	Data dictionary and sample rows showing one value per data element, with extra rows used for additional values	Multiple values packed into one cell; free-text entries where a coded value is expected; inconsistent spellings of the same entity
Reconciliation with the ICT services policy	Policy on ICT services, mapping of functions to services, and the register rows that cover each critical or important function	Register not updated after policy changes; functions classified as critical in the policy but not flagged in the register
Consistency across group-level registers	Entity-level and group-level registers, with a record of how intra-group arrangements are reported in each	Same provider recorded with different identifiers or names across entities; intra-group services missing from the consolidated view

Evidence that shows the register is complete and accurate

A register of information is only as credible as the evidence behind each row. The cards below describe the artifacts that let a competent authority trace every entry back to a contract, an identifier and a supply chain decision, and the routines that keep them current between submissions.

Populated templates with version history

Keep the 15 templates under Article 5 in a controlled repository, with each submission frozen as a dated version. Store the template files, the data glossary used for each run and the sign-off record from the person accountable for the register. Between submissions, log every change to a row with the reason and the reviewer, so you can show how a value moved from one version to the next. Check that the entity-level templates (B_01 to B_03) agree with the contract-level templates (B_02 to B_07) before each freeze.

Contract source list reconciled to the register

Maintain a single list of every ICT contract, order form and intra-group agreement that supports an ICT service, then reconcile it line by line against the contract-level templates. Each contract should map to one or more register rows, and each register row should trace back to a signed contract. Unmatched contracts are gaps, and register rows without a contract are either errors or evidence of an informal arrangement that needs review. Run this reconciliation before each submission and keep the output as a signed exception list.

LEI and EUID validation records

Article 3(5) and (6) require a valid and active LEI or European Unique Identifier for each ICT third-party provider that is a legal person, and for relevant subcontractors. Record the lookup date, the source consulted and the status returned for every identifier, then repeat the check on a fixed schedule. Keep a separate record for providers that have no identifier, showing what was checked and why the identifier is absent. Lapsed or inactive identifiers are a common reason a row fails validation, so track their expiry dates.

Supply chain mapping with rank logic

Under Article 2, the direct provider is always rank 1 and each subcontractor ranks higher. Produce a diagram or table for every critical or important function showing each provider, its rank and the service it underpins, and check that every subcontractor appears with the correct rank. Retain the mapping as a dated artifact, because assessors often test whether a subcontractor that underpins a critical function was captured at all. Refresh the mapping whenever a provider notifies a subcontracting change.

Data quality check outputs

Article 3(4) sets six data quality principles: accuracy, completeness, consistency, integrity, uniformity and validity. Article 4 requires each data element to hold a single value, with additional values placed in extra rows. Run automated checks that flag empty mandatory fields, duplicate identifiers, conflicting values across templates and multiple values in a single cell, and keep the output of each run. Record how each flagged issue was resolved so the check log demonstrates correction, not just detection.

Change log linking updates to contracts

Every new, amended or ended contract should trigger a register update, and the change log should link each update to the event that caused it. Record the contract reference, the date of signature or termination, the affected register rows and the person who made the change. Review the log against the contract source list each quarter, because entries that cannot be traced to a contract event are the first thing a supervisor will question. Confirm with your competent authority how it expects ended arrangements to be represented before you delete any row.

What building and maintaining the register costs

This table compares the cost components of building the register of information and keeping it accurate, showing who does the work, whether the cost is one-time or recurring, and what drives it up. Read the one-time rows as the initial build and the recurring rows as the ongoing cost of keeping the register current. No price or duration figures are given, so use the drivers to frame a written scope and quote request.

Cost component	One-time or recurring	Main cost drivers
Contract discovery effort	One-time, then recurring for new contracts	Number of ICT contracts across entities, branches and business units, and how well procurement records link contracts to services
Subcontractor mapping effort	One-time, then recurring as chains change	Depth of subcontracting chains, since Article 2 ranks providers and subcontractors above rank 1 must be traced to the services that support critical or important functions
Identifier collection (LEI and EUID)	One-time per provider, then recurring checks	Number of legal-person providers and subcontractors, and whether identifiers are held in procurement records or must be sourced from providers
Tooling or licences	Recurring subscription or maintenance	Commercial register tools priced per user or entity, compared with self-hosted open-source options such as CISO Assistant (AGPL-3.0-only) and GLPI (GPL-3.0-or-later), which carry no licence fee but need hosting and administration
Engineering time for data pipelines	One-time build, then recurring maintenance	Number of source systems feeding the register, such as procurement, contract management and asset inventories, and how much mapping into the 15 templates is automated
Recurring upkeep and reconciliation	Recurring	Frequency of contract changes, onboarding of new providers, exits, and checks against the data quality principles of Article 3(4) for accuracy, completeness and consistency
External review	Periodic, and at each register submission cycle	Scope and depth of independent review, and whether the reviewer is an auditor or a consultant who prepares evidence rather than issuing an opinion
Single-value and extra-row formatting	One-time setup, then recurring checks	Volume of data elements with multiple values, since Article 4 requires one value per data element with extra rows for additional values

Which self-hosted tools can hold the evidence behind the register

CISO Assistant is an open-source governance, risk and compliance platform. Its catalog includes DORA among more than 200 frameworks, and it runs audits and compliance assessments against them with automatic mapping between frameworks. For the register, its value is in the governance layer: recording which ICT third-party arrangements exist, linking them to the DORA requirements they affect, and keeping assessment results and owners in one place. It does not generate the Commission's 15 register templates. Any export into the template format needs to be built or confirmed separately.

Assessment evidence: Questionnaires, control assessments and audit records against the DORA requirements that govern third-party risk.
Link to register data: Provider and arrangement records can be aligned with the entries in the register so that assessment dates and owners match what is reported.
Traceability: Mapped requirements show which contractual and risk controls support each critical or important function.
License caveat: CISO Assistant is licensed under AGPL-3.0-only. Confirm with counsel how the terms apply if you modify the software or offer it to third parties as a service.

Confirm with the project and your own environment whether a given release can export register data in the format the ESAs require before you rely on it for submission.

Where registers fail review and how to close each gap

Most rejected or challenged registers fail on the same few points: incomplete supply chains, identifiers that have quietly expired, and data that no longer matches the contracts behind it. Each gap below is tied to a specific requirement in Implementing Regulation (EU) 2024/2956, with a practical fix you can check before submission.

Missing subcontractors below the direct provider

The register must reflect the supply chain, not just the contracting party. Subcontractors that effectively underpin ICT services supporting critical or important functions belong in the register, and the ranking logic places them at a rank higher than 1. A register that lists only the direct provider leaves the supervisor unable to see where concentration or single points of failure sit. Check each critical service against its provider's subcontracting disclosures and record every link in the chain, including cloud hosting and managed support.

Lapsed LEI or EUID records

Every ICT third-party provider that is a legal person needs a valid and active LEI or EUID, and subcontractors underpinning critical or important functions need one too, where available. An identifier that has lapsed or been retired makes the record invalid even when every other field is correct. Set a recurring check against the issuing registry for each identifier, assign an owner to it, and re-verify after any corporate restructuring, merger or change of legal name.

Several values packed into one field

The data model requires each data element to hold a single value, with additional values entered as extra rows. Lists of sites, multiple governing laws or several service locations written into one cell break this rule and fail uniformity and validity checks. Review each template for free-text cells that contain separators such as semicolons or line breaks, split them into rows, and confirm that each row still links correctly to its contract and provider.

Group entities left out

Where a financial group relies on shared ICT services, intra-group arrangements and the entities that use them must appear in the consolidated picture. Registers built by one subsidiary often omit parent-level contracts, shared platforms or branches that consume services through another group member. Map every entity that uses a shared service, reconcile the entity templates against the group's legal structure, and confirm that intra-group links appear in both directions.

Register updates lagging contract changes

A register that reflects last year's contracts fails the accuracy and completeness principles even if each entry was correct when written. Renewals, new subcontractors, changed service locations and terminated providers all change the record. Tie register updates to the contract lifecycle, with the procurement or legal team notifying the register owner before signature and within a fixed internal window after any change, and keep a dated change log that shows when each entry last changed.

Data quality checks run once, not continuously

Accuracy, completeness, consistency, integrity, uniformity and validity must hold at every submission, not only at the first build. Run automated validation on each export: confirm that every provider has a rank, every critical service links to a provider, and every identifier is present in the expected format. Keep the validation results with the submission so that you can show the reviewer how the data was checked.

Questions buyers ask about the DORA register of information

Can we build our DORA register of information in-house?

Yes, a financial entity can build the register with its own staff, because DORA places the duty on the entity itself, not on any outside firm. The work is mostly data work: listing every ICT arrangement, tracing each direct provider and the subcontractors beneath it, and filling the standard templates consistently. Teams that already run a current ICT asset inventory and a vendor contract database usually find the job more manageable. Teams without those sources often spend most of their effort reconciling records that disagree with each other. An outside partner can help with the data pipeline and the checks, but the entity remains responsible for the content and for keeping it current.

What drives the effort and cost of a DORA register project?

The main drivers are the number of ICT arrangements, how many of them support critical or important functions, and how far the supply chain runs beneath each provider. Cost also rises when the source data lives in spreadsheets, procurement files and several business units, because each source must be reconciled before it can be trusted. Group structures add work, since intra-group links and entity-level registers need their own rows. Costs fall when contract data is centralized and the asset inventory is accurate. Ask any provider for a quote that separates discovery, data cleansing, template population, validation against the data quality principles, and handover, and that states which items are one-time and which recur at each update.

How long does it take to reach a usable register?

The timeline depends on how quickly the entity can produce complete, reconciled data, not on the templates themselves. The longest phase is usually discovery, where teams find arrangements that were never logged in procurement, and the second longest is resolving subcontractor chains that providers do not disclose readily. A usable first version needs every direct provider, the critical or important functions they support, and valid identifiers for the legal persons involved. Expect the schedule to move if contract owners are slow to respond or if group entities hold data separately. Ask for a written plan that names the data sources, the owner of each source, and the checkpoint where the register is first validated end to end.

What does the register need from our contract and vendor teams?

The register depends on contract and vendor teams to supply accurate facts about each arrangement. Procurement and legal should provide executed contracts, the service descriptions, and the identity of each contracting entity. Vendor management should confirm which functions each service supports, the locations where services are delivered, and whether the provider has subcontracted parts of the service. Relationship owners need to ask providers for their subcontractor lists and identifiers, and to tell the entity when those change. Expect some providers to answer slowly or incompletely, so build a request process early and record every gap. Several items below are recurring obligations that need an owner after the first submission.

Can an LEI or EUID be missing from the register?

A valid and active LEI or EUID is required for ICT third-party providers that are legal persons, and for subcontractors that underpin services supporting critical or important functions, where the identifier is available. The rule requires both identifiers where both are available. If an identifier does not exist for a provider, the entity should record the gap, document its checks, and confirm the position with the provider. Missing identifiers should not be filled with guesses or placeholder values, because the data quality principles require accuracy and validity. Confirm the exact handling of gaps with your competent authority and check the current text of Article 3 of the Implementing Regulation in the EUR-Lex text before you finalize your approach.

Does DeployOpen issue any DORA attestation for the register?

No. DeployOpen does not issue audit reports, attestations or certifications. For the register, DeployOpen can help plan the data sources, build the reconciliation steps, prepare the templates and checks, and document how the entity maintains the register over time. The financial entity owns the content and its accuracy. Independent auditors and the competent authority assess the entity's compliance with DORA, and the supervisor decides what evidence it needs. Under DORA, the only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements, which is a separate process. Ask any partner to state this division of roles in writing before work starts.

Which tools can help assemble and maintain the register data?

Tools help most with the inventory and the audit trail, not with the legal judgments. An IT asset management platform such as GLPI can hold records of hardware, software and network equipment, entered manually or pushed by its agent through native inventory. Wazuh's Syscollector module collects installed software, services and network interfaces from endpoints, which can support evidence about where systems run. A compliance platform such as CISO Assistant can track DORA-related assessments and evidence. Confirm with each vendor which fields export cleanly into the register templates and whether the connection needs custom work. The register itself still needs a documented owner, a review cycle and a change log.

How DeployOpen prepares the register evidence

DeployOpen's role in the register of information is an implementation partner role, delivered as a fixed-scope engagement. Before work starts, scope, deliverables and timelines are agreed in writing, and the written scope names the register templates, the ICT services and providers in the inventory, and the systems that will hold the data. DeployOpen plans and builds the technical side inside the client's own cloud accounts, data centers or air-gapped networks: the data model that maps contractual arrangements to providers, the workflow that captures LEI and EUID values, the checks that test data quality, and the documentation that explains how each field is populated and by whom. DeployOpen does not issue audit reports, attestations or certifications. The client owns its controls, its register and every submission made to a competent authority, and any independent assessment is performed by an auditor or assessor the client selects.

Practically, the most useful early decision is how much of the register will be generated from source systems and how much will be maintained by hand. Asset and configuration sources such as GLPI and Wazuh can help populate infrastructure and software facts, but they do not know the contract, the subcontracting chain or the legal entity identifiers, so the client must decide who owns those fields and how changes flow from procurement and legal teams into the register. Ask the implementation partner to show a field-by-field lineage for the templates in scope, a validation rule set that enforces single values per data element, and a handover pack with runbooks, data dictionaries and test records. Confirm with your competent authority which submission format and channel it expects before the build is fixed, since those requirements sit outside the technical standard and can change the export design.