Article 12 DORA backup and restoration requirements

What DORA Article 12 asks for backup and restoration

A DORA-regulated entity needs more than backups that run on schedule. Article 12 expects documented backup policies, restoration and recovery procedures, and evidence that both work when they are needed. The common failure is a backup job that reports success for months while nobody has ever restored a database, a file share or a configuration set from it. When an incident hits, the first real restore turns into the test, and the supervisor's question becomes why the entity did not know sooner. Compliance leads should treat restore success as the measure, not job completion.

Article 12(1) asks for a documented policy that sets two things: which data is backed up, and how often, with frequency tied to how critical or confidential that data is. Scope is hard because ICT-supported functions depend on data held in many places, including SaaS platforms, configuration stores and endpoints, and the asset inventory from Article 8 has to show where it lives. Article 12(1) also requires written restoration and recovery procedures and methods, so the policy and the runbooks must agree on the same systems and owners. Article 12(2) asks that backup systems can be activated without jeopardising security or data integrity, and that backup and restoration procedures are tested periodically. Article 12(6) and 12(7) add recovery time and recovery point objectives set per function, with attention to whether the function is critical or important, plus checks and reconciliations during recovery to protect data integrity. Confirm with your supervisor and your own risk assessment how often periodic testing must run, because the simplified regime sets its own annual expectation under Article 40 of Delegated Regulation (EU) 2024/1774, which is summarized in the Delegated Regulation 2024/1774 text.

Which systems, data and entities fall under Article 12 backup scope

Article 12 backup scope is set by a handful of decisions: which systems and data sets are backed up, how often, which functions carry the tightest recovery objectives, and whether the entity qualifies for lighter treatment. Each card below covers one of those decisions and what an assessor will ask to see behind it.

Data sets and ICT systems in scope

Start from the information and ICT assets your business functions depend on, not from the servers that happen to run backup jobs. Record which data sets, configurations, databases and identity stores are included, and which are excluded with a reason. An exclusion without a documented rationale is the gap assessors look for first. Confirm that the scope matches the asset inventory maintained under Article 8.

Frequency set by criticality

Article 12(1) ties the minimum backup frequency to the criticality or confidentiality of the data. A payments ledger and a internal reporting archive should not share one schedule by default. Document the rule that maps each data class to a frequency, the retention it implies, and who approved the mapping. Check that the actual Bareos or restic schedules match the documented rule.

Critical and important functions

The recovery time and recovery point objectives under Article 12(6) are set per function, with attention to whether the function is critical or important. Map each function to the systems and data it needs, then to the backup sets that protect them. A function with no mapped backup set has no recovery objective in practice. Ask who owns the mapping and how often it is reviewed.

Redundant capacity and secondary sites

Article 12(4) expects entities other than microenterprises to keep redundant ICT capacity adequate for business needs, and Article 12(5) requires central securities depositories to keep a secondary processing site at a geographical distance from the primary. Confirm which capacity is redundant, where the second site sits, and how its capacity is sized against the recovery objectives for each critical function.

Simplified regime and microenterprises

Microenterprises assess the need for redundant capacity against their own risk profile rather than meeting the blanket expectation. Entities under the simplified regime must still test backup and restore procedures at least once every year or upon every major change to the plan, under Article 40 of Delegated Regulation (EU) 2024/1774. Record which regime applies and the reasoning, since supervisors will ask.

Third-party hosted backups

Backups held by a cloud provider or managed service remain the entity's obligation. Under Article 12, the entity must still show scope, frequency, restore tests and integrity checks for that copy, and must confirm that the provider supports the recovery objectives agreed internally. Ask the provider for evidence of restore testing, segregation and retention, and record that evidence in the register of ICT third-party arrangements.

How a supervisor or auditor tests backup and restoration

This table sets out how a supervisor or independent auditor typically tests each limb of Article 12, the evidence they ask for, and the findings that most often appear. Read each row as a test step: the left column names the limb, and the other columns show what the reviewer checks and where weak programmes fail.

