If you work in financial services or supply technology to firms that do, the Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554, changed your world on January 17, 2025. It is now binding law across all EU Member States, and it targets one of the most overlooked weaknesses in financial sector security: the ICT (Information and Communication Technology) supply chain.
This article cuts straight to what DORA demands from you, what risks it targets, and which security controls you need to have in place. No fluff.
What DORA Means for Your Supply Chain
DORA does not just regulate banks and insurers. It reaches every organization that supplies ICT services to EU-regulated financial entities, including cloud providers, data analytics firms, software vendors, and data centers, whether they are based inside or outside the EU.
The core principle is blunt: financial entities can outsource technology services, but they cannot outsource accountability. Under Article 28(1) of DORA, your institution remains fully responsible for meeting all regulatory obligations even when a third party delivers the underlying service. That is a significant shift from older outsourcing models, where the regulatory burden was often felt to be shared.
DORA’s supply chain provisions sit primarily in Chapter V, Articles 28 through 44, which govern the management of ICT third-party risks and the oversight of critical providers.
The Three Supply Chain Risks DORA Is Solving
Before you can manage the requirements, you need to understand the risks DORA is explicitly designed to address.
- Concentration risk. Article 29 requires financial entities to assess whether they are dangerously dependent on a small number of providers, or on providers that are non-substitutable. If one cloud vendor goes down and half the EU’s financial system follows, that is concentration risk materializing at a systemic level. DORA treats this as a sector-wide threat, not just a firm-level operational issue.
- Subcontracting chain opacity. Your cloud provider may subcontract to a data center operator, who subcontracts network services to a fourth party, and so on. Article 30(5) of DORA specifically addresses this cascading visibility problem. You are expected to understand and assess the risks introduced by long or complex subcontracting chains, particularly for services that support critical or important functions.
- Vendor lock-in. DORA requires documented exit strategies under Article 28(8). If a provider fails, raises prices abruptly, or loses regulatory approval, your institution must be able to exit without operational disruption. Exit strategies must be comprehensive, documented, periodically tested, and reviewed.
Core Requirements: What You Must Do
Build a Third-Party Risk Strategy
Under Article 28(2), every non-microenterprise financial entity must establish and regularly review a formal strategy for ICT third-party risk. This is not a generic risk policy. It must specifically address your reliance on providers supporting critical or important functions and must be reviewed by senior management. DORA places accountability for supply chain risk squarely at the board level.
Maintain a Register of Information
Article 28(3) requires you to maintain a Register of Information (RoI) covering all contractual arrangements with ICT third-party service providers. The register must be maintained at entity, sub-consolidated, and consolidated levels. It serves three purposes: internal monitoring, regulatory supervision, and the designation of Critical ICT Third-Party Providers (CTPPs) by the European Supervisory Authorities (ESAs).
Competent authorities began collecting these registers in April 2025. The ESAs use the data to assess systemic concentration and identify which providers qualify for direct oversight.
Conduct Pre-Contract Due Diligence
Before signing any contract with an ICT provider, Article 28(4) requires you to conduct a thorough risk assessment. That assessment must cover potential concentration risk, the suitability of the provider, conflicts of interest, and the presence of appropriate information security standards. For services supporting critical or important functions, Article 28(5) raises the bar: you must verify that the provider meets the most up-to-date and highest-quality security standards available.
Enforce Mandatory Contractual Provisions
Article 30 specifies the minimum contractual requirements for all ICT third-party arrangements. When a service supports a critical or important function, contracts must additionally include unrestricted rights of access, inspection, and audit by the financial entity, appointed third parties, and competent authorities. Contracts must also cover clear service levels, incident reporting obligations, data portability rights, and provisions for orderly exit.
| Requirement | Standard Service | Critical/Important Function |
|---|---|---|
| Information security standards | Appropriate | Highest available |
| Audit rights | Risk-based frequency | Unrestricted, contractually guaranteed |
| Exit strategy | Required | Documented, tested, reviewed |
| Subcontracting oversight | General monitoring | Full chain assessment |
| Incident reporting | Required | Required, with client notification |
Critical ICT Third-Party Providers: The New Oversight Tier
DORA introduces a category of providers that face direct regulatory oversight: Critical ICT Third-Party Providers (CTPPs). The ESAs, made up of the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA), designate these providers based on systemic impact, substitutability, and the concentration of financial entities relying on them.
The designation process formally kicked off in 2025. Providers notified of potential CTPP status have a six-week window to object. Once designated, they are subject to ongoing oversight from a lead ESA supervisor, including inspections, recommendations, and the power to require changes to security practices. For the first time, technology companies that have never been directly regulated are now under EU supervisory authority.
If you are an ICT provider, this is the development that matters most to you right now.
Security Controls DORA Requires Across Your Supply Chain
DORA does not prescribe a specific security framework by name, but its requirements align closely with ISO 27001 (International Organization for Standardization’s information security management standard) and the NIST Cybersecurity Framework. Here is what the regulation expects in practice.
- Continuous monitoring. You cannot audit 30 suppliers once a year and call it compliance. DORA expects ongoing performance monitoring against agreed service levels, security standards, and incident response metrics. In practice, this means dashboards, automated status feeds, and regular reporting to senior management, not annual questionnaires.
- Tiered risk management. Not every supplier warrants the same level of scrutiny. You are expected to classify providers based on criticality and apply proportionate controls. Providers supporting critical or important functions receive the most intensive oversight; lower-risk vendors are managed accordingly. DORA’s proportionality principle, stated in Article 4, acknowledges this explicitly.
- Penetration testing inclusion. Article 26 covers Threat Led Penetration Testing (TLPT). ICT third-party providers may be included within the scope of advanced resilience testing. If a test could disrupt the provider’s operations or expose customer data outside DORA’s scope, the provider and the financial entity must enter a formal contractual agreement with the external testers. Your supply chain is now part of your red team exercise.
- Incident reporting integration. When a major ICT incident occurs, your providers are expected to participate in the response. Article 19 sets tight reporting timelines: initial notification to competent authorities within 24 hours, a follow-up report within 72 hours, and a final report within one month. Your contracts must reflect these obligations.
- Exit and transition planning. You must be able to move critical functions to an alternative provider without service disruption. Article 28(8) requires exit plans that are comprehensive, documented, tested, and reviewed periodically. Vendor lock-in is not just a commercial problem under DORA; it is a compliance failure.
How DORA Relates to Other Frameworks
DORA was designed to be the sector-specific regulation for financial entities under the NIS 2 Directive (Network and Information Security Directive). This means that where both apply, DORA takes precedence for financial entities. If your organization already operates under NIS 2, an ISO 27001 Information Security Management System, or the UK’s FCA PS21/3 operational resilience standards, DORA builds on top of those, it does not replace them. The governance structures, risk registers, and security controls you already have are a strong foundation. The gaps typically appear in supply chain depth, contractual rigor, and exit planning.
Five Practical Steps to Get Compliant Now
If your program is not yet where it needs to be, focus here first.
- Map your full ICT supply chain. Include fourth and fifth parties where your critical providers subcontract. The RoI is not optional, and regulators are already collecting it.
- Classify every provider by criticality. Determine which services support critical or important functions. That classification drives every other obligation, from due diligence depth to contract terms to audit frequency.
- Audit your contracts against Article 30. Many legacy agreements lack the audit rights, exit provisions, and incident reporting obligations DORA mandates. Prioritize contracts for critical services first and renegotiate where necessary.
- Build a continuous monitoring program. Move beyond annual assessments. Implement automated performance tracking, security posture monitoring, and internal reporting to senior management.
- Document and test your exit strategies. For every critical provider, define what exit looks like, who is responsible, what the timeline is, and where the alternative provider is. Then test it.
The Bottom Line
DORA is not a compliance checkbox. It is a structural change in how financial institutions must manage their technology supply chains, extending regulatory expectations from the boardroom all the way down to a provider’s subcontractors. The good news is that the requirements are clear, the timeline is set, and organizations that already invest in sound risk management practices are most of the way there.
