RMFInsider

CP-4 gives you three obligations: test the contingency plan for the system at a frequency your organization defines using tests your organization defines, review the test results, and initiate corrective actions if the test turns up gaps. That is the entire control. On DoD systems the frequency is typically annual, the test is usually a tabletop, and the evidence is a dated test record plus an after action report naming the participants, the scenario, what did not work, and who owns each fix. Nobody grades your exercise on realism. What gets graded is whether the test happened inside your own stated window, whether the record matches the current plan version, and whether every corrective action ended up somewhere tracked to closure.

What CP-4 actually requires

NIST SP 800-53 Rev 5 states CP-4 in three parts. Part a: test the contingency plan for the system at an organization-defined frequency, using organization-defined tests, to determine both the effectiveness of the plan and the readiness of the team to execute it. Part b: review the test results. Part c: initiate corrective actions if needed. Those two organization-defined values are the whole game, because you do not get to pick them at assessment time. Your contingency plan picked them, possibly years ago.

CP-4 is self-referential: the contingency plan you wrote under CP-2 defines the test you owe under CP-4. If the plan says the system gets a functional exercise every twelve months and you ran a ninety-minute tabletop, you did not fail NIST, you failed your own document, and the finding writes itself. Read the plan’s testing section word for word before you schedule anything. If it overpromises, revise the plan through document control first, then test to what it says. Write the plan to the test you will actually run every year.

The enhancements shape scope. CP-4(1) coordinates the test with related plans for incident response, continuity, and crisis communications. CP-4(2) covers testing at the alternate processing site. CP-4(3) is automated testing, CP-4(4) is full recovery and reconstitution, and CP-4(5) is self-challenge. Which ones land in your baseline depends on your categorization and overlay set, so pull your control allocation. Coordination with the incident response plan under IR-8 is worth building in regardless, because the first thirty minutes of an outage look identical to the first thirty minutes of an incident.

The test types, from walkthrough to full failover

Organization-defined tests is not permission to be vague. Name the method in the plan, then use the same word in the test record. Four rungs, in order of cost and evidentiary weight:

• Plan review or walkthrough. One person reads the plan against current reality and flags what is stale: phone numbers, role names, IP ranges, a hypervisor you migrated off. Thin as standalone CP-4 evidence on its own.
• Tabletop exercise. The team talks through a scenario against the plan, with a facilitator and a notetaker. No systems are touched. The default for low and moderate DoD systems, and defensible when done properly.
• Functional exercise. Part of the plan is actually executed: restore a file set, stand a service up on the alternate node, run the notification tree for real, fail a database over and read from it. Bounded scope, maintenance window.
• Full interruption or failover test. Production is cut over and recovery runs end to end. Rare outside programs with real redundancy, and it needs system owner and AO agreement in writing first.

Rung three makes evidence easy, because a functional exercise generates artifacts by itself: a restore log with a timestamp, a screen capture of a service coming up on the standby node, a call tree confirmation with names and times. A tabletop generates only what the notetaker writes down, which is why that role matters more than the facilitator.

What DoD systems do, and what annual has to mean

An annual tabletop, scheduled by the ISSO or system owner, with the ISSM on the invite. That is the pattern across the packages I have worked. The reading that keeps you safe is twelve months from the date of the last test, not once per calendar year. A test on 2 February 2026 followed by one on 18 December 2027 spans twenty-two months, and an assessor with a calendar will call it.

Two scheduling habits save pain. Anchor the CP-4 test to a fixed month on the same recurring calendar as your other annual artifacts, so the test, the CP-2 plan review, and your ongoing authorization and monitoring cycle move together. Then, where your AO allows it, run the contingency test and the incident response test in the same week with an overlapping participant list. You brief the same people once, you produce two records, and the CP-4(1) coordination expectation documents itself.

How to run a two-hour tabletop that produces real evidence

Book two hours, not one. Invite the system owner, the ISSO, an administrator who actually holds the credentials, whoever owns backups, and one person from the mission side who can say what happens to operations at hour four. Six to eight people. Name a facilitator and a separate notetaker before the meeting starts, and tell the notetaker plainly that their output is the artifact.

Yes, this is two hours of adults reading a document out loud in a conference room. It is also the only contingency control you can fully satisfy with a calendar invite, a scenario, and one person willing to write down what nobody in the room knows.

