guide

Last updated June 25, 2026

CSSF DORA Register of Information and eDesk Submission: 2026 Practical Guide

Direct answer

CSSF DORA Register of Information and eDesk Submission: 2026 Practical Guide helps compliance teams, directors, risk owners, and advisers translate a Luxembourg supervisory topic into owners, evidence, and escalation points. It explains understanding the Luxembourg regulatory obligation, supervisory evidence, internal ownership, and escalation points in CSSF DORA Register of Information and eDesk Submission: 2026 Practical Guide, then shows how to map the controlling rule, prepare board or compliance evidence, and know when a CSSF-facing specialist should review the file. The later sections connect official sources used, why the register matters, and scope and entity inventory so the next step is easier to judge. Read it before assigning owners or responding to a supervisory request, so the evidence file matches the regulatory question.

For boards, management, ICT risk teams, outsourcing teams, compliance, legal, procurement, data owners and third-party risk managers, the lesson is that the register is not just a spreadsheet exercise. It is the supervisory evidence layer for ICT third-party risk. The entity should be able to explain which ICT services it uses, which contracts support critical or important functions, which providers are inside or outside the EU, which subcontracting chains matter, which services are cloud or non-cloud, which legal entity owns the arrangement, which dates and identifiers are used, how validation errors are corrected, and who can submit through eDesk.

This guide is not legal advice. It is an operating guide for turning the CSSF's DORA register instructions into a controlled evidence process.

Official sources used

• CSSF: DORA - Submission timeframe for register of information - eDesk Portal open as of 11 February 2026
• CSSF: ICT and cyber risk - for DORA entities
• CSSF: Definition of ICT services under DORA and new forms for ICT third-party arrangements
• CSSF: Circular CSSF 25/882
• CSSF eDesk portal

Official CSSF, ESA and EU materials can change. Verify the current eDesk guide, technical package, validation rules, reporting window, file structure and contact instructions before filing.

Why the register matters

The register of information is the map of ICT dependency. A financial entity can claim that it understands digital operational resilience, but the register reveals whether it actually knows its providers, services, contracts, functions, subcontracting and identifiers. If the register is incomplete, the entity's understanding of ICT third-party risk is incomplete. If the register cannot be validated, the entity's data governance is weak. If one person can submit it but nobody else understands it, the process is fragile.

DORA makes ICT third-party oversight a board-level and management concern. The register connects procurement, outsourcing, legal, ICT, security, business continuity, risk management, compliance and regulatory reporting. That is why the CSSF's eDesk communication should be read as a governance instruction, not only a deadline notice.

Scope and entity inventory

Start by confirming which entities and branches are in scope. The CSSF communication refers to financial entities subject to DORA and notes that third-country branches of financial entity types falling in the DORA remit and supervised by the CSSF also have to submit. The entity should document legal entity, LEI, consolidation level, reporting owner, DORA perimeter, and whether submission is individual, sub-consolidated or consolidated.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Deep implementation playbook

A robust DORA register process starts with a sober recognition: most financial entities already have several partial inventories, but none of them is automatically the register of information. Procurement may know contracts. ICT may know systems. Security may know vendors with privileged access. Outsourcing governance may know critical or important arrangements. Finance may know paid suppliers. Business units may know tools used locally. Legal may know master services agreements. The register requires those partial views to be reconciled into a single supervisory view.

The first implementation workshop should therefore compare inventories rather than start from a blank template. Put procurement, ICT, outsourcing, risk, legal, finance, business continuity, information security and data protection in the same review. Ask each function what it knows, what it does not know, and which source it trusts. Differences should become issues, not informal debates. If a vendor appears in finance but not ICT, ask whether the service is an ICT service. If a system appears in ICT but not procurement, ask whether it is an internal system, a group service or a missing contract. If a contract exists but no business owner can explain it, the arrangement needs review.

