CP-2: Contingency Plan

Quick-reference card

What this control requires

CP-02 requires organizations to develop and maintain a contingency plan that keeps essential operations running when systems fail or go offline. That plan isn’t a checkbox document filed away for auditors. It’s a living operational playbook that defines which business functions are critical, how quickly you need them restored, and who’s responsible for making that happen.

Beyond naming critical functions, the plan must establish recovery objectives and restoration priorities tied to measurable metrics. It must also assign contingency roles to specific individuals, with their contact information documented and accessible. Beyond recovery, the plan addresses how your organization will sustain essential functions during a disruption, not just after one, and how you’ll eventually restore full system capability without weakening the security controls you originally implemented.

In practice, CP-02 doesn’t exist in isolation. You’re required to coordinate it with your incident handling activities, distribute the plan to everyone who needs it, review it on a defined schedule, and update it whenever organizational changes, environmental shifts, or lessons learned from testing demand revisions. The plan itself must be protected from unauthorized access and modification, which means treating it as a controlled document with appropriate safeguards.

Why it matters

Most organizations treat contingency planning as a compliance formality rather than an operational necessity. The result is a plan that reads well on paper but falls apart under real conditions, because nobody tested it, nobody updated it after the last infrastructure migration, and the contact list references employees who left two years ago.

The result is direct audit risk across every baseline. Since this control applies at LOW, MODERATE, and HIGH impact levels, assessors will evaluate it in virtually every NIST SP 800-53 authorization. A deficient contingency plan can result in certification delays, conditions on authorization, or regulatory findings that trigger remediation timelines.

But the operational cost compounds well beyond audit findings. Without defined recovery objectives and restoration priorities, teams make ad hoc decisions during incidents. Those decisions often conflict with each other, extend downtime, and can permanently degrade system integrity.

In practice, the gap between documented procedures and actual infrastructure widens every time organizations skip regular plan reviews. Eventually the plan becomes functionally useless.

Specifically, contingency planning intersects directly with incident handling. If your contingency planning procedures don’t activate during incident response, you’ve created a gap where two critical processes operate independently when they should reinforce each other.

What attackers exploit

• Prolonged system outages because no restoration priorities exist, forcing teams to recover systems in an arbitrary order that ignores business criticality
• Loss of essential business functions during disruption because the plan never addressed continuity of operations, only post-incident recovery
• Unauthorized access to the contingency plan itself, giving adversaries a detailed map of your organization’s fallback procedures and single points of failure
• Failure to incorporate lessons learned from testing or real incidents, meaning the same recovery gaps persist through repeated disruptions
• Inconsistent or missing role assignments that leave critical recovery tasks unowned during high-pressure situations

How to implement

The most common CP-02 failure isn’t a missing plan. It’s a plan that was written once, approved, and never revisited, leaving your organization with a recovery strategy that describes an environment you no longer operate.

For your organization

Start by conducting a business impact analysis to identify your essential mission and business functions. This analysis drives the entire plan. Without it, you’re guessing at which systems matter most, and that guessing leads to misaligned recovery objectives.

Specifically, define measurable recovery objectives for each essential function. Recovery time objectives (RTOs) and recovery point objectives (RPOs) should reflect your organization’s actual risk tolerance, regulatory obligations, and the system’s impact level.

In practice, these metrics aren’t aspirational targets. They’re commitments you’ll be measured against during audits and real incidents.

Beyond metrics, assign contingency roles to named individuals, not just job titles. Document their contact information and ensure that information stays current through update triggers tied to personnel changes, not just scheduled plan reviews.

Address both continuity and recovery in the plan. Continuity means sustaining essential functions during a disruption through degraded operations, manual workarounds, or alternate information flows.

Where this breaks down is in the distinction between the two. Recovery means restoring full system capability without weakening your original security posture, but many plans focus exclusively on recovery and ignore what happens in the gap between disruption and restoration.

The next gap to close is coordination. Coordinate your contingency plan with incident handling procedures. Your incident response team should know when and how to activate contingency measures, and your contingency plan should reference relevant incident response playbooks. These two processes need to operate as a unified workflow.

Where many organizations fall short is in review cadence. Establish a review schedule that matches your organization’s rate of change. Quarterly reviews work for dynamic environments, while semi-annual reviews may suffice for stable ones.

Finally, protect the plan itself. Store it in a controlled repository with access restrictions. Maintain offline copies in case the primary storage location becomes unavailable during the exact scenario the plan addresses. Common tooling categories include business continuity management platforms, document management systems with version control, and encrypted storage for offline copies.

For your vendors

