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 high 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 35 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 annually 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 year. 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-02(1) — Coordinate with Related Plans #

Baselines: Moderate / High

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

Procedure:

During ISCP development and at each annual review, the System Owner identifies the related plans that share dependencies with the system. These include the continuity of operations, disaster recovery, business continuity, incident response, and crisis communications plans. The System Owner meets with the owners of those plans. Together they compare recovery priorities, assign shared resources and personnel so two plans do not claim the same ones, and add cross-references where one plan hands responsibility to another. The System Owner records a point of contact for each related plan in the ISCP. Evidence: the coordination records from development and review cycles, the cross-references in the approved plan, and the notes on each conflict resolved.

CP-02(2) — Capacity Planning #

Baselines: High

Conduct capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.

Procedure:

The System Owner estimates the computing, storage, network, and facility capacity the system needs in each contingency phase. For workloads in the cloud platform, the System Owner documents the regions, quotas, and reserved resources that support recovery. For on-premises workloads, the System Owner confirms power, cooling, and circuit capacity at the alternate site. The System Owner records these figures in the contingency plan. During each plan test, the ISSO compares actual capacity with the plan and records any shortfall. Evidence: the capacity section of the plan, cloud quota records, and test reports.

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

Baselines: Moderate / High

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

Procedure:

The BIA records the maximum tolerable downtime (MTD) for each business function. The System Owner builds the ISCP recovery strategy from that MTD. The activation and notification timeline, the recovery sequence, and the resource commitments must let essential functions resume inside the approved window. During the annual review, the System Owner checks these timelines against the current architecture. Contingency tests measure the actual recovery time against the MTD. When a test or a real activation runs past the window, the System Owner corrects the strategy or the resources, or asks the Authorizing Official to review the documented tolerance. Evidence: the BIA with its approved MTDs, the recovery timelines in the ISCP, and the test results that compare achieved times with the objective.

CP-02(5) — Continue Mission and Business Functions #

Baselines: High

Plan for the continuance of essential mission and business functions with minimal or no loss of operational continuity and sustains that continuity until full system restoration at primary processing and/or storage sites.

Procedure:

The System Owner lists the essential mission and business functions the system supports and the minimum resources each one needs. The plan names the alternate processing or storage arrangement, such as another cloud platform region, that keeps those functions running. System administrators follow the plan to move operations to the alternate arrangement. They keep operations there until the primary site is restored. Plan tests confirm that the move works without a gap in service. Evidence: the contingency plan, test reports, and records of each activation.

CP-02(8) — Identify Critical Assets #

Baselines: Moderate / High

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

Procedure:

The System Owner identifies critical assets while preparing the BIA. For each essential function, the System Owner lists the components, services, information, personnel, and procedures the function cannot run without. The System Owner records them in the ISCP. The list sets the recovery sequence. It also tells the System Owner what the backups must cover and where the system needs safeguards beyond the routine baseline. At each annual review, and after a significant system change, the System Owner compares the list with the current architecture and corrects it. Evidence: the critical asset inventory in the approved ISCP, its links to the essential functions in the BIA, and the review history that shows each update.

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-03(1) — Simulated Events #

Baselines: High

Incorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.

Procedure:

The System Owner builds each training scenario from the system’s contingency plan and the threats it faces. The ISSO presents the simulated event in stages and asks participants to act on each stage using the plan. For systems in the cloud platform, the scenario can include simulated loss of a region or service. The ISSO records decisions, delays, and gaps. After the exercise, the System Owner updates the plan and training material to address the gaps. Evidence: scenario documents, attendance records, after-action reports, and plan updates.

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

Procedure:

The System Owner schedules the yearly 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-04(1) — Coordinate with Related Plans #

Baselines: Moderate / High

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

Procedure:

During annual test planning, the System Owner identifies the related plans whose owners share dependencies with the system. The System Owner invites those owners to help design the scenario. A joint exercise rehearses the handoffs between plans. Examples are the point where an incident becomes a plan activation, and a recovery step that depends on a facility or communications decision another plan owner makes. When the test covers only the system’s plan, the System Owner documents the assumptions the test makes about related plans. The owners of those plans confirm or correct them. The System Owner shares any finding that crosses a plan boundary with the responsible element and tracks it until that element decides how to handle it. Evidence: the test plans that show coordination with related plans, the joint exercise records, and the cross-boundary findings with their dispositions.

