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

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 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 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 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.

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, 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 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.