DORA Articles 11 and 12: what "recover" has to actually mean¶
Detection tells you something broke. Articles 11 and 12 are about getting back up. This is the part of DORA that auditors love, because continuity and backup are testable in a way that policies are not: either you restored within your stated objective or you did not. Today, business continuity and backup, and the RTS that says testing them once is not enough.
Article 11: continuity as a policy, not a binder¶
Article 11 requires an ICT business continuity policy and a set of ICT response and recovery plans, sitting inside the ICT risk management framework. The board approves and reviews them (that was Article 5(2)(e), the loop closing). The point of Article 11 is that continuity is a live capability, tied to your critical or important functions, not a document that gets dusted off after the incident.
The plans have to cover the scenarios that actually threaten those functions, and they have to connect to the identification work from Article 8. You cannot write a recovery plan for a dependency you never mapped.
Article 12: backup, stated in numbers¶
Article 12 is refreshingly concrete. Entities must develop "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", plus restoration and recovery procedures. The regulation ties backup frequency to criticality, which again reaches back to your Article 8 classification. Critical data backed up on the same lazy schedule as everything else is a finding waiting to happen.
There is a detail people miss: Article 12 expects restoration to use systems that are physically and logically separated from the source, and it is wary of restoration introducing the very compromise you are recovering from. Backups that restore the malware alongside the data are not backups, they are a second incident.
Where the RTS makes it repeatable¶
RTS 2024/1774 Chapter IV turns this into three articles. Article 24 sets out the components of the ICT business continuity policy. Article 25 is the one that changes behaviour: testing of the ICT business continuity plans, on a schedule, with scenarios that include the failure of a critical ICT third-party provider. Article 26 covers the ICT response and recovery plans. The through-line is testing. DORA does not accept a continuity plan that has never been exercised, because an untested plan is a hypothesis.
The artefact: continuity and backup evidence¶
What proves Articles 11 and 12 are real, not shelfware.
| Requirement | Evidence |
|---|---|
| ICT business continuity policy (Art. 11) | Board-approved policy, dated, linked to critical functions |
| Response and recovery plans (Art. 11) | Plans per critical function, with roles and steps |
| Backup scope and frequency by criticality (Art. 12) | Backup schedule mapped to asset classification |
| Separated restoration (Art. 12) | Evidence backups restore on isolated systems |
| Continuity testing (RTS Art. 25) | Test calendar, results, third-party-failure scenarios |
| Recovery objectives | Documented RTO and RPO per critical function |
If the test-results row is empty, start there. It is the fastest way to turn a paper plan into a defensible one. The RTS text is in the DORA resource library.
Next in this series: Articles 13 and 14, learning and communication, the quiet articles that decide whether you actually improve after an incident or just survive it.