Traceable-Answer Reference / Business Continuity Management and Operational Resilience
BCR-05 — Documentation
Develop and periodically review continuity/resilience documentation and make it available to authorized stakeholders.
Every framework that asks this
Answer BCR-05 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.
| Framework | Equivalent control(s) | Confidence |
|---|---|---|
| SOC 2 | CC7.4, CC7.5, CC8.1, CC9.1, A1.2, P6.0, P6.1, P6.4 | high |
| ISO 27001 | A.5.29 | medium |
| NIST CSF 2.0 | PR.IR-03, PR.IR-04, RC.RP-01, RC.CO-03 (domain-level) | high |
| NIST 800-53 | CP-2, CP-9, CP-10, CP-4 (domain-level) | high |
| SIG | IT Operations Management, Operational Resilience (domain-level) | medium |
Full provenance and NIST 800-53 mappings: the framework crosswalk.
What the reviewer is really checking
The reviewer is trying to establish that recovery is real and rehearsed, not a binder no one has opened. The surface question 'Do you have a business continuity and disaster recovery plan?' hides the ones that matter: What are your committed RTO (how fast you restore service) and RPO (how much data you can lose), and are they targets or contractually backed? How often are backups taken, where are they stored, are they encrypted and isolated from production so ransomware cannot reach them, and are they immutable? Most importantly, when did you last actually restore from a backup and verify the restore worked, versus assuming it would? What is your failover architecture across availability zones or regions, and is failover automated or manual? When did you last run a DR test or game-day exercise, what was the scenario, and what was the measured outcome against your RTO and RPO? The reviewer treats a DR plan with no test date as unproven, because the failure modes that break restores (corrupt backups, missing dependencies, expired credentials) only surface when you actually try.
What a truthful, defensible answer contains
A defensible answer states measurable targets and the last time you proved them. Give your RTO and RPO with units, and say whether they are internal objectives or SLA-backed commitments. Describe backup frequency, retention, storage location and geographic separation, encryption, and isolation or immutability from production. Then, the load-bearing part: state when you last performed a restore test and a DR failover exercise, what the scenario was, and the measured result, including whether you met or missed RTO/RPO and what you changed as a result. Describe the failover architecture (multi-AZ, multi-region, active-active or active-passive) and whether failover is automated. Note the cadence at which the plan is reviewed and tested, and who owns it. The detail that survives review is a recent, dated test with a concrete outcome. Avoid stating RTO/RPO you have never validated. If your last full DR test predates your current architecture, say so honestly rather than implying the number is proven.
Make it traceable
Anchor the answer to a dated artifact. Point at the most recent DR test report or game-day writeup that records the scenario, the measured RTO/RPO achieved, and remediation items, and at the backup and restore-testing schedule or logs showing restores actually ran. Reference the business continuity and disaster recovery policy for the committed targets, and the SOC 2 Availability criteria coverage if you hold one. The Promise-to-Proof line is that a stated RTO resolves to a test report where that RTO was measured, not asserted, so a reviewer reads the achieved-versus-target line rather than trusting the commitment. A restore claim resolves to a log entry with a date and outcome.
Answer patterns that hold up
- State RTO and RPO with units and say whether each is an internal objective or an SLA-backed commitment.
- Describe backup frequency, retention, geographic separation, encryption, and isolation/immutability from production.
- Give the date, scenario, and measured outcome of the most recent restore test and DR failover exercise.
- Describe the failover architecture and whether failover is automated or manual.
- State the review-and-test cadence and the plan owner, and note any gap between last test and current architecture.
Evidence that backs the answer
Red flags reviewers catch
- A BC/DR plan described with no date of any test.
- Stating RTO/RPO numbers that have never been measured in an exercise.
- "We back up regularly" with no restore-testing evidence.
- Backups described without isolation or immutability from production.
- Claiming automated failover with no game-day or test to confirm it.