IT Disaster Recovery Procedure

DS-01

A server, its storage or its database fails

The warehouse management system's database storage fails

DS-02

A hosting provider's data centre or a cloud region goes down

The hosting provider loses the data centre that runs online ordering, or the ERP provider loses one of its two data centres

DS-03

A network line to a site fails

Warehouse 2's line fails

DS-04

A faulty update stops devices or servers from starting

An update to the endpoint protection agent makes office PCs and servers fail at start-up

DS-05

A site is lost

Warehouse 2 cannot be entered

DS-06

An attack is suspected

Encryption activity on a server

Crisis lead

[[e.g. Chief Operating Officer, the executive incident lead in a cyber incident (P09)]]

Decides to recover, to fail over or recover elsewhere (RA-22), to start a workaround, to fail back (RA-23), and when recovery ends (RA-17).

Technical recovery lead

[[e.g. Head of IT]]

Estimates the repair, advises on the failover decision, runs the runbooks, and plans the failback.

Business owner

[[the manager accountable for each critical service]]

Runs the workaround, tests the service and confirms it works before users return (RA-12), and agrees the time of the failback.

Incident manager

[[e.g. Information Security Manager (P09)]]

Takes the report of a failure under P09 (IM-01). Where an attack is suspected, confirms whether the copy or site to be used can be trusted (RR-23).

Supplier liaison

[[e.g. Procurement Manager]]

Calls on suppliers' recovery commitments and records their estimates (RA-14).

Resilience coordinator

[[e.g. a risk manager or business continuity manager who runs no system in scope]]

Keeps the crisis log and the times (RA-16), and raises the gaps afterwards.

Communications lead

[[e.g. Head of Marketing and Communications (P09)]]

Sends staff and customer messages from the outage templates (RR-27).

Site or unit continuity lead

[[the manager of each site or business unit, e.g. a warehouse manager]]

Takes a site's first steps at once, starts its workaround when a line or the building is lost, and accounts for its people.

Head of Information Security

[[e.g. Head of Information Security or CISO]]

Helps judge whether a failure may be an attack; in a faulty update to a security product (DS-04), works with its supplier on the fix.

A system a critical service needs fails, or the supplier that runs it reports that it has failed, and it is not back within [[30 minutes]]

The first assessment below

Technical recovery lead

The crisis lead invokes a critical service's continuity plan after a failure that is not an attack (RA-04)

The failover decision for each system the service needs

Crisis lead

A site or business unit loses its building or its systems and its continuity plan moves its work (RR-22)

Recovery elsewhere of the systems that run at the site, where the moved work needs them (DS-05)

Site or unit continuity lead

1

Record when the system failed, or was first reported, and which critical services depend on it (Annex 1).

Technical recovery lead

2

Check for the signs of an attack in the section above. If any is present, or nobody can yet say, follow that section before anything else.

Technical recovery lead;

Head of Information Security

3

Report the failure through P09's reporting route (IM-01), so P09 can decide whether it is an incident.

Technical recovery lead

4

Estimate when the system can be repaired where it is. Where a supplier runs or supports it, ask the supplier for its own estimate, and record both.

Technical recovery lead;

Supplier liaison

5

Tell the crisis lead what failed, the services affected, the repair estimate, and the recovery method and time in the system's runbook.

Technical recovery lead

6

Decide to recover the service, and record the time of the decision: the recovery time objective runs from it.

Crisis lead

7

Open the crisis log and keep it until the end of recovery.

Resilience coordinator

Repair in place

Fix the failed system where it is: replace a part, repair a database, apply a vendor's fix.

The repair will finish within the time left, or no other route is quicker.

Estimates slip while you wait for parts or for the vendor. Set the time at which you will decide again.

Fail over

Switch the system to a second site, region or copy that is kept running or ready, such as a replica database or a second data centre.

Systems whose recovery time objective is shorter than a restore would take.

Replication copies corruption, deletions and an attacker's changes as fast as good data. Failing back needs a plan of its own.

Restore elsewhere

Bring the system up on other hardware, standby servers or another environment, and restore its data from backup.

Systems that can wait for a restore, and failures that took the hardware or the site.

The copies must be held apart from what failed and checked for integrity before use. The data lost is everything since the copy was taken.

