ICT Readiness for Business Continuity Plan Template (ISO/IEC 27001 A.5.30)

ICT continuity requirements from the BIA, RTO and RPO per service, measured capability and gaps, strategies, recovery order, test programme, size tiers

ISMS và ISO/IEC 27001Đầy đủISO/IEC 27001:2022 + Amd 1:2024 A.5.29, A.5.30 (cited only); ISO/IEC 27031:2025; ISO 22301:2019 + Amd 1:2024ict readiness business continuity planCập nhật 1 thg 11, 2026

Mở trong editorTải .md

Cách dùng: Use it when you must show that ICT services can meet the recovery objectives set by the business impact analysis (A.5.30). Fill the BIA requirements and the per-service objectives with measured test results first. The main pitfall is writing RTO and RPO values that describe what current backups deliver instead of what the business needs.

Xem trước

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.

Document control

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)

Purpose, scope and relationship to other plans
Roles and responsibilities
ICT continuity requirements from the BIA
ICT services, recovery objectives and measured capability
Gap analysis and improvement actions
ICT continuity strategies
Readiness: prevention, detection and security during disruption
Activation and recovery procedures
Testing and exercising
Performance measures
Size tiers
Records and evidence
Review and maintenance
References

1. Purpose, scope and relationship to other plans

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].

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

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

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

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

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

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

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

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.

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

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

9. Testing and exercising

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

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

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

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

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

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

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.

Template liên quan

ISMS và ISO/IEC 27001