DORA Art. 12 in Practice: Backup Policies That Actually Pass Supervisory Review
The Backup Illusion
Every financial institution has backups. Tapes, snapshots, replicated databases, cloud-based backup services, offsite copies. The question DORA asks is not whether backups exist — it is whether they work. Whether they cover the right systems. Whether they can be restored within the time windows that the business requires. Whether the restoration has been tested under realistic conditions. And whether all of this is documented, evidenced, and reported to the management body.
Article 12 of DORA is one of the most operationally demanding provisions in the regulation. It requires financial entities to establish backup and restoration policies that are aligned with their ICT risk management framework, tested regularly, and demonstrably effective. The ECB's cyber resilience stress test in 2024 revealed significant gaps in exactly this area — institutions had backup policies but could not demonstrate that restoration would meet their stated recovery objectives.
What Art. 12 Actually Requires
Art. 12 is more granular than most institutions initially expect. It does not simply require "backup policies." It requires a comprehensive framework:
| Art. 12 provision | Requirement | Supervisory focus |
|---|---|---|
| Art. 12(1) | Backup and restoration and recovery policies | Written policy with scope, frequency, retention, and testing requirements |
| Art. 12(2) | Backup scope to cover all systems needed for critical functions | Completeness — no critical function dependency left unprotected |
| Art. 12(3) | Recovery from backup within RTO/RPO targets | Demonstrated through actual testing, not theoretical analysis |
| Art. 12(4) | Segregation of backup environment | Physical or logical separation from production |
| Art. 12(5) | Consideration of ICT third-party service provider failures | Backup independence from primary provider |
The Scope Requirement (Art. 12(2))
Art. 12(2) requires that backup scope covers "systems and data supporting the performance of critical or important functions." This creates a direct dependency on the institution's ICT asset register and business impact analysis. If the asset register is incomplete, the backup scope is incomplete by definition.
The practical implication is that the backup policy cannot be written in isolation. It must derive from the business impact analysis, which derives from the critical function identification, which derives from the asset register. This chain of dependency means that gaps in any upstream step propagate to the backup policy.
The Testing Requirement (Art. 12(3))
Art. 12(3) is where most institutions fail supervisory review. Having a backup that theoretically provides 4-hour RPO and 2-hour RTO is meaningless if restoration has never been tested — or if the last test was three years ago on a different infrastructure version.
Supervisors expect to see:
- Regular restoration tests — at minimum annually for critical function supporting systems, semi-annually for the highest criticality tier
- Realistic test conditions — testing restoration on a production-equivalent environment, not a reduced-scale test bed
- Measured recovery metrics — actual RTO and RPO achieved during the test, compared against the targets defined in the business impact analysis
- Documented findings — any gaps between target and actual recovery, with remediation plans and deadlines
- Evidence archived — test scripts, test results, timing measurements, sign-off records
| Backup tier | Systems covered | RPO target | RTO target | Test frequency | Test type |
|---|---|---|---|---|---|
| Tier 1 (mission-critical) | Core banking, payment processing, client data | 15 minutes | 1 hour | Semi-annual | Full restoration to production-equivalent |
| Tier 2 (important) | Risk systems, reporting, compliance tools | 1 hour | 4 hours | Annual | Full restoration to test environment |
| Tier 3 (standard) | Internal tools, collaboration, email | 4 hours | 24 hours | Annual | Partial restoration sample |
| Tier 4 (administrative) | Development tools, archives, logs | 24 hours | 72 hours | Every 2 years | Validation of backup integrity |
The Segregation Requirement (Art. 12(4))
Art. 12(4) requires that backup environments are "adequately segregated" from the production environment. This addresses the scenario where an incident that affects production — ransomware, data corruption, infrastructure failure — simultaneously compromises the backups.
Segregation must be:
- Logical: Separate access controls, separate administrative credentials, separate network segments
- Physical or geographic: At least one backup copy in a different site, different availability zone, or different region
- Provider-diversified: For systems hosted with a single cloud provider, at least one backup copy stored independently of that provider (addressing Art. 12(5))
The Third-Party Independence Requirement (Art. 12(5))
Art. 12(5) requires that financial entities consider "ICT third-party service provider failures" in their backup strategy. This means the backup infrastructure must not share a single point of failure with the primary production infrastructure.
If core banking runs on AWS, the backup cannot rely solely on AWS. If the database is managed by a third-party DBaaS provider, the backup must be accessible independently of that provider. This does not require a full multi-cloud strategy — but it requires at least one backup tier that survives the complete failure of the primary ICT service provider.
The concentration risk analysis under Art. 29 informs this requirement. If the institution's third-party register shows that backup services are provided by the same hyperscaler as production services, this is a concentration risk that must be documented, assessed, and either mitigated or formally accepted with compensating controls.
Building the Evidence Package
A supervisory review of Art. 12 compliance will request specific evidence. The institution should maintain a standing evidence package that includes:
| Evidence artifact | Update frequency | Classification |
|---|---|---|
| Backup policy document (approved by management body) | Annual review | INTERNAL |
| Backup scope matrix (systems to backup tier mapping) | Quarterly or on asset register change | CONFIDENTIAL |
| Backup execution logs (success/failure per system per day) | Continuous (automated) | INTERNAL |
| Restoration test plans | Per test cycle | CONFIDENTIAL |
| Restoration test results with measured RTO/RPO | Per test cycle | CONFIDENTIAL |
| Gap analysis (target vs. actual recovery metrics) | Per test cycle | CONFIDENTIAL |
| Remediation plans for identified gaps | As needed | CONFIDENTIAL |
| Segregation architecture documentation | Annual review | RESTRICTED |
| Third-party provider backup independence assessment | Annual review | CONFIDENTIAL |
This evidence package feeds into the DORA evidence management framework with SHA-256 integrity verification, role-based access control, and 10-year retention.
Common Supervisory Findings
Based on supervisory practice and the ECB's 2024 stress test findings, the most common Art. 12 deficiencies are:
Incomplete backup scope. The institution backs up "all servers" but has not verified that this covers all data dependencies for all critical functions. Shadow IT, SaaS data, and cloud-native services are frequently excluded.
Untested restoration. Backups run successfully every night, but no one has attempted a full restoration in over a year. When restoration is tested, it is tested on a reduced-scale environment that does not replicate production complexity.
RTO/RPO targets not validated. The business impact analysis declares a 2-hour RTO, but the last restoration test took 6 hours. The gap is not documented, not reported to the management body, and not subject to a remediation plan.
No ransomware-specific backup. The backup infrastructure uses the same credentials, same network, and same access patterns as production. A ransomware attack that compromises production administrative credentials also compromises all backups.
Third-party concentration. All backups are stored with the same cloud provider as production. A provider-level outage takes down both production and recovery capabilities.
The Art. 12 Testing Programme
Restoration testing must be structured as a programme, not an ad hoc exercise. The programme should integrate with the institution's broader resilience testing programme under Art. 24-27.
Each test must produce a formal record that includes: test date, test scope, systems tested, target RTO and RPO, actual RTO and RPO achieved, any issues encountered, and the sign-off of the test owner. This record is stored in the evidence vault with the same chain-of-custody controls applied to all regulatory evidence.
The Art. 14 board reporting should include a summary of restoration test results, highlighting any gaps between target and actual recovery metrics and the status of remediation plans.
Proportionality Considerations
Art. 4 establishes proportionality as a principle throughout DORA. For Art. 12, this means that the backup and testing requirements scale with the institution's size, risk profile, and complexity.
A small payment institution with five employees and one critical application does not need the same multi-tier, multi-region backup architecture as a global systemically important bank. But it does need: a documented backup policy, backup scope covering its critical function dependencies, regular restoration testing (at least annual), and evidence that RTO and RPO targets are met.
The supervisory expectation is that proportionality reduces the complexity of the implementation, not the substance of the requirements. Even the smallest in-scope entity must demonstrate that its backups work.
Assess your institution's backup and recovery maturity using the DORA readiness assessment, and review the RTS/ITS standards for detailed technical requirements on backup management.
Conclusion
Art. 12 is a deceptively simple provision that requires sophisticated operational discipline. The institutions that pass supervisory review are those that can demonstrate — with evidence — that their backup scope is complete, their restoration targets are validated through testing, their backup infrastructure is segregated and independent of primary providers, and their management body is informed of any gaps. The institutions that fail are those that confuse having backups with having resilience.
Resume en francais
L'article 12 de DORA impose des politiques de sauvegarde et de restauration qui doivent couvrir tous les systemes soutenant les fonctions critiques, etre testees regulierement et atteindre les objectifs RTO/RPO dans la pratique. Cet article detaille les cinq exigences specifiques de l'Art. 12 : la politique ecrite, le perimetre de sauvegarde aligne sur les fonctions critiques, la demonstration de recuperation par des tests, la segregation de l'environnement de sauvegarde et l'independance vis-a-vis des fournisseurs tiers. Il presente un modele de sauvegarde a quatre niveaux avec des objectifs RPO/RTO et des frequences de test differencies, une architecture de segregation incluant la protection anti-ransomware, le dossier de preuves attendu par les superviseurs et les constats les plus frequents lors des examens de supervision. Le programme de tests de restauration est structure pour s'integrer au programme de tests de resilience de l'Art. 24-27, chaque test produisant un dossier formel archive dans le coffre-fort de preuves.