CSSF and Enterprise Architecture: One Map for ICT, Outsourcing and Resilience Documentation

What the CSSF expects supervised entities to be able to show

If you are supervised by the CSSF — a bank, a PFS, an investment firm, a fund actor or another regulated entity established in Luxembourg — a recurring theme runs through the expectations placed on you: be able to show how your information systems work, who runs them, what you have outsourced, and how you would keep operating if something failed. The substance is recognisable even without quoting any particular circular: govern your ICT risk, document and oversee your outsourcing and ICT third-party arrangements, and be able to evidence your operational resilience.

This article is a preparation and documentation aid, not legal advice, and we will not cite specific circular numbers or dates — the precise text and its application to your entity type are for qualified counsel and your compliance function. What it shows is where enterprise architecture gives those expectations a backbone, because almost every one of them presupposes the same thing: that you can actually see your capabilities, your applications, your data flows and the third parties behind them, as one current and connected picture rather than scattered documents.

Every expectation rests on a prior question: can you show your architecture?

ICT risk management, outsourcing oversight and operational resilience all sound like separate files owned by separate people. They share a hidden prerequisite. You cannot assess the risk to a system you have not inventoried. You cannot oversee an outsourcing arrangement whose provider you cannot trace to the function it supports. You cannot evidence resilience for a critical function if you do not know what it depends on. The prior question — can you show your architecture, current and connected — sits underneath the whole supervisory conversation.

For most entities that knowledge exists, but scattered: a CMDB that drifted, network diagrams in a wiki, an outsourcing register in compliance, supplier contracts in legal, criticality ratings in a slide deck from last year. None of it joins up, and the join is exactly what a CSSF discussion needs. An enterprise architecture repository is, at heart, the place where those threads become one connected model — capabilities, the applications that support them, the data flows between them, the dependencies, and the third parties and outsourcing chains behind them.

• ICT risk management presupposes a real inventory of applications and systems
• Outsourcing oversight presupposes you can trace functions to their providers and sub-providers
• Operational resilience presupposes you know what a critical function depends on
• The common prerequisite is a connected, current view — not several drifting registers

Mapping capabilities, applications and data flows

The starting point is a model that links what the business does to what runs it. Business capabilities — payments, customer onboarding, fund administration, regulatory reporting — sit at the top. Each is supported by applications, each application runs on technology and holds or moves data, and the flows between applications are the arteries a resilience conversation cares about. A flat asset list cannot express that; a connected model can.

In an EA repository each object carries attributes that make it analysable — owner, criticality, hosting, the technology it runs on — and points to the capabilities it supports and the applications and data flows it connects to. With that in place you can answer the questions that recur in CSSF and resilience reviews: which applications support this critical or important function, where does its data go, and what would be affected if one link failed. The honest caveat applies as always: the model is only as good as the data you put in it, and the determinations stay with your risk, compliance and IT functions. The repository gives them sight, not a verdict.

• Capability map linking business functions to the applications that support them
• Application register with owner, criticality, hosting and technology footprint
• Data flows between applications, so you can follow where data moves
• A queryable model that makes critical-function dependencies visible, not guessed

Outsourcing chains and ICT third parties, made visible

Outsourcing oversight is one of the areas where CSSF expectations are most concrete, and one where reality drifts fastest from the paperwork. Entities are expected to know who they have outsourced to, which arrangements support critical or important functions, and — crucially — the chains behind them, where a provider itself relies on sub-providers. You cannot oversee an exposure you cannot see, and outsourcing exposure is precisely the kind that accretes invisibly: each individual arrangement looked reasonable when it was signed.

A mapped model turns that invisible accretion into something you can count. Link each application to the suppliers and outsourcing providers behind it, then trace each critical or important function down to those third parties and the sub-providers behind them. The clusters appear: the provider sitting behind a disproportionate share of what matters, the concentration you would not have chosen deliberately but inherited. This is also exactly the analysis that overlaps with DORA's ICT third-party and concentration-risk work — one model, two regulatory conversations. To be clear about the boundary: the repository surfaces and documents the relationships and the chain; the assessment of any provider, and the contractual and notification posture around it, remain yours and your counsel's.

• Each application linked to its suppliers and outsourcing providers
• Outsourcing chains traceable down to sub-providers behind a function
• Concentration visible where many functions lean on the same provider
• Documentation that stays current because it lives next to the architecture

Operational resilience: scoping critical functions from a living map

Operational resilience is, at its core, the ability to keep delivering critical or important functions through disruption — and to show that you have thought it through. The slowest part of preparing that is rarely the controls themselves; it is the scoping, working out which functions are critical, what supports them, and what would happen if a dependency failed. Done from scattered documents, this is archaeology under deadline pressure.

A current architecture model collapses that step. Trace a critical function down to the applications, data flows, technology and third parties it relies on, and the picture of what must stay up — and what threatens it — is on screen rather than in someone's head. The same model makes the resilience narrative defensible: you can show, from a versioned source, which functions you treated as critical and why, and what each depends on. We are precise about the limit: an EA repository supports resilience documentation by providing the dependency context; it does not perform business continuity, incident response or testing. Those live in your operations and your plans, and the architecture model feeds them rather than replaces them.

• Trace critical functions to the applications, data and third parties they rely on
• Scope the impact of a failed dependency from a model, not from memory
• Show, from a versioned source, which functions were treated as critical and why
• An aid to resilience documentation — not continuity, response or testing itself

Why a sovereign, EU-hostable or on-prem repository fits Luxembourg specifically

Three properties of ArchiLU matter more in a CSSF context than almost anywhere else. It can be hosted in the EU or on-premise, so the sensitive map of which applications support which critical functions — close to a blueprint of where you are most exposed — does not leave a boundary you control, which matters in a jurisdiction where data location and control are taken seriously. It is available natively in French and English, which fits a Luxembourg 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 map are not gated by a seat count; the commercial detail lives on the pricing page rather than here.

The honest boundary, restated because it matters: ArchiLU is an enterprise architecture repository that produces documentation and evidence and makes it easier to assemble and keep current. It is not a CSSF certification, not a CSSF-approved control library, and we are transparent about certifications we do not yet hold. What it gives a CSSF-supervised entity is a sovereign, multilingual, connected model of its capabilities, applications, data flows and third parties — the groundwork the CSSF, DORA and NIS2 conversations all rest on. 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.