Test area	What the reviewer checks	Evidence requested and common findings
Documented backup policy review	Whether a written backup policy and restoration and recovery procedures exist, are approved by the right owner, and name the data scope and minimum frequency for each category of data.	Approved policy, procedure documents and version history. Common finding: policy describes backups in general terms with no link to data criticality or confidentiality.
Frequency and scope against criticality	Whether backup scope and minimum frequency follow the criticality or confidentiality classification of each data set, and whether the classification itself is current.	Data classification register, backup job schedules and scope definitions. Common finding: critical data sets missing from job scope, or schedules that do not match the classification.
Restore test sampling	Whether restore tests are performed on a defined schedule, cover a sample of systems and data sets, and succeed on the entity's own recovery procedure rather than on a vendor demonstration.	Restore test plans, results, timestamps and sign-off. Common finding: backups reported as successful by the tool but no restore ever attempted, or tests that cover only a single file.
Segregation of restore environments	Where backup data is restored into the entity's own ICT systems, whether those systems are physically and logically separated from the source system and protected from unauthorised access or corruption.	Network diagrams, access control lists for restore hosts, and evidence that backup repositories are isolated. Common finding: restore environment shares credentials or network segments with production.
Recovery objective traceability	Whether recovery time and recovery point objectives are set for each function, consider whether the function is critical or important, and link back to restore test results.	Documented RTO and RPO per function, mapped to restore test outcomes. Common finding: objectives missing for some functions, or set without evidence that restores meet them.
Reconciliation and integrity after recovery	Whether checks and reconciliations run after restoration to confirm data integrity, including verification of stored backup data and comparison with expected records.	Post-restore reconciliation records, integrity check logs and exception handling. Common finding: restored data accepted without reconciliation or integrity verification.

Why a backup that never restored is a DORA finding

A successful backup job is weak evidence under Article 12. Article 12(2) requires periodic testing of the backup procedures and of the restoration and recovery procedures and methods. The two are tested separately for a reason. A backup job can report success while writing files that are incomplete, unreadable, or missing the configuration, keys and dependencies needed to bring a service back. An assessor who asks to see a restore will ask which data was restored, into which environment, how long it took, and whether the result matched the production state. A job log answers none of those questions. Entities should keep dated test records that name the scenario, the data set, the restore target, the people involved and the measured outcome, and should confirm with their own supervisor how often the tests are expected to run for their entity type.

A restore environment that is not segregated can reintroduce the fault it was meant to fix. Article 12(3) requires that when backup data is restored using the entity's own systems, those systems are physically and logically segregated from the source system and protected from unauthorised access or corruption. In practice, the risk comes from restoring a backup of a compromised or corrupted database onto a host that still reaches production shares, service accounts or the same credentials. Malware or bad data can then travel back with the restore. The control to check is whether the restore network, identities and storage are separate from production, and whether the backup repository itself is protected from modification by a production account. Teams should test this boundary, not assume it from the architecture diagram.

Recovery without integrity checks leaves data that looks restored but is inconsistent. Article 12(6) and (7) require recovery point and recovery time objectives set per function, and checks and reconciliations during recovery to maintain the highest level of data integrity. A restored database can open cleanly while missing transactions written after the snapshot, or it can hold records that no longer match a downstream ledger. Before a restore is accepted, the team should define which reconciliations apply to each critical function, who signs off the result, and what happens when a mismatch appears. Tools can help verify the stored backup itself. For example, the restic check command with --read-data reads pack files back to confirm the stored data is unmodified, but it does not replace business-level reconciliation after recovery. Confirm what each tool verifies before relying on it as evidence.

How to implement Article 12 backup and recovery step by step

This sequence turns Article 12 into working backup, restoration and recovery arrangements, each step producing a document or record that an assessor can trace back to a critical function. The order matters because scope, frequency and recovery targets all depend on how the entity first classifies its data and functions.

