Cyber Recovery Operating Procedure
Sequences recovery after a destructive attack: assess, isolate, rebuild clean, restore data, validate, return to service.
Available soon
- Format
- Word
- Size
- 77 KB
- Length
- 27 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Legal note
- Why cyber recovery is different
- Scope
- Roles
- When this procedure starts
- How this procedure works with incident response
- The stages at a glance
- Procedure stages
- Partial and degraded running
- When to escalate
- Decisions and who takes them
- Pitfalls
- Worked example: a planned cyber recovery test of dispatch
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 1.1
RR-11 points to P23 for other restore checks and retention.
- 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.
Purpose
This procedure sets out how [[Organisation Name]] recovers its critical services after a destructive cyberattack, such as ransomware that has encrypted or wiped production systems. It runs the recovery in seven stages: assess, isolate and prepare, rebuild clean, restore data, validate, return to service, and stand down. Each stage has a goal, entry and exit criteria, numbered steps with who does them, and the gates from the Clean-Room Recovery & Rebuild Checklist that it checks.
It applies the Business Continuity & ICT Resilience Policy and runs each service's recovery plan, written with the Cyber Recovery Plan Template. It starts once the incident response of the Security Incident Management pack (P09) has contained the attack, and works beside it. P09 keeps every decision it owns. This procedure adds what P09 leaves to the continuity plan: the recovery order, the clean rebuild, the data, and the return to service.
Guidance — delete before approval
Replace every value in [[double brackets]] before approval, and name roles, not people.
The settings in [[double brackets]] (P09's monitoring period, the days to agree the change that closes a gap, how long records are kept) are shared with the Business Continuity & ICT Resilience Policy and P09. Change them there and here together.
Keep a printed copy and an offline copy of this procedure, the plans and the contact lists. In a destructive attack the file share this document lives on may be encrypted.
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.
Where this procedure names a law, it says which text asks for what and whom it binds. The NIS2 Implementing Regulation binds only the providers its Article 1 names (NIS2 IR 1); other organisations may use its Annex as good practice. DORA binds financial entities only, and 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.
Why cyber recovery 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.
RR-07 Plans assume a destructive cyberattack as well as a technical failure: production, its replicas and its administrator accounts may not be trusted. Each critical service's cyber recovery time is worked out and compared with its objectives (MX-05).
So this procedure works in an isolated recovery environment, rebuilds the foundations first, chooses each backup copy by when the attacker first appeared, and checks every system against gates before it goes back. And each critical service has two times: the time its last recovery test achieved, usually a restore onto trusted systems, and its 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)." In the worked example, one service needed 5 hours in its test and would need 17 after an attack.
Scope
This procedure applies to the recovery of any critical service, and the systems behind it, after an attack that destroyed, encrypted or corrupted them or left them untrusted; to a planned cyber recovery test (RR-14), which runs the same stages in the recovery environment without touching production; and to everyone, staff or supplier, who rebuilds, restores, checks or approves a system in either. A recovery after a technical failure with no sign of an attacker follows the service's plan (PS-6) until an attacker is suspected.
It does not cover detecting, containing and eradicating the attack, evidence, reports to authorities or the ransom decision: those are P09's. It does not cover exercises, which the Cyber Incident Exercises & Tabletop Scenario Library pack (P10) runs; a tabletop exercise is not a recovery test. How often other restore checks run follows the Backup & Restore Assurance pack, P23 (RR-11).
Roles
Role | What they do in this procedure |
|---|---|
Approver [[the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management]] | Approves the policy and the critical services' objectives, and receives the readiness dashboard. |
Crisis lead [[e.g. Chief Operating Officer, the executive incident lead in a cyber incident (P09)]] | Declares a crisis, invokes continuity plans, sets the recovery order and target times, and declares the end of recovery. |
Incident manager [[e.g. Information Security Manager (P09)]] | Runs the incident under P09: isolates, preserves evidence, decides restore or rebuild for each system, and confirms the recovery criteria are met. |
Technical recovery lead [[e.g. Head of IT]] | Rebuilds the foundations, runs the clean room and the rebuilds and restores, and recommends restore or rebuild and the recovery point. |
Business owner [[the manager accountable for each critical service]] | Agrees the service's objectives, runs its workaround, and confirms it works before it returns to users. |
Resilience coordinator [[e.g. a risk manager or business continuity manager who runs no system in scope]] | Keeps the objectives matrix, the dependency register, the plans and the test schedule current; keeps the crisis log during a disruption; reports readiness. |
Communications lead [[e.g. Head of Marketing and Communications (P09)]] | Sends staff, customer and public messages from approved templates (P09 IM-09). |
Supplier liaison [[e.g. Procurement Manager]] | Calls on suppliers' continuity commitments and keeps their contacts current (P06 TP-10). |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Owns the cyber scenarios in the plans and the security checks in the clean-room checklist. |
In a cyber incident the crisis lead is P09's executive incident lead, and the incident manager is P09's incident manager. There is one chain of command: this procedure gives neither of them a second set of decisions. The resilience coordinator keeps the crisis log; the technical recovery lead runs the recovery environment and the rebuilds.
Every role has a named deputy, and no one is the first holder of two roles that must act in the same hour (RR-19).
When this procedure starts
The procedure starts when the first two conditions hold. The third must hold, for each system, before that system is rebuilt or restored:
Condition | Who confirms | Where it is recorded |
|---|---|---|
P09 has contained the incident: nothing new is being encrypted or taken, on any site. | Incident manager | P09's case log |
The crisis lead has invoked the continuity plan of each affected critical service (RA-04). | Crisis lead | The crisis log, with the time: each service's recovery time is counted from it |
P09's eradication is confirmed (E5) for the systems concerned. | Incident manager | P09's case log, then the crisis log at the start of R3 |
Assessment and the isolated recovery environment (R1 and R2) can start while P09's eradication continues, so that no time is lost. No system is rebuilt or restored before E5 is confirmed for it, because a rebuilt system reconnected to a network the attacker still holds is lost again.
How this procedure works with incident response
P09's Ransomware Response Playbook runs the incident from the first sign to closure: contain (C), decide (D), eradicate (E), recover (V). Its recover steps say what must happen. This procedure says how, for a destructive attack, in the order of its stages. The table quotes each P09 step this procedure picks up, word for word, and says where it is picked up. Where they seem to differ, P09 wins and this procedure is corrected.
The P09 steps, as the Ransomware Response Playbook states them:
P09 step | What P09 says | Where this procedure picks it up |
|---|---|---|
D3 | “Are the backups intact and clean?” | R1 records the answer; R4 applies it (RR-12, CG-12 to CG-14). |
D4 | “For each system: do we know the attacker's route in and every change it made to this system?” | R1 records the decision for each system; R3 rebuilds; R4 restores. |
E1 | “Find the way in: the phishing email, remote access or unpatched system the attacker used first. Close it. For a phishing email, have it removed from every mailbox and its sender and attachment blocked.” | R3 checks it on every rebuilt system (CG-11). |
E2 | “Find and remove what the attacker left behind: new accounts, scheduled tasks, remote access tools, changed settings on the sign-in directory.” | R3 cleans the rebuilt directory (CG-08); R5 sweeps for persistence (CG-16). |
E3 | “Reset credentials in this order, from clean devices: administrator accounts, service accounts, remote access, backup system, then every user at affected sites. End all signed-in sessions.” | R3 resets again, in the same order, on the rebuilt systems (CG-09). |
E4 | “Patch the weakness used, and any other critical weakness on the affected systems.” | R3, before a rebuilt system holds data (CG-10). |
E5 | “Confirm to the incident manager that E1 to E4 are done, with no new attacker activity since containment.” | R3 starts for a system only after it. |
V1 | “Agree the restore order (Recovery criteria) and the target time for each service.” | R1: the crisis lead confirms the order and times set in advance (RR-08). |
V2 | “Check each backup's integrity before it is used (IM-10), and record the check.” | R4 (CG-13). |
V3 | “Rebuild or restore each system as D4 decides; apply the changed credentials; turn on endpoint protection and monitoring before reconnection.” | R2 to R4, in the recovery environment (RR-13). |
V4 | “Test the service and confirm in writing that it works.” | R5: the business owner's signed confirmation (CG-19). |
V5 | “Reconnect in stages, under closer monitoring, one site or service at a time.” | R6 (CG-21). |
V6 | “Start the monitoring period (7 days for Severity 1 and Severity 2) and tell staff what is back (CT-03 Staff holding message), customers where affected (CT-04 Customer notice).” | R6 (CG-22). |
V7 | “At closure, send CT-10 All-clear and thank-you.” | After P09's closure, which may follow the end of recovery (R7). |
The crisis lead's own decisions are to invoke a plan, set the recovery order and declare the end of recovery (RR-17). Every other decision stays where P09 puts it: isolating a system is the incident manager's; on paying a ransom, P09's answer is “Only the board or its equivalent”, and the plan assumes nothing is paid.
The stages at a glance
Seven stages: R1 assess, R2 isolate and prepare, R3 rebuild clean, R4 restore data, R5 validate, R6 return to service and R7 stand down. They run for each service and each system, so one service can be validating while another is still being rebuilt. The foundations pass R3 before any system that depends on them.
Each stage below gives its goal, start, end and lead, then its numbered steps with the gates they check, quoted from the Clean-Room Recovery & Rebuild Checklist, which also sets the evidence each gate needs. Every gate is mandatory unless marked conditional, and none can be waived. A system that fails a gate stays in its stage until it passes.
Procedure stages
Stage R1: Assess
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Know what is damaged, what can be trusted, and what each critical service needs back first. | P09 has contained the incident; the crisis lead has invoked the continuity plans of the services affected. | A damage list per system, the foundations' state, and the recovery order and target times confirmed by the crisis lead (RR-08). | Technical recovery lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R1.1 | Confirm the start: P09 has contained the incident and the crisis lead has invoked the continuity plan of each affected critical service. Record the time of each invocation in the crisis log. A service's recovery time is counted from the decision to recover it. | Crisis lead; Resilience coordinator |
R1.2 | Open the crisis log and keep it from now until stand-down: every decision, who took it, when and why; every gate result; every time a service stops and returns. | Resilience coordinator |
R1.3 | List every system the affected services depend on, from the dependency register and each service's plan (PS-4). For each, record its state: encrypted or wiped, running but connected to affected systems, unaffected, or not yet known. | Technical recovery lead; Incident manager |
R1.4 | Record the state of each part of the foundations. For the sign-in directory, record whether the attacker had administrator rights in it, or whether that is not yet known. Either answer means gate CG-08 applies in R3. | Technical recovery lead; Head of Information Security |
R1.5 | Record P09's answer to D3 for each backup set, and the earliest sign of the attacker the investigation has found so far, with its source. Both can change as the investigation learns more: check them again at every update. | Incident manager |
R1.6 | For each system, answer the trust question below and record the decision to restore or rebuild. The technical recovery lead recommends; the incident manager decides (P09 D4). | Technical recovery lead; Incident manager |
R1.7 | Call on the suppliers that run systems the affected services need, using the contacts in each plan (PS-9; P06 TP-10): confirm their contracted recovery time and who will work with the technical recovery lead (RR-10). | Supplier liaison |
R1.8 | Start each service's workaround where the service cannot be back within its recovery time objective, or where its plan says to start it at once (PS-5). Record when it started. | Business owner |
R1.9 | Confirm the recovery order and the target time for each service (P09 V1), and record any change from the plan's order with the reason. | Crisis lead; Resilience coordinator |
R1.10 | Tell staff, and customers where they are affected, what is down, what to use instead and when the next update will come, from the approved templates (P09 IM-09). | Communications lead |
The trust question: restore or rebuild
For each system, P09 asks two questions. D3: “Are the backups intact and clean?” D4: “For each system: do we know the attacker's route in and every change it made to this system?” Its answers, quoted:
- D3, Yes: “Restore (D4). Use copies from before the earliest sign of the attacker, not just before the encryption. Check each copy's integrity, and scan it in an isolated place before it goes back on the network.”
- D3, not yet known: “Do not restore until they have been checked. Never restore from a copy that the attacker could have reached without checking it.”
- D4, Yes: “Restore data onto the patched system, change its credentials, and check it before reconnecting.”
- D4, No: “Rebuild it from a clean image, then restore only data. Where the attacker had administrator rights, rebuild the systems it controlled, starting with the sign-in directory.”
Put together for one system, they give one of three answers. Record the answer and the inputs in the crisis log:
Backups intact and clean (D3)? | Route in and every change known (D4)? | Attacker had administrator rights on it? | What happens to the system |
|---|---|---|---|
No | Either | Either | Rebuild from a trusted source and recover the data from other sources |
Yes | No | Either | Rebuild from a trusted source, then restore only the data |
Yes | Yes | Yes | Rebuild from a trusted source, then restore only the data |
Yes | Yes | No | Restore onto the patched system, change its credentials and check it before it reconnects |
The technical recovery lead recommends; the incident manager decides (RA-09). Until a question is answered, treat the answer as No: a restore onto a system the attacker may still control is the costliest mistake in a cyber recovery.
The recovery order
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).
A change of order needs a reason, such as a workaround about to run out, and the reason goes in the crisis log.
Stage R2: Isolate and prepare
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Stand up an isolated recovery environment with trusted tools and new administrator accounts. | R1 complete. | The clean room passes gates CG-01 to CG-05. | Technical recovery lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R2.1 | Choose where the isolated recovery environment runs, as the plan sets it (PS-7): [[a separate cloud tenancy, spare hardware at a second site, or a recovery provider's environment]]. | Technical recovery lead |
R2.2 | Build its network, cut off from production, and have a second engineer check it. Gate CG-01: The recovery environment has no network path to production, and its connection to the internet is limited to what the rebuild needs. | Technical recovery lead |
R2.3 | Create the environment's own administrator accounts. Gate CG-02: Administrator accounts in the recovery environment are new, held by named people, and have no trust to the production directory. | Technical recovery lead |
R2.4 | Prepare the devices the recovery team will work from. Gate CG-03: The devices used to run the recovery are clean: newly built or never connected to the affected network. | Technical recovery lead |
R2.5 | Where the normal administration route is unavailable, use the emergency administrator accounts (P14 PA-12). Gate CG-04: Emergency administrator accounts were used only as P14 PA-12 allows, and every use is recorded for review. | Technical recovery lead; Head of Information Security |
R2.6 | Switch on endpoint protection and logging in the environment. Gate CG-05: Endpoint protection and logging run in the recovery environment and report to a monitoring console the attacker could not reach. | Head of Information Security |
R2.7 | Bring in the clean build sources the plan lists (PS-7): offline images, configuration baselines and installers. Do not connect the backup store yet. | Technical recovery lead |
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 is "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)." It can be small, enough for the foundations and the first service's systems, but it must be ready before it is needed: the plan names where it runs and where its build sources are kept (PS-7).
DORA Article 12(3) asks financial entities that restore backup data using their own systems to use ICT systems physically and logically segregated from the source ICT system.
Emergency administrator accounts
If the attacker holds the normal administrator accounts, or the directory they sign in through, the recovery team needs a way in that does not depend on them. The Privileged Access Management pack (P14) sets the emergency (break-glass) accounts. P14 PA-12: “There must be [[2]] break-glass accounts for each cloud identity tenant and [[1]] for each on-premises directory, sealed in the safe, alerting on every sign-in and tested every [[3]] months. They are used only when the normal route is unavailable, and every use is declared, reviewed and followed by a credential change within [[1]] working day.”
Use them to start the recovery environment or take back a cloud identity tenant, and no more. If the attacker could have reached their credentials, treat them as compromised and create new ones.
Stage R3: Rebuild clean
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Rebuild the foundations, then each system P09 D4 says to rebuild, from trusted build sources. | R2 complete; P09 eradication confirmed (E5). | Each system rebuilt passes gates CG-06 to CG-11. | Technical recovery lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R3.1 | Confirm with the incident manager that P09 E5 is complete for every system about to be rebuilt. No rebuild starts before it. | Technical recovery lead; Incident manager |
R3.2 | Check every build source before use. Gate 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. | Technical recovery lead |
R3.3 | Rebuild or recover the sign-in directory first, and clean it (see below). Gate CG-08: The sign-in directory is rebuilt or recovered and cleaned first, where the attacker had administrator rights: unknown accounts, groups, policies and trusts removed. Conditional: applies when the attacker had administrator rights in the directory, or it is not known. | Technical recovery lead; Head of Information Security |
R3.4 | Reset credentials in P09's E3 order. Gate CG-09: Credentials are reset in P09's order (E3): administrator, service, remote access, backup system, then users; the directory's own signing keys are reset twice where the directory was compromised. | Technical recovery lead |
R3.5 | Rebuild the rest of the foundations, then each system P09 D4 says to rebuild, in the recovery order, each configured from its stored baseline. Gate CG-07: Configuration is rebuilt from a stored, reviewed baseline, not copied from the affected system. | Technical recovery lead |
R3.6 | Patch each rebuilt system before it holds any data. Gate CG-10: Each rebuilt system is patched to the current priority deadlines before it holds data. | Technical recovery lead |
R3.7 | Close the attacker's way in on every rebuilt system, and rescan. Gate CG-11: The weakness the attacker used to get in is closed on every rebuilt system (P09 E1, E4). | Technical recovery lead; Head of Information Security |
R3.8 | Record each system's gate results in the crisis log. A system that fails a mandatory gate stays in R3 until it passes. | Resilience coordinator |
Foundations first
The foundations are "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." Every in-house system needs them first. A service that depends on them cannot come back sooner than the time it takes to rebuild them, whatever its own systems' times.
The parts of the foundations, in the order to rebuild them. The providers named are the EXAMPLE's; replace them with yours:
Order | Part | Who rebuilds it | Target time |
|---|---|---|---|
1 | Sign-in directory | [[your team or supplier]] EXAMPLE: Managed IT service provider (P06 SUP-001) | [[hours]] |
2 | Core network and firewalls | [[your team or supplier]] EXAMPLE: Managed IT service provider (P06 SUP-001) | [[hours]] |
3 | Backup platform | [[your team or supplier]] EXAMPLE: Backup service provider (P06 SUP-011) | [[hours]] |
4 | Endpoint protection and monitoring | [[your team or supplier]] EXAMPLE: Security monitoring provider (P06 SUP-006) | [[hours]] |
5 | Emergency administrator accounts (P14 PA-12) | [[your team or supplier]] EXAMPLE: Head of IT | [[hours]] |
Set a target time for the foundations as a whole, and measure it in a cyber recovery test. Until it has been measured, record it as an estimate. In the EXAMPLE, the foundations' 12 hours are "estimate (P09 Ransomware Response Playbook's example target); never tested as a whole".
When the attacker may control the sign-in directory
Most destructive attacks reach the sign-in directory, because administrator rights in it open every other system. Assume the attacker had them unless P09's investigation shows they did not. Gate CG-08 applies when they did, or when it is not known.
- Rebuild the directory in the recovery environment. Either build a new one and create accounts again from a reviewed list, or recover the directory from a copy taken before the earliest sign of the attacker and clean it. Both routes end with the review CG-08 asks for: no unknown accounts, groups, policies or trusts.
- Reset credentials in P09's E3 order, and reset the directory's own signing keys twice (CG-09), so that sign-in tokens the attacker forged stop working.
- Connect nothing that trusts the old directory until it has been rebuilt in its turn. Check a cloud identity tenant's administrators, trusted devices and external trusts the same way.
Guidance — delete before approval
Write the route you will take for your directory into the plan now, with how long it takes and who can do it. If a managed IT provider runs the directory, agree in advance that it rebuilds with new accounts from clean devices.
Stage R4: Restore data
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Restore each system's data from its recovery point, checked and scanned, and recover what was lost since from other sources. | R3 complete for the system's dependencies. | Each restore passes gates CG-12 to CG-15, with the data lost recorded against the RPO. | Technical recovery lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R4.1 | List the copies available for each data set the service needs, with the date and time each was taken and where it is held. | Technical recovery lead |
R4.2 | Check the integrity of each candidate copy (P09 V2). Gate CG-13: The copy passes its integrity check before it is restored (P09 IM-10). | Technical recovery lead |
R4.3 | Scan each candidate copy inside the recovery environment. Gate CG-14: The restored data is scanned for malware and for the indicators of this attack, inside the recovery environment. | Technical recovery lead; Head of Information Security |
R4.4 | Choose the recovery point (see below). The technical recovery lead recommends; the incident manager decides. Gate CG-12: The recovery point is the newest copy taken before the earliest sign of the attacker (RR-12). | Technical recovery lead; Incident manager |
R4.5 | Restore the data from the recovery point onto the rebuilt system, inside the recovery environment. | Technical recovery lead |
R4.6 | Record the data lost against the recovery point objective, and assign the recovery of what was lost to named people. Gate CG-15: The data lost since the recovery point is recorded against the RPO, and its recovery from other sources (suppliers, emails, paper) is assigned. | Business owner; Resilience coordinator |
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.
Choosing the recovery point
The recovery point is "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)." The newest copy is often the wrong one: the attacker may have been inside for weeks, and a copy taken after they arrived may hold their tools and accounts. The earliest sign comes from P09's investigation and can move earlier as it learns more. When it does, choose again; a system restored from a copy now after the earliest sign goes back to R3.
Illustration, not an event. One data set, backed up each night at 01:00, on hypothetical days. The investigation first finds the attacker at Day 3, 14:00 (the first administrator sign-in from an unknown device). Encryption starts and the service stops at Day 5, 03:00:
Copy taken | Before or after Day 3, 14:00 | Integrity check | Scan | Can it be used? |
|---|---|---|---|---|
Day 1, 01:00 | Before | Pass | Clean | Before the earliest sign; passed both checks |
Day 2, 01:00 | Before | Pass | Clean | Before the earliest sign; passed both checks |
Day 3, 01:00 | Before | Fail | Not scanned | Failed its integrity check |
Day 4, 01:00 | After | Pass | Clean | After the earliest sign: the attacker could have reached it |
Day 5, 01:00 | After | Pass | Clean | After the earliest sign: the attacker could have reached it |
The recovery point is the copy of Day 2, 01:00: the newest copy before the earliest sign that passed both checks. The copy of Day 5, 01:00, last night's, is the one a classic restore would use (PF-03); it was taken after the attacker arrived. The data lost is the time from the recovery point to when the service stopped: 74 hours.
Then the investigation finds an earlier sign: the remote access log shows the attacker's first session, at Day 1, 22:00. Run the choice again. Only the copy of Day 1, 01:00 is before it, so it becomes the recovery point, and the data lost grows to 98 hours. That is the price of a clean restore. What was lost is recovered from other sources, which is why CG-15 asks for the loss to be recorded and its recovery assigned.
Guidance — delete before approval
Keep copies far enough back to survive an attacker who was inside for weeks: the Backup & Restore Assurance pack's retention rule (P23 BR-05) sets how long.
Data lost against the recovery point objective (RPO)
Record, for each data set, the recovery point, the time the service stopped and the hours between them, beside the recovery point objective. A larger loss is an objective gap at stand-down (RR-15), even when it came from a clean restore. The business owner names who recovers what was lost, and from where: suppliers' records, customers' confirmations, emails, paper.
GDPR Article 32(1)(c) asks for the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident. Whether lost personal data is also a personal data breach is decided under P09.
Stage R5: Validate
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Show each system is clean and the service works, before anyone relies on it. | R4 complete for the service. | Gates CG-16 to CG-19 pass, and the business owner confirms the service works (P09 V4). | Business owner |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R5.1 | Sweep each system for this attack's indicators and for persistence. Gate CG-16: A sweep for this attack's indicators and for persistence (new accounts, scheduled tasks, remote access tools) finds nothing on the system. | Head of Information Security |
R5.2 | Reconcile the restored data with its other sources (see below). Gate CG-17: Data is reconciled with its other sources (orders with payments, stock with dispatch) and differences are explained. | Business owner; Technical recovery lead |
R5.3 | Re-establish each interface with a supplier or customer. Gate CG-18: Interfaces to suppliers and customers are re-established with new credentials or keys, and the other side has confirmed. Conditional: applies when the system exchanges data with a supplier or customer. | Technical recovery lead; Supplier liaison |
R5.4 | Test the service as its users will use it, and sign that it works (P09 V4). Gate CG-19: The business owner has tested the service and confirmed in writing that it works (P09 V4). | Business owner |
Reconciling data
A restore can be clean and still wrong: orders taken after the recovery point, payments with no order, stock that left on a paper pick list. Compare the restored data with each source outside the system, explain every difference, and record what was entered again and by whom.
DORA Article 12(7) asks financial entities, when recovering from an ICT-related incident, to perform the necessary checks, including multiple checks and reconciliations, to keep the highest level of data integrity, including when data is reconstructed from external stakeholders, so that all data is consistent between systems.
For the business owner's test (CG-19), the people who use the service run their everyday transactions on the restored system, in the recovery environment (RA-12).
Stage R6: Return to service
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Reconnect in stages under closer monitoring, end the workaround, and catch up the backlog. | R5 complete; P09's recovery criteria met (IM-10). | Gates CG-20 to CG-22 pass; the service runs normally; P09's monitoring period has started. | Crisis lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R6.1 | Confirm P09's recovery criteria are met for the system (IM-10). Gate CG-20: The incident manager confirms P09's recovery criteria are met for the system (IM-10). | Incident manager |
R6.2 | Reconnect in stages (P09 V5), and record each reconnection. Gate CG-21: The system reconnects in stages, one service or site at a time, with monitoring watching for the indicators found (P09 V5). | Technical recovery lead; Head of Information Security |
R6.3 | Start P09's monitoring period; run and check the first backups. Gate CG-22: P09's monitoring period of [[7]] days has started, and backups of the restored system have run and been checked. | Incident manager; Technical recovery lead |
R6.4 | End the workaround on a time agreed with the users, and catch up the backlog: enter what was handled on paper, and work through what the workaround could not handle. | Business owner |
R6.5 | Record the time achieved for each service, from the decision to recover it to its return to users, against its recovery time objective and its maximum tolerable downtime. | Resilience coordinator |
R6.6 | Tell staff what is back, and customers where they were affected, from the approved templates (P09 V6). | Communications lead |
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.
P09's recovery criteria, quoted. The incident manager confirms all five before CG-20 passes:
- The cause is understood well enough that the same route in is closed.
- Backups or rebuild images were checked for integrity before they were used.
- Restored systems are patched, scanned and monitored, with credentials changed where they could have been taken.
- The system owner has tested the service and confirms it works.
- The monitoring period has started: [[7]] calendar days of closer watching for Severity 1 and 2 before closure.
A staged return
Reconnect one service or site at a time, in the recovery order, and watch each before the next. If monitoring finds an indicator of this attack, stop and escalate. P09's monitoring period, [[7]] calendar days for Severity 1 and 2, starts when the system returns (CG-22).
Stage R7: Stand down
Goal | Starts when | Ends when | Led by |
|---|---|---|---|
Declare the end of recovery, complete the records, and feed the lessons into the plans and the objectives. | Every affected critical service has returned. | End of recovery declared (RR-17); crisis log closed; gaps raised (RR-15); plans reviewed (RR-16). | Crisis lead |
Step | What happens, and the gate it checks | Who |
|---|---|---|
R7.1 | Check that every affected critical service has returned, that each passed every mandatory gate, and that the crisis log is complete. | Resilience coordinator |
R7.2 | Declare the end of recovery on the stand-down criteria in each service's plan (PS-2), and record it in the crisis log. | Crisis lead |
R7.3 | Record every objective the recovery missed, and every failed check it showed, as an objective gap with an owner. Tell each service's risk owner. | Resilience coordinator; Business owner |
R7.4 | Review each affected service's plan and write the lessons in. Ask each business owner to review the objectives, and update the dependency register. | Resilience coordinator; Business owner |
R7.5 | Give the timings, gate results and data lost to P09's post-incident review (IM-11). | Resilience coordinator; Incident manager |
R7.6 | Close the crisis log and file it with the gate evidence where it cannot be changed, for the period the policy sets. | Resilience coordinator |
End of recovery and closure of the incident
The end of recovery is "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)." The crisis lead declares it on each plan's criteria (PS-2). P09's closure is separate: "Recovery criteria met, the monitoring period passed without recurrence, and the case log complete." The two may fall on different days.
Guidance — delete before approval
A common set of stand-down criteria: every affected service back with its users, every workaround ended and its backlog cleared, the crisis log complete, and no indicator of the attack since reconnection. Say in the plan whether you also wait for P09's monitoring period to end.
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).
P05 RM-10, which RR-15 calls on: “A trigger forces reassessment of the risks it touches within [[10]] working days.”
Each affected service's plan is then reviewed and the lessons written in (RR-16).
The crisis log and stand-down records
The crisis log is kept by the resilience coordinator from R1 to stand-down (RA-16). It holds:
Record | What it holds |
|---|---|
Invocation | When each service's plan was invoked, by whom, and when its workaround started |
Decisions | Each decision, who took it, when, the options considered and the reason: the order, restore or rebuild, the recovery point, every return to production |
Gate results | Each gate's result and its evidence, for each system, with the time |
Times | For each service: when it stopped, when recovery was decided, when it returned to users; the time achieved against its recovery time objective and maximum tolerable downtime |
Data lost | For each data set: the recovery point, the time it stopped, the data lost against the recovery point objective, and how it was recovered |
Messages | What was said to staff, customers, suppliers and the board, and when (P09 keeps the authority reports) |
Stand-down | The end of recovery: when, by whom, on which criteria; the gaps raised |
RR-20 Readiness is reported to [[executive management]] each quarter and to [[the approver]] each year, as counts with every gap named: no score and no share of readiness. Test records and crisis logs are kept for [[3]] years, or longer where law or a contract asks.
File the crisis log with the gate evidence where nobody who took part can change it, for [[3]] years. Report results as counts, such as "[[2]] of [[3]] services back within their objective", naming each that was not.
DORA Article 11(8) asks financial entities to keep readily accessible records of activities before and during disruption events when their ICT business continuity plans and ICT response and recovery plans are activated.
Partial and degraded running
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.
A workaround is "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)." It keeps the harm below Severe while recovery runs, so it starts at invocation (R1). Plan on an untried one lasting less than its plan says. When it nears its limit, the business owner tells the crisis lead, who may change the order. A workaround that keeps data on paper adds to the reconciliation in R5: keep the paper.
Part of a service can return before the whole: one site first, reading orders before taking them, one warehouse at reduced volume. Each part passes the gates for the systems it uses, the business owner confirms what users can and cannot do, and the crisis log records it with its own time.
Delegated Regulation (EU) 2024/1774, Article 26(1), asks the ICT response and recovery plans of financial entities to provide for short-term and long-term recovery options, including partial systems recovery.
When to escalate
At any stage, stop and escalate when:
When | What happens | To | Basis |
|---|---|---|---|
New attacker activity, or an indicator of this attack found on a rebuilt or restored system | Stop reconnecting. The system goes back under P09; its stage restarts when E5 is confirmed again. | Incident manager | P09 E5; CG-16 |
No copy of a data set passes its integrity check and scan (P09 D3 No) | Rebuild, and recover the data from other sources. The service's time grows and the order may change. | Crisis lead | RR-12; P09 D3 |
A service will not be back within its recovery time objective | Confirm its workaround is running and how long it can last; decide whether to change the order. | Crisis lead | RR-06; RR-08 |
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 mandatory gate fails and cannot be passed quickly | The system stays in its stage. Find another route, such as another build source or an older copy. | Technical recovery lead | RR-13; RR-18 |
A supplier cannot meet its contracted recovery time, or gave none | Call on the contract, record the gap, and plan around the supplier. | Crisis lead | RR-10; P06 TP-10 |
Decisions and who takes them
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.
Who decides (accountable) and who does the work (responsible), from the Crisis & Recovery Responsibility Matrix, which also names who is consulted and informed. Rows RA-05 to RA-07 are P09's decision rights, quoted:
Decision or task | Decides | Does the work | Basis | |
|---|---|---|---|---|
RA-01 | Approve the policy, the critical services and their objectives | Approver | Policy owner | RR-01 |
RA-02 | Agree a service's objectives and its workaround | Business owner | Resilience coordinator | RR-02, RR-06 |
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 | Incident manager | Technical recovery lead | P09 |
RA-06 | Stop a customer-facing service | Crisis lead | Incident manager | P09 |
RA-07 | Pay a ransom or extortion demand | 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-11 | Run the clean room and the rebuilds | Technical recovery lead | Technical recovery lead | RR-13 |
RA-12 | Confirm a service works before it returns to users | Business owner | Business owner | RR-18; P09 V4 |
RA-13 | Approve a system's return to production | Incident manager | Technical recovery lead | RR-18; P09 IM-10 |
RA-14 | Call on a supplier's continuity commitments | Technical recovery lead | Supplier liaison | RR-10; P06 TP-10 |
RA-15 | Tell staff, customers and the public | Crisis lead | Communications lead | P09 IM-09 |
RA-16 | Keep the crisis log | Crisis lead | Resilience coordinator | RR-20 |
RA-17 | Declare the end of recovery | Crisis lead | Resilience coordinator | RR-17 |
RA-18 | Test a service's recovery | Resilience coordinator | Technical recovery lead | RR-14 |
RA-19 | Close an objective gap | Business owner | Technical recovery lead | RR-15 |
The incident manager and the crisis lead are two different people, even in a small organisation.
Pitfalls
The mistakes this procedure is built to prevent, each with its fix:
Pitfall | Fix | |
|---|---|---|
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-03 | Restoring last night's backup after ransomware. | Restore from the newest copy before the earliest sign of the attacker, checked and scanned (RR-12). |
PF-04 | Bringing services back before the sign-in directory can be trusted. | Foundations first, in the clean room (RR-08, RR-13). |
PF-05 | Calling an exercise, a tabletop or a drill, a recovery test. | A recovery test restores systems and measures time against the objective (RR-14). |
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). |
Worked example: a planned cyber recovery test of dispatch
EXAMPLE, not part of the procedure. The organisation used throughout the pack is a wholesale distributor with about 900 staff and three warehouses, an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. After its ransomware incident INC-2026-014 (P09), its Head of Risk coordinated a resilience review from 14 Sep 2026 to 25 Sep 2026, and business owners agreed their objectives on 25 Sep 2026. Values are as at 30 Sep 2026.
The service and its objectives
CS-02 Warehouse dispatch | |
|---|---|
Business owner | Head of Logistics |
Why it is critical | Service: customers' kitchens run out of perishable stock within a day |
Maximum tolerable downtime | 24 hours: the impact analysis first reaches Severe at 24 hours (RR-03) |
Recovery time objective | 8 hours |
Recovery point objective | 4 hours. Stock movements after the recovery point are found again by a count of the affected aisles. |
Workaround | Dispatch from printed pick lists of the next day's orders, printed each evening, for up to [[24]] hours. Never tried: recorded as untried (RR-06). |
Why dispatch needs 17 hours after an attack, against an objective of 8
Two times, for the same service:
Hours | Against the objectives | |
|---|---|---|
Last recovery test, RV-2026-03 on 27 Aug 2026: the warehouse management system restored from backup and checked by the warehouse team | 5 | Within the 8-hour recovery time objective (MX-06 passes) |
Cyber recovery time: the foundations (12 hours), then the warehouse management system (5 hours) | 17 | Beyond the 8-hour objective; within the 24-hour maximum (MX-05 fails) |
The test restored the warehouse management system (DP-07 in the Resilience Dependency Register) onto systems that could be trusted. After a destructive attack, nothing can be restored until the foundations (DP-01) are rebuilt in the recovery environment (R3), and the system then needs its own 5 hours: 12 plus 5 is 17. The cyber recovery time counts only the systems the organisation restores itself. Dispatch's suppliers are checked separately against the objective (MX-02, MX-04): warehouse management system provider, no contracted time; ERP software provider (hosted), 8 hours; network connectivity provider, 12 hours.
So dispatch's status is Needs its workaround: "Tested in the last 12 months, but its test or its cyber recovery time puts it back after its RTO and within its MTD, so its workaround carries the gap." The review recorded it as objective gap OG-04: “After an attack, dispatch would take 17 hours: 12 to rebuild the foundations and 5 for the warehouse system. Its RTO is 8 and its MTD 24.” The change agreed: “The Head of Logistics accepts the printed pick-list workaround after an attack; the foundations' time is measured in RV-2027-03”. Owner: Head of Logistics; due 17 Feb 2027.
Two more facts bear on a cyber recovery of dispatch. Gap OG-05: “Stock and dispatch records are backed up daily; dispatch can lose at most 4 hours.” Until the change is made (“Back up the warehouse management system's database every 4 hours”, due 15 Dec 2026), a restore in R4 could lose up to 24 hours of stock records, plus however far before the earliest sign the recovery point falls, and the loss is recovered as the plan says: stock movements after the recovery point are found again by a count of the affected aisles. And the foundations' 12 hours have never been measured.
The planned test, RV-2027-03
From the year's test plan, approved with the policy:
Test | Service | Date | Kind | What it does |
|---|---|---|---|---|
RV-2027-03 | CS-02 Warehouse dispatch | 17 Feb 2027 | Cyber recovery | Foundations rebuilt in an isolated recovery environment, then the warehouse management system: the first measure of the cyber recovery time |
It is a recovery test: it rebuilds systems and measures the time against the objectives. Dispatch's only earlier test, RV-2026-03 (system restore, 5 hours), measured a restore onto trusted systems. RV-2027-03 is the first to measure the cyber recovery time. It falls on the due date of OG-04, and outside the peak season: "November and December are the peak season (P10): no recovery test touches online ordering, dispatch or payments then."
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.
Under RA-18, the Head of Risk (resilience coordinator) is accountable, the Head of IT runs the test, and the Head of Logistics is consulted. The Chief Operating Officer and the Information Security Manager take their usual roles.
How RV-2027-03 runs this procedure, stage by stage. Production keeps running throughout; the test works only in the recovery environment:
Stage | In the test | What it measures |
|---|---|---|
R1 Assess | Assume the foundations and the warehouse management system are lost, and the directory was the attacker's (CG-08 applies). | The start time |
R2 Isolate and prepare | The Head of IT's team stands up the recovery environment at [[location]]. | Time to pass CG-01 to CG-05 |
R3 Rebuild clean | The foundations, then the warehouse management system, from stored images and baselines. | The foundations' time, against the 12-hour estimate; CG-06 to CG-11 |
R4 Restore data | Stock and dispatch records, from a copy chosen as RR-12 sets against a hypothetical earliest sign of [[date and time]]. | Data lost against the 4-hour objective; CG-12 to CG-15 |
R5 Validate | Warehouse staff run [[a day's picks]]; stock is reconciled with dispatch. | CG-16 to CG-19 |
R6 Return to service | Not run: nothing reconnects to production in a test. | When the system would have been ready: the cyber recovery time, against 8 and 24 hours |
R7 Stand down | The Head of Risk closes the test record, raises a gap for each objective missed (RR-15) and updates the plan (RR-16). | Gaps raised; lessons in the plan |
What the result will mean for dispatch's status:
Cyber recovery time achieved | Status | What follows |
|---|---|---|
Up to 8 hours | Achievable | Tested within its RTO in the last 12 months, and its cyber recovery time is within the RTO. OG-04 can be closed. |
More than 8 and up to 24 hours | Needs its workaround | Tested in the last 12 months, but its test or its cyber recovery time puts it back after its RTO and within its MTD, so its workaround carries the gap. The printed pick lists stay the plan after an attack; try them. |
More than 24 hours | Not achievable | Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD. A new gap, with its change agreed within [[10]] working days (RR-15). |
Guidance — delete before approval
Trying the workaround on the same day, at one warehouse, would show whether printed pick lists can carry dispatch for the hours the test measures. It would also let the plan record the workaround as tried.
Related documents
Document | Relationship |
|---|---|
Business Continuity & ICT Resilience Policy | The rules RR-01 to RR-20 this procedure applies |
Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) | Each service's objectives, the checks MX-01 to MX-07 and its cyber recovery time |
Cyber Recovery Plan Template | Each service's plan: order, dependencies, workaround, build sources, stand-down criteria (PS-1 to PS-11) |
Clean-Room Recovery & Rebuild Checklist | The gates CG-01 to CG-22 a system passes before it returns, with their evidence |
Resilience Dependency Register | What each service depends on, and how long each dependency takes to recover (R1) |
Ransomware Response Playbook, Security Incident Management pack (P09) | Containment, eradication, D3, D4, E1 to E5, V1 to V7, the recovery criteria and the monitoring period |
Cyber Incident Exercises & Tabletop Scenario Library pack (P10) | Exercises of the plans and the roles (EX-07); never counted as recovery tests |
Privileged Access Management pack (P14) | Emergency administrator accounts (PA-12) |
Adapting this template
Guidance — delete before approval
Small organisation: keep the order (foundations first), the recovery environment, the recovery point rule and the business owner's test; they stop the attacker coming back with the restore. The environment can be a spare server and a switch with no link to production, or a cloud tenancy built from a script.
Managed service provider: most of R2 to R6 will be its work. Check its contract obliges it to rebuild from clean sources with new accounts, within the plan's times, and that its own administrator accounts cannot change or delete the backup copies.
Cloud services: the provider recovers the platform; you recover your configuration, accounts and data. Record what the provider will do, and how fast, as a supplier dependency (RR-10).
Regulated entity (NIS2, DORA): an essential or important entity under NIS2 keeps reporting under P09 during recovery, and the crisis log feeds its final report. A financial entity under DORA checks the reconciliation step (R5) against Article 12(7) and the crisis log (R7) against Article 11(8), with [[legal or compliance]].
Delete this section before approval.
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.30 — ICT readiness for business continuity | The whole procedure: recovering ICT to meet each service's objectives after a disruption |
NIST CSF 2.0 | RC.RP-05 — “The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed” | R5 and R6: restored systems checked, services restored, normal operation confirmed |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole procedure: recovery after a destructive attack, and the crisis team that leads it |
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 | R1: the order of recovery; R6: returning from the workaround; the roles table |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.2 — based on the risk assessment (point 2.1) and the business continuity plan, backup plans that include recovery times; “assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment”; storing backup copies in a safe location or locations “which are not in the same network as the system, and are at sufficient distance to escape any damage from a disaster at the main site”; physical and logical access controls to backup copies in accordance with the asset classification level; restoring data from backup copies; and retention periods based on business and regulatory requirements | R4: restoring data from backup copies kept apart from the network they back up |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.3 — “The relevant entities shall perform regular integrity checks on the backup copies.” | R4: integrity checks on backup copies before they are restored (CG-13) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.3.2 — the crisis management process addresses at least “roles and responsibilities for personnel and, where appropriate, suppliers and service providers, specifying the allocation of roles in crisis situations, including specific steps to follow”; appropriate communication means between the entity and the relevant competent authorities, covering both obligatory and non-obligatory communications; and measures to maintain network and information system security in crisis situations | Decisions and who takes them; escalation; security kept during the crisis |
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) | R1: activating the plans, limiting damage and putting recovery actions in order |
DORA — Regulation (EU) 2022/2554 | Article 11(8) — “Financial entities shall keep readily accessible records of activities before and during disruption events when their ICT business continuity plans and ICT response and recovery plans are activated.” | R7: the crisis log, kept readily accessible |
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 | The whole procedure: documented restoration and recovery procedures |
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.” | R2 to R4: backup systems activated without putting security or data integrity at risk |
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 | R2: restoring into systems segregated from the source systems |
DORA — Regulation (EU) 2022/2554 | Article 12(7) — “When recovering from an ICT-related incident, financial entities shall perform necessary checks, including any multiple checks and reconciliations, in order to ensure that the highest level of data integrity is maintained.” The checks also apply when reconstructing data from external stakeholders, so that all data is consistent between systems | R5: checks and reconciliations of the restored data |
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” | Partial and degraded running; R7: conditions to declare a successful recovery |
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” | R4: restoring availability of and access to personal data, and recording what was lost |
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 procedure |
|---|---|
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). |
Earliest sign of the attacker | The earliest time P09's investigation has found the attacker active in the organisation's systems. It can move earlier as the investigation goes on. |
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. |
Isolated recovery environment (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). |
Maximum tolerable downtime (MTD) | Maximum tolerable downtime: 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 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) | Recovery point objective: 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) | Recovery time objective: the time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04). |
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). |