The second step is to define a controlled source of truth for the register cycle. That does not mean every system has to be replaced. It means the entity chooses the controlled working file, data model or governance tool that will feed eDesk submission. That source should have version control, owners, review dates, validation rules and change log. A register assembled from emailed spreadsheets is possible once, but it is fragile as a permanent operating model.

The third step is to assign field ownership. Some fields belong naturally to procurement or legal. Others belong to ICT, information security, business owners, outsourcing governance or risk. If all fields are assigned to the regulatory reporting team, the process is false. Reporting can coordinate submission, but it cannot own provider legal names, service criticality, subcontracting chains, business function mapping, recovery expectations and contract dates without input from the functions that actually control those facts.

The fourth step is to define a quality threshold. Which fields have zero tolerance? Which fields can be corrected after first validation? Which fields require senior sign-off if unknown? Which fields are source-system remediation items? Without thresholds, every error becomes a deadline conversation. With thresholds, the team knows what must be clean before submission.

Register governance calendar

The register should have a yearly calendar that begins long before eDesk opens. In the first quarter, the entity may focus on submission and validation. In the second quarter, it should review ESA feedback, correct source weaknesses and update procedures. In the third quarter, it should reconcile new contracts, terminated services and provider changes. In the fourth quarter, it should prepare the reference-date snapshot and perform pre-validation. This calendar turns annual reporting into a continuous control.

The calendar should include management checkpoints. A first checkpoint confirms population completeness. A second confirms critical service mapping. A third confirms validation readiness. A fourth confirms eDesk access and upload responsibility. A fifth confirms post-submission monitoring. Each checkpoint should produce evidence, not only meeting notes.

Deadlines should include internal cut-offs earlier than the CSSF window. The CSSF explicitly recommends not waiting until the end of the submission period. The reason is practical: validation errors need time. If errors relate to missing LEIs, incorrect provider identifiers, unclear subcontracting, or wrong function mapping, correction can require business owners and providers. Submission on the final days leaves no operational room.

Data quality controls before eDesk

The entity should run internal validation before eDesk upload. Basic checks include mandatory fields, file names, folder structure, date formats, duplicate identifiers, missing provider names, missing service descriptions, unresolved criticality, inconsistent entity references, orphaned subcontractors and invalid country values. More advanced checks compare the register against procurement, finance, ICT inventory and outsourcing register.

Reconciliation should be documented. If procurement has 400 ICT-related contracts and the register has 260 arrangements, the difference should be explained. Some contracts may be outside DORA scope, some may be duplicates, some may be expired, and some may be missing. The explanation matters because the CSSF or internal audit may ask how completeness was assessed.

Data quality should not be measured only by whether eDesk accepts the upload. A file may pass technical validation and still be incomplete or poorly governed. The entity should also test business plausibility. Are all critical systems represented? Are all cloud providers present? Are key group services included? Are material security providers included? Are third-country providers captured? Are arrangements supporting critical or important functions mapped consistently?

Handling validation errors

Validation errors should be classified and tracked. A formatting error can often be fixed by the reporting team. A missing LEI may require provider outreach. A wrong relationship between tables may require data model correction. A criticality mismatch may require risk-owner judgment. A contract-date error may require legal review. Treating all errors as the same slows remediation.

The error log should record error message, affected field, affected arrangement, root cause, owner, correction, source remediation and resubmission status. If the same error appears repeatedly, the issue is not the error message; it is the source process. A mature entity reduces recurring errors over time.

If ESA validation later identifies additional errors after CSSF acceptance, the entity should treat that as part of the reporting cycle, not as an unexpected emergency. The CSSF communication makes clear that additional ESA checks may happen. Keep resources available after initial submission and retain the ability to regenerate corrected packages.

Third-party support model

Many entities use consultants or managed-service providers to prepare the register. That can be useful, but the CSSF's access warning should be taken seriously. If a third party receives eDesk access, it may have access to data beyond the register. The entity should decide whether third-party assistance can be provided through file preparation without direct eDesk access. If access is granted, it should be specific, time-bound, documented, monitored and revoked after use.