Rebuild

Install the system again from its build source and its stored configuration, then restore only its data.

A system whose own installation cannot be trusted or repaired, such as a corrupt operating system.

It needs current build sources and configuration baselines, kept where they can be reached when the main systems are down.

Supplier's own recovery

The supplier that runs the system recovers it on its own platform, under its contract.

Hosted and cloud services that you do not run yourself.

Its time is what the contract gives, or unknown, until the supplier shares a test. You still recover your own configuration, accounts and data.

Yes

Any

Any

Any

Hold: the incident manager first confirms the copy or site can be trusted

No

Yes

Any

Any

Repair in place

No

No

Yes

Any

Fail over or recover elsewhere

No

No

No

Yes

Fail over or recover elsewhere, and start the workaround now

No

No

No, or there is no other route

No

Repair in place, and start the workaround now

06:10

The warehouse management system's database storage fails, and warehouse dispatch stops. Its maximum tolerable downtime of 24 hours runs from now: the harm reaches Severe by 06:10 the next day.

06:40

The technical recovery lead estimates the repair in place at [[10]] hours. The restore elsewhere took 5 hours in RV-2026-03 (27 Aug 2026). The crisis lead decides to recover: the 8-hour recovery time objective runs from now, so the target is 14:40.

06:40

The repair would finish at about 16:40, after the target. The restore would finish at about 11:40, before it. Decision: Fail over or recover elsewhere. The system's method is restore elsewhere, onto [[standby servers]] (Annex 1).

About 11:40

The system is ready for the business owner's test. Users go back when the Head of Logistics confirms that dispatch works (RA-12).

1

Confirm what failed (the server, its storage or the database on it) and which critical services use it, from Annex 1. A corrupt database, or storage that fails with no hardware fault reported, deserves a check for the signs of an attack.

Technical recovery lead;

Head of Information Security

2

Get the repair estimate from the hardware or software supplier's support, record it with its source, and advise the crisis lead with the runbook's time for the alternative (RR-23).

Technical recovery lead;

Supplier liaison

3

Decide, and record the decision, the estimates and the time (RA-22).

Crisis lead

4

Run the decision. After a failover, keep repairing the failed system: it is where the service fails back to. Decide again when an estimate moves past the time left.

Technical recovery lead;

Crisis lead

1

Call on the provider's recovery commitment: its contracted time, its own estimate, and how often it will report progress (RA-14). Read its notice for any sign of an attack; if there is one, or it will not say what happened, tell the incident manager and hold.

Supplier liaison;

Incident manager

2

List every system the lost data centre or region ran, and the services each one serves, from Annex 1.

Technical recovery lead

3

Decide for each system, with the provider's estimate as the repair time and your own failover or restore elsewhere as the alternative (RR-23).

Crisis lead;

Technical recovery lead

4

Before a restore elsewhere, confirm the backup copies were not held in the lost data centre or region. Before a failover, confirm the other region or data centre has the capacity, network routes, certificates and accounts the systems need.

Technical recovery lead

5

Record each of the provider's updates with its time, and decide again when its estimate moves.

Resilience coordinator;

Crisis lead

1

The site tells IT and the crisis lead at once, and works from its continuity plan (RR-22).

Site or unit continuity lead

2

Ask the network provider for its repair estimate. If the line will be down longer than the time left, the site starts its workaround at once.

Supplier liaison;

Site or unit continuity lead

3

Use a second route where one exists, such as [[a second line from another provider, or a mobile data router kept at the site]], with its security settings agreed in advance.

Technical recovery lead

4

When the line returns, check that queued transactions, print jobs and scanner uploads have caught up, then end the workaround with the business owner.

Technical recovery lead;

Site or unit continuity lead

1

Confirm the pattern: devices or servers fail at start-up after an update to one product, and no other sign points to an attack. Tell the incident manager at once. Nothing is restored or failed over until the incident manager agrees the cause is the update (RR-23).

Technical recovery lead;

Incident manager

2

Stop the update spreading, where the product allows: pause it in the product's management console, and ask the supplier to withdraw it. Keep devices that still work running, and do not restart them until the fix is known.

Technical recovery lead;

Supplier liaison

3

