guide

Last updated June 25, 2026

CSSF DORA ICT Third-Party Register of Information in Luxembourg: 2026 Submission and Control Guide

Direct answer

CSSF DORA ICT Third-Party Register of Information in Luxembourg: 2026 Submission and Control 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 ICT Third-Party Register of Information in Luxembourg: 2026 Submission and Control 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. Read it before assigning owners or responding to a supervisory request, so the evidence file matches the regulatory question.

The register is not only a compliance spreadsheet. It is the supervisory data backbone for ICT third-party dependency, critical or important functions, contractual arrangements, provider chains and concentration risk. A weak register can be rejected by validation checks, create supervisory follow-up and expose the entity's lack of control over its technology dependencies.

This guide is for Luxembourg DORA entities, ICT risk teams, compliance, vendor management, procurement, legal, data teams, management bodies and internal audit. It is not legal advice. Source check date: 20 May 2026.

Official sources used

This article uses official CSSF DORA and ICT third-party sources, including the DORA entity page, Circular CSSF 25/882 and 2026 CSSF communications on the register of information submission timeframe and collection update.

• CSSF: ICT and cyber risk for DORA entities
• CSSF: Circular CSSF 25/882
• CSSF: DORA register submission timeframe, eDesk open as of 11 February 2026
• CSSF: DORA register submission for third-country branches
• CSSF: DORA register collection update
• CSSF DORA incident reporting guide
• CSSF outsourcing arrangements guide

Treat the register as an operating record

The DORA register of information should not be treated as a year-end regulatory upload prepared by one person in compliance. It should be the controlled record of ICT service dependencies used by the entity. If the register is assembled only at submission time, data quality problems are almost inevitable.

A usable register needs inputs from procurement, ICT, security, risk, legal, finance, business owners and group functions. Contracts may sit in legal repositories, provider names in procurement systems, service descriptions in IT architecture files and criticality assessments in risk tools.

The operating model should define who owns each field, who validates changes, who signs off the full register and how errors are corrected before submission.

The best register process is continuous. Annual submission then becomes a controlled extract rather than a discovery project.

Confirm DORA scope before preparing the file

DORA applies broadly to financial entities in the EU, but the precise local submission duties depend on entity type, supervision, group structure, ECB direct supervision and CSSF communications. Scope should be confirmed before data work begins.

The CSSF DORA page explains that DORA applies since 17 January 2025 and covers numerous financial-entity types. The 2026 CSSF communication excludes entities under direct ECB supervision from the described CSSF submission perimeter and adds third-country branch clarifications.

A scope memo should identify the legal entity, DORA category, CSSF supervisory status, ECB direct-supervision status where relevant, consolidated or sub-consolidated reporting level, and branch considerations.

This memo prevents the register team from preparing the wrong submission or missing a required level.

Use the 31 December 2025 reference date properly

For 2026, the CSSF communication states that the reference date is 31 December 2025 and the register should contain contractual arrangements contracted until that date. This cut-off matters for data completeness.

The entity should decide how to treat contracts signed, terminated, amended or migrated around the reference date. It should keep evidence of status, effective dates and renewal terms.

A contract inventory freeze can help. Capture the population as at the reference date, then separately track changes after that date for future updates.

If the entity discovers after submission that the reference-date inventory was wrong, document the correction logic and remediation.

Build a single contract population

A common register failure is fragmented contract population. ICT knows about platforms, procurement knows purchase orders, legal knows master agreements, finance knows invoices and business teams know tools used in practice. The register needs one reconciled population.

Reconciliation should compare procurement records, accounts payable, software inventories, cloud accounts, ICT asset registers, vendor-risk tools, outsourcing registers and business-owner declarations.

Differences should be investigated. A paid vendor with no contract record may indicate missing documentation. A contract with no current use may be terminated or dormant. A tool used by business with no procurement record may be shadow ICT.

The reconciled population is the base of data quality.

Classify ICT services consistently

