DORA Non-ICT Outsourcing for Banks (2026 Guide)
You review your bank's outsourcing inventory and quickly hit a familiar problem. Some arrangements are clearly ICT, cloud hosting, core banking software, cybersecurity monitoring. Others are less obvious: call center services, claims handling support, document archiving, payment operations assistance, back-office processing, HR administration. Your team asks a fair question: if DORA is focused on digital operational resilience, what happens to non-ICT outsourcing?
This is where many banks get stuck. DORA non ict outsourcing is not a separate pillar with its own full outsourcing regime, but it does not disappear from the control framework either. Banks still need to distinguish ICT third-party arrangements from broader outsourcing obligations, especially where EBA outsourcing expectations, operational risk governance, and internal control systems overlap. In practice, this means you may be running two connected lenses at once: DORA for ICT-related services, and banking outsourcing rules for non-ICT services.
DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows with guaranteed technical report acceptance. For banks trying to draw a clean line between ICT and non-ICT arrangements, that distinction matters more in 2026 than it did during initial implementation.
Why this topic matters for banks
If you work in compliance, procurement, operational risk, or IT governance, you have probably already seen this happen. DORA implementation drives a large inventory cleanup, and suddenly services that were once grouped together under "outsourcing" need to be split, re-labeled, and governed differently.
That is why the first step is not just understanding what is dora at a high level. You also need to understand where DORA sits next to existing banking frameworks, especially for banks that were already applying EBA outsourcing rules before 17 January 2025.
Consider this: a payroll provider may be outsourced, material, and operationally important, but not necessarily an ICT third-party service under DORA. A SaaS HR platform, on the other hand, may involve both outsourcing and ICT service considerations. The classification affects contracts, registers, testing expectations, incident escalation, and management reporting.
For banks, the real risk is not only misclassifying one service. It is building a fragmented control model where procurement sees one thing, compliance sees another, and IT risk sees a third.
What DORA covers and what it does not
From a regulatory standpoint, DORA is the EU framework for digital operational resilience in financial services. It applies to financial entities and focuses on five pillars: ICT risk management, incident reporting, resilience testing, ICT third-party risk, and information sharing. If you want the broader context, Dorapp's dora regulation explained article and its overview of the digital operational resilience act dora are useful starting points.
Non-ICT outsourcing is not the main object of DORA
Here is the key point: DORA is primarily concerned with dora ict service provider relationships and the operational resilience risks those services create. That means DORA does not replace every outsourcing rule a bank already follows.
Non-ICT outsourcing may still matter under your broader governance framework, under sectoral guidance, and under national supervisory expectations. So if a service is outsourced but does not qualify as an ICT service, that does not mean it is unmanaged. It means it may sit outside the core DORA third-party regime while remaining inside banking outsourcing, operational risk, business continuity, or internal control obligations.
Why banks often overextend DORA
Many teams reacted to DORA by trying to pull every external arrangement into one DORA-shaped process. That is understandable, but often inefficient. The better approach is to identify which arrangements belong in the DORA Register of Information and which belong in your broader outsourcing register or vendor governance framework.
If your team needs a practical reference point for DORA-specific registers, the Register of Information category is worth reviewing.
What counts as “ICT services” under DORA, and why it matters for scoping
This is where the real operational work starts. Most banks do not get stuck on the idea that DORA applies to ICT third-party risk. They get stuck on what an “ICT service” looks like in practice, especially when a provider is delivering a business function through technology.
Now, when it comes to scoping, a helpful way to think about an ICT service is this: it is typically a digital or data-related service delivered through ICT systems on an ongoing basis, where the technology component is not just a tool used internally by the supplier, but part of what you are buying. This often includes services that store, process, transmit, protect, or make available data or systems you rely on to run banking operations.
What many people overlook is how often hybrid models create confusion. A “business process outsourcing” arrangement might still include an ICT service element if the contracted outcome depends on a provider-run platform, managed portal, hosted workflow tooling, or a provider-controlled environment where your data is processed. In those cases, the service can sit in two places at once: the broader outsourcing frame for the function, and DORA for the ICT component that creates digital resilience exposure.
From a practical standpoint, scoping affects almost everything that comes after it. It influences whether the arrangement belongs in the DORA Register of Information, which contract annexes you trigger, what evidence you request from the provider, and how you structure incident coordination. If your scoping is inconsistent, your controls will be inconsistent too.
A simple “in-scope vs out-of-scope” indicator lens
No single indicator is perfect, but banks often get to a consistent result by applying a small set of repeatable signals.
Think of it this way: scoping is not about whether a supplier uses computers. It is about whether the service you are buying introduces a third-party ICT dependency you need to manage under DORA as ICT third-party risk.
Where EBA outsourcing still matters
The phrase dora eba outsourcing comes up so often because banks are dealing with overlapping regimes, not a clean replacement. EBA outsourcing expectations, as currently understood and subject to national supervisory interpretation, still matter for non-ICT outsourcing and for the broader governance principles around material arrangements.
In practice, this means banks typically still assess non-ICT outsourcing through questions such as:
What many people overlook is that DORA strengthened governance habits even where the service itself is not fully in scope as ICT third-party risk. Banks now expect better inventories, clearer accountability, stronger evidence, and faster issue escalation across all external dependencies.
That is one reason the topic of dora third party risk has become broader in operational practice than the formal text alone might suggest. The legal scope must stay precise, but the internal control culture around third parties has clearly tightened.
Contract clauses banks typically need for ICT third parties (and what changes for non-ICT outsourcing)
Once you classify a service as an ICT third-party arrangement under DORA, the contract conversation usually changes. The goal is not to turn every agreement into a technical document. It is to make sure your bank can evidence oversight, resilience expectations, and cooperation in situations that matter, especially incidents and disruptions.
In most cases, banks end up standardizing a set of DORA-oriented clause themes for ICT services. These themes tend to show up repeatedly across regulated institutions because they map to real operating needs, not just compliance checklists.
Clause themes banks typically focus on for ICT services
For non-ICT outsourcing, many of these topics still matter, but the emphasis often shifts. Non-ICT outsourcing agreements frequently lean more heavily on service level definitions, operational performance management, oversight rights for the function, and exit and substitution arrangements. The incident mechanics may still exist, but they are often framed around service disruption rather than ICT incident handling and digital evidence workflows.
A two-track contracting approach that reduces friction
Many banks find it easier to run two connected contract tracks:
The difference often comes down to internal alignment. If procurement, legal, vendor management, and risk teams do not share the same classification outcome, the wrong playbook gets used. A practical fix is to embed the classification result into the sourcing workflow itself, so the contract template and annexes are selected based on the approved service classification, not based on who happens to be leading the negotiation.
How to classify borderline arrangements
Most banks do not struggle with obvious examples. They struggle with mixed services. A managed service can include people, workflows, software access, data handling, infrastructure dependence, and subcontractors all in one commercial package.
Start with the service actually being delivered
Think of it this way: do not classify the supplier first, classify the service. A law firm is not an ICT provider just because it uses software. A back-office operations provider does not become an ICT third party only because work is done in a portal. But a service built around hosting, processing, transmitting, storing, or securing digital systems and data may well fall into ICT scope.
Ask four practical questions
For each borderline arrangement, banks often benefit from asking:
The answer will not always be binary. Some services may require dual treatment. For example, outsourced payment operations might trigger banking outsourcing governance while also relying on distinct ICT components that belong in DORA records.
Platforms like DORApp streamline the creation and maintenance of the Register of Information process through a 5-step approach: importing existing data, managing it through an intuitive interface, auto-enriching from public sources, validating against ESA rules, and generating compliant reports with one click. That can help when your main challenge is separating ICT reportable arrangements from broader third-party populations rather than rebuilding everything from scratch.
A practical control model for banks
The reality is that banks need a classification model that compliance, procurement, legal, operational risk, and IT can all use consistently. If each team uses different criteria, your inventory will drift within months.
Build a two-layer view
Many banks are moving toward a two-layer structure:
This sounds simple, but it usually forces better documentation. Contract owners have to describe what the provider actually does, what systems are involved, who depends on the service, and what would happen if it failed.
Make ownership explicit
From a practical standpoint, non-ICT outsourcing often falls into a governance gap. It is not fully owned by IT, but it can still create major continuity, conduct, and compliance issues. Banks should assign clear ownership for classification, approval, review, and re-assessment, especially for material services with subcontracting chains.
With features like automated workflows, non-blocking validation, a streamlined data model that auto-converts to XBRL, and full-text search across all records, DORApp allows compliance teams to start working immediately rather than waiting for perfect data. That is especially useful for institutions cleaning legacy records where ICT and non-ICT services were historically mixed.
Keep your registers connected
You do not necessarily need one giant register for everything, but you do need traceability between them. If your outsourcing register, vendor inventory, critical functions list, and DORA Register of Information all use different identifiers and naming conventions, reporting will become fragile very quickly.
This is also where broader concepts like what is digital resilience become practical rather than theoretical. Resilience is not just cyber defense. It is your institution's ability to understand dependencies, absorb disruption, and continue critical operations.
What 2026 changes in practice
2026 is different from the initial implementation phase. Supervisors are moving from "have you prepared?" to "can you prove how this works in daily operations?" For DORA, that means evidence of governance, data quality, classification logic, and repeatable controls.
Under DORA, this means banks should expect more scrutiny around the quality of their ICT third-party inventories, especially after the first Register of Information submission cycle and the growing use of automated cross-checks. The designation of Critical Third-Party Providers in late 2025 and the deeper subcontracting focus in Delegated Regulation (EU) 2025/532 also reinforce the need for cleaner third-party mapping.
For non-ICT outsourcing, the lesson is indirect but important. If your ICT population is poorly separated from non-ICT arrangements, your DORA evidence will be weaker, not stronger. Banks that can explain why a service is in or out of DORA scope, and show the alternative control route for non-ICT arrangements, will usually be in a better position.
What happens if an ICT provider is not DORA-ready, and how banks can respond
Even with good classification, banks often run into a practical bottleneck: the provider cannot produce the evidence, structure, or operational cooperation the bank needs to run DORA controls cleanly. This does not automatically mean the bank is “noncompliant,” but it can create gaps that are hard to explain under supervisory scrutiny if they affect material services.
In day-to-day terms, a provider that is not DORA-ready may struggle with basic requirements such as: providing consistent service and subcontractor data for your registers, supporting incident coordination with the right timing and detail, or demonstrating resilience practices in a way your institution can rely on as evidence. The result is often slower evidence collection, manual workarounds, and a higher chance of inconsistencies between what contracts say and what operations can actually deliver.
For most small business owners and entrepreneurs this would be a procurement inconvenience. For banks, it can become a governance issue because the problem tends to show up during audits, during incidents, or during recurring register submissions.
Banks typically respond with a set of options, chosen based on materiality and risk:
Here is the thing: keeping your ICT and non-ICT populations clean helps you focus pressure where it belongs. You avoid forcing non-ICT suppliers into DORA evidence they may not be able to provide, while ensuring true ICT suppliers are managed with the right level of contractual and operational discipline.
If you want a broader sense of how the framework developed, see DORA European Commission Timeline and History (2026). For the structural breakdown, DORA Pillars Explained: Complete Breakdown (2026) is also helpful. You can also browse DORA Fundamentals for related topics.
Explore how DORApp can support your DORA compliance journey with a 14-day free trial. If your institution wants to discuss classification logic, reporting readiness, or modular rollout, you can also book a demo.
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.
Regulatory note: 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.
Frequently Asked Questions
Does DORA apply directly to non-ICT outsourcing?
Usually, not in the same way it applies to ICT third-party service arrangements. DORA is focused on digital operational resilience and ICT-related third-party risk. If a service is outsourced but does not qualify as an ICT service, it may fall outside the DORA third-party scope while still remaining subject to other banking governance, outsourcing, operational risk, or national supervisory expectations. For banks, the practical task is to classify services carefully and document why a service is treated under DORA, under broader outsourcing rules, or under both frameworks where overlap exists.
What is the difference between outsourcing and an ICT third-party service under DORA?
Outsourcing is a broader concept. It generally covers the use of an external provider to perform functions or services that the institution would otherwise perform itself or that are operationally important. An ICT third-party service under DORA is narrower and tied to technology-related services that affect digital operations and resilience. Some arrangements are both outsourcing and ICT-related. Others are only outsourcing. That is why banks should avoid assuming every outsourced service belongs in DORA-specific processes, especially when the service is mainly operational or administrative rather than technology-delivered.
Can one arrangement be both non-ICT outsourcing and in scope for DORA?
Yes, in some cases an arrangement can involve both dimensions. A provider may deliver a business process while also providing a meaningful ICT component that supports the service. In those situations, banks may need dual governance treatment. One part of the arrangement may sit in the broader outsourcing framework, while the ICT service element may need to be reflected in DORA-specific inventories and controls. The important thing is not forcing a one-label answer where the service model is mixed. Clear documentation of scope, dependencies, and rationale is usually more valuable than oversimplified categorization.
How should banks handle borderline services like payroll, call centers, or document processing?
Banks should assess the actual service delivered, not just the provider type or the software used in the background. Payroll administration, call center services, and document processing may be outsourced services without being ICT services under DORA. But if the service depends heavily on hosted platforms, data processing environments, or managed technology components delivered by the provider, part of the arrangement could still raise DORA-relevant issues. A structured questionnaire and documented classification criteria usually help teams apply the same reasoning across departments and avoid inconsistent treatment.
Do non-ICT outsourced services belong in the DORA Register of Information?
Not automatically. The Register of Information is a DORA-specific requirement for ICT third-party service arrangements. If a non-ICT outsourced service does not include an ICT service element that meets DORA reporting logic, it may belong only in your outsourcing register or vendor inventory, not in the DORA Register of Information. Still, many banks keep references between registers so they can explain dependencies and show supervisors how services were assessed. That traceability can be very useful when a service looks operational at first but includes embedded ICT components.
How does EBA outsourcing guidance fit with DORA for banks?
For banks, EBA outsourcing expectations still matter, especially for non-ICT outsourcing and broader governance around material outsourced functions. DORA did not simply erase those concerns. Instead, it created a more specific regime for ICT-related resilience and third-party risk. In practice, banks often need to apply DORA to ICT third-party services while continuing to use outsourcing governance principles for non-ICT arrangements. National supervisors may also interpret the interaction differently, so institutions should align internal policy with local legal and supervisory advice rather than relying on one simplified rule.
What are the main risks of misclassifying non-ICT outsourcing under DORA?
The biggest risk is weak governance evidence. If a bank puts too many non-ICT services into DORA, the Register of Information can become inflated and harder to validate. If it excludes services without clear rationale, supervisors may question the inventory and classification process. Misclassification also creates operational friction, because procurement, compliance, legal, and IT may follow conflicting controls. Over time, that leads to duplicate reviews, inconsistent contracts, and weak audit trails. A bank is usually better off with a documented classification model than with a large but poorly reasoned inventory.
Should banks maintain separate registers for outsourcing and DORA third parties?
Many do, and that can work well if the records are connected. Separate registers may reflect separate regulatory objectives, one focused on broader outsourcing governance and the other on DORA ICT third-party reporting. The key is consistency across identifiers, service names, entity names, and ownership fields. If the systems cannot be reconciled, the separation becomes a weakness. In practice, banks often benefit from distinct but linked datasets so they can meet DORA reporting needs without losing visibility over non-ICT outsourcing and the wider operational dependency picture.
What should banks show supervisors in 2026?
Supervisors are increasingly interested in proof of compliance rather than project plans. For this topic, banks should be able to show how they classify arrangements, who approves the classification, how often records are reviewed, how ICT and non-ICT populations are distinguished, and how alternative governance applies where DORA does not. Clean inventories, documented rationale, aligned contracts, and evidence of periodic review matter more than polished slide decks. The stronger institutions are usually the ones that can explain their logic clearly and produce supporting records without heavy manual reconstruction.
What is the DORA outsourcing policy?
A DORA outsourcing policy is typically the internal policy (or set of linked policies) a financial entity uses to govern ICT third-party service arrangements under DORA. In practice, it usually sets out how services are classified as ICT or non-ICT, which records must be maintained for DORA reporting, which approvals are required for material ICT dependencies, and how contracts, monitoring, incident coordination, and exit planning are handled. Many banks align it with existing outsourcing and third-party risk policies so the “ICT annex” is triggered only when the arrangement is actually in DORA scope.
What does ICT mean in DORA?
In DORA, ICT generally refers to information and communication technologies: the systems, networks, software, and digital infrastructure used to process, store, transmit, or protect information and enable digital operations. For third-party scoping, the practical question is often whether the provider is delivering an ongoing ICT capability or managing ICT assets or data environments you rely on, rather than simply using technology internally while delivering a people-led service.
Why does DORA cover third-party ICT service providers?
Because third-party ICT dependencies can become single points of failure for digital operations. If a provider that runs key systems, platforms, or security services suffers disruption, the impact can spread quickly across business lines and even across multiple institutions. DORA’s approach is to strengthen governance, oversight, and resilience expectations around these ICT services, while still leaving non-ICT outsourcing to broader banking outsourcing and operational risk frameworks.
What happens if ICT providers are noncompliant with DORA in time?
It depends on the service, its materiality, and what the provider cannot support. In many cases, the immediate effect is operational friction: delays in receiving evidence, gaps in subcontractor transparency, or incident coordination that does not meet your bank’s needs. Over time, those gaps can increase supervisory attention, especially if they affect important services. Banks typically respond through a mix of remediation plans, contract updates, compensating controls, and for material services where gaps persist, stronger exit or substitution planning. The practical aim is to keep ICT and non-ICT populations clearly classified, so requests and controls match what the provider is actually delivering.
Key Takeaways
Conclusion
The practical answer to non ict dora questions is not that non-ICT outsourcing is ignored. It is that banks need a more disciplined distinction between digital resilience obligations and broader outsourcing governance. That distinction matters for reporting, contracts, accountability, and how confidently your institution can explain its control model to supervisors.
Here is the thing: the banks that handle this well usually do not rely on a perfect legal shortcut. They build a usable classification method, connect their inventories, and make ownership clear across compliance, procurement, legal, and IT. That creates better evidence and less internal confusion.
If your team is refining its DORA inventory, reviewing borderline services, or trying to operationalize the Register of Information without losing sight of broader outsourcing obligations, DORApp is one platform worth exploring. You can find more practical guidance on the Dorapp blog and see how DORApp approaches structured DORA workflows, XBRL-ready reporting, and year-round evidence management at dorapp.eu.
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.