DORA (applicable as of 17 January 2025) affects how a bank assesses and oversees ICT service providers in IT outsourcing. In practice, the bank will require: governance (KPI/SLA), auditability, incident handling rules, control over subcontractors, BCP/DR (where applicable) and an exit plan.
DORA (Digital Operational Resilience Act) is an EU regulation concerning the digital operational resilience of the financial sector. It has applied since 17 January 2025 and affects, among other things, how banks manage ICT risk and their relationships with ICT service providers (outsourcing).
This article is a practical checklist for banks and for teams in: Vendor Management / Procurement / IT / Security / PMO. You can use it in:
RFP/RFQ for IT outsourcing (staff augmentation),
a request for a dedicated team,
cyclical vendor reviews,
tightening governance and the “auditability” of the cooperation.
Important: this is informational material, not legal advice or a regulatory interpretation. The final assessment of compliance and contractual requirements should always go through the bank’s legal/compliance teams.
TL;DR: what a bank usually wants to have “under control” in IT outsourcing after DORA
Regardless of the model (staff augmentation / dedicated team / managed services), in practice a bank will aim to have:
a clear scope of services and responsibilities,
governance (KPI/SLA, reporting, escalations),
the ability to obtain insight/audit and access to evidence,
defined rules for incident handling and information-sharing,
control over subcontracting (subcontractors and changes in the supply chain),
BCP/DR and an approach to testing (appropriate to criticality),
an exit plan (leaving without lock-in and without losing knowledge),
consistent data for the register of information on ICT provider contracts (register of information).
What does DORA change in IT outsourcing in a bank?
The most “practical” change is that the importance increases of:
managing ICT third-party risk as an ongoing process (not a one-off audit),
the supply chain (including subcontractors),
evidentiary requirements (policies, procedures, logs, reports, tests – proportionate to risk),
contracts and governance that enable real control (not just “nice wording”).
DORA strengthens the weight of these topics in the context of the operational resilience of the financial sector.
Step 0: classification – how “critical” is the service / cooperation?
Before you use the checklist, define the context:
Does what you are outsourcing (the ICT service) support a critical or important function?
If yes, the bank will usually expect a more stringent approach: more controls, more auditability, more transparency around subcontracting and a stronger exit plan.
How to think about this in staff augmentation / dedicated team?
Even if formally you are “providing people”, the risk is assessed through the impact of their work on the bank’s processes and systems (e.g. digital channels, integrations, core, payments, data, AML). In that case, the provider becomes part of the bank’s operational risk.
DORA checklist: requirements for an ICT provider (IT outsourcing for a bank)
Below you’ll find a checklist in a “RFP-friendly” layout. You can treat each point as:
a question to the provider,
an element of a scorecard,
a list of evidence for due diligence.
A) Due diligence (before signing the contract): minimum information and evidence
What a bank will typically check / ask about:
Does the provider have a documented approach to information security (policies, roles, training, reviews)?
What does risk management look like in the organisation (risk register, reviews, approvals)?
How is access managed (e.g. process for granting/revoking rights, periodic reviews, MFA – where applicable)?
How does the provider approach vulnerabilities and updates (Vulnerability/Patch Management – to the extent relevant to the service)?
Is there an incident management process (who escalates, how and in what time)?
Is there a business continuity (BCP/DR) approach and testing (if relevant to the scope of services)?
Practical note: some points (e.g. MDM, specific tools) are examples of good practices. A bank usually assesses “whether the control exists and is adequate”, not whether it is implemented in that one specific technology.
B) Cooperation governance: measurability and predictability of delivery
In outsourcing models, banks typically expect the provider to show:
what onboarding looks like (access, environments, ways of working),
how reporting works (cadence, format, statuses),
what escalation paths exist (operational and management),
how the work will be measured (KPI/SLA – adequate to the model and criticality).
This is critical especially when facing the objection “just another body leasing provider” – governance is what separates “supplying people” from “predictable delivery”.
C) Auditability and access to information
In IT outsourcing for a bank, it’s worth making sure you can answer the question:
“Does the bank have real access to the information and evidence it needs to control the provider risk?”
In practice, the bank may expect:
a definition of which information/evidence the provider shares as standard,
support in audit mode (e.g. Q&A, providing evidence),
a clear mode of cooperation in exceptional situations (e.g. an incident).
It’s not about “full visibility into everything”, but about adequacy to the risk and scope of the service.
D) ICT incidents: escalation, cooperation, data
In bank–provider relationships it is important that the provider has:
an incident management process and defined roles/responsibilities,
rules for escalation to the bank (when and how to notify),
a practice of RCA (root cause analysis) and corrective actions,
readiness to cooperate in information-sharing (data, timeline, impact).
This supports the bank in fulfilling its obligations related to incident management and reporting.
E) Subcontractors and the supply chain (subcontracting)
This is one of the most “sensitive” areas in banking.
What is worth having clearly defined:
whether the provider uses subcontractors and to what extent,
how the bank is informed about changes in the chain (notification / change control),
whether and how the bank can assess the risk of material subcontractors,
how the provider ensures that security obligations are “flowed down” along the chain.
European supervisory authorities have prepared technical standards on the sub-outsourcing of ICT services supporting critical/important functions; in practice, it’s worth considering them when assessing providers and drafting cooperation terms.
F) Business continuity (BCP/DR) and tests – proportionate to risk
A bank will typically ask:
whether the provider has BCP/DR (if relevant to the service),
how recovery (RTO/RPO – where applicable) is defined and tested,
what communication looks like in an emergency.
The key is adequacy to what you actually deliver (different for managed services, different for staff augmentation).
G) Exit plan: how to end the cooperation without lock-in and loss of knowledge
From the bank’s perspective, it is important that the provider has predefined:
rules for knowledge transfer (documentation, runbooks, onboarding of the successor),
support during the transition period (transition assistance),
a process for closing access and tidying up permissions.
This is not a “plan for a divorce” – it’s a standard in a regulated environment.
H) Register of information: data the bank may need from the provider
DORA is also linked to maintaining a register of information on contracts with ICT providers. Standardised templates for the register have been adopted in the Commission Implementing Regulation (EU) 2024/2956.
What practically helps the bank on the provider’s side:
consistent identification data (legal name, country, registration data),
a description of the service and scope,
locations of service provision/delivery (where applicable),
information on subcontracting (to the extent relevant),
contract data (duration, material operational terms).
RFP ready-made: 25 control questions for an IT provider (outsourcing in a bank)
The questions below are intentionally “operational” – they don’t assume that the provider is a DORA law firm. They are meant to check whether the cooperation will be controllable and auditable.
How do you describe the service scope and the boundaries of responsibility (RACI)?
What does governance look like: reporting, cadence, escalations?
What KPI/SLA do you use (examples) and how do you report them?
What does onboarding into a regulated environment look like (access, rules, client requirements)?
How do you manage access rights (granting/revoking, reviews) – within your organisation?
What is your approach to information security (policies/rules, training)?
What does your incident and escalation process towards the client look like?
How do RCA and corrective actions after an incident work?
How do you approach business continuity (BCP/DR) – where relevant to your service?
How often do you test emergency procedures (if applicable)?
Can you participate in the client’s incident exercises (to an agreed extent)?
How do you manage change (change management) for critical elements of the cooperation?
How do you manage documentation (architecture/runbooks/procedures) during the project?
How do you ensure team continuity (backup, substitution, knowledge transfer)?
Do you use subcontractors? If so, to what extent?
How do you inform about changes in subcontracting?
How can the client assess the risk of material subcontractors (to an agreed extent)?
How do you ensure that security requirements are maintained throughout the supply chain?
What does “auditability” look like: what evidence can you provide as standard?
Do you support client audits (to an agreed extent)?
What does communication look like in a crisis (channels, roles, reaction times)?
What does the exit plan and support in migration/knowledge transfer look like?
How do you close access and tidy up permissions after the end of the cooperation?
What information can you provide to the bank’s register of information?
What are your limitations (what you do not do / where you need client support)?
The most common pitfalls in IT outsourcing for a bank (and how to avoid them)
Lack of governance: the work “happens”, but without a cadence of reporting, escalation and metrics.
Subcontracting in the shadows: the bank learns about subcontractors too late (or not at all).
Incidents without clear information-sharing: no consistent timeline, no RCA, chaotic communication.
An exit plan in “two sentences”: no procedure for knowledge transfer and transition support.
Security statements that are too generic, without the ability to present evidence.
FAQ
Does DORA apply to IT outsourcing and staff augmentation in a bank?
DORA concerns the digital operational resilience of the financial sector and includes, among other things, the management of risk related to ICT services provided by third parties. In practice, banks also take DORA into account in outsourcing relationships, depending on the criticality of the service.
What is the “register of information” and what does it change for the provider?
It is a register of information about contracts and dependencies with ICT service providers. Standard templates have been adopted for the register, which makes it easier to structure data on relationships with providers.
Do subcontracting standards matter in the choice of provider?
Yes – European supervisory authorities publish technical standards on the sub-outsourcing of ICT services supporting critical/important functions, which in practice strengthens the importance of controlling the supply chain.
7) How Edge One Solutions can help
If you are considering outsourcing IT specialists or a dedicated team to work in a regulated environment, we can support you in the areas that are on our side: delivery, cooperation setup and the team’s working standards.
Dedicated Teams – we build and run dedicated project teams.
Staff Augmentation / IT specialists outsourcing – we provide specialists to the client’s teams, with a structured selection process and onboarding aligned with the organisation’s rules.
Our teams work in line with the agreed security rules and the client’s requirements (e.g. NDA/confidentiality, onboarding, access rules to environments, working in the client’s tools and processes). We do not provide legal advice or “DORA implementations” – however, we help you work in a cooperation model that is structured, measurable and easier to supervise on the bank’s side.
