On 18 September, the EBA published its Guidelines on the sound management of third-party risk for non-ICT services (https://www.eba.europa.eu/publications-and-media/press-releases/eba-publishes-its-final-guidelines-management-third-party-risk-delivering-more-proportionate-and).
The EBA presents them as a simplification, focused on arrangements that support critical or important functions. On paper, it is a long-expected update: the 2019 outsourcing guidelines are repealed, DORA covers ICT, and this text covers everything else. Most institutions will file it as one more compliance workstream, with contract clauses to renegotiate as renewals come up.
I think that reading misses what the text actually says. Lighter in scope, it is more demanding in substance.
One passage, easy to pass over in the background section, carries the intent of the whole text. For services supporting critical or important functions, institutions must be able to control and challenge what their providers deliver, and to carry out their own risk assessment and monitoring. Checking formally that those services meet regulatory requirements, the EBA writes, is not sufficient. In other words, the supervisor will no longer ask whether the risk assessment exists. It will ask whether it holds.
This is where frameworks will run into their own history. In many institutions, third-party risk assessment is still a craft.
The supplier owner is asked to identify the risks of an arrangement, and the risks that appear are the ones they happened to think of, often without the risk background the exercise assumes. The second line is meant to challenge that list, and it has the expertise to do so. What it lacks is usable material and time. An assessment built from scratch has to be reconstructed before it can be challenged, and no second line can do that across hundreds of arrangements. It falls back, rightly, on a risk-based approach, which means most assessments receive a light review, and some none at all.
The result is a portfolio that looks complete and is not. Taken one at a time, these assessments can be serious. Laid side by side, they cannot be compared: each has its own risks, its own wording, its own idea of what “high” means, and none covers the same scenarios as the next. You cannot aggregate them, measure a concentration from them, or explain why two similar arrangements received different ratings.
The guidelines point the other way. They ask that the risk assessment include scenarios of possible risk events, high-severity ones included, and assess the impact of failed or inadequate services arising from processes, systems, people or external events. That is a common frame, not a blank page. The text also requires a consolidated view: concentration measured at entity and group level, substitutability graded, a register the supervisor can process. None of that works unless assessments share the same structure.
The tension deserves to be named. Third-party risk is a matter of judgement, and no questionnaire replaces someone who has watched a critical provider fail. But judgement that cannot be reproduced cannot be defended in an inspection. A supplier owner who rates an arrangement as low risk on instinct may well be right. If nobody can show how they got there, or that a colleague would get to the same place, that judgement becomes a risk in its own right.
The answer is not to choose between judgement and standardisation. It is to industrialise the question, not the answer.
Qualification shows why. The guidelines impose a cascade: is the service ICT or not? Does it fall under an exclusion? Is it provided on a recurrent basis? Does it support a critical or important function? Does it cover operational tasks of internal control, which are now presumed critical? Each step can be reduced to closed questions whose combination produces a traceable result. That does not simplify judgement. It formalises it, and it moves the expert to where the answer is genuinely not binary, instead of starting every file from a blank page.
Where we have built this, one lesson stood out. The hard part is not writing the questions. It is deciding which answers trigger what. A well-built qualification tree says as much about what does not need deeper analysis as about what does.
The same logic applies to due diligence, whose scope the guidelines widen considerably: data protection, conflicts of interest, business continuity, geographic dependencies, the political stability and insolvency law, and, outside the EU, ESG and human rights. Bundled into one monolithic questionnaire, that scope defeats itself. Providers who receive the same long list, whatever they actually deliver, answer late, partially or not at all, and splitting it into a light version and a full one only moves the problem. Due diligence ends up stalling on the questionnaire rather than on the risk. The guidelines themselves ask for due diligence proportionate to the criticality of the arrangement.
The answer is modular. The profile of the service decides which modules apply: no personal data, no data protection module; no critical function, no continuity section; low risk, no detailed questions. This is the direction the more mature practices have taken, ours included. The scenarios covered depend on what the arrangement is, not on who happens to own it. And because a given module always asks the same questions, answers stay comparable from one provider to the next. The second line no longer has to rebuild each assessment before questioning it, and can spend its limited capacity on the arrangements and answers that actually warrant it. A collection of opinions becomes a portfolio of risks.
A single portfolio, though, assumes a single framework, and the boundary with DORA is where that will be tested. Whether a non-ICT service that relies on ICT falls under DORA is left to the institution, provided it can justify the call. ICT subcontractors that underpin a critical non-ICT service go in the non-ICT register. The EBA allows a single register, and encourages institutions to avoid any discrepancy between the two. Where the third-party register already covers non-ICT, that is a formality; elsewhere, it is a reconciliation project.
Artificial intelligence makes that boundary more porous still, and the guidelines do not mention it once.
Yet this is where providers are innovating fastest: sanctions screening, identity verification, instant payment screening, fraud detection, transaction monitoring. An institution that outsources part of its onboarding no longer buys only analyst time. It often buys a decision prepared by a model it cannot see.
Last month I noted that Annex III of the AI Act names only two financial use cases as high-risk. Fraud detection is explicitly carved out of the credit one, and screening or KYC tooling is not listed at all. So most of the AI your providers run on your clients sits outside the high-risk regime, and its governance falls back on the third-party framework almost by default.
Which raises questions neither DORA nor these guidelines settle. Is the service ICT or not? Is the AI component material? If the provider replaces its model, is that a material change you should hear about, in the same way as a new subcontractor? A due diligence that never asks which decisions a provider has delegated to a model, under what human oversight and with what traceability, leaves a blind spot exactly where supervisors will look next. It is the same question I ended on last month, one step further down the chain: what is running, on whose authority, inside the services you rely on?
Then there is the part Luxembourg cannot look away from.
The guidelines explicitly target entities that rely on a parent outside the EU to the point of becoming empty shells. They state that an intragroup provider is not less risky by nature, and that an intragroup provider located in a third country remains a third-country risk. For a financial centre built in part on the hubs of international groups, substance will not be demonstrated with a group framework agreement and an annual attestation.
Circular CSSF 22/806, as amended by 25/883, is where these expectations will land nationally. How the CSSF brings the new guidelines into it is the next thing to watch.
The transition period, two years for arrangements supporting critical or important functions, leaves a choice.
It can be used to reopen the 2019 outsourcing file, amend contracts as they come up for renewal, and produce compliant documentation at the deadline. Or it can be used to turn third-party risk into a single framework, where every qualification can be replayed identically and every risk compared with the others.
Both paths lead to compliance. Only one will hold on the day the supervisor stops asking where your assessment is, and asks why it says what it says.
Alexandre Castaing is Managing Director of Axon Advisory & Consulting, working with supervised financial entities in Luxembourg on digital resilience, AI governance and regulatory compliance.
#ThirdPartyRisk #EBA #DORA #AIAct #CSSF #Luxembourg #OperationalResilience #TPRM