Cyber Recovery Plan Template
Service-level recovery plan with priorities, dependencies, clean-build sources and decision authorities.
Available soon
- Format
- Word
- Size
- 77 KB
- Length
- 25 pages
- Version
- 1.0
- Updated
What's inside
- About this template
- Legal note
- How to use this template
- First hour of this plan
- The service and its objectives
- When this plan starts and stops
- Who does what
- What the service depends on
- The workaround
- Recovery order and steps
- Clean build sources
- Returning to service
- Suppliers
- Communications
- Testing and review
- Adapting this template
- Framework references
- Definitions
What changed
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
About this template
This template is the form in which [[Organisation Name]] writes the recovery plan for one critical service, as the Business Continuity & ICT Resilience Policy requires (RR-16). The plan takes the service from the moment it fails, or an attack reaches it, to the moment the crisis lead declares the end of recovery. Write one plan per critical service, and keep the eleven sections in their order.
Why a cyber recovery plan is different
Classic disaster recovery assumes the systems you recover with can be trusted: fail over to the second site, restore last night's backup, and carry on. A destructive cyberattack breaks that assumption. Replication copies the damage to the second site, the attacker may have been inside for weeks before the encryption, and the sign-in directory and administrator accounts you would recover with may be the attacker's. Recovery then starts with the foundations, rebuilt from sources you can trust, and every system is checked before it goes back.
So the plan works out this service's cyber recovery time, and shows it beside the objectives and the time the last test achieved.
What this plan leaves to incident response
The Security Incident Management pack (P09) runs the incident: containment, eradication, evidence, the backup check (Ransomware Response Playbook D3), restore or rebuild (D4), the recovery criteria (IM-10), the monitoring period and every decision right. This plan quotes them by ID and changes none of them. Its recovery work starts where P09's eradication ends (E5). A tabletop exercise under P10 is not a recovery test (RR-14).
Legal note
This document helps you plan and test recovery from a disruption, including a destructive cyberattack. It is not legal advice, and following it is not a statement that you comply with NIS2, DORA, the GDPR, ISO 22301 or any standard. Which continuity and recovery duties apply to you depends on your sector and your national law: confirm them with counsel or your supervisor.
The NIS2 Implementing Regulation (EU) 2024/2690 binds only the providers its Article 1 names, such as cloud computing, data centre and managed service providers. Other entities may use its Annex as good practice. DORA binds financial entities only. Its Articles 11 and 12 do not apply to the entities of its Article 16(1), which follow Article 16(1)(f) and Articles 39 and 40 of Delegated Regulation (EU) 2024/1774 instead. EXAMPLE: the distributor is an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply.
How to use this template
The plan opens with a one-page card for its first hour, then has eleven sections, PS-1 to PS-11. Each opens with a line naming its ID, what it holds and its rules, and a guidance box on what good looks like; delete the boxes before approval. Your entries are in [[double brackets]]; beside them, or in rows marked EXAMPLE, is the worked example.
EXAMPLE. The worked example is the pack's wholesale distributor with about 900 staff, three warehouses and an online ordering service, after its ransomware incident INC-2026-014 (P09). Its Head of Risk, who runs no system in scope, coordinated a resilience review from 14 Sep 2026 to 25 Sep 2026; objectives were agreed on 25 Sep 2026, and figures are as at 30 Sep 2026. The plan is for Online ordering (CS-01), owned by the Chief Operating Officer. Its status, Not achievable, is the furthest of the five critical services from its objectives.
First hour of this plan
Print this page and keep it with every copy of the plan. It is what the team does in the first hour after the plan is invoked, before anyone has time to read the rest.
Do this | Who | Rule | |
|---|---|---|---|
1 | Confirm the trigger. Check that an activation condition in this plan holds (PS-2). If none does, record why and stop here. | Crisis lead EXAMPLE: Chief Operating Officer | RR-17; RA-04 |
2 | Invoke and log. Invoke the plan and note the time in the crisis log. The recovery time objective counts from the decision to recover the service, so record that decision and its time too. | Crisis lead EXAMPLE: Chief Operating Officer | RA-04; RA-16 |
3 | Call the team without the main systems. Reach the roles in PS-3 from the offline contact list, on the out-of-band channel. Call the deputy if a role holder is not reached within 30 minutes, the time P09 gives for reaching the executive incident lead in a Severity 1 incident. | Resilience coordinator EXAMPLE: Head of Risk | RR-16; RR-19 |
4 | Start the workaround. Start the workaround (PS-5), and tell the people who run it how long it may need to last. | Business owner EXAMPLE: [[a manager the Chief Operating Officer names]] starts the workaround, because the Chief Operating Officer leads the crisis (RR-19) | RR-06; RA-04 |
5 | Ask whether it is an attack. Ask the incident manager whether a cyberattack is the cause, or may be. If yes or not known, follow the cyber route: P09 runs containment, and nothing is restored, failed over or reconnected until the incident manager agrees. | Incident manager EXAMPLE: Information Security Manager | RR-07; RA-05 |
6 | Warn the suppliers. Tell each supplier in PS-9 what has happened and what you need from it, with P09's supplier notice (CT-05). | Supplier liaison EXAMPLE: Procurement Manager | RR-10; RA-14 |
7 | Tell staff and customers. Send the staff and customer messages in PS-10, from P09's approved templates. | Communications lead EXAMPLE: Head of Marketing and Communications | RA-15; P09 IM-09 |
8 | State the recovery order. Read out the planned recovery order and target times from PS-6. They are confirmed, or changed with a recorded reason, when recovery starts (P09 V1). | Crisis lead EXAMPLE: Chief Operating Officer | RR-08; RA-08 |
9 | Set the next update. Set the time of the next crisis team update and who attends. Record every decision so far in the crisis log. | Crisis lead EXAMPLE: Chief Operating Officer | RA-16 |
Never in the first hour: restore last night's backup, fail over to a second site, or reconnect anything while an attack is possible (RR-07, RR-12). Never decide on a ransom: only the board or its equivalent decides that (P09).
The service and its objectives
PS-1 · What the service does, its business owner, MTD, RTO and RPO, and its status · Rules RR-02, RR-04
This section says what the service is and how long it can be without its systems: its maximum tolerable downtime (MTD), recovery time objective (RTO) and recovery point objective (RPO), defined at the end. Everything else in the plan is measured against them.
Guidance — delete before approval
What good looks like. The business owner, not IT, has agreed the objectives, on a recorded date. The MTD comes from the business impact analysis, the RTO is shorter, and the RPO says why that much data loss can be borne. The status is copied from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), with the last test's time and the cyber recovery time beside the objectives.
The rules behind it. RR-02: “Every critical service has a named business owner, who sets and agrees its objectives. IT proposes what is achievable; the business owner decides what is needed. Objectives set by IT alone are not agreed.”
RR-04: “Each critical service has a recovery time objective shorter than its maximum tolerable downtime, and a recovery point objective. The service's dependencies must recover within its recovery time, and the backup interval of each data set it needs must be no longer than its recovery point.”
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Service | [[name and ID, as in the objectives matrix]] | Online ordering (CS-01) |
What it does and for whom | [[what users or customers get from it]] | [[customers place and track orders online, day and night]] |
Business owner and deputy | [[role]]; [[deputy]] | Chief Operating Officer; [[deputy for the service]] |
Why it is critical the analysis's driver | [[impact area, and when harm reaches Severe]] | Service: most orders arrive through it (P03); stopped for more than 2 days is Severe (P05 R-01) |
Maximum tolerable downtime | [[hours, from the analysis below]] | 48 hours (2 days) |
Recovery time objective | [[hours]] | 24 hours (1 day) |
Recovery point objective and why that loss can be borne | [[hours]]; [[how lost data is found again]] | 24 hours (1 day). Orders since the last nightly backup are keyed again from the confirmations customers hold |
Time the last test achieved | [[hours; test ID]] | 96 hours (4 days) (RV-2026-02, 20 May 2026) |
Cyber recovery time | [[hours, from PS-4]] | 108 hours: foundations 12, then the platform 96 |
Status from the objectives matrix | [[Achievable / Needs its workaround / Not proven / Not achievable]] | Not achievable. Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD. |
Objectives agreed and next review | [[YYYY-MM-DD]]; [[YYYY-MM-DD]] | 25 Sep 2026; by 25 Sep 2027 |
Business impact analysis
The analysis rates the service's worst harm, across the risk register's impact areas, at each of 4, 8, 24, 48, 72, 120 and 168 hours out. The MTD is the first point at which any area reaches Severe (RR-03).
Hours out | 4 | 8 | 24 | 48 | 72 | 120 | 168 |
|---|---|---|---|---|---|---|---|
Your service | [[level]] | [[level]] | [[level]] | [[level]] | [[level]] | [[level]] | [[level]] |
EXAMPLE: Online ordering | 2 Moderate | 2 Moderate | 3 Major | 4 Severe | 4 Severe | 4 Severe | 4 Severe |
EXAMPLE. Harm first reaches Severe at 48 hours, so the MTD is 48 hours (2 days). That matches the risk register's R-01, “Ransomware takes online ordering offline for more than 2 days” (P05). The last test took 96 hours, restoring a backup with trusted tools; after a destructive attack recovery would take about 108 hours, because the foundations come first. Both are beyond the MTD.
When this plan starts and stops
PS-2 · The conditions to invoke and to stand down, and who decides · Rule RR-17
A plan nobody is sure they may start is started late. A plan with no end runs on in crisis mode long after the service is back. This section sets both conditions in advance, and who decides each.
Guidance — delete before approval
What good looks like. Conditions someone can check at 3 a.m. without judgement: a time, a P09 severity, a named dependency. One person decides, with a named deputy. The crisis lead stands the plan down against a fixed list, never because things feel normal.
The rule behind it. RR-17: “The crisis lead invokes a service's continuity plan, sets the recovery order, and declares the end of recovery on the plan's criteria. Every other decision right during an incident is P09's: the incident manager isolates and decides restore or rebuild; the executive incident lead stops customer-facing services; only the board or its equivalent decides on a ransom.”
DORA's Delegated Regulation asks financial entities' plans to specify activation and deactivation conditions and when the plan has succeeded (Article 26(1)); the NIS2 Implementing Regulation lists activation and deactivation conditions for the providers its Article 1 names (Annex point 4.1.2).
When the plan starts
The crisis lead invokes the plan when any one of these holds (RA-04). Adjust them to the service, but keep each one checkable:
- The service is unavailable, or is expected to be, for longer than [[a set time, e.g. half its recovery time objective]].
- P09 declares a Severity 1 or 2 incident that affects the service, one of its systems, or the foundations.
- A dependency in PS-4 fails and will not be back within the service's recovery time objective.
- A supplier in PS-9 tells you it has invoked its own continuity or recovery plan for what it runs for the service.
- Data the service needs is found corrupted, encrypted or deleted, even while the service still runs.
If the crisis lead cannot be reached within 30 minutes, P09's time for reaching the executive incident lead in a Severity 1 incident, the deputy decides. Invoking early costs little; waiting for certainty spends part of the RTO.
When a cyberattack is the cause
The plan still starts, and P09 runs the incident alongside it. The workaround, supplier warnings and messages start at once. The assessment (R1) waits until P09 has contained the incident, and the rebuild (R3) until P09 confirms eradication (E5). Nothing is restored, failed over or reconnected before the incident manager agrees (RA-05, RA-09).
When the plan stops
The crisis lead declares the end of recovery (RA-17) when every one of these holds. Together they are this plan's conditions for successful execution:
Condition | Rule or gate | |
|---|---|---|
1 | The service runs normally for its users, with the workaround ended. | RR-18 |
2 | Every system behind it has passed the clean-room checklist's mandatory gates, and the incident manager has confirmed P09's recovery criteria. | CG-20; P09 IM-10 |
3 | The business owner has tested the service and confirmed in writing that it works. | CG-19; P09 V4 |
4 | The data lost since the recovery point is recorded against the recovery point objective, and its recovery from other sources is complete or assigned. | CG-15 |
5 | The backlog the workaround built up is entered and reconciled. | CG-17 |
6 | P09's monitoring period has started, and the restored systems' backups have run and been checked. | CG-22 |
7 | The crisis log is complete, and the gaps and lessons are recorded for the plan's review. | RR-15; RR-16 |
The resilience coordinator prepares the declaration; the incident manager and the business owner are consulted; the approver and the communications lead are told (RA-17). If the plan was invoked and the trigger turns out not to hold, the crisis lead stands it down early and records why.
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Started and stopped by and deputy | [[role]]; [[role]] | Chief Operating Officer; Chief Financial Officer |
Starts when any one holds | [[your conditions, each checkable]] | Online ordering is down, or expected to be, for more than [[a set time, e.g. 4 hours]]; P09 declares a Severity 1 or 2 incident affecting the ordering platform, its hosting or the foundations; the cloud hosting provider, backup service provider or network connectivity provider invokes its own recovery plan; or order data is found corrupted or encrypted |
Stops when every one holds | [[the conditions above, adjusted]] | The seven conditions above, with the telephone and email orders entered and reconciled |
Who does what
PS-3 · Roles with deputies and contacts, reached without the main systems · Rule RR-19
Roles, not people, carry the plan, because people change and most outages start at night or at a weekend. Each role has a deputy with the same authority while acting. The contacts must work when email, the directory and the phone system are down.
Guidance — delete before approval
What good looks like. Every role has a holder and a deputy, as in the Crisis & Recovery Responsibility Matrix. No one is the first holder of two roles that act in the same hour. Every number is answered outside working hours, and every holder and deputy has taken part in an exercise.
The rule behind it. RR-19: “Every crisis and recovery role has a named deputy, and no one is the first holder of two roles that must act in the same hour. Role holders and deputies take part in an exercise at least as often as P10 EX-07 sets.” P10's EX-07: “Every role holder in the incident response plan, and every deputy, must take part in an exercise at least every [[24]] months.”
The roles of this plan; the Crisis & Recovery Responsibility Matrix sets what each does.
Role | Holder | Deputy | 24/7 contacts | EXAMPLE: Online ordering (CS-01) |
|---|---|---|---|---|
Crisis lead | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Chief Operating Officer; deputy Chief Financial Officer |
Incident manager | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Information Security Manager; deputy Head of Information Security |
Technical recovery lead | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Head of IT; deputy IT Operations Manager |
Business owner | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Chief Operating Officer; deputy [[deputy for the service]] |
Resilience coordinator | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Head of Risk; deputy Quality and Compliance Manager |
Communications lead | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Head of Marketing and Communications; deputy none named (RRM-07) |
Supplier liaison | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Procurement Manager; deputy Finance Manager |
Head of Information Security | [[role]] | [[role]] | [[holder's]] [[deputy's]] | Head of Information Security; deputy Information Security Manager |
EXAMPLE. Two things stand out. The communications lead has no deputy, which the readiness dashboard names (RRM-07). And the Chief Operating Officer is both the crisis lead and the business owner of Online ordering, and both roles act in the first hour. [[a manager the Chief Operating Officer names]] starts the workaround, because the Chief Operating Officer leads the crisis (RR-19).
Decision authorities
Who decides what during a recovery, from the Crisis & Recovery Responsibility Matrix. The decisions to isolate, to stop a customer-facing service and on a ransom are P09's, quoted as P09 sets them; the others are this pack's.
Decision | Decides | Does it | Source |
|---|---|---|---|
RA-03 Declare a crisis and call the crisis team | Crisis lead | Crisis lead | RR-17 |
RA-04 Invoke a service's continuity plan and start its workaround | Crisis lead | Business owner | RR-17 |
RA-05 Isolate a system, site or account P09: “Incident manager.” | Incident manager | Technical recovery lead | P09 |
RA-06 Stop a customer-facing service P09: “Executive incident lead.” | Crisis lead | Incident manager | P09 |
RA-07 Pay a ransom or extortion demand P09: “Only the board or its equivalent.” | Approver | Crisis lead | P09 |
RA-08 Set the recovery order and target times | Crisis lead | Resilience coordinator | RR-08; P09 V1 |
RA-09 Decide restore or rebuild for each system | Incident manager | Technical recovery lead | RR-12; P09 D4 |
RA-10 Choose each system's recovery point | Incident manager | Technical recovery lead | RR-12; P09 D3 |
RA-13 Approve a system's return to production | Incident manager | Technical recovery lead | RR-18; P09 IM-10 |
RA-17 Declare the end of recovery | Crisis lead | Resilience coordinator | RR-17 |
P09 names the executive incident lead as the one who stops a customer-facing service; in a cyber incident that is the crisis lead (RA-06). On a ransom, P09 adds: “Never before legal advice (including sanctions checks), the insurer's view and a report to law enforcement. The plan assumes we do not pay.” (RA-07)
Keeping this plan reachable in an outage
RR-16 asks that “a copy of every plan and of the contact lists can be reached when the main systems are down”. The mistake to avoid: 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).
Copy | Where it is kept | Who holds it | Last checked |
|---|---|---|---|
Printed copy | [[e.g. sealed folder in the crisis lead's home office and at the second warehouse]] | [[crisis lead and deputy]] | [[YYYY-MM-DD]] |
Offline electronic copy | [[e.g. encrypted USB drive or a tablet never joined to the production directory]] | [[technical recovery lead and deputy]] | [[YYYY-MM-DD]] |
Copy outside your own systems | [[e.g. a document store with sign-in that does not use the production directory]] | [[resilience coordinator]] | [[YYYY-MM-DD]] |
Each copy holds the whole plan, the first-hour card and the contact lists, at the current version, and every role holder and deputy keeps the contact list on their phone. At least one copy opens without the sign-in directory, email or file shares. Check every copy [[every quarter]] and at every recovery test. The out-of-band channel is agreed in advance, as P09 does for the incident team. EXAMPLE: the worked example does not say where the distributor keeps its copies, so its rows stay as placeholders.
What the service depends on
PS-4 · Dependencies with their recovery times, single points of failure and alternatives · Rule RR-09
A service is only as quick to recover as its slowest dependency. This section lists everything the service needs to run, with the time each takes to come back and where that time comes from: a test, a contract or an estimate. Copy it from the Resilience Dependency Register.
Guidance — delete before approval
What good looks like. Each dependency has a recovery time and its basis, or says plainly that none is known. The cyber recovery time is worked out from the list, not guessed.
The rule behind it. RR-09: “Every critical service has its dependencies recorded: systems, suppliers, data, people, sites and the foundations. Each has a recovery time; a single point of failure is marked with its alternative, or as having none. The register is reviewed at least every [[12]] months and when a dependency changes.”
The 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. After a destructive attack they come back first, rebuilt from trusted sources, because every other system needs them and the attacker may control them. EXAMPLE: the distributor estimates 12 hours for the set, the Ransomware Response Playbook's example target; it has never rebuilt them as a whole.
Record who rebuilds each part: [[part: who rebuilds it]]. EXAMPLE: the managed IT service provider (P06 SUP-001) rebuilds the sign-in directory and the core network and firewalls; the backup service provider (P06 SUP-011) rebuilds the backup platform; the security monitoring provider (P06 SUP-006) rebuilds the endpoint protection and monitoring; the Head of IT rebuilds the emergency administrator accounts (P14 PA-12).
The service's dependencies
Rows marked EXAMPLE are the distributor's for Online ordering; add your own below them.
ID | Dependency and kind | Recovery time | Basis | Single point of failure | Alternative |
|---|---|---|---|---|---|
EXAMPLE DP-01 | Foundations: sign-in directory, network, backup platform, endpoint protection Foundations | 12 hours | Estimate | Yes | None: every in-house system needs them first |
EXAMPLE DP-02 | Online ordering platform System | 96 hours | Tested 20 May 2026: restored from backup in 4 days (P05 R-01) | Yes | None |
EXAMPLE DP-03 | Cloud hosting provider Supplier | 24 hours | Contract: hosting restored within 24 hours | Yes | None within the RTO |
EXAMPLE DP-04 | Backup service provider Supplier | Not known | Not in the contract; assessment planned 3 Nov 2026 (P06) | Yes | None |
EXAMPLE DP-05 | Orders and customer accounts Data | Backed up every 24 hours | Nightly backup (P05 R-01) | No | Customers' order confirmations |
EXAMPLE DP-06 | Ordering platform team People | Not applicable | Not a recovery time | Yes | Managed IT service provider's engineers, with the plan's runbook |
EXAMPLE DP-11 | Network connectivity provider Supplier | 12 hours | Contract: a failed line restored within 12 hours | Yes | None: a second line from another provider is not in place |
[[DP-xx]] | [[name]] [[System / Supplier / Data / People / Site / Foundations]] | [[hours, or Not known]] | [[test, contract or estimate, with its date]] | [[Yes / No]] | [[alternative, or None]] |
The cyber recovery time
The time a service would take to come back after a destructive attack: the foundations' rebuild, if the service depends on them, plus the slowest of the systems the organisation restores itself (MX-05). Suppliers recover in parallel, and their times are checked against their contracts in PS-9.
EXAMPLE. The foundations take 12 hours; the only system the distributor restores itself, the ordering platform, took 96 hours in May. The cyber recovery time is 12 + 96 = 108 hours, against an RTO of 24 hours and an MTD of 48 hours. Even a platform rebuilt to recover in 24 hours would wait 12 hours for the foundations: the RTO assumes they are trusted.
The checks on this service's objectives
The Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) runs seven checks, MX-01 to MX-07, on every critical service. Copy the ones that fail: each is an objective gap (RR-15), listed in PS-11. EXAMPLE: as at 30 Sep 2026, Online ordering passes MX-01, MX-03 and MX-07, and fails the other four:
Check failed | EXAMPLE, as at 30 Sep 2026 |
|---|---|
MX-02 Dependencies recover in time | Online ordering platform: 96 h |
MX-04 Supplier recovery times known and in time | Backup service provider: not known |
MX-05 Cyber recovery within the objective | 108 h after an attack |
MX-06 Tested within objective | 20 May 2026: 96 h |
The workaround
PS-5 · How the service runs without its systems, for how long, who starts it, and when it was last tried · Rule RR-06
A workaround buys time. Where the service cannot be back within its RTO, as after most destructive attacks, the workaround keeps the harm below Severe until it is.
Guidance — delete before approval
What good looks like. The business owner has written, accepted and tried the workaround. It says how much of the service it keeps, how long it can run before harm reaches Severe, who starts it, and what it needs. Those needs are dependencies too: a workaround that relies on a system the attack also takes down is no workaround.
The rule behind it. RR-06: “Where a service cannot be back within its recovery time, its business owner records a workaround that keeps the harm below Severe until the service returns, and who starts it. A workaround that has never been tried is recorded as untried.”
Try it in a drill or on a quiet day, with the people who would run it. Trying a workaround is not a recovery test (RR-14), but it is the only way to know the phones, the forms and the people are there.
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
What it is | [[how the service runs without its systems]] | Telephone and email orders keyed by the customer contact team into the ERP, about [[a fifth]] of a normal day's orders |
How long it can run before harm reaches Severe | [[hours or days]] | [[how long the workaround keeps harm below Severe]]; without it, harm is Severe at 48 hours |
Started by on the crisis lead's invocation | [[role]] | [[a manager the Chief Operating Officer names]] starts the workaround, because the Chief Operating Officer leads the crisis (RR-19) |
Run by | [[team]] | The customer contact team |
What it needs and whether an attack could take it down | [[people, systems, places]] | The contact team, their phones and email, and the ERP; [[whether an attack on the foundations would take those down too]] |
How it ends | [[who switches back (PS-8)]] | Orders switch back to the platform at a set time; the backlog is entered and reconciled |
Last tried | [[YYYY-MM-DD, how, what was learned; or Untried]] | Untried. [[date of the first trial]] |
Recovery order and steps
PS-6 · Foundations, then systems in order, each with restore or rebuild, the build source and the recovery point · Rules RR-08, RR-12
This section is the recovery itself: what comes back first, how each system comes back, and from which copy of its data. The order is set now, in calm, and confirmed or changed by the crisis lead when recovery starts.
Guidance — delete before approval
What good looks like. The foundations come first. Each system has a planned route, knowing that P09 D4 decides it on the day, a named build source and a stated way of choosing the recovery point. The target times fit within the RTO, or the plan says plainly that they do not.
The rules behind it. RR-08: “Recovery restores the foundations first, then critical services in order of recovery time, shortest first, unless the crisis lead sets another order and records why. The order and the target times are set in advance and confirmed when recovery starts (P09 V1).”
RR-12: “After an attack, each system is restored from the newest copy taken before the earliest sign of the attacker that passes its integrity check and a scan, never from a copy the attacker could have reached without checking it (P09 D3). Whether a system is restored or rebuilt is decided under P09 D4.”
The Cyber Recovery Operating Procedure runs a recovery in seven stages: R1 assess, R2 isolate and prepare, R3 rebuild clean, R4 restore data, R5 validate, R6 return to service and R7 stand down. This plan supplies what they need for this service: the order, the build sources, the recovery points and the business test.
Restore or rebuild
P09's incident manager decides for each system whether it is restored or rebuilt (P09 D4, RA-09), after the backup check (P09 D3). The plan records a planned route and the build source for both, so neither decision waits for a search:
What P09's checks find | What happens to the system |
|---|---|
No clean copy (D3) | Rebuild from a trusted source and recover the data from other sources |
A clean copy, but the attacker's route or changes are not fully known, or it had administrator rights on the system (D4) | Rebuild from a trusted source, then restore only the data |
A clean copy, the route and every change known, no administrator rights (D4) | Restore onto the patched system, change its credentials and check it before it reconnects |
Choosing the recovery point
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). It is last night's copy only if last night was before the attacker arrived. The technical recovery lead proposes it and the incident manager chooses it (RA-10); the plan states where the copies are and how far back they go. If no copy predates the attacker, more data is lost than the RPO allows: record that risk in advance.
The recovery order
Foundations first, then the service's systems. Suppliers' recovery runs alongside and is not added to the cyber recovery time. Rows marked EXAMPLE are Online ordering's:
Order | System or dependency | Planned route | Build source | Recovery point | Target time | Who |
|---|---|---|---|---|---|---|
EXAMPLE 1 | Foundations (DP-01) | Rebuild in the recovery environment | [[Clean build sources rows]] | [[directory recovery copy, if clean]] | 12 hours (estimate) | Technical recovery lead |
EXAMPLE Alongside | Cloud hosting provider (SUP-002); Backup service provider (SUP-011); Network connectivity provider (SUP-014) | The supplier's own recovery | The supplier's | The supplier's | 24 hours; Not known; 12 hours | Supplier liaison |
EXAMPLE 2 | Online ordering platform (DP-02) | Planned: [[restore, or rebuild then restore data]]; P09 D4 decides | [[Clean build sources rows]] | Orders and customer accounts: the newest nightly copy before the earliest sign of the attacker, checked and scanned | 96 hours as tested; objective 24 hours | Technical recovery lead |
EXAMPLE 3 | The service as a whole | Business test, then staged return | Not applicable | Not applicable | Within the RTO of 24 hours | Business owner |
[[n]] | [[system]] | [[restore, or rebuild then restore data]] | [[source]] | [[where the copies are; how far back]] | [[hours]] | [[role]] |
EXAMPLE. Nothing in this order brings Online ordering back within 24 hours today. P05's Risk Treatment Plan carries the fix as TA-01, “Rebuild the ordering platform's recovery so it can be restored within 24 hours”, due 15 Dec 2026; the plan is rewritten when it is done.
Short-term, partial and long-term options
For financial entities, DORA's Delegated Regulation asks that response and recovery plans provide for both short-term and long-term recovery options, including partial systems recovery (Article 26(1)), and consider alternative options where the primary recovery measures may not be feasible in the short term because of costs, risks, logistics or unforeseen circumstances (Article 26(3)).
Option | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Short term Keep the most important part running while the systems are down. | [[e.g. the workaround]] | The telephone and email workaround, untried, for [[as long as it keeps harm below Severe]] |
Partial recovery Bring part of the service back first: one customer group, channel or site, or the core transaction. | [[which part first]] | [[e.g. order taking for account customers first, then card payments, then promotions and reports]] |
Full recovery The primary measure: the service back on rebuilt or restored systems. | [[the recovery order]] | The recovery order above: the foundations, then the platform, its data from the recovery point |
Long term If the primary measure is not feasible soon: another platform, supplier or site, or a lasting manual process. | [[the alternative]] | The rebuilt recovery set-up of P05 TA-01, once tested (RV-2027-04); if the platform cannot be rebuilt in time, [[an alternative, e.g. a standby platform at another hosting provider]] |
Clean build sources
PS-7 · Where each trusted image, baseline and installer is kept, with its hash and who can reach it · Rule RR-13
After a destructive attack, nothing on the affected network can be trusted to rebuild from: not the image library on the file share, nor the deployment server. This section lists the sources that can be, where they are kept, and how anyone knows they are unchanged.
Guidance — delete before approval
What good looks like. Every source a rebuild needs is listed and kept where the production administrator accounts cannot reach it, with a recorded hash, a named custodian and the date it was last checked. Nobody has to work out on the day where the installer is.
The rule behind it. RR-13: “After a destructive attack, systems are rebuilt and restored in an isolated recovery environment, from trusted build sources, with new administrator credentials, and pass every mandatory gate of the clean-room checklist before they reconnect to production.”
The clean-room checklist checks each source at the rebuild. CG-06: “Every build source is trusted: an offline golden image whose hash matches the recorded one, or vendor media downloaded fresh and hash-checked.” CG-07: “Configuration is rebuilt from a stored, reviewed baseline, not copied from the affected system.”
A plan's build sources usually include the rows below. Delete those the service does not need:
Source | Where it is kept | Hash recorded | Who can reach it | Last checked |
|---|---|---|---|---|
Golden images of each server and of administrator workstations | [[e.g. offline media in the safe]] | [[algorithm; where kept]] | [[two named roles]] | [[YYYY-MM-DD]] |
Installation media and installers for the operating systems and applications, with their vendors' hashes | ||||
Configuration baselines and any infrastructure or deployment code, at a reviewed version | ||||
The application's own release package or code repository, at the release in production | ||||
Licence keys, certificates and the secrets needed to install, held apart from production | ||||
The sign-in directory's own recovery copy, where one exists |
EXAMPLE. The worked example does not give the distributor's build sources. The Online ordering plan lists here the platform's images, application release, configuration baseline and certificates. Until it does, gate CG-06 cannot be passed quickly on the day.
Returning to service
PS-8 · The gates, the business test, the staged reconnection and the backlog catch-up · Rule RR-18
A recovered system that goes back too early can bring the attacker back with it. This section says what must be true before the service returns to its users, how it returns, and how the workaround's backlog is caught up.
Guidance — delete before approval
What good looks like. No system reconnects until the gates pass and the incident manager confirms P09's criteria. The business owner tests the service against a written list, not a quick look. The return is staged, and the backlog has an owner and an end.
The rule behind it. RR-18: “A system returns to production only when the clean-room checklist's mandatory gates and P09's recovery criteria are met, and its business owner has tested the service and confirmed it works (P09 IM-10, V4). The checks continue through P09's monitoring period.”
The gates before return
Each system behind the service passes the clean-room checklist's last gates, CG-16 to CG-22: a sweep for the attack's indicators and persistence (CG-16), data reconciled (CG-17), interfaces re-established with new credentials where there are any (CG-18), the business test (CG-19), P09's recovery criteria confirmed (CG-20), a staged reconnection (CG-21), and the monitoring period started with backups checked (CG-22). The incident manager confirms P09's five recovery criteria (IM-10) as P09 sets them, without restating them here.
The business test
The business owner, or someone they name who uses the service daily, runs these checks and signs that the service works (CG-19, P09 V4). Write them now, so they are the same every time:
- [[e.g. sign in as a customer, find three products, place an order and receive its confirmation]]
- [[e.g. check that the order reaches dispatch with the right stock, price and address]]
- [[e.g. check that the service's interfaces to payments and to suppliers work with their new credentials]]
Staged return and catching up
The service reconnects in stages, one part or one group of users at a time, with monitoring watching for the attack's indicators (CG-21, P09 V5). Then the backlog is caught up, in this order:
- Freeze the workaround's intake at a set time, and switch new orders back to the service (RR-18).
- Enter what the workaround took into the restored service, and reconcile the service's data with its other sources, explaining every difference (CG-17).
- Recover the data lost since the recovery point from the other sources the plan names, and record what could not be found (CG-15).
- Tell the business owner when the backlog is clear; this is one of the conditions for standing down (RR-17).
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Business test run by and signed off by | [[role]]; [[business owner]] | [[a customer contact team member who uses the platform daily]]; Chief Operating Officer |
Stages of return | [[e.g. internal users, then one group, then all]] | [[e.g. internal test orders, then account customers, then all customers]] |
Data lost since the recovery point recovered from | [[other sources]] | Orders since the last nightly backup are keyed again from the confirmations customers hold |
Backlog entered by and reconciled with | [[team]]; [[systems]] | The customer contact team; [[payments and dispatch]] |
Suppliers
PS-9 · Each supplier's contracted recovery time, contact and notice · Rule RR-10
Suppliers recover on their own timetable. This section names each one the service needs, the recovery time its contract gives, and how to reach it when your own systems are down.
Guidance — delete before approval
What good looks like. Every supplier that runs something the service needs has a contracted recovery time no longer than the RTO, and a 24/7 contact not reached through your own email. Where the contract is silent or too slow, the plan says so, and the gap has an owner.
The rule behind it. RR-10: “A supplier that runs a system a critical service needs has a recovery time in its contract no longer than that service's recovery time, and is named in the service's plan with a contact and the notice it must give (P06 TP-10). Where the contract gives no time, or a longer one, the gap is recorded (MX-04).”
P06's TP-10: “Critical suppliers must be part of incident response and continuity plans, with named contacts and notification duties.” The clause “Business continuity and disaster recovery” (CL-10, in the Supplier Contract Security Clause Library) is where the recovery time goes into the contract.
Rows marked EXAMPLE are the suppliers Online ordering needs, against its RTO of 24 hours:
Supplier | What the contract gives | Contracted recovery time | Against the RTO | 24/7 contact | Notice it must give |
|---|---|---|---|---|---|
EXAMPLE Cloud hosting provider SUP-002 | Contract: hosting restored within 24 hours | 24 hours | Within | [[name, number]] | [[notice in the contract]] |
EXAMPLE Backup service provider SUP-011 | Not in the contract; assessment planned 3 Nov 2026 (P06) | Not known | Not known: a gap (MX-04) | [[name, number]] | [[notice in the contract]] |
EXAMPLE Network connectivity provider SUP-014 | Contract: a failed line restored within 12 hours | 12 hours | Within | [[name, number]] | [[notice in the contract]] |
[[name and reference]] | [[what it runs for the service]] | [[hours, or Not known]] | [[Within / Longer / Not known]] | [[name, number]] | [[e.g. within 24 hours]] |
EXAMPLE. The hosting and network providers' recovery times are within the 24 hours. The backup service provider holds the copies the platform is restored from, and its contract gives no restore time: gap OG-02, to be closed at the supplier's assessment on 3 Nov 2026. The foundations are rebuilt with the managed IT service provider (SUP-001), the backup service provider (SUP-011) and the security monitoring provider (SUP-006); their contacts belong in this table too.
Communications
PS-10 · Who is told what, when, from which template (P09) · Rule RR-17
People who are not told make their own arrangements: customers go elsewhere, staff improvise, suppliers wait. This section says who is told what, when, and from which template. The templates are P09's, in its Incident Communications Template Set; this plan names them by ID and changes none of them.
Guidance — delete before approval
What good looks like. Each audience has a message, a moment and a sender. Customer messages say how to use the workaround. Updates go out at a set rhythm, even when nothing is new. Reports to authorities stay with P09's reporting screen (IM-06) and are not repeated here.
The rule behind it. RR-17: “The crisis lead invokes a service's continuity plan, sets the recovery order, and declares the end of recovery on the plan's criteria. Every other decision right during an incident is P09's: the incident manager isolates and decides restore or rebuild; the executive incident lead stops customer-facing services; only the board or its equivalent decides on a ransom.” The communications lead sends messages from approved templates (RA-15, P09 IM-09).
Who | What they are told | When | Template | Sent by |
|---|---|---|---|---|
Crisis team, executive and board | What is down, the workaround, the recovery order and the next update | At invocation and at every update | P09 CT-02 | Resilience coordinator |
Staff | What is affected, what to do instead, and when they will hear next | When staff notice the effects | P09 CT-03 | Communications lead |
Customers | How to keep using the service through the workaround, and when they will hear next | When their service is affected | P09 CT-04 | Communications lead |
Suppliers in this plan | What happened, what you need from them, and by when | At invocation, and when their part starts | P09 CT-05 | Supplier liaison |
Press and public | A holding statement, only if the outage is or is about to be public | When needed | P09 CT-09 | Communications lead |
Everyone told earlier | The service is back, what changes for them, and thanks | At the end of recovery | P09 CT-10 | Communications lead |
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Customers told | [[channel, e.g. website banner, email to account customers]] | From CT-04: online ordering is down; telephone and email orders are taken by the customer contact team. [[channel]] |
Suppliers told | [[which suppliers]] | From CT-05: the cloud hosting provider, the backup service provider and the network connectivity provider |
Sent by | [[role; deputy]] | Head of Marketing and Communications; no deputy is named (RRM-07), so the plan names [[a stand-in]] |
Testing and review
PS-11 · Last test, result against the objectives, next test, last review, and lessons written in · Rules RR-14, RR-16
An untested plan is a hypothesis. This section records the last recovery test and what it showed, the next one, the plan's reviews, and the gaps still open.
Guidance — delete before approval
What good looks like. The last test recovered the service or its systems, and measured the time against the RTO and the data lost against the RPO. The next test is booked before it falls due. Lessons from each test are written into the plan, and the plan is reviewed after every test and every real recovery.
The rules behind it. RR-14: “The recovery of every critical service is tested at least every [[12]] months, and after a significant change to it. A service never tested is tested within [[6]] months of its objectives first being agreed under this policy; agreeing them again does not move that date. A test recovers the service or its systems, restores its data, and records the time achieved and the data lost against the objectives. Where a supplier runs the systems, the test is the supplier's own recovery test, with its results shared and checked against the objectives. An exercise under P10, a tabletop or a drill, is not a recovery test.”
RR-16: “Each critical service has a recovery plan, reviewed at least every [[12]] months, after every test and real recovery, and after a significant incident or change. Lessons from tests are written into the plan. A copy of every plan and of the contact lists can be reached when the main systems are down.”
Field | Your plan | EXAMPLE: Online ordering (CS-01) |
|---|---|---|
Last recovery test | [[ID, date and kind]] | RV-2026-02, 20 May 2026, full restore: the ordering platform restored from its nightly backup into the hosting provider's spare environment |
Time achieved and data lost against the RTO and RPO | [[hours; within or missed]] | 96 hours (4 days): missed the RTO of 24 hours, beyond the MTD of 48 hours. 24 hours of data lost: within the RPO |
Cyber recovery time measured or estimated | [[hours; how known]] | 108 hours, estimated: the foundations have never been rebuilt as a whole |
Next test due under RR-14, and planned | [[due date]]; [[ID, date, kind]] | Due by 20 May 2027. Planned: RV-2027-04, 10 Mar 2027, full restore: the ordering platform recovered on the rebuilt recovery set-up (P05 TA-01), against its 24 hours |
Plan last reviewed and why | [[YYYY-MM-DD; trigger]] | 25 Sep 2026, in the review after INC-2026-014 |
Next review due RR-16 | [[12 months on, or sooner after a test]] | 25 Sep 2027, or sooner, after RV-2027-04 |
Lessons written in | [[what changed after the last test or recovery]] | The four-day restore is gap OG-01, and the cyber recovery time is now worked out in PS-4 |
EXAMPLE. RV-2027-04 falls after TA-01 is due (15 Dec 2026), so it tests the rebuilt set-up, and before 20 May 2027, when the next test falls due. November and December are the peak season (P10): no recovery test touches online ordering, dispatch or payments then.
P10's exercises test the people and the decisions; this section never counts them as recovery tests (RR-14). A review that changes nothing is still recorded in the revision history.
Open objective gaps
RR-15: “Every failed check in the objectives matrix, and every objective a test or a real recovery missed, is an objective gap. Its owner agrees the change that closes it within [[10]] working days, with a due date; the service's risk owner is told and the risk is reassessed (P05 RM-10).”
Gap | Checks failed | Finding | Change that closes it | Owner | Dates |
|---|---|---|---|---|---|
EXAMPLE OG-01 | MX-02, MX-05, MX-06 | The ordering platform took 4 days to restore in May; the MTD is 2 days. | Rebuild the platform's recovery (P05 TA-01), then test it (RV-2027-04) Linked: P05 TA-01, P12 GAP-03 | Head of IT | Found 25 Sep 2026 Plan by 9 Oct 2026 Due 15 Dec 2026 Open |
EXAMPLE OG-02 | MX-04 | The backup service provider's contract gives no recovery time. | Agree a restore time at the supplier's assessment and put it in the contract Linked: P06 SUP-011 | Procurement Manager | Found 25 Sep 2026 Plan by 9 Oct 2026 Due 3 Nov 2026 Open |
[[OG-xx]] | [[MX-xx]] | [[what fails]] | [[the change]] | [[role]] | [[found, plan by, due]] |
Adapting this template
Guidance — delete before approval
Small organisation: keep the card and all eleven sections, each short. One person may hold several roles, but not two that act in the first hour (RR-19). Where a provider rebuilds your foundations, name its lead and keep the decisions with your own people.
Guidance — delete before approval
Service outsourced wholly to a supplier: the plan is still yours. Record what the contract commits the supplier to (CL-10), how you would know its recovery is clean, and the data you hold outside it.
Guidance — delete before approval
Regulated financial entity under DORA: have the plan reviewed by independent internal audit unless you are a microenterprise (Article 11(3)), test it at least yearly with cyberattack and switchover scenarios (Article 11(6)), and check it against the scenarios of Delegated Regulation Article 26(2). Entities under Article 16(1) follow Article 16(1)(f) and Delegated Regulation Article 39(2) instead.
Guidance — delete before approval
Provider named in NIS2 Implementing Regulation Article 1: check the plan against Annex points 4.1.2 (contents) and 4.1.4 (testing and review).
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; ISO 22301:2019 incl. Amd 1:2024 (number and title only); NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.29 — Information security during disruption | PS-2, PS-3; the cyber route throughout |
ISO/IEC 27001:2022 | Annex A 5.30 — ICT readiness for business continuity | The whole template |
NIST CSF 2.0 | RC.RP-01 — “The recovery portion of the incident response plan is executed once initiated from the incident response process” | The whole template, run once invoked |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole template, with crisis roles |
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 | Legal note: who it binds |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.1 — “For the purpose of Article 21(2), point (c) of Directive (EU) 2022/2555, the relevant entities shall lay down and maintain a business continuity and disaster recovery plan to apply in the case of incidents.” | The whole template |
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 | PS-1 to PS-8 |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.4 — “The business continuity plan and disaster recovery plan shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks. The relevant entities shall ensure that the plans incorporate lessons learnt from such tests.” | PS-11 |
DORA — Regulation (EU) 2022/2554 | Article 11(3) — “financial entities shall implement associated ICT response and recovery plans which, in the case of financial entities other than microenterprises, shall be subject to independent internal audit reviews” | Adapting this template |
DORA — Regulation (EU) 2022/2554 | Article 11(4) — “Financial entities shall put in place, maintain and periodically test appropriate ICT business continuity plans, notably with regard to critical or important functions outsourced or contracted through arrangements with ICT third-party service providers.” | PS-9, PS-11 |
DORA — Regulation (EU) 2022/2554 | Article 11(6) — test the ICT business continuity plans and the ICT response and recovery plans “in relation to ICT systems supporting all functions at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”, and test the crisis communication plans (Article 14); financial entities other than microenterprises include in the testing plans “scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities”; the policy and plans are regularly reviewed taking into account test results and recommendations from audit checks or supervisory reviews | PS-11; Adapting this template |
DORA — Regulation (EU) 2022/2554 | Article 12(1) — “For the purpose of ensuring the restoration of ICT systems and data with minimum downtime, limited disruption and loss”, financial entities develop and document 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”, and restoration and recovery procedures and methods | PS-1, PS-4: recovery point and backup interval |
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” | PS-2, PS-3, PS-6 |
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 | The cyber scenario; PS-4 |
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.” | PS-6: long-term options |
DORA — Delegated Regulation (EU) 2024/1774 | Article 39(2) — for the entities under the simplified framework (DORA Article 16(1)), the ICT business continuity plans are approved by the management body, documented and readily accessible in an emergency, adequately resourced, “establish planned recovery levels and timeframes for the recovery and resumption of functions and key internal and external dependencies, including ICT third-party service providers”, identify activation conditions, restoration and recovery measures and backup procedures, consider alternative options, specify communication and escalation arrangements, and are updated in line with lessons learned | Adapting this template |
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” | PS-1, PS-6: timely restoration |
ISO 22301:2019 incl. Amd 1:2024 | Security and resilience — Business continuity management systems — Requirements (cited by number and title only) | The whole template |
ISO/IEC 27001 references name the clause or control this document relates to; ISO 22301 is named by number and title only. Neither says that meeting one meets any other framework's requirement.
Definitions
Term | Meaning in this plan |
|---|---|
Business impact analysis (BIA) | for each critical service, how the harm grows over time on the risk register's impact areas, and the point at which it becomes Severe (RR-03). |
Business owner | The manager accountable for a critical service. Sets and agrees its objectives, accepts its workaround, and confirms it works before it returns to users (RR-02). |
Clean room | An isolated recovery environment: a network with no connection to production, its own administrator accounts and no trust to the production directory, where systems are rebuilt and checked before they return (RR-13). |
Crisis team | The group that leads the organisation through a disruption: the crisis lead, the incident manager for a cyber incident, the technical recovery lead, the business owners of affected services, communications, legal and the data protection officer (P09 crisis team). |
Critical service | A service the organisation delivers whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale (RR-01). It is a business service, such as online ordering, not a system. |
Cyber recovery time | The time a service would take to come back after a destructive attack: the foundations' rebuild, if the service depends on them, plus the slowest of the systems the organisation restores itself (MX-05). |
Dependency | Anything a critical service needs to run: a system, a supplier, a data set, a group of people, a site, or the foundations (RR-09). |
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). |
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). |
Objective gap | A check in the objectives matrix that fails: an objective the service cannot meet as things stand. Recorded with an owner, a due date and the change that closes it (RR-15). |
Rebuild | Wipe a system and install it again from a trusted build source, then restore only its data (P09 D4). |
Recovery point | 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 test | A technical test that recovers a critical service, or the systems behind it, and measures the time achieved and the data lost against its objectives; for a service a supplier runs, the supplier's own recovery test with its results shared. An exercise, a tabletop or a drill, is not a recovery test (RR-14). |
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). |
Restore | Put data or a system back from a backup copy that has been checked for integrity (P09 IM-10). |
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). |