ArchiLU home
Documentation

CSSF and Enterprise Architecture: Documenting ICT, Outsourcing and Resilience

Banks, PFS, investment firms and fund players document their ICT, outsourcing and operational resilience. These files rest on the same foundation: capabilities, applications, data flows and the third parties behind them. The architecture repository keeps that foundation current.

Updated on

Documentation expectations for a supervised entity

A bank, PFS, investment firm or fund player established in Luxembourg and supervised by the CSSF must be able to show how its information systems work. Expectations cover ICT risk management, outsourcing and ICT service arrangements, and operational resilience.

This text helps prepare documentation; it is not legal advice. It does not cite circular numbers: the applicable text and its scope for your type of entity are matters for your compliance function and qualified counsel.

A shared foundation: capabilities, applications, flows and third parties

ICT risk, outsourcing and resilience look like separate files, held by separate teams. They rely on the same knowledge. Supervising an arrangement requires knowing which function it supports. The resilience of a critical function can be demonstrated once its dependencies are known.

This knowledge often sits in several places: a CMDB, diagrams in a wiki, an outsourcing register in compliance, contracts in legal, criticality levels in a slide deck. The architecture repository connects them in one model, object by object, with an owner for each.

Capabilities, applications and data flows

The model links the business to what makes it run. Capabilities such as payments, client onboarding, fund administration or regulatory reporting are supported by applications. Each application relies on technologies and exchanges data through its interfaces.

In ArchiLU, each interface, inbound or outbound, states its protocol and the data it carries. An application record shows it layer by layer, from business to technology, with its history. These links answer the questions raised in a review: which applications support a critical function, where its data goes, and what would be affected if one link failed.

  • The capability map, with the applications supporting each capability.
  • The application list, with owner, criticality, lifecycle and supplier.
  • Interfaces, their protocol and the data they carry.
  • The technologies of each application and their support deadlines.

Outsourcing and ICT providers

An entity needs to know to whom it has entrusted services, which arrangements support critical or important functions, and which subcontractors work behind a provider. This information drifts quickly when it lives in a register kept apart from the architecture.

In ArchiLU, the chain starts from the critical or important function and follows processes, applications and ICT services down to the subcontractor and the contract. A dedicated view distinguishes an application’s supplier from the provider of an ICT service. A missing link stays visible, and the exposure analysis flags concentration on a single provider.

Assessing an arrangement, any notifications and the contractual position remain with the entity and its advisers.

Operational resilience: starting from the critical function

Operational resilience means continuing to deliver critical or important functions during a disruption, and showing that this continuity was prepared. The first task is to identify those functions and what supports them.

In ArchiLU, each function carries its criticality under DORA, its owner and the applications that serve it. A function record shows its processes, its applications, the deployed instance with its recovery time and tolerable data loss, and the application’s exit plan. Continuity plans, testing and incident response remain in the entity’s processes; the repository gives them the dependencies.

  • The list of functions, with their criticality and owner.
  • The dependencies of each critical function down to the providers.
  • Regulatory reports, frozen with their fingerprint.
  • A read-only audit engagement, limited to its scope and period.

A Luxembourg entity and its teams

ArchiLU is published in Heinerscheid, Luxembourg, by MIP-IT SARL. Each organisation has its own dedicated instance, hosted in the European Union; deployment on your infrastructure is an optional service, quoted separately. Screens, tasks and help are available in French, English and German.

In a small entity, one person can hold several profiles. In free mode, an architect can lay the foundation alone, and a decision body can have a single member. The offers include unlimited users, readers included: risk, compliance, IT and management read the same map.

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.

Actual Payments dependency-chain view in ArchiLU, showing applications, ICT services, providers and missing links.

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 an architecture repository make an entity compliant with CSSF expectations?
No. The authority and the entity’s control functions assess compliance against its organisational, contractual, technical and procedural measures. The repository documents capabilities, applications, data flows and third parties. It makes the files easier to build and keep current.
How does mapping help document outsourcing?
Each application is linked to its ICT services, providers and their contracts. The entity follows a critical or important function to the third parties and subcontractors behind it, and identifies the providers on which several functions depend. Assessing each arrangement remains with the entity and its advisers.
How does this work relate to DORA?
DORA sets harmonised requirements for ICT risk management, ICT third-party risk and operational resilience. For the entities it supervises, the CSSF acts as competent authority. CSSF and DORA files rest on the same inventory of functions, applications, data flows and third parties; the legal detail is a matter for qualified counsel.
We are a PFS: does this apply to us?
The principle applies to any supervised firm that relies on ICT and third parties, with requirements that vary by type of entity, size and risk. A small team finds it easier to maintain one repository than several registers. The exact scope should be confirmed with qualified counsel.