CP-4 Contingency plan testing: requirements and evidence

What CP-4 contingency plan testing requires and why assessors check it

When an audit, contract or agency requirement cites SP 800-53 CP-4, the organization must do two things: test its contingency plan at a defined frequency using defined tests, and then review the results and start corrective action where the tests expose gaps. The control is about proof of readiness, not about having a plan document. An untested contingency plan is a set of assumptions, and CP-4 exists because recovery steps, contact lists and backup restores frequently fail in ways nobody sees until a real outage. The catalog's guidance accepts a range of test methods, from checklist reviews and tabletop exercises through to full interrupt simulations, so the organization chooses the depth, but it must define that choice in advance and be able to justify it. Assessors will check the defined frequency, the defined tests and the written results against that definition.

CP-4 applies to the low, moderate and high baselines in SP 800-53B Release 5.2.0 and is not selected for the privacy baseline. The base control has five enhancements. CP-4(1) asks for coordination with related plans and is selected in the moderate and high baselines. CP-4(2) covers testing at the alternate processing site and is selected only in the high baseline. The remaining enhancements (CP-4(3) to CP-4(5)) add further testing expectations and are not part of the baseline selections, so the organization should confirm whether its authorizing body or contract expects them. CP-4 is hard to satisfy for a predictable reason: plans exist on paper, but tests are skipped, scoped so narrowly that they never touch the failure mode that matters, or run without a written record of what failed and who fixed it. Assessors look for that record, and a test without documented results and corrective actions usually fails the examine step.

The catalog names related controls for CP-4: CP-2 (contingency plan), CP-3 (contingency training), CP-8 (telecommunications services), CP-9 (system backup), IR-3 (incident response testing) and IR-4 (incident handling). A useful test often reaches into several of them, for example a restore test under CP-9 that reveals a plan step under CP-2 is wrong. NIST's CSF 2.0 to SP 800-53 Release 5.2.0 crosswalk, posted in the OLIR catalog, maps CP-4 to CSF category RC.RP and subcategories ID.IM-02 and RC.RP-03. NIST marks that crosswalk as not comprehensive, so treat the mapping as a starting point for discussion with your assessor, not as evidence that a CSF assessment is complete. Before scoping tests, confirm which systems, sites and related plans your authorization boundary includes.

Which systems, teams and providers CP-4 tests cover

CP-4 testing is only as broad as the scope the organization sets for its contingency plan. The cards below cover the decisions that most change the effort: which systems the plan covers, who must take part, whether alternate sites or cloud regions are in scope, and how deep the tests go.

Systems covered by the plan

The plan, and therefore CP-4 testing, applies to systems that the organization has categorized and placed in a security baseline. CP-4 is selected in the low, moderate and high baselines of SP 800-53B but not in the privacy baseline, so a system that only falls under the privacy baseline does not inherit the CP-4 test requirement by default. Confirm the category of each system in its inventory before you size the test program. For example, an illustrative environment with three moderate systems and one low system would test the three moderate systems at the defined frequency and the low system on the terms its own plan sets.

Internal teams in each test

A plan that only the IT operations team can execute will fail in a real event that also involves security, application owners, communications and business leaders. Name every role the plan assigns, from the system owner to the people who approve a failover, and confirm that each one attends the tests. Record who was absent and which steps they were responsible for, because assessors check whether personnel with contingency responsibilities took part and reviewed the results.

Third parties in the test

Hosting providers, managed service providers, telecommunications carriers and software vendors often hold pieces of the recovery path. Decide which of them must take part in a test, which can be tested only through their documented recovery commitments, and what contract terms cover their participation. Check that any third party whose service you depend on can be reached during a test, and record the outcome. Verify these points with each provider rather than assuming the contract covers them.

Alternate sites and cloud regions

If the plan relies on an alternate site or a second cloud region, the test must show that the site can actually run the essential functions within the recovery objectives in the plan. This includes checking data replication, network routing, identity access and the availability of supporting services in that location. Ask whether the alternate location is in the test scope for each exercise or only in a periodic exercise. An illustrative case: a region that holds a current copy of data but has never been used to start the application would be tested on paper only.

