From Spreadsheet to Living Model: The ICT Third-Party and Outsourcing Register as Enterprise Architecture

The register everyone keeps, and almost nobody keeps current

If you are a regulated EU entity — a bank, a payment or investment firm, a fund actor, an essential or important entity under the network-and-information-security regime — you are expected to keep some form of register of your ICT third parties and outsourcing arrangements. DORA frames it as a register of ICT third-party arrangements; the CSSF has long-standing outsourcing documentation expectations for Luxembourg-supervised entities; NIS2 adds supply-chain security expectations on top. Different words, one recurring artefact: a list of who you depend on for what.

The trouble is rarely producing the register once. The trouble is keeping it true. Most registers live in a spreadsheet, and a spreadsheet is a snapshot: the day it is finished it begins to drift. An application is decommissioned, a provider is swapped, a sub-contractor is added behind a provider, a function is reclassified — and the file does not move, because updating it is somebody's quarterly chore rather than a by-product of how the organisation actually changes. This article is about closing that gap by treating the register not as a document but as a view of a living architecture model. It is a documentation aid, not legal advice, and we will not quote specific article numbers or dates — the precise text and its application to your entity are for your compliance function and qualified counsel.

Why a spreadsheet register drifts — and a model does not

A spreadsheet register has a structural flaw: it is a copy. It restates, in its own cells, facts that already live elsewhere — the application inventory, the supplier contracts, the criticality ratings. Every copy of a fact is a fact that can fall out of sync, and a register is nothing but copies. Worse, the relationships that matter most — which function this provider actually supports, which sub-contractor sits behind it — are flattened into free text, where they cannot be queried, counted or reconciled.

A model inverts that. Instead of restating facts, it links the objects that hold them: a critical or important function points to the applications that support it; each application points to the third parties and outsourcing providers behind it; each provider can point to its sub-providers. The register becomes a view over those links rather than a separate file. Change the supplier on an application once, and the dependency map, the concentration count and the register entry all reflect it, because they are all reading the same object. The honest limit stands: someone still maintains the model, and it is only as good as the data entered. What disappears is the silent reconciliation tax of several drifting copies.

• A spreadsheet restates facts; a model links the objects that hold them
• Relationships (function-to-provider, provider-to-sub-provider) become queryable, not free text
• One change to a supplier updates dependency, concentration and register views together
• Still your data to maintain — but no longer several copies to reconcile by hand

Mapping critical functions to applications to third parties

The model has a natural shape that mirrors what the regulations care about. At the top sit the critical or important functions — payments, customer onboarding, fund administration, regulatory reporting. Each function is supported by one or more applications. Each application runs on technology, moves data, and depends on third parties: the software vendor, the hosting or cloud provider, the outsourced operator. Laid out as a connected model rather than a flat list, this lets you follow any critical function downward to everything it leans on.

Each object carries the attributes that make the register meaningful — owner, criticality, hosting location, the nature of the arrangement — and, crucially, the links to what sits above and below it. With that in place the questions a supervisory or audit conversation asks become queries rather than research projects: which third parties support this critical function, which applications would be affected if this provider failed, and which arrangements support more than one critical function. The repository organises and connects this picture; it does not classify your functions for you or judge whether an arrangement is in scope — those determinations stay with your risk and compliance functions and your counsel.

• Critical or important functions linked to the applications that support them
• Each application linked to its third parties and outsourcing providers
• Attributes that matter to a register: owner, criticality, hosting, arrangement type
• Supervisory questions answered as queries over the model, not as fresh research

Sub-outsourcing chains and concentration, made countable

The hardest part of a register to keep honest is the depth behind a provider. A first-tier provider is visible; the sub-contractor it relies on — the fourth party in your chain — is the one that quietly disappears from a spreadsheet, captured at best as a note in a cell that nobody revisits. Yet that is exactly where modern supply-chain risk concentrates, and exactly what supervisors increasingly ask about.

In a connected model the chain is a path, not a note. A provider object can point to the sub-providers behind it, so you can trace a critical function not just to its first-tier provider but down the chain. Once the links exist, concentration becomes arithmetic rather than assertion. Follow every critical function to the providers — and sub-providers — behind it and the clusters surface: the provider sitting behind a disproportionate share of what matters, the platform that became load-bearing without a decision, the fourth party two of your supposedly independent providers secretly share. This is precisely the analysis DORA's concentration-risk work and NIS2's supply-chain expectations both circle. To be clear about the boundary: the model reveals and documents the chain and the clustering; the assessment of any provider, and the contractual and notification posture around it, remain yours and your counsel's.

• Sub-outsourcing chains modelled as paths, traceable beyond the first tier
• Concentration counted, not asserted, where many functions share a provider
• Hidden fourth-party overlap between nominally independent providers surfaced
• Documents and reveals the chain — the risk assessment stays with your functions

Keeping the register live: change flows through the model

A register earns its keep at the moment something changes, because that is when a stale one becomes dangerous. The value of holding it as a model is that the same act that changes reality updates the register. When the architecture team retires an application, swaps a hosting provider or onboards a new outsourced service in the model, the register view changes with it — there is no separate file waiting for a quarterly catch-up that may never come.

That also makes the register defensible. Because the model is versioned, you can show, from a single source, what your dependency picture looked like at a given point, what changed, and when — the difference between a narrative you reconstruct under deadline pressure and one you can evidence on demand. We are precise about what this is and is not: an EA repository keeps the documentation current and connected and makes the evidence easier to assemble. It does not perform the legal classification, run your third-party due diligence, or guarantee that every required register field is complete. The completeness and legal sufficiency of the register stay your institution's responsibility, with your compliance function and qualified counsel.

• The change that updates reality updates the register view — no separate quarterly chore
• Versioned model: show what the dependency picture was, what changed, and when
• Evidence assembled on demand, not reconstructed under deadline pressure
• Legal completeness and sufficiency of the register stay the institution's responsibility

Why a sovereign, EU-hostable or on-prem model fits regulated entities

A register of your critical functions and the third parties behind them is close to a blueprint of where you are most exposed — which makes where it lives a question in its own right. Three properties of ArchiLU matter more here than almost anywhere else. It can be hosted in the EU or on-premise, so that sensitive map does not leave a boundary you control. It is available natively in French and English, which fits a regulated European market where the same model has to serve a French-speaking management body and an English-language audit or supervisory exchange. And it is licensed for unlimited users, so the risk, compliance, IT and architecture people who all need to read the same dependency picture are not gated by a seat count.

The honest boundary, restated because it matters: ArchiLU is an enterprise architecture repository that organises and connects this data and makes the evidence easier to assemble and keep current. It is not a regulatory register product, not a compliance certification, and we are transparent about certifications we do not yet hold. What it gives a regulated entity is a sovereign, multilingual, connected model of its critical functions, applications and third-party chains — the backbone the DORA, NIS2 and CSSF conversations all rest on, while the register's legal completeness stays yours. For the fastest read on where your own practice stands across portfolio, governance and risk dimensions, the free EA Maturity Assessment scores ten dimensions and returns a prioritised plan in about ten minutes — a sensible first step before deciding whether to see the model on your own data in a demo.