The entity should also review confidentiality and data protection. The register can reveal sensitive information about ICT architecture, critical providers, functions, operational dependencies and third-country exposure. Sharing it casually creates its own risk. Consultants should receive only what they need and should return or delete data according to agreed controls.

Internal accountability must remain clear. A consultant can help prepare a file, but management signs off the substance. If the register omits a critical provider or misclassifies a function, the supervised entity owns the issue. The sign-off process should therefore include internal owners who understand the data, not only external preparers.

Relationship with ICT risk management

The register should connect to ICT risk management. If a provider supports a critical function, the risk assessment should reflect availability, confidentiality, integrity, exit risk, concentration, subcontracting, resilience testing and incident history. If the register says a service is not critical but the business impact analysis says it is essential, the contradiction should be resolved.

ICT risk assessments should feed the register and the register should feed ICT risk assessments. This bidirectional relationship is important. A register that is maintained only for reporting may become stale. An ICT risk process that ignores register fields may miss supervisory data requirements. The two processes should share provider identifiers, service names and function mapping.

Digital operational resilience testing should also use the register. Select critical ICT third-party services and test failure scenarios. What happens if the service is unavailable? Who is contacted? What contractual rights exist? Which customers or business functions are affected? Which incident procedures apply? Which alternatives exist? The register provides the population for these tests.

Relationship with outsourcing governance

Not every ICT third-party arrangement is the same as an outsourcing arrangement, and not every outsourcing process captures the full DORA register detail. That distinction should be documented. The entity should avoid two extremes: assuming only outsourcing arrangements matter, or treating every minor ICT purchase as equally critical. The register should be complete, but governance should be risk-based.

Outsourcing committees should receive DORA register quality metrics. Missing subcontractor information, unclear criticality, expired contracts, weak exit plans and provider concentration should be visible. If outsourcing governance and register governance operate separately, the institution may duplicate work and still miss key risks.

New outsourcing or ICT third-party arrangements should be designed with register fields in mind. The procurement request should capture DORA-relevant data before approval. Legal templates should request provider identifiers, service description, location, subcontracting, audit rights and incident obligations. Business owners should classify function support before the service goes live.

Role of the board and senior management

Boards do not need to inspect every CSV file, but they should understand what the register says about concentration and resilience. A board-level summary should answer: which critical services depend on third parties, which providers support multiple critical functions, which third-country dependencies exist, which providers have unresolved data gaps, which arrangements lack exit plans, and whether submission was accepted or required remediation.

Senior management should also see process maturity. How many arrangements were corrected after validation? How many errors were recurring? How many source systems had gaps? How many business owners failed to confirm data on time? These metrics show whether the register process is becoming stronger or simply surviving each deadline.

The board should challenge whether the entity is using the register for risk management. If the register is filed and forgotten, DORA's value is reduced. If it informs provider concentration reviews, resilience testing, procurement controls and incident readiness, it becomes a management tool.

Practical checklist

1. Confirm the DORA entity population and consolidation level.
2. Confirm LEI and eDesk onboarding.
3. Assign DORA Reporting role and backup.
4. Build a source inventory across procurement, ICT, outsourcing, finance and business owners.
5. Define field owners and data dictionary.
6. Reconcile contract population to source systems.
7. Classify ICT services and document borderline decisions.
8. Map services to functions and criticality.
9. Validate provider identifiers and subcontracting data.
10. Generate plain CSV files and zip structure according to current instructions.
11. Run internal validation before eDesk.
12. Upload early enough to correct CSSF and ESA errors.
13. Monitor messages sent to the uploader.
14. Retain source, package, validation, correction and submission evidence.
15. Convert recurring errors into source remediation.

Final readiness test

Before submission, pick ten arrangements from the register and trace each to contract, provider owner, service owner, ICT asset, business function, risk assessment, outsourcing decision where relevant, business continuity record and validation output. Then pick ten contracts or ICT services from source systems and verify whether they appear in the register or are excluded for a documented reason. This two-way test catches both wrong entries and missing entries.

