# ICT Readiness for Business Continuity Plan: [Organization name]

> Plan that makes sure the information and communication technology (ICT)
> services behind prioritized business activities can be kept running or
> restored within the time and data-loss objectives set by the business
> impact analysis. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A
> control A.5.30 (ICT readiness for business continuity, new in 2022) and
> control A.5.29 (security during disruption), and follows the approach of
> ISO/IEC 27031:2025 (ICT readiness for business continuity) within a
> business continuity programme aligned with ISO 22301:2019 + Amd 1:2024.
> It sits between the business continuity plan and the technical disaster
> recovery plan. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Use it when the organization has a business impact analysis (BIA) or
  is writing one, and needs to show that ICT can meet the recovery
  objectives the business has set. Certification auditors look for this
  link under A.5.30: objectives come from the BIA, ICT capability is
  measured against them, and gaps are treated.
- Fill section 3 (requirements from the BIA) and section 4 (service
  objectives and measured capability) first. Every later section depends
  on those two tables.
- Main pitfall: writing RTO and RPO values that describe what the current
  backups happen to deliver, instead of what the business needs. The BIA
  sets the requirement; this plan proves or improves the capability.
- Keep step-by-step technical recovery in the disaster recovery plan
  (`ops/disaster-recovery-plan`) and restore steps in
  (`ops/backup-restore-procedure`). Link, do not copy.
- Related templates: `compliance/business-impact-analysis`,
  `compliance/business-continuity`, `ops/disaster-recovery-plan`,
  `ops/dr-test-report`, `compliance/incident-response-plan`,
  `isms/backup-policy`, `isms/backup-restore-test-log`,
  `isms/crisis-management-communications-plan`, `isms/cloud-exit-plan`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Treat this plan as controlled documented information (cl. 7.5). Auditors check that the version in use is approved, that the last test is recent and that the BIA it relies on is the current one. -->

