Testing, Exercising, and Continuous Improvement
Exercise the capability, not the document
The exam tests whether you can design a risk-based testing and exercise program that produces evidence and improvement. Testing ranges from plan review and tabletop exercises to walkthroughs, simulations, parallel processing, and full failover or cutover. Backup restores, restoration tests, penetration tests, and red-team exercises answer different questions. A mature program combines several methods over a cycle.
Core rules
- Start with objectives and success criteria. Examples: validate the four-hour RTO, test crisis communications, confirm a restore from immutable media, or measure decision latency.
- Define scope, scenario, participants, safety controls, and stop conditions. For production tests, use change control, backups, and rollback plans.
- Use realistic injects: unavailable key personnel, degraded network, vendor outage, and misleading initial information. Observers record timing and decisions.
- Conduct a hot wash immediately, then a formal after-action report with findings, owners, due dates, and risk ranking. Track corrective actions to closure and retest.
- Frequency should reflect criticality and change. Critical services may warrant annual full failover and more frequent tabletops; major changes should trigger targeted tests.
- Protect evidence: logs, screenshots, timestamps, and test records support audit and continuous improvement.
Worked example
A bank runs an annual full failover for online banking and quarterly tabletops for the crisis team. The failover meets the four-hour RTO, but customer login fails because the DR environment uses an old DNS record. The after-action report assigns a corrective action to the network team, adds a DNS dependency check to the runbook, and schedules a targeted retest within 30 days. The test is not passed until the retest confirms login and transaction integrity.
Traps
Do not test only backup completion. Do not run exercises without objectives, success criteria, or a no-blame learning culture. Do not exclude business, legal, and communications participants. Do not leave findings untracked. Do not test production failover without rollback and safety controls. Do not confuse a tabletop discussion with proof of technical recovery.