When assessing vendor compliance with CP-02, the questionnaire should go beyond “Do you have a contingency plan?” That question yields a yes-or-no answer with no useful signal.

Beyond that initial question, ask vendors to describe their essential business functions and the recovery objectives tied to each one. Request specific RTOs and RPOs for the services they provide to your organization. If a vendor can’t articulate these metrics, their contingency planning likely hasn’t reached the level of specificity CP-02 demands.

Specifically, request a copy of the contingency plan’s table of contents and last review date. You don’t necessarily need the full plan, but the structure and currency tell you whether the plan is comprehensive and actively maintained. A plan last reviewed 18 months ago in an environment that’s migrated to new infrastructure since then is a red flag.

Beyond structure, ask for evidence of contingency plan testing. CP-04 covers testing specifically, but CP-02 requires that lessons learned from testing feed back into plan updates. If a vendor tests their plan but never updates it based on results, they’re not meeting the full control requirement.

The next area to probe is coordination. Verify that the vendor coordinates contingency planning with incident handling. Ask how their incident response team activates contingency procedures and whether there’s a defined handoff process. Vendors that treat these processes as separate and uncoordinated present continuity risk to your operations.

Finally, request documentation of role assignments within the contingency plan. You want to see that named individuals, not just departments, own specific recovery responsibilities, and that the vendor updates these assignments when personnel changes occur.

But self-attestation alone isn’t sufficient verification for critical vendors. Request evidence of the most recent plan review, including any changes that resulted from that review.

Evidence examples

Cross-framework mapping

Related controls

• CP-03 — Contingency Training: ensures personnel understand their contingency roles and can execute the procedures documented in the CP-02 plan
• CP-04 — Contingency Plan Testing: validates that the contingency plan works as intended and generates lessons learned that CP-02 requires you to incorporate
• CP-06 — Alternate Storage Site: establishes offsite storage locations that the contingency plan references for backup data and critical records
• CP-07 — Alternate Processing Site: provides the fallback processing capability that contingency plans rely on when primary sites become unavailable
• CP-08 — Telecommunications Services: addresses the communications infrastructure needed to execute contingency procedures during a disruption
• CP-09 — System Backup: produces the backup data that contingency plans depend on for system restoration
• CP-10 — System Recovery and Reconstitution: governs the actual recovery and reconstitution activities that the contingency plan defines and sequences
• CP-11 — Alternate Communications Protocols: establishes backup communication methods referenced in the contingency plan when primary channels fail
• CP-13 — Alternative Security Mechanisms: provides fallback security controls that the contingency plan may activate when primary mechanisms are compromised
• IR-04 — Incident Handling: coordinates directly with contingency planning to ensure incident response activities trigger appropriate contingency measures

Frequently asked questions

What is NIST SP 800-53 CP-02?

CP-02 requires organizations to develop and maintain a contingency plan that identifies essential business functions, establishes recovery objectives and restoration priorities, assigns contingency roles to specific individuals, and defines procedures for sustaining operations during system disruptions. The control also mandates regular plan reviews, coordination with incident handling activities, and protection of the plan from unauthorized disclosure. It applies across LOW, MODERATE, and HIGH baselines, making it one of the most broadly required controls in the framework.

What happens if CP-02 is not implemented?

Without a contingency plan, your organization lacks defined recovery objectives and restoration priorities, which means system recovery during an incident becomes ad hoc and uncoordinated. Assessors evaluating your authorization will flag the absence of CP-02 as a significant deficiency, potentially resulting in conditions on your authorization or delays in certification. The operational consequence is equally serious, since teams without documented contingency roles and contact information waste critical time during disruptions figuring out who owns which recovery tasks.

How do you audit CP-02?

Auditors verify CP-02 by examining the contingency plan itself and confirming it addresses all required elements, including essential business functions, recovery metrics, named role assignments with contact information, and procedures for maintaining operations during disruption. They’ll review evidence that the plan was approved by designated personnel, distributed to key contingency staff, and reviewed at the defined frequency. Auditors also check for documented coordination between contingency planning and incident handling, evidence that lessons learned from testing or real events were incorporated into plan updates, and controls protecting the plan from unauthorized access.

What is the difference between a contingency plan and a disaster recovery plan?

A contingency plan addresses the full scope of maintaining and restoring operations during any system disruption, compromise, or failure, including procedures for orderly degradation, manual workarounds, and alternate information flows. A disaster recovery plan is narrower in focus, concentrating specifically on restoring IT infrastructure and data after a major disruptive event. Under NIST SP 800-53, the contingency plan is the broader document. It encompasses disaster recovery as one component alongside continuity of operations, alternate processing strategies, and coordination with incident response activities.