guide

Last updated June 25, 2026

CSSF Outsourcing Arrangements in Luxembourg: Critical or Important Functions Governance Guide

Direct answer

Use CSSF Outsourcing Arrangements in Luxembourg: Critical or Important Functions Governance Guide when a CSSF-facing question needs a structured file rather than a loose policy summary. It explains understanding the Luxembourg regulatory obligation, supervisory evidence, internal ownership, and escalation points in CSSF Outsourcing Arrangements in Luxembourg: Critical or Important Functions Governance Guide, then shows how to map the controlling rule, prepare board or compliance evidence, and know when a CSSF-facing specialist should review the file. The later sections connect official sources used, start with a perimeter decision, and define critical or important function in business terms so the next step is easier to judge. Read it before assigning owners or responding to a supervisory request, so the evidence file matches the regulatory question.

Circular CSSF 22/806, as amended by Circular CSSF 25/883, remains a core Luxembourg source for outsourcing arrangements. The April 2025 CSSF update clarifies the split created by DORA: for DORA entities, ICT outsourcing requirements are largely replaced by DORA ICT third-party risk rules and Circular CSSF 25/882, while Circular 22/806 remains relevant for business-process outsourcing and for certain non-DORA or specifically scoped entities. That split makes classification the first operational control.

This guide is for supervised entities, compliance teams, management bodies, vendor managers, legal teams, internal audit, risk managers and founders preparing Luxembourg operating models. It is not legal advice. Source check date: 20 May 2026.

Official sources used

This article uses official CSSF sources on outsourcing, ICT third-party services and the April 2025 update of circulars. It links to the relevant CSSF pages so compliance teams can verify the current perimeter before acting.

• CSSF: Circular CSSF 22/806 on outsourcing arrangements
• CSSF: Circular CSSF 22/806 as amended by Circular CSSF 25/883
• CSSF: Update of circulars related to ICT risk and ICT outsourcing
• CSSF: Circular CSSF 25/882
• CSSF: ICT and cyber risk for DORA entities
• CSSF internal governance guide
• CSSF DORA incident reporting guide

Start with a perimeter decision

The first mistake in an outsourcing file is jumping directly to contract clauses. The entity should first decide what the arrangement is. Is it business-process outsourcing, ICT outsourcing for a non-DORA entity, use of ICT third-party services for a DORA entity, intragroup support, consulting, software licensing, cloud infrastructure, delegated portfolio activity, administration, call-center support or another model?

This perimeter decision controls the rest of the file. A business-process outsourcing arrangement under Circular 22/806 is not handled exactly like a DORA ICT third-party arrangement under Circular 25/882. A non-critical vendor service is not governed like a critical or important function. A one-off advisory service is not the same as operational dependency.

The perimeter memo should be short but explicit. It should name the service, provider, function owner, regulated activity supported, customers affected, data involved, technology dependency, substitutability and initial classification.

If the classification later changes, document why. A provider can become more important as volumes grow or as the entity moves more processes into the service.

Define critical or important function in business terms

Critical or important is not only a legal label. It asks whether a defect, failure or discontinuity would materially impair the entity's regulated performance, financial stability, continuity, compliance, risk management or ability to serve customers. Business terms make the assessment usable.

A service may be critical because it supports payment execution, transaction monitoring, client reporting, NAV calculation, accounting, customer communication, regulatory reporting, data storage, claims handling, complaint handling, risk engines or access to essential records.

The assessment should consider impact, customer harm, time sensitivity, legal obligations, substitutability, internal capacity and concentration. If a service cannot be replaced quickly and failure would impair regulated operations, the file needs a stronger governance case.

Avoid superficial labels. A spreadsheet saying 'not critical' without analysis is weak evidence.

Keep accountability with the supervised entity

Outsourcing can delegate tasks, but it should not delegate accountability. The management body and authorized management need a governance model that shows who approves, monitors, escalates and can terminate or replace the arrangement.