After submission, repeat the test for any corrected item. Do not close a validation error only because the file was accepted. Close it because the source data was corrected, the owner confirmed the correction, and the next cycle will not reproduce the same defect.

Final operating conclusion

The DORA register is one of the clearest examples of regulatory reporting becoming operational infrastructure. Done poorly, it is a deadline-driven file. Done well, it is a living map of digital dependency. The CSSF's eDesk process, validation warnings, access cautions and resubmission expectations all point to the same practical standard: know your ICT third parties, prove your data, submit early, monitor feedback and improve the source process every year.

Management questions for each reporting cycle

Management should ask whether the register population is complete, whether all critical or important functions are mapped to supporting ICT services, whether any provider concentration creates resilience risk, whether any third-country provider or subcontractor creates additional oversight needs, whether validation errors repeated from last year, whether any business owner failed to confirm data, whether eDesk access is controlled, and whether post-submission messages were monitored. These questions are simple, but they force the organisation to move beyond file preparation.

Management should also ask what changed since the previous reference date. New services, terminated services, amended contracts, provider mergers, cloud migrations, new subcontractors, new business products, outsourcing changes and incident history can all affect the register. A register that does not explain change is hard to trust. The change narrative should be part of the sign-off pack.

Finally, management should ask what the register reveals about strategic risk. If one cloud provider supports many critical services, concentration is a management issue. If several key services depend on providers outside the EU, oversight and exit planning matter. If a provider appears repeatedly in incidents, supplier management should respond. The register is useful only if these insights are acted upon.

Practical examples of weak evidence

Weak evidence often looks acceptable until someone asks a follow-up question. A contract list without service descriptions is weak because no one can map it to functions. A provider name without legal identifier is weak because it may hide group entities or duplicates. A criticality flag without rationale is weak because it cannot be challenged. A validation log without root-cause analysis is weak because the same error may return next year. An eDesk acknowledgement without the submitted package is weak because the entity cannot prove what was sent.

Another weak pattern is excessive reliance on one expert. If one person understands the register and everyone else waits for that person, the process has key-person risk. The register should be documented enough that another competent employee can continue the process. Backup is not only about access. It is about understanding definitions, sources, correction logic and submission evidence.

Weak evidence also appears when third-party preparers hold the working knowledge. If a consultant can explain the register better than the supervised entity, management has not retained enough control. The entity may use external support, but it should own the data and the reasoning.

How to improve source systems

The most durable improvement is to capture DORA-relevant data at the point of contract approval. Procurement intake should ask whether the service is ICT, which business function it supports, whether it supports a critical or important function, whether it uses subcontractors, where services are provided, whether cloud is involved, what identifiers are available, and which internal owner is accountable. Legal should ensure that contract terms give the entity enough information and rights to maintain the register.

ICT inventory should be linked to contract records. A system should not be used without a known provider or internal owner. A provider should not be listed without knowing which systems or services it supports. Finance vendor lists should be reconciled periodically because paid invoices may reveal services that governance inventories missed.

Business owners should certify their services periodically. Certification does not need to be bureaucratic. It can be a short confirmation that service description, provider, function mapping, criticality, subcontracting and contact details remain current. The point is to prevent silent drift.

Resubmission governance

If the CSSF or ESA process requires resubmission, the entity should treat it as a controlled event. The team should preserve the original package, validation output, corrected fields, rationale, approvals and resubmitted package. It should not overwrite evidence in place. Version history matters because supervisory reviewers may ask what changed and why.

Resubmission should also trigger root-cause review. Was the error caused by misunderstanding of instructions, source-system limitation, missing provider data, late business-owner response, file-generation defect or manual mistake? Each root cause has a different remediation. Without classification, the entity may fix the immediate file but not the process.

