# Information System Contingency Plan

**Template version:** 1.0.0 · **Edition:** Annotated (with guidance) · **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/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** This outline follows the Moderate sample plan in Appendix A of [NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final), Contingency Planning Guide for Federal Information Systems (May 2010, updated November 2010; current as of September 2026): an introduction, a concept of operations, and three phases, activation and notification, recovery, and reconstitution, followed by appendices. Complete the [business impact analysis](https://kston83.github.io/nist-guide/templates/reports/business-impact-analysis/) first; its recovery objectives drive this plan. Low systems can shorten sections 4 and 5; High systems add detail for the alternate processing site and for continuing essential functions (CP-2(5)). The plan describes how to restore the system, so protect it like the system itself (CP-2h).

| System name | System identifier | Plan version | Approved by | Approval date |
| --- | --- | --- | --- | --- |
| [Fill in: system name] | [Fill in: unique system identifier] | [Fill in: version] | [Fill in: name and title] | [Fill in: date] |

## Plan approval

This plan was reviewed by [Fill in: personnel or roles to review a contingency plan. Typical: the system owner and the system security officer] and is approved by [Fill in: personnel or roles to approve a contingency plan. Typical: the authorizing official, or the business owner the authorizing official names] (CP-2a.7).

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

## 1. Introduction

### 1.1 Background

This plan sets out how [Fill in: system name] is recovered after a disruption, compromise or failure. The system supports these mission and business functions: [Fill in: the functions, from the business impact analysis]. Of these, the essential functions are [Fill in: the essential functions] (CP-2a.1).

### 1.2 Scope

This plan covers [Fill in: the system boundary, locations and components]. It does not cover [Fill in: what is out of scope, for example the facility, covered by the building's emergency plan].

### 1.3 Assumptions

- [Fill in: for example the alternate processing site is available and unaffected]
- [Fill in: for example key personnel or their backups are available]
- [Fill in: for example current backups exist at the alternate storage site]

## 2. Concept of operations

### 2.1 System description

[Fill in: a short description of the system, its architecture, where it runs, its main components and its connections, or a reference to the system security plan]

### 2.2 Recovery objectives and phases

The business impact analysis sets these objectives (CP-2a.2):

| Objective | Value |
| --- | --- |
| Maximum tolerable downtime | [Fill in: time] |
| Recovery time objective | [Fill in: time] |
| Recovery point objective | [Fill in: time] |

Essential functions are resumed within [Fill in: the recovery time objective] of plan activation (CP-2(3)). The critical system assets that support them are listed in Appendix H (CP-2(8)).

Recovery runs in three phases:

1. **Activation and notification:** the disruption is assessed, the plan is activated and the contingency team is notified (section 3).
2. **Recovery:** the system's capabilities are restored, at the primary site or at the alternate site (section 4).
3. **Reconstitution:** the system is tested and returned to normal operation, with its controls working as originally planned (section 5; CP-2a.5, CP-10).

### 2.3 Roles and responsibilities

| Role | Responsibilities | Primary | Alternate |
| --- | --- | --- | --- |
| Contingency plan coordinator | Activates the plan, leads recovery, reports status | [Fill in: name] | [Fill in: name] |
| [System owner] | Approves activation; accepts the recovered system | [Fill in: name] | [Fill in: name] |
| Recovery team | Restores components and data | [Fill in: names] | [Fill in: names] |
| [Fill in: other role, for example the network team or the cloud service provider] | [Fill in: responsibilities] | [Fill in: name] | [Fill in: name] |

Contact details are in Appendix A (CP-2a.3).

## 3. Activation and notification

### 3.1 Activation criteria and procedure

The plan is activated when [Fill in: for example the system is, or is expected to be, unavailable for longer than a set time, or a compromise requires rebuilding it]. The [Fill in: role] decides whether to activate it. When a disruption is caused by an incident, the contingency plan coordinator works with the incident response team under the incident response plan (CP-2c).

### 3.2 Notification

On activation, the contingency plan coordinator notifies [Fill in: who, and how, for example by the notification tool and by phone], using Appendix A. Status is shared with [Fill in: who receives updates, for example users, the business owner and leadership] [Fill in: how often] (CP-2a.6).

### 3.3 Outage assessment

The recovery team assesses the cause, the extent of damage and the expected outage time, and reports to the coordinator, who decides whether to recover at the primary site or at the alternate site.

## 4. Recovery

### 4.1 Sequence of recovery activities

Components are recovered in the priority order from the business impact analysis (CP-2a.2):

| Order | Component or service | Recovery time objective | Depends on |
| --- | --- | --- | --- |
| 1 | [Fill in: component] | [Fill in: time] | [Fill in: dependencies] |
| 2 | [Fill in: component] | [Fill in: time] | [Fill in: dependencies] |

### 4.2 Recovery procedures

Step-by-step procedures for each component are in Appendix C, and for moving operations to the alternate processing site in Appendix D. Backups are restored from [Fill in: where, for example the backup service in the second region] (CP-9, CP-10).

### 4.3 Recovery escalation and notices

The coordinator reports progress to [Fill in: who] [Fill in: how often], and escalates to [Fill in: who] when a recovery step fails or the recovery time objective is at risk.

## 5. Reconstitution

### 5.1 Validation data testing

The recovery team confirms that data is complete and current to the recovery point objective, using [Fill in: how, for example record counts and checks against the last transactions].

### 5.2 Validation functionality testing

The recovery team tests that the system works as expected and that its security controls operate as originally planned, using the system validation test plan in Appendix E (CP-2a.5).

### 5.3 Recovery declaration

The [System owner] declares recovery complete when validation passes.

### 5.4 Notification

The coordinator tells users and stakeholders that the system is available again.

### 5.5 Cleanup

Temporary configurations, accounts and workarounds used during recovery are removed or brought under normal change control.

### 5.6 Offsite data storage

Media and copies used during recovery are returned to the alternate storage site, or replaced there (CP-6).

### 5.7 Data backup

A full backup of the recovered system is made as soon as it is back in operation (CP-9).

### 5.8 Event documentation

The coordinator records what happened, the timeline, the actions taken, the problems found and the lessons learned. The plan is updated where the event showed a gap (CP-2e, CP-2g).

### 5.9 Deactivation

The coordinator formally deactivates the plan and tells the contingency team.

## 6. Plan maintenance and distribution

- The [System owner] shall distribute copies of this plan to [Fill in: key contingency personnel (identified by name and/or by role) to whom copies of the contingency plan are distributed. Typical: the contingency team members, by role] and to [Fill in: key contingency organizational elements to which copies of the contingency plan are distributed. Typical: the operations, facilities and communications functions]. (CP-2b)
- The [System owner] shall review this plan [Fill in: frequency of contingency plan review. Typical: annually]. (CP-2d)
- The [System owner] shall update this plan to address changes to the organization, the system or its environment of operation, and problems found when the plan is carried out or tested. (CP-2e)
- The [System owner] shall communicate plan changes to [Fill in: key contingency personnel (identified by name and/or by role) to communicate changes to. Typical: the contingency team members, by role] and to [Fill in: key contingency organizational elements to communicate changes to. Typical: the operations, facilities and communications functions]. (CP-2f)
- This plan is coordinated with the related plans listed in Appendix K (CP-2(1)).

### Federal systems

Agency continuity programs follow FEMA's [Federal Continuity Directive: Federal Executive Branch Continuity Program Management Requirements](https://www.fema.gov/sites/default/files/documents/fema_oncp_fcd-federal-executive-branch-continuity-program-management-requirements.pdf) (August 2024), which rescinded and superseded FCD-1 (January 2017). Essential functions are identified under the [Federal Continuity Directive: Federal Executive Branch Essential Functions Risk Identification and Management](https://www.fema.gov/sites/default/files/documents/fema_oncp-fcd-federal-executive-branch-essential-functions-risk-identification-management.pdf) (August 2024), which rescinded and superseded FCD-2 (June 2017). Checked September 2026.

- The [System owner] shall align the essential functions and recovery priorities in this plan with the agency's continuity plan and its identified essential functions. (CP-2(1))

## Appendix A. Personnel contact list

| Role | Name | Phone | Alternate phone | Email |
| --- | --- | --- | --- | --- |
| [Fill in: role] | [Fill in: name] | [Fill in: phone] | [Fill in: phone] | [Fill in: email] |

## Appendix B. Vendor contact list

| Vendor | Product or service | Contract or support number | Contact | Phone and email |
| --- | --- | --- | --- | --- |
| [Fill in: vendor] | [Fill in: product or service] | [Fill in: reference] | [Fill in: name] | [Fill in: phone and email] |

## Appendix C. Detailed recovery procedures

[Fill in: step-by-step procedures for recovering each component, or references to the runbooks that hold them]

## Appendix D. Alternate processing procedures

[Fill in: how operations move to the alternate processing site and back]

## Appendix E. System validation test plan

[Fill in: the tests that confirm the recovered system and its data are complete and working, and who signs them off]

## Appendix F. Alternate storage, processing site and telecommunications

| Item | Details |
| --- | --- |
| Alternate storage site (CP-6) | [Fill in: location or service, and the agreement] |
| Alternate processing site (CP-7) | [Fill in: location or service, and the agreement] |
| Alternate telecommunications (CP-8) | [Fill in: provider and service] |

## Appendix G. Diagrams

[Fill in: system and data flow diagrams, or a reference to the system security plan]

## Appendix H. Hardware and software inventory

[Fill in: the components needed to recover the system, marking the critical assets, or a reference to the component inventory]

## Appendix I. Interconnections

| Connected system | Organization | Type of connection | Contact |
| --- | --- | --- | --- |
| [Fill in: system] | [Fill in: organization] | [Fill in: type] | [Fill in: contact] |

## Appendix J. Test and maintenance schedule

| Activity | Frequency | Last done | Next due |
| --- | --- | --- | --- |
| Plan review | [Fill in: frequency of contingency plan review. Typical: annually] | [Fill in: date] | [Fill in: date] |
| Plan test (CP-4) | [Fill in: frequency] | [Fill in: date] | [Fill in: date] |
| Contingency training (CP-3) | [Fill in: frequency] | [Fill in: date] | [Fill in: date] |

## Appendix K. Associated plans and procedures

| Plan | Owner | Location |
| --- | --- | --- |
| [Fill in: for example incident response plan, business continuity plan, disaster recovery plan] | [Fill in: owner] | [Fill in: location] |

## Appendix L. Business impact analysis

[Fill in: the business impact analysis, or a reference to it]

## Appendix M. Document change page

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [Fill in: version] | [Fill in: date] | [Fill in: summary of change] | [Fill in: name and title] |