The register depends on service classification. Teams should define a taxonomy that distinguishes cloud hosting, SaaS, data centers, network services, cybersecurity tools, core banking platforms, payment gateways, reporting tools, development tools, customer platforms, data analytics and support services.

Inconsistent service names create duplicate records and validation issues. One team may call the same service cloud platform, infrastructure hosting or production environment. The register needs controlled vocabulary.

Classification should also connect the ICT service to the business function it supports. A provider name alone is not enough.

A consistent taxonomy makes concentration analysis possible.

Identify critical or important functions supported by ICT

DORA focuses heavily on ICT services supporting critical or important functions. The register should therefore connect provider arrangements to functions and business impact.

A critical function assessment should consider customer impact, regulatory deadlines, transaction processing, financial loss, market integrity, data availability, operational continuity and substitutability.

The service may not be critical by itself but may support a critical or important function. For example, identity access management, transaction monitoring, payment infrastructure, reporting tools or client portals can all support important operations.

Function mapping should be signed off by business and risk, not only ICT.

Document provider and group relationships

The register should distinguish legal provider, service brand, group entity, reseller, subcontractor and cloud infrastructure provider. Confusing these relationships can create wrong entries.

A SaaS service may be contracted with one legal entity, hosted by another cloud provider and supported by group affiliates. The entity needs enough information to populate the register accurately and understand dependency chains.

Legal entity names, identifiers, addresses, countries and contract references should be verified against documents. Do not rely on marketing names alone.

Provider hierarchy matters for concentration and supervisory analysis.

Control subcontracting data

ICT third-party services often involve subcontracting. DORA and related technical standards emphasize visibility of arrangements and dependencies. The register process should capture relevant subcontractors and chains where required by the template and guidance.

Vendor questionnaires, contract appendices, security documentation and provider portals may all contain subcontractor information. That data should be reconciled and updated when providers change subcontractors.

Subcontracting is not only a legal issue. It affects data location, resilience, incident handling, concentration and exit planning.

If subcontractor data is unavailable, escalate early. Waiting until submission week is too late.

Prepare for validation errors

The CSSF March 2026 communication warned that validation checks would be applied to more data fields and that a register accepted in a previous year might be rejected. This is a practical warning about data quality.

Entities should run pre-validation as early as possible, maintain an error log and assign owners for corrections. Common issues can include missing mandatory fields, inconsistent identifiers, invalid formats, mismatched dates, duplicate records or taxonomy errors.

Do not treat validation as a purely technical issue. A validation error may reveal a real governance gap, such as missing contract dates or unclear provider identity.

The correction process should preserve evidence of what changed and why.

Plan resources through April

The March 2026 CSSF communication advised entities to ensure availability of relevant resources throughout April because ESA additional quality controls could lead to refusal and re-submission before end-April. That is a resource-planning instruction, not just an administrative note.

The register team should keep business, ICT, procurement, legal and data owners available after initial CSSF submission. If the ESA refuses entries, the entity may need rapid corrections and resubmission.

A team that disbands after upload creates operational risk. Keep the correction tracker open until acceptance and post-submission follow-up are complete.

Resource planning should also include management awareness of possible late-stage issues.

Use eDesk evidence as part of the control file

Submission through eDesk creates evidence that should be retained: submission date, submitted file version, validation messages, confirmation, rejection notices, resubmission records and correspondence.

The control file should link the submitted file to the approved source data. If the entity later needs to explain what was submitted, it should not rely on a local user's downloads folder.

Version control matters. Label the pre-submission file, submitted file, corrected file and final accepted version. Preserve the error log between versions.

This evidence is useful for internal audit and next year's preparation.

Manage third-country branch considerations

The CSSF February 2026 communication about third-country branches of credit institutions having their head office in a third country set a 30 June 2026 best-effort deadline for these entities, following ESA clarification. Branches should treat this as a structured onboarding of the register requirement rather than a casual extension.

