Contingency Plan

To meet the FedRAMP Moderate contingency plan requirement (NIST SP 800-53 Rev 5 CP-2), you must produce a system-specific contingency plan that names essential mission/business functions, defines recovery objectives and restoration priorities with metrics, and assigns contingency roles with current contact information. Operationalize it by tying plan content to your architecture, dependencies, and runbooks, then keeping it audit-ready. ¹

Key takeaways:

• Your contingency plan must be system-scoped, not an enterprise boilerplate, and must map to mission functions, dependencies, and recovery actions. ¹
• Auditors look for measurable recovery objectives, clear restoration sequencing, and named owners with reachable contact details. ¹
• Evidence matters: retain the plan, review history, role assignments, and the artifacts that prove it can actually be executed. ¹

A “contingency plan” under NIST SP 800-53 Rev 5 CP-2 is the document your assessors use to judge whether your team can restore a specific system to a known-good operating state after disruption. In FedRAMP Moderate environments, that system is usually the cloud service offering boundary, not your whole company. The requirement is simple to read and easy to fail in practice because teams submit generic DR language without the elements CP-2 explicitly calls for: essential functions, contingency requirements, recovery objectives, restoration priorities, metrics, and named roles with contact information. ¹

If you are a Compliance Officer, CCO, or GRC lead, your job is to drive a plan that an operator can run at 2 a.m. and an assessor can trace to your architecture and operational model. That means: defining what “essential” means for this system, declaring realistic recovery targets, sequencing restoration based on dependencies, and assigning accountable humans (and alternates) with accurate contacts. This page gives you requirement-level, step-by-step implementation guidance and the evidence package you should retain for assessments.

Regulatory text

Requirement (CP-2): “Develop a contingency plan for the system that identifies essential mission and business functions and associated contingency requirements; provides recovery objectives, restoration priorities, and metrics; addresses contingency roles, responsibilities, and assigned individuals with contact information.” ¹

Operator interpretation of what you must do

• Produce a system-specific contingency plan that clearly states which functions are essential and what conditions must be met to sustain or restore them. ¹
• Define recovery objectives and metrics in a way that operators can measure during an event and that assessors can test for completeness and internal consistency. ¹
• Establish restoration priorities (what comes back first, second, third) based on system dependencies and mission impact. ¹
• Assign roles and responsibilities to named individuals and include reliable contact information so the plan is executable. ¹

Plain-English requirement (what CP-2 really demands)

CP-2 demands a plan that answers five exam-grade questions for this system:

1. What must keep working (or be restored first) because the mission depends on it? ¹
2. What conditions must be true to recover those functions? Think: required dependencies, credentials, access paths, third-party services, and minimum configurations. ¹
3. How fast do you intend to recover, and how will you measure success? State recovery objectives and metrics that can be tracked during restoration. ¹
4. In what order do you restore components and services, and why? The plan must include a defensible priority order. ¹
5. Who does what, and how do you reach them quickly? Named people, clear responsibilities, current contact details. ¹

Who it applies to

Entity types

• Cloud Service Providers (CSPs) operating a FedRAMP Moderate system boundary. ¹
• Federal Agencies responsible for system operations or shared responsibility execution. ¹

Operational context

• Applies to the information system (the authorization boundary). If your plan reads like “corporate BCP” without boundary-specific architecture, dependencies, and operational runbooks, expect assessors to flag it as not meeting CP-2’s “for the system” intent. ¹

What you actually need to do (step-by-step)

1) Set the scope and assumptions (system boundary first)

• Identify the system name, boundary, and major components (compute, storage, network, identity, logging, key management, CI/CD, ticketing/on-call). Keep it aligned with your FedRAMP boundary documentation. ¹
• Document credible disruption scenarios you plan against (region outage, identity provider failure, ransomware, configuration corruption, lost admin access, third-party outage). You don’t need to be exhaustive; you need to be actionable and aligned to your dependency model. ¹

2) Identify essential mission and business functions

Build a table that forces clarity. Example structure:

Function	Why it’s essential	Degraded-mode allowed?	Downstream impact	Contingency requirement
Authentication to tenant portal	Needed for user access	Yes, break-glass only	Users cannot sign in	Break-glass access path, offline MFA recovery, privileged access approvals

This satisfies the “identifies essential mission and business functions” clause and creates a bridge to contingency requirements. ¹

3) Define recovery objectives and metrics that can be observed

For each essential function (or each critical service that supports it), specify:

• Recovery objective: what “recovered” means in operational terms (service endpoints reachable, control plane stable, admin access restored, core workflows functional). ¹
• Metrics: what you will measure during an event (time to restore access, percentage of critical workflows passing, error rates below a defined threshold, successful data restore validation). Avoid vague metrics like “system operational.” ¹

Practical tip: write metrics so an incident commander can ask for a status update and receive a measurable answer, not a narrative.

4) Set restoration priorities and sequence the work

Create a restoration priority list that reflects dependencies. Typical sequencing (adjust to your architecture):

1. Safety and access: break-glass admin access, identity, key management, privileged workstations/jump hosts.
2. Control plane: configuration management, orchestration, databases that store system state.
3. Data plane: customer-facing APIs/apps, message queues, worker pools.
4. Security logging and monitoring: re-enable detection and auditability as early as possible.

Your plan must state the priority order and the rationale. Assessors will check whether priorities match the system’s real dependency graph. ¹

5) Assign roles, responsibilities, and contacts (named people, not departments)

Minimum set you should cover:

• Incident/Contingency Commander (primary + alternate)
• Infrastructure lead
• Application/service lead(s)
• Security lead (for containment and safe restoration gates)
• Communications lead (customer/agency notifications)
• Third-party liaison (cloud provider, critical SaaS, telecom)
• Compliance/GRC point for evidence capture and assessor communications

