7.12 Disaster Recovery Testing

Key Takeaways

CISSP 7.12 is: Test Disaster Recovery Plans.

The current ISC2 outline explicitly covers: read-through/tabletop, walkthrough, simulation, parallel, full interruption and communications.

DR testing determines whether recovery plans, personnel, communications and technology actually support the organisation's recovery requirements.

A DR plan existing does not prove a DR capability exists.

Testing can validate documentation, personnel, technical systems, dependencies, suppliers and recovery objectives.

Testing should begin with clearly defined objectives.

The organisation should know what the exercise is expected to prove.

Success criteria should be established before the exercise.

Measures may include RTO, RPO, functionality, security, capacity and communications.

Objective → exercise → measure → improve → retest.

A read-through reviews the plan for completeness, accuracy and usability.

It is low risk and can identify documentation problems before more complex exercises occur.

A tabletop exercise uses a hypothetical disaster scenario.

Participants discuss how they would respond and make decisions.

Tabletop exercises are particularly useful for testing roles, responsibilities, escalation, communication and decision-making.

Tabletop = talk it through.

A successful tabletop does not prove that backups or alternate systems actually work.

A walkthrough steps through the recovery process in greater operational detail.

Participants may verify facilities, equipment, access, procedures and contacts.

Tabletop = discuss it. Walkthrough = step through it.

A simulation places participants into a realistic disaster scenario and requires them to respond as if the event were real.

Simulations can introduce changing conditions and unexpected events to test decision-making.

Production usually remains protected from deliberate interruption.

A parallel test activates and tests the recovery environment while normal production continues operating.

It provides stronger technical evidence without intentionally making production dependent on the recovery site.

Parallel = DR runs beside production.

Parallel testing may still leave some activities untested, such as real user redirection or complete production cutover.

A full-interruption test deliberately makes actual operations depend on the recovery capability.

This creates the highest realism but also the greatest operational risk among the test types listed by ISC2.

Full interruption = use DR for real.

Full-interruption testing requires careful risk assessment, authorisation, monitoring, rollback and stop criteria.

The test should not accidentally become the disaster.

More realistic testing can provide greater assurance, but more realism is not automatically appropriate.

The organisation should select the test method that provides sufficient assurance while managing business risk.

Restore testing is especially important.

Backup software reporting success does not prove that data can actually be recovered.

Backup success ≠ restore success.

DR testing should measure actual recovery time against the documented RTO.

A service with a two-hour RTO that takes six hours to recover has a measurable recovery gap.

DR testing should also validate the RPO.

A technically successful restore may still fail requirements if recovered data is older than the business can tolerate.

RTO tests time. RPO tests recoverable data.

Dependencies should be included in DR exercises.

Recovering an application does not help if DNS, identity, databases, networking or required suppliers remain unavailable.

Testing is one of the best methods for finding undocumented dependencies.

Recovery capacity should also be tested.

An alternate environment that supports a handful of test users may not be able to support production demand.

DR testing should include people as well as technology.

Organisations should consider whether alternate personnel can perform important procedures if the primary specialist is unavailable.

Expert knows how ≠ organisation knows how.

Communications are an explicit part of current CISSP 7.12.

Exercises should consider stakeholders, test status and any applicable external communications.

Alternate communication channels should be tested where normal communications could fail during the scenario.

Exercise messages should be controlled so simulated events are not accidentally interpreted as genuine incidents.

Critical third-party dependencies should also be incorporated into recovery assurance where practical.

A contract saying that a supplier can recover within a particular time is weaker evidence than a successfully tested activation process.

DR exercises should have observers or evaluators where appropriate.

Recovery times, decisions, communication delays, errors and unexpected dependencies should be recorded.

Testing should produce evidence rather than relying solely on participant memory.

A failed recovery test can be valuable.

Discovering that a backup cannot be restored during a controlled exercise is far better than discovering it during a real disaster.

Finding weakness during testing is not failure of the testing process. It is one of its purposes.

Exercises should be followed by evaluation.

Findings should identify what failed, why it failed and what needs to change.

Corrective actions should have owners and target completion.

Significant corrections should then be retested.

Finding → cause → owner → correction → retest.

DR documentation should be updated when exercises reveal inaccurate information.

Major changes to production architecture can also invalidate previously tested recovery procedures.

A successful DR test from last year does not automatically prove today's environment remains recoverable.

Test frequency should reflect organisational risk, business criticality, applicable requirements, technological change and prior findings.

There is no single universal test interval appropriate for every system and organisation.

Test environments and recovery copies must also remain secure.

Recovery testing should not expose sensitive production data or create uncontrolled access.

Training, exercises and technical testing should not be confused.

Training develops the person's capability.

Exercises evaluate coordination and use of plans.

Technical tests validate the operability of systems and recovery mechanisms.

NIST refers to these collectively as Test, Training and Exercise activities.

The three surrounding CISSP objectives can be remembered as:

7.10 = build recovery capability. 7.11 = execute recovery. 7.12 = prove recovery works.

The central CISSP principle is:

test Disaster Recovery at a level appropriate to the organisation's risk, measure actual performance against business recovery requirements, treat weaknesses as useful findings, assign corrective actions and retest until the organisation has evidence that recovery capability works.