DORA Third Party Compliance: Essential Requirements for Financial Services

By James Rees, MD, Razorthorn Security

The Digital Operational Resilience Act (DORA) third party compliance requires EU financial institutions to implement specific contractual controls, risk assessments and monitoring processes for all ICT service providers. Since January 2025, banks, insurers and investment firms must demonstrate proper oversight of external technology providers through enhanced contract clauses, continuous monitoring and detailed exit strategies.

This isn’t just another regulatory hurdle. DORA fundamentally changes how financial institutions manage operational risk. This is particularly true when it comes to the third party providers that now handle much of their critical technology infrastructure. DORA third party compliance has become a critical priority for EU financial institutions since the regulation came into force in January 2025.

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.

DORA Third Party Compliance Requirements (in Plain English)

DORA’s approach to third party risk sits in Chapter V of the regulation (Articles 28-44). Don’t let the legal numbering fool you into thinking this is optional fine print. These requirements form the backbone of how financial institutions must manage ICT outsourcing relationships.

The Critical vs Non-Critical Distinction

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.

Key Obligations You Can’t Delegate

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.

Where 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. What they want to see is clear evidence of progress and proper risk management of any gaps whilst you work toward full compliance.

Contract Clauses That Actually Matter

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.

Access and Audit Rights (The Non-Negotiables)

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
  • 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.

Data Location and Residency Requirements

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
  • 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.

Incident Reporting Obligations

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
  • 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.

Exit Planning and Data Retrieval Rights

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
  • 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.

Business Continuity and Disaster Recovery Standards

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
  • 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.

The Tricky Bits Everyone’s Still Wrestling With

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 working through these challenges.

Dealing with Large Cloud Providers Who Won’t Budge

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.

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
  • 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.

Cross-Border Data Flows and Conflicting Regulations

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
  • 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.

Cost Implications of Enhanced Monitoring Requirements

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
  • 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. The alternative – non-compliance with DORA – is proving to be far more expensive.

Implementing DORA Third Party Compliance in Practice

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.

Risk Assessment Frameworks That Regulators Will Recognise

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.

Documentation and Record-Keeping That Won’t Drive You Mad

DORA creates significant documentation requirements. The goal isn’t to generate paperwork for its own sake though. The documentation should actually help you manage relationships more effectively.

Key documents that serve both compliance and operational purposes:

  • Third party risk registers that link specific risks to mitigation measures and contract clauses
  • Incident logs that track both your own operational issues and problems at third parties
  • Testing records that demonstrate regular validation of provider capabilities and your own response procedures
  • Performance dashboards that give management clear visibility of third party performance and risk levels

The trick is building these into your normal operational processes rather than treating them as separate compliance exercises. If your teams find the documentation useful for day-to-day risk management, it’s more likely to stay current and accurate.

Managing Existing Contracts vs New Procurement

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.

Practical steps that continue to work:

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.

Leverage 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.

Building Relationships with Legal and Procurement Teams

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 teams prioritise which battles to fight with providers
  • 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
  • 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 and support regulatory requirements
  • 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.

Conclusion

DORA represents a fundamental shift in how financial institutions must manage third party ICT relationships. The regulation recognises that operational resilience now depends as much on external providers as internal capabilities. It demands corresponding changes in oversight and control.

The key takeaways for immediate action:

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 capabilities, not just contracts: Having the right contract clauses is important, but you also need the operational processes and expertise to actually manage relationships effectively.

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.

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:

  • European Banking Authority (EBA) regulatory technical standards and supervisory expectations
  • European Securities and Markets Authority (ESMA) guidance for investment firms and market infrastructure
  • European Insurance and Occupational Pensions Authority (EIOPA) implementation materials for insurers
  • Industry associations like the European Banking Federation and Insurance Europe for practical guidance and template approaches
  • Legal updates from specialist financial services law firms tracking regulatory developments

The regulatory landscape will continue evolving. However, the fundamental principle is clear: operational resilience requires proper oversight of third party relationships. That oversight must be built into contracts, processes and governance structures from the ground up.

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.

TALK TO US ABOUT YOUR THIRD PARTY SECURITY REQUIREMENTS

Please leave a few contact details and one of our team will get back to you.

Follow Us