DORA Third Party Compliance: Essential Requirements for Financial Services

By James Rees, MD, Razorthorn Security
Last Updated: February 2026

Razorthorn helps financial institutions meet DORA third party compliance requirements under the Digital Operational Resilience Act (EU 2022/2554). Since January 2025, banks, insurers and investment firms must demonstrate proper oversight of ICT service providers through specific contractual controls, risk assessments, continuous monitoring and detailed exit strategies. The requirements sit in Articles 28-44 of the regulation and apply to over 21,000 financial entities across the EU, with serious penalties for non-compliance.

This isn’t just another regulatory hurdle. DORA compliance fundamentally changes how financial institutions manage operational risk, particularly when it comes to the third party providers that now handle much of their critical technology infrastructure.

Here’s the reality: most banks, insurers and investment firms now depend on external providers for everything from cloud hosting to payment processing. A decade ago, you might have run your own data centres and built most systems in-house. Today, your operational resilience is only as strong as your weakest third party link.

DORA recognises this shift. Rather than treating third party risk as a side issue, the regulation puts it front and centre. EU financial entities need to demonstrate they have proper oversight, monitoring and contractual controls over their ICT service providers. The days of signing standard terms and hoping for the best are over.

This isn’t just about ticking compliance boxes. Getting third party risk management right under DORA means better operational resilience. It means clearer accountability when things go wrong. It means stronger negotiating positions with providers who know you’re serious about risk management.

What follows is a practical guide to the contract requirements and risk management frameworks that will actually keep regulators happy whilst protecting your business when the inevitable incidents occur.

What are the DORA requirements for third party compliance?

Razorthorn Security works with financial institutions to meet DORA’s third party requirements, covering contractual controls, risk assessments, continuous monitoring and exit strategies for all ICT service providers.

Don’t let the legal numbering fool you into thinking this is optional fine print. These requirements, set out in Chapter V (Articles 28-44), form the backbone of how financial institutions must manage ICT outsourcing relationships.

How does DORA classify critical and non-critical ICT providers?

DORA splits ICT third party providers into two categories. Getting this classification right matters enormously for what you need to do next.

Critical ICT third party providers are those supporting functions that, if disrupted, would materially impact your business operations, financial position or regulatory compliance. This could be core banking systems, trading platforms or payment processing services. If losing the service would force you to invoke business continuity plans or potentially breach regulatory requirements, it’s almost certainly critical.

Non-critical providers handle everything else. This could be your office productivity software, standard HR systems or marketing tools. The regulatory burden is lighter, but you still can’t ignore them entirely.

The European Supervisory Authorities will maintain a public register of critical ICT third party providers. However, you can’t wait for that list to appear. You need to make your own assessments now based on the impact losing each service would have on your operations.

What obligations can’t be delegated under DORA?

Under DORA, you remain fully accountable for outsourced functions. This isn’t new in principle. DORA makes the practical requirements much more explicit though.

Governance and oversight: You need clear policies covering how third party relationships are approved, monitored and terminated. Your board and senior management must understand and approve your approach to critical dependencies.

Risk assessment: You must assess each provider’s operational resilience, security controls and financial stability. This happens before signing contracts and regularly throughout the relationship. Generic questionnaires won’t suffice. You need evidence.

Monitoring and testing: Continuous monitoring of critical providers’ performance and regular testing of their incident response capabilities becomes mandatory, not optional.

Incident management: You need clear processes for how incidents at third parties are reported to you. You need to know how you’ll communicate with customers and regulators. You need plans for how you’ll manage the operational and reputational impact.

Register of Information: Under Article 28(3), you must maintain and regularly update a register of all contractual arrangements with ICT third party service providers at entity, sub-consolidated and consolidated levels. This register must distinguish between critical and non-critical services and be reported to competent authorities at least annually.

Where do we stand now?