The policy should assign a function owner, outsourcing officer or vendor manager, risk reviewer, legal reviewer, information-security input, data-protection input where relevant and internal audit coverage. It should also define when the board or management body must approve.

Accountability evidence includes minutes, approvals, risk opinions, sign-off matrix, escalation logs and periodic reports. It should be possible to identify who knew what and when.

A mature file does not depend on one person remembering the rationale. It preserves the rationale in records.

Perform due diligence before signing

Due diligence should happen before commitment, not after a commercial decision is effectively irreversible. The depth should be proportionate to the service and risk.

A basic due-diligence pack can include provider identity, financial soundness where relevant, experience, licences, audit reports, information-security controls, business continuity, subcontractors, jurisdiction, data handling, insurance, conflicts, sanctions screening and operational references.

For critical or important functions, the entity should also assess concentration risk, substitutability, exit complexity, dependency on key staff, service-level realism and ability to audit or access information.

Due diligence is not a procurement ritual. It is the evidence that the entity understood the provider before relying on it.

Write the contract around control, not only price

Outsourcing contracts should not be treated as commercial purchase orders. The contract is part of the control environment. It should support access, audit, information rights, service levels, confidentiality, data protection, subcontracting controls, incident notification, business continuity, termination, exit assistance and cooperation with authorities where relevant.

The more important the function, the more dangerous vague language becomes. Terms such as reasonable efforts, standard support or provider policy may not be enough where continuity and supervisory access matter.

Legal teams should work with function owners and risk teams. A contract can include elegant clauses but still fail operationally if the service owner cannot monitor the obligations.

The contract should map to the risk assessment. If the risk assessment identifies concentration and exit risk, the contract should address data portability, assistance, notice and transition.

Create a living outsourcing register

An outsourcing register is useful only if it is current. It should identify provider, service, owner, classification, criticality, start date, renewal, jurisdiction, subcontracting, data, risk rating, approvals, monitoring frequency and exit plan status.

The register helps management see concentration and dependency. It also helps prepare supervisory responses because the entity can quickly identify outsourced functions and supporting evidence.

A register that is updated only once before an audit is not a control. The policy should define who updates it, when changes are logged and how it reconciles with procurement and accounting records.

For groups, the register should distinguish local entity arrangements from group-level services used by the Luxembourg entity.

Handle intragroup outsourcing with the same discipline

Intragroup arrangements can feel safer because the provider is within the corporate group. That does not remove the need for governance. The Luxembourg entity still needs to understand service scope, responsibilities, controls, access rights and exit options.

Group services can create less visible concentration risk. A shared platform, group operations center or group data function may support many entities at once. Failure can affect the Luxembourg entity even if the contractual counterparty is an affiliate.

The file should include service-level documents, cost allocation, responsibilities, control reports, escalation paths and evidence that the local entity can obtain information when needed.

Intragroup does not mean informal. The record should be defensible to a supervisor.

Monitor the provider after go-live

Approval is not the end of outsourcing governance. Ongoing monitoring should verify service levels, incidents, control findings, complaints, data issues, business continuity tests, subcontractor changes, audit results and remediation.

Monitoring should be risk-based. A low-risk service may need annual review. A critical or important function may need more frequent metrics, management reporting and incident escalation.

The service owner should not simply collect dashboards. They should interpret them. If metrics deteriorate, volumes change or incidents repeat, the risk assessment may need revision.

Monitoring evidence is often what proves that governance is real rather than policy-only.

Plan exit before the service fails

Exit planning should exist before failure, not after the provider collapses or the relationship becomes unsustainable. A credible exit plan identifies trigger events, alternative providers, internal fallback, data migration, customer communication, regulatory implications and time estimates.

For critical or important functions, exit plans should be tested or at least walked through. A plan that assumes a replacement provider will be available immediately may be unrealistic.

The exit plan should also address contract termination assistance, access to data, handover documentation, intellectual property, staff knowledge and post-termination confidentiality.

A good exit plan does not mean the entity expects failure. It means the entity can preserve continuity if failure occurs.

Control subcontracting and chains

