What the DORA register of information requires and who does the work
Financial entities in scope of DORA must maintain a register of information on all their contractual arrangements for ICT services under Article 28(3), using the 15 templates set by Implementing Regulation (EU) 2024/2956, and report it each year through their competent authority to the European Supervisory Authorities. If a regulator, customer or contract now asks for the register, the first question is which entity and which level of consolidation it covers, because the same contracts can appear in more than one submission. The financial entity owns the register and is accountable for its accuracy. An implementation partner can help map contracts to templates, extract and clean the data, and build the repeatable process that produces it, but no partner receives or processes the submission. That step belongs to the competent authority.
The workload depends on three variables. The first is the number of ICT third-party providers and the depth of the supply chain, since the register must cover subcontractors that effectively underpin services supporting critical or important functions, and each legal-person provider needs a valid and active LEI or EUID where one is available. The second is the consolidation structure: the register is maintained at entity, sub-consolidated and consolidated levels, and the reporting level to the ESAs depends on whether the entity is stand-alone, has a non-EU parent with no Union parent, or sits inside a Union group. The third is the state of contract records. Entities with contracts scattered across procurement, IT and business units usually spend most of their effort finding and reconciling records before any template is filled in. Ask your team to confirm the consolidation level and provider count before requesting a quote, because these determine the scope.
What the register must contain across its 15 templates
The register of information is one dataset split across 15 templates, from the reporting entity down to the terminology used. Each group answers a different supervisory question, and the cards below show how they connect so that a single provider or subcontractor is described consistently everywhere it appears.
Reporting entity and consolidation
The first templates identify the financial entity filing the register, its branches and where it sits in any consolidation group. Because Article 28(3) requires the register at entity level and at sub-consolidated and consolidated levels, the reporting perimeter must match the group structure your supervisor uses. Confirm which entity is the reporting unit before collecting any provider data, since every later template inherits that scope.
Contractual arrangements
These templates record each contract for ICT services, its reference, dates, and the services it covers. Each arrangement is a row that must tie back to a provider and to the functions it supports. Check that contracts with intra-group providers, cloud platforms and self-hosted open-source support partners are all captured, not only the contracts procurement holds in its main system.
Signing entities and providers
These templates identify who signed each arrangement and which ICT third-party service providers receive the services. Every provider that is a legal person must carry a valid and active LEI or EUID, and both where available. Ask each provider for its identifier early, because missing or expired codes are among the most common reasons a register fails data quality checks.
Entities using the services
These templates name the group entities that use each ICT service, which matters when one contract serves several legal entities in the same group. A shared platform may be listed once under the contracting entity yet used by several others. Confirm the usage mapping with business owners, since an incomplete list understates the exposure a supervisor sees for that provider.
Providers and the supply chain
This group records providers and the subcontractors that effectively underpin services supporting critical or important functions. Direct providers are ranked 1, and subcontractors are ranked higher, so the register shows the chain rather than only the contracting party. Ask providers which of their own suppliers host or operate the service, because subcontractors a financial entity never contracted with still belong in the register.
Functions and critical or important assessment
The functions template links each arrangement to the business functions it supports, and the assessment template records whether those services support critical or important functions. This is the judgment that drives scope, because the register must distinguish those arrangements. Document the reasoning behind each assessment so it can be reviewed, and align it with the criteria used in your ICT third-party risk policy.
Which identifiers and reporting levels apply
Article 28(3) of DORA requires the register to be kept at entity level and, where applicable, at sub-consolidated and consolidated levels. A stand-alone firm maintains one register for itself. A group may need a register for each subsidiary, a sub-consolidated register for a intermediate parent, and a consolidated register at the top, with each level covering the contractual arrangements that fall within its perimeter. The levels are not interchangeable, so the same contract can appear in more than one register.
- Entity level: each financial entity keeps a register covering its own ICT contracts, including those that support critical or important functions.
- Sub-consolidated level: an intermediate parent maintains a register covering the arrangements of the entities below it.
- Consolidated level: the top parent in scope maintains the group-wide view.
- Overlap: one provider contract may legitimately appear in several levels, so the entries must match across them.
- Ownership: confirm which legal entity signs each contract, since that determines where the entry belongs.
Confirm your group perimeter with your competent authority and document the level map before building any templates.
Every ICT third-party provider that is a legal person must be identified in the register by a valid and active Legal Entity Identifier (LEI) or EUID, and by both where both are available. The rule applies to subcontractors that effectively underpin services supporting critical or important functions, not only to direct providers. Identifiers are a data quality matter as much as a legal one, because a missing, expired or mistyped code will fail the validation checks applied to the register.
- Direct providers: each legal-person provider needs a valid and active LEI or EUID, and both where available.
- Subcontractors: the same rule applies to supply-chain entities that underpin critical or important functions.
- Validity: check that the identifier is active on the day you submit, since a lapsed status is a defect.
- Individuals and non-legal persons: this identifier rule is aimed at legal persons, so describe other providers accurately rather than inventing codes.
- Mapping: keep a source record showing where each identifier was verified and when.
Ask providers for their identifiers during due diligence and contract onboarding, so the register does not depend on last-minute chasing.
The ESAs submission level depends on the position of the Union parent. Stand-alone entities report at individual level. Entities whose parent sits outside the Union with no Union parent also report at individual level. Other entities report at the highest level of consolidation in the Union. A subsidiary inside a group may therefore submit its own register to its competent authority while the group submits the consolidated view that reaches the ESAs.
- Stand-alone entities: report the individual register, since no parent consolidates them.
- Non-Union parent with no Union parent: report at individual level for the Union entities concerned.
- Union groups: report at the highest consolidation level in the Union.
- Competent authority deadlines: competent authorities may set earlier dates for financial entities, so the ESAs date is not always the working deadline.
- Reference date: the ESAs use 31 December of the preceding year from 2026 onward, so align your data cut-off with it.
Confirm with your competent authority which level and deadline apply to your entity before the group structure changes.
Why data quality decides whether the register passes
The register of information is judged less on whether it exists than on whether its data holds up under checking. The Implementing Technical Standards require the register to meet six data quality principles: accuracy, completeness, consistency, integrity, uniformity and validity. In practice, every ICT third-party provider that is a legal person must carry a valid and active LEI or EUID, and where both are available, both must be recorded. This applies to subcontractors that underpin services supporting critical or important functions, not only to direct contracting parties. A missing or lapsed identifier is the most common way a register fails a basic check, because the identifier is what lets a supervisor link a provider across entities, contracts and the ESAs' lists.
Gaps in contract records fail in a different way. A register row that names a provider but omits the contractual arrangement, the service type, the ranking of a subcontractor or the link to a critical or important function creates an internal inconsistency that a reviewer can spot without outside data. Teams should reconcile the register against the signed contract file, the procurement system and the list of ICT services in the service inventory before each submission, and confirm that the same provider is spelled and identified the same way in every template. The ESAs' FAQ states that registers are reported in plain-csv format under the ESAs' technical specification, so formatting errors and inconsistent codes are a practical risk, not a cosmetic one. Ask your competent authority which validation rules it runs before submission and whether it sets an earlier deadline than the ESAs' calendar.
Expect similar checks. In a 2024 dry run of register reporting, 1039 participating financial entities received direct data quality feedback from the ESAs, and a summary report was published on 17 December 2024. The feedback was given to individual entities, so an entity cannot assume its errors went unnoticed because a regulator did not contact it first. Treat the dry run as a preview of the reporting the ESAs will apply to the annual submissions. Before your next cycle, run a full internal validation against all six principles, record who owns each correction, and keep the reconciliation evidence so that you can explain any residual gap to your supervisor.
How the annual register cycle runs from entity to ESAs
The register cycle turns a continuously maintained contract inventory into a yearly submission that competent authorities pass to the ESAs, with each stage checked before the next one starts. Financial entities should treat the reference date as the point their data must be complete, not the point they start preparing.
Maintain the register continuously
The financial entity keeps its register of information current as contracts are signed, amended, renewed or ended. Article 28(3) of DORA requires the register to cover all contractual arrangements for ICT services and to flag those supporting critical or important functions, at entity level and at sub-consolidated and consolidated levels where applicable. The contract owner, usually in procurement or the ICT function, feeds changes to the register owner. The step is done when every live arrangement has a current record and no contract sits outside the inventory.
Validate identifiers and data quality
Before any submission, the team checks each ICT third-party provider that is a legal person for a valid and active LEI or EUID, using both where available. This applies to subcontractors that underpin services supporting critical or important functions as well. The data must meet the principles of accuracy, completeness, consistency, integrity, uniformity and validity set in Article 3(4) of the ITS. Checks against the ESAs' technical specification and Annex III service typology catch errors early. The step closes with a validation report that lists exceptions and their owners.
Reconcile the register at the reference date
The entity fixes its snapshot at the reference date: 31 March 2025 for the 2025 submission, and 31 December of the preceding year from 2026 onwards. Reconciliation compares the register against contract files, the ICT asset inventory and accounts payable records to confirm nothing was missed between the last update and the snapshot. Differences are either corrected or documented with a reason. The output is a frozen, reconciled dataset tied to a named reference date.
Meet the competent authority's earlier deadline
Competent authorities set their own deadlines for financial entities, and these are often earlier than the ESA-level dates. The entity should confirm its national deadline, the channel for upload and any format instructions directly with its supervisor, since these details are not fixed by the ESAs. The step is complete when the authority acknowledges receipt of the entity's register. Teams that map this deadline into the internal calendar avoid a gap between their own internal sign-off and the supervisor's cut-off.
Submit the register in plain CSV format
Registers are reported in plain-csv format according to the ESAs' technical specification, which the competent authority then passes on. The entity or its authority applies the consolidation rule: stand-alone entities and entities whose parent sits outside the Union with no Union parent report at individual level, while others report at the highest level of consolidation in the Union. Responsible staff should check the file against the specification before sending. Completion is confirmed by the authority's receipt record and any data quality feedback issued.
Respond to data quality feedback
After submission, competent authorities and the ESAs may return data quality findings. In the 2024 dry run, 1039 participating financial entities received direct feedback from the ESAs, which shows that this step is routine rather than exceptional. The entity logs each finding, traces the source record, corrects it in the master register and records the change. Recurring error patterns, such as missing identifiers for subcontractors, should trigger a process fix rather than repeated manual repairs. The step closes when findings are resolved or explained to the authority.
Carry the corrections into the next cycle
Each annual submission feeds the next. The yearly register submission generally satisfies the Article 28(3) yearly report on new arrangements, according to ESAs Q&A 2025_7309. The entity uses this cycle to record new arrangements, retired providers and corrected identifiers, so the next reference date starts from a clean baseline. The output is an updated register, a lessons-learned note and an assigned owner for each open improvement. The cycle then restarts with continuous maintenance.
What a register of information project costs and who is paid
This table lists each cost component of a register of information project, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to structure a written quote and to see which costs stay inside your organization regardless of who you hire.
| Cost component | Who is paid or who bears it | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Contract inventory | Internal staff: procurement, legal and IT contract owners | One-time, then recurring at each update | Number of ICT contracts, how many are held centrally, and whether contract records are complete |
| Provider identifier collection | Internal staff, with time spent by providers and subcontractors to supply LEI or EUID data | One-time, then recurring as providers and subcontractors change | Number of legal-person providers, share of subcontractors that underpin critical or important functions, and provider responsiveness |
| Data preparation and mapping to templates | Internal staff and any implementation partner paid under a fixed-scope agreement | One-time build, then recurring annual refresh | Volume of arrangements, quality of source data, and how many templates require manual population |
| Register tooling and data management | Software vendor or internal platform team, depending on whether you buy, build or host | Licence or hosting recurring, configuration one-time | Number of entities in the consolidation, need for validation checks, and integration with existing contract or asset systems |
| Data quality validation | Internal compliance and data staff, and any partner performing checks | Recurring before each submission | Number of identifiers to verify and the number of data quality rules the file must pass |
| Competent authority reporting | Internal staff preparing and submitting the file through the reporting channel | Recurring each reporting cycle | Reporting deadlines set by your competent authority, which may be earlier than the ESA dates, and the level at which you report |
| Governance and sign-off | Internal management body and compliance function | Recurring each cycle | Number of consolidated and sub-consolidated levels and how many entities sign off the register |
What makes the register larger, harder or cheaper to maintain
The size of a DORA register of information depends less on the number of systems than on how many contracts, providers and layers of subcontracting sit behind each service. Most of the effort comes from the links between those items, so the drivers below are the ones to measure before estimating the work.
Number of contractual arrangements
Every contractual arrangement for ICT services has to be recorded and kept current, so the count of agreements is the most direct driver of workload. Groups that buy the same platform through several legal entities multiply the rows without adding any new provider. Consolidate shared agreements where the contract allows it, and keep one owner for each arrangement so that renewals, amendments and terminations reach the register on time.
Subcontractors in the supply chain
Subcontractors must appear in the register when they effectively underpin services that support critical or important functions, and the chain can run several layers deep. Ask each direct provider for its list of material subcontractors, their locations and their identifiers, and write the duty to provide these updates into the contract. Without that clause, the register becomes dependent on goodwill for every change.
Group structure and consolidation levels
The register is kept at entity level, at sub-consolidated and consolidated levels, and reported to the ESAs at individual level or at the highest level of consolidation in the Union, depending on the group structure. Each additional subsidiary or branch that buys services adds reconciliation work. Map the legal entities, their parents and the reporting level for each one before the first submission, so duplicate or conflicting records are caught early.
Share of critical or important functions
The register must distinguish arrangements that support critical or important functions, and the templates ask for a detailed assessment of those services. Every function you classify as critical or important adds documentation, substitutability analysis and subcontractor detail. Review the classification regularly, because a function that was moved to a new provider or a changed process can shift the category and the depth of records required.
Quality of existing contract records
Most of the effort in the first cycle comes from cleaning up historic records: missing legal entity identifiers, inconsistent provider names, unclear service descriptions and contracts stored in several procurement tools. The data quality principles of accuracy, completeness, consistency, integrity, uniformity and validity apply to every field. Run a reconciliation between the contract repository, the finance system and the supplier master file before building the register itself.
Self-hosted open-source platforms you run
When an entity runs open-source platforms in its own cloud accounts or data centers, the entity is often both the customer and the operator, so the register must describe the software, the hosting provider and any support vendor separately. Record each component, its version, its hosting location and any commercial support contract, so that a patch or upgrade does not leave the register out of date. Confirm with your competent authority how it expects self-operated tooling to be classified.
How open-source and self-hosted platforms change the register
Self-hosting an open-source platform does not remove the register question. Running the software on your own infrastructure does not by itself mean no ICT third-party service is involved. Most self-hosted estates still depend on a support contract with the software's maintainers or a commercial distributor, a hosting or managed data center provider, a cloud provider supplying the underlying compute and storage, or an implementation partner that installs, upgrades or documents the platform. Each of these can be an ICT service arrangement that belongs in the register. The entity must decide, for each dependency, whether a contractual arrangement exists, whether a fee or formal agreement is involved, and whether the service supports a critical or important function. Open-source licensing terms and the absence of a vendor invoice are not a basis for leaving an arrangement out without recording the reasoning.
Start with a written inventory that maps each self-hosted component to its supporting arrangements. For each line, record the contracting entity, the provider's legal name and identifier (an LEI or EUID where the provider is a legal person and one is available), the ICT service typology category used in the register templates, and any subcontractors that effectively underpin the service. Where the platform is installed or maintained by an outside partner, the arrangement with that partner is an ICT service that the entity must classify on its own. DeployOpen can prepare system inventories, dependency maps and the supporting evidence for these records. The classification decision, the critical or important function assessment and the sign-off stay with the financial entity, because the entity owns its controls and its register.
Confirm the scoping position before you finalize the register. Ask your competent authority how it expects self-hosted open-source software to be treated, particularly where no direct contract exists, where a community project has a commercial support tier, or where the platform is a shared component inside a group. Record the answer in the register's documentation so that the decision can be shown at the next submission. Ask any implementation partner to state in writing which systems and evidence they produce for the register, and which decisions remain with your team.
What to have in place before the first register submission
The register of information is only as good as the inventory behind it. The six items below are the groundwork that a competent authority will expect to see reflected in the file before anything is reported to the ESAs. Each one feeds the next, so gaps in the contract inventory tend to surface later as identifier and classification errors.
Complete contract inventory
List every contractual arrangement for ICT services with an ICT third-party provider, including free, intra-group and open-source arrangements where a provider supplies support or hosting. Article 28(3) covers all such arrangements, not only the paid ones. Check the inventory against accounts payable, procurement records and cloud subscriptions, and against the business units that buy software directly. Ask each owner whether any self-hosted platform relies on a commercial support or managed service contract.
Mapped critical or important functions
For each contractual arrangement, record which critical or important function the ICT service supports. The register must distinguish arrangements that support such functions, so this mapping has to exist before the first submission. Start from the business services and processes that the entity's own function analysis identifies, then trace each ICT service back to them. Where one provider supports several functions, record the most demanding one and document the reasoning so an assessor can follow it.
Identifiers for legal-person providers
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 effectively underpin services supporting critical or important functions. Confirm each identifier against the public registry before submission, check that its status is active, and record the entity name exactly as the registry shows it. Missing identifiers for subcontractors are a common gap, because the entity usually holds no contract with them and must ask the direct provider for the chain.
Subcontractor chain for critical services
Map the subcontracting chain behind each service that supports a critical or important function, down to the providers that effectively underpin it. Direct providers are ranked 1 and subcontractors rank higher, so the chain must be traceable level by level. Ask direct providers in writing for their subcontractor lists, including cloud hosting, managed service and data center operators. Record where a provider refuses or cannot answer, because that gap is itself a risk finding to be managed under the entity's third-party policy.
ICT service typology aligned to Annex III
Classify every ICT service using the service typology in Annex III of Implementing Regulation (EU) 2024/2956, so that provider categories in the register match the regulator's taxonomy. The ESAs' Q&A on the yearly submission confirms that these categories follow the Annex III typology. Keep a short mapping table that shows which internal service name corresponds to which Annex III category, and review it when a new platform is added. Inconsistent classification across entities in a group is one of the main sources of data quality findings.
Named owner who signs off the data
Assign one accountable person for the register, with a deputy, and record who approves each submission before it leaves the entity. The owner should hold the authority to request contract documents from procurement and identifiers from providers, and should be able to escalate when a provider does not respond. Sign-off should cover accuracy, completeness and consistency checks against the inventory, and the approval should be retained as evidence. Without a named owner, register updates tend to lag behind contract changes.
Who owns the register, who prepares it, and who receives it
The financial entity owns the register. Under Article 28(3) of DORA, it must maintain and update the register of information on all contractual arrangements for ICT services, at entity level and at sub-consolidated and consolidated levels, and it must mark which arrangements support critical or important functions. Management remains accountable for the register even when a consultant or software tool assembles it. The entity decides how each arrangement is classified, confirms the identifiers it reports, and signs off on the data that goes to its competent authority.
- Ownership of the record: The entity keeps the register current as contracts start, change and end, and it decides which arrangements are in scope.
- Classification decisions: The entity determines which functions are critical or important and which ICT services support them.
- Identifier accuracy: The entity confirms that each legal-person provider and relevant subcontractor carries a valid and active LEI or EUID, where available.
- Data quality: The entity checks accuracy, completeness, consistency, integrity, uniformity and validity before submission.
- Internal evidence: The entity keeps the working files, approvals and reasoning that show how each entry was produced.
Confirm internally who signs the register and who answers questions from the competent authority, because those answers cannot be delegated to a partner.
An implementation partner such as DeployOpen can prepare the systems, data mapping and documentation that make the register producible and repeatable. In a fixed-scope engagement, the partner might map contract and asset data from existing procurement, CMDB or document stores into the template structure, build the controls that keep the data consistent, and document how the process runs. The partner works inside the entity's environment and under its direction. It does not decide classifications, sign the register, or issue any report or certificate on it. Only an independent auditor or the supervisor's own review can assess the register.
- Data mapping: The partner identifies where contract, provider, subcontractor and service data sits and maps it to the register's fields.
- System preparation: The partner can configure self-hosted tools or scripts that gather, validate and export the data in the required format.
- Validation checks: The partner can build checks for missing identifiers, duplicate entries and inconsistent provider records before each submission.
- Documentation: The partner can write the procedure, roles, change log and evidence folder that explain how the register is maintained.
- Scope limits: The partner's deliverables are agreed in writing, and ownership of the content stays with the entity.
Ask any partner to state in writing which tasks it performs, which remain with your staff, and what evidence it will hand over at the end.
Competent authorities receive the register, check it, and supervise the entity's compliance. Under the ESAs' decision of 8 November 2024, competent authorities report registers to the ESAs, and the reporting cycle runs on fixed reference dates. The ESAs use the reported data for their own analysis, including the first step of the process that led to the designation of critical ICT third-party providers. Competent authorities may set earlier deadlines for financial entities, so the national schedule matters as much as the EU one.
- Receipt and format: Entities submit to their competent authority, which reports to the ESAs in plain-csv format under the ESAs' technical specification.
- Reporting level: Submissions are made at individual level for stand-alone entities, or at the highest consolidation level in the Union where one applies.
- Data feedback: In the 2024 dry run, participating entities received direct data quality feedback from the ESAs, which shows that the quality checks are applied closely.
- Supervision: Authorities can ask for explanations and evidence about classifications and gaps, and they use the register to target supervision.
- Annual cycle: From 2026, the reference date is 31 December of the preceding year, with submission by 31 March each calendar year.
Confirm your national authority's deadlines and submission channel now, since they may differ from the ESA dates.
Questions buyers ask about the DORA register of information
What is the first step in building a DORA register of information?
The first step is an inventory of every contractual arrangement for ICT services your organization has with ICT third-party providers, including intra-group arrangements. Start from procurement and contract records rather than the IT asset list, because the register is built around contracts. For each arrangement, record whether the service supports a critical or important function, since that flag drives how much detail the register needs. Then confirm the legal entity behind each provider and whether it has a valid LEI or EUID. Only after that inventory is reliable should you map the data onto the templates in Implementing Regulation (EU) 2024/2956.
Who must keep the DORA register of information?
Each financial entity in scope of DORA must keep the register, and it must be maintained at entity level and at sub-consolidated and consolidated levels where those apply. Under Article 28(3), the duty sits with the financial entity that holds the contracts, so a group needs a clear view of which entity signed each arrangement. For reporting to the ESAs, registers are submitted at individual level for stand-alone entities and for entities whose parent sits outside the Union with no Union parent. Otherwise the submission is made at the highest level of consolidation in the Union. Confirm with your competent authority how it expects the group structure to be reflected.
How long does a first register build take?
No supplied fact gives a duration, so treat any figure you hear with caution. The effort depends mainly on the number of contractual arrangements, how many of them support critical or important functions, how many subcontractors sit behind those services, and how complete your contract records are. Organizations with decentralized procurement usually spend the most time locating contracts and missing provider identifiers. Ask any advisor for a written plan that lists the arrangements in scope, the data sources, the validation steps and the points where business owners must respond, then compare the plan against your own contract count.
Can an in-house team build the DORA register of information?
Yes, an in-house team can build the register if it has access to contract data, procurement records and the people who own each service. The work is mostly data collection and validation rather than technical engineering, so the main constraint is capacity and knowledge of the templates. Teams often struggle with subcontractor chains, provider legal entity identification and consistency checks across the templates. An external implementation partner can prepare the data model, tooling and validation checks, but the financial entity remains responsible for the content it submits. Only the competent authority receives and processes the submission, and no outside party issues an approval.
What does the register need from the business?
The register depends on information that sits outside IT. Procurement needs to supply the contract list, signing entity, start and end dates and termination terms. Contract owners need to confirm which business functions each service supports and whether it supports a critical or important function. Vendor management or the provider itself must supply valid LEI or EUID identifiers and details of material subcontractors. Finance or legal may need to confirm the entities that use each service. Agree in advance who answers for each field, how quickly they must respond and how changes to contracts will flow into the register during the year.
How does the register connect to oversight of critical ICT providers?
The ESAs used data from financial entities' registers as the first step of the assessment that led to the first list of 19 designated critical ICT third-party providers, published on 18 November 2025. The register therefore shapes which providers come under direct ESA oversight. For your organization, the practical link is that accurate provider identifiers, subcontractor chains and service classifications determine whether a provider can be identified and assessed. Review your register against that designation list, check which of your providers are on it, and keep the mapping current as designations change. Confirm the current list and any follow-up directly with the European Supervisory Authorities.
How DeployOpen scopes and prepares register evidence
DeployOpen is a Chainscore Labs company. It plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it prepares the systems and evidence that a register of information depends on. That work starts with a fixed-scope written agreement that names the entities covered (solo, sub-consolidated or consolidated), the ICT services and platforms in the register, the templates the team will populate, and the deliverables and dates. Before work begins, ask whether the scope lists the subcontractor chains you need to map and whether the agreement says who signs off the final data set. The quote follows from that written scope, so a scope that leaves out a platform or a provider will leave a gap in the register.
Most of the effort in register preparation sits in inventories and data files that the client already holds, such as contract repositories, configuration management records, asset registers and procurement files. DeployOpen's role is to structure those sources, check them against the data quality principles (accuracy, completeness, consistency, integrity, uniformity and validity) and document how each field was derived. Expect to hand over the contract inventory, service descriptions, provider identifiers (LEI or EUID where available) and any subcontractor information in agreed formats. Confirm early which of these you can produce and who inside your organization owns each source, because missing or inconsistent identifiers are the most common reason a register needs rework.
DeployOpen does not issue audit reports, attestations or certifications, and it does not guarantee a regulatory outcome. The register is the financial entity's own document, and the entity submits it through its competent authority. Independent auditors and the competent authority assess it, and a DeployOpen engagement does not replace either. The useful question for procurement is what evidence the handover will contain, such as the populated templates, the data quality checks performed, the list of open issues, and the record of who approved each version, so that your internal owner and any assessor can trace every entry back to its source.