Get the supplier's fix and its instructions. Try them on one device of each kind before using them widely. If the fix is manual, such as removing a file from each device in a recovery environment, plan the hands-on time per device, and have the recovery key ready for each encrypted device.

Technical recovery lead;

Head of Information Security

4

Recover the sign-in directory and monitoring first, then the rest of the foundations. Reach the disk recovery keys of encrypted devices from where they are kept apart from the affected systems; if the only copy is in the directory or the device management tool, recover that first.

Technical recovery lead

5

Recover the servers, then the devices, of each critical service in the recovery order. Count devices recovered against devices affected, by service and site.

Technical recovery lead;

Resilience coordinator

6

Start the workaround of every service that cannot be back within its recovery time objective (RR-06).

Business owner

7

Give staff a way to have their devices fixed by hand: [[a desk at each site, and a courier or a call-back for staff at home]].

Technical recovery lead;

Communications lead

1

Take the site plan's first steps at once: people safe and accounted for, the call tree started, the crisis lead called (RR-22).

Site or unit continuity lead

2

Invoke the site's continuity plan (RR-17). It says where the site's work moves and how fast.

Crisis lead

3

List the systems that run at the site itself: servers, network equipment, printers, scanners. Recover elsewhere only those the moved work needs, by their runbooks.

Technical recovery lead

4

Give the receiving sites the network access, devices, printers and accounts the moved work needs, and check them with the site's lead.

Technical recovery lead;

Site or unit continuity lead

1

Confirm the decision is in the crisis log with its time. Where an attack was suspected, confirm the incident manager has said the copy or site to be used can be trusted.

Resilience coordinator

2

Open the system's runbook and follow it step by step. Record when each step starts and ends. If a step fails, stop and tell the crisis lead, who decides the next route.

Technical recovery lead

3

Record the recovery point. For a restore, use the newest copy that passes its integrity check (RR-11), and record when it was taken. For a failover, record how far behind the second site or copy was when the first failed.

Technical recovery lead

4

Bring up the system and its interfaces, and check them: it starts, it answers, its interfaces to other systems and suppliers work, and its backups run from the new place.

Technical recovery lead

5

Measure the data lost, from the recovery point to the failure, against the recovery point objective. Name who recovers what was lost, and from where: suppliers' records, customers' confirmations, emails, paper.

Business owner;

Resilience coordinator

6

Ask the business owner to test the service as its users use it. Let users back only when the business owner confirms that it works.

Business owner

7

Let users back. End the workaround at a time agreed with them, and catch up the backlog it left.

Business owner;

Technical recovery lead

8

Record the time achieved, from the decision to recover to users back, against the recovery time objective and the maximum tolerable downtime.

Resilience coordinator

1

Plan the failback like a change: the steps, the time each takes, the checks, how to stop and stay on the failover set-up if a step fails, and how the data written meanwhile is copied back and reconciled before users move. Where writes landed on both sides, name the source for each data set and who resolves a conflicting record.

Technical recovery lead;

Business owner

2

Agree the time with the business owner, away from the service's busiest periods.

Business owner

3

Ask the crisis lead to approve the failback (RA-23).

Technical recovery lead;

Crisis lead

4

Tell users when, and for how long, the service will pause, from the outage templates.

Communications lead

5

Fail back. Check the system as after the recovery, and have the business owner confirm that the service works.

Technical recovery lead;

Business owner

6

Record the time taken, the data reconciled and anything found, in the crisis log and in the runbook.

Resilience coordinator;

Technical recovery lead

1

Check that every affected service runs on its normal set-up, or on an alternate set-up accepted for a set time (RR-25), that its workaround has ended and that its backlog is cleared.

Resilience coordinator

2

Declare the end of recovery on the plan's criteria, and record it (RA-17).

Crisis lead

3

Tell staff, and the customers who were told of the disruption, that the service is back.

Communications lead

4

Close the crisis log and file it, with the runbook records, where nobody who took part can change it.

Resilience coordinator

Failure

When each system failed or was reported, how it was found, and the critical services affected

Attack check

Who checked for signs of an attack, what they found, and the incident manager's answer where asked

Decisions

Each decision: repair, fail over, restore elsewhere, start or end the workaround, fail back, end recovery. Who took it, when, the estimates it rested on and the reason

Times

