Clean-Room Recovery & Rebuild Checklist
Verifies trusted build media, credentials, backups and network isolation before systems return to production.
Available soon
- Format
- Excel
- Size
- 83 KB
- Length
- 11 sheets
- Version
- 1.1
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.1
RR-11 points to P23 for other restore checks.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Use this workbook with the Cyber Recovery Operating Procedure. P09 runs containment and eradication; this checklist starts when P09 confirms eradication (E5) and the crisis lead has set the recovery order (RR-08). The Gates Explained sheet says what each gate means and why it exists: read it once before you start. |
| 2 | Make one copy of the Checklist sheet for each system you rebuild or restore, foundations first: right-click the tab, choose Move or Copy, tick Create a copy, and name the copy after the system. Do the same with the Recovery Point sheet. Each copy calculates on its own. |
| 3 | Fill "This system" at the top: the service it supports, the objectives, the restore-or-rebuild decision (P09 D4, the incident manager's) and who confirmed that evidence was preserved before anything was wiped (P09 IM-07). |
| 4 | Work the stages in order: R2 Isolate and prepare, R3 Rebuild clean, R4 Restore data, R5 Validate, R6 Return to service. Do not start a stage until the one before it shows "May move on". |
| 5 | For each gate, look at the evidence, then choose the Result: Pass, Fail or Not applicable. Enter the date, who signed, and where the evidence is kept. A result counts only once it is dated and signed. The person who signs is the role the gate names in the "Who signs" column, or that role's deputy named in the Crisis & Recovery Responsibility Matrix. |
| 6 | Mandatory gates cannot be waived: Not applicable is never accepted on one. A conditional gate (CG-08, CG-18) applies when its condition holds. Answer "Condition holds?" Yes, No or Not known. Not applicable is accepted only when the answer is No; Not known counts as Yes. |
| 7 | When a gate fails, never overwrite the Fail. Put it right, describe what was done in "If it failed", then record the re-check result, date and signature. The Result now column uses the re-check. |
| 8 | Read the stage table. "May move on": every gate in the stage is met. "Held": a gate failed or a Not applicable was not allowed; the gate holding it is named. "Not finished": a gate has no signed result yet. "On first results" shows the stage as the first results left it, before any re-check. |
| 9 | On the Recovery Point sheet, list every backup copy of the system's data with when it was taken, its integrity check and its scan result. Enter the earliest sign of the attacker that the investigation has found. The sheet picks the newest copy taken before it that passed both checks (RR-12, P09 D3). The incident manager confirms the choice (RA-10); it is the evidence for CG-12. |
| 10 | If the investigation later finds an earlier sign of the attacker, change the date on the Recovery Point sheet. The recovery point may move: restore again from the earlier copy and repeat stage R4. |
| 11 | The system returns to production only when the overall result reads "All gates met: may return to production" and P09's recovery criteria are met (RR-18, CG-20). The checks continue through P09's monitoring period. |
| 12 | Keep each completed checklist with the incident's case log and the crisis log. Keep a printed copy, and a copy off the main systems, so the checklist can be used when they are down (RR-16). |
| 13 | To clear the EXAMPLE, delete the EXAMPLE Checklist sheet, and clear the yellow cells on the Recovery Point sheet. The Checklist sheet is already blank. The gates stay: they are the standard. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
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.
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.
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.
P09 IM-07: Evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded.
P09 IM-10: A system must not return to normal service until the recovery criteria are met, and backups must be checked for integrity before they are restored.
Why a checklist. 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.
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 gate rule. A stage may move on when every mandatory gate is Pass, and every conditional gate is Pass, or Not applicable with its condition recorded as not holding. A Fail, or a Not applicable that is not allowed, holds the stage. Results are counted, never weighted or turned into a score (RR-20).
EXAMPLE, an illustration: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. The EXAMPLE Checklist and Recovery Point sheets show a hypothetical rebuild of its warehouse management system (P07 SYS-02) after a destructive attack. A hypothetical illustration, not an event in the example's story: no such attack happened, and the dates and times (5 to 12 Oct 2026) are invented for it. CG-06 failed and held stage R3 until the server was rebuilt from fresh vendor media; the re-check passed and the system returned.
Adapting this template.
Small organisation: keep every mandatory gate. One person may sign for several stages, but the business owner signs CG-19 and the incident manager confirms CG-20. Ask your IT provider to show you the evidence for each gate, not to tick it.
IT run by a service provider: the provider may do the work of stages R2 to R4. Your technical recovery lead still signs each gate, on the provider's evidence. Write the provider's recovery environment and its isolation into the contract before you need them.
Cloud and software-as-a-service systems: the provider rebuilds its own platform. Your gates cover what you control: your administrator accounts (CG-02, CG-09), your configuration (CG-07), your data (CG-12 to CG-15) and your links to it (CG-18). Mark the rest of the gates in the note as the provider's, with its evidence.
Gates of your own: add them on the yellow rows at the foot of the table, with an ID (CG-23 onwards), a stage, and Mandatory or Conditional. They count in the stage results.
This workbook is your own record. Keep it with your recovery plans and the incident's records.
Checklist
Clean-room checklist: [[system name]]
One copy of this sheet for each system rebuilt or restored. Yellow cells are yours; the result now, the gate check and every stage result calculate. A stage may move on only when all its gates are met.
This system
| System, and its ID | [[System name and ID in your system inventory]] | ||||||||||
| Critical service it supports, and its business owner | [[Service: business owner]] | ||||||||||
| The service's objectives (hours) | [[RTO; RPO; MTD]] | ||||||||||
| Time achieved at its last recovery test, and its cyber recovery time | [[Hours achieved, test reference and date; cyber recovery time in hours]] | ||||||||||
| Incident (P09 case log) | [[INC-yyyy-nnn]] | ||||||||||
| Restore or rebuild (P09 D4), and who decided | [[Restore or rebuild; decided by the incident manager, on the technical recovery lead's recommendation]] | ||||||||||
| Evidence preserved before anything was wiped (P09 IM-07) | [[Confirmed by, date]] | ||||||||||
| Recovery point (CG-12) | [[From the Recovery Point sheet: copy and time taken]] | ||||||||||
| Workaround running while it is down | [[The service's workaround, and who started it]] | ||||||||||
Can the system move on?
| Stage | Stage, and who signs | Gates | Gates met | Result now | Gate holding it | On first results | |||
|---|---|---|---|---|---|---|---|---|---|
| R2 | Isolate and prepare: signed by technical recovery lead, head of information security | 5 | 0 of 5 | Not finished | Not finished | ||||
| R3 | Rebuild clean: signed by technical recovery lead, incident manager | 6 | 0 of 6 | Not finished | Not finished | ||||
| R4 | Restore data: signed by incident manager, technical recovery lead, head of information security, business owner | 4 | 0 of 4 | Not finished | Not finished | ||||
| R5 | Validate: signed by head of information security, business owner, technical recovery lead | 4 | 0 of 4 | Not finished | Not finished | ||||
| R6 | Return to service: signed by incident manager, technical recovery lead | 3 | 0 of 3 | Not finished | Not finished | ||||
| Overall | May the system return to production? | 22 | 0 of 22 | Not finished at R2 | Not finished at R2 | ||||
Counted only from signed and dated results. A gate without a stage is counted in no stage. Gates met are counts, never a share (RR-20).
The gates, CG-01 to CG-22
| Gate | Stage | Gate: what must be true | Mandatory or conditional | Condition (conditional gates) | Condition holds? | Evidence | Who signs | Result | Date | Signed by | Evidence reference and note | If it failed: what was done | Re-check result | Re-check date | Re-check signed by | Result now | Gate check | Holds stage |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CG-01 | R2 | The recovery environment has no network path to production, and its connection to the internet is limited to what the rebuild needs. | Mandatory | Network diagram and firewall rules of the environment, checked by a second engineer | Technical recovery lead | Not checked | ||||||||||||
| CG-02 | R2 | Administrator accounts in the recovery environment are new, held by named people, and have no trust to the production directory. | Mandatory | Account list with creation dates | Technical recovery lead | Not checked | ||||||||||||
| CG-03 | R2 | The devices used to run the recovery are clean: newly built or never connected to the affected network. | Mandatory | Device list and how each was built | Technical recovery lead | Not checked | ||||||||||||
| CG-04 | R2 | Emergency administrator accounts were used only as P14 PA-12 allows, and every use is recorded for review. | Mandatory | Break-glass use record (P14) | Head of Information Security | Not checked | ||||||||||||
| CG-05 | R2 | Endpoint protection and logging run in the recovery environment and report to a monitoring console the attacker could not reach. | Mandatory | Console showing the environment's devices reporting | Head of Information Security | Not checked | ||||||||||||
| CG-06 | R3 | Every build source is trusted: an offline golden image whose hash matches the recorded one, or vendor media downloaded fresh and hash-checked. | Mandatory | Hash comparison record | Technical recovery lead | Not checked | ||||||||||||
| CG-07 | R3 | Configuration is rebuilt from a stored, reviewed baseline, not copied from the affected system. | Mandatory | Baseline version and a comparison report | Technical recovery lead | Not checked | ||||||||||||
| CG-08 | R3 | 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 | The attacker had administrator rights in the directory, or it is not known | Directory review record | Technical recovery lead | Not checked | |||||||||||
| CG-09 | R3 | 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. | Mandatory | Reset log with times | Technical recovery lead | Not checked | ||||||||||||
| CG-10 | R3 | Each rebuilt system is patched to the current priority deadlines before it holds data. | Mandatory | Scan report on the rebuilt system | Technical recovery lead | Not checked | ||||||||||||
| CG-11 | R3 | The weakness the attacker used to get in is closed on every rebuilt system (P09 E1, E4). | Mandatory | Change record and a rescan | Incident manager | Not checked | ||||||||||||
| CG-12 | R4 | The recovery point is the newest copy taken before the earliest sign of the attacker (RR-12). | Mandatory | The copy's date and time beside the earliest sign, with who decided | Incident manager | Not checked | ||||||||||||
| CG-13 | R4 | The copy passes its integrity check before it is restored (P09 IM-10). | Mandatory | Integrity check result | Technical recovery lead | Not checked | ||||||||||||
| CG-14 | R4 | The restored data is scanned for malware and for the indicators of this attack, inside the recovery environment. | Mandatory | Scan report | Head of Information Security | Not checked | ||||||||||||
| CG-15 | R4 | The data lost since the recovery point is recorded against the RPO, and its recovery from other sources (suppliers, emails, paper) is assigned. | Mandatory | Data-loss record | Business owner | Not checked | ||||||||||||
| CG-16 | R5 | A sweep for this attack's indicators and for persistence (new accounts, scheduled tasks, remote access tools) finds nothing on the system. | Mandatory | Sweep report from the monitoring provider | Head of Information Security | Not checked | ||||||||||||
| CG-17 | R5 | Data is reconciled with its other sources (orders with payments, stock with dispatch) and differences are explained. | Mandatory | Reconciliation record | Business owner | Not checked | ||||||||||||
| CG-18 | R5 | Interfaces to suppliers and customers are re-established with new credentials or keys, and the other side has confirmed. | Conditional | The system exchanges data with a supplier or customer | Confirmation from each counterpart | Technical recovery lead | Not checked | |||||||||||
| CG-19 | R5 | The business owner has tested the service and confirmed in writing that it works (P09 V4). | Mandatory | Signed confirmation | Business owner | Not checked | ||||||||||||
| CG-20 | R6 | The incident manager confirms P09's recovery criteria are met for the system (IM-10). | Mandatory | Confirmation in the case log | Incident manager | Not checked | ||||||||||||
| CG-21 | R6 | The system reconnects in stages, one service or site at a time, with monitoring watching for the indicators found (P09 V5). | Mandatory | Reconnection log | Technical recovery lead | Not checked | ||||||||||||
| CG-22 | R6 | P09's monitoring period of [[7]] days has started, and backups of the restored system have run and been checked. | Mandatory | Monitoring start time; first backup check | Incident manager | Not checked |
Sign-off: return to production
| Role | Name | Date | Signature or reference | |||||
|---|---|---|---|---|---|---|---|---|
| Gates complete (Technical recovery lead) | [[Name]] | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Service confirmed (Business owner, CG-19) | [[Name]] | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Recovery criteria met (Incident manager, CG-20) | [[Name]] | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Return to production approved (Incident manager, RA-13) | [[Name]] | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Told of the return (Crisis lead, informed under RA-13) | [[Name]] | [[YYYY-MM-DD]] | [[Reference]] | |||||
EXAMPLE Checklist
EXAMPLE, an illustration: a hypothetical rebuild of the warehouse management system
A hypothetical illustration, not an event in the example's story: no such attack happened, and the dates and times (5 to 12 Oct 2026) are invented for it. The system, its service, objectives, backups, suppliers and people are the example distributor's. CG-06 failed and held stage R3; "On first results" shows the stage held, "Result now" shows it after the re-check.
This system
| System, and its ID | Warehouse management system (P07 SYS-02; dependency DP-07) | ||||||||||
| Critical service it supports, and its business owner | Warehouse dispatch (CS-02): Head of Logistics | ||||||||||
| The service's objectives (hours) | Recovery time objective 8; recovery point objective 4; maximum tolerable downtime 24 | ||||||||||
| Time achieved at its last recovery test, and its cyber recovery time | 5 hours in recovery test RV-2026-03 (27 Aug 2026). Cyber recovery time: 17 hours, 12 to rebuild the foundations and then 5 for this system (MX-05, OG-04). | ||||||||||
| Incident (P09 case log) | [[INC-yyyy-nnn]] (hypothetical) | ||||||||||
| Restore or rebuild (P09 D4), and who decided | Rebuild from a trusted source, then restore only the data. Hypothetically, the attacker had administrator rights on the server. Decided by the incident manager (Information Security Manager) on the technical recovery lead's recommendation (RA-09). | ||||||||||
| Evidence preserved before anything was wiped (P09 IM-07) | Confirmed by the incident manager (Information Security Manager) before the server was wiped, [[date]] | ||||||||||
| Recovery point (CG-12) | Copy C-3, taken 7 Oct 2026, 01:00 (Recovery Point sheet) | ||||||||||
| Workaround running while it is down | Dispatch from printed pick lists of the next day's orders, printed each evening, for up to [[24]] hours | ||||||||||
Can the system move on?
| Stage | Stage, and who signs | Gates | Gates met | Result now | Gate holding it | On first results | |||
|---|---|---|---|---|---|---|---|---|---|
| R2 | Isolate and prepare: signed by technical recovery lead, head of information security | 5 | 5 of 5 | May move on | May move on | ||||
| R3 | Rebuild clean: signed by technical recovery lead, incident manager | 6 | 6 of 6 | May move on | Held | ||||
| R4 | Restore data: signed by incident manager, technical recovery lead, head of information security, business owner | 4 | 4 of 4 | May move on | May move on | ||||
| R5 | Validate: signed by head of information security, business owner, technical recovery lead | 4 | 4 of 4 | May move on | May move on | ||||
| R6 | Return to service: signed by incident manager, technical recovery lead | 3 | 3 of 3 | May move on | May move on | ||||
| Overall | May the system return to production? | 22 | 22 of 22 | All gates met: may return to production | Held at R3 | ||||
Counted only from signed and dated results. A gate without a stage is counted in no stage. Gates met are counts, never a share (RR-20).
The gates, CG-01 to CG-22
| Gate | Stage | Gate: what must be true | Mandatory or conditional | Condition (conditional gates) | Condition holds? | Evidence | Who signs | Result | Date | Signed by | Evidence reference and note | If it failed: what was done | Re-check result | Re-check date | Re-check signed by | Result now | Gate check | Holds stage |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CG-01 | R2 | The recovery environment has no network path to production, and its connection to the internet is limited to what the rebuild needs. | Mandatory | Network diagram and firewall rules of the environment, checked by a second engineer | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Recovery network diagram and firewall rules: no route to production; internet only to the warehouse management system provider's download site and the update service. Checked by the IT Operations Manager as second engineer. | Pass | OK | |||||||
| CG-02 | R2 | Administrator accounts in the recovery environment are new, held by named people, and have no trust to the production directory. | Mandatory | Account list with creation dates | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Account list: [[3]] new administrator accounts, one per named engineer, created in the recovery environment. No trust to the production directory. | Pass | OK | |||||||
| CG-03 | R2 | The devices used to run the recovery are clean: newly built or never connected to the affected network. | Mandatory | Device list and how each was built | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Device list: [[4]] laptops newly built from the maker's factory image; none was ever on the affected network. | Pass | OK | |||||||
| CG-04 | R2 | Emergency administrator accounts were used only as P14 PA-12 allows, and every use is recorded for review. | Mandatory | Break-glass use record (P14) | Head of Information Security | Pass | 11 Oct 2026 | Head of Information Security | No emergency administrator account was used for this system. The break-glass use record (P14) has no entry for it. | Pass | OK | |||||||
| CG-05 | R2 | Endpoint protection and logging run in the recovery environment and report to a monitoring console the attacker could not reach. | Mandatory | Console showing the environment's devices reporting | Head of Information Security | Pass | 11 Oct 2026 | Head of Information Security | The security monitoring provider's (P06 SUP-006) separate console shows every recovery device reporting. | Pass | OK | |||||||
| CG-06 | R3 | Every build source is trusted: an offline golden image whose hash matches the recorded one, or vendor media downloaded fresh and hash-checked. | Mandatory | Hash comparison record | Technical recovery lead | Fail | 11 Oct 2026 | Head of IT | The offline golden image of the server did not match the hash recorded when it was made. Nobody could say why, so it was not used. | Rebuilt from installation media downloaded fresh from the warehouse management system provider (P06 SUP-010) and checked against the provider's published hash. The unmatched image was kept as evidence for the incident manager (P09 IM-07), and the golden image process was added to the lessons (RR-16). | Pass | 11 Oct 2026 | Head of IT | Pass | OK | |||
| CG-07 | R3 | Configuration is rebuilt from a stored, reviewed baseline, not copied from the affected system. | Mandatory | Baseline version and a comparison report | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Configuration from baseline [[WMS-BL-04]], last reviewed [[date]]; the comparison report shows no difference after the build. | Pass | OK | |||||||
| CG-08 | R3 | 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 | The attacker had administrator rights in the directory, or it is not known | No | Directory review record | Technical recovery lead | Not applicable | 11 Oct 2026 | Head of IT | The condition does not hold: the monitoring provider found that the attacker used a local administrator account on this server and had no administrator rights in the sign-in directory. The directory's own review is on the foundations' checklist. | Not applicable | OK: not applicable | |||||
| CG-09 | R3 | 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. | Mandatory | Reset log with times | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Reset log with times: administrator, service, remote access and backup system accounts, then users, in P09 E3's order. Signing keys not reset: the directory was not compromised. | Pass | OK | |||||||
| CG-10 | R3 | Each rebuilt system is patched to the current priority deadlines before it holds data. | Mandatory | Scan report on the rebuilt system | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | Scan report on the rebuilt server: no missing patch past its deadline. | Pass | OK | |||||||
| CG-11 | R3 | The weakness the attacker used to get in is closed on every rebuilt system (P09 E1, E4). | Mandatory | Change record and a rescan | Incident manager | Pass | 11 Oct 2026 | Information Security Manager | The way in the incident manager recorded (P09 E1) is closed on the rebuilt server: change [[CHG-nnnn]] and a rescan. | Pass | OK | |||||||
| CG-12 | R4 | The recovery point is the newest copy taken before the earliest sign of the attacker (RR-12). | Mandatory | The copy's date and time beside the earliest sign, with who decided | Incident manager | Pass | 11 Oct 2026 | Information Security Manager | Copy C-3, taken 7 Oct 2026, 01:00: the newest copy before the earliest sign of the attacker (8 Oct 2026, 22:40) that passed its integrity check and scan (Recovery Point sheet). Chosen by the incident manager (RA-10). | Pass | OK | |||||||
| CG-13 | R4 | The copy passes its integrity check before it is restored (P09 IM-10). | Mandatory | Integrity check result | Technical recovery lead | Pass | 11 Oct 2026 | Head of IT | The backup platform's integrity check of copy C-3: Pass (Recovery Point sheet). | Pass | OK | |||||||
| CG-14 | R4 | The restored data is scanned for malware and for the indicators of this attack, inside the recovery environment. | Mandatory | Scan report | Head of Information Security | Pass | 11 Oct 2026 | Head of Information Security | The restored database was scanned inside the recovery environment by the security monitoring provider: no malware and none of this attack's indicators. | Pass | OK | |||||||
| CG-15 | R4 | The data lost since the recovery point is recorded against the RPO, and its recovery from other sources (suppliers, emails, paper) is assigned. | Mandatory | Data-loss record | Business owner | Pass | 11 Oct 2026 | Head of Logistics | Data lost: 98.5 hours, from 7 Oct 2026, 01:00 to 11 Oct 2026, 03:30, against a recovery point objective of 4 hours. Stock movements found again by a count of the affected aisles, and dispatches from the carriers' records, assigned to the Head of Logistics. Objective gap raised (RR-15). | Pass | OK | |||||||
| CG-16 | R5 | A sweep for this attack's indicators and for persistence (new accounts, scheduled tasks, remote access tools) finds nothing on the system. | Mandatory | Sweep report from the monitoring provider | Head of Information Security | Pass | 12 Oct 2026 | Head of Information Security | Sweep report from the security monitoring provider (P06 SUP-006): none of this attack's indicators and no new accounts, scheduled tasks or remote access tools. | Pass | OK | |||||||
| CG-17 | R5 | Data is reconciled with its other sources (orders with payments, stock with dispatch) and differences are explained. | Mandatory | Reconciliation record | Business owner | Pass | 12 Oct 2026 | Head of Logistics | Stock reconciled with the aisle counts and dispatches with the carriers' records; [[n]] differences, each explained. | Pass | OK | |||||||
| CG-18 | R5 | Interfaces to suppliers and customers are re-established with new credentials or keys, and the other side has confirmed. | Conditional | The system exchanges data with a supplier or customer | Yes | Confirmation from each counterpart | Technical recovery lead | Pass | 12 Oct 2026 | Head of IT | The links to the ERP (P07 SYS-01, hosted by P06 SUP-004) and to [[the carriers' booking systems]] set up again with new keys; each counterpart confirmed in writing. | Pass | OK | |||||
| CG-19 | R5 | The business owner has tested the service and confirmed in writing that it works (P09 V4). | Mandatory | Signed confirmation | Business owner | Pass | 12 Oct 2026 | Head of Logistics | The Head of Logistics tested picking, packing and dispatch on [[n]] orders and confirmed in writing that the service works. | Pass | OK | |||||||
| CG-20 | R6 | The incident manager confirms P09's recovery criteria are met for the system (IM-10). | Mandatory | Confirmation in the case log | Incident manager | Pass | 12 Oct 2026 | Information Security Manager | The incident manager confirmed in the case log that P09's five recovery criteria are met for this system. | Pass | OK | |||||||
| CG-21 | R6 | The system reconnects in stages, one service or site at a time, with monitoring watching for the indicators found (P09 V5). | Mandatory | Reconnection log | Technical recovery lead | Pass | 12 Oct 2026 | Head of IT | Reconnection log: Warehouse [[1]] first, then the other two, with the monitoring provider watching for the indicators found. | Pass | OK | |||||||
| CG-22 | R6 | P09's monitoring period of [[7]] days has started, and backups of the restored system have run and been checked. | Mandatory | Monitoring start time; first backup check | Incident manager | Pass | 12 Oct 2026 | Information Security Manager | Monitoring period of [[7]] days started at [[time]]; the rebuilt system's first backup ran and its integrity check passed. | Pass | OK |
Sign-off: return to production
| Role | Name | Date | Signature or reference | |||||
|---|---|---|---|---|---|---|---|---|
| Gates complete (Technical recovery lead) | Head of IT | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Service confirmed (Business owner, CG-19) | Head of Logistics | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Recovery criteria met (Incident manager, CG-20) | Information Security Manager | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Return to production approved (Incident manager, RA-13) | Information Security Manager | [[YYYY-MM-DD]] | [[Reference]] | |||||
| Told of the return (Crisis lead, informed under RA-13) | Chief Operating Officer | [[YYYY-MM-DD]] | [[Reference]] | |||||
What happened at the Fail (hypothetical illustration). CG-06: The offline golden image of the server did not match the hash recorded when it was made. Nobody could say why, so it was not used. Stage R3 was held: nothing more was installed and no data was restored until the gate was put right.
How it was resolved. Rebuilt from installation media downloaded fresh from the warehouse management system provider (P06 SUP-010) and checked against the provider's published hash. The unmatched image was kept as evidence for the incident manager (P09 IM-07), and the golden image process was added to the lessons (RR-16). The re-check passed and was signed by the technical recovery lead (Head of IT), so the stage could move on.
The recovery point. The last copy before the encryption was C-7; the attacker was already inside when it was taken. The Recovery Point sheet picks C-3, and 98.5 hours of stock and dispatch data had to be recovered from other sources (CG-15).
Both times. Dispatch's recovery test restored the system in 5 hours. After a destructive attack, the foundations come first: 17 hours in all, beyond the 8-hour objective and within the 24-hour maximum, which is why the business owner relies on the workaround (OG-04).
Recovery Point
Recovery point: which copy to restore from
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). One copy of this sheet per system. Rows marked EXAMPLE: a hypothetical illustration, not an event in the example's story: no such attack happened, and the dates and times (5 to 12 Oct 2026) are invented for it. Replace them with your own.
The system and the attack
| System | EXAMPLE: Warehouse management system (P07 SYS-02) | |||||||
| Earliest sign of the attacker | 8 Oct 2026 | The earliest time the investigation has found any sign of the attacker on this system or on anything that could reach it. Not the time of the encryption. | ||||||
| How it was found, and by whom | EXAMPLE, hypothetical: the security monitoring provider's investigation found a new local administrator account created on the warehouse management system's server at this time. Nothing earlier was found. | |||||||
| System stopped or isolated at | 11 Oct 2026 | EXAMPLE, hypothetical: the server was isolated by the incident manager's decision (P09) after encryption started at 03:10. Data written after the recovery point and before this time is lost. | ||||||
| Recovery point objective (hours) | 4 | EXAMPLE: Warehouse dispatch's recovery point objective, agreed by its business owner (RR-04). | ||||||
| Chosen by | EXAMPLE: the incident manager (Information Security Manager), on the technical recovery lead's recommendation (RA-10) | |||||||
The copies
| Copy | Where it is held | Taken (date and time) | Integrity check | Scan | Before the earliest sign? | Usable? | Usable: taken | Note | |
|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | C-1 | Backup platform (P06 SUP-011) | 5 Oct 2026 | Pass | Clean | Yes | Yes | 5 Oct 2026 | |
| EXAMPLE | C-2 | Backup platform (P06 SUP-011) | 6 Oct 2026 | Pass | Clean | Yes | Yes | 6 Oct 2026 | |
| EXAMPLE | C-3 | Backup platform (P06 SUP-011) | 7 Oct 2026 | Pass | Clean | Yes | Yes | 7 Oct 2026 | The newest copy before the earliest sign that passed both checks. |
| EXAMPLE | C-4 | Backup platform (P06 SUP-011) | 8 Oct 2026 | Fail | Clean | Yes | No | Before the earliest sign, but its integrity check failed: not usable. | |
| EXAMPLE | C-5 | Backup platform (P06 SUP-011) | 9 Oct 2026 | Pass | Found indicators | No | No | After the earliest sign; the scan found the attacker's tool. | |
| EXAMPLE | C-6 | Backup platform (P06 SUP-011) | 10 Oct 2026 | Pass | Clean | No | No | Passed both checks, but taken after the earliest sign: the attacker was already inside. Not used. | |
| EXAMPLE | C-7 | Backup platform (P06 SUP-011) | 11 Oct 2026 | Pass | Found indicators | No | No | The last copy before the encryption. Restoring it is the mistake this sheet prevents. |
The recovery point
| Recovery point: copy | C-3 | The newest copy taken before the earliest sign that passed its integrity check and scan (RR-12, P09 D3). No usable copy: rebuild and recover the data from other sources (P09 D3). | ||||||
| Recovery point: taken | 7 Oct 2026 | The evidence for CG-12. Restore this copy, check its integrity again (CG-13) and scan the restored data (CG-14). | ||||||
| Data lost (hours) | 98.5 | From the recovery point to the time the system stopped. The evidence for CG-15. | ||||||
| Against the recovery point objective | Beyond the recovery point objective: record it under CG-15 and raise an objective gap (RR-15) | Name who recovers the lost data from other sources: suppliers, customers' confirmations, emails, paper, counts. | ||||||
Why the earliest sign, not the encryption. Attackers are often inside for days or weeks before they encrypt. A copy taken after they arrived may hold their tools or data they changed. In the EXAMPLE, C-6 passed both checks and is still not used: it was taken after the attacker arrived.
A copy the attacker could have reached is never restored without its integrity check and scan (RR-12). Keep at least one copy that production administrator credentials cannot change or delete (RR-11).
Gates Explained
What each gate means, and why it exists
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.
The stages a system passes through (from the Cyber Recovery Operating Procedure)
| Stage | Name | Goal | Starts when | Ends when | Lead | |
|---|---|---|---|---|---|---|
| R1 | Assess | 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 | |
| R2 | Isolate and prepare | 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 | |
| R3 | Rebuild clean | 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 | |
| R4 | Restore data | 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 | |
| R5 | Validate | 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 | |
| R6 | Return to service | 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 | |
| R7 | Stand down | 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 | |
| R1 and R7 have no gates: R1 assesses the damage and sets the order; R7 declares the end of recovery (RR-17). Before stage R3 wipes anything: P09 IM-07, "Evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded." | ||||||
The 22 gates
| Gate | Stage | Kind | The gate | What it means | Why it exists | Rules | Who signs |
|---|---|---|---|---|---|---|---|
| CG-01 | R2 | Mandatory | The recovery environment has no network path to production, and its connection to the internet is limited to what the rebuild needs. | The place you rebuild in cannot reach production at all, and reaches the internet only for what the rebuild needs, such as a vendor's download site. | Whatever the attacker left in production can spread to anything that can reach it. A recovery network with a path to production is part of the attacked network. | RR-13 | Technical recovery lead |
| CG-02 | R2 | Mandatory | Administrator accounts in the recovery environment are new, held by named people, and have no trust to the production directory. | Nobody signs in to the recovery environment with a production account. Each administrator account there is new and belongs to one named person, and the environment does not trust the production directory. | The administrator accounts you would normally recover with may be the attacker's. A trust to the production directory lets any account the attacker holds walk straight in. | RR-13 | Technical recovery lead |
| CG-03 | R2 | Mandatory | The devices used to run the recovery are clean: newly built or never connected to the affected network. | The laptops and servers used to run the recovery are newly built, or have never been connected to the affected network. | A device from the affected network may carry the attacker's tools or signed-in sessions. Every password typed on it may be captured. | RR-13 | Technical recovery lead |
| CG-04 | R2 | Mandatory | Emergency administrator accounts were used only as P14 PA-12 allows, and every use is recorded for review. | If an emergency administrator account was used to get in, it was used only as P14 PA-12 allows, and each use is written down for review. | Emergency accounts open everything. In a crisis they are used under pressure, and a use nobody recorded looks the same as the attacker's. | RR-13; P14 PA-12 | Head of Information Security |
| CG-05 | R2 | Mandatory | Endpoint protection and logging run in the recovery environment and report to a monitoring console the attacker could not reach. | Endpoint protection and logging run on every device in the recovery environment, and report to a monitoring console the attacker could not reach. | Without it you cannot see whether the attacker follows you into the recovery environment. A console that sits in production may itself be in the attacker's hands. | RR-13 | Head of Information Security |
| CG-06 | R3 | Mandatory | Every build source is trusted: an offline golden image whose hash matches the recorded one, or vendor media downloaded fresh and hash-checked. | Every system is installed from a source you can prove is unchanged: an offline golden image whose hash matches the one recorded when it was made, or vendor media downloaded fresh and checked against the vendor's published hash. | An image or installer kept on the network may have been changed by the attacker. Comparing hashes is the only way to show it was not. | RR-13; P09 D4 | Technical recovery lead |
| CG-07 | R3 | Mandatory | Configuration is rebuilt from a stored, reviewed baseline, not copied from the affected system. | Settings are rebuilt from a stored, reviewed baseline. Nothing is copied from the affected system. | Copying settings from the affected system copies whatever the attacker changed: an extra administrator, a disabled log, an opened port. | RR-13 | Technical recovery lead |
| CG-08 | R3 | Conditional: the attacker had administrator rights in the directory, or it is not known | The sign-in directory is rebuilt or recovered and cleaned first, where the attacker had administrator rights: unknown accounts, groups, policies and trusts removed. | Where the attacker had, or may have had, administrator rights in the sign-in directory, the directory is rebuilt or recovered and cleaned before anything that depends on it. | Whoever controls the directory controls every system that trusts it. A system rebuilt cleanly and then joined to a compromised directory is compromised again at once. | RR-08; RR-13; P09 D4 | Technical recovery lead |
| CG-09 | R3 | Mandatory | 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. | Passwords and keys are reset in P09's order (E3), highest access first, and the directory's own signing keys twice where the directory was compromised. | Stolen credentials survive a rebuild. Resetting in order closes the attacker's widest access first. Resetting signing keys twice cancels sign-in tickets the attacker may have forged. | RR-13; P09 E3 | Technical recovery lead |
| CG-10 | R3 | Mandatory | Each rebuilt system is patched to the current priority deadlines before it holds data. | Each rebuilt system is patched to the current priority deadlines before any data goes on it. | A fresh install is usually behind on patches. An unpatched system holding data is a new way in. | RR-13; P09 IM-10 | Technical recovery lead |
| CG-11 | R3 | Mandatory | The weakness the attacker used to get in is closed on every rebuilt system (P09 E1, E4). | The weakness the attacker used to get in is closed on every rebuilt system (P09 E1, E4). | If the way in is still open, the attacker can come back the same way. | RR-13; P09 E1, E4 | Incident manager |
| CG-12 | R4 | Mandatory | The recovery point is the newest copy taken before the earliest sign of the attacker (RR-12). | The data comes from the newest backup copy taken before the earliest sign of the attacker, not the newest copy before the encryption. The Recovery Point sheet works it out. | Attackers are often inside for days or weeks before they encrypt. A copy taken after they arrived may hold their tools or data they changed. | RR-12; P09 D3 | Incident manager |
| CG-13 | R4 | Mandatory | The copy passes its integrity check before it is restored (P09 IM-10). | The chosen copy passes its integrity check before it is restored. | A damaged or altered copy restores the damage. P09 IM-10 asks for the check before every restore. | RR-11; RR-12; P09 IM-10, D3 | Technical recovery lead |
| CG-14 | R4 | Mandatory | The restored data is scanned for malware and for the indicators of this attack, inside the recovery environment. | The restored data is scanned for malware and for this attack's indicators, inside the recovery environment. | Something the attacker placed before anyone noticed them can sit in a copy from before the earliest sign. Scanning inside the recovery environment stops it reaching production. | RR-12; P09 D3 | Head of Information Security |
| CG-15 | R4 | Mandatory | The data lost since the recovery point is recorded against the RPO, and its recovery from other sources (suppliers, emails, paper) is assigned. | The data lost between the recovery point and the moment the system stopped is recorded against the recovery point objective, and someone is named to recover it from other sources. | Data lost without anyone noticing turns into errors later: orders never sent, stock that is not there. The record also shows whether the objective held; a missed objective is an objective gap (RR-15). | RR-04; RR-15 | Business owner |
| CG-16 | R5 | Mandatory | A sweep for this attack's indicators and for persistence (new accounts, scheduled tasks, remote access tools) finds nothing on the system. | A sweep for this attack's indicators and for ways back in (new accounts, scheduled tasks, remote access tools) finds nothing on the system. | Attackers leave ways back in. The sweep is the last technical check before the system is trusted with users. | RR-18; P09 E2 | Head of Information Security |
| CG-17 | R5 | Mandatory | Data is reconciled with its other sources (orders with payments, stock with dispatch) and differences are explained. | The restored data is checked against its other sources, such as orders against payments or stock against dispatches, and every difference is explained. | Restored data is older than the moment the system stopped. Reconciling finds what is missing or wrong before customers do. | RR-18 | Business owner |
| CG-18 | R5 | Conditional: the system exchanges data with a supplier or customer | Interfaces to suppliers and customers are re-established with new credentials or keys, and the other side has confirmed. | Where the system exchanges data with a supplier or customer, each link is set up again with new credentials or keys, and the other side confirms it. | The old keys may have been stolen, and the other side may have blocked the link or been reached through it. Their confirmation shows both ends trust the new link. | RR-18 | Technical recovery lead |
| CG-19 | R5 | Mandatory | The business owner has tested the service and confirmed in writing that it works (P09 V4). | The business owner tests the service and confirms in writing that it works (P09 V4). | IT can show the system runs. Only the business owner can say the service works for the people who use it. | RR-18; P09 V4 | Business owner |
| CG-20 | R6 | Mandatory | The incident manager confirms P09's recovery criteria are met for the system (IM-10). | The incident manager confirms that P09's recovery criteria are met for this system (IM-10). | A system's return to normal service is decided under P09. The criteria are P09's, unchanged. | RR-18; P09 IM-10 | Incident manager |
| CG-21 | R6 | Mandatory | The system reconnects in stages, one service or site at a time, with monitoring watching for the indicators found (P09 V5). | The system reconnects in stages, one service or site at a time, while monitoring watches for the indicators found (P09 V5). | Reconnecting everything at once makes a recurrence hard to see and hard to contain. | RR-18; P09 V5 | Technical recovery lead |
| CG-22 | R6 | Mandatory | P09's monitoring period of [[7]] days has started, and backups of the restored system have run and been checked. | P09's monitoring period has started, and the rebuilt system's own backups have run and been checked. | Recovery does not end at reconnection. If the attacker returned to a system whose backups had not yet run, there would be no clean copy to go back to. | RR-11; RR-18; P09 IM-10 | Incident manager |
P09's recovery criteria, confirmed at CG-20 (IM-10)
1. The cause is understood well enough that the same route in is closed.
2. Backups or rebuild images were checked for integrity before they were used.
3. Restored systems are patched, scanned and monitored, with credentials changed where they could have been taken.
4. The system owner has tested the service and confirms it works.
5. The monitoring period has started: [[7]] calendar days of closer watching for Severity 1 and 2 before closure.
The monitoring period is P09's: [[7]] days in its example. RR-17 keeps every other decision right with P09: the incident manager isolates and decides restore or rebuild; only the board or its equivalent decides on a ransom.
Lists
| Result | ConditionHolds | GateKind | Stage | Integrity | Scan |
|---|---|---|---|---|---|
| Pass | Yes | Mandatory | R2 | Pass | Clean |
| Fail | No | Conditional | R3 | Fail | Found indicators |
| Not applicable | Not known | R4 | Not checked | Not scanned |
R5
R6
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Clean room (isolated recovery environment) | 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). |
| Gate | One of CG-01 to CG-22: something that must be true, with evidence, before a system moves on from a stage (RR-13, RR-18). |
| Mandatory gate | A gate that cannot be waived. Only Pass meets it. |
| Conditional gate | A gate that applies when its condition holds. Pass meets it; so does Not applicable when "Condition holds?" is No. Not known counts as Yes. |
| Pass | The evidence shows the gate is true for this system. |
| Fail | The gate is not true, or there is no evidence that it is. It holds the stage until it is put right and re-checked. |
| Not applicable | Only for a conditional gate whose condition does not hold, with the reason in the note. |
| Result now | The re-check result where there is one, otherwise the first result. A result with no date or no signature reads Unsigned and does not count. |
| May move on | Every gate in the stage is met. |
| Held | A gate in the stage failed, or Not applicable was entered where it is not allowed. |
| Not finished | No gate holds the stage, but at least one has no signed result yet. |
| Earliest sign of the attacker | The earliest time the investigation has found any trace of the attacker: a new account, a tool, a sign-in. Usually days or weeks before the encryption. It can move earlier as the investigation goes on. |
| 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). |
| Integrity check | A check by the backup platform that a copy is complete and unchanged since it was taken (P09 IM-10). |
| Scan | A scan of a copy, or of restored data, for malware and for the indicators of this attack, run inside the recovery environment. |
| Indicators | Traces that identify this attack: file names, addresses, accounts, tools. The incident manager keeps the list (P09). |
| Golden image | A stored, approved installation of a system, kept offline with a hash recorded when it was made. |
| Hash | A fingerprint of a file. If the file changes, the hash changes. Comparing it with the recorded or published one shows the file is unchanged. |
| Baseline | The stored, reviewed configuration a system is rebuilt to. |
| Persistence | Whatever an attacker leaves to get back in: new accounts, scheduled tasks, remote access tools, changed settings. |
| Rebuild | Wipe a system and install it again from a trusted build source, then restore only its data (P09 D4). |
| Restore | Put data or a system back from a backup copy that has been checked for integrity (P09 IM-10). |
| 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. |
| 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. |
| 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). |
| 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 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). |
| 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). |
| 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). |
| 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). |
| 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). |
| Technical recovery lead | Rebuilds the foundations, runs the clean room and the rebuilds and restores, and recommends restore or rebuild and the recovery point. |
| Incident manager | Runs the incident under P09: isolates, preserves evidence, decides restore or rebuild for each system, and confirms the recovery criteria are met. |
| Crisis lead | Declares a crisis, invokes continuity plans, sets the recovery order and target times, and declares the end of recovery. |
| CG-nn, RR-nn | CG-nn are the gates; RR-nn the rules of the Business Continuity & ICT Resilience Policy; R1 to R7 the stages of the Cyber Recovery Operating Procedure; RA-nn the responsibilities of the Crisis & Recovery Responsibility Matrix. A reference with a pack, such as P09 D3 or P14 PA-12, is that pack's. |
| EXAMPLE | An illustration: a hypothetical rebuild of the warehouse management system of a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. A hypothetical illustration, not an event in the example's story: no such attack happened, and the dates and times (5 to 12 Oct 2026) are invented for it. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.30 — ICT readiness for business continuity | The checklist as a whole: systems returned to service after a disruption only when they can be trusted |
| ISO/IEC 27001:2022 | Annex A 8.13 — Information backup | CG-12 to CG-15 and the Recovery Point sheet: backup copies chosen, checked and scanned before they are restored |
| ISO/IEC 27001:2022 | Annex A 8.16 — Monitoring activities | CG-05, CG-16 and CG-21: monitoring in the recovery environment, the sweep, and watching the staged reconnection |
| NIST CSF 2.0 | RC.RP-03 — “The integrity of backups and other restoration assets is verified before using them for restoration” | CG-06, CG-12 to CG-14 and the Recovery Point sheet: build sources and backup copies checked before they are used |
| 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” | CG-16 to CG-22: restored systems checked, the service confirmed, and normal operation resumed under monitoring |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The checklist as a whole: systems brought back from backups and rebuilt only when they can be trusted, as part of business continuity and disaster recovery |
| 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 | Applies only to the providers its Article 1 names; for them, the Annex points below. Others, such as the example distributor, may use them as good practice |
| 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 | CG-07 and CG-12 to CG-15, for those providers: data restored from backup copies, and configuration rebuilt from a stored baseline |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.3 — “The relevant entities shall perform regular integrity checks on the backup copies.” | CG-13 and the Recovery Point sheet, for those providers: each copy's integrity checked before it is used. Regular checks between incidents follow the Backup & Restore Assurance pack, P23 (RR-11) |
| 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.” | CG-01 to CG-05 and CG-12 to CG-14, for financial entities: backups brought into use without putting the network or the data 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 | CG-01 to CG-03, for financial entities: restoring in an environment separated 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 | CG-17 and CG-18, for financial entities: restored data reconciled with other sources and with counterparts |
| GDPR — Regulation (EU) 2016/679 | Article 32(1)(b) — the security measures include, as appropriate, “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” | The checklist as a whole: systems that process personal data return with their integrity and availability checked |
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)
DORA binds financial entities only. Articles 11 and 12 do not apply to the entities in its Article 16(1), which follow Article 16(1)(f) and Delegated Regulation (EU) 2024/1774 Articles 39 and 40. The example distributor is not a financial entity.
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.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.