Topics in this domain
- IT Service Management
- Hardware Components and Architecture
- Operating Systems
- OSI Model
- TCP/IP and Common Protocols
- Network Devices: Switches, Routers, Gateways
- LAN/WAN Topologies
- Database Models and DBMS
- Database Controls and Normalization
- Asset Management
- Configuration Management
- Job Scheduling and Batch Processing
- Incident Management
- Problem Management
- Change Management
- Release and Patch Management
- Service Level Management
- Capacity and Performance Monitoring
- End-User Computing
- BCP Lifecycle
- Business Impact Analysis
- RTO, RPO, MTD, SDO
- Recovery Strategies
- Alternate Sites: Hot, Warm, Cold
- Backup Types: Full, Incremental, Differential
- Backup Storage and Rotation
- DRP Contents
- Testing BCP/DRP
- High Availability, RAID, Insurance
- Auditing BCP
Testing BCP/DRP
The fire drill
A school doesn’t wait for a real fire to discover the fire exit is blocked. It runs drills, starting with a talk-through and building up to everyone actually leaving the building.
Continuity tests work the same way. An untested plan gives very little assurance. Testing proves the plan works, shows whether recovery objectives can really be met, checks people know what to do, and flushes out stale information and missing steps.
The ladder of tests
| Test | What happens | Risk to operations |
|---|---|---|
| Checklist review | The plan is sent to each area, which checks its section is accurate and complete | None |
| Structured walkthrough (tabletop) | Team members meet and talk through the plan step by step for a scenario | None |
| Simulation / functional exercise | A realistic scenario is rehearsed: teams play their roles and make decisions, perhaps including notifications and some actions, but operations aren’t moved | Minimal |
| Parallel test | Critical systems are recovered at the alternate site and run with real or test data, while production carries on at the main site; results can be compared | Low |
| Full interruption test | The main site is actually shut down and operations run from the recovery site | High |
The Review Manual also uses three broader categories:
- Paper test: a desk-based walkthrough by the people who’d carry out the plan.
- Preparedness test: a localised version of a full test, exercising one part of the plan with real resources. Often run regularly on different components.
- Full operational test: one step short of an actual service disruption. Done only after paper and preparedness tests have succeeded.
Climb the ladder. A full interruption test comes only after the lower-level tests succeed, and with senior management approval, because the test itself could cause a disruption.
Running a test
- Pre-test: set objectives and success criteria before the test (such as “ERP back within the 6-hour RTO”), define the scope and scenario, arrange resources, get approvals.
- Test: carry out the recovery while observers record times, actions and problems.
- Post-test: return resources, remove test data, restore the normal setup.
Judging the result
Results are measured against the criteria set beforehand:
- elapsed time to recover each system, compared with its RTO
- amount of work processed at the recovery site
- accuracy of data and processing, compared with the RPO and integrity checks
- percentage of the plan carried out successfully
A post-test report records the findings and assigns actions. The plan is updated, and anything that failed is retested.
Example. A parallel test restores the ERP at the hot site in 9 hours against an RTO of 6. The delay came from waiting for a firewall rule change from the network provider. The actions: pre-stage the rules at the recovery site, update the runbook, and retest the network component.
Who takes part
Business users, not just IT: the test should prove that business processes can recover, not just servers. Internal audit may observe tests and review the results.
A test that finds nothing wrong probably wasn’t realistic. Finding weaknesses, and fixing them, is the whole point.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Least disruptive test | Checklist review / desk check |
| Team members talk through the plan together | Structured walkthrough (tabletop) |
| Recovery site activated while production continues | Parallel test |
| Most realistic, most risky test | Full interruption test |
| Test performed only after successful paper and preparedness tests | Full operational / full interruption test |
| Most important outcome of a test | Identifying weaknesses and updating the plan |
| Best measure of test success | Recovery achieved within RTO and RPO |
In short
- Test types, from least to most disruptive: checklist (desk) review, structured walkthrough (tabletop), simulation, parallel test, full interruption test.
- A checklist review distributes the plan for each team to check against their area; a walkthrough has team members talk through the plan together.
- A simulation (functional exercise) rehearses a scenario with roles and decisions, without actually moving operations.
- A parallel test recovers systems at the alternate site while production continues at the primary site.
- A full interruption test shuts down the primary site and runs from the recovery site; most realistic, most risky.
- Tests have pre-test, test and post-test phases; results are measured against objectives and drive plan updates.
- Tests should increase in scope over time; a full interruption test is done only after lower-level tests succeed.
Exam traps
- A full interruption test should not be the first test performed; start with paper and walkthrough tests.
- A parallel test doesn't interrupt production; a full interruption test does.
- A test that 'passes' with no issues found may mean the test wasn't realistic.
- Test objectives and success criteria (such as meeting RTO) must be defined before the test.
- The most important outcome of a test is identifying weaknesses and updating the plan.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The ladder of tests
Running a test