CP-2: Contingency Plan

To meet the cp-2: contingency plan requirement, you must document a system-specific contingency plan that tells operators exactly how the system will be recovered and kept running through disruptive events, and you must be able to prove the plan is owned, current, and executable. Operationalize CP-2 by defining roles, triggers, recovery priorities, and restoration steps, then keeping repeatable evidence that the plan is maintained.

Key takeaways:

• CP-2 is a written, system-level plan with clear recovery actions, ownership, and maintenance expectations.
• Auditors look for execution readiness: decision criteria, contacts, dependencies, and proof the plan matches the real environment.
• The fastest path is to map CP-2 to an owner, a procedure, and a recurring evidence set you can produce on demand.

CP-2 sits in the Contingency Planning (CP) control family and sets the baseline expectation: every in-scope system has a contingency plan that your team can actually follow under stress. In practice, CP-2 fails less because teams have “no plan,” and more because the plan is generic, outdated, missing system dependencies, or disconnected from how recovery is really performed (cloud console steps, identity break-glass, backup locations, third-party runbooks, etc.).

For a Compliance Officer, CCO, or GRC lead, the shortest route to compliance is to treat CP-2 as a requirement to produce and maintain a system-specific operational playbook. Your deliverable is not a business continuity slide deck. It is a document (or controlled set of documents) that an on-call engineer, incident commander, or service owner can execute to recover the system, validate integrity, and restore normal operations.

This page translates CP-2 into concrete implementation steps, evidence artifacts, and audit-ready outputs, with an emphasis on making the control easy to run year after year.

Regulatory text

Requirement excerpt: “Develop a contingency plan for the system that:” ¹

What the operator must do: CP-2 requires you to produce a system-level contingency plan. Even though the excerpt above is short in the provided source, auditors generally evaluate CP-2 as “Do you have a plan for this system, is it fit-for-purpose, and can you demonstrate it is maintained under change control?” Anchor your implementation to the system boundary you use for authorization/assessment and make the plan testable and maintainable ².

Plain-English interpretation

CP-2 means: for each in-scope system, write down how you will keep it operating (or restore it) when something goes wrong, and keep that plan accurate over time. The plan must be specific enough that a responder can:

• Decide when to invoke contingency actions
• Know who is in charge and who to call
• Identify what must be restored first and why
• Execute recovery steps without tribal knowledge
• Verify recovery worked and the system is safe to resume

Who it applies to

Entities:

• Federal information systems
• Contractor systems handling federal data ¹

Operational contexts where CP-2 becomes urgent:

• You provide a shared service that other systems depend on (identity, logging, network, CI/CD)
• You run regulated workloads in cloud where recovery depends on IAM, KMS, and infrastructure-as-code
• You rely on third parties for critical components (SaaS platforms, managed databases, managed security services)
• You have uptime expectations in contracts, interconnection agreements, or internal SLAs

Scope tip: Treat “the system” as your assessed boundary (applications, infrastructure, data stores, and required supporting services). If you can’t describe the boundary crisply, CP-2 documentation will drift into generic statements.

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

Step 1: Assign a control owner and define the system boundary

1. Name a single accountable owner (typically the system owner or service owner).
2. Document system boundary: major components, hosting model, regions/accounts/subscriptions, and key integrations.
3. Identify upstream/downstream dependencies, including critical third parties (IdP, DNS, CDN, payment processor, managed DB, ticketing/on-call tooling).

Output: “CP-2 Ownership & Scope” section in the plan, plus a current system diagram reference.

Step 2: Define contingency objectives you can execute

You need clear, system-specific objectives that drive recovery decisions:

• Recovery priorities: what must come back first (data layer, auth, API, UI, background jobs)
• Minimum service levels acceptable during contingency mode (read-only mode, degraded features, manual processing)
• Data integrity expectations during restoration (what is acceptable to lose, what is not)

Avoid invented metrics if you can’t defend them. If you do define targets (RTO/RPO), treat them as business requirements and ensure engineering agrees and can support them.

Output: “Recovery Objectives & Priorities” section.

Step 3: Build actionable recovery runbooks (the heart of CP-2)

Write steps that responders can follow without guessing. At minimum include:

• Activation criteria: specific triggers (data corruption suspected, region outage, ransomware event, key compromise) and who can declare contingency mode.
• Roles and contacts: incident commander, SRE lead, security lead, business owner, third-party escalation contacts.
• Access prerequisites: break-glass accounts, MFA requirements, vault locations for recovery credentials, KMS key access path.
• Restore procedures: backups/snapshots restore steps, infrastructure rebuild steps (IaC), failover steps, DNS changes, traffic shifting, queue draining.
• Validation steps: integrity checks, service health checks, security checks (secrets rotation, malware scanning where relevant), customer-impact verification.
• Return-to-normal: steps to exit contingency mode, communications closeout, and post-incident review expectations.

Operator tip: If your “runbook” is a paragraph, it will fail in a real event. Use checklists with command examples and links to authoritative internal docs (and ensure those links are access-controlled and maintained).

Output: Controlled runbook documents referenced by the CP-2 plan (or embedded as appendices).

Step 4: Align the plan to adjacent controls so it stays real

CP-2 is easier to defend when it connects to the rest of your program:

• Incident response: ensure the plan references incident communications and escalation paths.
• Backups/restore: ensure recovery steps match actual backup tooling and permissions.
• Change management: require plan review when major architecture changes occur.
• Third-party risk: where recovery depends on a third party, document the dependency and escalation route.