For each service: the failure, the decision to recover, users back; the time achieved against the recovery time objective and the maximum tolerable downtime

Data lost

For each data set: the recovery point, the data lost against the recovery point objective, and how it was recovered

Suppliers

Each supplier's estimates and updates, with their times, and what it was asked to do

Messages

What staff and customers were told, and when

End

When the end of recovery was declared, by whom and on which criteria; the gaps raised

1

Record every objective the recovery missed as an objective gap, with an owner, and tell the service's risk owner (RR-15).

Resilience coordinator;

Business owner

2

Write the time each method achieved into its runbook. A method used in a real recovery has shown what it achieves; record that, and keep it in the test plan.

Technical recovery lead

3

Review the service's recovery plan and the runbooks used, and write the lessons in (RR-16). Update the dependency register where a dependency turned out different (RR-09).

Resilience coordinator;

Technical recovery lead

4

Ask the business owner to review the objectives where the recovery showed they are wrong (RR-05).

Resilience coordinator;

Business owner

5

Give the timings and the data lost to the incident manager, where P09 treated the failure as an incident, for its review (IM-11).

Resilience coordinator

The repair estimate keeps moving, or nobody can give one

Decide on the information there is. Treat an unknown repair time as later than the time left, and start the workaround.

Crisis lead

RR-23; RR-06

The failover or restore elsewhere fails, or runs longer than its runbook says

Decide again with the time now left. Start the workaround if it is not running.

Crisis lead

RR-23

A service, with its workaround, is heading past its maximum tolerable downtime

Decide what else can be done: more people, a supplier's help, a partial service. Tell the approver.

Crisis lead

RR-06; RR-17

A sign of an attack appears at any point

Stop failing over and restoring until the incident manager confirms the copy or site can be trusted. P09 runs the incident.

Incident manager

RR-23; P09 IM-01

A supplier gives no recovery time, or misses its contracted one

Call on the contract, record the gap, and plan around the supplier.

Crisis lead

RR-10; P06 TP-10

The data lost is more than the recovery point objective allows

The business owner names who recovers what was lost. It becomes an objective gap at the end of recovery.

Business owner

RR-15

PF-02

Counting failover to a second site as cyber recovery.

Replication copies the damage. Work out the cyber recovery time from a clean rebuild (RR-07, MX-05).

PF-07

Keeping the only copy of the plan on the systems it recovers.

Keep a copy and the contacts where they can be reached in an outage (RR-16).

PF-10

Failing over to a replica while an attack may still be under way.

Hold until the incident manager confirms the copy can be trusted (RR-23).

PF-11

Testing failover on the live service in its busiest weeks, with no way back.

Plan every test with a stop point and a way back, approved by the business owner (RR-26).

PF-12

Telling customers nothing until the service is back.

Send the first message within hours and update on a set rhythm (RR-27).

Business Continuity & ICT Resilience Policy

The rules this procedure applies: RR-23 to RR-25, and the rules on workarounds, communication, gaps and records

Cyber Recovery Operating Procedure

Recovery after a destructive cyberattack (DS-06)

Critical Service Recovery Objectives Matrix (RTO, RPO, MTD)

Each service's maximum tolerable downtime and recovery time and point objectives

Cyber Recovery Plan Template

Each service's recovery plan; the runbooks sit beside it

Resilience Dependency Register

What each service depends on, and each dependency's recovery time

Site & Business Unit Continuity Plan Template

Each site's and unit's plan for the loss of its building, people, a supplier or its systems (DS-03, DS-05)

Continuity & Disaster Recovery Test Plan and Report

Plans and reports of failover tests, recovery tests and workaround trials (RR-26)

Outage Communications Template Set

The outage messages (RR-27)

Incident Response Plan, Security Incident Management pack (P09)

Incident response, the reporting route (IM-01) and every decision right during an incident

Third-Party Security Risk Management pack (P06)

Supplier contracts and their recovery commitments (TP-10)

Patch Management pack (P17)

Rings and rollback criteria for updates (PM-05 to PM-08)

DP-02

Online ordering platform

Restore elsewhere

The hosting provider's spare environment

96 hours

Tested in RV-2026-02, 20 May 2026

CS-01: beyond 24

Moved back to the primary environment in a planned window outside the peak season, once the orders taken meanwhile are reconciled.

