DORA Third-Party Risk Management: Article 28 Guide

Under DORA, a financial entity remains responsible for ICT risk even when the technology or service is provided by a third party. Articles 28-30 require financial entities to manage ICT third-party risk through a defined strategy, a register of ICT service arrangements, pre-contract risk assessment and due diligence, concentration-risk review, ongoing monitoring, exit planning, and written contractual requirements. Services supporting critical or important functions face additional controls.

That changes the role of procurement and vendor management. A cloud platform, managed service provider, core banking vendor, payment processor, or other ICT supplier cannot be treated as a contract that disappears into procurement once it is signed. The dependency stays inside the financial entity's ICT risk model for as long as the service is used.

DORA's third-party rules sit mainly in Chapter V. This guide focuses on the financial entity's responsibilities. The separate EU oversight regime for designated critical ICT third-party service providers is related, but it is not the same thing.

What does DORA require for ICT third-party risk management?

DORA Article 28 starts with a principle that is easy to miss in outsourcing discussions: the financial entity remains fully responsible for complying with DORA. Contracting an ICT service does not transfer the regulatory responsibility to the provider.

The regulation then builds third-party risk management around several connected duties. At a practical level, the entity needs to know what ICT services it buys, which business functions depend on them, how important those functions are, what risks the provider introduces, what the contract permits, how the relationship is monitored, and how the service can be exited without unacceptable disruption.

The baseline looks like this:

The full legal text is available in Regulation (EU) 2022/2554 on EUR-Lex. Articles 28-30 are the core reference points for this workstream.

Which ICT third-party providers fall into the DORA process?

For financial entities in the scope of DORA, the third-party risk process is not limited to a short list of famous cloud providers. Article 28 addresses contractual arrangements for the use of ICT services provided by ICT third-party service providers. The register of information also covers ICT service arrangements broadly, while the depth of risk management depends on the service and the function it supports.

Examples can include cloud hosting, managed security services, data center services, software platforms, payment technology, network services, identity services, managed infrastructure, and other external ICT capabilities used by the financial entity.

The practical dividing line is not "large vendor versus small vendor." A smaller provider can create significant DORA exposure if the financial entity depends on it for a function whose disruption would materially affect services, compliance, financial performance, or continuity.

What changes when an ICT service supports a critical or important function?

DORA applies a higher level of scrutiny where the ICT service supports a critical or important function. That status affects risk assessment, due diligence, contractual terms, monitoring, audit, subcontracting, and exit planning.

A critical or important function is a function whose disruption would materially impair the financial entity's financial performance, the soundness or continuity of its services and activities, or its continued compliance with authorization conditions and other obligations. The classification therefore starts with the business function, not with the vendor brand.

For these arrangements, Delegated Regulation (EU) 2024/1773 adds detailed requirements for the policy governing the contractual lifecycle. The policy covers planning, risk assessment, due diligence, approval, implementation, monitoring, documentation, independent review, and exit. The management body must remain involved, and the policy is reviewed at least annually.

The detailed policy requirements are set out in Commission Delegated Regulation (EU) 2024/1773.

How should a DORA third-party risk management process work?

DORA does not prescribe one software workflow or one vendor questionnaire. It does, however, make the lifecycle clear enough that an organization can build a repeatable operating process around the legal requirements.

1. Map the ICT service to the business function it supports

Start by identifying the service, provider, supported process, data involved, locations, internal owner, and dependency. Then determine whether the service supports a critical or important function. This classification affects the depth of every later step.

The Register of Information is the structured record of these relationships, but it is not a substitute for risk analysis. If you need the reporting structure and data-readiness side, see the dedicated DORA Register of Information Readiness guide.

2. Assess the arrangement before the contract is signed

Article 28(4) requires the financial entity to assess whether the arrangement supports a critical or important function, whether supervisory conditions are met, all relevant risks, concentration risk, provider suitability, and conflicts of interest before entering the arrangement.

For services supporting critical or important functions, Regulation 2024/1773 expects an ex-ante risk assessment that considers the impact of the ICT service on the entity and the risks created by the arrangement. The assessment should connect to the entity's actual risk profile rather than treating every vendor as equivalent.

3. Perform due diligence on the provider