CP-04(2) — Alternate Processing Site #

Baselines: High

Test the contingency plan at the alternate processing site: (a) To familiarize contingency personnel with the facility and available resources; and (b) To evaluate the capabilities of the alternate processing site to support contingency operations.

Procedure:

The System Owner schedules the alternate site test as part of the yearly contingency plan test. The ISSO prepares a test plan that names the systems, staff, and recovery steps to run at the alternate site.

On test day, the recovery team activates the plan and moves the selected workloads to the alternate the cloud platform region or facility. The team runs the operations phase there and records start and finish times for each step. The ISSO notes every shortfall in capacity, access, or staff readiness.

After the test, the ISSO writes an after-action report with findings and corrective actions. The System Owner updates the contingency plan and signs the revised version.

Evidence: the test plan, timed test logs, the after-action report, and the signed revised contingency plan.

CP-06 — Alternate Storage Site #

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

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.

Procedure:

System backup information replicates to alternate storage in a geographically separate cloud platform region under the service agreements in place for the environment. The System Owner configures replication for each system to match its ISCP. The ISSO verifies on the backup verification cycle that the alternate copies exist and are current.

The controls at the alternate site match the primary site. The same authorized roles hold access, encryption protects the stored backup information, and logging covers storage and retrieval activity. The platform’s Federal Risk and Authorization Management Program (FedRAMP) authorization covers the physical and environmental protections.

During contingency tests, the System Owner restores data from the alternate site. The restoration proves that the media are readable and that the access path works. Evidence: the replication configuration records, the verification results, the access and logging records for the alternate site, and the test restorations retrieved from it.

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

Baselines: Moderate / High

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

Procedure:

The System Owner places alternate storage in a cloud platform region geographically distinct from the primary region. The System Owner selects the region so the two locations do not share the regional exposures the risk assessment identifies, such as weather systems, seismic zones, and power and network infrastructure. The System Owner documents the separation rationale with the ISCP: which threats the analysis considered and why the chosen separation defeats each one. When a risk assessment identifies a new shared exposure, or the storage arrangement changes, the System Owner reevaluates the placement. Evidence: the documented separation analysis in the contingency planning records and the review history that shows each update.

CP-06(2) — Recovery Time and Recovery Point Objectives #

Baselines: High

Configure the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives.

Procedure:

The System Owner records the recovery time objective and recovery point objective in the contingency plan. The system administrator configures backup replication to the alternate storage region in the cloud platform. Replication timing is set so stored copies never fall further behind than the recovery point objective allows.

The ISSO reviews the replication and access settings against both objectives whenever either changes. During the yearly contingency plan test, the recovery team restores data from the alternate storage site. The team records the age of the restored data and the time the restore took. The ISSO compares both results with the objectives and opens a corrective action for any miss.

Evidence: the contingency plan objectives, replication configuration records, timed restore results from the test, and corrective action records.

CP-06(3) — Accessibility #

Baselines: Moderate / High

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

Procedure:

For each system, the System Owner records in the ISCP what staff need to reach alternate storage during an area-wide event. The list covers connectivity into the cloud platform region, the identities and credentials that retrieval requires, and any staff or facility the retrieval depends on. For each problem, the System Owner records a mitigation action and names its owner. Examples are alternate network routes, out-of-band access to credentials, and secondary personnel authorized to carry out the retrieval. The System Owner includes a retrieval under degraded-access conditions in contingency tests to prove the mitigations work. Evidence: the access analysis and mitigation actions in the approved plan, and the test records that show the degraded path exercised.

CP-07 — Alternate Processing Site #

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

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.

Procedure:

Alternate processing runs in a cloud platform region separate from primary operations. For each system, the information technology contingency plan (ITCP) defines what transfers to the alternate region, in what order, and how fast. Those values come from the recovery time objectives (RTOs) and the business-function MTDs in the BIA. The System Owner keeps the alternate environment aligned with the current production architecture. The System Owner updates its images, templates, and capacity as production changes, so a failover does not restore an obsolete copy.

The System Owner provisions the resources that resumption requires in the alternate region, or holds them under agreements that deliver within the recovery window. The System Owner configures the security controls in the alternate environment to the same requirements as the primary environment. The ISSO verifies that the controls match when the environment changes.

The System Owner exercises the failover during contingency testing and measures the elapsed time against the RTOs. Evidence: the ITCP recovery sequences, the alternate environment configuration records, the agreements that cover required resources, the control verification records, and the test results measured against the recovery objectives.

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

Baselines: Moderate / High

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

Procedure:

The alternate processing environment runs in a cloud platform region geographically distinct from the primary region. The System Owner chooses the region against the regional exposures the risk assessment identifies, so one disaster cannot reach both sites. The System Owner documents the separation rationale in the ITCP: the threats considered, the distance between the sites, and the independence of their infrastructure. The System Owner reviews the analysis when the regions, the architecture, or the assessed threats change. Contingency test scenarios assume the loss of the primary region, so each test checks the separation assumption. Evidence: the documented separation analysis, its review history, and the test scenarios that exercise full loss of the primary site.

CP-07(2) — Accessibility #

Baselines: Moderate / High

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

Procedure:

The System Owner records in the ITCP what staff need to reach and operate the alternate processing environment during an area-wide event. The list covers network connectivity into the alternate the cloud platform region, the credentials and administrative access that failover requires, and the personnel expected to carry it out. For each access problem, the System Owner records the mitigation next to the risk it addresses. Examples are alternate connectivity, out-of-band administrative access, and geographically dispersed personnel authorized to act. The System Owner runs the failover under degraded-access conditions in contingency tests. Evidence: the access analysis with its mitigation actions and owners in the approved documentation, and the test records that exercise them.

CP-07(3) — Priority of Service #

Baselines: Moderate / High

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

Procedure:

The System Owner reviews each alternate processing agreement for priority-of-service provisions when the agreement starts and at each renewal. The System Owner compares the provisions with the RTOs in the current BIA and ITCP. The System Owner raises any gap with the CISO for renegotiation, or for a documented risk decision by the Authorizing Official. The System Owner records the review with the agreement file. The System Owner also uses contingency test observations, such as the capacity available during an exercise, to judge whether the provisions would hold in a real regional event. Evidence: the agreement records that show the provisions, the reviews against current RTOs, and the escalation or risk-acceptance records for any gap.

CP-07(4) — Preparation for Use #

Baselines: High

Prepare the alternate processing site so that the site can serve as the operational site supporting essential mission and business functions.

Procedure:

The system administrator builds the alternate processing environment in a separate the cloud platform region or facility. The administrator applies the same approved security settings used at the primary site. The administrator also sets up the accounts, network routes, and licenses the recovery team needs.

When a change at the primary site affects recovery, the administrator applies the matching change at the alternate site. The ISSO then checks that both sites still use the same settings. During the yearly contingency plan test, the recovery team runs essential functions from the alternate site and records any missing item. The System Owner assigns a corrective action for each gap found.

Evidence: configuration comparison records, change tickets for alternate site updates, test results, and corrective action records.

CP-08 — Telecommunications Services #

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

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.

Procedure:

The System Owner documents in the ITCP each system’s telecommunications dependencies: the data and voice services its essential functions require at the primary and alternate sites, and the alternate services arranged for each. The System Owner keeps the alternate telecommunications agreements with the recovery documentation and maps each resumption commitment to the RTOs and MTDs in the approved BIA and ITCP.

When primary telecommunications fail at any site, the System Owner activates the ISCP and starts the alternate services. The System Owner tracks the elapsed restoration time against the objectives. Contingency tests exercise the alternate paths on the test cycle, so the System Owner observes the capacity and the cutover behavior.