Too slow for the 24-hour objective until the rebuild of P05 TA-01 is done (OG-01).

DP-03

Cloud hosting provider

Supplier's own recovery

The hosting provider's other data centre

24 hours, from the contract

Untested

CS-01: within 24

CS-04: within 48

The provider's, with notice of the window.

Contract only: never tested.

DP-04

Backup service provider

Supplier's own recovery

The backup service provider's platform

Not known

Untested

CS-01: not known

CS-04: not known

The provider's.

No recovery time in the contract (OG-02).

DP-07

Warehouse management system

Restore elsewhere

[[standby servers]]

5 hours

Tested in RV-2026-03, 27 Aug 2026

CS-02: within 8

Moved back to the usual servers in a planned evening window, after a count of the affected aisles.

Within dispatch's 8 hours.

DP-08

Warehouse management system provider

Supplier's own recovery

The provider's support service

Not known

Untested

CS-02: not known

Not needed: the system stays where it is.

No recovery time in the contract (OG-06).

DP-09

ERP software provider (hosted)

Fail over

The ERP provider's second data centre

3 hours

Tested in RV-2026-01, 20 Jan 2026

CS-02: within 8

CS-04: within 48

The provider's, with notice of the window.

Contract: 8 hours, at most 15 minutes of data lost.

DP-11

Network connectivity provider

Repair in place

The network connectivity provider repairs the line

12 hours, from the contract

Untested

CS-01: within 24

CS-02: beyond 8

Not needed: the line is repaired.

No second line (OG-03): dispatch uses its workaround.

DP-14

Payment service provider

Supplier's own recovery

The payment service provider

Not known

Untested

CS-03: not known

The provider's.

Its recovery test is planned (RV-2027-01).

DP-16

Payroll bureau

Supplier's own recovery

The payroll bureau

Not known

Untested

CS-04: not known

The bureau's.

No recovery time in the contract (OG-08).

DP-17

Email and office software provider

Supplier's own recovery

The email and office software provider

Not known

Untested

CS-05: not known

The provider's.

The contract sets availability, not a recovery time; the restore is tested in RV-2026-04.

DP-18

Outsourced customer contact centre

Supplier's own recovery

The outsourced customer contact centre

Not known

Untested

CS-05: not known

The provider's.

No recovery time in the contract (OG-09).

System

[[system name, DP-nn]]

Warehouse management system (DP-07; P07 SYS-02)

Services it serves

Each with its recovery time and recovery point objectives

[[CS-nn service: RTO, RPO, MTD]]

CS-02 Warehouse dispatch: RTO 8 hours, RPO 4 hours, MTD 24 hours

Recovery method

[[method]]

Restore elsewhere

Where it recovers to

[[where]]

[[standby servers]]

Time it takes

From the first step to the system ready for the business owner's test

[[hours]]

5 hours

Tested

Test ID, date and time achieved, or Untested

[[test ID, date, hours]] or Untested

RV-2026-03, 27 Aug 2026: 5 hours

Before you start

What must be in place: foundations, access, licences, recovery keys, the copy to restore

[[prerequisites]]

The foundations running (DP-01); [[access to the standby servers, their licences, the backup copy]]

Who may run it

With deputies and the accounts they use

[[role; deputy; accounts]]

Head of IT (technical recovery lead); deputy: IT Operations Manager

Steps

Numbered, each with its time and the check that it worked

[[1. … 2. … 3. …]]

[[the steps as run in RV-2026-03, each with its time]]

Data

Where the copies are, how often they are taken, how lost data is found again

[[copies, interval, sources]]

Stock and dispatch records (DP-10): daily backup, against the 4-hour RPO; gap OG-05, change due 15 Dec 2026. Data lost is found again by a count of the affected aisles.

Checks before users return

Technical checks, then the business owner's test (RA-12)

[[checks]]

[[technical checks]]; then the Head of Logistics confirms that dispatch works (RA-12)

Fail back

How the system returns to its normal set-up (RR-25)

[[failback steps, window]]

Moved back to the usual servers in a planned evening window, after a count of the affected aisles.

Supplier

[[supplier, contact, hours, notice]]

Warehouse management system provider (DP-08): no recovery time in the contract (OG-06). [[contact and notice]]

