The Digital Operational Resilience Act, or DORA, is an EU regulation for the financial sector. It requires banks, insurers, investment firms and other financial entities to manage ICT risk in a structured way and to strengthen their ability to withstand, respond to and recover from ICT-related disruption.
DORA is also about how financial institutions work with ICT service providers. Contracts, service levels, responsibilities, documentation, incident handling and exit options all become part of operational resilience. For backup and recovery, this matters directly. A bank needs more than a backup policy on paper. It needs a resilient backup solution, clear recovery processes and service agreements that support its operational requirements.
During an incident, the question becomes much simpler: can the institution restore the data and systems it needs, within the required time?
Backup is not the final goal. Recovery is.
This article looks at what banks and other financial institutions should consider when organizing backup and recovery under DORA, including sensitive data, RTO and RPO targets, restore testing, documentation, outsourcing aspects, SLA-related questions and the role of a resilient backup solution.
Data must stay available, correct and recoverable
Banks work with data that is sensitive, business-critical, or both. Customer data. Account information. Payment data. Transaction records. Reporting data. Internal documents. System data.
If this data is lost, encrypted, corrupted or unavailable, the impact does not stay inside IT. It can affect customer access, payment processes, regulatory reporting, internal operations and trust.
A successful backup job is only one part of the process. The real test comes later.
Can the data be restored?
Can the right system be restored first?
Can the team prove that the process works?
That is where backup quality becomes visible.
Recovery time is not one number
Not every banking system has the same recovery priority. A payment-related service, a customer-facing application, an archive and a test system do not have the same role in daily operations.
This is why recovery objectives need to be defined per system, service or data category.
RTO defines how quickly a system should be restored. RPO defines how much data loss can be accepted. These values should fit the real backup architecture, the storage design, the restore workflow and the available team.
A simple example.
A critical system has a short RTO, but the restore process is manual, slow and rarely tested. On paper, the target looks fine. In practice, it is fragile.
What makes backup and recovery resilient?
A resilient backup process is more than a list of scheduled jobs.
It includes clear decisions about what is protected, how often backups are created, where backup data is stored, who can access it and how restore is tested.
Several points matter in practice:
- backup systems should be separated from production where possible and air-gapped where appropriate
- restore procedures should be tested regularly
- backup storage should match the risk profile
- failed jobs and warnings should be monitored
- reports and logs should be available for review
- responsibilities should be clear
No owner, no process.
This sounds simple, but it is often where backup strategies become weak. The technology may work, but nobody reviews failed jobs. Restore tests exist, but only for non-critical systems. Storage is available, but not separated enough from production.
What procurement teams should check
For banks, choosing a backup and recovery solution is not only a technical decision. Procurement, ICT risk, compliance, security and operations may all be involved.
A useful evaluation should cover both the product and the operating model around it.
Important questions include:
- Which systems, platforms and workloads are supported?
- Are physical servers, virtual machines and databases covered?
- How are restore procedures handled?
- Can restore tests be documented?
- What reports and logs are available?
- Can backup storage be separated from production?
- How are encryption, access control and secure communication handled?
- What support model is available for production use?
- Does the solution create strong vendor lock-in?
- Can backup data still be restored if the organization later changes backup software?
- How much effort would be needed to move to another backup solution?
- Can it fit into existing ICT risk and outsourcing processes?
These questions help avoid a common problem: buying a backup tool that looks acceptable during procurement, but becomes hard to operate, test or document later..
Where Bareos can support banks
Bareos can support DORA-related backup and recovery processes as a flexible open-source backup platform for heterogeneous IT environments.
Many banks do not run one clean, uniform infrastructure. They run a mix of systems: Linux, Windows, virtual machines, databases, storage systems and older components that still matter. A backup solution should work with this reality.
Bareos supports physical systems, virtual environments, databases and different storage targets. It can be used with disk, tape and object storage. This gives organizations room to design backup strategies that fit their infrastructure, recovery priorities and retention needs.
For procurement teams, Bareos is also relevant because it combines open-source software with subscription-based access to maintained packages, enterprise plugins and professional support. This can be important in production environments where technical control, maintainability, documentation and support all matter.
With clear responsibilities, service levels, documentation and regular restore testing, a Bareos-based backup and recovery process can support the bank’s compliance with DORA and internal ICT risk requirements.
Bareos does not replace DORA governance, ICT risk management, outsourcing management or internal procedures. These responsibilities remain with the financial entity.
But Bareos can provide the technical backup and recovery layer that supports documented, tested and controlled recovery processes.
Avoiding lock-in in backup architecture
Backup data is long-living data. It may need to be kept for years. It may also be needed at the worst possible moment.
This is why vendor lock-in is an important topic in backup procurement. If backup data, restore workflows or storage choices depend too strongly on one closed environment, future changes become harder.
Bareos follows an open-source approach and gives organizations control over their backup infrastructure and backup data. If a bank changes its subscription, support model or backup strategy, the data does not become locked inside a closed vendor platform. Existing backups remain under the organization’s control and can still be restored with Bareos.
This gives banks more flexibility when planning long-term recovery, changing service arrangements or avoiding dependency on one proprietary provider.
Conclusion
Under DORA, backup and recovery should be treated as part of digital operational resilience.
For banks, the central questions are practical:
Can critical data be restored?
Are recovery targets realistic?
Are restore procedures tested?
Is evidence available?
Is the backup architecture flexible enough for future needs?
A resilient backup and recovery process depends on technology but also on ownership, documentation and regular testing.
Bareos can support this work with an open-source backup and recovery platform for mixed IT environments, flexible storage targets and professional support options for production use.
Backup protects data.
Recovery protects operations.