DORA's Register of Information: What Your Azure Platform Has to Prove
In this article
DORA has applied to financial entities since 17 January 2025. In Luxembourg, the CSSF made it very concrete in April 2025: circular CSSF 25/882 now governs the use of ICT third-party services for DORA entities, and circular 25/883 amended 22/806 to strip out the ICT outsourcing chapters, now covered by DORA. Circular 22/806 keeps applying to business process outsourcing and to entities outside the DORA perimeter.
In the middle of all this sits an obligation that gets less attention than it deserves: the register of information. Every financial entity has to maintain and update a register of its contractual arrangements for ICT services provided by third-party providers, with considerably more detail for the ones supporting critical or important functions. The register is submitted to the CSSF annually, on the schedule the CSSF communicates.
On paper, a spreadsheet. In practice, we have yet to see a team fill it in honestly without discovering holes in their own platform. The register is an architecture test disguised as a form.
What the register actually asks
For each ICT service supporting a critical or important function, the register requires, among other things, the identity of the provider, the type of service, the business function it supports, where data is stored and processed, the subcontracting chain, a substitutability assessment, and the exit strategy.
Take those fields one at a time and ask the question: where does the answer come from in your Azure environment?
Which function runs on what
The register starts from business functions, and business functions have to be traceable down to the subscriptions, resource groups, and Azure services that carry them. If your criticality and owner tags are decorative, filled in on migration day and never maintained, that traceability does not exist. An Azure Resource Graph inventory filtered by tags should produce the “services involved” column in minutes. When it takes three weeks and four workshops, the problem is not the register.
Where the data really is
Storage and processing location sounds simple: “West Europe”. Then the awkward questions start. Where do the logs go? Which region hosts your Log Analytics workspace? Your geo-redundant backups replicate to which region pair? Does your WAF or CDN process requests outside the EEA? An “allowed locations” Azure Policy enforced in deny mode gives you a defensible answer for resources. The side channels have to be mapped by hand.
The subcontracting chain
Microsoft publishes its subprocessor list and contractual commitments. That documentation work can be done once and reused for every register line. The tricky part sits one level up: the SaaS products you consume that themselves run on a cloud. For a critical function, the register expects the chain beyond the direct provider, wherever subcontractors matter for the service.
The exit strategy
The most uncomfortable field. “See contract” is unlikely to be enough when the CSSF asks. A credible platform-side exit strategy comes down to three verifiable things: enough Infrastructure as Code coverage to redeploy elsewhere, documented and tested data export paths, and a realistic estimate of rebuild time. Nobody leaves a hyperscaler over a weekend, and the CSSF knows it. What they want to see is that you did the exercise.
The timeline changes how teams work
Circular 25/882 requires notifying the CSSF before putting in place an ICT arrangement that supports a critical or important function: as early as possible, and no later than three months before the planned date (one month when the provider is a Luxembourg support PFS).
Three months means the architecture has to be settled well before go-live. Access model, locations, network flows, reversibility plan: all of it has to exist at notification time rather than being regularised afterwards. For teams used to finalising architecture during the release sprint, that is a change of discipline more than a change of paperwork.
The circular also keeps cloud-specific requirements, including the appointment of a cloud officer. That person often becomes one of the first internal consumers of the evidence described above. It pays to produce it in a format they can reuse.
Where to start on the Azure side
The full exercise is bigger than a blog post, but four workstreams cover most of the distance.
- A tag-driven Resource Graph inventory, with a criticality taxonomy aligned to your list of critical functions. This is the backbone of the register.
- Location policies in deny mode, with compliance evaluation exports as dated evidence.
- Diagnostic settings verified on everything that carries a critical function. Claiming in the register that a function is monitored is proven by logs that exist.
- An exit runbook per critical workload: what gets redeployed, what gets exported, in how much time, tested at least once.
Done seriously, the register stops being an annual chore. It becomes the map of your real dependencies, the one security, risk management, and the architect all consult for the same reason: knowing what breaks what.
One honest note: we work on the technical architecture and the evidence. Legal interpretation of the regulation and the circulars stays with your compliance and legal teams.
Related: Azure Landing Zone Audit: What We Find covers the recurring gaps between declared architecture and actual architecture.
Need Azure evidence that stands up to DORA and the CSSF?
We help Azure teams turn their actual architecture into usable evidence: inventory, data locations, diagnostic settings, dependencies, API exposure, and a remediation path.
More from the blog
The Missing Layer Between Cloud Architecture and Audit Evidence
NIS2 Belgium After 18 April: From Basic Readiness to Continuous Azure Evidence