The System Owner reviews the arrangements when the architecture or the providers change. Evidence: the documented telecommunications dependencies and agreements, the activation records from disruptions and tests, and the restoration times measured against the recovery objectives.

CP-08(1) — Priority of Service Provisions #

Baselines: Moderate / High

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.

Procedure:

The System Owner reviews each telecommunications agreement when it starts and at each renewal for priority-of-service provisions that match the recovery objectives in the BIA and ITCP. For a common-carrier service that supports national security emergency preparedness functions, the System Owner requests Telecommunications Service Priority (TSP) enrollment and follows the sponsorship until approval. The System Owner records the enrolled services and their TSP status with the agreement file. The System Owner raises any gap, such as an agreement without provisions or an eligible service without TSP, with the CISO for correction or a documented risk acceptance. Evidence: the agreement provisions on file, the TSP enrollment records, and the review and escalation history.

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

Baselines: Moderate / High

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

Procedure:

When the Organization arranges alternate telecommunications, the System Owner compares the physical and logical routing of the primary and alternate services. Each provider documents its transmission paths, shared facilities, and common upstream infrastructure. The System Owner records the analysis with the agreement file. Where the paths converge in a shared conduit, facility, or provider, the System Owner either restructures the service or records the remaining single point of failure for a risk acceptance the Authorizing Official can see. The System Owner repeats the analysis when a provider changes its infrastructure or the Organization changes sites. Evidence: the path-separation analysis, the provider routing documentation, and the risk records for any accepted convergence.

CP-08(3) — Separation of Primary and Alternate Providers #

Baselines: High

Obtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.

Procedure:

The System Owner identifies the threats to telecommunications service named in the system risk assessment. Before signing an alternate service agreement, the System Owner asks each candidate provider for route maps and facility locations. The ISSO compares them with the primary provider’s routes and facilities. The ISSO then records any shared infrastructure.

If a single provider is proposed for both services, the ISSO documents how the provider keeps the services separate. The CISO then approves or rejects the arrangement. The System Owner repeats this review when either provider changes its routing or when the risk assessment is updated.

Evidence: provider route and facility documentation, the ISSO separation analysis, any signed CISO exception, and the updated risk assessment.

CP-08(4) — Provider Contingency Plan #

Baselines: High

1. Require primary and alternate telecommunications service providers to have contingency plans;
2. Review provider contingency plans to ensure that the plans meet organizational contingency requirements; and
3. Obtain evidence of contingency testing and training by providers annually.

Procedure:

The System Owner includes a contingency plan clause in each telecommunications service agreement. On the review schedule, the ISSO asks each provider for its current contingency plan or a summary of it. The ISSO checks whether the plan supports the system’s recovery objectives and alternate communication needs. The ISSO records the result and any gaps.

The System Owner also asks each provider for records of its most recent contingency test and staff training. Records of provider participation in government disaster recovery exercises are acceptable. The ISSO files these records with the system contingency plan. For each gap, the System Owner opens a corrective action and follows up with the provider until it is closed.

Evidence: service agreement clauses, ISSO plan review records, provider test and training records, and corrective action records.

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)

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 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-09(1) — Testing for Reliability and Integrity #

Baselines: Moderate / High

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

Procedure:

At least every month, the ISSO coordinates a restoration test for each system. In the test, staff restore a sample of backup information to an isolated environment in the cloud platform and compare it with the source for completeness and integrity. Where copies replicate to alternate storage, the sample comes from there. The test verifies that the media are readable, that the restore process works as documented, and that the recovered information matches what the backup protected. The ISSO records the results. A failure opens a ticketing system ticket, the System Owner corrects the cause, and staff repeat the restoration until it succeeds. Evidence: the monthly test records with their sample scope, the integrity comparison results, and the correction tickets for each failure.

CP-09(2) — Test Restoration Using Sampling #

Baselines: High

Use a sample of backup information in the restoration of selected system functions as part of contingency plan testing.

Procedure:

Before each contingency plan test, the ISSO selects the system functions to restore and the backup sets to sample. The ISSO records the reason for each choice. The system administrator restores the sampled backups into an isolated the cloud platform environment.