Management should be informed of material resubmissions, especially if they involve critical services, repeated errors or late deadline pressure. A resubmission is not automatically a failure, but less visible resubmission risk is a governance weakness.

Evidence retention and audit trail

The evidence file should be retained in a way that supports future review. It should include the source register, data dictionary, validation scripts or checks, generated CSV files, zip package, eDesk upload evidence, messages, errors, corrections, approvals, management sign-off and post-submission closure note. If files are stored in separate locations, the index should point to each location.

Audit trail should show sequence. When was the source frozen? When were validations run? Who approved corrections? When was the package generated? Who uploaded? What messages came back? Who reviewed them? When was the process closed? Sequence matters because a correct final file does not prove controlled process if no one can reconstruct how it was produced.

The audit trail should also capture limitations. If a provider identifier was unavailable and a temporary treatment was used, record the limitation and remediation. If a field was manually corrected, record source-system follow-up. Honest limitation tracking is more credible than silent assumptions.

Training and role awareness

People who contribute to the register should understand why their data matters. Procurement should know that vendor names and subcontracting details affect regulatory reporting. Business owners should know that function mapping affects criticality and resilience analysis. ICT should know that system inventories feed DORA oversight. Legal should know that contract terms affect evidence. Compliance should know that eDesk submission is only the final step.

Training should be role-specific. A one-hour general DORA session is not enough for data owners. Use short practical modules: how to classify ICT services, how to identify subcontractors, how to map functions, how to review provider names, how to document exclusions, and how to respond to validation errors. The best training uses examples from the entity's own previous errors.

Training completion should be linked to quality. If trained owners still submit incomplete data, the issue may be unclear definitions or poor source systems. Training is one control, not the whole answer.

Final board-level summary format

A useful board summary can fit on one page. It should show submission status, population size, number of critical or important function arrangements, top providers by critical service count, third-country exposure, cloud concentration, unresolved data-quality issues, validation error trend, resubmission status, incidents linked to registered providers, and remediation priorities. This gives directors a practical view without burying them in technical detail.

The board should receive exceptions. If everything is green, the report should still explain why management is confident. Which reconciliations were performed? Which validation checks passed? Which issues were fixed? Which limitations remain? A good board summary is not a decorative compliance report. It is a challenge document.

Closing thought

The register's value compounds over time. The first year may feel like data collection. The second year should reveal trends. The third year should support strategic decisions about provider concentration, cloud dependency, outsourcing quality and resilience investment. If the entity treats each submission as isolated, it loses that value. If it keeps improving the source process, the register becomes a genuine tool for digital operational resilience.

Final maturity model

A basic register process can produce a file for eDesk, but it depends on manual collection and deadline pressure. An intermediate process has a data dictionary, owner confirmations, validation logs, submission evidence and issue tracking. A mature process has source-system capture, procurement integration, outsourcing alignment, business-continuity linkage, management dashboards, audit testing and continuous improvement after each validation cycle. The entity should know which level it currently occupies.

Moving from basic to intermediate usually requires ownership clarity. The organisation must know who owns provider data, contract data, ICT service descriptions, function mapping, criticality, subcontracting, location, validation, eDesk submission and issue remediation. Ownership gaps are the most common reason registers become late or unreliable. Once owners are assigned, recurring deadlines become easier because the work is distributed to the people who control the facts.

Moving from intermediate to mature requires integration. Procurement must collect register data before contract signature. ICT asset management must align systems with providers. Outsourcing governance must use the same provider and service definitions. Business continuity must use the same critical service population. Incident management must update provider risk. Internal audit must test source-to-register and register-to-source completeness. At that stage, the register is no longer a standalone regulatory file. It is part of the entity's operational nervous system.

The maturity model should be reviewed after each submission. If validation errors fall, source records improve, owners respond faster and management uses the data, the process is maturing. If the same errors recur and the same people rebuild the file manually, the process is stagnant. That conclusion should be reported honestly.

Practical questions for data owners