Include name, role, phone, email, and escalation path. Make ownership explicit: “does” and “decides,” not “supports.” ¹

6) Embed “how to execute” via runbook links and prerequisites

CP-2 is a planning control, but exams expect the plan to be executable. Add:

• Links to runbooks (restore database from backup, rebuild cluster, rotate keys, revoke tokens, validate integrity).
• Prerequisites: where backups are stored, who holds break-glass credentials, how to access them during outages, and what approvals are required. ¹

If you manage third parties that are operational dependencies (managed database, SMS provider, monitoring platform), list them with contingency requirements (alternate provider, manual fallback, contractual support path, contact numbers). This is where third-party risk management meets CP-2 in the real world.

7) Put the plan under change control

Operational requirement: keep contacts, architecture references, and procedures current. Treat the contingency plan like a controlled document with:

• Owner
• Review cadence tied to material system changes
• Version history and approvals

Daydream can help here by keeping contingency-plan evidence, ownership, and dependency mappings in one place so the plan stays aligned with your system and third-party inventory.

Required evidence and artifacts to retain

Keep an assessor-ready package:

• System Contingency Plan (CP-2) document with the required elements. ¹
• Essential functions and dependency mapping (tables/diagrams referenced by the plan).
• Recovery objectives and metrics definitions ¹.
• Restoration priority list with rationale.
• Roles and responsibilities matrix (RACI is fine if it names individuals) plus current contact list. ¹
• Change history: approvals, review notes, updates after incidents or architecture changes.
• Referenced runbooks and proof they exist in an accessible repository.
• Third-party contact and escalation references for critical dependencies (contracts optional, but escalation paths should be documented).

Common exam/audit questions and hangups

Expect these questions:

• “Show me where the plan identifies essential mission/business functions for this system.” ¹
• “Where are the recovery objectives and how do you measure them during restoration?” ¹
• “Why is this the restoration priority order? Show dependency justification.” ¹
• “Who is accountable for initiating recovery and who is the alternate? Are contacts current?” ¹
• “If your monitoring or identity provider is unavailable, how do you execute the plan?” (tests whether your contingency requirements are real)

Hangups that cause findings:

• Plan is corporate-level and not boundary-specific.
• RTO/RPO-like statements exist but no metrics tied to real checks.
• Roles named as teams, not people, with stale phone lists.
• Restoration priorities ignore identity, keys, or control-plane dependencies.

Frequent implementation mistakes (and how to avoid them)

1. Boilerplate BCP pasted into a FedRAMP package. Fix: build a system-specific function/dependency table and reference architecture artifacts.
2. Metrics that can’t be observed. Fix: use checks your operators already run (synthetic tests, health endpoints, key workflows).
3. “Call the vendor” as the contingency requirement. Fix: document alternate paths, escalation contacts, and what you can do while waiting on the third party.
4. No named alternates. Fix: assign primary and alternate for every critical role, with contacts stored where they are reachable during an outage.
5. Restoration order based on org chart instead of dependencies. Fix: sequence by prerequisites (identity/keys/control plane first).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, a weak CP-2 control increases operational risk: longer outages, unsafe restores, and poor evidence trails after incidents. In FedRAMP assessments, CP-2 gaps commonly translate into assessment findings because the plan is easy to inspect and cross-check against the system boundary.

A practical phased execution plan (30/60/90)

First 30 days (Immediate)

• Appoint a contingency plan owner and backup; confirm document control location. ¹
• Define system boundary scope and list critical dependencies, including third parties.
• Draft essential mission/business functions table and map each function to contingency requirements. ¹
• Create a named contact roster with escalation paths. ¹

By 60 days (Near-term)

• Finalize recovery objectives and metrics per essential function; align them to how operations will actually measure status. ¹
• Publish restoration priorities with dependency justification. ¹
• Link the plan to current runbooks; fill missing runbooks for high-impact components.
• Validate third-party escalation paths and store support contacts in the same controlled location.

By 90 days (Operationalize and keep it current)

• Run a tabletop exercise against at least one realistic disruption scenario and capture updates to the plan based on lessons learned.
• Add triggers for plan review when major architecture or third-party changes occur (new regions, new identity provider, new managed service).
• Centralize evidence (plan versions, approvals, contact confirmations, runbook references). Daydream is a practical place to track ownership, evidence, and third-party dependencies so CP-2 stays assessment-ready.

Frequently Asked Questions

Does CP-2 require a contingency plan per application, or one for the whole FedRAMP boundary?

CP-2 requires a plan “for the system,” so it should align to the authorization boundary and be detailed enough to execute restoration for the boundary’s critical components. ¹

What counts as “essential mission and business functions” for a SaaS provider?

Functions that must be available (or restored first) to deliver the system’s intended service and meet mission needs, such as authentication, core workflows, and data integrity. Tie each function to dependencies and contingency requirements. ¹

Are recovery objectives the same as RTO/RPO?

CP-2 requires recovery objectives and metrics, but it does not prescribe specific labels. If you use RTO/RPO concepts, define them clearly and show how you measure them during restoration. ¹

Do we need named individuals, or can we list an on-call rotation?

CP-2 calls for assigned individuals with contact information. You can reference an on-call role, but you still need accountable named owners and a reliable way to reach the current on-call resource. ¹

How do we handle third-party dependencies in the contingency plan?

Document each critical third party dependency as a contingency requirement: escalation contacts, expected support actions, and your internal fallback steps if the third party is degraded. This keeps restoration priorities realistic. ¹

What evidence is most likely to be challenged by assessors?

Stale contacts, missing restoration priorities, and objectives with no measurable metrics are common failure points. Keep version history and show that plan content matches the real system architecture and runbooks. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5