• 0:00 to 0:10. Roll call with printed names, roles, and organizations. State the system name, the plan version and date, and the scope.
• 0:10 to 0:20. Read the scenario aloud, including time of day, what is down, and what is still up. Do not let the room start solving it yet.
• 0:20 to 1:10. Walk the plan section by section: activation criteria, who declares, notification sequence, recovery procedures, and the decision point between repair and failover.
• 1:10 to 1:35. Two injects. The recovery lead is unreachable. The backup you planned to use is nineteen hours old instead of four.
• 1:35 to 1:50. Gaps and owners. Every gap gets one sentence, one named owner, and one date before the room moves on.
• 1:50 to 2:00. The notetaker reads the gap list back aloud so nobody can claim later that they never agreed to it.

One discipline separates a record from a transcript. Each time the room hits something the plan does not answer, the facilitator stops, states the gap in one sentence, and assigns a name and a date before continuing. Leave that to the write-up and you will be inventing owners a week later.

Scenarios that actually produce findings

Pick one primary scenario and two injects. Broad scenarios produce broad conversation and no findings. These surface real gaps in my experience:

• The primary storage array fails at 0300 on a Saturday and the on-call administrator has the runbook but not the vendor support contract number.
• Ransomware encrypts a file server and the last three backup sets sit on the same reachable network share.
• A building power event drops the server room for eighteen hours and the generator carries the facility but not your rack.
• The one administrator who knows the restore procedure transferred to another command with no turnover documentation.
• An ordered evacuation ahead of a storm means the plan has to run with nobody physically on site, which is not hypothetical if your system lives in Hawaii or Guam.

What the test record and after action report must contain

One document can carry both, and for a tabletop I prefer one file with two sections over two files that drift apart. The record proves the test occurred. The after action report proves you reviewed the results, which is part b and the part teams skip. The evidence set an assessor will ask for:

• System name, system identifier, and the plan version and date the exercise tested against.
• Test date, start and end times, the test type in the same words the plan uses, and location or platform.
• Participant list with printed names, roles, and organizations. Not a distribution list, not a screenshot of a meeting invite.
• The scenario as it was read to the room, plus any injects, in the text of the record.
• An objective-by-objective result showing what the team did and where they stalled.
• Findings and gaps, each written as a discrete statement, not a paragraph of discussion.
• Corrective actions with a named owner, a target date, and a destination: plan revision, change request, or POA&M item.
• A statement that the results were reviewed, the reviewer named, and a signature and date from the system owner or ISSM.

Sign it. An undated file with no signature block is a draft, and a draft is not evidence. Load it into the package as an artifact mapped to CP-4, and to CP-2 if the plan references it, so the assessor finds it without asking.

Corrective actions, and where they are allowed to go

Part c says initiate corrective actions if needed. Assessors read that as a paper trail, not a good intention. Each gap needs one of three destinations: a plan revision, a procedural or configuration change tracked in your change process, or a POA&M item. There is no fourth option, and a note in a file nobody opens is not a destination.

Gaps meaning the control is not implemented as documented belong on the POA&M with a scheduled completion date and milestones you can hit. Soft milestones are how a CP-4 corrective action sits untouched for eighteen months and then reappears the week before your assessment, which is why POA&M milestones that do not slip name a specific deliverable and a specific person per line. When a gap is documentation only, say so and cite the plan revision number, because an assessor who sees a gap with no visible destination will assume nothing happened.

The two failures assessors catch

A test record with no participant list or no scenario

This is the commonest CP-4 finding I have watched get written. Somebody produces a one-page memo saying the annual contingency plan test was conducted on a date and was successful. No scenario, so nothing was tested. No participant list, so nobody can be shown ready to execute, which is half of part a. The fix costs nothing during the test and is close to impossible to reconstruct six months later.

Corrective actions that were never tracked

The second failure is worse, because it is visible in your own artifact. The after action report lists five gaps. The POA&M has none of them, the change log has none of them, and the plan was never revised. You handed the assessor a signed document identifying deficiencies you then did nothing about, which is a finding against part c and a credibility problem for the rest of the package. Before you sign, put a tracking reference next to every line: a POA&M identifier, a change request number, or a plan revision. A gap with no reference is either not a gap or not finished.

Run the test in October, write the record the same day while the details are fresh, and stop treating CP-4 as the control you catch up on during assessment prep. If you want the annual contingency test on a calendar next to the other artifacts that expire quietly, the RMF Checklist is where I keep mine.