Cyber · Trackr The Free Compliance Library
⌘K
CP · Plan wizard

Contingency Plan

Documents how the system continues to operate during a disruption and how it recovers afterwards. Covers the controls of the CP family in NIST SP 800-53 r5 and aligns with NIST SP 800-34 r1 (Contingency Planning Guide for Federal Information Systems).

1 System metadata
Full official name of the information system.
Short identifier used in headings and references.
Role or named individual accountable for the system.
Describe what falls inside the authorization boundary - components, services, networks, data flows.
2 Baseline
Determines which controls in this family appear in your plan.
3 Contingency Planning approach
Approach basics → §4.x

Program ownership and the recovery objectives that drive everything else.

Role accountable for keeping the plan current and the program operating (e.g., 'Director of IT Operations', 'Business Continuity Manager').
Target time from disruption to restored operation (e.g., '4 hours', '1 business day'). Drives the alternate-site and backup strategies.
Maximum acceptable data loss measured in time (e.g., '1 hour', '24 hours'). Drives the backup frequency.
Hard upper bound on how long the system can be down before consequences become unacceptable. Drives the alternate-processing strategy.
How critical the system is to the mission. Federal MEF/PMEF terminology per FCD 1; lower tiers are organizational classifications.
Business Impact Analysis (BIA) → §4.x

What functions the system supports, what depends on it, and the tolerance for disruption.

Mission / business functions the system supports. State which are time-critical and why.
Other systems / services this system depends on (auth, network, storage, payments, etc.). Recovery cannot complete without these. Reference SA-9 if external.
Systems / services that depend on THIS system. They will also be affected by a disruption.
Role responsible for keeping the BIA current. Often the System Owner or Business Continuity Manager.
Alternate Storage and Processing → §4.x

Off-site storage and failover processing capabilities (CP-6, CP-7).

Where backups and configuration baselines live in off-site / cross-region storage. Distance from primary, access controls.
Where the system can run when the primary is unavailable. Cloud cross-region, hot/warm/cold site, mutual-aid agreement.
Distance from primary site in miles / km, or cloud-region pair (e.g., 'us-gov-west-1 → us-gov-east-1, ~2400 mi').
How the alternate site is activated. Who authorizes? What credentials / access are pre-positioned?
System Backup Strategy → §4.x

Backup types, frequency, retention, and integrity verification (CP-9). Overlaps with the CM plan's backup_strategy group; the CP plan focuses on disaster-recovery use, the CM plan focuses on configuration restoration.

How often each backup type runs. Tied to RPO target.
How long each backup type is retained. Often shorter for incremental, longer for full.
Where the offsite copy lives. Same as alternate storage site or distinct? Encryption in transit and at rest.
How often backup integrity is verified (hash check + restore test). Separate from full restoration test.
How often a real restore is exercised end-to-end (e.g., 'Quarterly restore-from-cold to scratch environment').
Recovery Strategy → §4.x

How the system is restored from backup or alternate site (CP-10).

Phases per NIST SP 800-34: Activation/Notification → Recovery → Reconstitution → Plan Deactivation. Document who does what at each phase.
Where the technical step-by-step runbook lives. Should be accessible during a primary-site outage.
Role authorized to declare a contingency event and trigger recovery (e.g., 'CP Program Lead in coordination with System Owner').
Order in which components / services are restored. Database first? Auth first? Document the dependency chain.
How the recovered system is validated before returning to production (smoke tests, security scans, data-integrity checks).
Telecommunications Continuity (CP-8) → §4.x

Primary and alternate communication paths.

Main connectivity for the system (carrier + technology, e.g., 'AT&T MPLS + fiber').
Diverse-path backup connectivity. Different carrier? Different technology? Different physical entry to the building?
How often path diversity is verified — carriers can converge to common physical paths over time without notice.
Training and Exercises (CP-3, CP-4) → §4.x

Contingency-specific training and the exercise program.

How exercise findings are tracked to closure (POA&M, internal tracker), and the cadence for revalidating closure.
Safe Mode and Degraded Operations (CP-12) → §4.x

How the system continues operating in a degraded state during a disruption.

What functions remain available in safe mode? What's disabled? Read-only access only? Reduced user populations?
What conditions cause the system to enter safe mode (automated or manual). Detection thresholds.
How users are informed of degraded operation and remaining capabilities (status page, banner, email).
Conditions for returning to full operation. Validation steps before exit.
System Criticality Overview → §2.x

High-level summary of how critical the system is to the mission.

Order-of-magnitude count of users / dependent systems who would be impacted.
If quantifiable. Otherwise qualitative — 'mission-essential', 'core operations halted', etc.
Regulatory / contractual obligations that disruption would violate (uptime SLA, public-facing service requirement, etc.).
Contingency Metrics & KPIs → §6.x

Metrics tracked to demonstrate CP control effectiveness over time.

    Suggested:
    Plan Review Cadence → §6.x

    When and why the plan is revised.

    Events that force a plan revision outside the annual schedule (real disruption, organizational restructure, major architecture change).
    Who receives the plan, and how access is controlled (the plan often contains procedural detail useful to attackers — control distribution accordingly).
    Cross-references to other RMF artifacts → §7

    Where this plan plugs into the broader RMF package.

    Where in the SSP the CP control implementations are summarized (e.g., 'SSP §13.7').
    Convention for CP-related POA&M items (e.g., 'POAM-CP-').
    How recovery from cybersecurity incidents coordinates with the IR plan's recovery phase.
    How CP backup activities coordinate with the CM plan's baseline-storage and integrity-protection approach.
    Pointer to the CA-7 monitoring strategy document tying CP continuous-monitoring metrics to the broader ConMon plan.
    4 Per-control implementation

    Pick a baseline in section 2 and the applicable controls will appear here. Each control gets a card with the official text, related controls, linked CCIs, and fields for your implementation status, narrative, responsible role, and evidence.

    5 Document metadata

    Your answers autosave to this browser. Click Save progress to download a JSON file you can re-upload later or share.