Business continuity plan: the clause the question tests
Whether the service keeps running through a disruption, on a written and exercised plan.
How the customer usually asks it
example"Do you have a documented business continuity plan tested at least annually?"
Anchor clauses
7 frameworks| Framework | Anchor clause |
|---|---|
| ISO/IEC 27001:2022 | 5.29 Information security during disruption · 5.30 ICT readiness for business continuity |
| SOC 2 (Trust Services Criteria) | A1.3 Recovery plan procedures support system recovery from failures |
| SIG (Shared Assessments) | domain K Business Resiliency |
| CSA Cloud Controls Matrix v4.0.1 | BCR-04 Business Continuity Planning · BCR-06 Business Continuity Exercises |
| NIST Cybersecurity Framework 2.0 | RC.RP-01 The recovery portion of the incident response plan is executed once initiated from the incident response process |
| NIST SP 800-53 Rev 5 | CP-2 Contingency plan |
| HIPAA Security Rule (45 CFR 164) | 164.308(a)(7)(i) Contingency Plan (Standard) |
Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.
Evidence expected
The continuity plan covering the service, the business impact analysis behind it, and the report of the last exercise with its actions.
The clauses, with what an assessor asks for
ISO 27001 5.29 Information security during disruptionPlan how to keep information security at the right level during disruption.
Where answers usually fall short: Plans not updated after tests; Missing documented approval for temporary control changes
Source: ISO/IEC 27001:2022
ISO 27001 5.30 ICT readiness for business continuityPlan, implement, maintain and test ICT readiness against business continuity objectives.
Where answers usually fall short: Testing frequency not aligned with risk; Plans not updated after infrastructure changes
Source: ISO/IEC 27001:2022
SOC 2 A1.3 Recovery plan procedures support system recovery from failuresNamed, not quoted: the criteria text is not held in full here.
Where answers usually fall short: Testing limited to a walkthrough or a single file restore, which does not test the recovery plan procedures the criterion names; Restore performed with no verification the recovered data was complete and usable
Source: SOC 2 (Trust Services Criteria)
SIG domain K Business ResiliencyWhat it asks for, in one line (the standard's own text is not quoted here):
Maintain business continuity and disaster recovery programs including business impact analysis, recovery objectives, plans, periodic testing, and dependencies on third party providers.
Where answers usually fall short: RTO and RPO not validated against tested recovery; Critical supplier failover untested
Source: SIG (Shared Assessments)
CSA CCM BCR-04 Business Continuity PlanningWhat it asks for, in one line (the standard's own text is not quoted here):
Write a business continuity plan that implements the chosen resilience strategies, and keep it approved, communicated and maintained.
Where answers usually fall short: Plan holders carrying superseded versions; Plan contents not traceable to any strategy or impact analysis
Source: CSA Cloud Controls Matrix v4.0.1
CSA CCM BCR-06 Business Continuity ExercisesWhat it asks for, in one line (the standard's own text is not quoted here):
Run a live exercise of the continuity and resilience plans every year, repeat it whenever something significant changes, and feed what the exercise exposes back into the plans.
Where answers usually fall short: Walkthrough discussions recorded as exercises without anything being tested; Findings raised at each exercise and never closed before the next
Source: CSA Cloud Controls Matrix v4.0.1
NIST CSF RC.RP-01 The recovery portion of the incident response plan is executed once initiated from the incident response processThe recovery portion of the incident response plan is executed once initiated from the incident response process
Where answers usually fall short: Triggers unclear in the plan; Execution log incomplete during incidents
Source: NIST Cybersecurity Framework 2.0
SP 800-53 CP-2 Contingency planRequires a contingency plan that identifies essential mission and business functions and their contingency requirements, sets recovery objectives, priorities and metrics, assigns roles and contacts, addresses operating through disruption and full restoration without weakening controls, is approved by defined personnel, distributed to defined recipients, coordinated with related plans, reviewed on a defined frequency and updated after change or testing.
Where answers usually fall short: Plan lists systems but never identifies the business functions they support; Contact details stale, naming people who left the organization
Source: NIST SP 800-53 Rev 5
HIPAA 164.308(a)(7)(i) Contingency Plan (Standard)Establish policies for responding to emergencies that damage ePHI systems. NIST recommends contingency planning per SP 800-34 with business impact analysis driving recovery priorities.
Where answers usually fall short: BIA not performed; RTO and RPO undefined
Source: HIPAA Security Rule (45 CFR 164)