Contingency Planning Procedure

Approval #

Revision History #

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

1. Purpose #

The people named in this procedure use it to carry out the CP control family policy (POL-CP). It covers every control in the contingency planning family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the CP family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the low security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

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

3. Controls Covered #

This procedure covers the following 6 controls in the CP family:

3.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 that the Procedure section carries out.

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)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the CP controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Contingency Planning family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Contingency Planning Coordinator carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the CP policy (POL-CP) for the role definitions.

4.2 Control-Specific Procedures #

CP-01 — Policy and Procedures #

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

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].

Procedure:

The CISO’s office owns POL-CP and PROC-CP as controlled documents. The CISO’s office opens the review in the policy library in the document management system every 3 years. A major incident or a major change to applicable policy opens a review sooner. The assigned reviewer compares the text with current directives, with the systems and recovery arrangements now in place, and with the lessons recorded from contingency tests and real activations.

The reviewer sends the revision to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and key stakeholders for comment. The CISO approves the revision, and the CISO’s office records the approval in the review record before it publishes the documents. The CISO’s office records each recipient and the revision they received in the distribution record. It keeps superseded versions in the policy library’s version history.

Evidence: the review records with their triggers, the approval records, the version history, and the distribution log for each release.

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)

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.

Procedure:

Before writing the plan, the System Owner completes the business impact analysis (BIA) for the system, whatever its impact level. The System Owner follows the three BIA steps in NIST SP 800-34r1. First, the System Owner identifies the mission and business processes and sets the maximum tolerable downtime, recovery time objective, and recovery point objective. Next, the System Owner identifies the resources the system needs. Last, the System Owner sets the recovery order for those resources. The ISSO reviews the BIA and stores it with the plan in the governance, risk, and compliance (GRC) system.

The System Owner writes the Information System Contingency Plan (ISCP) from the Organization’s template, using the BIA results. The System Owner organizes the plan around the activation and notification, operations, and reconstitution phases and names the person who fills each contingency role. The Authorizing Official or a designated representative and the System Owner approve the plan. The System Owner sends the approved copy to the key contingency personnel, uploads it to the GRC system, and records the distribution. The System Owner coordinates contingency planning with incident handling.

Every year, and after each significant change or a problem found in testing, the System Owner updates the BIA and the plan. The update includes lessons learned from tests, training, and real activations. The System Owner limits access to the plan to people who need it.

Evidence: the BIA and the approved ISCP in the GRC system, the distribution records, the yearly review and update history, and the lessons-learned records.

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)

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].

Procedure:

When the System Owner assigns a person to a contingency role in the ISCP, the System Owner opens a ticketing system request for role-based training. The training is due within [CP-03 parameter 1 — to be defined] of the assignment. The content matches the role: general staff learn the reporting and communication expectations, administrators learn the restoration and alternate-processing procedures, and officials learn how to make essential-function continuity decisions. The completion record in the learning management system (LMS) shows the date for each person.

When a system change alters the contingency procedures, the affected roles complete update training. Every role repeats the training every year. Taking part in a contingency plan test, including its lessons-learned session, may count as the yearly training when the exercise covered the role’s duties. The LMS holds that participation record in the same way.

Every year, and after a major incident or a major change, the CISO’s office reviews and updates the training content with the lessons from tests and activations. Evidence: the training completion records with dates measured against the [CP-03 parameter 1 — to be defined] and yearly deadlines, the content review history, and the exercise participation records credited as training.

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)

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.

Procedure:

The System Owner schedules the three-year test and scopes it to the system’s Federal Information Processing Standards (FIPS) 199 categorization: tabletop or functional for low, functional for moderate, and full-scale functional for high. The System Owner writes a test plan with success criteria for each objective. The objectives are notification, recovery from backup on an alternate platform, internal and external connectivity, performance on alternate equipment, and return to normal operations. The scenario set includes a destructive cyberattack, such as ransomware. The System Owner may run that scenario jointly with the incident response test.