DORA has been in force since January 2025, with no phase-in period for third party requirements. At the time of writing, the implementation picture is mixed. Some providers adapted their terms early and are now seen as preferred partners by financial institutions seeking DORA compliant arrangements. Others are still working through the implications and may be facing pressure to update their approach.

If you’re still working through your critical third party contracts, you’re not alone. Many institutions are finding that meaningful renegotiations take longer than expected, particularly with large providers. Regulators are taking a pragmatic approach to enforcement, recognising these realities. Razorthorn recommends documenting your current contractual position against DORA’s requirements so you can show regulators clear evidence of progress, even where full compliance isn’t yet achievable.

What contract clauses does DORA require for ICT providers?

Getting DORA compliant contracts isn’t about adding a few standard clauses to your existing templates. The regulation demands specific rights and protections that many financial institutions have never properly secured from their ICT providers. Article 30 sets out the minimum contractual requirements, with enhanced obligations for providers supporting critical or important functions.

What audit and access rights does DORA require?

DORA requires you to have full access to all relevant information about outsourced services. This goes far beyond the typical “we’ll provide reasonable information upon request” clauses that providers love to include.

You need contractual rights to access detailed information about the provider’s ICT systems, processes and controls; conduct on-site inspections (or virtual equivalents) with reasonable notice; review subcontractor arrangements and security measures; and obtain copies of relevant policies, procedures and incident reports.

But here’s the catch. Cloud providers and large software companies have spent years standardising their terms precisely to avoid these kinds of detailed oversight requirements. They’ll argue that their certifications (ISO 27001, SOC 2, etc.) should be sufficient. Under DORA, they’re not.

Your contracts need to specify what “reasonable notice” means for inspections. They need to specify who pays for what during audits and how disputes about access will be resolved. Vague language here will cause problems later.

What does DORA require for data location and residency?

DORA doesn’t explicitly mandate data residency within the EU. It does require you to know where your data is at all times and ensure you can access it when needed. This creates practical requirements that affect how you structure contracts.

Key contractual provisions should cover specific geographic locations where data will be stored and processed; prior written consent requirements before data is moved to new locations; guarantees about data sovereignty and local law compliance; and emergency data access procedures that work regardless of geopolitical issues.

This is particularly important for cloud services. Data might be replicated across multiple regions for performance or resilience reasons. Your contract needs to give you visibility and control over these decisions.

What incident reporting obligations must be included in contracts?

Standard IT service contracts typically include broad service level agreements but limited incident reporting requirements. DORA changes this significantly.

Your contracts must specify what constitutes an incident that must be reported to you; timeframes for initial notification (hours, not days); required information in incident reports; escalation procedures for serious incidents; and your provider’s obligations to help you meet your own regulatory reporting requirements.

Remember, you still need to report major ICT incidents to regulators within specific timeframes. This applies even if the problem sits entirely with a third party. Your contracts need to ensure providers give you the information to do this properly.

What exit strategy and data retrieval rights does DORA require?

DORA requires detailed exit strategies for critical ICT third party relationships. This means your contracts need to address what happens when relationships end, whether planned or not.

Essential exit clauses include minimum notice periods before service termination; data extraction rights and technical specifications; transition assistance obligations and timeframes; intellectual property and licensing arrangements post-termination; and cost allocation for exit activities.

Many providers try to limit their exit obligations to basic data dumps in standard formats. For critical systems, this won’t be sufficient. You need commitments to reasonable transition assistance and data portability that actually enables you to move to alternative providers.

What business continuity standards must contracts include?

Generic business continuity clauses won’t meet DORA requirements. You need specific, measurable commitments about operational resilience.

Your contracts should define recovery time objectives (RTOs) and recovery point objectives (RPOs) for different scenarios; testing frequency and methodology for disaster recovery plans; geographic distribution of backup facilities and data; communication protocols during major incidents; and performance standards that apply during recovery situations.

The key is making these requirements specific enough to be enforceable but realistic enough that providers will actually agree to them.

What are the biggest challenges with DORA third party compliance?