Backup restore checks

A restore test shows whether backed-up data can be recovered, which a tabletop exercise cannot. Tools such as Bareos schedule and supervise restore jobs and restore files from the current backup or from a backup taken before a given date and time, and restic can read pack files back to confirm stored data is unmodified. Decide which restores are in scope, how often they run, and who signs off on the results. Confirm the exact verification options your backup tool supports before you write them into the test procedure.

Failover and full interrupt scope

CP-4 guidance covers a range of test methods, from checklists and tabletop exercises to full interrupt simulations. Each step up the range adds disruption, coordination effort and risk to production, so the scope should match the system category and the recovery objectives. Decide in advance whether a test will switch traffic, stop a primary component or interrupt a live service, and document the stop conditions and rollback steps. Assessors look for a defined test type and a recorded reason for the scope chosen.

How an assessor tests CP-4 and what they ask to see

This table sets out how SP 800-53A structures the assessment of CP-4 by method, object type and determination statement, and what each part looks like in practice. Read it as a checklist of what to have ready before an assessor arrives, and note that the most common gaps sit in the review and corrective action steps rather than in running the test itself.

Assessment element	What the assessor does	Evidence to have ready
Examine (plan and documents)	Reads the contingency plan and checks that it defines how and how often testing happens, which tests are used and who owns each step	Current contingency plan, written test schedule, test scripts or exercise plans with defined methods
Examine (test documentation)	Checks that each test has a recorded scope, method, date, participants and the systems it covered	Test records for each exercise, including checklist, tabletop, functional or full interrupt tests as applicable
Examine (test results)	Compares results against the test objectives and looks for documented findings and outcomes	Signed results, observed recovery times or failures, and a list of issues raised during each test
Interview (personnel)	Asks staff who plan, review or respond to tests to explain the process, their role and what happened after the last test	Named roles with responsibilities, staff who can walk through a recent test without reading from a script
Test (testing processes)	Observes or walks through the organization's process for running, reviewing and acting on contingency tests	Documented process steps, workflow or ticket trail from test to corrective action, and evidence the process is followed
Determination statements (five)	Decides for each statement whether the organization has met it, based on the examine, interview and test results combined	A mapping of each determination statement to the artifact or interview answer that supports it
Finding: tests without defined methods	Flags tests run without a stated method, scope or success criteria, since results cannot show effectiveness	Written test objectives and success criteria approved before each test
Finding: results without corrective actions	Flags test results that identify gaps but show no tracked remediation, owner or closure date	Tickets or POA&M entries linked to each test finding, with closure evidence
Finding: no evidence of review	Flags test results that no one reviewed, approved or escalated	Documented review sign-off, meeting minutes or approval records for each test cycle

How to implement CP-4 testing in six steps

This sequence turns CP-4 from a line in the contingency plan into a repeatable cycle: define what gets tested and how often, run the tests with named people, record the results in a fixed format, fix what failed, and feed those lessons back into the plan. Each step ends with an artifact an assessor can examine.

