Backup Policy: 6 Proven Rules DORA Article 12 Sets

Most organisations have a backup policy. Far fewer have one that says what the regulators actually ask it to say — and the gap is almost always in the same three places: scope, segregation, and what happens to data integrity after a restore.

DORA is the most specific text available on this, and it is worth reading even if you are not a financial entity, because it describes what “good” looks like in operative language rather than guidance.

What a backup policy has to specify

DORA Article 12(1)(a) requires backup policies and procedures specifying the scope of the data that is subject to the backup and the minimum frequency of the backup, based on the criticality of information or the confidentiality level of the data.

Two details change how the document is written.

Scope has to be stated, which means exclusions have to be stated. A backup policy that describes how backups run but never says which data is in scope is not answering the requirement. The useful version names what is not backed up and why.

Frequency is derived, not chosen. It follows from criticality or confidentiality — so the policy needs a link to your data classification scheme. If classification and backup frequency are maintained by different teams on different schedules, the derivation does not exist and the policy is asserting a number.

The backup policy requirement that means immutability

Article 12(3) is the provision worth taking to an infrastructure team. When restoring backup data using their own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system, and those systems shall be securely protected from any unauthorised access or ICT corruption.

The Regulation never uses the word “immutable”. It does not need to. A backup that an attacker with domain credentials can reach from the source environment is neither logically segregated nor protected from corruption, and that is precisely the failure mode ransomware relies on.

Article 12(2) adds the other half: activating backup systems shall not jeopardise the security of the network and information systems or the availability, authenticity, integrity or confidentiality of data. A restore path that requires disabling controls to work is a finding, not a procedure.

And the testing duty sits in the same paragraph — testing of the backup, restoration and recovery procedures shall be undertaken periodically. Restoring a file is not testing a restore.

Backup policy recovery objectives that hold in extreme scenarios

Article 12(6) requires recovery time and recovery point objectives to be set per function, taking into account whether it is a critical or important function and the potential overall impact on market efficiency — and it adds a condition most RTO tables quietly fail: such time objectives shall ensure that, in extreme scenarios, the agreed service levels are met.

An RTO derived from a single-system failure is not an RTO for an extreme scenario. If your numbers were calculated assuming the primary site is available, the network is intact and the team is reachable, they describe an inconvenience rather than a disaster.

Article 12(4) backs this with capacity: entities other than microenterprises shall maintain redundant ICT capacities adequate to business needs, and microenterprises must assess the need based on their risk profile.

The backup policy clause everyone forgets: integrity after the restore

Article 12(7) is the most practically useful sentence in the article. When recovering from an ICT-related incident, financial entities shall perform necessary checks, including any multiple checks and reconciliations, in order to ensure that the highest level of data integrity is maintained. Those checks shall also be performed when reconstructing data from external stakeholders, in order to ensure that all data is consistent between systems.

This is the part of a recovery that actually takes the time. Restoring to a point before the incident means every transaction after that point is missing, and the reconstruction comes from counterparties, payment providers and customers. It is where the real recovery window is spent, and almost no backup policy describes it.

Write the reconciliation procedure now, while nobody is under pressure, and name who owns each external source.

Where NIS2 puts it

NIS2 handles the same ground with a single phrase. Article 21(2)(c) lists business continuity, such as backup management and disaster recovery, and crisis management among the risk-management measures entities must take.

Less prescriptive, same three components — and because NIS2 is transposed nationally, the detail arrives through your Member State’s implementing law rather than the Directive itself. DORA’s Article 12 is a reasonable model for what a supervisor will expect to see behind that phrase.

A backup policy that survives an audit

• State the scope, including exclusions, and say who approved them.
• Derive frequency from classification, and show the mapping rather than asserting the interval.
• Describe the segregation — physical and logical — between backup and source, in terms an attacker path would have to defeat.
• Set RTO and RPO against extreme scenarios, and record the assumptions each number rests on.
• Include the reconciliation procedure for data reconstructed from external parties.
• Record the test, its date, what failed and what changed.

How the backup policy connects

Where to start

1. Check whether your backup policy states scope at all, or only method.
2. Trace one frequency back to a classification decision, and see whether the link exists.
3. Test the segregation by asking what credentials would reach the backups from a compromised source system.
4. Re-derive RTOs for an extreme scenario, not a single-system failure.
5. Write the external reconciliation procedure, since Article 12(7) requires it and nobody has one.
6. Schedule and record restore tests, because periodic testing is explicit.

This guide reflects Regulation (EU) 2022/2554 and Directive (EU) 2022/2555 as published on EUR-Lex, read at 16 August 2026. NIS2 is transposed nationally — the applicable detail is your Member State’s.

The ISO 27001 Toolkit provides 162 editable templates including the backup policy, the information classification scheme it depends on and the test records — and the DORA Toolkit covers the Article 12 specifics for financial entities.