Third-party risk: does your critical function depend on a supplier IT cannot see?

Mapping cloud providers, telecom operators, SaaS vendors and IT suppliers has become common practice in mature organisations. But a critical function does not depend on IT alone.

On 18 September 2026, the European Banking Authority published its final Guidelines on the sound management of third-party risk related to non-ICT services. They are final but not yet applicable: the EBA states that they are awaiting translation into the EU official languages and provides for a two-year transitional period.12

The practical question therefore changes from “Who are our critical suppliers?” to “Which third parties does this critical function actually depend on?”

DORA structured the ICT view of third-party risk

DORA created a structured framework for financial entities' ICT third-party risk. It also establishes a key principle: a financial entity remains fully responsible for compliance when it uses an ICT third-party service provider.3

This has encouraged organisations to connect contracts, ICT services and critical or important functions. Yet it can leave a blind spot: a business function does not necessarily depend only on ICT resources.

The EBA extends the reasoning to non-ICT third parties

The new EBA Guidelines address third-party services outside DORA's ICT scope. They focus particularly on arrangements supporting critical or important functions and cover the full lifecycle: risk assessment, due diligence, contracting, subcontracting, monitoring, documentation and exit strategies.2

The consequence for dependency mapping is straightforward.

Starting with suppliers hides part of the problem

Consider a bank analysing its credit-granting process. Supplier-centred inventories may separately list cloud providers, software vendors, network operators, business subcontractors, data suppliers and document services.

IT knows technology vendors. Procurement knows contracts. Business teams know specialist providers. Legal follows contractual relationships.

The hard question is: which third parties are required for the credit process to work tomorrow morning?

Reverse the map: start with the function

A more useful chain is:

critical function → process → activity → required service → third party → subcontractor → dependency → alternative

Credit may depend on a business application, cloud provider, identity provider, external data source, assessment provider, document service or signature provider. Some are ICT; others may not be.

From a continuity perspective, the first question is still: what happens if this service disappears?

The removal test

For each third party connected to a function, mentally remove it and ask: can the function still operate? For how long? Is there a genuinely usable alternative? How long would switching take?

This separates commercial importance from operational dependency. A low-spend supplier may support an essential activity, while an expensive contract may cover an easily replaceable service.

Dependencies can be indirect

The real chain may be:

function → service → supplier → subcontractor → indispensable infrastructure or service

The EBA explicitly includes subcontracting in the third-party risk lifecycle.2 The objective is not to map every marginal participant, but to identify dependencies whose failure could threaten a critical or important function.

Concentration is not just a contract count

Two applications can use different direct suppliers while ultimately depending on the same actor. A better question is: how many critical functions depend on the same third party, and how many have a real alternative?

This reveals concentrations that contractual inventories can hide.

Exit strategies must connect to real dependencies

Documenting an exit strategy is not the same as being able to exit. For each material dependency, organisations should connect the service, affected function, required data or assets, alternatives, contractual constraints, technical dependencies and replacement time.

An alternative written in a document is useful only if it can be activated within the function's continuity requirements.

Third-party risk becomes an enterprise-architecture problem

Organisations operate through people, processes, applications, infrastructure, data and external services. Mapping only infrastructure is incomplete. Mapping only suppliers is incomplete too.

The business function is the meeting point:

function → process → application → service → third party → subcontractor → alternative

IT sees technical dependencies; business teams see operational consequences; procurement sees supplier relationships; legal sees contracts; security sees exposure; risk teams see concentration.

Six questions to test a third-party risk map

1. Can we start from a critical function and identify every third party required to operate it?
2. Do we know the most important indirect dependencies?
3. Do we know which functions depend on the same third party?
4. Is there a real alternative for each major dependency?
5. Do we know how long activating that alternative would take?
6. Does a supplier or subcontractor change update our dependency view?

From a supplier register to a dependency map

The EBA Guidelines do not make supplier inventories obsolete. A register answers “Who do we work with?”

A dependency map answers “Who does this activity depend on?”

The difference may look subtle. In a crisis, it becomes essential.