The ICT Third-Party and Outsourcing Register: Keeping It Current from the Architecture
An ICT third-party register is useful only if it stays accurate and can be queried. Kept in a spreadsheet, it drifts as soon as an application or a provider changes. In ArchiLU, the DORA register of information is produced from the chain of functions, applications, providers and contracts; the entity remains responsible for its completeness.
Updated on
A required register that is rarely kept current
A regulated EU entity keeps some form of register of its ICT providers and outsourcing arrangements. DORA makes it a register of information on contractual arrangements for ICT services provided by third-party providers. The CSSF sets expectations for outsourcing documentation at the entities it supervises. For essential and important entities, NIS2 adds supply chain security.
Producing the register once is rarely the hard part. Keeping it accurate is: an application is retired, a provider changes, a subcontractor appears, a function is reclassified. In a spreadsheet, these changes wait for someone’s quarterly update.
This text supports documentation work; it is not legal advice. The exact text and how it applies to your entity are matters for your compliance function and qualified counsel.
Why a spreadsheet register drifts
The spreadsheet copies facts that live elsewhere: the application inventory, the contracts, the criticality levels. Each copy can fall out of step. The most useful relationships, such as the function a provider supports or the subcontractor behind it, end up as free text that cannot be counted or reconciled.
In a repository, the register relies on the objects that hold these facts. The function points to its applications, the application to its ICT services, the service to its provider and its contract. When an application’s provider changes, the chain, the exposure analysis and the register read the same object. Someone still keeps the data up to date; reconciling several copies disappears.
From critical functions to providers and contracts
The model follows the logic of the regulation. Critical or important functions such as payments, client onboarding, fund administration or regulatory reporting are supported by applications. Each application relies on ICT services provided by third parties: software vendor, hosting provider, cloud provider, outsourced operator.
In ArchiLU, the function catalogue brings together their criticality, owner and the applications that serve them. A dedicated view follows relationships down to the suppliers and distinguishes an application’s supplier from the provider of an ICT service. Contracts covering these services appear in the chain. Having a contract on file is not enough: its scope must be documented.
The repository does not classify functions on the entity’s behalf and does not decide whether an arrangement falls within the register’s scope. Those judgements remain with the risk and compliance functions.
- The function, its criticality under DORA and its owner.
- The applications and ICT services that support it.
- The provider, its subcontractors, its substitutability and its exit plan.
- The contract, its end date, its renewal and its scope.
Subcontracting chains and concentration
The direct provider appears in the register. The subcontractor it depends on vanishes more easily from a spreadsheet: a note in a cell that nobody rereads. Arrangements that support critical or important functions still require knowledge of that chain.
In ArchiLU, the chain runs from the critical or important function down to the subcontractor and the contract. The exposure analysis starts from a provider, works up to the functions that depend on it and calculates its findings, including concentration. Each capability shows its dominant supplier and that supplier’s share. Each finding leads to a request, a risk or a Board decision.
Assessing a provider, the contractual position and any notifications remain with the entity and its advisers.
Producing the register and filling the gaps
In ArchiLU, the DORA register of information is produced as a regulatory report from the chain. Each missing item goes to its owner, who completes it, confirms it or accepts the gap with a reason. Each regulatory report is frozen with its fingerprint.
The register templates are set by Implementing Regulation (EU) 2024/2956. The entity remains responsible for the register’s completeness, for classifying its arrangements and for submitting it to the competent authority.
The auditor enters through their engagement and reads the same chain in read-only mode, limited to its scope and period. The engagement opens on an eight-part evidence dossier, frozen with its fingerprints.
Hosting and shared reading
A register of your critical functions and the third parties behind them shows your most exposed points. Each organisation has its own dedicated ArchiLU instance, hosted in the European Union; deployment on your infrastructure is an optional service, quoted separately.
Risk, compliance, procurement, IT and architecture work on the same objects and open their records from the chain view. The offers include unlimited users, readers included.
In ArchiLU
Start with the function. Find the provider.
In ArchiLU: Payments → Payment Engine → Maelis Paiements. Four screens in the same application, connected through the same objects.
Identify what must keep running.
The function catalogue shows criticality, ownership and documented links. Critical or important functions are distinguished from supporting functions.
Understand why it is critical and what supports it.
The Payments record explains the impact of an interruption, names its owner and links to the Payment Engine application. Missing relationships remain visible.
Identify the provider: Maelis Paiements.
The actor registry opens the Maelis Paiements provider record, with its identity, status and role. The dependency chain links this same provider to the Payment Engine application and the ICT maintenance service.
See the dependency. Spot what is missing.
The dedicated view links Payments to its application, ICT services and documented providers. Contracts appear when they cover these services; missing links are identified for each object.
Frequently asked questions
- Does ArchiLU produce the DORA register of information?
- Yes, as a regulatory report produced from the chain of functions, applications, ICT services, providers and contracts. Each missing item goes to its owner. The entity remains responsible for the register’s completeness, for classifying the arrangements and for submitting it to the competent authority.
- Why keep the register in an architecture repository?
- The register describes objects that change: applications, providers, contracts, functions. In the repository, their owners maintain these objects. When one changes, the chain and the register read the same data, with no copy to reconcile.
- How does the register relate to DORA, NIS2 and the CSSF?
- DORA requires a register of information on ICT service arrangements. NIS2 sets supply chain security requirements for essential and important entities. The CSSF sets outsourcing documentation expectations for the entities it supervises. All three rest on the same chain, from the critical function to the third parties; the legal detail is a matter for qualified counsel.
- Does the model show subcontractors and concentration?
- Yes. The chain runs from the critical or important function down to the subcontractor and the contract. The exposure analysis calculates concentration, and each capability shows its dominant supplier and that supplier’s share. Assessing each provider remains with the entity.