If it is not back in time

The service's workaround and who starts it (RR-06)

[[workaround; who starts it]]

Dispatch from printed pick lists of the next day's orders, printed each evening, for up to [[24]] hours. Untried: its first trial is WT-2026-01 on 24 Oct 2026 (RR-26).

Where this runbook is kept

Copies reachable when the main systems are down (RR-24)

[[printed copy at …; offline copy at …]]

[[printed copy in the IT office and with the deputy; offline copy at …]]

Last reviewed

With the service's plan (RR-16)

[[YYYY-MM-DD, role]]

[[YYYY-MM-DD, role]]

ISO/IEC 27001:2022

Annex A 5.30 — ICT readiness for business continuity

The whole procedure: recovering the ICT a critical service needs within its objectives

ISO/IEC 27001:2022

Annex A 8.14 — Redundancy of information processing facilities

Recovery methods: failover to a second site or region; Annex 1

ISO/IEC 27001:2022

Annex A 8.13 — Information backup

Restore elsewhere from backup; the copy to restore from (RR-11)

ISO/IEC 27001:2022

Annex A 8.32 — Change management

Failing back, planned like a change (RR-25)

NIST CSF 2.0

RC.RP-02 — “Recovery actions are selected, scoped, prioritized, and performed”

The failover decision and the steps for each failure: recovery actions selected, put in order and performed

NIS2 — Directive (EU) 2022/2555

Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management”

The whole procedure: disaster recovery after failures that are not attacks

NIS2 — Implementing Regulation (EU) 2024/2690

Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers

Who the Implementing Regulation binds; for other entities its Annex is a guide only

NIS2 — Implementing Regulation (EU) 2024/2690

Annex, point 4.1.2 — “The relevant entities’ operations shall be restored according to the business continuity and disaster recovery plan.” The plan is based on the risk assessment (point 2.1) and includes, where appropriate: purpose, scope and audience; roles and responsibilities; key contacts and communication channels; conditions for plan activation and deactivation; order of recovery for operations; recovery plans for specific operations, including recovery objectives; required resources, including backups and redundancies; restoring and resuming activities from temporary measures

When this procedure starts and ends; roles; the recovery order (DS-04); failing back from the failover set-up

NIS2 — Implementing Regulation (EU) 2024/2690

Annex, point 4.2.4 — based on the risk assessment (point 2.1) and the business continuity plan, “sufficient availability of resources by at least partial redundancy” of network and information systems; assets, including facilities, equipment and supplies; personnel with the necessary responsibility, authority and competence; and appropriate communication channels

Recovery methods: failover to a second site or region; Annex 1: each system's route and the single routes without one

DORA — Regulation (EU) 2022/2554

Article 11(2) — the ICT business continuity policy is implemented “through dedicated, appropriate and documented arrangements, plans, procedures and mechanisms” aiming to ensure the continuity of critical or important functions; respond to and resolve all ICT-related incidents in a way that limits damage and prioritises the resumption of activities and recovery actions; activate without delay dedicated plans enabling containment and tailored response and recovery procedures (Article 12); estimate preliminary impacts, damages and losses; and set out communication and crisis management actions (Article 14) and reporting to competent authorities (Article 19)

The first assessment and the failover decision: recovery started without delay, and in order

DORA — Regulation (EU) 2022/2554

Article 12(2) — backup systems can be activated in accordance with the backup policies and the restoration and recovery procedures; “The activation of backup systems shall not jeopardise the security of the network and information systems or the availability, authenticity, integrity or confidentiality of data. Testing of the backup procedures and restoration and recovery procedures and methods shall be undertaken periodically.”

If an attack may be the cause: no second site or backup copy used until it can be trusted

DORA — Regulation (EU) 2022/2554

Article 12(3) — “When restoring backup data using own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system.” Those systems are securely protected from unauthorised access or ICT corruption and allow timely restoration

Restore elsewhere: restoring onto systems apart from the failed ones

DORA — Delegated Regulation (EU) 2024/1774

