EBA DORA Alignment Guide (2026 Guide)
You review an outsourcing policy that already references the EBA Guidelines, then someone on the team asks a fair question: “Do we need to rewrite everything because of DORA?” That is where many compliance, legal, procurement, and IT teams are right now. They are not starting from zero. They already have outsourcing controls, vendor inventories, contract clauses, and governance routines shaped by years of supervisory expectations. What they need is clarity on how those EBA expectations fit with DORA, and where the gaps actually are.
The short answer is that DORA did not make the EBA outsourcing conversation disappear. It changed the frame. Outsourcing is now part of a wider digital operational resilience model that covers ICT risk management, incident reporting, testing, third-party oversight, and evidence. If you work in a bank, investment firm, payment institution, or another financial entity affected by DORA, understanding the overlap between EBA outsourcing guidance and DORA can save you from duplicate work and weak controls. If you need a broader foundation first, it helps to start with what is dora.
DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows with a strong focus on technically compliant reporting and audit-ready execution.
Why EBA and DORA are discussed together
The reason is simple: both frameworks care deeply about how financial entities govern external providers that support important business activities. The EBA outsourcing framework focused heavily on outsourcing arrangements, especially those involving critical or important functions. DORA keeps that concern, but broadens it into a more structured ICT third-party risk regime.
In practice, that means your EBA outsourcing work may still be useful, but it may not be enough on its own. DORA applies from 17 January 2025 and creates an EU-wide operational resilience regime for 20 categories of financial entities. Its scope reaches beyond traditional outsourcing classifications and into a fuller view of ICT dependencies, service chains, incident readiness, and supervisory evidence.
If your team is still treating DORA as a contract refresh exercise, you may be underestimating the operational side of the regulation. A better starting point is to read DORA as a resilience framework first, then map your outsourcing controls into it. That broader lens is explained well in dora regulation explained and digital operational resilience act dora.
Where they align most clearly
Here is the good news: there is meaningful continuity. If your institution already built mature outsourcing governance under EBA expectations, you likely have a useful base for DORA. The overlap is strongest in governance, risk assessment, contract discipline, concentration awareness, and board-level accountability.
Governance and accountability still matter
Both EBA and DORA expect management bodies to stay accountable. You cannot outsource responsibility just because you outsourced the service. This means decision-making, risk acceptance, escalation, and monitoring still need clear ownership inside your institution.
What many people overlook is that DORA raises expectations around proving that those controls actually operate. Written policies still matter, but by 2026 the conversation is shifting toward proof of compliance, not just policy existence.
Risk-based classification remains central
Under both approaches, not every provider is treated the same. Institutions need a defensible method to identify which ICT services support critical or important functions, where dependencies sit, and what level of oversight is justified. That naturally connects to dora third party risk.
Contracts are still a control tool, not just legal paperwork
EBA outsourcing guidance pushed firms to improve contractual discipline, and DORA keeps that principle. Contracts need to support oversight, access, auditability, termination planning, and service continuity. The exact wording may vary across institutions and jurisdictions, but the operational purpose is the same: your contract should help you govern the relationship, not merely document it.
Where DORA goes further than EBA outsourcing guidance
This is where the eba dora discussion becomes more than a mapping exercise. DORA does not simply repeat prior outsourcing expectations. It expands them, standardizes parts of them, and connects them to reporting and resilience obligations that many teams historically managed in silos.
DORA centers ICT third-party dependency, not only outsourcing labels
One practical shift is that DORA focuses on ICT third-party service arrangements more directly. Some services that teams previously debated as “outsourcing” versus “non-outsourcing” may still become highly relevant under DORA because they create operational dependency. That is why provider mapping needs to be more complete than older outsourcing inventories.
From a regulatory standpoint, this means your population of in-scope relationships could be wider than the outsourcing register your institution historically maintained. That is especially important when assessing any dora ict service provider.
The Register of Information changes the data burden
DORA requires a Register of Information covering ICT third-party service arrangements. For many firms, this is the biggest operational shift. You are no longer managing only a legal or procurement record. You need structured, reportable data that stands up to supervisor review and EU-level technical requirements.
The first ROI submission deadline was 30 April 2025, and by 2026 regulators are increasingly using automated checks and cross-referencing methods. That makes data quality, entity consistency, and relationship mapping much more important than many institutions first assumed. You can browse the relevant topic cluster under Register of Information.
DORA ties third-party oversight to operational resilience
Under DORA, third-party oversight is not isolated. It connects to incident reporting, resilience testing, internal ICT risk management, and information sharing. If a provider fails, supervisors may care not only about the contract and due diligence file, but also about how the institution identified impact, escalated decisions, recorded evidence, and improved control design afterward.
Subcontracting scrutiny is becoming deeper
Delegated Regulation (EU) 2025/532 brought additional depth to subcontracting risk expectations. In practice, this means firms should look beyond their direct provider and understand material subcontracting chains where relevant. That may require better collaboration across procurement, legal, IT, security, and operational risk teams.
DORA oversight and “critical ICT third-party providers”: what changes beyond your contracts
Here’s the thing: DORA is not only asking each financial entity to manage its own ICT third-party risk. It also introduces an EU-level oversight framework for certain ICT third-party service providers that may be designated as “critical.” The goal is to reduce systemic fragility where many institutions depend on the same providers for services that are hard to replace quickly.
From a practical standpoint, this matters even if you are not a provider and even if your own vendors are not labeled “critical.” Oversight changes the supervisory environment around large ICT dependencies. It can influence the information your institution is expected to collect, how fast remediation is expected to happen when issues appear, and how supervisory questions are framed during reviews.
What financial entities typically need to be ready to evidence is not just “we did due diligence.” It is the ongoing ability to monitor, challenge, and cooperate. That often includes demonstrating how you:
The difference often comes down to operational readiness. If a supervisor expects faster closure of a recurring provider issue, your ability to negotiate contract amendments, enforce controls, or implement compensating controls can become a time-sensitive governance problem, not only a legal one.
So what does this mean for compliance teams? In most cases, it is about reflecting oversight reality in your third-party governance model without overcomplicating it. That typically means clearer escalation paths for high-dependency providers, better internal reporting that connects third-party issues to operational resilience impacts, and a disciplined approach to documenting decisions and residual risk when you cannot get every contractual change you want. Your legal and compliance teams should confirm how oversight expectations apply in your jurisdiction and supervisory context.
What this means for policies, contracts, and registers
If you are aligning EBA outsourcing controls with DORA, the goal is not to duplicate every document. The smarter approach is to update your control architecture so one coherent framework can support both supervisory logic and operational execution.
Policies should describe the control model clearly
Your outsourcing policy, ICT third-party risk policy, procurement standards, and resilience governance documents should not contradict one another. They should explain how the institution identifies ICT services, classifies criticality, approves providers, monitors performance, manages incidents, and exits relationships when needed.
Consider this: a policy library can look complete on paper while still failing in practice because no one owns the data model or workflow between functions. That is often where implementation slips.
Contract reviews need a DORA lens
Contract remediation should usually focus on a few practical questions:
Not every legacy contract can be fixed immediately, so many institutions use risk-based remediation waves. That tends to be more realistic than trying to renegotiate everything at once.
Your data model matters more than teams expect
DORA reporting requires structured outputs, including xbrl for EU-level submissions. That means classification logic, provider identifiers, entity relationships, and service mappings must be coherent enough to convert into technically acceptable reports.
Platforms like DORApp streamline the creation and maintenance of the Register of Information process through a structured workflow: importing existing data, managing it in an intuitive interface, auto-enriching from public sources, validating against technical rules, and generating compliant outputs with fewer manual steps.
A practical contractual clause checklist for ICT services under DORA
Competitors often go more granular than a general “contract refresh” and they are right to. DORA contract expectations are easier to operationalize when you treat clauses as inputs into processes, evidence, and escalation paths. The goal is typically not to copy a clause library blindly. It is to make sure your agreements support day-to-day governance under both dora eba guidelines logic and your internal operating model.
Below is a practical checklist of clause areas that commonly matter for ICT services, especially where the arrangement supports critical or important functions. Your legal team should tailor wording to your jurisdiction and contracting posture, but compliance and risk teams can use the structure to drive consistent reviews:
Think of it this way: every clause should connect to an operational evidence point. Audit rights connect to an audit plan and a request workflow. Incident clauses connect to incident response playbooks and contact lists. Exit support connects to an exit plan that someone maintains and periodically reviews. Subcontractor clauses connect to a process for tracking changes in the supply chain and updating your risk assessment.
Common negotiation sticking points tend to show up in the same places: broad audit rights, short incident notification timelines, subcontractor approval rights, and detailed exit support. In many cases, a realistic mitigation is to define workable alternatives that still preserve governance, for example: pooled audits or third-party assurance reporting where direct audits are constrained, tighter incident cooperation language even when notification timing is negotiated, contractual change notifications plus periodic subcontractor attestations, or a documented compensating control where a provider’s standard terms cannot be changed quickly. What matters is that you document the decision, the residual risk, and the controls that make the arrangement governable.
A practical alignment workplan
If your team is trying to align eba outsourcing dora requirements without creating unnecessary complexity, a phased approach usually works best. The reality is that most institutions already have useful building blocks. The challenge is making them consistent, auditable, and reportable.
Step 1: Map your current outsourcing framework to DORA controls
Start with what exists: outsourcing policy, criticality methodology, contract standards, vendor inventory, due diligence, concentration analysis, and board reporting. Then identify where DORA expects broader ICT third-party coverage, stronger evidence, or more structured reporting.
Step 2: Build a single source of truth for ICT third-party records
This is where many projects stall. Data often sits in legal trackers, procurement tools, spreadsheets, and local team files. Under DORA, this fragmentation becomes a reporting and governance problem. A single controlled record structure helps reduce reconciliation work and supports repeatable updates.
Step 3: Prioritize critical or important relationships first
You do not need to perfect every record on day one. Focus first on relationships tied to critical or important functions, then expand. This is often the fastest way to improve supervisory readiness while staying realistic about internal capacity.
Step 4: Connect contracts, risk, and incidents
DORA expects these areas to inform one another. If a provider has repeated control issues, contract reviews, risk scoring, and incident governance should not happen in isolation. That broader context is one reason to monitor the full DORA Fundamentals category.
Step 5: Test your reportability before a deadline forces the issue
Do not wait until submission season to learn that your data cannot be transformed into a valid output. Teams that test early usually discover hidden problems in legal entity identifiers, service categorization, and relationship hierarchy. With features like automated workflows, non-blocking validation, a streamlined data model that auto-converts to XBRL, and full-text search across records, DORApp supports teams that want to begin operational work before every field is perfect.
What compliance teams often miss
The biggest mistake is treating DORA as only a legal mapping exercise. Yes, legal interpretation matters. But operational resilience lives in process execution, data quality, role clarity, and evidence. If your outsourcing team, IT risk team, procurement team, and legal team all use different definitions and records, you may still have a weak control environment even if each team appears compliant on its own.
Another common issue is underestimating how much supervisory thinking has moved toward evidence and traceability. The shift in 2026 is less about saying “we have a policy” and more about showing how your institution actually runs the process month after month.
That is also why DORApp’s modular design is relevant for many institutions. Rather than forcing a full transformation at once, it allows teams to start with immediate pain points such as the Register of Information or third-party risk workflows, then expand as their DORA operating model matures. For broader context, the published posts DORA Pillars Explained: Complete Breakdown (2026) and DORA European Commission Timeline and History (2026) are also useful background reads.
Precontractual subcontracting checks: how to make the chain visible before you sign
Subcontracting governance often fails before the contract is even signed. The reality is that once a service is live and embedded, it is harder to negotiate transparency, change controls, or approval rights. That is why many teams are bringing subcontracting chain questions into the precontractual phase, not treating them as a later operational problem.
A “precontractual risk assessment” for subcontracting typically means you collect enough information to decide whether the proposed delivery model is governable for your specific use case. In practice, that often includes asking for:
Now, when it comes to internal sign-off, this works best when procurement, IT or security, operational risk, legal, and compliance each own a piece of the assessment. Procurement typically validates commercial feasibility and contracting posture. IT and security assess technical dependency and control fit. Risk and compliance assess criticality, impact, and evidence expectations. Legal confirms contractual enforceability. Not every institution will use the same RACI, but the key is that the decision and its rationale are recorded in a way you can explain later.
Ongoing visibility is the second half of the problem. Even a solid onboarding assessment can go stale if subcontractors change frequently. Many institutions use a mix of contractual change notifications, periodic attestations, and a refresh cadence aligned to criticality. For higher-risk arrangements, that cadence is often tied to operational risk reviews, incident patterns, and concentration considerations.
What many people overlook is the connection back to the Register of Information. If subcontractor details live only in emails or vendor questionnaires, your register can drift away from reality. A more resilient approach is to define which subcontracting data points are reportable and auditable, who maintains them, and how updates flow into your register record as part of a controlled process. That is how subcontracting governance becomes repeatable, not just a one-time due diligence exercise.
Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.
This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.
Explore how DORApp can support your DORA compliance journey with a 14-day free trial at https://dorapp.eu/create-account/ or request a personalized walkthrough at https://dorapp.eu/book-demo/.
Frequently Asked Questions
Does DORA replace the EBA outsourcing guidelines completely?
Not in a simple yes-or-no way. DORA creates a binding EU framework for digital operational resilience, including ICT third-party risk management, but many institutions still use EBA outsourcing logic as part of their control environment. In practice, firms often map existing outsourcing controls into DORA rather than discarding them. The key question is whether your current framework covers DORA’s broader focus on ICT dependencies, operational evidence, reporting, and resilience governance. Your legal and compliance teams should confirm how national supervisors expect those frameworks to interact in your specific case.
What is the main difference between EBA outsourcing and DORA third-party risk?
The main difference is scope and integration. EBA outsourcing guidance traditionally focused on outsourcing arrangements and governance around critical or important functions. DORA keeps those concerns but frames them within a wider ICT third-party risk model. That means regulators may look not only at contracts and due diligence, but also at your Register of Information, incident escalation, resilience testing connections, concentration risk, and ongoing oversight. Think of DORA as broadening third-party control from a legal-governance topic into an operational resilience topic.
Do all ICT providers need to be included in the Register of Information?
DORA requires financial entities to maintain a Register of Information covering ICT third-party service arrangements as currently defined by the framework and related technical standards. The practical challenge is identifying which arrangements belong in scope and how they should be classified. Many institutions discover that their historical outsourcing register is too narrow or too inconsistent for DORA reporting. The safest approach is to build a clear scoping methodology, document assumptions, and test it against legal, procurement, IT, and compliance records rather than relying on one team’s interpretation alone.
How should we handle legacy outsourcing contracts under DORA?
Most institutions handle legacy contracts through phased remediation rather than attempting a full rewrite at once. A common method is to prioritize contracts linked to critical or important functions, high-risk ICT dependencies, or large concentration exposures. Review whether key oversight rights, audit rights, access rights, subcontracting visibility, and exit support are adequate. If immediate renegotiation is not possible, firms often document interim controls and remediation plans. Legal review is essential here because the right contractual approach may depend on jurisdiction, provider bargaining power, and business criticality.
Where does XBRL fit into the EBA and DORA discussion?
XBRL matters because DORA reporting is not just a policy exercise. Certain regulatory submissions require structured technical output, and for EU-level submissions the format is based on the DORA XBRL Data Point Model. That means your provider, entity, and service data needs to be organized in a way that can be transformed into a valid report. Teams sometimes leave this too late and then discover data quality issues. If your process still depends heavily on manually adjusted spreadsheets, technical submission readiness may become a bottleneck.
What should banks do first if they already follow EBA outsourcing guidance?
Start with a gap assessment, not a rebuild. Review your existing outsourcing policy, classification methodology, provider inventory, due diligence process, contract templates, and reporting routines. Then test where DORA requires broader ICT third-party coverage, stronger operational traceability, or a more structured data model. Banks often already have solid governance foundations, but fragmented data and inconsistent ownership across functions create practical weaknesses. A focused mapping exercise can show whether you need policy updates, system changes, workflow redesign, or simply better alignment between existing teams.
How does DORA affect non-bank financial entities that also look to EBA guidance?
DORA applies across 20 categories of EU financial entities, so non-bank firms may still face substantial third-party governance obligations even if their historical supervisory framework was not centered on EBA outsourcing rules. For payment institutions, investment firms, insurers, asset managers, and other regulated entities, the key issue is understanding their own sector rules alongside DORA’s horizontal requirements. In practice, many institutions borrow useful outsourcing concepts from earlier guidance, but they should avoid assuming that older sector habits alone will satisfy DORA’s operational resilience expectations.
Why are supervisors focusing so much on proof of compliance in 2026?
Because the initial compliance phase is over. Supervisors now increasingly expect institutions to show that controls operate continuously, not just that policies exist. Automated checks, structured submissions, and cross-referencing of ICT registers are making weak data and inconsistent governance more visible. From a practical standpoint, this means audit trails, approval records, issue remediation, and data lineage matter more than they did in earlier implementation stages. Institutions that operationalize compliance tend to be in a stronger position than those that treat DORA as a once-a-year reporting task.
Can a platform solve DORA compliance on its own?
No platform should be viewed as a substitute for institutional judgment, legal analysis, or accountable governance. A tool can support data quality, workflow control, reporting, auditability, and cross-team coordination, but your institution still needs sound policies, decision-making, and expert oversight. That said, software can remove a lot of manual friction. DORApp, for example, offers modular support for areas such as the Register of Information, third-party risk management, report generation, audit trail visibility, and data enrichment, which may help teams work more consistently.
What does DORA mean for banks?
For banks, DORA typically formalizes and expands operational resilience expectations into one integrated framework that supervisors can test more consistently across the EU. If you already follow EBA outsourcing guidance, you may have a solid starting point on governance and contracts. The added work is usually in tying ICT third-party oversight to incident response, resilience testing, and structured reporting, especially through the Register of Information. In practice, banks often benefit from clarifying ownership across procurement, IT, risk, legal, and compliance so evidence and reporting stay consistent over time.
What is the difference between ECB and EBA?
The EBA is an EU authority that develops regulatory standards, guidelines, and convergence tools for banking supervision across the EU. The ECB is the central bank for the euro area and also acts as a banking supervisor for significant institutions under the Single Supervisory Mechanism. In day-to-day terms, the EBA often shapes the “rulebook” and supervisory expectations, while the ECB may be one of the supervisors applying those expectations to certain banks. The exact supervisory setup depends on your institution type, size, and where you are licensed.
What is DORA E?
“DORA E” is not a standard term in the regulation itself. People sometimes use it informally to refer to DORA’s European level elements, for example the role of European Supervisory Authorities in developing technical standards or the EU-level oversight approach for certain ICT third-party providers. If you see the term used internally or by a vendor, it is worth asking what exactly they mean, because the practical implications depend on whether the topic is reporting, technical standards, supervisory oversight, or something else.
Is EBA a government agency?
The EBA is an EU agency, not a national government department. It was created to help build consistent supervisory and regulatory practices across the EU banking sector. It does not “supervise” every institution directly in the way a national competent authority or the ECB might, but its guidelines and technical standards can strongly shape what supervisors expect firms to implement.
Key Takeaways
Conclusion
If you are working through the eba dora question, the most useful mindset is this: do not throw away mature outsourcing work, but do not assume it is enough either. DORA changes the center of gravity. It connects third-party oversight to resilience, data quality, governance evidence, and technical reporting in a way many institutions did not previously operationalize.
That creates work, but it also creates a chance to simplify. Instead of maintaining separate interpretations across legal, procurement, risk, and IT, you can build one clearer operating model for ICT third-party governance. In many cases, the institutions making the fastest progress are not those with the biggest documentation sets. They are the ones that align data, workflow, and accountability early.
If you want to keep building that picture, explore the Dorapp blog for more DORA-focused guidance, or see how DORApp approaches structured third-party risk and reporting support at https://dorapp.eu/#features-09-623721. If a hands-on review would help, you can also request a demo at https://dorapp.eu/book-demo/.
About the Author
Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.