Set test frequency and define test types in the plan
The system owner and the contingency planning lead write the testing frequency and the test types into the contingency plan itself, because CP-4 requires both to be defined rather than left to judgment. Test types can range from checklist reviews and tabletop exercises to full interrupt simulations, so the plan should name which types apply to which systems and recovery objectives. The step is complete when the approved plan states the frequency, lists each test type with its scope, and an assessor can match each test to a stated requirement. Confirm the frequency against the baseline and any agency, contract or regulator requirement that applies to your system.
Select test methods matched to each system
Next, the contingency planning lead chooses a test method for each system in scope, based on its impact level, its essential functions and the recovery objectives set in CP-2. A low-impact internal tool may only need a documented tabletop walkthrough, while a system with alternate processing commitments may need a controlled failover exercise. Record the chosen method, the expected pass criteria and the systems it covers. The output is a test matrix that links each system to its test type, so the scope of every later test can be traced back to the plan.
Schedule and run tests with named roles
The test coordinator issues a test plan for each exercise that names the facilitator, the system owners, the technical responders, the observers and the people who can stop the test. Where the plan involves other parties such as an alternate site provider or a cloud service, their contacts and notice requirements go into the test plan too. Run the test as documented, and log start and end times, deviations and any action taken to stop or contain it. The step closes when the test has been executed and the test record shows who participated and what they did.
Capture results and evidence in a fixed format
Immediately after each test, the coordinator completes a standard results record for the exercise. The record should show the objectives, the steps executed, the measured outcomes such as restore completion or whether the system reached an agreed state, the evidence collected (logs, screenshots, restore reports, backup job output) and the final pass or fail decision against the stated criteria. Using one template for every test lets an assessor compare results across cycles. Store the record with the test plan so both can be examined together. The step is complete when every test has a signed results record and its evidence is retained.
Review results and assign corrective actions
The system owner and the contingency planning lead review each results record, decide whether the test met its objectives, and log each gap as a corrective action. Every action needs a named owner and a due date, and it should be tracked in the same plan of action and milestones or ticketing system used for other security findings. Where a test exposes a backup gap, the owner may need to coordinate with the backup testing controls in CP-9. The output is a corrective action register showing each finding, its owner, its due date and its status, which an assessor can follow from the test result to closure.
Feed lessons into plan updates and the next test
Finally, the contingency planning lead updates the contingency plan, training materials and procedures where the results showed they were wrong or incomplete, and sets the scope of the next test to re-check every corrective action that has closed. Changes to the plan go through the same review and approval as the original, and the revision history records what changed and why. The step is complete when the updated plan is approved, the corrective actions are linked to the next test plan, and the change history shows the loop from test result back to plan revision.

Evidence that passes a CP-4 review

An assessor testing CP-4 looks for a chain of evidence: a plan that sets the test rules, records that show the tests happened, findings that show what failed, and proof that failures led to changes. Each artifact below should link to the next, so a reviewer can trace one test from its schedule to the fix that followed.

Dated test plan with frequency and methods

The test plan states how often the contingency plan is tested, which test methods are used for each cycle, and which systems and scenarios are in scope. Assessors check that the frequency is the one the organization defined, that the methods match the defined tests (for example, a checklist review, a tabletop exercise or a full interrupt simulation), and that the plan is dated and approved. Keep it under version control next to the contingency plan so the two cannot drift apart.

Test records and attendance

Each test needs a record showing the date, scenario, systems exercised, participants and their roles, and the method used. Assessors compare attendance against the people named in the contingency plan, so gaps in responders or missing alternates appear quickly. A standard test record template, stored in the same repository as the plan, makes every cycle produce the same fields.

Results with pass and fail findings

Results should state what was tested, what was expected, what happened and where the gap was. A test that shows no failures deserves the same scrutiny as one that does, because assessors ask whether the scenario was hard enough to be meaningful. Record restore times and data loss measured against the plan's recovery objectives, and link backup job logs or restore verification output where they support a finding.

Review sign-off

Someone accountable for the contingency plan reviews each set of results and signs off on them, and the sign-off is dated. Assessors check that the reviewer is independent of the test execution where practical and that the review covers every failed step. Store the signed review with the results so the link between findings and management oversight is obvious without a search.

Corrective action tracker entries

Every failed step should produce a tracker entry with an owner, a due date, the corrective action and a closure record. Assessors sample entries to confirm that corrective actions were started and completed, and they look for repeat findings across cycles, which suggest the fix did not work. Keep the tracker in the same system as other remediation items so closure can be shown consistently.

Updated plan revisions

When a test exposes a wrong contact, a missing dependency or an outdated recovery procedure, the contingency plan itself should change, and the revision history should show when and why. Assessors compare plan versions against test dates to confirm that the plan in force at each test was the one tested. Keep prior revisions retrievable so the audit trail is complete.

What meeting CP-4 costs in money and effort