Data owners should be asked concrete questions. Is the provider legal name current? Is the contract active? Does the service description match actual use? Which business function relies on the service? Is the function critical or important? Is cloud involved? Are subcontractors known? Is the service provided from a third country? Did the arrangement change after the reference date? Is an exit plan available if the service supports a critical function? Which incident history is relevant?

These questions should be answered with evidence. A business owner may believe a service is non-critical, but the business impact analysis may show that its outage would stop customer activity. Procurement may believe a contract expired, but finance may still pay invoices. ICT may believe a service is internal, but a group provider may be contractually involved. Evidence resolves these contradictions.

Why the CSSF communication should change behaviour

The CSSF communication includes practical details that should change internal behaviour. The need for LEI onboarding should lead to early entity checks. The DORA Reporting role should lead to access governance. The statement that messages go only to the uploader should lead to message-monitoring controls. The plain CSV zip requirement should lead to technical packaging controls. The warning about more validation fields should lead to early validation. The third-party access warning should lead to stricter consultant access.

Each CSSF detail maps to an internal control. That is the difference between reading a communiqué and operationalising it. The entity should maintain a simple crosswalk: CSSF instruction, internal control, owner, evidence and review date. This crosswalk makes supervisory expectations visible and reduces the risk that important details sit only in a project email.

Final sign-off checklist

Before closing the cycle, the accountable manager should confirm that the population reconciliation is complete, critical arrangements are reviewed, validation errors are resolved or escalated, eDesk evidence is retained, post-submission messages are monitored, ESA follow-up resources are available, third-party access is controlled, and recurring source defects have remediation owners. The sign-off should include limitations, not hide them.

If limitations remain, they should be classified. Some limitations affect current submission accuracy. Others affect future efficiency. Others affect broader ICT risk management. Classifying limitations helps management prioritise. A mature sign-off is not a blanket statement that everything is perfect. It is a documented decision that the entity understands the current state and has a plan for remaining weaknesses.

The final practical measure is whether next year's register can be produced from improved source records rather than copied from this year's emergency file. If yes, the control environment improved. If no, the same operational risk remains.

LEI and eDesk access

The CSSF says the LEI of the submitting financial entity has to be communicated beforehand and that the DORA Reporting role must be assigned to at least one dedicated employee. This is an access-control issue. The entity should document who has access, who uploads, who reviews, who receives messages, who is backup, and how access is revoked when people change roles.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Submission messages and inbox risk

The CSSF notes that upload and validation messages are addressed only to the person who uploaded the register, not every person with the role. That creates inbox risk. If the uploader is absent, validation messages can be missed. The operating model should require message forwarding, shared evidence storage, backup monitoring and escalation before the deadline.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Plain CSV zip structure

The CSSF highlights that the register must be submitted in plain CSV files enclosed in a zip file following predefined folder structure and naming convention defined by the ESAs. This is a technical control as much as a regulatory requirement. Teams should version the source file, generated CSVs, zip package, validation output and submitted evidence.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Validation and rejection readiness

The CSSF warns that validation checks apply to more data fields in 2026 and that accepted registers from previous years may be rejected. The entity should therefore run validation early, not at deadline. Errors should be classified by missing data, format error, identifier issue, relationship mismatch, provider data defect, contract data defect or interpretation question.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

ESA re-validation risk

The CSSF says accepted registers may be submitted to ESAs for additional validation and that ESA errors can require correction and resubmission. This means the team should remain available after local acceptance. A register is not operationally closed until downstream validation risk is resolved or monitored.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Third-party assistance and access risk

The CSSF warns that granting eDesk access to a third party can expose other entity data beyond the register and reminds entities that they remain responsible for sensitive data protection. If consultants help, the entity should minimise access, document confidentiality, control files shared, review submissions internally and avoid delegating accountability.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Data dictionary

