Recovery Testing — Flashcards

The proactive practice of validating disaster recovery plans and procedures before a real incident occurs. Conducted on a regular schedule (annual, semi-annual) using defined scenarios, time constraints, and rules of engagement. Goal: find plan gaps in a controlled test rather than during an actual disaster.

Do not touch production systems. Recovery testing validates readiness without creating the incident it is simulating. A test that disrupts production is a self-inflicted outage — it defeats the purpose of testing. All other constraints (specific scenario, time limits, documentation) follow from this primary rule.

A discussion-based recovery test where key stakeholders verbally walk through a hypothetical disaster scenario without touching any systems. No hardware is reconfigured, no data is moved. Identifies procedural gaps, unclear authority, missing contacts, and cross-team coordination failures. Cost-effective; does not validate actual system or infrastructure behavior.

Tabletop exercises test procedures and human coordination — they cannot test whether actual systems work. They do not validate that backups restore correctly, that failover switches activate, that data consistency is maintained, or that infrastructure performs under real failure conditions. Technical infrastructure requires failover tests, simulations, and parallel processing validation.

A recovery test that deliberately disables a primary component (firewall, server, network link) to verify that the redundant backup activates automatically within the target time. Validates: that the failover trigger works, that the switchover is transparent to users, that data consistency is maintained, and that applications reconnect to the new active component. Untested redundant systems may silently fail due to configuration drift.

Users should notice nothing. An ideal failover is transparent — the primary fails, the secondary activates automatically, traffic is redirected, sessions are maintained, and service continues without any user-visible disruption. Users have no idea they are now running on backup systems. If users notice the failover, the transition was not seamless enough.

A controlled security test that sends a crafted phishing email to the organization's own users, measuring two things: (1) whether email security controls quarantine it before it reaches users, and (2) of users who receive it, how many click or submit credentials. Users who click receive additional training. Users who report the email are a positive outcome. The only reliable test of whether security awareness training translates to actual behavior.

1. Technical controls: Does the email security gateway catch and quarantine the phishing email before it reaches inboxes? If not, the filter failed.

2. Human behavior: Of users who received the email, how many clicked or submitted credentials? Training and actual behavior under realistic conditions are different — simulation measures the real behavior.

Distributing computational work across multiple processors or systems simultaneously. Resilience benefit: if one processor fails, the system detects it, removes it from the active pool, and continues processing on the remaining processors — graceful degradation rather than complete failure. A pool of 8 processors losing 1 retains 87.5% capacity; a single processor failing loses 100% capacity.

Plans drift: infrastructure changes, staff turns over, new systems are added, threat landscapes evolve. A plan that was accurate and tested 3 years ago may no longer match the current environment. Regular testing (annual, semi-annual) catches plan drift before it matters. Each test cycle also produces findings and updates that improve the plan — without repetition, there is no improvement loop.