Information System Contingency Plan
Information System Contingency Plan template: The plan for recovering one system after a disruption, compromise or failure, following the NIST SP 800-34 Rev. 1 template and covering every element SP 800-53 CP-2 requires.
| Type | Program stage | Status | Template version | NIST basis |
|---|---|---|---|---|
| Plan | Core | Draft | 1.0.0 | SP 800-53 release 5.2.0 |
What it is
Section titled “What it is”The plan for recovering one system after a disruption, compromise or failure, following the NIST SP 800-34 Rev. 1 template and covering every element SP 800-53 CP-2 requires.
Controls satisfied
Section titled “Controls satisfied”| Control | Title |
|---|---|
| CP-2 | Contingency Plan |
| CP-2(1) | Coordinate with Related Plans |
| CP-2(3) | Resume Mission and Business Functions |
| CP-2(8) | Identify Critical Assets |
| CP-6 | Alternate Storage Site |
| CP-7 | Alternate Processing Site |
| CP-8 | Telecommunications Services |
| CP-9 | System Backup |
| CP-10 | System Recovery and Reconstitution |
Downloads
Section titled “Downloads”| Variant | Ready to adopt | Annotated |
|---|---|---|
| All baselines | Word · Markdown | Word · Markdown |
Preview (annotated)
Section titled “Preview (annotated)”| 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
Section titled “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
Section titled “1. Introduction”1.1 Background
Section titled “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
Section titled “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
Section titled “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
Section titled “2. Concept of operations”2.1 System description
Section titled “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
Section titled “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:
- Activation and notification: the disruption is assessed, the plan is activated and the contingency team is notified (section 3).
- Recovery: the system’s capabilities are restored, at the primary site or at the alternate site (section 4).
- 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
Section titled “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
Section titled “3. Activation and notification”3.1 Activation criteria and procedure
Section titled “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
Section titled “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
Section titled “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
Section titled “4. Recovery”4.1 Sequence of recovery activities
Section titled “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
Section titled “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
Section titled “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
Section titled “5. Reconstitution”5.1 Validation data testing
Section titled “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
Section titled “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
Section titled “5.3 Recovery declaration”The System owner declares recovery complete when validation passes.
5.4 Notification
Section titled “5.4 Notification”The coordinator tells users and stakeholders that the system is available again.
5.5 Cleanup
Section titled “5.5 Cleanup”Temporary configurations, accounts and workarounds used during recovery are removed or brought under normal change control.
5.6 Offsite data storage
Section titled “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
Section titled “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
Section titled “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
Section titled “5.9 Deactivation”The coordinator formally deactivates the plan and tells the contingency team.
6. Plan maintenance and distribution
Section titled “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
Section titled “Federal systems”Agency continuity programs follow FEMA’s Federal Continuity Directive: Federal Executive Branch Continuity Program Management Requirements (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 (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
Section titled “Appendix A. Personnel contact list”| Role | Name | Phone | Alternate phone | |
|---|---|---|---|---|
| Fill in: role | Fill in: name | Fill in: phone | Fill in: phone | Fill in: email |
Appendix B. Vendor contact list
Section titled “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
Section titled “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
Section titled “Appendix D. Alternate processing procedures”Fill in: how operations move to the alternate processing site and back
Appendix E. System validation test plan
Section titled “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
Section titled “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
Section titled “Appendix G. Diagrams”Fill in: system and data flow diagrams, or a reference to the system security plan
Appendix H. Hardware and software inventory
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Appendix L. Business impact analysis”Fill in: the business impact analysis, or a reference to it
Appendix M. Document change page
Section titled “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 |
Independent guidance, not an official NIST publication. Control text is from NIST SP 800-53 Rev. 5 and SP 800-53A (public domain). Original content is licensed CC BY 4.0; program templates and the downloadable kit are dedicated to the public domain under CC0 1.0.