Which standards require a disaster recovery plan?

ISO/IEC 27001:2022: 5.30, 8.14; ISO 22301:2019: 8.4.5; DORA (Regulation (EU) 2022/2554): Art. 11, Art. 12; The NIS2 Directive: Art. 21(2)(c).

Who should own the disaster recovery plan?

The clauses imply the head of IT operations. The register names the role so the line on your list can carry a name.

How often should a disaster recovery plan be reviewed?

Annual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).

Is there a template for a disaster recovery plan?

Yes: https://compliance.theartofservice.com/policy-templates/disaster-recovery-plan

Every policy type · Resilience and incidents

Disaster recovery plan

Q: What must a disaster recovery plan contain under ISO 27001?

5.30: Plan, implement, maintain and test ICT readiness against business continuity objectives. 8.14: Build enough redundancy into processing facilities to meet availability requirements. The ISO 27002 guidance beside 5.30: Requires ICT readiness to be planned, implemented, maintained and tested against business continuity objectives and ICT continuity requirements. Supporting material frames this as ICT infrastructure and resources being resilient enough to carry business operations through disruption.

How the technology behind the critical activities is recovered: the order, the targets, the sites, the people and the tests.

How the register reads it

Also called	DR plan, ICT readiness for business continuity, IT continuity plan
Family	Resilience and incidents
Document type	Plan. The regimes ask for the content, not the label; a line pasted as a standard, procedure, plan or schedule is placed here with the label noted.
Folds into	The regimes accept it folded into the business continuity plan; when neither is listed, the gap is counted once, under the parent.
Expected owner	The head of IT operations.
Review cadence	Annual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).
On the gap list when	ISO 27001 or DORA is ticked and no line resolves to it or to its parent (ISO 22301, NIS2 require it too, inside a parent document, so they do not list it separately).
Template	Disaster recovery plan.

Which standards require it, and what each expects it to contain

6 requiring clauses, 4 regimes

Shown on a register for the regimes you tick; with none ticked, ISO 27001 is applied. Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.

ISO/IEC 27001:2022

ISO 27001 5.30 ICT readiness for business continuity

Plan, implement, maintain and test ICT readiness against business continuity objectives.

What the ISO 27002 guidance expects the document to say: Requires ICT readiness to be planned, implemented, maintained and tested against business continuity objectives and ICT continuity requirements. Supporting material frames this as ICT infrastructure and resources being resilient enough to carry business operations through disruption.

Evidence an auditor accepts: ICT continuity requirements derived from the business impact analysis, expressed as recovery time and recovery point objectives per service; the ICT continuity plans and the technical capability supporting them, such as replication, failover and alternative capacity; test plans and results for the period, showing objectives were measured against the requirement rather than assumed
Common gap: Testing frequency not aligned with risk
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022

ISO 27001 8.14 Redundancy of information processing facilities

Build enough redundancy into processing facilities to meet availability requirements.

What the ISO 27002 guidance expects the document to say: Requires information processing facilities to be implemented with redundancy sufficient to meet the availability requirements placed on them.

Evidence an auditor accepts: Availability requirements per service, expressed as measurable objectives; the redundancy design showing how each requirement is met, and where single points of failure remain; evidence of failover testing, with results measured against the objective and the date of the last test
Common gap: reliance on undocumented manual backups
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022

ISO 22301:2019

ISO 22301 8.4.5 Recovery

Maintain documented processes to restore and return business activities from the temporary measures adopted during and after a disruption.

Evidence an auditor accepts: Documented restoration and return to normal processes; criteria for deciding that temporary measures can be withdrawn; evidence of use, from exercises or real events, including backlog clearance
Common gap: Recovery treated as implicit once the incident is closed, with no process behind it
Source: ISO 22301:2019

DORA (Regulation (EU) 2022/2554)

DORA Art. 11 Response and recovery

Financial entities shall put in place an ICT business continuity policy and ICT response and recovery plans (including measures, procedures and arrangements) to ensure continuity of critical or important functions, quickly contain damage, resume activities and recover, subject to regular testing.

Evidence an auditor accepts: ICT business continuity policy + response/recovery plans; records of plan testing
Common gap: No ICT continuity/response/recovery plans
Source: DORA (Regulation (EU) 2022/2554)

DORA Art. 12 Backup policies and procedures, restoration and recovery

Financial entities shall develop and document backup policies and procedures, and restoration and recovery procedures and methods, ensuring backups can be restored with minimal disruption, with backup systems physically and logically segregated from the source system.

Evidence an auditor accepts: Backup and restoration policies/procedures; evidence of segregated backups and restoration tests
Common gap: No tested backups
Source: DORA (Regulation (EU) 2022/2554)

The NIS2 Directive

NIS2 Art. 21(2)(c) Business continuity, backup management, disaster recovery and crisis management

This category asks the entity to be able to keep providing its services, or to restore them, when systems fail or are attacked. Backup management means backups that are taken, protected against the same event that takes out production, and demonstrably restorable, which is why restore testing rather than backup success rate is the evidence that counts. Disaster recovery means recovery objectives that were derived from what the service can actually tolerate, and infrastructure and procedure capable of meeting them. Crisis management is the decision-making layer above both: who declares a crisis, who can commit the organisation, how the entity communicates while under pressure. Because NIS2 is concerned with continuity of service to recipients, recovery objectives set purely from internal convenience are the usual weak point.

Evidence an auditor accepts: Business impact analysis deriving recovery time and recovery point objectives from service tolerance; backup configuration showing isolation or immutability against destructive attack; restore test results, dated, covering the systems that carry the essential service
Common gap: Backups verified as completed but never restored end to end
Source: NIS2 Directive

Do this for every document on your list

Paste the list and get this reading for every document at once, with the owner and cadence against each, the clauses quoted, and the documents the regimes expect that the list does not carry. Eight documents free, no account.

Build a register

Crisis management plan · Evidence collection and forensics procedure