The provider assessment should test whether the supplier is capable of delivering the service securely and reliably. For critical or important functions, the 2024/1773 policy requirements point to areas such as business reputation, resources, information security, organizational structure, risk management, internal controls, continuity measures, and the assurance available over those controls.

A certificate can be useful evidence, but it does not answer every DORA question. The financial entity still needs to understand the service dependency, contract model, incident obligations, data locations, subcontracting, recovery capability, and exit constraints that are specific to its own use of the service.

4. Put the DORA requirements into the contract

Article 30 requires written allocation of rights and obligations and a set of minimum contractual elements. The contract is part of the control system because it determines what the financial entity can inspect, obtain, require, recover, or terminate when the service is under stress.

Services supporting critical or important functions need additional terms, including detailed service levels, provider notice obligations for material developments, tested contingency arrangements, security requirements, cooperation with threat-led penetration testing where applicable, audit and access rights, and workable exit provisions.

5. Monitor the relationship after onboarding

DORA third-party risk management continues after contract signature. The entity needs to monitor performance, security and continuity concerns, material provider changes, subcontracting developments, concentration, audit findings, and whether the service still supports the same business function under the same risk assumptions.

A common failure is to treat the original due-diligence pack as permanent evidence. Provider architectures change, services move region, subcontractors are added, contracts are revised, and business reliance can increase. The risk record needs to change when the dependency changes.

6. Keep an exit path that can work in practice

DORA requires termination rights and, for critical or important functions, exit strategies that allow the entity to move to another provider or an appropriate in-house solution without creating unacceptable disruption. Regulation 2024/1773 also expects exit planning to consider alternative solutions and transition measures.

An exit plan is weak if it exists only as a contract clause. Teams need to understand data-return conditions, technical dependencies, migration time, internal skills, substitute providers, transition support, and any concentration risk that makes switching unrealistic.

What does DORA Article 28 require before signing an ICT contract?

Article 28(4) creates a clear pre-contract gate. The entity should be able to show why the arrangement is acceptable before it becomes an operational dependency.

This is a legal decision gate, not a prescribed five-row checklist. The evidence and approval flow should fit the entity's governance model and the criticality of the service.

How does DORA address ICT concentration risk?

Article 29 requires a preliminary assessment of concentration risk when the arrangement supports a critical or important function. Two questions matter in particular: whether the provider is difficult to substitute and whether the entity already has multiple relevant arrangements with the same provider or closely connected providers.

That means concentration is not only a market-level issue for regulators. It is also an entity-level dependency question. A provider can be operationally attractive and still create a recovery problem if there is no realistic alternative, migration would take too long, or several critical services depend on the same provider group.

DORA does not set a simple universal cap such as "no more than X percent with one provider." The entity weighs the benefits and costs of alternatives and considers whether the dependency fits its digital operational resilience strategy.

What does DORA require in ICT third-party contracts?

Article 30 sets a baseline for ICT service contracts and then adds extra requirements where the service supports a critical or important function. The point is not contract length. The point is whether the financial entity keeps enough control to manage the service under normal operation, disruption, audit, and exit.

How do the DORA subcontracting rules affect third-party risk?

Subcontracting matters because the service the financial entity sees may depend on several providers underneath the primary contract. Long or opaque chains can make it harder to assess security, continuity, data location, concentration, and the ability to supervise the service.

Commission Delegated Regulation (EU) 2025/532 adds specific requirements for subcontracting ICT services that support critical or important functions. It focuses the financial entity's attention on subcontractors that underpin the service, including those whose disruption could impair the security or continuity of the ICT service.

The practical consequence is that "our vendor manages its own subcontractors" is not enough for a critical dependency. The financial entity needs contract rights and information that allow it to understand material subcontracting, assess changes, and decide whether the resulting risk remains acceptable.

The current subcontracting RTS is Commission Delegated Regulation (EU) 2025/532.

For the wider map of DORA Level 2 rules covering third-party risk, the Register of Information, and other workstreams, see our DORA RTS and ITS technical standards list.

Is every provider supporting a critical function a "critical ICT third-party provider"?

No. DORA uses two concepts that are easy to confuse. A financial entity may use an ICT provider for a service supporting one of its critical or important functions. Separately, the European Supervisory Authorities can designate certain ICT third-party service providers as critical for the EU financial sector under Article 31.