Branch teams may depend on head-office systems, global contracts and group vendor data. They should start early to map which ICT arrangements support the Luxembourg branch and which records sit outside Luxembourg.

The branch file should explain how global arrangements are used locally, who owns data, and how the branch obtains the information needed for the CSSF register.

Best effort still requires evidence of effort, testing and remediation.

Connect the register to notification of new critical ICT arrangements

Circular CSSF 25/882 and CSSF DORA materials describe notification requirements for planned ICT arrangements supporting critical or important functions for certain entities not under direct ECB supervision. The register process and notification process should share data.

A planned arrangement should enter the internal inventory before the contract takes effect. If it supports a critical or important function, the notification timeline should be assessed early.

The CSSF DORA page notes a three-month notice period before the planned contractual arrangement comes into effect, reduced to one month when resorting to a Luxembourg support PFS governed by Article 29-3 LFS, for the described cases. Teams should verify the current form and communication channel.

A register that only records live contracts may miss pre-contract notification duties.

Assign field ownership

Every register field should have an owner. Contract date may belong to legal, provider ID to procurement, service description to ICT, critical function mapping to risk and business, data location to security, and submission formatting to regulatory reporting.

Without field ownership, errors bounce between teams. With ownership, correction is faster and accountability clearer.

A field-owner matrix should also define evidence sources. If two systems disagree, the matrix should state which system is authoritative or how conflicts are resolved.

Field ownership is one of the simplest ways to improve register quality.

Reconcile register with outsourcing and procurement records

DORA ICT third-party registers and outsourcing registers are related but not identical. The entity should reconcile them to avoid missing dependencies or double counting.

Some business-process outsourcing arrangements may include ICT components. Some ICT third-party services may not be outsourcing under the amended Circular 22/806 perimeter. The entity needs mapping rather than assumption.

Procurement records can reveal paid ICT services not present in risk systems. Outsourcing registers can reveal critical functions supported by ICT providers. Architecture inventories can reveal technical dependencies not obvious from contracts.

A reconciliation report is strong evidence for supervisory and audit purposes.

Keep management body oversight practical

DORA emphasizes governance and management body accountability for ICT risk. The register should therefore feed meaningful oversight, not just technical reporting.

Management reporting should show material ICT dependencies, critical function support, concentration, unresolved data-quality issues, validation status, late owner responses and remediation progress.

The management body does not need every row of the register, but it needs decision-grade summaries and exceptions. It should know whether the entity can explain its ICT third-party risk.

Oversight evidence includes minutes, dashboards, challenge questions and remediation tracking.

Handle cloud arrangements with service clarity

Cloud arrangements can be complex because one provider may support infrastructure, platform, software, storage, analytics, security or business applications. The register should describe the service accurately rather than merely saying cloud.

A cloud provider may be the direct contractual counterparty or an underlying subcontractor of a SaaS provider. The register should reflect the contractual reality and dependency chain required by the applicable template.

Service clarity affects criticality, data location, exit planning and concentration analysis. A vague cloud label is not enough for risk management.

The entity should also maintain architecture evidence that explains what the service does.

Prepare an annual improvement loop

After each submission, the entity should run a lessons-learned review. What errors occurred? Which fields were hardest? Which owners responded late? Which systems disagreed? Which contracts lacked data?

The review should create remediation actions before the next cycle. Examples include contract template changes, procurement intake changes, mandatory service classification, better provider master data or automated validation.

An annual loop turns the register from a stressful filing into a maturing control.

Internal audit can use the loop to test whether past problems were actually fixed.

Avoid common anti-patterns

Common anti-patterns include treating the register as a compliance-only spreadsheet, relying on vendor marketing names, ignoring subcontractors, excluding intragroup ICT services, failing to map critical functions, waiting until submission week, and not preserving validation evidence.

Another anti-pattern is assuming that because a contract is small, the service is unimportant. A low-cost authentication, monitoring or reporting tool can support a critical process.

