DORA affects more than a bank’s internal processes. It also changes how financial institutions assess, contract and oversee ICT service providers.
DORA (Digital Operational Resilience Act) is an EU regulation on 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 relationships with external ICT service providers.
In practice, this increases the importance of governance, KPI/SLA, auditability, incident handling rules, subcontractor control, BCP/DR — where applicable — and exit planning.
Responsibility for compliance with DORA remains with the financial institution. However, an ICT provider should enable the bank to meet the relevant requirements within the scope of the service provided — through appropriate processes, information, evidence, reporting and cooperation structures.
This is why selecting an IT partner for a bank should not be limited to comparing rates and specialist availability. It also matters whether the cooperation is controllable, predictable and auditable.
This article is a practical checklist for Vendor Management, Procurement, IT, Security and PMO teams. You can use it in RFP/RFQ processes, due diligence, vendor reviews and when defining governance for cooperation with an ICT provider.
Important: this material is for informational purposes only. It is not legal advice or a regulatory interpretation. Final compliance assessments and contractual requirements should be verified by the financial institution’s legal and compliance teams.
TL;DR: what does a bank usually want to keep “under control” when outsourcing IT after DORA?
Regardless of the cooperation model — Staff Augmentation, Dedicated Team or Managed Services — a bank will usually want to have:
- a clearly defined service scope and responsibilities,
- governance — KPI/SLA, reporting and escalation paths,
- audit and information rights, together with access to relevant evidence,
- defined incident-handling and information-sharing rules,
- control over subcontracting and supply-chain changes,
- BCP/DR and testing appropriate to the criticality of the service,
- an exit plan that reduces vendor lock-in and knowledge-loss risk,
- consistent data for the register of information on ICT provider agreements.
This does not mean that the requirements should be identical for every provider. The scope of controls should reflect the type of service, the provider’s responsibility, access to systems and data, and the importance of the supported process.
What does DORA change in IT outsourcing for banks?
One of the most practical changes is that ICT provider risk management should be treated as a continuous process rather than a one-off verification before signing the contract.
The following areas become more important:
- ICT third-party risk management,
- supply-chain and subcontractor control,
- evidence requirements — policies, procedures, reports, logs or test results, depending on the service scope,
- contracts and governance that enable effective oversight of the relationship,
- ongoing provider monitoring during service delivery.
The bank therefore needs to know not only who it is selecting, but also how it will oversee the relationship after the contract is signed.
Due diligence answers the question: “can we start working together?”. Governance and vendor reviews help answer: “can we continue the relationship safely?”.
At the same time, the scope of controls should be proportionate to the risk and importance of the ICT service. A specialist joining the client’s existing team may require different controls than a provider responsible end-to-end for operating a critical service.
Step 0: classification – how “critical” is the ICT service or cooperation model?
Before applying a checklist to a provider, the bank should first define the context of the cooperation.
Does the ICT service support a critical or important function?
If it does, the bank may expect a more stringent approach: more controls, greater auditability, more transparency around subcontractors and a stronger exit plan.
There is another important principle: the cooperation model itself does not determine the level of risk.
What matters is the actual impact of the provider’s work on the bank’s systems, data and processes. A specialist working in a Staff Augmentation model may be involved in a digital channel, integration layer, payment system, data platform or AML process. Formally, the provider supplies expertise, but the work itself may still be relevant to the bank’s operational risk.
Staff Augmentation, Dedicated Team and Managed Services – why can the requirements differ?
| Model | Typical responsibility split | What may matter to the bank? |
|---|---|---|
| Staff Augmentation | Provider specialists join the client’s team and work within the client’s processes and tools. | Onboarding, access, offboarding, skills, continuity of specialists, security and adherence to the bank’s processes. |
| Dedicated Team | A dedicated team delivers a defined project scope and is integrated with the client’s organisation. | Team governance, responsibilities, reporting, delivery, documentation, knowledge transfer and replacement capability. |
| Managed Services | The provider may be responsible for a broader service scope and defined operational parameters. | SLA, monitoring, incidents, BCP/DR, operational responsibility, auditability, subcontracting and exit planning. |
This distinction also matters from a business perspective. Applying exactly the same requirements to every model can either underestimate risk or create controls that do not reflect the provider’s actual responsibilities.
You can find more examples of IT projects delivered for financial institutions on the Banking & Financial Services page.
DORA checklist: requirements for an ICT provider
The checklist below is operational in nature and can be used as a set of questions for an ICT provider, a scorecard element or a starting point for collecting evidence during due diligence and vendor reviews.
A) Due diligence – minimum information and evidence
The bank should verify, among other things:
- whether the provider has a documented approach to information security — policies, roles, training and reviews,
- how risk management is organised,
- how access is granted, changed, reviewed and revoked,
- how vulnerabilities and updates are managed, where relevant to the service,
- whether an incident-handling and escalation process exists,
- whether there is an appropriate BCP/DR and testing approach, where applicable to the service.
A provider declaration may not always be sufficient. Depending on the risk, the bank may need specific evidence that the relevant processes actually operate — for example policies, procedures, review results, reports, certificates or other agreed evidence.
Practical note: the objective should not be to verify whether the provider uses one particular tool or technology. What matters more is whether the relevant control exists, works and is proportionate to the risk.
B) Cooperation governance – measurable and predictable delivery
The provider should be able to explain:
- how onboarding works — access, environments, requirements and working rules,
- how reporting works — cadence, format and responsibilities,
- what the operational and management escalation paths are,
- how KPI/SLA are defined and measured, where applicable,
- how team continuity and replacement capability are ensured,
- who is responsible for each part of delivery.
Governance should reflect the cooperation model. In Staff Augmentation, more responsibility for backlog and delivery management may remain with the bank. In a Dedicated Team model, the provider’s responsibility for organising the team’s work may be broader. In Managed Services, service parameters, SLA, monitoring and operational responsibility become more important.
This governance layer helps distinguish simple “resource provision” from cooperation in which the bank has clearly defined responsibilities, information flows and a predictable service-delivery model.
C) Auditability and access to information
One of the fundamental questions is: does the bank have practical access to the information and evidence required to oversee provider risk?
In practice, it is worth defining:
- what information and evidence the provider can supply as standard,
- how audit requests are handled,
- who is responsible for collecting and providing evidence,
- how the provider supports audits or vendor reviews,
- how information sharing works in exceptional situations.
This does not mean that the bank should have unrestricted access to all internal provider information. The scope should reflect the risk, service type and agreed cooperation rules. However, it is useful to define the process before the first audit request arrives.
D) ICT incidents – escalation, cooperation and information
In a bank–ICT provider relationship, it is important that the provider has:
- an incident-handling process and defined roles and responsibilities,
- agreed escalation rules to the bank,
- a root cause analysis process,
- a corrective-action process,
- the ability to provide agreed information on the event, timeline and impact.
The provider’s role is to support efficient information exchange within the scope of its service. The bank’s formal regulatory obligations and reporting to competent authorities remain a separate matter.
E) Subcontractors and the supply chain
Subcontracting is particularly relevant where additional entities participate in delivering the service. From the bank’s perspective, transparency is key.
It is worth defining:
- whether the provider uses subcontractors and for which elements of the service,
- how the bank is informed about changes in the supply chain,
- whether the bank can assess the risk of relevant subcontractors within the agreed scope,
- how security and cooperation requirements are reflected further down the supply chain.
The bank should understand which entities actually participate in service delivery and in which parts of the service. The more critical the cooperation, the more important this transparency becomes.
F) Business continuity – BCP/DR and testing
Depending on the nature of the service, the bank may verify:
- whether the provider has appropriate BCP/DR arrangements,
- how RTO/RPO are defined and tested, where this falls within the provider’s responsibility,
- how communication and responsibility are organised during a disruption.
Proportionality is essential. In Staff Augmentation, the provider’s responsibility for BCP/DR of the entire system may be significantly lower than in Managed Services, where the provider is responsible for defined service parameters.
The requirement should therefore follow the actual responsibility scope rather than the generic label “IT outsourcing”.
G) Exit plan – how to end the relationship without lock-in or knowledge loss
An exit plan should not be created only when the contract is being terminated. The approach to ending the cooperation should be defined at the beginning.
It should cover, among other things:
- knowledge transfer,
- up-to-date documentation and runbooks,
- onboarding of the team taking over the service,
- transition assistance during the agreed period,
- closure of access rights, accounts, keys and tokens,
- organisation of information and responsibilities after the cooperation ends.
A good exit plan reduces two risks at the same time: vendor lock-in and loss of knowledge critical to the continued operation of the system.
H) Register of information
DORA also requires financial entities to maintain a register of information covering contractual arrangements with ICT service providers. Standard templates for this register are set out in Implementing Regulation (EU) 2024/2956.
From the provider’s perspective, it is useful to be able to provide consistent information on, among other things:
- entity identification data,
- description and scope of the service,
- service-delivery location, where applicable,
- relevant subcontracting information,
- basic contractual and operational information.
RFP-ready: 25 control questions for an ICT provider
The questions below are intentionally operational. They can be used in an RFP/RFQ, due diligence process or recurring vendor review. Their purpose is to verify whether the cooperation will be controllable, auditable and aligned with the organisation’s requirements.
- How do you define the service scope and responsibility boundaries (RACI)?
- How does governance work: reporting, cooperation cadence and escalation?
- Which KPI/SLA do you use and how are they reported?
- How does onboarding into a regulated environment work?
- How do you manage granting, changing, reviewing and revoking access?
- What is your approach to information security and training?
- How does your incident-handling and client-escalation process work?
- How do you perform RCA and corrective actions?
- What is your BCP/DR approach where relevant to the service scope?
- How often do you test relevant continuity procedures?
- Can you participate in the client’s incident exercises within an agreed scope?
- How do you manage changes affecting critical elements of the cooperation?
- How do you manage documentation, runbooks and project knowledge?
- How do you ensure team continuity, replacement capability and knowledge transfer?
- Do you use subcontractors? If so, for which parts of the service?
- How do you inform the client about subcontracting changes?
- How can the client assess the risk of relevant subcontractors?
- How do you ensure that agreed security requirements are maintained throughout the supply chain?
- What does auditability look like — which evidence can you provide as standard?
- How do you support client audits and vendor reviews?
- How does crisis communication work — channels, roles and response times?
- What does the exit plan look like, including migration support and knowledge transfer?
- How do you close access and clean up permissions after the cooperation ends?
- What information can you provide for the bank’s register of information?
- Where are the boundaries of your responsibility and where is action required from the client?
Common pitfalls in IT outsourcing for banks
| Pitfall | Consequence |
|---|---|
| No governance | Work is delivered, but the bank lacks a consistent reporting cadence, escalation model and measurable controls. |
| Hidden subcontracting | The bank learns too late which entities are actually involved in delivering the service. |
| Incident chaos | Unclear roles, no consistent event timeline, delayed escalation and weak RCA. |
| A two-line exit plan | Vendor lock-in, knowledge loss and costly service transition. |
| Declarations without evidence | The provider declares that processes and controls exist but is not prepared to provide the agreed evidence. |
| The same requirements for every model | Staff Augmentation is assessed like Managed Services or vice versa, so the controls no longer reflect the actual responsibility and risk. |
The common denominator is a mismatch between controls and the actual way the service is delivered. DORA increases the importance of formalising cooperation, but the number of procedures alone cannot replace a clear responsibility model and functioning processes.
How can Edge One Solutions support IT projects in regulated environments?
A bank needs more than technical expertise. It also needs a partner that can work within defined governance, respect the client’s security requirements and provide the information necessary to oversee the cooperation.
Edge One Solutions supports organisations in Banking & Financial Services, delivering technology projects in environments where security, process stability and structured cooperation matter.
Depending on the client’s needs, cooperation can be structured as Staff Augmentation or a Dedicated Team. :chatgpt-content-reference{index=”1″}
| STAFF AUGMENTATION Strengthen an existing team Edge1S specialists join the client’s team and work within its processes, tools, access rules and governance. | DEDICATED TEAM A dedicated project team The team is built around a defined scope and can be integrated with the organisation’s processes, security requirements and reporting model. |
In practice, this means working within an agreed onboarding model, access rules, NDA and confidentiality requirements, client processes and defined reporting and escalation structures. The scope of documentation, auditability and support during vendor reviews can be aligned with the nature of the cooperation and the organisation’s requirements.
One example of Edge1S experience in financial services is its cooperation with Bank Pekao on the development of digital banking solutions. :chatgpt-content-reference{index=”2″}
Edge One Solutions does not provide legal advice and is not responsible for a bank’s compliance with DORA. The role of a technology partner is to organise its part of the cooperation in a way that enables the bank to effectively manage the provider, associated risk and requirements relevant to the service.
Edge One Solutions
Need specialists or a dedicated IT team for a project in financial services?
Let’s discuss a cooperation model aligned with your governance, security requirements and responsibility scope — from Staff Augmentation to a Dedicated Team.