The second status is an EU-level designation based on criteria such as systemic impact, the importance of the financial entities relying on the provider, the functions supported, and substitutability. A provider does not become an Article 31 critical ICT third-party service provider simply because one customer classifies a supported function as critical or important.

For the financial entity, Article 28-30 third-party risk duties still matter regardless of whether the provider appears on the EU critical-provider list.

How should DORA third-party risk connect to the rest of the DORA program?

Third-party risk is not an isolated procurement workstream. It feeds directly into operational resilience, DORA incident reporting, and the Register of Information, as well as testing and management oversight.

If a provider supports a critical payment process, for example, the continuity plan needs to reflect that dependency, incident procedures need a route for provider notifications, the register needs the correct contractual and service data, audit rights need to be usable, and the exit plan needs to match the actual recovery options.

That is why separate spreadsheets owned by procurement, IT, risk, and compliance often create gaps. The stronger model is one shared dependency record with clear ownership and links to the controls and evidence each team needs.

A practical DORA third-party risk example

Consider a payment institution using a cloud-based fraud platform for transaction screening. The provider has strong security certifications and a mature product, but the service supports a function the institution cannot easily pause without affecting payment operations.

The DORA question is wider than "is the provider secure?" The institution must determine whether the supported function is critical or important, assess the provider and concentration risk before contracting, understand service and data locations, review subcontracting, negotiate the required contract terms, keep the arrangement in the Register of Information, monitor material changes, and maintain a credible exit path.

The same provider could create a different risk profile for another financial entity that uses it only for a noncritical internal workflow. DORA third-party risk management therefore follows the dependency and business impact, not a universal vendor score.

Common DORA third-party risk mistakes

Most weak implementations fail at the joins between teams rather than at the existence of a vendor policy. These are the problems worth looking for during implementation reviews.

• Treating provider certification as the complete due-diligence decision instead of one source of assurance.
• Classifying the vendor without first classifying the business function and service dependency.
• Keeping the Register of Information separate from the risk process, so contract data and risk decisions drift apart.
• Accepting audit or access clauses that cannot be exercised in practice.
• Ignoring concentration and substitutability because the provider has strong uptime history.
• Reviewing subcontracting only at onboarding even though the delivery chain changes later.
• Writing an exit clause without testing whether data, workloads, integrations, and operations can actually move.

Final thoughts: The goal is control of the dependency, not a larger vendor file

A DORA-ready third-party process should make one thing clear: what happens to the financial service if this ICT dependency degrades, fails, changes, or becomes difficult to exit. Once that is understood, due diligence, contracts, monitoring, register data, continuity, and exit planning can be built around the same risk decision instead of operating as separate compliance tasks.

Frequently asked questions about DORA third-party risk management

These answers cover the short search questions that belong with this page. Detailed register, incident, and broad DORA questions stay with their dedicated guides.

What is DORA third-party risk management?

It is the DORA framework for identifying, assessing, contracting, monitoring, and exiting ICT third-party relationships. Financial entities remain responsible for compliance even when ICT services are outsourced.

What does DORA Article 28 require?

Article 28 covers ICT third-party risk strategy, the Register of Information, pre-contract assessment and due diligence, information-security expectations, monitoring, audit, termination, and exit planning.

Does DORA require third-party due diligence?

Yes. Before entering an ICT service arrangement, financial entities must perform due diligence on prospective ICT third-party providers and ensure the provider is suitable.

Does DORA require a vendor risk register?

DORA requires a Register of Information for ICT service contractual arrangements. A broader vendor-risk register can support governance, but DORA does not prescribe one universal risk-register format.

What is ICT concentration risk under DORA?

It includes reliance on providers that are hard to substitute and multiple critical or important-function arrangements with the same or closely connected providers.

What are DORA third-party contract requirements?

Article 30 requires written terms covering service scope, locations, data/security, incident support, cooperation, termination, and other baseline items. Critical or important functions require additional service-level, audit, testing, monitoring, and exit provisions.

Does DORA apply to subcontractors?

DORA requires financial entities to assess subcontracting risk for ICT services supporting critical or important functions. Delegated Regulation 2025/532 adds detailed requirements for material subcontracting chains.

Is a critical ICT provider the same as a provider supporting a critical function?

No. "Critical ICT third-party service provider" is an ESA designation under Article 31. A provider can support a customer's critical or important function without having that EU-level status.