Classify data and functions by criticality
Start by listing the ICT-supported business functions and the data each one depends on, then rate each function as critical or important and each data set by its criticality or confidentiality. The owner of each function signs off the rating, and risk or continuity staff check that it matches the business impact analysis. The output is a classified register that every later step references, so a gap here carries forward into backup scope, frequency and recovery targets.
Set backup scope and minimum frequency
For each classified data set, define what is backed up, including systems, databases, configurations and any data held by third-party services, and set a minimum backup frequency that reflects its criticality or confidentiality. Record exclusions with a reason, because an assessor will ask why a critical data set is absent. The output is a backup scope matrix that maps each data set to its frequency, retention and storage location.
Document backup and restoration procedures
Write the backup and restoration procedures as runbooks that name the tool, the job definitions, the credentials custody model, the restore steps and the person authorized to start a restore. Where open-source tools such as Bareos or restic are used, the runbook should show how the Director schedules jobs and how snapshots are selected for restore. The output is approved, version-controlled procedures that the management body or delegated owner has reviewed.
Set recovery time and recovery point objectives per function
Set a recovery time objective and a recovery point objective for each function, taking into account whether the function is critical or important. Confirm each target against what the backup frequency and restore process can actually achieve, and flag any mismatch for remediation or a change to the target. The output is a signed table of objectives per function, with the evidence that the restore process can meet them.
Build segregated restore capacity
Provision restore environments that are physically and logically separated from the source systems and protected from unauthorized access or corruption, with capacity sized for the functions that depend on them. Where the entity relies on a secondary site or redundant capacity, document how that capacity is kept in step with production and how it is activated without weakening security or data integrity. The output is an architecture record showing segregation boundaries, access controls and sized capacity.
Schedule and record restore tests
Schedule periodic tests of both the backup procedures and the restoration and recovery procedures, covering a sample of critical functions and at least one full restore path. Run the tests in the segregated environment, time them against the recovery objectives, and record the operator, date, result and any deviation. Under the simplified regime, Article 40 of Delegated Regulation (EU) 2024/1774 sets a yearly test or a test after every major change to the plan, so confirm your obligation before setting the cadence. The output is a test log with findings tracked to closure.
Define post-recovery integrity reconciliations
After any restore, define the checks and reconciliations that confirm the recovered data is complete and unmodified, such as record counts, transaction reconciliations and integrity verification of backup packs. For tools that support it, such as restic check with read-data options, include a data read-back that confirms stored backup data has not changed. The output is a documented post-recovery checklist, with sign-off recorded before recovered systems return to production.

Evidence that passes an Article 12 review

An assessor testing Article 12 starts with paper and then checks whether the systems behave the way the paper says. The cards below cover the artifacts that connect backup policy to real job records, restore tests and recovery reconciliations, and the habits that keep each one current between reviews.

Backup policy and restoration procedures

This is the documented policy that sets the data in scope, the minimum backup frequency and the restoration and recovery methods Article 12(1) requires. Keep it under version control with an owner, an approval date and a review trigger tied to major system changes. Check that each procedure names the systems, credentials and steps a second engineer could follow during an outage without the original author present.

Criticality mapping that sets frequency

The frequency in the policy must follow from how critical or confidential each data set is, so the mapping is the justification an assessor reads first. Record each function, its data stores, its criticality classification and the backup interval assigned to it. Revisit the mapping whenever a function changes classification or a new system takes over its data.

Job schedules and catalog reports

Scheduler configuration and catalog output show that backups ran as designed. In Bareos, the Director schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, so exported job history and catalog queries are the evidence to retain. Export them on a fixed cadence and check for failed, skipped or partial jobs that were never remediated.

Restore test records

Article 12(2) requires periodic testing of backup and restoration procedures, so the assessor expects dated records showing what was restored, from which backup, by whom and with what outcome. Each record should state the time taken against the recovery objectives and list any failed step with its fix. A backup that has never been restored is not evidence of recovery.

Segregated restore environment configuration

Where restores run on the entity's own systems, Article 12(3) requires those systems to be physically and logically segregated from the source and protected from unauthorized access or corruption. Keep network diagrams, firewall rules, separate credentials and access lists for the restore environment. Confirm that the backup server and its repository cannot be reached or altered with production administrator credentials.

RTO and RPO register

Article 12(6) requires recovery time and recovery point objectives set per function, with regard to whether the function is critical or important. The register should hold each function's objectives, the measured results from restore tests and the gap between them. Any function whose measured results exceed its objective needs a dated corrective action that the assessor can trace.

Post-recovery reconciliation logs

Article 12(7) requires checks and reconciliations during recovery to keep data integrity at the highest level. Logs should record the checksum or consistency verification run after restore, the record counts or transaction reconciliations compared against the source, and any discrepancies with their resolution. For tooling, restic's check command can verify structural consistency and, with --read-data or --read-data-subset, read pack files back to confirm stored data is unmodified, and those outputs belong in the log.

What meeting Article 12 costs in money and effort

