DORA Supplier Risk in Luxembourg: From Messy Supplier Lists to a Register You Can Defend

The practical problem is rarely that a security manager has never heard of DORA. The problem is the gap between a supplier list and a defensible operating model. Supplier names may exist. Contract owners may be known. Risk assessments may have been performed. But when a supervisor asks for a Register of Information that ties providers, services, contractual arrangements, supported functions, and criticality together, the gap becomes visible ^{1 3 4}.

This article explains what DORA Articles 28-30 require operationally, what the Register of Information is, and how to move from a static supplier list to a supplier-risk posture that can be maintained.

What DORA Articles 28-30 Require

DORA's third-party ICT risk framework is structured around several linked obligations.

Article 28: general principles and governance. Financial entities remain responsible for compliance when they use ICT third-party service providers, must manage ICT third-party risk as an integral component of ICT risk, and must maintain a register of information for contractual arrangements on ICT services ¹. Article 28 is also the basis for mapping ICT services to the functions they support and for assessing risks such as dependency and concentration ¹.

Article 29: preliminary assessment of concentration risk. Before entering into contractual arrangements for ICT services supporting critical or important functions, financial entities must assess whether the arrangement may create concentration risk or other relevant dependencies ¹.

Article 30: key contractual provisions. Contracts for ICT services, and especially those supporting critical or important functions, must include specified provisions such as service descriptions, locations, data-processing and security requirements, access and audit rights, termination rights, and cooperation duties ¹.

These are not only procurement requirements. They are governance, risk, contract, and evidence requirements that need a shared data model.

The Register of Information

The Register of Information is the structured record that ties the third-party ICT risk programme together. DORA Article 28(3) requires financial entities to maintain and update a register of information in relation to all contractual arrangements on ICT services provided by ICT third-party service providers ¹. Commission Implementing Regulation (EU) 2024/2956 sets the standard templates for the register, including the use of Annex I-IV templates at entity, sub-consolidated, or consolidated level ³.

CSSF has made the Register operationally concrete for Luxembourg entities. CSSF Circular 25/882 covers requirements on the use of ICT third-party services for financial entities subject to DORA, including practical modalities for register reporting, while Circular 25/883 amends Circular 22/806 for the ICT outsourcing framework ². CSSF has also communicated Register of Information submission timing through eDesk, including the 2026 submission window for entities under CSSF supervision ⁴.

The Register is a maintained data set. It should show providers, services, contractual arrangements, functions supported, criticality, entity relationships, and other fields required by the templates ³. It is strongest when it reflects a living operating process, not a one-time spreadsheet exercise.

Five Layers Between Supplier List and Defensible Register

A defensible Register of Information usually requires five layers of work.

1. Function mapping. Each ICT service should be linked to the business function or process it supports. Criticality classification depends on that connection, and DORA's third-party risk framework is built around ICT services supporting critical or important functions ¹.

2. Criticality tiering. Services do not carry equal risk. DORA distinguishes arrangements supporting critical or important functions, and that tiering affects due diligence, contractual provisions, and ongoing monitoring ¹.

3. Per-provider risk assessment. Article 28 requires ongoing ICT third-party risk management, and Article 29 makes concentration risk a specific assessment point before certain arrangements are entered into ¹. A financial entity with multiple critical services dependent on one hyperscaler has a different exposure from one with genuinely diversified dependencies.

4. Contractual compliance check. Article 30 sets contractual requirements for ICT services, with additional detail for services supporting critical or important functions ¹. Many contracts pre-date DORA. A systematic contract review is needed before gaps become supervisory findings.

5. Ongoing monitoring. DORA third-party risk is continuous. Providers change services, locations, subcontractors, ownership, risk posture, and contractual terms. The Register and the underlying risk file need to change with them ^{1 3}.

Where Cyvalent 360 Cyber Services and CORTEX AI Fit

Cyvalent 360 Cyber Services / CISOaaS provides the practitioner-led operating model: mapping ICT functions to third-party dependencies, tiering dependencies by criticality, reviewing provider risk, checking contractual provisions, preparing Register evidence, and coordinating remediation with business owners, procurement, legal, and risk stakeholders ^{1 2 3}.

CORTEX AI maintains the cross-mapped supplier-risk posture view. It tracks DORA obligations, supplier-risk evidence, contract-review status, control coverage, and the relationship between DORA requirements and the control framework the entity operates. As providers are added, contracts are updated, and assessments are refreshed, CORTEX AI helps show where the supplier-risk programme stands against Articles 28-30.

For entities that need a regulation-native Register process, Cyvalent 360 Cyber Services provides the managed work to build and maintain the Register evidence and operating routine. CORTEX AI supports the posture, evidence, and control-mapping layer that makes that work easier to govern over time.

DORA's third-party ICT risk requirements are in force. If you are working towards a CSSF-ready Register of Information, discuss the scoping and operating model with Cyvalent.

References

[1] European Parliament & Council. Regulation (EU) 2022/2554 (DORA) — Art. 5 (governance/management body), Arts. 17-23 (incident management), Arts. 24-27 (testing/TLPT), Arts. 28-30 (third-party ICT risk; Art. 28(3) Register of Information), Art. 64 (applies 17 Jan 2025). Status/date: applicable from 17 Jan 2025. Source: EUR-Lex. https://eur-lex.europa.eu/eli/reg/2022/2554/oj

[2] Luxembourg / CSSF. Loi du 1er juillet 2024 implementing DORA / transposing Directive (EU) 2022/2556; Circular CSSF 25/882; Circular CSSF 25/883 amending Circular CSSF 22/806 — CSSF and CAA competent authorities; Circular 25/882 on requirements for ICT third-party service use by DORA entities; Circular 25/883 amending Circular 22/806. Status/date: law of 1 July 2024; CSSF circulars published 2025. Source: CSSF. https://www.cssf.lu/en/regulatory-framework/ and https://www.cssf.lu/en/Document/circular-cssf-25-882/

[3] European Commission. Commission Implementing Regulation (EU) 2024/2956 — standard templates for the Register of Information under DORA Article 28(3), including Annex I-IV templates. Status/date: adopted 29 Nov 2024. Source: EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/2956/oj

[4] CSSF. DORA — Submission timeframe for register of information — eDesk Portal open as of 11 February 2026 — CSSF communication on annual Register submission and 2026 eDesk submission window. Status/date: published 11 Feb 2026. Source: CSSF. https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/