---
title: "DORA Article 12 Support with Bacula Enterprise"
published_at: "2026-11-06T09:06:22+00:00"
modified_at: "2026-11-06T11:49:34+00:00"
url: "https://www.baculasystems.com/compliance/dora/"
markdown_url: "https://www.baculasystems.com/compliance/dora.md"
---

[Home](https://www.baculasystems.com/)
 > [Enterprise Backup Solutions](https://www.baculasystems.com/enterprise-backup-solutions/)
 > DORA Article 12 Support with Bacula Enterprise

# DORA Article 12 Compliance: A Backup and Recovery Guide for Financial Entities

DORA is an [EU law](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)
 that took effect in January 2025, designed to keep banks, insurers, investment firms, and other financial companies running when their IT systems fail or are compromised. **Complying with DORA Article 12, the law’s backup and recovery section** requires you to document what data you back up and how often, record how you restore it, test those procedures regularly, and restore to systems kept physically and logically separate from production.

Bacula Enterprise is a cyber-resilient backup and recovery platform that supports DORA Article 12 compliance by providing the required technical controls. These include policy-based backup schedules, encrypted and immutable backup copies, integrity checks, and recovery from isolated tape or disconnected storage.

[https://www.baculasystems.com/wp-content/uploads/2026/11/Bacula-DORA-Backup-and-Recovery.png](https://www.baculasystems.com/wp-content/uploads/2026/11/Bacula-DORA-Backup-and-Recovery.png)

## DORA Article 12 Requirements

Article 12 of the [Digital Operational Resilience Act](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en)
 тcovers backup policies, restoration procedures, along with recovery methods. Its requirements give financial entities a way to restore their ICT systems and data with minimum downtime, disruption, and data loss after an outage or a cyberattack.

### Article 12(1)(a): Backup Scope and Minimum Backup Frequency

Under **Article 12(1)(a),** financial entities must write and maintain a backup policy that lists which data they back up and how often each category of data must be backed up at minimum. They must base the scope and frequency on how critical or confidential the data is.

Because data carries different risk levels, the rule ensures your most important data gets the most frequent protection. To comply with this clause, classify your data by criticality; for example, mark customer account records as critical, HR files as important, and old project documents as low priority. Then set a minimum frequency for each class, and record your reasoning in the policy. A payments ledger might need hourly backups, while an archive of marketing files can run weekly.

### Article 12(1)(b): Documented Restoration and Recovery Procedures

In addition to the backup policy in clause (a), **Article 12(1)(b)**covers the recovery aspect of data protection. It requires financial entities to keep written restoration and recovery procedures that tell staff which backup to use, where to restore it, and the order in which systems come back online. Because staff can’t afford to improvise during a crisis, a written plan helps them restore services quickly and reduces recovery time. Make sure to keep those documents reachable even when your main systems are down.

### Article 12(2): Secure Activation of Backup Systems

A careless restore can pull malware back into production or leave customer data sitting on an unprotected server. **Article 12(2)** guards against this risk by setting two conditions for your backup systems. First, you must be able to switch them on the way your backup policy describes. Second, switching them on can’t weaken your network security or put your data at risk of being lost, altered, faked, or exposed. To comply with this article, encrypt your backups, limit who can run restores and where restored data can go, and scan restored data for malware before it returns to production.

### Article 12(2): Periodic Backup and Recovery Testing

**Article 12(2)**also requires periodic testing of your backup, restoration, and recovery procedures. Untested backups often fail at the worst possible moment, and the only proof recovery works is restoring the data to a separate test system and confirming the application starts, the data is complete, and the restore finishes within your recovery time target. Use [cyber-resilient backup and recovery software](https://www.baculasystems.com/)
 to restore real data into a test environment on a regular schedule, and confirm that the systems run. Don’t forget to keep a record of the results and of any problems you fix, because DORA’s technical standards require documented test results.

### Article 12(3): Physically and Logically Segregated Restore Systems

When financial entities restore backups on their own systems, **Article 12(3) obliges** them to use systems that are physically and logically separated from production and protected from unauthorized access. The rule keeps an attacker, even one who has already broken into production, from reaching your recovery environment. [EIOPA](https://www.eiopa.europa.eu/qa-regulation/questions-and-answers-database/dora038-2991_en)
 interprets it as systems under your full control that are not directly connected to the main system. **To comply, build your recovery environment on separate infrastructure with its own network separation and access controls.**Your backup software must then restore from isolated copies, and [Bacula Enterprise](https://www.baculasystems.com/)
 can recover critical systems from offline tape or disconnected storage on infrastructure you control.

### Articles 12(6) and 12(7): Recovery Objectives and Integrity Checks

**Article 12(6)** mandates recovery time and recovery point objectives (RTOs and RPOs) for each function, and **Article 12(7)** adds integrity checks and reconciliations after you recover from an incident. These rules set how fast you must recover, how much data you can afford to lose, and how you confirm that restored data is correct. **In order to comply with Articles 12(6) and 12(7), set an RTO and an RPO for every critical or important function, and schedule backups at least as often as each RPO allows.**

A one-hour RPO requires at least hourly backups, while a 24-hour RPO can rely on a nightly backup. Before going live, reconcile restored data against your other systems. The rest of Article 12 adds redundant ICT capacity for all but the smallest firms and extra rules for central securities depositories, central counterparties, and data reporting service providers.

## Other DORA Backup and Recovery Rules (Beyond Article 12)

A couple of extra backup and recovery rules sit outside **Article 12** that you should also comply with, and auditors will cite them by number. It’s good practice to keep them separate from Article 12 to help you match each piece of evidence to the right provision.

### Articles 11(6) and 11(8): Annual Recovery Testing and Activity Records

**Article 11(6)**addresses a testing-frequency requirement that Article 12 missed. Financial entities must test their ICT business continuity plans and ICT response and recovery plans **at least once** **a year,** and whenever they make a major change to systems supporting critical or important functions.

Unless you’re a microenterprise (under 10 staff and no more than €2 million in turnover or balance sheet), those tests need a cyberattack scenario and an actual switchover to your backups. Put simply, Article 11 has you show, once a year, that you can fall back on them in case of a breach or crash. And when you do activate those plans, Article 11(8) wants readily accessible records of what your team did before and during the disruption.

### Delegated Regulation 2024/1774: Switchover Testing, Plan Access, and Key Management

Per DORA’s technical standards ([Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng)
), Article 25, a switchover test passes only if your critical or important functions keep running for a sufficient period and normal operations resume afterward. Document the results and record any problems that occur. Then fix those problems and report them to your board or equivalent leadership.

Another noteworthy article is **Article 26**, which requires your staff to be suitably enabled to follow your recovery plans, with documented plans to be available to the staff executing them and readily accessible during emergencies.

Then there’s **Article 7**, which requires you to plan for backing up and replacing your encryption keys, because you can’t restore encrypted backups without them.

### DORA Article 16: Simplified Framework for Smaller Entities

Per **DORA Article 16**, some smaller firms don’t have to follow Article 12 at all. That group includes small investment firms, exempted payment and e-money institutions, and small pension funds. That said, these firms must still back up their data and test their restores. In fact, their testing rules are more specific on timing.

**Under Article 40**of the delegated regulation, they must test backups and restores at least once a year, or whenever they make a major change to their continuity plan. Article 12, on the other hand, only says ‘periodically’.

## How Bacula helps with DORA Article 12 compliance

Bacula Enterprise is a cyber-resilient backup and recovery platform, trusted by [NASA](https://www.baculasystems.com/customers/success-stories/nasa-chooses-bacula-enterprise-to-back-up-ibm-hpss/)
, the [US Air Force, and the US Navy](https://www.baculasystems.com/data-backup-and-recovery-in-defense-and-military-organizations/)
. It equips you with all the necessary tools to tackle DORA Article 12 requirements. Here’s how it can help you comply with the following clause.

| DORA Article | Requirement | Bacula feature | Your job |
| --- | --- | --- | --- |
| 12(1)(a) | Backup scope and frequency | Jobs, Filesets, Schedules | Classify data |
| 12(1)(b) | Written recovery procedures | Catalog, bootstrap, bare-metal recovery | Write the runbook |
| 12(2) | Secure activation | Encryption, MFA, access control | Guard the keys |
| 12(2) | Protected backup copies | Immutable storage | Align retention |
| 12(2), 11(6) | Regular testing | Restore jobs, Recovery Independence Test | Set success criteria |
| 12(3) | Segregated restore systems | Bacula Independent Recovery | Build the recovery site |
| 12(7) | Integrity checks | Verify Jobs | Reconcile data |

### Article 12(1)(a) : Jobs, Filesets, and Schedules for Backup Policy

Article 12(1)(a) requires you to write a backup policy that lists which data you back up and how often, based on how critical that data is. Bacula lets you enter those same two decisions straight into the software.

You can list the servers, databases, and folders to back up in a setting called a [Fileset](https://docs.baculasystems.com/BETechnicalReference/Director/DirectorResourceTypes/FilesetResource/index.html)
, and you set how often to back them up in a setting called a **Schedule**, for example, every hour for payment records and once a day for email. Bacula then runs every backup automatically on that schedule and logs each run in a **Job report,** which gives you written proof that your actual backups follow your policy.

### Article 12(1)(b): Recovery Procedures with Catalog, Bootstrap, and Bare-Metal Recovery

Article 12(1)(b) requires written step-by-step procedures for restoring your systems and data after an outage. Bacula gives you three tools to carry out those procedures: **the catalog, bootstrap files, and bare-metal recovery.**

- First, the Catalog is a database that records what was backed up and where each copy is stored, and Bacula recommends backing it up daily.
- The second tool is bootstrap files, which tell Bacula exactly where each backup sits and let you rebuild the Catalog if the backup server itself is lost.
- Lastly, you get bare-metal recovery for Linux and Windows, which rebuilds a failed server from scratch, including its operating system, settings, and data.

### Article 12(2): Encryption and Access Control for Secure Restores

Article 12(2) requires that switching on your backups doesn’t put your systems at risk or expose, change, or corrupt your data. To help you comply with this clause, Bacula **encrypts backup data**in transit and at rest, keeping it unreadable to anyone without your encryption keys.

It also controls who can run a restore and where the restored data can go, using your existing **Active Directory** or **LDAP** accounts, two-factor login, and role-based permissions. During backup and restore, Bacula can check files against known malware signatures, helping prevent an infected file from returning to production. That said, backing up and protecting the encryption keys stays your job under Article 7 of the delegated regulation.

### Article 12(2): Immutable Storage for Backup Copies

Article 12(2) also requires that your backup data stays available and unaltered when you need to restore it. Bacula can write backups to immutable storage, where your saved backups can’t be changed or deleted ( until a protection period you set runs out).

Bacula supports immutable storage on Linux disk volumes, on NAS systems such as NetApp SnapLock and Data Domain Retention Lock, on WORM tape, and in the cloud through Amazon S3 Object Lock and Azure Blob immutable storage. Immutable storage can still connect to your network, though, and it doesn’t replace the separate restore systems Article 12(3) requires.

### Articles 12(2) and 11(6): Recovery Independence Test for Restore Testing

Articles 12(2) and 11(6) each call for real recovery tests, and Bacula’s documentation treats testing as part of the recovery plan. With Independent Recovery, the Recovery Independence Test checks that agreed critical systems can come back using only your own infrastructure, staff, credentials, and isolated backups, with no help from Bacula. You set the scope and success criteria. The results, timings, and fixes then become the records Article 25 of the delegated regulation asks you to report.

### Article 12(3): Bacula Independent Recovery for Segregated Restoration

When you restore on your own systems, Article 12(3) requires those systems to be physically and logically separate from production and protected from unauthorized access. [Bacula Independent Recovery](https://www.baculasystems.com/bacula-independent-recovery/)
 restores critical systems from offline copies on tape, removable media, or disconnected storage. It can run entirely on your own infrastructure with no connection to Bacula or any vendor service, which lines up with EIOPA’s reading of the rule. Moreover, you get a sealed Recovery Independence Kit that holds the software, settings, encryption keys, and instructions needed to rebuild from scratch.

### Article 12(7): Verify Jobs for Integrity Checks

Article 12(7) requires you to check that your data is complete and correct after recovering from an incident, including reconciling it against your other systems. A Bacula Verify Job reads backup data back from storage and confirms that it’s intact and matches Bacula’s records of what was saved.

It can also compare files on a server against an earlier backup and flag any that changed unexpectedly; importantly, these reports help during audits. Adding to this, please note that a Verify Job doesn’t confirm that an application runs or that balances reconcile, and your teams still have to run those checks themselves.

## DORA Article 12 FAQ

### What is DORA Article 12?

DORA Article 12 is the backup and recovery section of the EU’s Digital Operational Resilience Act. It tells banks, insurers, investment firms, and other financial entities how to back up their data, restore it, and prove the restore works. It has been in effect since 17 January 2025.

### What backup requirements does DORA Article 12 set?

Article 12 sets five core requirements. Financial entities must keep a written backup policy that defines data scope and minimum frequency by criticality, document restore procedures, activate backups without compromising security, test those procedures periodically, and restore to systems kept separate from production. Articles 12(6) and 12(7) add recovery time and point objectives and integrity checks after an incident.

### Does DORA require a physically and logically segregated recovery system?

Yes, when you restore backup data on your own systems. Article 12(3) requires those systems to be physically and logically separate from the source system and protected from unauthorized access. [EIOPA reads this](https://www.eiopa.europa.eu/qa-regulation/questions-and-answers-database/dora038-2991_en)
 as systems under your full control that aren’t directly connected to production.

### Does DORA require all backups to be air-gapped?

No. Neither DORA nor its technical standards use the term ‘air gap’. Article 12(3) requires separate restore systems, and EIOPA’s reading only rules out a direct connection to production. Many firms still keep copies on offline tape or removable media because a network attacker can’t reach them, but that’s a design choice and not a legal requirement.

### How often must backups and recovery procedures be tested?

It depends on your firm and the rule. Article 12 only says ‘periodically’, but Article 11(6) requires testing recovery plans at least once a year and after major system changes, including a switchover to backups, except for microenterprises. Smaller firms under the simplified framework must test backup and restore at least yearly under [Article 40 of Delegated Regulation 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng)
.

### Does Bacula make an organization DORA-compliant?

No. DORA puts the legal obligation on the financial entity, and compliance depends on your own policies, tests, and records. Bacula Enterprise supplies the technical controls behind several Article 12 requirements, from scheduled backups and encryption to immutable storage, Verify Jobs, and recovery from isolated copies.