Contingency Plan Testing CP-4

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-4 (Contingency Plan Testing) is where you prove the plan works instead of assuming it does. On a set schedule you run a test — from a simple tabletop walk-through up to an actual restore — then review the results and fix whatever failed. A backup you have never restored is a guess, not a backup. It is a Low-baseline control.

What good looks like

• Test on a schedule — do not wait for a real outage to find out the plan has gaps.
• Match the test to the risk: a tabletop review to check the steps, or a full restore to prove the data and services actually come back.
• Do a real restore of this server’s backups into a safe location and confirm the files and services are intact.
• Review the results — what worked, what took too long, and what was missing.
• Initiate corrective actions for anything that failed, and feed those fixes back into the plan (this links to CP-2).

Framework mapping

• NIST CSF 2.0 — ID.IM-02 — Improvements are identified from security tests and exercises
• CIS Controls v8 — Control 11 — Data Recovery

How to move it toward Implemented

• Pick a test type and scope, then run it. For a real restore, pull the latest backup into a scratch path (for example restic restore latest --target /tmp/cp4-test) so production is never touched.
• Verify the restored data — compare a checksum or file count against the source, and start a restored service in a test to confirm it comes up.
• Write a short, dated test report: what you tested, how long recovery took, what failed, and the corrective action for each gap.
• Attach that test report as hardening evidence on the asset, naming CP-4 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.