Every register field should have a definition, source, owner and validation rule. Contract identifiers, provider identifiers, service descriptions, function mappings, country fields, dates, criticality, subcontracting references, LEIs and cloud indicators should not be improvised during submission week. A dictionary makes recurring annual submissions easier.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Critical or important functions

Mapping ICT services to critical or important functions is one of the most judgmental parts of the register. The entity should document why a service supports a critical or important function, which business process relies on it, what impact outage would create, and whether alternative arrangements exist. This judgment should align with business impact analysis and outsourcing governance.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Provider and subcontractor data

Provider data should be controlled. Legal names, identifiers, country, group relationships, subcontractors and service descriptions often differ across procurement systems and contracts. The register should not rely on casual vendor names. It should use controlled provider records and capture changes.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Contract population

The register should include relevant contractual arrangements up to the reference date. The entity should reconcile procurement records, outsourcing registers, contract management systems, ICT inventories, cloud inventories, finance vendor lists and business-unit confirmations. A single source rarely captures everything.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Definition of ICT services

The CSSF's guidance on ICT services under DORA helps prevent perimeter mistakes. Teams should assess whether a service is an ICT service under DORA and document the conclusion. Borderline services should be logged, because recurring debate wastes time and creates inconsistent reporting.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Change management

The register is not an annual panic task. New ICT arrangements, amendments, terminations, subcontracting changes and provider migrations should update the register data during the year. Annual submission should then be a controlled extraction, not a reconstruction.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Board and management reporting

Management should see register readiness metrics: population completeness, missing provider identifiers, unresolved validation errors, critical services without exit plans, third-country provider exposure, cloud concentration, subcontracting uncertainty and submission status. This turns the register into ICT risk governance.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Business continuity connection

The register should connect to business continuity and resilience testing. If a provider supports a critical function, the entity should know recovery expectations, alternative process, incident contacts and exit feasibility. Register data that is disconnected from resilience planning is underused.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Incident management connection

ICT incidents should be compared with register data. If an incident involves a provider missing from the register, the population is incomplete. If a provider is in the register but incident contacts are unclear, provider governance is weak. Incident lessons should update register quality.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Procurement discipline

Procurement should collect DORA-relevant data before contract signature. Waiting until reporting season to ask providers for LEIs, subcontractors, service countries and function mapping creates delay. Procurement checklists should reflect the register fields.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Legal and contract review

Legal teams should ensure contracts provide enough information and rights for DORA oversight, audit, access, termination, subcontracting notification and incident communication. The register is easier to maintain when contracts are structured consistently.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Internal audit test

Internal audit can sample register entries and trace each to contract, provider due diligence, service owner, function mapping, business continuity record, risk assessment and validation evidence. Audit should also sample contracts from procurement and verify whether they appear in the register.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Deadline governance

A deadline plan should include data freeze, review period, validation period, correction period, management sign-off, submission window, message monitoring and ESA follow-up availability. The CSSF's recommendation not to wait until the end of the submission period should be converted into internal cut-offs.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Common failure patterns

Common failures include missing contracts, inconsistent provider names, stale subcontractor data, unclear criticality, wrong date formats, missing LEIs, single-person upload dependency, consultant access risk, no post-submission monitoring and weak source remediation after validation errors.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Remediation roadmap

A practical roadmap starts with inventory reconciliation, then field ownership, then validation, then management reporting, then source-system improvement. Do not treat every error as a manual fix. Repeated manual fixes should become source remediation items.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Evidence pack

The evidence pack should include scope decision, LEI confirmation, eDesk role evidence, source register, CSV package, validation logs, corrections, submission acknowledgement, messages, management sign-off, issue log and post-submission follow-up. This pack should be retained for supervisory review.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.

Final operating view

The DORA register should become a living operational map. A strong entity can use it to understand concentration, critical dependencies, provider risk and resilience gaps. A weak entity treats it as an annual file and discovers missing facts under deadline pressure.

The practical evidence should identify owner, source record, validation rule, exception, remediation and sign-off so the register can be defended without relying on memory.