The recovery team then brings the selected functions online with the restored data. Application owners run checks to confirm the functions work and the data is complete. The team records each failed check and assigns a corrective action. The ISSO adds the results to the contingency plan test report.

Evidence: the sample selection record, restore job logs, functional check results, corrective action records, and the test report.

CP-09(3) — Separate Storage for Critical Information #

Baselines: High

Store backup copies of [Assignment: organization-defined critical system software and other security-related information — to be defined] in a separate facility or in a fire rated container that is not collocated with the operational system.

Procedure:

The system administrator sets up automated backup of the operating system images and critical software to a separate the cloud platform region. The ISSO exports the current hardware, software, and firmware inventory and stores a copy in that same separate location. For any physical media, the administrator stores the media in a fire-rated container at a separate facility.

After each major software change or inventory update, the administrator refreshes the stored copies. The ISSO checks the copy dates against the change record and logs the result. During contingency plan tests, the recovery team retrieves a copy to confirm it can be used.

Evidence: backup job logs, stored inventory exports with dates, storage location records, and ISSO check logs.

CP-09(5) — Transfer to Alternate Storage Site #

Baselines: High

Transfer system backup information to the alternate storage site [Assignment: organization-defined time period and transfer rate consistent with the recovery time and recovery point objectives — to be defined].

Procedure:

The system administrator configures backup jobs to copy backup information to the alternate storage region in the cloud platform. The administrator sets the job schedule and bandwidth so each transfer finishes within the required time period and rate. When the administrator ships storage media, the administrator records the shipment and the receipt at the alternate site.

The backup system logs the start time, finish time, and size of each transfer. The ISSO reviews these logs for late or failed transfers. The ISSO then reports each one to the System Owner, who assigns a corrective action.

Evidence: backup transfer logs, shipping and receipt records, ISSO log reviews, and corrective action records.

CP-09(8) — Cryptographic Protection #

Baselines: Moderate / High

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

Procedure:

The System Owner encrypts backup information at rest in the cloud platform using the platform’s customer-configured cryptographic services. The encryption covers primary backup storage and the alternate-region copies. The System Owner manages the keys under the Organization’s key management arrangement: only the roles that restoration requires can decrypt, and the platform logs every key operation. The encryption includes integrity protection, so any change to stored backup data is detectable at restoration. The System Owner verifies the configuration when backup storage starts and reviews it when the storage changes. Restoration tests confirm that encrypted backups decrypt and pass their integrity checks. Evidence: the encryption configuration records, the key access restrictions and logs, and the restoration test results for encrypted backup sets.

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)

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

CP-10(2) — Transaction Recovery #

Baselines: Moderate / High

Implement transaction recovery for systems that are transaction-based.

Procedure:

The System Owner configures transaction recovery on each transaction-based component in the cloud platform environment. Journaling captures committed work between backups, and rollback discards incomplete transactions, so a failure never leaves a partly applied state. The ISCP recovery procedures state how staff replay the journals against the last restored backup to reach the recovery point. Restoration tests for these systems verify that the result is consistent at a transaction boundary, and not only that the files came back. The System Owner protects and monitors journal storage the same way as backup storage. Evidence: the transaction recovery configuration records, the ISCP recovery procedures that cover journal replay, and the test results that show recovery to a consistent transaction boundary.

CP-10(4) — Restore Within Time Period #

Baselines: High

Provide the capability to restore system components within time period consistent with the restoration time-periods defined in the service provider and organization SLA from configuration-controlled and integrity-protected information representing a known, operational state for the components.

Procedure:

The system administrator keeps an approved image and backup for each system component in the cloud platform. The administrator updates the image only through an approved change. The administrator stores each image with an integrity check, such as a hash, and restricts write access.

When a component fails or is compromised, the administrator reimages it from the approved image and restores its data. The administrator verifies the integrity check before use and records the restore start and finish times. During the yearly contingency plan test, the recovery team times the restore of selected components. The ISSO compares results with the required time period and opens a corrective action for any miss.

Evidence: change records for images, integrity check results, timed restore logs, and corrective action records.

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.