Theory is one thing. Practice is quite another. Since DORA came into force, several issues keep coming up that don’t have easy answers. Many financial institutions are still wrestling with these challenges.

The single biggest mistake we see is treating third party compliance as a contract drafting exercise – it isn’t. Contracts matter, but without the operational processes to monitor, test and enforce those terms, they’re just paper.

How do you handle large cloud providers who won’t negotiate DORA compliant terms?

The elephant in the room remains what happens when critical providers simply refuse to negotiate DORA compliant terms. Microsoft, Amazon, Google and other hyperscale cloud providers have spent years standardising their contracts to avoid exactly the kinds of detailed oversight requirements DORA mandates.

Their standard response continues to be pointing to their certifications, transparency reports and shared responsibility models. While these provide some assurance, they don’t give you the specific access rights and incident reporting obligations DORA requires.

Practical approaches financial institutions are using include:

Collective bargaining: Industry associations and buying consortiums continue working together to demand better terms from major providers.

Alternative providers: Some institutions have moved critical workloads to smaller, more flexible cloud providers who are willing to negotiate.

Hybrid approaches: Keeping the most critical functions with providers who will agree to enhanced terms whilst accepting standard terms for less critical services.

Risk acceptance: Documenting the residual risk where better terms aren’t available and ensuring governance processes acknowledge these limitations.

None of these approaches is perfect. However, regulatory expectations mean doing nothing isn’t an option.

How does DORA address subcontracting chains and fourth party visibility?

Modern ICT services rarely involve just two parties. Your primary provider almost certainly uses subcontractors. Those subcontractors may use their own suppliers. DORA requires you to understand these relationships, but getting visibility remains challenging.

The regulation requires your contracts to address subcontracting, including prior approval rights for critical subcontractors; information sharing about subcontractor arrangements; flow-down of key contractual obligations to subcontractors; and incident reporting that covers the entire supply chain.

In practice, many providers will still only commit to sharing information about “material” subcontractors or those handling “sensitive” data. You need to continue negotiating definitions that actually give you the visibility DORA requires.

How do cross-border data flows interact with DORA compliance?

DORA operates alongside GDPR, national data protection laws and increasingly complex international data transfer rules. When your ICT providers operate globally, these requirements can still conflict.

Ongoing challenges include US cloud providers subject to laws that may conflict with EU data protection requirements; data localisation requirements in some EU member states that limit where providers can process data; third country adequacy decisions that change over time and affect existing arrangements; and sector-specific rules (like banking regulations) that impose additional constraints.

Your contracts still need to address how these conflicts will be resolved. They need to specify who bears the risk when regulations change. Standard “comply with applicable law” clauses remain insufficient.

What are the cost implications of DORA third party compliance?

DORA’s monitoring and oversight requirements aren’t free. The cost implications are now becoming clearer. Enhanced reporting, more frequent testing, additional audit rights and stronger exit provisions all have ongoing cost impacts.

Providers have started pricing these requirements into their proposals, either as standard service features or optional add-ons. Financial institutions are now budgeting for premium pricing for DORA compliant service levels; audit and assessment costs for due diligence and ongoing monitoring; legal and negotiation expenses for contract renegotiations; technology investments for enhanced monitoring and reporting capabilities; and staff costs for expanded risk management and vendor oversight teams.

Understanding these costs and building them into business cases for critical ICT relationships has become essential. But the alternative (non-compliance with DORA) is proving to be far more expensive.

How should financial institutions implement DORA third party compliance?

Having the right contract clauses is only half the battle. The other half is building the operational capabilities to actually manage third party relationships in line with DORA requirements.

What does a DORA compliant risk assessment framework look like?

DORA requires “comprehensive assessment” of third party providers, but doesn’t specify exactly what this means. Regulators will be looking for evidence that your assessments are thorough, consistent and actually inform decision-making.

Effective frameworks typically include:

Financial stability analysis: Can the provider maintain services through economic downturns? Credit ratings and financial statements matter. So do revenue concentration, customer dependencies and funding sources.

