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 moderate baseline of FIPS 200 and NIST SP 800-53B:

• CP-01 — Policy and Procedures
• CP-02 — Contingency Plan
• CP-02(1) — Coordinate with Related Plans
• CP-02(3) — Resume Mission and Business Functions
• CP-02(8) — Identify Critical Assets
• CP-03 — Contingency Training
• CP-04 — Contingency Plan Testing
• CP-04(1) — Coordinate with Related Plans
• CP-06 — Alternate Storage Site
• CP-06(1) — Separation from Primary Site
• CP-06(3) — Accessibility
• CP-07 — Alternate Processing Site
• CP-07(1) — Separation from Primary Site
• CP-07(2) — Accessibility
• CP-07(3) — Priority of Service
• CP-08 — Telecommunications Services
• CP-08(1) — Priority of Service Provisions
• CP-08(2) — Single Points of Failure
• CP-09 — System Backup
• CP-09(1) — Testing for Reliability and Integrity
• CP-09(8) — Cryptographic Protection
• CP-10 — System Recovery and Reconstitution
• CP-10(2) — Transaction Recovery

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-02(1) — Coordinate with Related Plans #

Baselines: Moderate / High

Requirement:

Coordinate contingency plan development with organizational elements responsible for related plans.

Implementation guidance:

System Owners must coordinate contingency plan development with the organizational elements that own related plans. Related plans include the business continuity, disaster recovery, continuity of operations, crisis communications, incident response, and occupant emergency plans. The coordination must align the assumptions, dependencies, and recovery priorities of each plan before any activation. System Owners must resolve conflicts between plans during development. A conflict found during a disruption delays recovery.

CP-02(3) — Resume Mission and Business Functions #

Baselines: Moderate / High

Requirement:

Plan for the resumption of all mission and business functions within time period defined in service provider and organization SLA of contingency plan activation.

Implementation guidance:

Each contingency plan must provide for resuming essential mission and business functions within the approved Maximum Tolerable Downtime (MTD). The system’s Business Impact Assessment (BIA) documents the MTD for each function. The Organization measures the time from contingency plan activation. System Owners must confirm that the recovery strategies, resources, and sequence of steps fit inside that window. A plan whose steps take longer than the MTD does not meet this requirement.

CP-02(8) — Identify Critical Assets #

Baselines: Moderate / High

Requirement:

Identify critical system assets supporting [Selection: all; essential — to be defined] mission and business functions.

Implementation guidance:

System Owners must identify the critical system assets that support essential mission and business functions. Critical assets include the technical components and services, and the operational procedures and personnel behind them. This list lets the Organization direct contingency resources to the assets the mission depends on. System Owners must record the list with the contingency planning documentation and must update it as the system changes. An outdated asset list sends recovery effort to the wrong places.

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 annually using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: functional exercises.
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 year. 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-04(1) — Coordinate with Related Plans #

Baselines: Moderate / High

Requirement:

Coordinate contingency plan testing with organizational elements responsible for related plans.

Implementation guidance:

System Owners must coordinate contingency plan testing with the organizational elements that own related plans, including the continuity of operations, disaster recovery, business continuity, incident response, and crisis communications plans. The test must exercise the dependencies and handoffs the plans share. Where practical, the System Owner must schedule a joint exercise with those elements. Where a joint exercise is not practical, the System Owner must share the scenario and the results with each plan’s owner, so each owner can see where the plans do not connect.

CP-06 — Alternate Storage Site #

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

Requirement:

1. Establish an alternate storage site, including necessary agreements to permit the storage and retrieval of system backup information; and
2. Ensure that the alternate storage site provides controls equivalent to that of the primary site.

Implementation guidance:

The Organization must keep an alternate storage site and the agreements needed to store and retrieve system backup information there. System Owners must confirm that backups for their systems reach the alternate site, and not only appear in the plan. The alternate site must provide controls that match the primary site, because backup information keeps its sensitivity when it moves. The Organization implements alternate storage in the cloud platform using geographically separate regions. The alternate region inherits the Federal Risk and Authorization Management Program (FedRAMP)-authorized physical and environmental protections of the platform. The Organization configures access, encryption, and logging for the alternate site to the same standard as the primary site. System Owners must prove retrieval from the alternate site during contingency testing, and must not rely on the service description alone.

CP-06(1) — Separation from Primary Site #

Baselines: Moderate / High

Requirement:

Identify an alternate storage site that is sufficiently separated from the primary storage site to reduce susceptibility to the same threats.

Implementation guidance:

The alternate storage site must be far enough from the primary storage site that one event cannot affect both. Events to consider include a natural disaster, a structural failure, and an area-wide loss of infrastructure. The System Owner must document why the separation is enough, using the threats identified in the Organization’s risk assessments. The System Owner must review that rationale when the identified threats change or the storage arrangement changes. An alternate site that shares the primary site’s hazards only copies the same risk.

CP-06(3) — Accessibility #

Baselines: Moderate / High

Requirement:

Identify potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outline explicit mitigation actions.

Implementation guidance:

The System Owner must identify the access problems an area-wide disruption or disaster could create for the alternate storage site. Examples include a network path that is down, credentials or key material that staff cannot reach, and a dependent service that no longer works. The System Owner must document a specific mitigation action for each problem in the contingency plan. Each mitigation must name an owner and describe an action, because recovery cannot wait while staff work out how to get access.

CP-07 — Alternate Processing Site #

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

Requirement:

1. Establish an alternate processing site, including necessary agreements to permit the transfer and 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 processing capabilities are unavailable;
2. Make available at the alternate processing site, the equipment and supplies required to transfer and resume operations or put contracts in place to support delivery to the site within the organization-defined time period for transfer and resumption; and
3. Provide controls at the alternate processing site that are equivalent to those at the primary site.

Implementation guidance:

The Organization must keep an alternate processing site and the agreements that allow the systems and services defined in each system’s BIA and information technology contingency plan (ITCP) to move there and resume. The site must let the Organization resume essential mission and business functions within the Recovery Time Objectives (RTOs) and Maximum Tolerable Downtimes (MTDs) those approved documents specify. The equipment and supplies needed to resume operations must be at the alternate site, or contracts must deliver them within the same window. The controls at the alternate site must match the controls at the primary site. A disruption does not permit the Organization to run with fewer controls. The Organization implements alternate processing in geographically separate cloud platform regions. The System Owner must keep the failover capability aligned with the production architecture it replaces.

CP-07(1) — Separation from Primary Site #

Baselines: Moderate / High

Requirement:

Identify an alternate processing site that is sufficiently separated from the primary processing site to reduce susceptibility to the same threats.

Implementation guidance:

The alternate processing site must be far enough from the primary site that the threats in the Organization’s risk assessments cannot disable both at once. Those threats include natural disaster, structural failure, and area-wide loss of infrastructure. Processing capacity that fails together with the primary site does not count as alternate capacity. The System Owner must document why the separation is enough, and must reassess it when the architecture or the identified threats change.

CP-07(2) — Accessibility #

Baselines: Moderate / High

Requirement:

Identify potential accessibility problems to alternate processing sites in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.

Implementation guidance:

The System Owner must identify the access problems an area-wide disaster could create for the alternate processing site. Examples include loss of connectivity, staff who are out of reach, and services the same disruption took down. The System Owner must document a specific mitigation action for each problem in the contingency documentation. Each mitigation must name an owner and a trigger. Contingency tests must exercise the access assumptions, so the Organization does not rely on untested assumptions during a disaster.

CP-07(3) — Priority of Service #

Baselines: Moderate / High

Requirement:

Develop alternate processing site agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives).

Implementation guidance:

Agreements for the alternate processing site must contain priority-of-service provisions that match the Organization’s availability requirements, including the Recovery Time Objectives (RTOs) in the BIA. Without those provisions, the Organization’s resumption waits behind other customers’ demand during a regional disruption. The System Owner must verify at each agreement review that the provisions exist and match the current recovery objectives. An RTO the agreement cannot support is not a valid objective.

CP-08 — Telecommunications Services #

Baselines: Moderate / High 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 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-08(1) — Priority of Service Provisions #

Baselines: Moderate / High

Requirement:

1. Develop primary and alternate telecommunications service agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives); and
2. Request Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness if the primary and/or alternate telecommunications services are provided by a common carrier.

Implementation guidance:

Primary and alternate telecommunications service agreements must contain priority-of-service provisions that match the Organization’s availability requirements, including its recovery time objectives. During a regional disruption, carriers restore service in priority order, and an organization without provisions waits. Where a common carrier provides primary or alternate services, the Organization must request Telecommunications Service Priority (TSP) for every service that supports national security emergency preparedness. The Organization must complete the enrollment before it needs the priority, so the restoration priority is in the contract.

CP-08(2) — Single Points of Failure #

Baselines: Moderate / High

Requirement:

Obtain alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services.

Implementation guidance:

The Organization must obtain alternate telecommunications services that reduce the chance of sharing a single point of failure with the primary services. The Organization must use separate providers where feasible, and must use separate physical paths and facilities in every case. The System Owner must require each provider to disclose enough about its actual transmission routing to confirm the separation. Where the System Owner cannot verify the independence, the System Owner must treat the services as dependent.

CP-09 — System Backup #

Baselines: Low / Moderate / High 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-09(1) — Testing for Reliability and Integrity #

Baselines: Moderate / High

Requirement:

Test backup information at least annually to verify media reliability and information integrity.

Implementation guidance:

The Organization must test backup information at least every year to verify that the media work and the information matches the source. The test must restore data and compare it with the source. A job log that reports success is not a test. System Owners must make sure the test samples cover the backup sets that recovery depends on. System Owners must treat a failed test as a failed backup: find the cause, correct it, and test again.

CP-09(8) — Cryptographic Protection #

Baselines: Moderate / High

Requirement:

Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of all backup files.

Implementation guidance:

The Organization must use cryptographic mechanisms to prevent unauthorized disclosure and modification of the defined backup information. The protection must apply to backups at rest in both primary and alternate storage. Backup files hold a complete copy of the Organization’s sensitive information in portable form. The encryption strength must match the sensitivity of the information in the backups. The Organization must manage the keys so that losing control of the storage never means losing control of the information.

CP-10 — System Recovery and Reconstitution #

Baselines: Low / Moderate / High 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.

CP-10(2) — Transaction Recovery #

Baselines: Moderate / High

Requirement:

Implement transaction recovery for systems that are transaction-based.

Implementation guidance:

Systems that process transactions, including database and transaction processing components, must implement transaction recovery. The mechanisms, such as journaling and rollback, must let interrupted processing resume at a known transaction boundary without loss or duplication. Recovery to the last backup alone can erase a day of transactions. System Owners must confirm that the transaction recovery capability meets the system’s Recovery Point Objective (RPO). The journal must capture whatever the mission cannot afford to lose.

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-20-19: Harnessing Technology to Support Mission Continuity, March 22, 2020.