Participants carry out their documented roles, perform the recovery steps, and record the measured recovery times against the recovery time objective. After the exercise, the System Owner writes an after-action report that states what worked, what failed, and what the plan did not anticipate. The System Owner and the ISSO review the results. Each finding becomes a corrective action in the GRC system, and the ISSO tracks it to closure. Corrective actions include plan revisions, resource fixes, and retraining.

Evidence: the test plan with its objectives and scenario, the after-action report with measured recovery times, the corrective action records in the GRC system, and the plan revision history.

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)

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.

Procedure:

The System Owner configures backup jobs in the cloud platform for each system. The jobs take daily incremental and daily full backups of the user-level information on the components needed to restore full function and of the system-level information. The jobs also capture system documentation every day or when the documents change. The schedule comes from each system’s recovery time objective (RTO) and recovery point objective (RPO), and the System Owner owns that mapping.

The System Owner monitors job status. A failed or missed backup raises an alert and opens a ticketing system incident ticket. The System Owner corrects the failure before the system passes its recovery point objective. The System Owner protects backup information in storage: only authorized roles have access, encryption applies, and integrity checks are available. Copies replicate to alternate storage under the alternate-site arrangements.

Evidence: the backup configurations mapped to the recovery objectives, the job success reports, the failure tickets with their correction times, and the protection settings on backup storage.

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)

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.

Procedure:

The System Owner runs the recovery from the ISCP. Staff restore backups from primary or alternate storage into the cloud platform environment, rebuild systems from known-good baselines, and bring essential functions up in the sequence the plan sets. The System Owner tracks the elapsed time from activation against the RTO, and against the [CP-10 parameter 1 — to be defined] maximum tolerable downtime (MTD) for Mission Essential Systems under Federal Continuity Directive 1.

Reconstitution follows. The System Owner deactivates the interim capabilities used during recovery, verifies the restored system against its approved baseline to confirm a known state, and reestablishes continuous monitoring. Staff open a ticketing system ticket for each remaining fix. The System Owner and the ISSO assess whether the restoration changed anything that needs the Authorizing Official’s attention, including reauthorization.

The System Owner holds a post-recovery review to record what the disruption taught, and those lessons go into the next ISCP update. Evidence: the activation and recovery timeline, the baseline verification results, the reconstitution checklists, the tickets for remaining actions, and the post-recovery review.

4.3 Business Impact Analysis and Contingency Planning Steps #

The System Owner completes the BIA during system initiation and updates it after each significant change. The BIA feeds the seven contingency planning steps in NIST SP 800-34 Rev. 1. Each test checks the five areas that guide lists for contingency plan tests.

Step 1: Conduct the business impact analysis #

These are the three BIA steps in NIST SP 800-34 Rev. 1.

Step 2: Follow the seven contingency planning steps #

These are the seven contingency planning steps in NIST SP 800-34 Rev. 1, with the person who does each.

Step 3: Test the plan #

Each test plan sets success criteria for these five areas.

1. Notification: staff on the call list receive and act on the activation notice.
2. Alternate platform recovery: staff restore the system from backup media on an alternate platform.
3. Connectivity: internal and external connections work from the recovered system.
4. Performance: the system on alternate equipment handles the expected workload.
5. Restoration: staff return the system to normal operations.

The System Owner writes an after-action report that compares measured recovery times with the recovery time objective. The ISSO records each gap as a plan of action and milestones (POA&M) item. Evidence: the signed BIA, the approved contingency plan, the test plan, the after-action report, and the POA&M items in the GRC system.

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).

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Procedure execution records for CP
• Configuration documentation
• Periodic review records
• Evidence for IG FISMA metric CP.01
• Evidence for IG FISMA metric CP.02
• Evidence for IG FISMA metric CP.35

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-20-19: Harnessing Technology to Support Mission Continuity, March 22, 2020.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• FIPS 199: Standards for Security Categorization, February 2004.
• 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-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006.