Why this matters
CISSP lens
Pick answers that align business risk, governance intent, and practical control execution.
Backups, runbooks, and cloud failover plans look impressive on paper. During a real outage, only tested capabilities matter. Domain 6 includes verifying that disaster recovery and business continuity plans work as intended so the organization can survive serious disruptions.
Core concept
Disaster recovery (DR) and business continuity (BC) aim to keep critical services available or to restore them within acceptable time and data loss limits.
Testing answers questions such as.
- Can we recover systems within our recovery time objectives.
- Is data loss limited to our recovery point objectives.
- Do people know what to do under stress.
BIA, RTO, and RPO
A business impact analysis (BIA) identifies.
- Critical business processes.
- Dependencies such as systems, people, vendors, and facilities.
- Acceptable downtime, recovery time objectives (RTOs).
- Acceptable data loss, recovery point objectives (RPOs).
DR and BC tests validate whether the organization can meet those RTOs and RPOs.
Types of DR and BC tests
From least to most disruptive.
- Checklist review: Stakeholders review plans, contact lists, and runbooks on paper to ensure they are current and complete.
- Tabletop exercise: Participants walk through a hypothetical scenario in a meeting room, discussing decisions and actions.
- Walkthrough or simulation: Teams simulate parts of the response, such as restoring a system in a test environment.
- Parallel test: Systems are restored and operated in an alternate site alongside production without fully switching over.
- Full interruption test: Production is deliberately shut down and operations are moved to a backup site.
Most organizations rely on a mix of these, using high disruption tests sparingly because of risk.
Cross functional coordination
Effective DR and BC testing involves.
- IT infrastructure and application teams.
- Business process owners.
- Facilities, communications, and HR.
- Key vendors and service providers.
Tests should include communication workflows, decision making, and manual workarounds, not just technical recovery.
CISSP lens
Domain cross-reference
Domain 6 expects you to know.
- The names and characteristics of DR and BC test types.
- When each type is appropriate based on risk and impact.
- That evidence from tests feeds into governance and risk management.
Exam scenarios may ask.
- Which test type to recommend for a given objective and risk tolerance.
- How to respond when a test reveals gaps in recovery capabilities.
- How to balance assurance needs with operational disruption risk.
Generally.
- Checklist and tabletop exercises are low risk ways to validate documentation and coordination.
- Parallel tests validate technical recovery with reduced operational risk.
- Full interruption tests offer high assurance but carry significant business risk and should be used carefully.
Real world scenario
A financial services company declares that its core payment system has an RTO of four hours and an RPO of 15 minutes. These values were set years ago and have never been tested end to end.
The security manager organizes a series of exercises.
- A checklist review updates contact lists, escalation paths, and vendor phone numbers.
- A tabletop exercise with business and IT leaders walks through a scenario where the primary data center is unavailable.
- A technical recovery test restores the payment system to a backup environment using existing backups.
The test reveals that.
- Backups take longer to restore than expected.
- Key staff lack clear step by step instructions.
- Dependencies on external payment gateways were not fully documented.
As a result.
- Runbooks are updated with detailed steps and responsibilities.
- Additional automation and tooling are introduced to speed restoration.
- Contracts with external providers are reviewed to clarify support during disasters.
Subsequent tests show improved performance, though the organization decides to adjust its RTO to a more realistic number and communicate this to stakeholders.
Test types at a glance
The exam expects you to rank these instantly; operations benefit from the same clarity:
| Test type | Disruption risk | Cost/effort | Assurance gained | Sensible cadence |
|---|---|---|---|---|
| Checklist review | None | Low | Documents current and complete | Quarterly |
| Tabletop exercise | None | Low to medium | Decision-making and coordination | Semiannual |
| Walkthrough / simulation | Low | Medium | Specific procedures actually work | Semiannual, rotating scope |
| Parallel test | Low to medium | High | Technical recovery meets RTO/RPO | Annual for critical systems |
| Full interruption | High | Highest | End-to-end proof under real conditions | Rare; only with executive sign-off |
Exam trap: full interruption is the "most thorough" option and almost never the right first answer. If the scenario describes untested plans, the progression starts at checklist and tabletop; recommending a full interruption test for an organization that has never run a tabletop is the classic over-reach distractor.
Capturing evidence that counts
A test that ends with "it mostly worked" wasted everyone's afternoon. The deliverable is measured evidence against declared objectives:
- Timing data per recovery step - when the restore began, when data was usable, when the business process actually resumed. Actual-versus-RTO, plotted across successive tests, is the single most persuasive chart in a continuity program.
- Measured data loss - the timestamp gap between the last recoverable transaction and the failure point, compared against RPO. Backup success logs are not RPO evidence; restored data is.
- Decision and communication log - who declared the event, who was reachable, how long notifications took. People failures dominate real disasters and hide easily in untimed tests.
- Deviation list - every step that required improvisation beyond the runbook. Each one is either a documentation fix or a capability gap.
Route the results into governance: gaps become findings with owners and dates in the same register as audit and vulnerability findings, and material misses force an honest conversation - improve the capability or formally revise the objective. An RTO that has failed three consecutive tests is not a target; it is a fiction on file with your regulator. Either investment closes the gap or leadership accepts and documents the longer number, as the payment-system scenario above concluded.
Common mistakes
DR and BC testing programs often suffer from.
Treating tests as checkboxes. Running minimal exercises just to satisfy auditors without learning from them.
Avoiding disruptive tests entirely. Never validating end to end recovery for critical systems.
Leaving out business leaders. Focusing only on technical recovery while ignoring decision making and manual workarounds.
Ignoring third party dependencies. Failing to include vendors, cloud providers, and partners in scenarios.
Not updating plans. Letting documentation drift after changes in systems or organizational structure.
Actionable checklist
To strengthen DR and BC testing.
- Review your BIA, RTO, and RPO values for critical processes and confirm they are still valid and agreed by business owners.
- Inventory existing DR and BC plans and identify when they were last tested.
- Select appropriate test types for each critical process, starting with low risk methods and building up.
- Schedule at least one tabletop exercise and one technical recovery test within the next 12 months for your most critical services.
- Involve business leaders, IT, and key vendors in planning and execution.
- After each exercise, conduct a lessons learned session and document issues and improvement actions.
- Update plans, contact lists, and architectures based on findings, and track progress.
- Report test outcomes and residual risks to senior leadership in business language.
Key takeaways
- Disaster recovery and business continuity plans must be tested to be trusted.
- Different test types balance assurance against operational risk; you should use a mix over time.
- Domain 6 expects you to select test types and frequencies based on criticality and risk appetite.
- Exercises reveal gaps in both technical recovery and human processes and drive improvements.
- Honest reporting of test results, including failures, supports realistic risk management.
Exam-style reflection
A company wants to validate that its backup data center can handle production workloads but is concerned about disrupting operations. Which type of DR test is most appropriate.
Answer: A parallel test, where systems are restored to the backup site and run alongside production without fully switching over. This validates capacity and procedures with lower risk than a full interruption test.
Keep learning: Security Assessment And Testing Fundamentals, Logging, Monitoring, And Control Validation, Security Metrics And Reporting.
This article is part of the CISSP Domain 6: Security Assessment and Testing study guide. Use the pillar to navigate every article in this domain.
