Contingency Planning Policy

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for contingency planning in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers contingency planning and recovery for the Organization’s systems. Mission continuity is the outcome the security program protects. The Organization must set recovery objectives (recovery time objective (RTO) and recovery point objective (RPO)) for every system based on business impact. It must test backups by restoring from them, and it must arrange alternate processing and storage in proportion to mission criticality. It must exercise its contingency plans every year and change the plans based on what the exercises show.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

• PR.IR — Technology Infrastructure Resilience (Protect function)
• RC.RP — Recovery Plan Execution (Recover function)
• RC.CO — Recovery Communication (Recover function)

These categories fall under the Protect, Recover function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every contingency planning control in the low baseline of FIPS 200 and NIST SP 800-53B:

• CP-01 — Policy and Procedures
• CP-02 — Contingency Plan
• CP-03 — Contingency Training
• CP-04 — Contingency Plan Testing
• CP-08 — Telecommunications Services
• CP-09 — System Backup
• CP-10 — System Recovery and Reconstitution

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• OMB M-20-19: Harnessing Technology to Support Mission Continuity, March 22, 2020.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the CP control family. They add to the NIST SP 800-53 control requirements in the Policy section.

NIST SP 800-34: Contingency Planning Guide

• The organization must develop, document, and test contingency plans for each system based on its FIPS 199 impact level. Plans must include three phases: Activation/Notification, Operations, and Reconstitution. (NIST SP 800-34r1, §3)
• The organization must test contingency plans at least annually. Testing methods range from tabletop exercises to full interruption tests, with the test type proportional to the system’s criticality and impact level. Deadline: Annually. (NIST SP 800-34r1, §4)
• The organization should conduct a business impact analysis for each system that sets business processes and recovery criticality, resource requirements, and system resource recovery priorities. (NIST SP 800-34 Rev 1, §3.2)
• The organization should develop each contingency plan through the seven planning steps: policy, business impact analysis, preventive controls, recovery strategies, the plan, testing and exercises, and plan maintenance. (NIST SP 800-34 Rev 1, §3)

NIST SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities

• The organization should write objectives and success criteria for each contingency plan test or exercise, and record the results and lessons learned in an after-action report. (NIST SP 800-84, §§4-6)

3. Policy #

The Organization must implement and maintain its contingency planning controls to meet the following requirements:

CP-01 — Policy and Procedures #

Baselines: Low / Moderate / High CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution)

Requirement:

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] contingency planning policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the contingency planning policy and the associated contingency planning controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the contingency planning policy and procedures; and
3. Review and update the current contingency planning:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Implementation guidance:

The Organization must keep a contingency planning policy and the procedures that put it into practice. The CISO manages the development, documentation, and distribution of both documents. The CISO’s office distributes them to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and the key stakeholders who hold contingency roles. The policy must state its purpose and scope, assign roles and responsibilities, record management’s commitment, and describe how organizational units coordinate during planning and during a disruption. It must also state what compliance requires. The policy must stay consistent with the laws, executive orders, directives, and regulations that apply to the Organization. The CISO must review and update the policy and the procedures every year, and sooner after a major incident or a major change to applicable policy. Procedures written for an earlier architecture can fail when the Organization activates them.

CP-02 — Contingency Plan #

Baselines: Low / Moderate / High CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

1. Develop a contingency plan for the system that:

1. Identifies essential mission and business functions and associated contingency requirements;
2. Provides recovery objectives, restoration priorities, and metrics;
3. Addresses contingency roles, responsibilities, assigned individuals with contact information;
4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure;
5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented;
6. Addresses the sharing of contingency information; and
7. Is reviewed and approved by [Assignment: organization-defined personnel or roles — to be defined];

2. Distribute copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements — to be defined];
3. Coordinate contingency planning activities with incident handling activities;
4. Review the contingency plan for the system at least annually;
5. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;
6. Communicate contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements — to be defined];
7. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and
8. Protect the contingency plan from unauthorized disclosure and modification.

Implementation guidance:

Every system must have an Information System Contingency Plan (ISCP). Each System Owner must complete a business impact analysis (BIA) for every system, low-impact systems included, before writing the plan and again after each significant change. The plan must identify the system’s essential mission and business functions. It must set recovery objectives and restoration priorities from the BIA. It must name the contingency roles and the people who fill them, with current contact information. The plan must describe how the Organization sustains essential functions through a disruption, compromise, or failure. It must describe how the Organization restores the system fully without weakening its controls, and how it shares contingency information. Plans follow NIST SP 800-34r1 and cover activation and notification, continuity operations, and reconstitution. The Authorizing Official or a designated representative and the System Owner must review and approve each plan. The System Owner must send copies to the key contingency personnel listed in the approved ISCP and must upload the plan to the governance, risk, and compliance (GRC) system. The System Owner must review the plan every year. The System Owner must update it for organizational and system changes and for problems found during execution or testing, and must protect it from unauthorized disclosure and modification.

CP-03 — Contingency Training #

Baselines: Low / Moderate / High CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

1. Provide contingency training to system users consistent with assigned roles and responsibilities:

1. Within *See Additional Requirements of assuming a contingency role or responsibility;
2. When required by system changes; and
3. at least annually thereafter; and

2. Review and update contingency training content at least annually and following [Assignment: organization-defined events — to be defined].

Implementation guidance:

The Organization must train every person who holds a contingency role, and the training must match the role’s duties. The person must complete the training within [CP-03 parameter 1 — to be defined] of taking the role, again when a system change alters the role’s duties, and every year after that. The content depends on the role. Most personnel need to know where to report and how their duties change during a disruption. Administrators need the skills to restore systems at the alternate site. Officials need to know how to sustain essential functions from wherever the disruption leaves them. The CISO must review and update the training content every year and after a major incident or a major change, and must add the lessons from tests and real activations. Supervisors must not leave a contingency role with a person whose training is overdue.

CP-04 — Contingency Plan Testing #

Baselines: Low / Moderate / High CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

1. Test the contingency plan for the system at least every 3 years using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: classroom exercise/table top written tests.
2. Review the contingency plan test results; and
3. Initiate corrective actions, if needed.

Implementation guidance:

System Owners must test each system’s contingency plan every 3 years. The type of exercise depends on the system’s Federal Information Processing Standards (FIPS) 199 categorization, as NIST SP 800-34r1 directs. A low-impact system needs a tabletop or functional exercise. A moderate-impact system needs a functional exercise. A high-impact system needs a full-scale functional exercise. Each test plan must set objectives for notification, recovery from backup on an alternate platform, internal and external connectivity, performance on alternate equipment, and return to normal operations. The test scenarios must include a destructive cyberattack, such as ransomware that encrypts or deletes data. The System Owner must review the test results with the ISSO. Where the test found a weakness, the System Owner must start corrective action and must revise the plan. A reduction in test scope from one year to the next is a risk decision for the Authorizing Official.

CP-08 — Telecommunications Services #

Baselines: Moderate / High / High Value Asset (HVA) overlay (applies to systems designated as High Value Assets, under OMB M-19-03) CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

Establish alternate telecommunications services, including necessary agreements to permit the resumption of [Assignment: organization-defined system operations — to be defined] for essential mission and business functions within [Assignment: organization-defined time period — to be defined] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.

Implementation guidance:

The Organization must keep alternate telecommunications services and the agreements needed to resume the systems and services defined in each system’s BIA and information technology contingency plan (ITCP). The alternate services must restore the systems within the Recovery Time Objectives (RTOs) and the business-function Maximum Tolerable Downtimes (MTDs) those approved documents specify. The services apply whenever primary telecommunications fail at the primary site, the alternate processing site, or the alternate storage site. System Owners must confirm that the alternate arrangements cover both the data paths and the voice paths the essential functions depend on. The CISO must confirm that contingency tests validate the arrangements, and must not accept contract language alone as proof. An alternate service that cannot start inside the RTO does not satisfy this policy.

CP-09 — System Backup #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

1. Conduct backups of user-level information contained in [Assignment: organization-defined system components — to be defined] daily incremental; weekly full;
2. Conduct backups of system-level information contained in the system daily incremental; weekly full;
3. Conduct backups of system documentation, including security- and privacy-related documentation daily incremental; weekly full; and
4. Protect the confidentiality, integrity, and availability of backup information.

Implementation guidance:

System Owners must run backups for each system on the schedule its recovery objectives require. The backups must capture the user-level information on the components needed to restore full function, and the system-level information. The schedule is daily incremental and daily full backups, and it must meet the system’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO). System Owners must back up system documentation, including security and privacy documentation, every day or when the documents change. System Owners must protect the confidentiality, integrity, and availability of backup information wherever the Organization stores it. Backup data needs the same protection as production data. System Owners must monitor backup execution and must correct a failure within the window the RPO allows. A backup failure that no one notices until restoration is the outcome this policy exists to prevent.

CP-10 — System Recovery and Reconstitution #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.IR (Technology Infrastructure Resilience), RC.RP (Recovery Plan Execution), RC.CO (Recovery Communication)

Requirement:

Provide for the recovery and reconstitution of the system to a known state within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives — to be defined] after a disruption, compromise, or failure.

Implementation guidance:

The Organization must recover and reconstitute each system to a known state within a time that meets the system’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO). For every Mission Essential System, the Organization must recover within the [CP-10 parameter 1 — to be defined] Maximum Tolerable Downtime that Federal Continuity Directive 1 sets. Recovery restores essential operations. Reconstitution completes the work: the System Owner stands down interim capabilities, assesses full capability, reestablishes continuous monitoring, and returns the system to its authorized configuration with its controls in place. The System Owner must run the recovery against the clock. The System Owner must inform the Authorizing Official when reconstitution requires a reauthorization decision. A system that still runs on an improvised configuration remains a risk, and the System Owner must not declare it recovered.

Business Impact Analysis and Contingency Planning Process #

Every system, including each low-impact system, must have a business impact analysis (BIA) that sets its recovery objectives. The System Owner builds the contingency plan from the BIA through the seven steps in NIST SP 800-34 Rev. 1.

• The System Owner must complete a BIA for every system before writing its contingency plan.
• The System Owner must update the BIA after each significant change to the system.
• Each BIA must set the maximum tolerable downtime, the recovery time objective, and the recovery point objective for each process the system supports.
• The ISSO must review each BIA and store it with the system’s contingency plan in the GRC system.
• Each contingency plan test must set success criteria for notification, recovery on an alternate platform, connectivity, performance, and return to normal operations.
• The System Owner must plan each test under NIST SP 800-84 and record measured recovery times against the recovery time objective.

Source: NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (2010), sections 3.1 through 3.7; NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (2006).

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of contingency planning controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves contingency planning through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Automate restoration testing so RTO/RPO validation runs on a schedule rather than as a manual annual event.
6. Adopt immutable/offline backup tiers and measure recovery from simulated ransomware scenarios.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FIPS 199: Standards for Security Categorization, February 2004.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems, May 2010.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-20-19: Harnessing Technology to Support Mission Continuity, March 22, 2020.