The opposite error is over-classifying everything as critical without analysis. That creates noise and weakens management focus.

The remedy is disciplined classification, evidence and review.

Build a register readiness calendar

A readiness calendar should begin months before submission. It should include population freeze, owner attestations, data-quality checks, management review, test upload where possible, correction window, submission, ESA follow-up window and lessons learned.

For the 2026 general CSSF collection, the window from 11 February to 31 March made early preparation especially important. Future cycles should not rely on last-minute assembly.

The calendar should also align with contract renewal and procurement cycles. New contracts should produce register-ready data at signature rather than at year end.

A calendar makes the register a planned control, not an emergency project.

Create a data dictionary before validation starts

A register data dictionary explains each field in business language, identifies the source system, field owner, allowed values and evidence required. Without a dictionary, each team may interpret the same field differently.

The dictionary should define provider legal name, service type, contractual arrangement, critical function mapping, dates, entity level, location, subcontracting information and status. It should also explain how to handle unknown, not applicable and group-level values.

A data dictionary reduces validation errors and makes onboarding new contributors easier. It also helps internal audit test whether the same rule was applied across the register.

When ESA or CSSF validation expectations change, update the dictionary and communicate the change.

Use attestations for business-owner accountability

Business owners understand how services are used in practice. Their attestation should confirm that the listed arrangements are complete for their area, service descriptions are accurate, criticality mapping is reasonable and post-reference-date changes have been flagged.

Attestations should not be empty signatures. Give owners a clear extract, ask specific questions and require exceptions to be logged. The central register team should challenge inconsistent responses.

This process prevents the register from becoming a central compliance guess. It also gives management a stronger basis for submission confidence.

Attestations should be retained with the control file.

Track correction root causes

A validation error log should not end at fixing the cell. The team should identify why the error happened: missing contract field, inconsistent taxonomy, wrong owner, system limitation, unclear guidance, late provider data or manual transcription.

Root-cause tracking supports next-cycle improvement. If many errors come from provider identifiers, improve provider master data. If many errors come from criticality mapping, improve function-owner training.

This is how the register matures from manual rescue to controlled process.

A short post-submission root-cause report is useful for management and internal audit.

Protect continuity during register remediation

Register remediation can involve contract review, provider outreach and data clean-up. Teams should avoid disrupting live services while correcting records. The goal is better supervision and control, not operational confusion.

Where gaps are serious, such as missing contracts for critical services or unclear provider chains, the entity should escalate and remediate quickly. But even then, actions should be coordinated with service owners and continuity plans.

A remediation plan should prioritize high-risk gaps first, define interim controls and avoid overwhelming business teams with low-value data requests.

This keeps register work aligned with operational resilience.

Integrate the register with new-contract intake

The easiest way to improve next year's register is to capture register-ready data when new ICT contracts are created. Procurement intake should require service classification, legal entity, function mapping, criticality, data location, subcontracting information and owner before signature.

If this data is captured only after year end, the register team must reconstruct it from documents and interviews. That is slower and less reliable.

Contract templates and onboarding questionnaires can include register fields. Legal and procurement can reject incomplete intake for arrangements likely to fall within DORA ICT third-party scope.

This makes the register an upstream control rather than a downstream reporting burden.

Reconcile entity-level and group-level views

Many Luxembourg entities operate inside larger banking, fund, payment or investment groups. ICT contracts may be signed at group level, while the Luxembourg entity consumes the service locally. The register process must reconcile group-level arrangements with entity-level use.

The local entity should know which group contracts support its operations, which functions they affect, what data is processed, which provider legal entities are involved and whether the arrangement is included at the correct reporting level.

A group register can help, but local management still needs enough evidence to understand and defend the Luxembourg entity's dependency. Blind reliance on head-office data is weak if the local service use is not mapped.

This reconciliation is particularly important for consolidated or sub-consolidated reporting and for branch structures.

Validate dates and lifecycle status