This table breaks down the cost components of meeting Article 12, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Use it to scope a written quote and to see where self-hosted open-source tooling removes licence spend, while labour and infrastructure remain.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Backup storage and infrastructure	Cloud provider, data center operator or hardware vendor	Both: hardware or setup is one-time, capacity is recurring	Data volume, retention periods, backup frequency and the number of critical functions in scope
Backup software licences	Commercial vendor, or no licence fee for open-source tools such as Bareos (AGPL-3.0-only) and restic (BSD-2-Clause)	Recurring for commercial products, typically none for the open-source option	Choice of platform; open-source removes licence spend but not the engineering effort to run it
Redundant ICT capacity	Internal platform team or infrastructure provider	Recurring, because standby capacity runs continuously	Business needs for each critical or important function and the sizing that Article 12(4) expects for non-microenterprises
Segregated restore environments	Internal platform team or the cloud or data center provider hosting the isolated network	Setup is one-time; running the environment is recurring	Number of systems restored in isolation, network segmentation work, and how often restores are rehearsed
Secondary processing site (central securities depositories)	Site operator, colocation provider or internal facilities team	Largely recurring, with one-time build and data replication setup	Geographic distance requirement under Article 12(5), replication bandwidth and the size of the dataset
Engineering time for procedures and restore tests	Internal staff, or an implementation partner under a fixed-scope written agreement	Initial documentation is one-time; periodic testing is recurring	Number of procedures, the restore testing frequency required by Article 12(2) and by the simplified regime, and the amount of automation
Evidence upkeep	Internal compliance and operations staff	Recurring, tied to each test cycle and each major change	Logging depth, how records of tests and integrity checks are kept, and how often recovery plans change
External review or testing	Independent auditor or assessor, and any third-party tester the entity engages	Usually recurring, tied to the audit or review cycle	Scope of the review, number of critical functions and the findings from previous reviews. DeployOpen prepares evidence but does not issue audit reports
Quote contents to request	Implementation partner or vendor	Separate one-time and recurring lines in every quote	Ask for itemized scope, assumed data volumes, named deliverables, test frequency, and which items are the client's own cost

How Bareos and restic support Article 12 evidence

Bareos is a self-hosted backup system built around a central Director. The Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog that records the files held in each backup. That catalog is what lets an operator restore files selected from the current backup or from a backup taken before a given date and time, which maps directly to the recovery point discussion in Article 12(6) and (7). For evidence, the job logs, catalog entries and verify job results show that backups ran on the schedule the entity defined and that the catalog reflects what was stored. Bareos is licensed under AGPL-3.0-only, so an entity that modifies it and offers it to users over a network should take licensing advice before deployment.

Scheduled job records: Job history in the Director shows which backup, verify and archive jobs ran, when, and with what status.
Catalog-based restore: Restores can be selected from the current backup or from a prior point in time, which supports documented recovery point objectives.
Verify jobs: Verify jobs compare stored data with the catalog, producing a record that the backup set is readable.
Archive jobs: Archive job records help show retention and separation of long-term copies from routine backups.
Licence review: Confirm AGPL-3.0-only obligations with counsel if the platform is modified or exposed to outside users.

Before relying on these records, confirm which job types your configuration runs, how long catalog and job history are retained, and whether logs are shipped to a store the operations team cannot alter.

Common Article 12 gaps and how to close them

Why does backup frequency need to be linked to data criticality?

Article 12(1) requires a documented minimum backup frequency that depends on how critical or confidential the data is, so a single schedule applied to everything usually fails the test. Many organizations back up all systems nightly because it is easy to configure, but nobody can explain why a payment ledger and a test wiki share a frequency. The closing action is to take the output of your business impact analysis and classify each ICT-supported function by criticality and data confidentiality, then write a frequency for each class in the backup policy and configure the backup jobs to match. Keep the mapping as evidence, and have the owner of each function approve it.

What does it mean to test restores end to end, and why is it a gap?

Restores are never tested end to end when the team confirms that backup jobs succeed but has never rebuilt a system from backup in a separate environment and checked that it works. Article 12(2) requires periodic testing of both backup procedures and restoration and recovery procedures, so job logs alone do not satisfy it. The closing action is to write a restore test for each critical function that restores the data to an isolated environment, starts the application, and checks business transactions against a known reference. Record the date, the backup used, the elapsed time and the result, and treat any failure as a finding with an owner and a deadline. Open-source tools such as Bareos, which restores files from the current backup or one before a given date and time, and restic, whose restic check command can read pack files back, can supply part of this evidence.

How do I stop restore environments from being reachable from production?

Restore environments become a gap when they share credentials, networks or backup repositories with production, so a compromise in one can reach the other. Article 12(3) requires that ICT systems used to restore backup data be physically and logically segregated from the source system and protected from unauthorized access or corruption. The closing action is to place restore targets in a separate network segment with no standing routes to production, use separate identities and credentials, and make the backup repository append-only or write-protected from production administrators. Document the segregation design, then test it by attempting access from production hosts and recording that the attempts fail. Your security engineers and the platform owner should review the design together, since the answer depends on how your network and identity systems are built.

