Contingency Plan CP-2

Contingency Planning · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds CP-2 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Contingency Planning family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

CP-2 (Contingency Plan) is the actual plan for keeping this server’s essential functions running — or bringing them back quickly — when something breaks: hardware failure, a bad update, ransomware, or a lost site. It names the essential functions, sets recovery goals, lists who does what, and is kept current as the system changes. It is a Low-baseline control.

What good looks like

Identify the essential functions this server provides and what each one needs to come back (data, services, dependencies).
Set recovery objectives — how fast you must be back (recovery time) and how much recent data you can afford to lose (recovery point).
List roles, responsibilities, and contact information so no one is guessing who restores what during an outage.
Coordinate the plan with incident handling, distribute copies to the recovery team, and protect the plan from tampering or leaking.
Review and update the plan on a schedule and after tests, training, or a real incident — fold in the lessons learned.

Framework mapping

NIST CSF 2.0 — ID.IM-04 — Incident response and other operational plans are established, communicated, maintained, and improved
CIS Controls v8 — Control 11 — Data Recovery

How to move it toward Implemented

Write the contingency plan: essential functions, recovery time and recovery point targets, the recovery team with contacts, and the step-by-step restore order.
Confirm the plan matches reality on the box — check that the backup job (for example a cron entry running restic, borg, or rsync) actually runs and that a restore path is documented.
Store the plan where it survives the server failing — not only on the server it protects — and restrict who can edit it (chmod 640, owned by the recovery role).
Attach the contingency plan as hardening evidence on the asset, naming CP-2 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.