Operational resilience testing: How do they actually perform during incidents? This means going beyond their disaster recovery documentation to understand real-world response times and effectiveness.

Security and compliance posture: Certifications are a starting point. You need evidence of actual security practices, incident history and how they handle vulnerabilities.

Governance and risk management: Do they have proper oversight of their own supply chains? How do they manage changes that might affect your services?

The assessment needs to be documented, updated regularly and clearly linked to contract terms and ongoing monitoring activities. Generic questionnaires filled out once during procurement won’t satisfy regulators.

How should you prioritise existing contracts for DORA compliance?

Most financial institutions have hundreds or thousands of existing ICT contracts that predate DORA. You can’t renegotiate everything at once. A strategic approach to prioritisation remains essential.

Prioritise critical providers: If you haven’t already, focus your efforts on relationships that would cause the most operational disruption if they failed.

Use contract renewal cycles: When contracts come up for renewal, use the opportunity to incorporate DORA requirements rather than trying to amend mid-term.

Use procurement power: New procurements continue to give you the strongest negotiating position to demand DORA compliant terms.

Risk-based amendments: For existing contracts that can’t wait for renewal, focus amendments on the highest-risk areas rather than trying to achieve perfect compliance immediately.

Remember that DORA compliance isn’t binary. Making meaningful progress on the most important relationships is better than achieving perfect compliance on a few contracts whilst ignoring the rest. And that’s exactly why Razorthorn recommends tying your prioritisation directly to your business impact assessments rather than working alphabetically through your provider list.

How do you get legal, risk and procurement teams aligned?

DORA implementation requires close collaboration between risk management, legal and procurement functions. These teams often have different priorities and ways of working. Success depends on getting them aligned.

Risk management teams need to translate regulatory requirements into specific contract language that legal teams can negotiate, provide clear risk ratings that help procurement prioritise which battles to fight and support contract negotiations with technical expertise about operational requirements.

Legal teams need to understand the operational context behind DORA requirements rather than treating them as abstract compliance obligations, develop template clauses that can be reused across multiple negotiations and balance regulatory requirements with commercial reality when providers push back.

Procurement teams need to factor DORA compliance into supplier selection criteria and cost evaluations, build relationships with suppliers who understand regulatory requirements and plan contract cycles to allow time for proper risk assessment and negotiation.

Regular cross-functional meetings, shared training sessions and joint planning exercises help ensure everyone understands their role in DORA implementation.

Key takeaways for DORA third party compliance

Act decisively: Regulators expect to see concrete progress on third party compliance. If you’re still in early stages of contract renegotiations with critical providers, accelerate these discussions and demonstrate clear timelines for completion.

Focus on what matters: Not every contract needs the same level of attention. Concentrate your efforts on critical relationships that pose the greatest operational risk.

Think beyond compliance: The goal isn’t just regulatory box-ticking. Better third party risk management under DORA should genuinely improve your operational resilience and incident response capabilities.

Build internal expertise: Your legal and risk teams need to understand DORA’s operational requirements, not just its contract clauses. Training pays for itself during provider negotiations.

Accept imperfection: Perfect DORA compliance may not be achievable immediately, especially with large providers who won’t negotiate. Document your efforts, manage residual risks appropriately and keep working toward better arrangements over time.

Razorthorn Security’s recommendation

Third party compliance is the hardest part of DORA for most financial institutions. It touches every provider relationship, every contract and every operational process that depends on external technology. It’s also the area where regulators are paying closest attention.

Razorthorn’s approach starts with a targeted gap analysis of your critical ICT provider relationships, mapping your current contractual position against DORA’s requirements in Articles 28-44. From there, we prioritise the contract renegotiations, monitoring processes and exit strategies that will have the biggest impact on your compliance position.

We don’t try to do everything at once. We focus on the relationships that pose the greatest operational risk first and build a practical programme that your legal, risk and procurement teams can actually deliver. If you want to know where your organisation stands on DORA third party compliance, get in touch.