Subcontracting can turn one provider relationship into a chain of dependencies. The supervised entity needs enough visibility to understand which material tasks are subcontracted, where they are performed, what data is involved and how changes are controlled.

Contractual rights should require notification or approval for relevant subcontracting changes, especially where critical or important functions are affected. The entity should not discover after an incident that a key process was moved to an unknown subcontractor.

Subcontracting assessment should include geography, concentration, data access, resilience and auditability. It should also consider whether subcontractor failure could impair the main service.

A clear subcontractor register or appendix makes the chain reviewable.

Connect outsourcing with data protection and security

Many outsourcing arrangements involve personal data, confidential business information or regulated records. Outsourcing governance should therefore connect with information security, data protection, record retention and access control.

The file should identify data categories, data locations, encryption expectations, access management, logging, retention, incident notification and deletion or return at exit. Where GDPR applies, data-processing arrangements may be needed.

Security due diligence should not be copy-pasted. It should reflect the service. A payroll provider, cloud host, call center and analytics tool create different risks.

The entity should also know which data must remain available to meet regulatory, audit, complaint and customer obligations.

Avoid shadow outsourcing

Shadow outsourcing occurs when business teams rely on external providers without the arrangement entering the outsourcing governance process. Examples include operational tools bought by card, consultants given access to client data, analytics services embedded into workflows or group teams performing local tasks without documentation.

Shadow arrangements create risk because no one has classified them, risk assessed them, checked data, reviewed contracts or added them to the register.

The policy should make it easy for teams to escalate potential outsourcing early. If the process is too slow or unclear, teams may bypass it. Good governance includes a practical intake path.

Periodic reconciliation with procurement, IT, finance and vendor payment records helps detect shadow dependencies.

Use internal audit as a reality check

Internal audit should test whether the outsourcing framework works in practice. That means checking a sample of arrangements from intake to exit planning, not only reading the policy.

Audit can examine whether classifications are supported, approvals are complete, contracts match required clauses, registers are current, monitoring evidence exists and issues are escalated. It can also test whether business owners understand their obligations.

Findings should lead to remediation with owners and deadlines. Repeated findings about missing classification or stale registers indicate a framework problem, not isolated clerical errors.

A strong audit trail helps the management body see whether outsourcing risk is under control.

Prepare supervisory evidence before being asked

Supervisory review often begins with basic questions: what is outsourced, which functions are critical or important, who approved them, how are providers monitored, what incidents occurred, and how would exit work. The entity should be able to answer quickly.

A supervisory evidence folder can include policy, register, criticality methodology, selected risk assessments, contracts, due diligence, monitoring reports, incident logs, exit plans, board reporting and remediation tracking.

The folder should not be assembled from scratch after a request. It should be maintained as part of normal governance.

This is especially important during rapid growth, acquisitions, platform migrations or provider changes.

Account for the DORA split after April 2025

The April 2025 CSSF update matters because it changed how ICT outsourcing overlaps are handled. For DORA entities, ICT third-party risk management is now primarily a DORA/Circular 25/882 topic, while business-process outsourcing remains a Circular 22/806 topic. For non-DORA entities and certain specific entities, the amended outsourcing circular remains relevant for ICT outsourcing in the stated way.

An entity should therefore record why an arrangement is being treated under one framework rather than another. A legacy ICT outsourcing register may need mapping to DORA ICT third-party registers and business-process outsourcing records.

Do not assume that old cloud outsourcing files automatically satisfy the new DORA-oriented requirements. Review the provider, service, criticality, notification, register and contract evidence.

A transition memo can prevent confusion between old and new governance labels.

Integrate outsourcing with operational resilience

Outsourcing risk is not separate from operational resilience. If a provider supports an important activity, its failure can become an operational incident, customer service problem, regulatory reporting issue, data issue or financial loss.

Business continuity planning should include provider scenarios. What happens if the provider is unavailable for two hours, two days or two weeks? What if data is corrupted, access is lost, a subcontractor fails or a cyber incident affects the provider?