This table breaks the cost of CP-4 testing into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No supplied figures exist for prices or durations, so use the table to structure quote requests and internal budgeting rather than to estimate totals.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Staff time to design tests	Internal staff or an implementation partner preparing the test plan and scenarios	One-time at first, then recurring when scenarios change	Number of systems in the plan, number of defined tests, and how well the plan is already documented
Staff time to run and review tests	Contingency role holders, system owners and reviewers who record results and track corrective actions	Recurring at the defined test frequency	Test frequency, number of participants, and whether tests are checklist, tabletop or full interrupt
Backup and restore testing tooling	Licensed commercial backup products charge license and support fees; open-source options such as Bareos and restic carry no license fee	Recurring for licenses and support; one-time for setup	Number of protected systems and data volume; self-hosted open source removes license spend but keeps operating effort
Test environment or infrastructure	Cloud or data center capacity for alternate site, full recovery or automated test runs	Recurring when environments are kept or rented per test	Alternate site scope under CP-4(2), size of recovery environment, and whether capacity can be reused between tests
Coordination with related plans	Staff from incident response, telecommunications and alternate site owners joining coordinated tests under CP-4(1)	Recurring at each coordinated exercise	Number of related plans and third-party providers that must take part
External facilitation or independent testing	External facilitators or testers designing or observing exercises, paid per engagement	Usually recurring, scoped per exercise	Whether the organization runs tests in-house, the complexity of scenarios and any third-party dependencies
Evidence upkeep	Internal compliance staff maintaining test records, results and corrective action logs for assessors	Recurring with every test cycle	Level of automation for capturing logs and results, and how many tests produce evidence
Assessor sampling	The independent assessor, who samples test documentation and results during the assessment	Recurring at each assessment cycle	Number of systems in scope, number of test cycles in the assessment period, and quality of the documentation

How Bareos and restic support CP-4 evidence

Bareos is an open-source backup system built around a central Director that schedules and supervises backup, restore, verify and archive jobs across client systems. The Director keeps a SQL catalog of what was backed up, so an operator can look up which files exist in which job and restore them from the current backup or from the state at an earlier date and time. For CP-4, those job logs, catalog entries and restore results can show that a defined recovery action was run, when it ran and what came back.

Scheduled and logged jobs: Backup, restore and verify jobs run under Director control, and their status is recorded, which gives assessors dated run history to compare against the test schedule the organization defined.
Catalog-based restore records: Restores selected from the catalog can be documented with the job, the point in time and the target host, which supports a test record that names exactly what was recovered.
Point-in-time restores: Restoring from a backup taken before a given date and time lets a test simulate recovery to a known earlier state, a scenario that a defined test may require.
Verify jobs: Verify jobs compare stored data with the catalog, producing evidence that backup media or volumes still match what was recorded.
License review: Bareos is licensed under AGPL-3.0-only. Legal and procurement teams should review what that license means if the organization modifies the software or offers it to third parties, and should confirm it with their own counsel.

Confirm that Bareos can reach every system in scope, that catalog retention matches the test cycle, and that restore tests write to a separate target so production data is not overwritten.

restic is an open-source backup tool licensed under BSD-2-Clause that writes deduplicated, encrypted snapshots to a repository. Its check command verifies the structural consistency of snapshots, trees and pack files. With --read-data or --read-data-subset, it goes further and reads pack files back to confirm that the stored backup data is unmodified. The output of these runs can serve as integrity evidence in a CP-4 test file, showing that the backup a test depends on is readable and intact at the time of the check.

Structural checks: A standard check run confirms that snapshots, trees and pack files are consistent, which is useful as a recurring pre-test control.
Read-back verification: --read-data reads all pack files back, while --read-data-subset reads a defined portion. Organizations should choose the subset approach only if their test documentation explains why the sample is sufficient.
Dated output: Logs from check runs record when integrity was confirmed, which helps link a backup state to a specific test date.
Restore testing: restic restores can be run to a scratch directory as part of a defined test, with the restored content compared to expected results and the outcome recorded.
Scope limits: restic checks data integrity, not whether recovery meets recovery time objectives or whether the plan covers the right systems.

Before relying on either tool for evidence, confirm the license terms with your legal team, test restores in a non-production environment, and check that the retained logs meet the record keeping your assessor expects.

Where CP-4 testing usually falls short and how to close each gap

Most CP-4 findings do not come from missing plans. They come from tests that never happen, tests that prove less than they claim, and findings that stall after the test ends. The cards below take the gaps assessors most often raise and give the fix for each.

