# Contingency Plan Test Plan

**Template version:** 1.0.0 · **Edition:** Ready to adopt · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/plans/contingency-plan-test-plan/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

| System | Test type | Test date | Test lead | Plan version tested |
| --- | --- | --- | --- | --- |
| [Fill in: system name and identifier] | [Fill in: tabletop or functional] | [Fill in: date] | [Fill in: name and title] | [Fill in: version] |

## 1. Introduction

The contingency plan is tested [Fill in: frequency of testing the contingency plan for the system. Typical: annually], using [Fill in: tests for determining the effectiveness of the contingency plan. Typical: a functional test that restores the system, or a representative part of it, from backup] to determine its effectiveness and [Fill in: tests for determining readiness to execute the contingency plan. Typical: a tabletop exercise that walks the contingency team through the plan] to determine readiness to execute it (CP-4a). This test is [Fill in: which of those tests this is, and why it was chosen].

## 2. Scope and concept of operations

| Item | Description |
| --- | --- |
| In scope | [Fill in: components, sites, teams and plan sections tested] |
| Out of scope | [Fill in: what is not tested] |
| Location | [Fill in: where the test takes place, including the alternate processing site for High systems (CP-4(2))] |
| Safeguards | [Fill in: how production is protected during a functional test, and who can stop the test] |
| Related plans | [Fill in: related plans and the teams responsible for them, involved in this test (CP-4(1))] |

## 3. Objectives

| Objective | How it is measured |
| --- | --- |
| [Fill in: for example the team activates the plan and notifies everyone within 1 hour] | [Fill in: measure] |
| [Fill in: for example the database is restored from backup within the RTO and to the RPO (CP-9(2))] | [Fill in: measure] |
| [Fill in: for example personnel at the alternate site can reach the resources they need (CP-4(2))] | [Fill in: measure] |

## 4. Participants

| Role | Name | Test role |
| --- | --- | --- |
| Test lead or facilitator | [Fill in: name] | Runs the test |
| [Fill in: contingency role] | [Fill in: name] | Player |
| Observer or evaluator | [Fill in: name] | Records what happens against the objectives |

## 5. Agenda

| Time | Activity |
| --- | --- |
| [Fill in: time] | Briefing: objectives, rules and safeguards |
| [Fill in: time] | Scenario and exercise |
| [Fill in: time] | Debrief (hotwash) |

## 6. Scenario and injects

**Scenario:** [Fill in: the event that triggers the plan, for example ransomware encrypts the primary database server at the start of the business day]

| Time or step | Inject or action | Expected response |
| --- | --- | --- |
| [Fill in: time or step] | [Fill in: new information given to players, or a recovery action to perform] | [Fill in: what the plan says should happen] |

## 7. Debrief questions

- [Fill in: for example what worked well]
- [Fill in: for example where the plan was unclear or out of date]
- [Fill in: for example what slowed recovery]

## 8. Evaluation

The evaluators record, for each objective, whether it was met and what they observed. The results, findings and recommendations go in the after-action report, and corrective actions are tracked to completion (CP-4b, CP-4c).

## 9. Approval

| Name | Title | Signature | Date |
| --- | --- | --- | --- |
| [Fill in: name] | [System owner] | | [Fill in: date] |