CSSF Cloud Computing Guidance: What “Critical or Important Function” Actually Means

Luxembourg’s standalone cloud circular no longer exists as a separate document — it’s now Chapter 2 of Circular 22/806, and which set of rules actually applies to a given cloud arrangement turns entirely on one classification: whether the underlying function is “critical or important.”

The CSSF’s original cloud-specific rulebook, Circular 17/654, was repealed and folded into Circular 22/806 on outsourcing arrangements when that circular took effect in June 2022. Since DORA’s application from January 2025, the CSSF has further amended 22/806 (via Circular 25/883) and issued a new Circular 25/882 specifically for DORA-scope entities’ ICT third-party arrangements. The core principles from the original cloud circular — a designated resource operator, a designated cloud officer — persist, but the applicable regime now depends on two things: whether the entity is DORA-scope, and whether the specific function being outsourced to the cloud is critical or important. This is what that classification actually determines.

Who this is for

• The CTO at a Luxembourg-supervised entity planning a cloud migration and unsure which circular, or which amended version, actually governs the notification requirement.
• The compliance officer determining whether a specific cloud workload counts as “critical or important” and therefore triggers CSSF notification.
• The board member reviewing the firm’s cloud register ahead of a CSSF inspection.

Two regimes, split by DORA scope

Circular 22/806 as amended by 25/883 remains fully applicable to non-DORA entities for both business process outsourcing and ICT outsourcing, including cloud. For DORA-scope entities, the ICT outsourcing provisions of 22/806 have been repealed and replaced by DORA’s own third-party risk management requirements, supplemented by the new Circular 25/882, which sets out the practical mechanics — the notification form and process — for DORA entities specifically. Getting this split wrong at the outset means preparing the wrong notification form, or assuming a requirement has been repealed when it still fully applies to your entity type.

The classification that decides everything downstream

“Critical or important function” is a defined term, read in line with MiFID II’s implementing regulation and, for recovery and resolution purposes, the BRRD Law’s definition of critical functions. Getting this classification right is the single most consequential technical decision in a cloud outsourcing project, because it determines everything that follows: whether the CSSF must be notified at all, which notice period applies, and what contractual and governance obligations attach to the arrangement.

For entities still under 22/806’s outsourcing provisions, outsourcing a critical or important function requires notification to the CSSF at least three months before the arrangement becomes effective — reduced to one month where the outsourcing is to a Luxembourg-regulated support professional of the financial sector. Non-critical, non-important outsourcing carries no specific notification formality under the circular. The classification decision, in other words, is the fork in the road between a three-month lead time and no CSSF process at all.

Roles the circular still requires by name

The cloud-specific requirements that survived the transition from the standalone circular into Chapter 2 of 22/806 include the appointment of a cloud officer, responsible for the use of cloud computing services and for confirming the competence of employees involved, and the concept of a resource operator — the party actually operating the underlying cloud resources, which may be the supervised entity itself or an intermediary Luxembourg-regulated support PFS. Both roles need to be named and documented, not just implied by an existing IT organisation chart — CSSF FAQ guidance is explicit that this is a designated, identifiable responsibility.

What every cloud arrangement needs, regardless of criticality

Even where a specific cloud arrangement doesn’t meet the critical-or-important threshold, entities are still expected to maintain a comprehensive outsourcing register covering all outsourcing arrangements — the earlier requirement to notify non-material cloud activity was replaced with an ongoing register obligation rather than removed altogether. A firm treating “not critical or important” as “no obligations at all” has missed this distinction: the notification requirement lifts, the register requirement doesn’t.

Contractual specifics the CSSF expects to see

For cloud arrangements specifically, the expected contractual coverage extends beyond generic outsourcing clauses to data location, encryption standards, audit rights, and the constraints of multi-tenant environments. Where the outsourcing involves outsourcing accounting systems to a provider located outside Luxembourg, specific requirements now apply to back-up and storage location — a detail easy to miss in a broader cloud migration that happens to include the accounting function among the systems being moved.

What a defensible cloud arrangement demonstrates

1. A documented, reasoned critical-or-important classification for every cloud workload, referencing the MiFID/BRRD definitions rather than an internal judgement call alone.
2. Named cloud officer and resource operator roles, with documented competence.
3. A complete cloud register covering all arrangements, critical or not.
4. Contractual clauses addressing data location, encryption, audit rights, and multi-tenancy specifically — not assumed to be covered by general outsourcing terms.
5. Clarity on which regime — 22/806 as amended, or the DORA/25/882 route — actually governs the entity, confirmed and documented rather than assumed.

Direct versus indirect outsourcing, and why it changes who’s accountable

The circular distinguishes direct from indirect cloud outsourcing, and the distinction has real accountability consequences. Under direct outsourcing, the supervised entity itself appoints the cloud officer and carries that accountability internally. Under indirect outsourcing, the entity may route through a support PFS — a Luxembourg-regulated or group-affiliated intermediary — which can sit either in Luxembourg or abroad. Choosing the indirect route doesn’t remove the supervised entity’s underlying responsibility for the cloud arrangement; it changes the practical mechanics of who holds the cloud officer role and how oversight is exercised day to day. A firm that has outsourced indirectly and treated that as outsourcing away its own accountability has misunderstood the structure.

Worth noting for any firm assuming a quiet compliance posture is sustainable indefinitely: the CSSF has historically carried out unannounced controls specifically to verify cloud register completeness and accuracy, rather than relying solely on scheduled inspections or self-reported updates. A register maintained sporadically, updated only when a new arrangement is signed rather than reviewed on a regular cycle, is exactly what this kind of control is designed to catch.

How we engage with this

We read cloud outsourcing arrangements against the current, amended version of the CSSF’s requirements — confirming which regime actually applies before assessing compliance against it — as an Architecture Review. The output is a written assessment of the classification, the register, and the contractual position, ready for the next CSSF notification or inspection.

We don’t broker cloud contracts. We don’t submit CSSF notifications on a client’s behalf. We don’t sell cloud infrastructure. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If a cloud workload’s critical-or-important classification hasn’t been formally documented, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.