Tests defined but never run

The plan names a test frequency and test types, but the calendar shows no executed test, or the last one predates major system changes. CP-4 asks for testing at the defined frequency, so an assessor compares the plan's stated schedule with the dated test records. Fix it by putting each planned test on a tracked schedule with an owner, and by recording the date and participants for every run. Confirm the frequency value in your own plan, since the control leaves it to the organization to define.

Tabletop only, no recovery proof

A discussion-based exercise shows that people know their roles, but it does not show that data can be restored or that the system starts. The catalog's guidance covers a range of methods, from checklists and tabletop exercises up to full interrupt simulations, so a tabletop alone rarely establishes readiness. Fix it by pairing each tabletop with at least one functional test that restores a sample system from backup and records the elapsed time and any failed step.

Results not reviewed or signed off

Test notes sit in a shared folder with no reviewer, no recorded outcome and no decision on whether the plan passed. CP-4 requires the organization to review the test results, so an assessor will ask who reviewed them and when. Fix it by giving each test a written result that states the objectives met, the objectives missed and the named reviewer who accepted the record. Keep the sign-off with the test record, not in a separate email thread.

Corrective actions not tracked to closure

Findings from a test are logged, but nothing shows that the fix was assigned, built and retested. CP-4 requires corrective actions when they are needed, so the assessor looks for a trail from each finding to a verified fix. Fix it by entering every test finding into the plan of action and milestones or your issue tracker with an owner and due date, then linking the closing retest to the original finding. Open items older than the next test cycle deserve a visible escalation.

Alternate site and full recovery untested

The plan describes an alternate processing site or a full restoration, but no exercise has ever moved the system there or rebuilt it from backups alone. CP-4 enhancements address coordinated testing, alternate site testing and full recovery testing, and the high baseline selects the alternate processing site enhancement. Fix it by scheduling a bounded exercise that brings up the alternate environment with real backup data, and documenting what was missing before the test could succeed.

Plan updates ignore test findings

The contingency plan reads the same after a failed test as it did before, so the next exercise repeats the same gap. CP-4 expects test results to drive corrective action, and the plan itself is the record that must reflect what was learned. Fix it by adding a plan-update step to every test closeout, listing which sections changed, who approved the change and which version now applies. The related controls CP-2 and CP-3 make the same link between plan content, training and testing.

Who owns CP-4 work, what partners take on and where the auditor stops

Your organization owns CP-4 from start to finish. Leadership and the contingency planning owner decide what the plan covers, how often testing happens and which test types fit each system. Your staff then run the tests, record what happened and decide which problems get fixed and by when. CP-4 asks for this ownership directly: the organization must define the test frequency and tests, review the results and start corrective actions, so none of those steps can be handed off in full.

Test frequency and scope: Approve the defined testing frequency and the test types for each system, from checklist reviews to full interrupt simulations.
Test execution: Staff the roles named in the plan, run the tests and capture results at the time they occur.
Results review: Document the outcome of each test against the plan's objectives and record the gaps found.
Corrective actions: Assign owners, track fixes to closure and feed changes back into the plan and related controls such as CP-2 and CP-3.
Coordination: Keep the plan aligned with incident response and other related plans where your system relies on them.

Before engaging anyone, confirm internally who signs off the test program and who holds the authority to accept risk from unresolved findings.

Questions buyers ask about CP-4 testing cost, time and effort

How much effort does CP-4 contingency plan testing take?

CP-4 takes recurring effort rather than a single project. The control asks the organization to test its contingency plan at a defined frequency, using defined tests, then review the results and correct problems. The effort scales with the number of systems in scope, how complex their recovery paths are, and whether tests are tabletop exercises or full interrupt simulations. NIST's catalog lists a range of test methods, from checklist reviews to full interrupt simulations, so a light first cycle can be much smaller than a full recovery exercise. Ask your assessor which test types they expect to see evidence for, and confirm the frequency your own system security plan defines.

Can an in-house team run CP-4 testing without outside help?

