Business Continuity & ICT Resilience Policy
Commits the organisation to continuity and recovery objectives; the resilience domain's single policy.
Available soon
- Format
- Word
- Size
- 70 KB
- Length
- 23 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Scope
- Why a cyberattack changes recovery
- How this policy works with incident response and exercises
- Policy statements
- Roles and responsibilities
- Compliance and consequences
- Exceptions
- Related documents
- Definitions
- Document control
- Example: the distributor's policy
- Which laws ask for this
- Adapting this template
- Framework references
What changed
- 1.1
RR-11 points to P23 for other restore checks.
- 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 policy commits [[Organisation Name]] to keeping its critical services running through a disruption, or to bringing them back within times the business has agreed, with no more data lost than the business has accepted. It covers technical failures and destructive cyberattacks.
It sets 20 rules, RR-01 to RR-20. Every critical service has a business owner, who agrees how long the service can be down and how much data it can lose. Its dependencies, backups and suppliers are checked against those objectives. Its recovery is tested, and every gap a check or a test finds is closed by a named owner by a set date. Readiness is reported as counts, with every gap named.
This is the resilience domain's single policy. The other documents of the Cyber Resilience & Recovery pack put it into practice: the Cyber Recovery Operating Procedure runs a recovery after a destructive attack, the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) records and checks each service's objectives, the Cyber Recovery Plan Template is one service's plan, the Clean-Room Recovery & Rebuild Checklist holds the gates a system passes before it returns, the Resilience Dependency Register lists what each service needs, the Crisis & Recovery Responsibility Matrix says who decides and does what, and the Resilience Readiness Dashboard reports readiness. The Cyber Resilience & Recovery Pack — Guide shows how they fit together.
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.
Guidance — delete before approval
This is the policy for topic PT-16, business continuity and ICT resilience, in the Security Policy Management pack's list of policy topics. It is a Policy-tier document, reviewed at least every 12 months.
It is approved by the board or its equivalent, above the usual approver of the tier, because the critical services and their objectives decide how much harm the organisation accepts in a disruption. Replace [[the approver]] wherever it appears with the body you name in the approval record.
Scope
This policy applies to:
- Services: every critical service (RR-01), and everything it depends on: systems, suppliers, data, people, sites and the foundations (RR-09). A critical service is a business service, such as taking orders or paying staff. The systems behind it are its dependencies.
- Disruptions caused by technology: a hardware, software or network failure, a failed change, the loss of a data centre, or a supplier's outage.
- Destructive cyberattacks: ransomware, data wiped or corrupted on purpose, or an attacker with administrator rights in the systems a service needs. The rules on cyber recovery (RR-07, RR-08, RR-12, RR-13) apply to these.
- Other disruptions: fire, flood, a power cut, a pandemic or the loss of key staff use the same crisis lead, crisis team, plans, objectives and workarounds. Where nothing suggests an attacker, the clean-room steps are not needed.
- People: the crisis and recovery role holders and their deputies, business owners, IT, and suppliers' staff who recover a service for the organisation.
Excluded: responding to the cyber incident itself (detection, triage, containment, removing the attacker and evidence) follows the Security Incident Management Policy and Incident Response Plan (Security Incident Management pack, P09). Exercises follow the Cyber Incident Exercises & Tabletop Scenario Library pack (P10). How often backups are restored to check them, beyond each service's recovery test, follows the Backup & Restore Assurance pack, P23 (RR-11). [[Anything else deliberately left out, and where it is covered; or "None"]].
Guidance — delete before approval
Start with the services whose loss for a few days would do serious harm to customers, money, legal duties or reputation. Most organisations of a few hundred staff have between three and ten. A list of forty services is a list of systems.
Your backup standard is topic PT-06, backup and recovery, at the Standard tier of the Security Policy Management pack's list. Keep it, and make sure its backup intervals are no longer than each service's recovery point (RR-11).
Why a cyberattack changes recovery
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.
What changes, step by step:
Classic disaster recovery | Cyber recovery | |
|---|---|---|
What is assumed | The second site, the backups and the administrator accounts are sound. | Any of them may be damaged or in the attacker's hands (RR-07). |
Where recovery starts | Fail over to the second site, or restore the latest backup. | Rebuild the foundations first, in an isolated recovery environment (RR-08, RR-13). |
Which backup is used | The newest. | The newest copy taken before the earliest sign of the attacker, checked and scanned (RR-12; P09 D3). |
Restore or rebuild | Restore, almost always. | Decided system by system by the incident manager (P09 D4). |
When a system goes back | When it works. | When it passes the clean-room gates, P09's recovery criteria and the business owner's test (RR-18). |
How long it takes | The time a recovery test achieved. | The foundations' rebuild plus the slowest system restored in-house: the cyber recovery time (MX-05). |
So every service has two recovery times. The test time is what a recovery test achieved, with the usual tools. The cyber recovery time is 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). Where the two differ, every document in this pack shows both, and the objectives are checked against both (MX-05, MX-06).
Guidance — delete before approval
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Its warehouse dispatch service has a recovery time objective of 8 h and a maximum tolerable downtime of 24 h. The warehouse management system was restored in 5 h in a test on 27 Aug 2026: within the objective. After a destructive attack, the foundations would first take an estimated 12 h to rebuild, so dispatch would be back in 17 h. That is beyond its objective and within its maximum, so its status is "Needs its workaround": the Head of Logistics accepts the printed pick-list workaround after an attack; the foundations' time is measured in RV-2027-03 (OG-04).
How this policy works with incident response and exercises
The Security Incident Management Policy and the Incident Response Plan of the Security Incident Management pack (P09) run every cyber incident. They own containment, removing the attacker, evidence (P09 IM-07), the backup check (Ransomware Response Playbook, D3), the decision to restore or rebuild each system (D4), the recovery criteria (IM-10), the monitoring period and every decision right during the incident. This policy does not change any of them.
Before any incident, this policy sets the objectives, the dependencies, the plans and the tests. During a cyber incident, it starts where P09's removal of the attacker ends: when the incident manager has confirmed that the attacker's way in is closed, what it left is removed, credentials are reset and the weakness is patched (P09 E5). It then adds what P09 leaves to the continuity plan: the recovery order, the clean rebuild, the return to service and the end of recovery.
Who owns each part of a disruption:
Part | Owner | Where it is set |
|---|---|---|
Triage, declare and contain a cyber incident; preserve evidence; remove the attacker and confirm it is done | Incident manager (P09) | P09 IM-02, IM-03, IM-07, IM-08; Ransomware Response Playbook E1 to E5 |
Declare a crisis, invoke a service's plan and start its workaround | Crisis lead (this policy) | RR-17, RR-06 |
Set the recovery order and target times | Crisis lead (this policy) | RR-08; confirmed at P09 V1 |
Check the backups and choose each recovery point | Incident manager (P09) | P09 D3, IM-10; applied by RR-12 |
Decide restore or rebuild for each system | Incident manager (P09) | P09 D4; applied by RR-12, RR-13 |
Rebuild in the clean room and restore data | Technical recovery lead (this policy) | RR-13 |
Confirm the service works before users rely on it | Business owner | RR-18; P09 V4 |
Approve a system's return to production | Incident manager (P09) | P09 IM-10; RR-18 |
Watch for the attacker's return | Incident manager (P09) | P09's monitoring period |
Declare the end of recovery | Crisis lead (this policy) | RR-17 |
Decisions during a cyber incident
The crisis lead takes the decisions this policy gives it (RR-17). These decisions stay with the people the Incident Response Plan names, exactly as it names them:
Decision | Who decides (P09) |
|---|---|
Isolate a system, site or account | Incident manager |
Stop a customer-facing service | Executive incident lead |
Pay a ransom or extortion demand | Only the board or its equivalent |
In a cyber incident the crisis lead is the person P09 calls the executive incident lead, so recovery and the incident have one leader. P09 IM-10 applies to every system this policy recovers: "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."
Exercises and recovery tests
Exercises belong to the Cyber Incident Exercises & Tabletop Scenario Library pack (P10). An exercise tests decisions and roles around a table or in a drill. A recovery test restores systems and data and measures the time against the objectives (RR-14). Neither counts as the other. Crisis and recovery role holders and their deputies take part in exercises as P10 EX-07 sets (RR-19): "Every role holder in the incident response plan, and every deputy, must take part in an exercise at least every [[24]] months."
Policy statements
The statements keep the rule IDs RR-01 to RR-20 that every document in the Cyber Resilience & Recovery pack cites. Values in [[brackets]] are the pack's defaults; set your own before approval. Under each statement is the reason for it.
Scope and critical services
RR-01 A critical service is one whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale. The list of critical services is approved by [[the approver]] with the policy, and reviewed with the objectives.
Why: A short list puts the recovery effort where the harm is greatest. Using the risk register's scale means a service's harm is judged the same way in risk management and in recovery.
RR-02 Every critical service has a named business owner, who sets and agrees its objectives. IT proposes what is achievable; the business owner decides what is needed. Objectives set by IT alone are not agreed.
Why: Only the business knows how long it can manage without a service; IT knows what a faster recovery costs. Objectives set by one side alone are either unaffordable or too slow.
Impact analysis and objectives
RR-03 Each critical service's maximum tolerable downtime comes from a business impact analysis: the harm is rated on the risk register's impact areas at 4, 8, 24, 48, 72, 120 and 168 hours, and the MTD is the first point at which any area reaches Severe.
Why: Rating the harm at fixed times shows when an outage turns from a nuisance into serious damage. That point is the longest the service can be down, and every other objective is set below it.
RR-04 Each critical service has a recovery time objective shorter than its maximum tolerable downtime, and a recovery point objective. The service's dependencies must recover within its recovery time, and the backup interval of each data set it needs must be no longer than its recovery point.
Why: A recovery time equal to the maximum leaves no margin for anything to go wrong. A service comes back no faster than its slowest dependency, and loses at least the data since its least frequent backup.
RR-05 Business owners review their service's analysis and objectives at least every [[12]] months, and after a significant incident, a recovery test that missed an objective, or a significant change to the service, its suppliers or its risks.
Why: Services, suppliers and risks change. An objective agreed two years ago may describe a business that no longer exists.
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.
Why: Some services will not be back in time, whatever the plan says. A workaround agreed in advance keeps the harm below Severe meanwhile. Marking it untried stops anyone relying on it before it has been shown to work.
Cyber recovery
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).
Why: A plan written for a fire or a failed disk assumes the second site, the backups and the administrator accounts can be trusted. After a destructive attack they may not be. Working out the cyber recovery time shows whether the objectives still hold.
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).
Why: Nothing else can be trusted until the sign-in directory, the network and the backup platform are. An order agreed in advance saves hours of argument on the first morning of a crisis.
Dependencies and suppliers
RR-09 Every critical service has its dependencies recorded: systems, suppliers, data, people, sites and the foundations. Each has a recovery time; a single point of failure is marked with its alternative, or as having none. The register is reviewed at least every [[12]] months and when a dependency changes.
Why: Most missed recovery times come from something the plan did not list: a supplier, a data feed, one engineer. A single point of failure with no alternative is a risk the business owner should know about before the outage.
RR-10 A supplier that runs a system a critical service needs has a recovery time in its contract no longer than that service's recovery time, and is named in the service's plan with a contact and the notice it must give (P06 TP-10). Where the contract gives no time, or a longer one, the gap is recorded (MX-04).
Why: A service cannot recover faster than the supplier that runs part of it. Where the contract gives no recovery time, nobody knows how long the organisation will wait.
Backups
RR-11 Each critical data set is backed up at least as often as its service's recovery point requires, and at least one copy cannot be changed or deleted with production administrator credentials. Copies are checked for integrity before they are restored (P09 IM-10). How often other restore checks run, and how they are judged, is set by the Backup & Restore Assurance pack (P23).
Why: Attackers look for the backups first. A copy that production administrator credentials cannot change or delete survives when those credentials are stolen.
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.
Why: The newest backup may already hold the attacker's tools or damaged data. Going back to before the earliest sign of the attacker, and checking the copy, avoids restoring the attack with the data.
Recovery and return to service
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.
Why: Rebuilding beside infected systems, or with accounts the attacker knows, invites a second attack. An isolated environment lets each system be shown to be clean before it is trusted again.
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.
Why: A system returned too early can bring the attacker back with it. The business owner's test catches data and processes that look right to IT and are wrong for the business.
Testing and review
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.
Why: An untested recovery time is an estimate. Only a recovery that is timed against the objective shows whether the service can come back in time. A tabletop exercise tests decisions and restores nothing.
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).
Why: A gap with no owner is found again at the next test. Telling the risk owner keeps the risk register honest about what recovery can deliver.
RR-16 Each critical service has a recovery plan, reviewed at least every [[12]] months, after every test and real recovery, and after a significant incident or change. Lessons from tests are written into the plan. A copy of every plan and of the contact lists can be reached when the main systems are down.
Why: Plans go out of date as systems and people change. A plan that can only be read on the systems it recovers cannot be read when it is needed.
Roles and decisions
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.
Why: In a crisis, two people deciding the same thing is as harmful as nobody deciding. The crisis lead takes the recovery decisions, and every incident decision stays where the incident management policy puts it.
RR-19 Every crisis and recovery role has a named deputy, and no one is the first holder of two roles that must act in the same hour. Role holders and deputies take part in an exercise at least as often as P10 EX-07 sets.
Why: Crises happen at night, during holidays and to the people who would lead the response. A deputy who has taken part in an exercise can step in; one who has only been named may not.
Reporting and records
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.
Why: A percentage hides which service would fail. Counts with every gap named tell the approver what to fix and who owns it. Kept records show what was tested and what happened, to auditors, insurers and supervisors.
How each service's objectives are checked
The Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) runs 7 checks for every critical service: recovery time shorter than the maximum (MX-01), dependencies recover in time (MX-02), backups as often as the recovery point (MX-03), supplier recovery times known and in time (MX-04), cyber recovery within the objective (MX-05), tested within objective (MX-06) and objectives agreed and current (MX-07). A failed check is an objective gap (RR-15).
From its checks, each service has one status:
Status | What it means |
|---|---|
Achievable | Tested within its RTO in the last 12 months, and its cyber recovery time is within the RTO. |
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. |
Not proven | Not tested in the last 12 months. The objectives may be right; nobody has shown they can be met. |
Not achievable | Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD. |
The settings
Every value the rules use, in one place. Change a value here and in the other documents of the pack together.
Setting | Default | Rule | Who sets it |
|---|---|---|---|
Months between recovery tests of each critical service | [[12]] | RR-14 | Yours to set |
Months from agreeing a never-tested service's objectives to its first recovery test | [[6]] | RR-14 | Yours to set |
Months between reviews of each recovery plan | [[12]] | RR-16 | Yours to set |
Months between business owners' reviews of their analysis and objectives | [[12]] | RR-05 | Yours to set |
Months between reviews of the dependency register | [[12]] | RR-09 | Yours to set |
Working days to agree the change that closes an objective gap | [[10]] | RR-15 | Yours to set |
Years test records and crisis logs are kept | [[3]] | RR-20 | Yours to set; longer where law or a contract asks |
Hours after the start of an outage at which the analysis rates the harm | [[4, 8, 24, 48, 72, 120 and 168]] | RR-03 | Yours to set; keep a point at each day of the first week |
The level on the risk register's impact scale that fixes the maximum tolerable downtime | Severe (level 4) | RR-01, RR-03 | Set by the Risk Assessment Methodology & Scoring Model (P05); change it there |
Monitoring period after a system returns from a cyber incident | 7 days | RR-18 | Set by the incident response plan (P09); change it there |
Guidance — delete before approval
Keep the rule IDs. If you remove a rule, keep its number and mark it "Withdrawn in version x.y", so plans and records that cite it still point to the right text.
The test interval is the setting most often lengthened, and lengthening it weakens the policy most. Twelve months is the longest gap most supervisors and insurers accept between tests of a critical service.
Roles and responsibilities
Each role below has a named holder and a named deputy (RR-19). One person may hold several roles, but nobody is the first holder of two roles that must act in the same hour, such as the crisis lead and the incident manager.
Role | Responsibilities under this policy |
|---|---|
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. |
Policy owner [[e.g. Chief Operating Officer]] | Owns the policy and the resilience programme, and is the crisis lead unless the plan names another. |
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. |
The Crisis & Recovery Responsibility Matrix sets who is responsible, accountable, consulted and informed for each decision and task, with deputies. P09's decision rights appear there exactly as P09 sets them.
Guidance — delete before approval
Make the resilience coordinator someone who runs no system in scope, such as a risk manager: they check objectives that IT proposes. The business owner of a service is usually the manager whose team stops working when it stops.
Compliance and consequences
How compliance is checked. The resilience coordinator keeps the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), whose checks find every objective that cannot be met, and the Resilience Dependency Register. The Resilience Readiness Dashboard reports the seven measures below to [[executive management]] each quarter and to [[the approver]] each year (RR-20). Each is a count, with every gap named. [[Internal audit]] reviews the policy and a sample of plans and test records [[every year]].
Measure | What it counts | Target |
|---|---|---|
RRM-01 Objectives agreed and current | Critical services whose business owner agreed the objectives in the last 12 months, out of all critical services. | All |
RRM-02 Plans current | Critical services whose recovery plan was reviewed in the last 12 months, out of all, with any due within the next quarter named. | All |
RRM-03 Recovery tested | Critical services whose recovery was tested in the last 12 months, out of all. | All |
RRM-04 Restored within objective | Critical services restored within their RTO in a test in the last 12 months, out of all. | All |
RRM-05 Could not recover in time | Critical services that a test or the cyber recovery time shows would be back after their MTD, by name. | None |
RRM-06 Objective gaps open and past due | Objective gaps not yet closed, with those past their due date by name. | None past due |
RRM-07 Roles without a deputy | Crisis and recovery roles with no named deputy, by name. | None |
No measure is turned into a percentage, a score or a colour for the whole programme. Five services of which two would recover in time is reported as 2 of 5, with the three named.
Consequences of not complying. A missed objective found by a check or a test is a gap to close (RR-15), and nobody is disciplined for finding one. Reporting a test as passed when it was not run or did not meet its objective, setting objectives without the business owner, or removing the protected backup copy without approval may lead to action under the [[disciplinary procedure]]. For a supplier, a missed contracted recovery time is handled under its contract.
Guidance — delete before approval
EXAMPLE, as at 30 Sep 2026: RRM-01 objectives agreed and current: 5 of 5; RRM-02 plans current: 5 of 5; 3 due by 30 Oct 2026; RRM-03 recovery tested: 3 of 5; RRM-04 restored within objective: 2 of 5; RRM-05 could not recover in time: Online ordering; RRM-06 objective gaps open and past due: 9 open; none past due; RRM-07 roles without a deputy: Communications lead.
Exceptions
Any departure from these rules is requested and approved under the Security Exception & Waiver Standard [[document ID]] (Security Exception, Waiver & Segregation of Duties pack) before the departure begins. Agreement by email, in a meeting or by a manager is not an exception.
An objective gap is not an exception. It is recorded and closed under RR-15. A business owner who accepts a workaround for a service that cannot be back within its recovery time records it under RR-06. Neither needs an exception.
An exception never changes a P09 decision right, a legal duty, or the rule that only the board or its equivalent decides on a ransom.
Related documents
Document | Relationship |
|---|---|
Cyber Resilience & Recovery Pack — Guide and the other Cyber Resilience & Recovery documents | How the policy is put into practice, document by document, as Purpose lists them |
Security Incident Management Policy; Incident Response Plan; Ransomware Response Playbook | Incident response, decision rights, the backup check, restore or rebuild, and the recovery criteria; Security Incident Management pack |
Tabletop Exercise Design Methodology; Exercise Planning & Facilitation Procedure | Exercises for the crisis team and deputies (RR-19); Cyber Incident Exercises & Tabletop Scenario Library pack |
Third-Party Security Policy; Supplier Contract Security Clause Library | Critical suppliers in the plans (TP-10) and the recovery clause (RR-10); Third-Party Security Risk Management pack |
Risk Assessment Methodology & Scoring Model; Information Security Risk Register | The impact scale that fixes each service's maximum, and the risks a gap is reported to (RR-03, RR-15); Information Security Risk Management pack |
Security Exception & Waiver Standard | The route for every exception to this policy; Security Exception, Waiver & Segregation of Duties pack |
Backup & Restore Assurance pack (P23) | How often backups are taken and restored to check them (RR-11) |
[[Information Security Policy]] | [[Parent policy]] |
Definitions
Term | Meaning in this policy |
|---|---|
Business impact analysis | Business impact analysis: for each critical service, how the harm grows over time on the risk register's impact areas, and the point at which it becomes Severe (RR-03). |
Business owner | The manager accountable for a critical service. Sets and agrees its objectives, accepts its workaround, and confirms it works before it returns to users (RR-02). |
Clean room | An isolated recovery environment: a network with no connection to production, its own administrator accounts and no trust to the production directory, where systems are rebuilt and checked before they return (RR-13). |
Crisis team | The group that leads the organisation through a disruption: the crisis lead, the incident manager for a cyber incident, the technical recovery lead, the business owners of affected services, communications, legal and the data protection officer (P09 crisis team). |
Critical service | A service the organisation delivers whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale (RR-01). It is a business service, such as online ordering, not a system. |
Cyber recovery time | The time a service would take to come back after a destructive attack: the foundations' rebuild, if the service depends on them, plus the slowest of the systems the organisation restores itself (MX-05). |
Dependency | Anything a critical service needs to run: a system, a supplier, a data set, a group of people, a site, or the foundations (RR-09). |
End of recovery | The point at which the crisis lead declares every affected critical service back in normal operation, on the criteria the plan sets, and the records are complete (RR-17). |
Foundations | What every other recovery needs first: the sign-in directory, the core network and firewalls, the backup platform, endpoint protection and monitoring, and the emergency administrator accounts. |
Maximum tolerable downtime (MTD) | 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). |
Objective gap | A check in the objectives matrix that fails: an objective the service cannot meet as things stand. Recorded with an owner, a due date and the change that closes it (RR-15). |
Rebuild | Wipe a system and install it again from a trusted build source, then restore only its data (P09 D4). |
Recovery point | The backup copy a system is restored from: the newest copy taken before the earliest sign of the attacker, checked for integrity and scanned before use (RR-12; P09 D3). |
Recovery point objective (RPO) | 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 test | A technical test that recovers a critical service, or the systems behind it, and measures the time achieved and the data lost against its objectives; for a service a supplier runs, the supplier's own recovery test with its results shared. An exercise, a tabletop or a drill, is not a recovery test (RR-14). |
Recovery time objective (RTO) | 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). |
Restore | Put data or a system back from a backup copy that has been checked for integrity (P09 IM-10). |
Workaround | A way of running the service, or its most important part, without its systems for a set time, such as dispatch from printed pick lists. Owned and accepted by the business owner (RR-06). |
Document control
Approval record
Version | Approved by | Date | Evidence of approval | Next review by |
|---|---|---|---|---|
[[1.0]] | [[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]] | [[YYYY-MM-DD]] | [[e.g. minutes of meeting, reference and item]] | [[YYYY-MM-DD]] |
Review. This policy is reviewed at least every 12 months, and sooner after: a major incident, or an incident the document should have prevented; a material change to the organisation's activities, systems or suppliers; a change in law, regulation or a contract the document supports; an audit or assessment finding against the document; a significant change in the threats the document addresses. A real recovery of a critical service, or a recovery test that missed a maximum tolerable downtime, always triggers a review.
Publication. The current approved version is published at [[location everyone in scope can reach]], and a copy is kept with the recovery plans where it can be read when the main systems are down (RR-16).
Guidance — delete before approval
Nobody approves a document they own or wrote: if the policy owner sits on the approving body, the rest of it approves.
Example: the distributor's policy
EXAMPLE, not part of the policy. The organisation used throughout the pack is a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. It is an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. Replace this with your own, or delete it before approval.
EXAMPLE | |
|---|---|
Policy owner | Chief Operating Officer |
Resilience coordinator | Head of Risk |
Review that set the objectives | Workshops with each business owner, 14 Sep 2026 to 25 Sep 2026, after INC-2026-014 |
Endorsed | By the executive committee, 30 Sep 2026 |
Approver | The board (a board of seven: the chair, the chief executive, the chief financial officer and four non-executive directors), which is asked to approve it on 29 Oct 2026 |
The five critical services, with the objectives their business owners agreed, as at 30 Sep 2026. Times in hours.
Service | Business owner | MTD | RTO | RPO | Last test | Cyber recovery | Status |
|---|---|---|---|---|---|---|---|
CS-01 Online ordering | Chief Operating Officer | 48 h | 24 h | 24 h | 96 h 20 May 2026 | 108 h | Not achievable |
CS-02 Warehouse dispatch | Head of Logistics | 24 h | 8 h | 4 h | 5 h 27 Aug 2026 | 17 h | Needs its workaround |
CS-03 Payments | Chief Financial Officer | 72 h | 24 h | 0 h | Never tested | None restored in-house: the provider restores it | Not proven |
CS-04 Finance and payroll | Chief Financial Officer | 120 h | 48 h | 1 h | 3 h 20 Jan 2026 | 12 h | Achievable |
CS-05 Customer contact | Sales Director | 48 h | 24 h | 24 h | Never tested | 12 h | Not proven |
Guidance — delete before approval
2 of 5 critical services were restored within their recovery time in a test in the last 12 months (RRM-04). Online ordering took 96 h to restore in the test on 20 May 2026, against a maximum of 48 h. The change that closes the gap (OG-01): rebuild the platform's recovery (P05 TA-01), then test it (RV-2027-04). Owner: the Head of IT; due 15 Dec 2026.
Which laws ask for this
Several texts ask for continuity and recovery arrangements. This section says, in summary, what each asks. It does not say that this policy, or following it, fulfils any of them. The framework references at the end list which parts of this document relate to each text.
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.
NIS2 Directive
Article 21(2)(c) of the NIS2 Directive lists, among the measures essential and important entities take, “business continuity, such as backup management and disaster recovery, and crisis management”. Article 21(1) asks those measures to prevent or minimise the impact of incidents on the recipients of the entity's services.
Implementing Regulation (EU) 2024/2690 sets the detail for the providers its Article 1 names: DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers (NIS2 IR 1). Section 4 of its Annex asks them for a business continuity and disaster recovery plan (point 4.1.1) with recovery objectives and an order of recovery (4.1.2), a business impact analysis (4.1.3), and tests and reviews at planned intervals and after significant incidents, with lessons learnt written in (4.1.4). It asks for backups with recovery times, kept away from the production network, with regular integrity checks and tested recovery (4.2.1 to 4.2.6), and for a crisis management process with set roles (4.3). Other entities are not bound by it; many use it as good practice.
DORA (financial entities only)
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to financial entities. Article 11 asks for an ICT business continuity policy (11(1)) carried out through documented plans and arrangements (11(2)), a business impact analysis (11(5)), and tests of the plans at least yearly and after substantive change, including cyberattack and switchover scenarios (11(6)). Article 5(2)(e) asks the management body to approve the policy and review it. Article 12 asks for backup policies whose frequency follows the criticality of the data (12(1)), and for recovery time and recovery point objectives for each function (12(6)). Delegated Regulation (EU) 2024/1774, Article 24, sets what the policy contains.
Articles 5 to 15 do not apply to the entities listed in Article 16(1), such as small and non-interconnected investment firms and exempted payment and electronic money institutions. They follow Article 16(1)(f), which asks for business continuity plans with backup and restoration measures, and Articles 39 and 40 of the Delegated Regulation, which ask for recovery levels and timeframes for functions and their dependencies, and for tests of backup and restore at least once a year.
GDPR
Where the systems hold personal data, Article 32(1) of the GDPR names, among the security measures that may be appropriate, “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” and “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”.
ISO 22301
ISO 22301:2019 incl. Amd 1:2024, Security and resilience — Business continuity management systems — Requirements, is the international standard for a business continuity management system. This template names it by number and title only and reproduces none of its text.
Guidance — delete before approval
EXAMPLE: the distributor is an important entity under NIS2 in its Member State. It is not one of the providers the Implementing Regulation names, so it uses section 4 of the Annex as good practice; it reviewed its plans after INC-2026-014, a significant incident. It is not a financial entity, so DORA does not apply to it.
Adapting this template
Guidance — delete before approval
Small organisation: keep all 20 rules; they cost little with a short list of services. One manager may own several services, and the IT provider may be the technical recovery lead. Start with the impact analysis and objectives of your two or three most important services, then test the one whose recovery nobody has tried.
Regulated entity, NIS2: an essential or important entity keeps the same rules and has the management body approve the policy. A provider named by the NIS2 Implementing Regulation also checks each point of its Annex section 4 against your plans with counsel, and keep the records of tests and reviews that points 4.1.4 and 4.2.6 describe.
Regulated entity, DORA: a financial entity other than a microenterprise has its response and recovery plans reviewed by internal audit (Article 11(3)). Name each critical or important function, as DORA defines it, in the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), and have the management body approve the policy itself. An entity under the simplified framework (Article 16(1)) keeps the same rules and tests backup and restore at least once a year.
Outsourced IT and services run by a service provider: the business owner still agrees the objectives, and the supplier's contracted recovery time is checked against them (RR-10, MX-04). P06 TP-10 asks for the same: "Critical suppliers must be part of incident response and continuity plans, with named contacts and notification duties."
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.29 — Information security during disruption | The whole policy: keeping services going through a disruption, including a cyberattack |
ISO/IEC 27001:2022 | Annex A 5.30 — ICT readiness for business continuity | Objectives, dependencies, plans and recovery tests for each critical service (RR-03 to RR-16) |
ISO/IEC 27001:2022 | Annex A 8.13 — Information backup | Backups (RR-11, RR-12) |
NIST CSF 2.0 | GV.PO-01 — “Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced” | The policy itself, approved and communicated |
NIST CSF 2.0 | RC.RP-03 — “The integrity of backups and other restoration assets is verified before using them for restoration” | Copies checked before they are restored (RR-11, RR-12) |
NIS2 — Directive (EU) 2022/2555 | Article 21(1) — essential and important entities take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”, and “to prevent or minimise the impact of incidents on recipients of their services and on other services” | Purpose: recovery as one of the measures that limit an incident's impact on the people who use the services |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole policy: continuity, backups, recovery and crisis management |
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 | Which laws ask for this: the providers the Implementing Regulation binds; for other entities its Annex is good practice |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.1 — “For the purpose of Article 21(2), point (c) of Directive (EU) 2022/2555, the relevant entities shall lay down and maintain a business continuity and disaster recovery plan to apply in the case of incidents.” | A recovery plan for each critical service (RR-16) |
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 | Objectives, the recovery order, roles and invoking the plans (RR-04, RR-08, RR-17) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.3 — “The relevant entities shall carry out a business impact analysis to assess the potential impact of severe disruptions to their business operations and shall, based on the results of the business impact analysis, establish continuity requirements for the network and information systems.” | The business impact analysis and the maximum tolerable downtime (RR-03) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.4 — “The business continuity plan and disaster recovery plan shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks. The relevant entities shall ensure that the plans incorporate lessons learnt from such tests.” | Tests and reviews at set intervals and after significant incidents, with lessons written into the plans (RR-14, RR-16) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.1 — “The relevant entities shall maintain backup copies of data and provide sufficient available resources, including facilities, network and information systems and staff, to ensure an appropriate level of redundancy.” | Backups, and alternatives for single points of failure (RR-09, RR-11) |
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 | Backups as often as the recovery point needs, one copy out of reach of production credentials, checked before a restore (RR-11) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.3.1 — “The relevant entities shall put in place a process for crisis management.” | Roles and decisions in a crisis (RR-17, RR-19) |
DORA — Regulation (EU) 2022/2554 | Article 5(2)(e) — the management body shall “approve, oversee and periodically review the implementation of the financial entity’s ICT business continuity policy and ICT response and recovery plans, referred to, respectively, in Article 11(1) and (3)” | Approval by the approver, and the yearly report to it (RR-20) |
DORA — Regulation (EU) 2022/2554 | Article 11(1) — as part of the ICT risk management framework and based on the identification requirements of Article 8, “financial entities shall put in place a comprehensive ICT business continuity policy, which may be adopted as a dedicated specific policy, forming an integral part of the overall business continuity policy of the financial entity” | The whole policy: continuity of ICT services within the organisation's wider continuity arrangements |
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) | Plans, the recovery order, crisis roles and the hand-off from incident response (RR-07, RR-08, RR-17) |
DORA — Regulation (EU) 2022/2554 | Article 11(5) — “As part of the overall business continuity policy, financial entities shall conduct a business impact analysis (BIA) of their exposures to severe business disruptions.” The BIA uses quantitative and qualitative criteria, internal and external data and scenario analysis; considers the criticality of business functions, support processes, third-party dependencies and information assets and their interdependencies; and ICT assets and services are designed and used in full alignment with it, in particular to ensure “the redundancy of all critical components” | The business impact analysis and the dependencies (RR-03, RR-09) |
DORA — Regulation (EU) 2022/2554 | Article 11(6) — test the ICT business continuity plans and the ICT response and recovery plans “in relation to ICT systems supporting all functions at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”, and test the crisis communication plans (Article 14); financial entities other than microenterprises include in the testing plans “scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities”; the policy and plans are regularly reviewed taking into account test results and recommendations from audit checks or supervisory reviews | Recovery tests, including cyberattack scenarios, at least yearly and after significant change (RR-07, RR-14) |
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 | Backup frequency set from each service's recovery point (RR-11) |
DORA — Regulation (EU) 2022/2554 | Article 12(6) — “In determining the recovery time and recovery point objectives for each function, financial entities shall take into account whether it is a critical or important function and the potential overall impact on market efficiency. Such time objectives shall ensure that, in extreme scenarios, the agreed service levels are met.” | Recovery time and recovery point objectives for each critical service (RR-04) |
DORA — Regulation (EU) 2022/2554 | Article 16(1) — “Articles 5 to 15 of this Regulation shall not apply to” small and non-interconnected investment firms, exempted payment institutions, institutions exempted under Directive 2013/36/EU where the Member State has not applied the Article 2(4) option, exempted electronic money institutions, and small institutions for occupational retirement provision; those entities instead apply the simplified ICT risk management framework | Which laws ask for this: the entities under the simplified framework |
DORA — Regulation (EU) 2022/2554 | Article 16(1)(f) — the entities under the simplified ICT risk management framework “ensure the continuity of critical or important functions, through business continuity plans and response and recovery measures, which include, at least, back-up and restoration measures” | Which laws ask for this: plans with backup and restoration measures, for the entities under the simplified framework |
DORA — Delegated Regulation (EU) 2024/1774 | Article 24(1) — the ICT business continuity policy (DORA Article 11(1)) includes a description of its objectives, “including the interrelation of ICT and overall business continuity, and considering the results of the business impact analysis (BIA)”, its scope including limitations and exclusions, the timeframe covered, and “the criteria to activate and deactivate ICT business continuity plans, ICT response and recovery plans, and crisis communications plans”; and provisions on governance, roles, responsibilities and escalation, alignment of ICT and overall business continuity plans, plans for severe business disruptions, testing and review, and crisis communication | Purpose, scope, invoking the plans, roles, testing and review |
DORA — Delegated Regulation (EU) 2024/1774 | Article 39(2) — for the entities under the simplified framework (DORA Article 16(1)), the ICT business continuity plans are approved by the management body, documented and readily accessible in an emergency, adequately resourced, “establish planned recovery levels and timeframes for the recovery and resumption of functions and key internal and external dependencies, including ICT third-party service providers”, identify activation conditions, restoration and recovery measures and backup procedures, consider alternative options, specify communication and escalation arrangements, and are updated in line with lessons learned | Recovery times for services and their dependencies, for the entities under the simplified framework (RR-04, RR-09) |
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” | Dependencies and single points of failure of the systems that hold personal data (RR-09) |
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” | Restoring personal data in time from checked backups (RR-11, RR-12) |
ISO 22301:2019 incl. Amd 1:2024 | Security and resilience — Business continuity management systems — Requirements (cited by number and title only) | Which laws ask for this: the business continuity management system standard, by number and title only |
DORA — Delegated Regulation (EU) 2024/1774 | Article 40(1) — the entities under the simplified framework test their business continuity plans, including the scenarios referred to in Article 39, “at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan” | Yearly tests of backup and restore, for the entities under the simplified framework (RR-14) |
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.