The entity should define recovery expectations, communication channels and decision authority. Provider continuity claims should be tested against the entity's own tolerance for disruption.

Operational resilience turns outsourcing from contract management into service survival planning.

Manage renewals and material changes

Renewals can be a less visible risk point. A contract may renew automatically while the service has changed, volumes increased, subcontractors shifted or regulation evolved. A renewal should trigger a proportional review.

Material changes should be assessed before they take effect: new geography, new data access, changed service scope, cloud migration, subcontractor change, pricing model that affects continuity, or provider ownership change.

The register and risk assessment should be updated after material change. If approval or notification is required, plan ahead rather than discovering the issue after signature.

Renewal discipline prevents stale outsourcing files.

Use proportionality without weakening evidence

Proportionality means controls should fit risk, size, complexity and service importance. It does not mean undocumented judgment. Even a proportional approach should leave evidence.

For a simple non-critical service, the evidence may be a short classification memo, basic due diligence and a contract check. For a critical or important function, the evidence should be deeper and involve governance, monitoring and exit planning.

The decision that a lighter process is appropriate should itself be documented. Otherwise proportionality can look like omission.

A mature framework has tiers, not exceptions without records.

Create a practical implementation roadmap

A supervised entity improving its outsourcing framework should not begin by rewriting every contract at once. Start with inventory, classification, risk tiering and gaps. Then prioritize critical or important functions and high-risk providers.

The roadmap can include register clean-up, policy refresh, template contract clauses, due-diligence checklist, approval workflow, monitoring calendar, exit-plan template and board reporting format.

Assign owners and dates. Outsourcing remediation can stall if every item belongs to compliance but the evidence sits with business, legal, IT and procurement.

The roadmap should also preserve business continuity. Remediation should strengthen the framework without disrupting essential services.

Design the intake workflow before business teams need it

Outsourcing governance works best when business teams know how to start. A clear intake workflow should ask for service description, provider identity, business owner, expected start date, data involved, customer impact, technology dependency, intragroup status, approximate spend and whether the service supports a regulated activity.

The intake should triage quickly. Not every request needs the same depth, but every request should get a documented classification. If the intake is slow or unclear, teams may sign contracts first and ask compliance later.

A practical workflow includes early legal, risk, ICT security and procurement routing. It should also identify arrangements that may require notification or management-body approval before contract signature.

The intake record becomes the first page of the outsourcing file and explains why the entity treated the arrangement as it did.

Use a risk-tier model that can survive challenge

A risk-tier model helps teams apply proportionality consistently. It can classify arrangements by criticality, data sensitivity, customer impact, regulatory impact, substitutability, jurisdiction, subcontracting, concentration and operational complexity.

The model should not be a mechanical score that overrides judgment. A low total score may still hide a red flag, such as access to sensitive client data or support for a time-critical process. The model should allow reasoned override with approval.

Each tier should trigger defined controls: minimum due diligence, contract review depth, approval level, monitoring frequency, exit-plan depth and audit coverage.

The evidence should show the score, rationale and reviewer. This makes the tier defensible.

Map outsourcing to regulated obligations

The outsourcing file should connect the service to the obligations it supports. A customer-reporting provider supports communication duties. A transaction-monitoring platform supports AML/CFT controls. A fund-accounting provider supports valuation and reporting. A payment processor supports execution and user obligations.

This mapping matters because failure impact depends on the obligation. A provider outage is more serious if it prevents regulatory reporting, customer redress, complaint response, transaction processing or safeguarding controls.

The mapping should identify the obligation, business process, system, provider and internal owner. It should also identify whether internal staff can perform a fallback process.

Without obligation mapping, criticality assessments can become generic and understate real risk.

Define minimum evidence for non-critical services

A proportional framework still needs minimum evidence. For non-critical services, the file can be lighter, but it should still show classification, provider identity, contract or terms, data assessment, owner and review date.

This prevents a common failure where only critical arrangements are documented and everything else becomes invisible. Non-critical services can become important over time, and small tools can hold sensitive data.