What happens if RTO and RPO are set for the whole company instead of per function?

A single recovery time objective and recovery point objective for the whole organization is a gap because Article 12(6) and (7) require objectives set per function, taking into account whether the function is critical or important. A company-wide figure either overstates what a low-value system needs, which wastes money on redundancy, or understates what a payment or settlement function needs, which leaves real exposure. The closing action is to derive the recovery time objective (the time within which a function must be back) and the recovery point objective (the amount of data loss a function can tolerate) for each critical or important function from the business impact analysis, and to get the business owner to sign them. Then confirm that the backup frequency, redundant capacity and restore tests all support those figures. Ask your auditor which functions they will sample.

What integrity checks should run after a restore is complete?

After a restore, the gap is usually that the team declares the system live without checking that its data is complete and consistent with what it was before the failure. Article 12(7) requires checks and reconciliations during recovery to maintain the highest level of data integrity. The closing action is to define reconciliation rules for each critical function, such as record counts, control totals, balance checks against the ledger, hash or checksum comparisons for files, and sequence checks for transactions, and to run them before the restored system is returned to users. Where the function depends on transactions that occurred during the outage, document how they will be recovered and reconciled. Keep the reconciliation results with the restore test record, so an assessor can see the check was performed and what it found.

Can we do these closing actions ourselves, or do we need an implementation partner?

Most organizations can close these gaps internally if they have staff who know their backup platform, network segmentation and business processes, and the work is mostly documentation plus repeated testing. The effort depends on how many critical functions you have, how many backup systems are in use, and whether the restore environments already exist. An implementation partner can help prepare the isolated restore environment, configure backup and verification jobs on open-source platforms inside your own infrastructure, and assemble the evidence pack. Under a fixed-scope engagement, the scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that scope. The organization still owns the policy, the RTO and RPO decisions and the test results, and only an independent auditor issues any assessment conclusion.

Which evidence will an assessor ask for to show Article 12 is met?

An assessor will usually ask for the documented backup policy, the criticality classification that links frequency to function, the RTO and RPO register, the segregation design for restore environments, dated restore test records and the reconciliation results from those tests. They will also check whether the tests were periodic, whether failures produced corrective actions, and whether the policy matches what the systems actually do. Gather these artifacts in a single folder with version numbers, approval dates and named owners. Confirm with your competent authority or auditor which artifacts they expect, since the depth of evidence can depend on your entity type and the proportionality principle under Article 4.

How DeployOpen prepares Article 12 backup and recovery evidence

DeployOpen scopes Article 12 work in writing before any build starts. The written scope names the data sets and ICT functions covered, the backup frequency tied to each function's criticality or confidentiality, the restore paths to be proven, and the recovery time and recovery point objectives the entity has set for each critical or important function. Engagements are fixed-scope, so the deliverables are known in advance. DeployOpen implements the self-hosted backup and restore environments inside the client's own cloud accounts, data centers or air-gapped networks, using open-source platforms such as Bareos, where the Director schedules backup, restore, verify and archive jobs and keeps a SQL catalog of what was backed up. DeployOpen does not select the entity's functions or set its objectives; the management body and the entity's own risk owners do.

The build covers the points Article 12 asks for in practice: a restore environment physically and logically separated from the source systems and protected from unauthorized access or corruption, documented procedures for activating backup systems without weakening security or data integrity, and redundant capacity sized to the business need. Where a secondary site is required, the site design and its distance from the primary are decisions to confirm with the entity's regulator and its own legal analysis. DeployOpen runs restore tests and integrity checks against those environments, using tools such as restic, whose check command verifies snapshot, tree and pack file consistency and, with --read-data or --read-data-subset, reads pack data back to confirm it is unmodified. Test results, restore timings measured against the objectives, and reconciliation records are retained as evidence.

DeployOpen assembles this evidence into a package the entity can give to its own auditor or supervisor: the backup and restoration policies and procedures, configuration records, test plans and results, and the change history of the environment. DeployOpen does not issue audit reports, attestations or certifications. Only the entity's independent auditor or the competent authority can assess whether its arrangements meet Article 12. Before engaging, ask the provider to confirm in writing which artifacts will be delivered, who owns the restore test records after handover, and how periodic testing will be repeated for the simplified regime or after major changes.

Article 12 Backup policies, restoration and recovery