Article 26(1) — the ICT response and recovery plans take into account the BIA, specify activation and deactivation conditions, describe actions to ensure the availability, integrity, continuity and recovery of at least the ICT systems and services supporting critical or important functions, are “designed to meet the recovery objectives of the operations of the financial entities”, are documented and readily accessible in an emergency with roles clearly specified, “provide for both short-term and long-term recovery options, including partial systems recovery”, and “lay down the objectives of ICT response and recovery plans and the conditions to declare a successful execution of those plans”

When this procedure starts; ending recovery on the plan's criteria; partial and longer-term running through the workaround and an accepted alternate set-up

DORA — Delegated Regulation (EU) 2024/1774

Article 26(2) — the plans identify relevant scenarios, including severe business disruptions, and take into account at least: cyber-attacks and switchovers to redundant capacity, backups and redundant facilities; failure of a critical or important function, including insolvency or other failure of an ICT third-party service provider; partial or total failure of premises and data centres; substantial failure of ICT assets or communication infrastructure; non-availability of a critical number of staff; climate and environment-related events, natural disasters, pandemics and physical attacks; insider attacks; political and social instability; and widespread power outages

Scope: the failures DS-01 to DS-06, among them the loss of a data centre, of a network line and of a site, and switching to redundant capacity

DORA — Delegated Regulation (EU) 2024/1774

Article 26(3) — “Where the primary recovery measures may not be feasible in the short term because of costs, risks, logistics, or unforeseen circumstances, the ICT response and recovery plans referred to in paragraph 1 shall consider alternative options.”

The failover decision: another route when the repair is not in time, and the workaround

GDPR — Regulation (EU) 2016/679

Article 32(1)(c) — the security measures include, as appropriate, “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”

Running a failover or a restore elsewhere: restoring availability of and access to data after a technical incident

HIPAA — 45 CFR Parts 160 and 164

§ 164.308(a)(7)(ii)(B) — disaster recovery plan (required): “Establish (and implement as needed) procedures to restore any loss of data.”

Running a failover or a restore elsewhere: procedures to restore lost data; Annex 2: the runbook

AICPA Trust Services Criteria

SOC 2 A1.2, Additional Criteria for Availability

Recovery methods and runbooks; Annex 1: each system's recovery set-up and its tested time

AICPA Trust Services Criteria

SOC 2 CC7.5, System Operations

If an attack may be the cause: the hand-over to incident response and cyber recovery; ending recovery and the work after it

ISO 22301:2019 incl. Amd 1:2024

Clause 8.4.5 — Recovery (clause number and title only)

The whole procedure, from the failover decision to failback and the end of recovery

Disaster recovery

Recovering the systems a critical service needs after a failure that is not an attack: repair where they are, fail over, restore elsewhere, or the supplier's own recovery (RR-23, RR-24). After an attack, cyber recovery applies instead (RR-07).

End of recovery

The point at which the crisis lead declares every affected critical service back in normal operation, on the criteria the plan sets, and the records are complete (RR-17).

Failback

Returning a system from its failover set-up to its normal one, with the data written meanwhile copied back and reconciled (RR-25).

Failover

Switching a system to a second site, region or copy that runs it while the first is down (RR-23, RR-24).

Foundations

What every other recovery needs first: the sign-in directory, the core network and firewalls, the backup platform, endpoint protection and monitoring, and the emergency administrator accounts.

Maximum tolerable downtime (MTD)

The longest a critical service can be unavailable before the harm reaches Severe on the impact scale. Found by the business impact analysis (RR-03).

Recovery point

The copy a system is restored or failed over from. After a failure that is not an attack, it is the newest copy that passes its integrity check (RR-11). After an attack, the pack's definition applies: “The backup copy a system is restored from: the newest copy taken before the earliest sign of the attacker, checked for integrity and scanned before use (RR-12; P09 D3).”

Recovery point objective (RPO)

The most data, measured in time, the service can lose. The backup interval of every data set it needs must be no longer (RR-04, MX-03).

Recovery time objective (RTO)

The time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04).

Runbook

The written steps of one system's recovery method: the steps and the time each takes, who may run them, what must be in place first, how to fail back, and where the runbook is kept (RR-24).

Time left

The recovery time objective less the time since the decision to recover. The failover decision compares each estimate with it (RR-23).

Workaround

A way of running the service, or its most important part, without its systems for a set time, such as dispatch from printed pick lists. Owned and accepted by the business owner (RR-06).