Resources for staying current

DORA guidance continues to evolve as regulators provide more detailed implementation guidance and industry practices develop. Key resources to monitor include the European Banking Authority (EBA) regulatory technical standards and supervisory expectations; ESMA guidance for investment firms and market infrastructure; EIOPA implementation materials for insurers; industry associations like the European Banking Federation and Insurance Europe for practical guidance; and legal updates from specialist financial services law firms tracking regulatory developments.

If you are looking for more information on DORA compliance, visit our DORA Resource Hub.

Get in touch to discuss how Razorthorn can help with your cybersecurity requirements.

Frequently asked questions about DORA third party compliance

What is DORA third party compliance?

DORA third party compliance refers to the requirements under the Digital Operational Resilience Act (EU Regulation 2022/2554) for financial institutions to manage risks associated with their ICT third party service providers. It covers contractual controls, risk assessments, continuous monitoring, incident reporting and exit strategies for all ICT outsourcing arrangements, with enhanced requirements for providers classified as critical. The requirements are set out in Articles 28-44 of the regulation.

Which organisations does DORA third party compliance apply to?

DORA applies to over 21,000 financial entities across the EU, including banks, credit institutions, investment firms, insurance companies, payment institutions, crypto-asset providers and crowdfunding platforms. It also applies directly to ICT third party service providers designated as critical by the European Supervisory Authorities. The regulation has been in force since January 2025 with no phase-in period for third party requirements.

What are the penalties for DORA non-compliance?

DORA penalties work differently depending on who is in breach. For financial entities, administrative penalties are set by individual EU member states under Article 50 of DORA, and vary by country. Turnover-based ceilings range from 5% to 10% of annual turnover depending on the jurisdiction, with some member states also imposing absolute caps. For critical ICT third party providers under the ESA oversight framework, penalties can reach up to 1% of average daily worldwide turnover, accumulating daily for up to six months until compliance is achieved. Individual senior managers can also face personal fines. Competent authorities also have powers to publicly disclose breaches, restrict business activities or suspend operations in severe cases.

What is a critical ICT third party provider under DORA?

A critical ICT third party provider is one that supports functions which, if disrupted, would materially impact a financial institution’s business operations, financial position or regulatory compliance. Examples include core banking systems, trading platforms and payment processing services. The European Supervisory Authorities maintain a register of designated critical providers, but financial institutions must also make their own assessments based on the operational impact of losing each service.

Does DORA require data to be stored within the EU?

DORA does not explicitly mandate EU data residency. However, it requires financial institutions to know where their data is stored and processed at all times and to ensure access regardless of geopolitical circumstances. This creates practical requirements for contractual provisions covering data location, consent for data transfers and emergency access procedures.

What is the DORA Register of Information?

The Register of Information is a mandatory record that financial institutions must maintain under Article 28(3) of DORA. It must document all contractual arrangements with ICT third party service providers at entity, sub-consolidated and consolidated levels, distinguishing between critical and non-critical services. The register must be reported to competent authorities at least annually and serves as both an internal risk monitoring tool and a regulatory oversight resource.

How does DORA relate to GDPR and NIS2?

DORA operates alongside GDPR and is considered sector-specific legislation in relation to the NIS2 Directive. For financial entities covered by DORA, its provisions on ICT risk management, incident reporting and third party risk take precedence over the equivalent NIS2 requirements. GDPR obligations for data protection continue to apply in parallel with DORA’s operational resilience requirements.

Can financial institutions use pooled audits to meet DORA audit requirements?

Yes. DORA recognises that individual financial institutions may not always have the resources or leverage to conduct independent audits of large ICT providers. The regulation allows for pooled audits conducted by groups of financial institutions, as well as reliance on third party audits, provided these meet regulatory standards and cover the necessary scope. This is particularly relevant for oversight of hyperscale cloud providers where individual institutions have limited negotiating power.