Yes, an in-house team can run CP-4 testing, because the organization owns the control and the tests. What usually takes time is not the test itself but the preparation: defining the tests, scheduling people across teams, recording results and tracking corrective actions. Teams that already run disaster recovery exercises or incident tabletops often adapt those records. Teams without that practice usually need more time to agree on objectives and evidence. Whichever way you staff it, the independent assessor will test the results against your own plan, so confirm early what documentation they expect.

How long does preparation for CP-4 testing usually take?

Preparation time depends on how many elements are already in place. The main drivers are whether a current contingency plan exists and is approved, whether recovery objectives are defined for each system, whether backup and restore procedures have been exercised, and how many teams and third parties a recovery depends on. Organizations with mature plans mainly need to define test scenarios and write up results. Organizations starting from a draft plan need to build the plan first. No duration is set by NIST for this, so ask your implementation partner or internal lead to base the schedule on a written scope and a gap review of your current plan.

What does CP-4 require from the organization before testing starts?

Before testing, the organization needs a documented contingency plan, defined test frequency and test types, named roles for people who run and review tests, and a way to record results and corrective actions. The plan should also identify the systems and recovery priorities it covers. Assessors typically look for test documentation and results, interviews with the personnel responsible for testing and responding, and evidence that the testing process itself exists. Confirm with your auditor how they want test records retained and which system boundaries they will sample.

Do we need an outside partner to meet CP-4?

No external party is required by CP-4 itself. The organization owns the control, and the requirement does not call for a third party to run the tests. An outside partner can help with planning test scenarios, preparing self-hosted backup and recovery environments for testing, documenting results, or running a dry run before an assessment. Only an independent auditor or assessor issues an assessment report or opinion on whether the control is met. A partner prepares systems and evidence; it does not certify them. Decide whether you need outside help by comparing your internal capacity with the scope you need to cover, and get any engagement scope in writing before work starts.

What drives the cost of CP-4 testing?

The cost of CP-4 testing comes from people time, test environments, and tooling, with the largest share usually being staff time for planning, executing and reviewing tests. Costs rise with the number of systems and recovery paths, the depth of each test type, the need for separate test environments, and the number of teams that must take part. Recurring costs include repeating tests at the defined frequency, updating the plan after changes, and tracking corrective actions. Open-source tools such as Bareos for backup and restore jobs or restic for verifying backup integrity can reduce licensing spend, but they still need configuration, testing and staff time. Ask any quote to separate one-time setup from recurring testing effort and to state which test types are included.

How often should we test the contingency plan under CP-4?

CP-4 requires testing at a frequency the organization defines, so the right interval comes from your own risk assessment, system security plan and any contract, regulator or framework that applies to you. Many organizations pair a regular tabletop exercise with less frequent full recovery tests, and they retest after significant system changes. NIST does not set a universal interval in the supplied material, so confirm the frequency with your assessor and with any customer or regulator who requires evidence. Write the frequency into the plan so the schedule and the evidence line up.

How DeployOpen scopes and prepares CP-4 evidence

DeployOpen helps teams prepare the contingency plan testing program that CP-4 asks for, inside the client's own infrastructure. The organization owns its contingency plan, test frequency and results, while DeployOpen plans, builds and documents the supporting systems and evidence for an independent assessor to review.

How we scope

The written scope names which systems, contingency plans and test types are covered for CP-4 testing.
Scope records the defined test frequency and test methods that the organization has chosen or confirmed.
Scope states which related controls, such as CP-2 and CP-3, are included and which remain with the client.

How we build

We configure test runbooks, checklists and tabletop exercise templates that match the defined test methods.
We set up logging and ticketing so test objectives, results and corrective actions are recorded in one place.
We prepare test environments and restore procedures in the client's cloud accounts, data centers or air-gapped networks.

How we hand over

Deliverables include test plans, test records, results summaries and corrective action logs in agreed formats.
We document how each test result feeds plan updates, so an assessor can trace findings to changes.
Handover covers operator training so the client's staff can run the next test cycle without outside help.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Retainers can cover recurring test execution, evidence collection and updates when systems or plans change.
Confirm with DeployOpen in writing which assessment steps remain the organization's responsibility and which independent assessor will review the evidence.