| Field | Value |
|---|---|
| Document ID | [DOC-ISMS-047] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-it-operations] |
| Approvers/reviewers | [@ciso], [@business-continuity-lead], [@coo], [@isms-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.29, A.5.30, A.8.13, A.8.14); ISO/IEC 27031:2025; ISO 22301:2019 + Amd 1:2024 |
| Next scheduled review | YYYY-MM-DD (at least annually, after every activation and after every major test) |
| BIA reference | [DOC-ISMS-120, version and date] |
| Business continuity plan reference | [DOC-ISMS-121] |
| Disaster recovery plan reference | [DR plan ID and version] |
| Last test | [Test ID, date, result] |
| Offline copy location | [Encrypted copy outside the primary environment, printed copy at [site]] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Plan owner | [@head-of-it-operations] | [Prepared] | YYYY-MM-DD |
| Business continuity lead | [@business-continuity-lead] | [Reviewed] | YYYY-MM-DD |
| CISO or ISMS manager | [@ciso] | [Reviewed] | YYYY-MM-DD |
| Top management sponsor | [@coo] | [Approved / Approved with changes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.9 *(Example)* | YYYY-MM-DD | [@head-of-it-operations] | Draft built from BIA version 2.1 |
| 1.0 *(Example)* | YYYY-MM-DD | [@head-of-it-operations] | Approved after the first regional failover test (TST-002) |

## Contents

1. Purpose, scope and relationship to other plans
2. Roles and responsibilities
3. ICT continuity requirements from the BIA
4. ICT services, recovery objectives and measured capability
5. Gap analysis and improvement actions
6. ICT continuity strategies
7. Readiness: prevention, detection and security during disruption
8. Activation and recovery procedures
9. Testing and exercising
10. Performance measures
11. Size tiers
12. Records and evidence
13. Review and maintenance
14. References

## 1. Purpose, scope and relationship to other plans

<!-- Guidance: State which services, sites and cloud environments this plan covers and how it hands over to the BCP, the DR plan and the incident response plan. Questions: who decides that an ICT disruption becomes a continuity event? Which plan owns which step? Pitfall: three plans that each assume another plan restores the identity provider. An auditor checks that the hand-offs are named and tested. -->

This plan sets out how [Organization name] keeps the ICT services that
support its prioritized activities ready to continue or to recover within
the objectives approved in the BIA. It covers planning, the readiness
measures in place before a disruption, the decision to invoke recovery,
the recovery order and the tests that prove the plan works.

ICT readiness for business continuity (IRBC) is not a separate programme.
It is the ICT part of business continuity management, and it uses the
information security risk assessment to find the threats that could
disrupt ICT services. ISO/IEC 27031:2025 describes this readiness view.
For ISO/IEC 27001:2022 control A.5.30, the point to prove is simple:
the recovery the business asked for in the BIA is what IT has designed
for and has shown it can deliver, not a figure nobody tested (read the
official control text for the exact requirement).

In scope:

- ICT services: [production platform, data pipelines, identity provider,
  corporate e-mail and collaboration suite, source code and build
  pipeline, support desk tooling]
- Environments: [primary cloud region, secondary cloud region, office
  network, colocation suite]
- Suppliers whose services are part of the recovery path: [cloud
  provider, DNS provider, identity provider, backup service]

Out of scope: [business process workarounds, which belong to the BCP;
physical safety, which belongs to the emergency plan].

```mermaid
flowchart LR
  BIA["Business impact analysis (DOC-ISMS-120)"] --> REQ["ICT continuity requirements (section 3)"]
  RA["Risk register (DOC-ISMS-016)"] --> REQ
  REQ --> IRBC["This ICT readiness plan (DOC-ISMS-047)"]
  IRBC --> DR["Disaster recovery plan: technical steps"]
  IRBC --> BRP["Backup and restore procedure"]
  BCP["Business continuity plan (DOC-ISMS-121)"] -- "invokes" --> IRBC
  IRP["Incident response plan (DOC-ISMS-020)"] -- "escalates disruption" --> IRBC
  IRBC -- "test results" --> MR["Management review (DOC-ISMS-085)"]
```

| Plan | Owns | Hands over to this plan when |
|---|---|---|
| Business continuity plan (DOC-ISMS-121) | Business response, workarounds, prioritized activities | A business activity needs an ICT service restored or switched |
| Incident response plan (DOC-ISMS-020) | Detection, containment and eradication of security incidents | Containment requires a service to be rebuilt, failed over or restored from backup |
| Crisis management and communications plan (DOC-ISMS-078) | Strategic decisions and external communication | The crisis team decides to invoke ICT recovery or accept degraded service |
| This plan (DOC-ISMS-047) | ICT objectives, readiness, recovery order, ICT tests | Recovery is complete and the service returns to normal operations |
| Disaster recovery plan | Technical runbooks per system | Not applicable: it is the execution layer of this plan |

## 2. Roles and responsibilities

<!-- Guidance: Name roles, not people, and give each a deputy. Questions: who can declare an ICT continuity event out of hours? Who approves accepting a missed RTO? Pitfall: the only person who can run a failover is also the incident commander. -->

| Role | Responsibilities | Primary | Deputy |
|---|---|---|---|
| Plan owner | Keeps this plan current, runs the test programme, reports results | [@head-of-it-operations] | [@platform-lead] |
| ICT recovery manager | Leads recovery once invoked, decides recovery order within section 8.3 | [@platform-lead] | [@sre-on-call-lead] |
| Service owners | Confirm objectives for their service, verify recovery, sign off return to service | [@service-owner] | [@deputy] |
| Business continuity lead | Translates BIA results into requirements, links this plan to the BCP | [@business-continuity-lead] | [@deputy] |
| CISO or ISMS manager | Ensures security controls stay in place during disruption (A.5.29), tracks gaps as risks | [@ciso] | [@isms-manager] |
| Supplier manager | Holds supplier recovery commitments and contacts | [@supplier-manager] | [@procurement] |
| Top management sponsor | Approves objectives, funding and any accepted gap | [@coo] | [@ceo] |

| Activity *(Example)* | Plan owner | ICT recovery manager | Service owner | BC lead | CISO | Sponsor |
|---|---|---|---|---|---|---|
| Set RTO and RPO | C | C | R | R | C | A |
| Maintain readiness measures | A | R | C | I | C | I |
| Invoke ICT recovery | C | R | C | C | I | A |
| Verify and return to service | I | R | A | I | C | I |
| Run tests and record results | A | R | R | C | C | I |
| Accept an unresolved gap | R | C | C | C | C | A |

## 3. ICT continuity requirements from the BIA

<!-- Guidance: Copy the prioritized activities and their objectives from the current BIA, then list every ICT service each activity depends on. Questions: which ICT services sit under more than one activity? Does every dependency inherit the strictest RTO? Pitfall: forgetting shared services such as identity, DNS, certificates and secrets, which every other service needs first. -->

Rule: an ICT service inherits the shortest RTO and the shortest RPO of the
activities that depend on it. Shared foundation services (identity, DNS,
network, secrets, logging) must be available before the services that
depend on them, so their RTO is shorter than that of any dependent
service.

| Activity (from BIA) | MTPD | Activity RTO | Activity RPO | ICT services required | Notes |
|---|---|---|---|---|---|
| ACT-01 *(Example)* Customer dashboards and API | 12 h | 4 h | 15 min | SVC-001, SVC-002, SVC-003 | Contract service level: 99.9% monthly availability |
| ACT-02 *(Example)* Data ingestion from customer sources | 24 h | 8 h | 1 h | SVC-002, SVC-003 | Sources can re-send up to 24 h of data |
| ACT-03 *(Example)* Customer support | 48 h | 24 h | 4 h | SVC-003, SVC-004 | Phone fallback for priority customers |
| ACT-04 *(Example)* Software release and hotfixes | 96 h | 48 h | 24 h | SVC-003, SVC-005 | Hotfix path needed for security fixes |
| [ACT-NN] | [h] | [h] | [min / h] | [SVC-NNN] | [note] |

ICT requirements other than time objectives, from the BIA and the risk
assessment:

- Minimum capacity during disruption: [for example, 60% of normal API
  throughput for ACT-01].
- Security level during disruption: the same classification rules,
  access control and logging as normal operations (section 7.3).
- Data residency during failover: [both regions must be in the same
  legal jurisdiction as agreed in customer contracts].
- Contractual and legal requirements: [customer service levels, sector
  rules such as the ICT continuity duties in DORA for financial entities,
  NIS2 national measures where applicable], recorded in the legal register
  (DOC-ISMS-014).

## 4. ICT services, recovery objectives and measured capability

<!-- Guidance: One row per ICT service. "Measured capability" is the recovery time and data loss actually achieved in the last test, not the design value. Questions: when was each value last measured? Which services have never been tested? Pitfall: listing design values as capability, which hides the gap an auditor will find in the test report. -->

| Service ID | ICT service | Depends on | Required RTO | Required RPO | Strategy (section 6) | Measured recovery time | Measured data loss | Last test | Status |
|---|---|---|---|---|---|---|---|---|---|
| SVC-003 *(Example)* | Identity provider (SaaS) | Supplier, DNS | 2 h | Not applicable (configuration exported daily) | Supplier resilience plus break-glass accounts | 45 min (break-glass sign-in) | None | TST-001 YYYY-MM-DD | Meets |
| SVC-001 *(Example)* | Analytics platform and API | SVC-003, SVC-002 | 4 h | 15 min | Warm standby in secondary region | 6 h 10 min | 12 min | TST-002 YYYY-MM-DD | Gap on RTO |
| SVC-002 *(Example)* | Customer data store and pipeline | SVC-003 | 4 h | 15 min | Cross-region replication plus immutable backups | 3 h 20 min | 12 min | TST-002 YYYY-MM-DD | Meets |
| SVC-004 *(Example)* | Support ticketing (SaaS) | SVC-003 | 24 h | 4 h | Supplier resilience, daily export | Not tested | Not tested | None | Untested |
| SVC-005 *(Example)* | Source code and build pipeline | SVC-003 | 48 h | 24 h | Hosted repository plus nightly mirror | 30 h | 0 (mirror current) | TST-003 YYYY-MM-DD | Meets |
| [SVC-NNN] | [service] | [dependencies] | [h] | [min / h] | [strategy] | [measured] | [measured] | [test ID] | [Meets / Gap / Untested] |

SVC-002 carries a 4 h RTO, which is stricter than the 8 h needed by
ACT-02, because ACT-01 also depends on it (rule in section 3). SVC-003
has a 2 h RTO because every other service needs sign-in first. Its data
is held by the supplier, so its recovery point is covered by supplier
evidence, and the daily configuration export protects the settings.

Status values: **Meets** (measured values within required values),
**Gap** (one measured value outside the requirement), **Untested** (no
measurement in the last 12 months). Untested counts as a gap for
reporting.

Tier values: **Tier 1** is any service with a required RTO of 4 h or
less (SVC-001, SVC-002 and SVC-003 in the example); **Tier 2** is any
other service in scope. Sections 8 to 10 use these tiers.

## 5. Gap analysis and improvement actions

<!-- Guidance: Every Gap or Untested row in section 4 needs an action or a documented risk acceptance. Questions: is the gap a design problem (strategy cannot meet the objective) or an execution problem (runbook, people, automation)? Pitfall: closing a gap by relaxing the RTO without going back to the BIA owner. -->

| Gap ID | Service | Gap | Cause | Action | Owner | Due | Risk reference | Status |
|---|---|---|---|---|---|---|---|---|
| GAP-001 *(Example)* | SVC-001 | Recovery took 6 h 10 min against a 4 h RTO | Manual database promotion and DNS change took 3 h 40 min | Automate promotion and DNS switch, rehearse quarterly | [@platform-lead] | YYYY-MM-DD | RISK-014, RTP-022 | Open |
| GAP-002 *(Example)* | SVC-004 | Never tested | Supplier test reports not requested | Obtain supplier continuity evidence, test ticket export restore | [@supplier-manager] | YYYY-MM-DD | RISK-019 | Open |
| [GAP-NNN] | [SVC-NNN] | [gap] | [cause] | [action] | [@owner] | YYYY-MM-DD | [RISK-NNN] | [Open / Closed / Accepted] |

A gap that remains open past its due date is escalated to the ISMS
steering committee (DOC-ISMS-007). A gap that management decides not to
close is recorded as a risk acceptance (DOC-ISMS-019) using the
acceptance authority of the risk methodology (DOC-ISMS-010): High
residual risk needs top management acceptance.

## 6. ICT continuity strategies

<!-- Guidance: For each ICT service choose a strategy that can meet its objectives at a cost the business accepts, and record why. Cover technology, data, people, facilities and suppliers. Questions: which single points of failure remain? Can the strategy survive the loss of the primary cloud account, not only the primary region? Pitfall: replication without immutable backups, which copies ransomware encryption to the standby within seconds. -->

### 6.1 Strategy options

| Strategy | Typical recovery time | Typical data loss | Cost | Fits when |
|---|---|---|---|---|
| Active-active across regions or sites | Minutes | Near zero | Highest | RTO under 1 h, revenue or safety critical |
| Warm standby (scaled-down copy, data replicated) | 1 to 8 h | Minutes | High | RTO of a few hours |
| Pilot light (core data replicated, compute built on demand) | 4 to 24 h | Minutes to 1 h | Medium | RTO of a working day |
| Backup and restore to new infrastructure | 24 h or more | Backup interval | Low | RTO of days |
| Supplier resilience (SaaS) plus data export | Supplier dependent | Export interval | Low | Commodity SaaS with credible supplier evidence |
| Manual workaround (owned by the BCP) | Not an ICT recovery | Re-entry needed | Low | Short outages of low-volume activities |

These ranges are *Example* planning values. Confirm them with your own
tests before relying on them.

### 6.2 Strategy by resource

| Resource | Strategy *(Example, Quillmere Analytics Ltd)* | Your strategy |
|---|---|---|
| Technology | Warm standby of the platform in the secondary cloud region, infrastructure as code for rebuild | [strategy] |
| Data | Continuous replication to the secondary region plus daily immutable backups in a separate account with separate credentials (see `isms/backup-policy`) | [strategy] |
| Identity and access | Break-glass accounts with hardware keys stored in two places, tested every quarter | [strategy] |
| People | Two engineers trained on each runbook, on-call rota covering every hour | [strategy] |
| Facilities | Fully remote capable; office loss does not affect production | [strategy] |
| Suppliers | Contract clauses for supplier continuity evidence; exit plan for the cloud provider (`isms/cloud-exit-plan`) | [strategy] |
| Communications | Status page hosted outside the production environment, out-of-band chat channel | [strategy] |

### 6.3 Strategy decision record

| Decision ID | Service | Options considered | Chosen | Reason | Annual cost (USD) | Approved by |
|---|---|---|---|---|---|---|
| STR-001 *(Example)* | SVC-001 | Active-active, warm standby, pilot light | Warm standby | Meets 4 h RTO after GAP-001 automation; active-active cost not justified by BIA | 38,000 | [@coo] YYYY-MM-DD |
| STR-002 *(Example)* | SVC-002 | Replication only, replication plus immutable backup | Replication plus immutable backup | Replication alone fails against ransomware (RISK-009) | 12,000 | [@coo] YYYY-MM-DD |
| [STR-NNN] | [SVC-NNN] | [options] | [chosen] | [reason] | [amount] | [@approver] |

Costs are *Example* values in USD; use your local currency.

## 7. Readiness: prevention, detection and security during disruption

<!-- Guidance: ICT readiness is more than recovery. List what reduces the chance of disruption, what detects it early and how security is kept during the response. Questions: how quickly is a regional outage detected? Which controls are relaxed during recovery, and who approves that? Pitfall: emergency access granted during recovery and never removed. -->

### 7.1 Prevention

| Measure | Control reference | Evidence |
|---|---|---|
| Redundant processing in two regions or sites | A.8.14 | Architecture diagram, failover test |
| Backups with immutability and separate credentials | A.8.13 | Backup job reports, restore test log (DOC-ISMS-071) |
| Capacity monitoring and headroom | A.8.6 | Capacity plan (`ops/capacity-plan`) |
| Change management with rollback | A.8.32 | Change records (`ops/change-request`) |
| Supplier continuity commitments | A.5.19 to A.5.22 | Supplier register (DOC-ISMS-066), contract clauses |
| Vulnerability and patch management | A.8.8 | Remediation tracker (DOC-ISMS-072) |

### 7.2 Detection

- Health checks from outside the hosting provider for each service in
  section 4, alerting the on-call engineer within [5] minutes.
- Monitoring of replication lag against the RPO: alert when lag exceeds
  [50%] of the RPO.
- Backup job failure alerts and a weekly review of missed jobs.
- Security monitoring (`isms/security-monitoring-procedure`) for signs
  that a disruption is a security incident, such as mass encryption or
  deletion.

### 7.3 Security during disruption

Information security requirements continue to apply during disruption
(A.5.29). Plan any temporary change in advance rather than improvising:

| Situation | Pre-approved temporary measure | Limit | Restored by |
|---|---|---|---|
| Normal privileged access tooling unavailable | Break-glass accounts, every use logged and reviewed | Duration of the event | Password and key rotation within 24 h of stand-down |
| Logging pipeline down in the primary region | Local log retention on standby hosts, forwarded once the pipeline returns | 72 h | ICT recovery manager |
| Recovery in the secondary region | Same network rules, encryption and access groups as primary (built from code) | None: no relaxation | Not applicable |
| Third-party responders need access | Named, time-limited accounts approved by the CISO | 7 days | Access review after stand-down |

Any measure not listed here needs approval by the CISO or deputy and is
recorded in the recovery log.

## 8. Activation and recovery procedures

<!-- Guidance: Describe how the plan is invoked, in which order services come back and how return to normal is decided. Keep technical commands in the DR runbooks. Questions: what is the maximum time from detection to a decision? Who can decide alone out of hours? Pitfall: waiting for full diagnosis before invoking failover, which consumes the RTO. -->

### 8.1 Activation criteria

Invoke this plan when any of these is true:

- a service in section 4 is unavailable, or expected to be, for longer
  than [50%] of its RTO;
- data loss is expected to exceed the RPO of any service;
- the incident response plan requires a rebuild or restore as part of
  containment or recovery;
- the business continuity lead or crisis team requests ICT recovery.

The ICT recovery manager decides. If the expected outage is longer than
the RTO of a Tier 1 service, the decision is reported to the crisis team
(DOC-ISMS-078) at once.

### 8.2 Recovery states

The diagram shows the states a disrupted service moves through. A
service stays in degraded operation on the standby until the primary is
rebuilt and verified; stand-down is a decision, not an automatic step.

```mermaid
stateDiagram-v2
  [*] --> Normal
  Normal --> Assessment: Disruption detected
  Assessment --> Normal: Resolved within threshold
  Assessment --> Invoked: Activation criteria met
  Invoked --> Recovering: Recovery order started
  Recovering --> Verification: Services restored
  Verification --> Recovering: Checks fail
  Verification --> DegradedOperation: Running on standby
  DegradedOperation --> Return: Primary rebuilt and verified
  Return --> Normal: Stand-down approved
```

### 8.3 Recovery order

| Order | Service | Target time from invocation *(Example)* | Runbook | Verification |
|---|---|---|---|---|
| 1 | SVC-003 Identity provider and break-glass access | 0 h to 2 h | DR-RB-01 | Engineers and support staff can sign in |
| 2 | Network, DNS and secrets in the standby region | 0 h to 1 h, in parallel | DR-RB-02 | DNS resolves to standby, secrets readable by services |
| 3 | SVC-002 Customer data store and pipeline | 1 h to 4 h | DR-RB-03 | Row counts and checksums match the last replicated point |
| 4 | SVC-001 Analytics platform and API | 2 h to 4 h | DR-RB-04 | Synthetic customer journey passes, error rate under 1% |
| 5 | SVC-004 Support ticketing | Supplier dependent, by 24 h | Supplier status, DR-RB-05 | Agents can open and update tickets |
| 6 | SVC-005 Source code and build pipeline | By 48 h | DR-RB-06 | A test build and deploy completes |

### 8.4 Return to normal operations

1. Service owners confirm the primary environment is rebuilt, patched
   and verified against the same checks as section 8.3.
2. The CISO confirms that temporary measures from section 7.3 are
   reversed, and that credentials used during the event are rotated.
3. Data written to the standby is reconciled and replicated back.
4. The ICT recovery manager plans the fail-back as a change
   (`ops/change-request`) during a low-traffic window.
5. The plan owner records the timeline and measured values in the
   recovery log and opens actions for any gap.

## 9. Testing and exercising

<!-- Guidance: Testing produces the "measured capability" figures in section 4. Plan a mix of test types so that every Tier 1 service is technically tested at least once a year. Questions: which test proves the full chain, including identity and DNS? Who observes and records? Pitfall: tests that always succeed because they skip the hard parts (restoring from immutable backups, failing over without the primary). -->

| Test type | What it proves | Frequency *(Example)* | Evidence |
|---|---|---|---|
| Plan walkthrough | Contacts, roles and steps are current | Quarterly | Attendance and change list |
| Tabletop exercise | Decisions and hand-offs between plans work | Twice a year, one jointly with the crisis team | Exercise report (`security/tabletop-exercise`) |
| Component restore test | A backup can be restored within RPO and on time | Monthly sample per Tier 1 data store | Restore test log (DOC-ISMS-071) |
| Failover test | A service runs in the standby site within its RTO | Twice a year covering every Tier 1 service (one regional failover can cover several) | DR test report (`ops/dr-test-report`) |
| Full recovery simulation | All services recover in order without the primary | Once a year | DR test report, gap list |
| Supplier test participation or evidence | Supplier commitments hold | Annually per critical supplier | Supplier test summary or assurance report |

```mermaid
gantt
  title ICT readiness test programme 2027 (Example)
  dateFormat YYYY-MM-DD
  section Walkthroughs
  Q1_walkthrough :w1, 2027-01-18, 1d
  Q2_walkthrough :w2, 2027-04-19, 1d
  Q3_walkthrough :w3, 2027-07-19, 1d
  Q4_walkthrough :w4, 2027-10-18, 1d
  section Technical tests
  Tier1_regional_failover_H1 :t1, 2027-03-08, 2d
  Full_recovery_simulation :t2, 2027-06-14, 3d
  Tier1_regional_failover_H2 :t3, 2027-09-13, 2d
  section Exercises
  Tabletop_with_crisis_team :e1, 2027-05-10, 1d
  Tabletop_ransomware :e2, 2027-11-08, 1d
```

Each test has a written scope, success criteria taken from section 4, a
named observer who is not running the recovery, and a report that
records measured times, data loss, deviations and actions. Feed actions
into section 5 and the risk treatment plan (DOC-ISMS-013).

## 10. Performance measures

<!-- Guidance: Choose a few measures that show readiness to top management. Report them in the ISMS performance report (DOC-ISMS-081). Pitfall: measuring the number of tests instead of whether objectives were met. -->

| Measure | Target *(Example)* | Source |
|---|---|---|
| Tier 1 services with measured recovery within RTO in the last 12 months | 100% | Section 4 |
| Services untested in the last 12 months | 0 | Section 4 |
| Restore tests meeting RPO | At least 95% | Restore test log (DOC-ISMS-071) |
| Open gaps past due date | 0 | Section 5 |
| Mean time from detection to invocation decision in tests and real events | Under 30 min | Recovery logs, test reports |

Worked example for Quillmere Analytics Ltd: five services in section 4,
three meet, one has an RTO gap and one is untested. Services meeting
their objectives: 3 of 5, or 60%. Tier 1 services (SVC-001, SVC-002,
SVC-003) within RTO: 2 of 3, or 67%. Both figures go to the next
management review with GAP-001 and GAP-002.

## 11. Size tiers

<!-- Guidance: The control is the same at every size; the depth of the plan, the strategies and the test programme change. Use the tier closest to you and adapt. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Plan shape | One plan covering 5 services, owned by the Head of Engineering Operations, who is also the part-time ISMS manager | One plan plus one annex per service line (scheduling platform, managed service, corporate IT) | Group plan with site annexes for 3 plants, the service centre, the data centre and HQ, including OT recovery |
| Recovery environment | Secondary region of the same cloud provider | Secondary region for the SaaS platform, colocation suite rebuilt from backup for legacy systems | Group data centre plus cloud; plant OT recovered locally with spare controllers and offline images |
| Typical strictest RTO | 4 h | 2 h for hospital-facing scheduling | 1 h for production control systems at plants |
| Test programme | 2 failover tests, 1 full simulation, quarterly walkthroughs | Failover per service line twice a year, joint test with key hospital customers | Rolling site tests, annual group simulation aligned with the existing ISO 22301 exercise programme |
| Integration | BIA, BCP and this plan maintained by the same small team | 3-person security team reviews security during disruption | Integrated management system: this plan is the ICT annex of the certified ISO 22301 BCMS |

## 12. Records and evidence

<!-- Guidance: List the records that prove this plan operates. Auditors under A.5.30 usually ask for the BIA link, the objectives, the last test report and evidence that gaps are treated. Map each record in the control evidence matrix (`isms/control-evidence-matrix`). -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Approved plan and revision history | Plan is controlled and current | Plan owner | Document management system | Current plus 3 superseded versions |
| BIA extract with ICT requirements (section 3) | Objectives come from the business | Business continuity lead | BIA repository (DOC-ISMS-120) | 3 years |
| Test plans and reports | Capability is measured | Plan owner | `ops/dr-test-report` records | 3 years |
| Restore test log | Backups meet RPO | ICT recovery manager | DOC-ISMS-071 | 3 years |
| Gap and action list (section 5) | Gaps are treated | Plan owner | Risk treatment plan (DOC-ISMS-013) | Until closed plus 3 years |
| Recovery logs from real events | Plan is used and improved | ICT recovery manager | Incident register (DOC-ISMS-021) | 3 years |
| Supplier continuity evidence | Supplier commitments are checked | Supplier manager | Supplier register (DOC-ISMS-066) | Contract term plus 3 years |
| Management review input | Top management sees readiness | ISMS manager | Management review minutes (DOC-ISMS-085) | 3 years |

Retention periods are *Example* values; set them in the documented
information register (DOC-ISMS-028) to cover at least one full
certification cycle and any legal requirement.

## 13. Review and maintenance

<!-- Guidance: Tie reviews to events as well as the calendar. Questions: who tells the plan owner about a new service or supplier? Pitfall: a plan that still lists a service decommissioned a year ago. -->

Review this plan at least once a year and also when:

- the BIA is updated or a new prioritized activity is added;
- a new ICT service, region, site or critical supplier enters scope;
- a test or real event shows a gap or a wrong assumption;
- architecture changes alter dependencies or recovery order;
- a new legal, regulatory or contractual continuity requirement applies.

Contacts and runbook references are checked every quarter during the
walkthrough. Changes follow document control (DOC-ISMS-028), and results
go to management review (cl. 9.3).

## 14. References

<!-- Guidance: Cite editions exactly and read the official text before relying on any summary in this template. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, information security management systems, requirements | 2022, Amd 1 published 2024-02-23 | A.5.29, A.5.30, A.8.13, A.8.14 |
| ISO/IEC 27002:2022, information security controls | 2022 | Guidance for the controls above |
| ISO/IEC 27031:2025, ICT readiness for business continuity | 2025 | IRBC concepts, planning and testing approach |
| ISO 22301:2019 + Amd 1:2024, business continuity management systems, requirements | 2019, Amd 1 2024 | BIA, strategies, exercising |
| NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems | May 2010, updated November 2010 | Optional public reference for contingency plan structure |
| NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities | September 2006 | Optional public reference for test design |

Official pages: ISO/IEC 27001 https://www.iso.org/standard/82875.html,
Amd 1 https://www.iso.org/standard/88435.html, ISO/IEC 27002
https://www.iso.org/standard/75652.html, ISO/IEC 27031
https://www.iso.org/standard/80975.html, ISO 22301
https://www.iso.org/standard/75106.html.

Related templates: `compliance/business-impact-analysis`,
`compliance/business-continuity`, `ops/disaster-recovery-plan`,
`ops/backup-restore-procedure`, `ops/dr-test-report`,
`compliance/incident-response-plan`, `isms/backup-policy`,
`isms/backup-restore-test-log`, `isms/cloud-exit-plan`,
`isms/crisis-management-communications-plan`,
`isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 (including Amd 1:2024) Annex A
controls A.5.29 and A.5.30 and with the ICT readiness approach of ISO/IEC
27031:2025, within a business continuity programme aligned with ISO
22301:2019 + Amd 1:2024. The text, tables, examples and guidance are
original wording. ISO/IEC text is not reproduced: control numbers are
given with short descriptive labels written for this template, which are
not the official titles or control text. ISO and IEC standards are
copyrighted; obtain the official standards from ISO or your national
standards body before relying on this template. Check the current
edition and amendments of each standard before use. This is a
documentation format, not certification advice. Template licence: MIT.