Minimum evidence also supports future reclassification. If volumes grow or usage changes, the entity has a baseline record rather than starting from nothing.

The lighter path should be efficient enough that business teams use it.

Document exceptions and risk acceptance

No outsourcing framework is perfect. A provider may refuse a preferred clause, a legacy contract may lack audit detail, an exit plan may depend on future tooling, or a group service may not provide local data fast enough. The issue is not whether exceptions exist, but whether they are visible and accepted at the right level.

An exception record should state the gap, risk, compensating control, owner, expiry date and approving authority. Open-ended exceptions are weak because they become permanent without review.

Risk acceptance should be rare for critical or important functions and should involve management with enough information to understand consequences.

Exception discipline prevents silent erosion of the framework.

Review concentration risk across providers

A single provider may support several functions. A single cloud platform may host multiple applications. A single group operations hub may serve many entities. Concentration risk is therefore a portfolio issue, not just an individual contract issue.

The outsourcing register should allow management to see provider concentration, geography concentration, technology concentration and group-service concentration. It should also identify where several critical functions depend on the same provider or subcontractor.

Concentration does not automatically mean the arrangement is unacceptable. It means the entity needs stronger resilience, monitoring, exit and contingency analysis.

A portfolio view is especially important after acquisitions, migrations and platform consolidation.

Create board reporting that is short but decision-grade

Management bodies do not need every operational detail, but they need decision-grade reporting. A useful report shows critical or important outsourced functions, high-risk providers, material incidents, overdue reviews, open exceptions, concentration risks, failed exits tests and regulatory changes.

The report should distinguish status from comfort. A green dashboard is weak if it hides stale risk assessments or missing exit plans. Include a small number of meaningful metrics and a narrative on material changes.

Board minutes should reflect challenge, not only receipt. Questions about concentration, exit feasibility or overdue remediation show active oversight.

Good board reporting turns outsourcing governance into a managed risk rather than a compliance archive.

Align outsourcing records with incident management

Provider incidents can become internal incidents. The outsourcing file should define when provider incidents must be reported internally, who assesses impact, how customer communication is handled and whether regulatory reporting might be triggered.

Contracts should require timely provider notification and cooperation. Monitoring should track recurring incidents, unresolved root causes and service-level failures.

Incident lessons should feed back into risk assessment and renewal decisions. A provider with repeated outages may require stronger controls, remediation or exit.

This closes the loop between outsourcing governance and operational resilience.

Outsourcing file checklist

A practical outsourcing file should be readable without institutional memory. The file does not need to be theatrical, but it must let a reviewer understand the arrangement, classification, risk, approval, monitoring and exit plan.

The checklist below can be used as a first pass for Luxembourg supervised entities before signing, renewal or supervisory review.

FAQ

Is every vendor relationship outsourcing? No. The classification depends on whether the provider performs a process, service or activity that would otherwise be undertaken by the supervised entity and how that service supports regulated activity. Simple procurement and advisory support may fall outside, but the analysis should be documented.

Does DORA replace Circular 22/806 entirely? No. The April 2025 CSSF update explains a split. For DORA entities, ICT outsourcing requirements are largely replaced by DORA ICT third-party risk management and Circular 25/882, while Circular 22/806 remains relevant for business-process outsourcing and stated non-DORA or specific cases.

What is the biggest practical mistake? Treating outsourcing as a legal contract exercise instead of an operating-risk control. The evidence file should show classification, risk, approval, monitoring and exit.

Should intragroup services be documented? Yes. Intragroup does not eliminate the need for local governance and evidence.

What should be done first in a weak framework? Build the inventory, classify critical or important functions, identify missing contracts or exit plans, and remediate high-risk arrangements first.

Source risk and update note

CSSF circulars, DORA implementation guidance and outsourcing expectations can change. This article was checked against official CSSF sources on 20 May 2026. Supervised entities should verify current circulars, FAQs, forms and communication channels before signing or notifying an arrangement.