Keep the plan “thin” and link to source-of-truth operational docs, but make sure the CP-2 plan still stands alone as a recovery guide if links break.

Step 5: Put CP-2 on a maintenance and evidence cadence

You need an operating rhythm that produces repeatable artifacts. Minimum operational commitments:

• Review the plan when material system changes happen (new region, new database, new IdP, re-platform).
• Track revisions in a controlled repository (versioning, approvals, change history).
• Generate recurring evidence that the plan is current and owned.

Where Daydream fits naturally: Daydream helps you map CP-2 to an owner, an implementation procedure, and recurring evidence artifacts so the control is not a one-time document exercise and your audit packet is always ready ¹.

Required evidence and artifacts to retain

Auditors typically ask for proof of both design (the plan exists and is adequate) and operation (it is maintained). Retain:

• CP-2 contingency plan (system-specific) with version history and approval/attestation
• System boundary definition and architecture/dependency diagram (or reference to controlled diagram)
• Contact/roles roster with last-updated date
• Recovery runbooks/checklists (restore, failover, validation, return-to-normal)
• Backup and restore references used by the plan (locations, tool names, access model)
• Change tickets or review records showing the plan was updated after material changes
• Evidence pack mapping CP-2 to owner, procedure, and recurring artifacts (control matrix/control narrative)

Common exam/audit questions and hangups

Expect questions like:

• “Show me the contingency plan for System X. Who owns it and when was it last updated?”
• “Walk me through the first hour of recovery for a database corruption event.”
• “What dependencies could block recovery (identity, DNS, third parties), and how do you escalate?”
• “Where are recovery credentials stored, and how do you access them during an outage?”
• “How do you ensure the plan stays current when architecture changes?”

Hangups that trigger findings:

• Plan exists but does not match current architecture
• Recovery requires people who are not available (single points of failure)
• No documented activation criteria or decision authority
• Missing dependency mapping (especially third parties and shared services)

Frequent implementation mistakes and how to avoid them

1. Generic templates shipped as “complete.”
   Fix: require system-specific procedures, commands, and ownership, not boilerplate.

2. No boundary clarity.
   Fix: add a one-page boundary section listing components, accounts/subscriptions, regions, and critical integrations.

3. Runbooks live in random wikis with no change control.
   Fix: keep the plan and runbooks in a controlled repository; require review on material changes.

4. Recovery depends on access that won’t work during an incident.
   Fix: document break-glass and test that the access path is independent of the failed system where possible.

5. Third-party dependencies ignored.
   Fix: add a dependency table with escalation paths and known failure modes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-2, so you should treat this as a control assurance risk rather than a penalty-driven requirement. The practical risk is straightforward: if you cannot recover a system predictably, you face prolonged outages, data integrity loss, missed contractual obligations, and audit findings that can delay authorizations or renewals ².

A practical 30/60/90-day execution plan

First 30 days (stabilize and draft)

• Confirm in-scope systems and pick an order of operations (highest criticality first).
• Assign CP-2 owners per system and create a standard plan template with required sections.
• Draft the contingency plan for the first system, including boundary, roles, activation criteria, dependencies, and recovery priorities.
• Identify missing prerequisites (break-glass access gaps, undocumented restore steps, unknown third-party escalation paths).

Next 60 days (make it executable)

• Convert recovery narratives into step-by-step runbooks with checklists and validation steps.
• Add dependency mapping and escalation contacts, including third parties.
• Put the plan and runbooks under change control; define what types of changes force a review.
• Build the audit packet structure: owner, procedure, and recurring evidence artifacts for CP-2.

By 90 days (operate it like a control)

• Finish CP-2 plans for remaining in-scope systems.
• Run a tabletop exercise using the plan and capture outcomes as internal evidence.
• Close prerequisite gaps discovered earlier (access, backup restore permissions, missing documentation).
• Implement recurring review tasks and dashboarding (owner attestations, review dates, evidence collection workflow).

Frequently Asked Questions

Do I need a separate CP-2 contingency plan for every application?

You need a plan per “system” as you define and assess it. If multiple applications share the same boundary and recovery approach, one system-level plan can cover them, but it must clearly list included components.

Can our incident response plan count as the CP-2 contingency plan?

Usually no. Incident response focuses on detection, triage, containment, and communications, while CP-2 expects system restoration and continuity steps. You can cross-reference incident response, but CP-2 still needs recovery runbooks and restoration decisioning.

What evidence is most persuasive to an auditor for CP-2?

A current, system-specific plan with version history, named ownership, and linked runbooks is the baseline. The strongest supporting evidence is proof the plan is maintained under change control and used in a tabletop or recovery review.

How detailed do the recovery steps need to be?

Detailed enough that a qualified on-call engineer can execute them without guessing. If recovery depends on “tribal knowledge,” document the commands, consoles, permissions, and validation checks.

How should we handle third-party dependencies in the plan?

List each critical third party dependency, what fails if it’s unavailable, and the escalation/contact route. Include workarounds where possible (alternate DNS provider process, manual processing mode, offline exports).

What’s the fastest way to keep CP-2 from becoming shelfware?

Map CP-2 to an owner, a documented procedure, and a recurring evidence set, then tie plan reviews to change management triggers. Tools like Daydream help keep that mapping and evidence collection consistent across systems ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5