Dates create many register errors: signature date, start date, end date, renewal date, termination date, notice period and reference-date status. The entity should define which document proves each date and how to handle evergreen contracts or framework agreements.

A master agreement may have one date, a statement of work another, and a service activation date a third. The register team should not guess. It should record the date required by the template and preserve the source.

Lifecycle status should also be clear. Active, terminated, planned, dormant and migrated arrangements should not be mixed. The 31 December 2025 reference date requires a disciplined view of what was contracted by that date.

Date validation should be completed before submission week because missing dates often require legal or procurement research.

Control manual transformations

Even where source systems are strong, register preparation often involves manual transformations into required templates. Manual steps create risk: copied rows, changed formats, broken identifiers, deleted leading zeros, wrong date formats or accidental overwrites.

The team should document the transformation steps, preserve input and output files, restrict editing rights and run checks after transformation. If spreadsheet formulas are used, lock them or save a reviewed version.

For material submissions, a four-eyes review should compare a sample from source records to final submission fields. This is not bureaucracy; it is a control over regulatory data.

Manual-transformation evidence makes later questions easier to answer.

Link register data to contractual evidence

A register field without evidence is fragile. Provider name should link to the contract or master data. Service description should link to the statement of work or architecture record. Criticality should link to function assessment. Subcontracting should link to contract appendix or provider notice.

This evidence mapping does not mean attaching every document to the register. It means the entity can retrieve proof for each material field if challenged.

A document-reference column in the working file can be useful even if not submitted. It helps reviewers understand where facts came from and speeds correction.

Evidence mapping also deters unsupported assumptions.

Run a management sign-off that addresses known weaknesses

Management sign-off should not simply say the register is submitted. It should disclose known limitations, remediation actions, late provider data, unresolved questions and whether the register has passed internal validation.

A transparent sign-off allows management to take responsibility with context. If quality is imperfect, the decision record should explain why submission is still appropriate and how issues will be remediated.

This is especially important in the first years of a new reporting requirement, when data models and validation checks are still maturing.

A good sign-off protects both governance quality and institutional memory.

Turn CSSF or ESA feedback into permanent controls

If CSSF or ESA feedback identifies an error, the entity should not treat it as a one-off correction. It should ask whether the error reveals a systemic control weakness.

For example, a rejected provider identifier may indicate weak vendor master data. A rejected date field may indicate inconsistent contract lifecycle records. A missing critical-function link may indicate poor business-owner mapping.

The remediation should update the data dictionary, intake process, owner training or system controls so the same issue does not recur.

This converts supervisory feedback into continuous improvement.

Register readiness checklist

A register readiness checklist should turn the CSSF submission into a controlled process. The checklist below focuses on what can be evidenced.

FAQ

What is the CSSF DORA register of information? It is the structured register of contractual arrangements on the use of ICT services provided by ICT third-party service providers, maintained and updated by DORA financial entities and submitted to the CSSF where required.

What was the 2026 CSSF submission window? The CSSF communication stated that entities required to submit should do so between 11 February 2026 and 31 March 2026 via eDesk, excluding entities under direct ECB supervision. Third-country branches of credit institutions with head office in a third country received a 30 June 2026 best-effort deadline.

Why can a register be rejected? Validation checks can detect missing, inconsistent or incorrectly formatted data. The CSSF March 2026 update warned that checks would apply to more data fields and that a register previously accepted might be rejected.

Who should own the register? No single function can own all facts. A central owner should coordinate, but procurement, ICT, legal, risk, security, business owners and management need defined field responsibilities.

Is the register separate from outsourcing governance? It is related but not identical. DORA ICT third-party services, Circular 25/882 and amended Circular 22/806 outsourcing records should be mapped and reconciled.

Source risk and update note

DORA reporting expectations, eDesk processes, ESA validation checks and CSSF communication channels can change. This article was checked against official CSSF sources on 20 May 2026 and should be used as operational publication guidance, not legal advice.