CP-4(1): Coordinate with Related Plans

CP-4(1) is a deceptively small enhancement with real audit bite because it targets a common failure mode: contingency plan tests that run in isolation. The technical team tests backups and recovery. The incident response team runs a tabletop. Business continuity runs an exercise. Each group “passes,” but dependencies break during a real event because no one tested the seams between plans.

This requirement forces you to test those seams. “Related plans” are the plans that must work together during disruption: incident response, disaster recovery, business continuity, crisis communications, physical security, emergency management, and even third-party/provider continuity when you depend on them. CP-4(1) does not ask you to rewrite every plan. It asks you to coordinate testing so roles, triggers, handoffs, and decision points are validated across plan boundaries. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to assign a single control owner for CP testing coordination, build a shared test governance cadence, and standardize artifacts so every exercise produces audit-ready evidence.

Regulatory text

Requirement (excerpt): “Coordinate contingency plan testing with organizational elements responsible for related plans.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do:
You must ensure contingency plan tests are planned and executed in collaboration with the owners of plans that intersect with contingency operations. In practice, that means:

• Identify the “related plans” for the system or environment in scope.
• Include those plan owners in test design, scenario selection, and success criteria.
• Execute tests in a way that validates cross-team handoffs and dependencies.
• Record outcomes and corrective actions that span plan boundaries.

This is coordination, not observation. A related-plan owner who only receives a post-exercise summary is not coordination.

Plain-English interpretation (what auditors expect)

CP-4(1) expects a coordinated testing program where contingency exercises reflect how your organization actually responds to disruption. Examiners typically look for proof that:

• The right stakeholders were engaged before the test (planning and scoping).
• The test validated interdependencies (for example, incident declaration triggers disaster recovery; communications approves outbound statements; legal/privacy joins when data exposure is possible).
• Findings drove updates across the relevant plans, runbooks, and training.

A tight mental model: CP-4(1) = joint exercises + documented cross-plan fixes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to (entity and operational context)

This requirement applies when you implement NIST SP 800-53 controls, including:

• Federal information systems implementing NIST SP 800-53 control baselines. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or used as the control framework. (NIST SP 800-53 Rev. 5)

Operationally, CP-4(1) becomes most relevant when:

• Your recovery depends on multiple internal teams (IT ops, security, legal, communications, facilities).
• You rely on third parties (cloud hosting, managed security services, payroll, critical SaaS).
• You have multiple environments (on-prem + cloud) and need coordinated failover decisions.

What you actually need to do (step-by-step)

1) Set scope: which contingency plan tests are in-bounds

Define the system(s), business service(s), or mission functions covered by the contingency plan and its testing program. Then list test types you run (tabletop, functional, technical recovery, call-tree, crisis comms drill). Keep the scope statement short and reusable.

Artifact: CP-4(1) scope statement in your contingency testing procedure.

2) Identify “related plans” and their owners (make it explicit)

Create a one-page “related plans register” for the in-scope system/service. Include:

• Plan name (IR Plan, DR Plan, BCP, Crisis Comms Plan, Physical Security/Emergency Plan)
• Plan owner (role + team, not a person’s name only)
• What dependency exists (handoff, approval, resource, data, facility access, third party contact)

Tip: If your organization uses integrated planning (BC/DR/IR), still document ownership and interfaces. Auditors want to see that you intentionally mapped the relationships.

Artifact: Related plans register + RACI for test coordination.

3) Stand up a coordination mechanism (governance that repeats)

You need a lightweight structure that reliably brings the right people together:

• Name a CP-4 testing coordinator (often BCM lead, DR lead, or GRC program owner).
• Establish a recurring meeting or working session for exercise planning.
• Define minimum attendees by plan type (for example, IR + DR + Comms for ransomware scenario tests).
• Require sign-off on test objectives and success criteria.

This is where teams usually fail: coordination is informal, then people change roles, and evidence disappears.

Artifact: Contingency testing coordination SOP (who convenes, who must attend, what gets approved).

4) Build a shared annual test plan and scenario library

Create a test calendar that shows how different plans get tested together. For each planned test:

• Scenario (for example, identity provider outage, ransomware, region failure, insider sabotage, supplier outage)
• Plans involved and why
• Test objectives tied to cross-plan interfaces (handoffs, approvals, escalation paths)
• Preconditions and constraints (maintenance windows, change freezes, third-party participation)
• Success criteria and data capture method

Artifact: Annual contingency testing plan + scenario catalog.

5) Execute exercises with cross-plan checkpoints (force the handoffs)

During the exercise, include explicit “coordination checkpoints,” such as:

• Declaration checkpoint: who declares an incident vs. disaster vs. continuity event; what evidence is needed.
• Communications checkpoint: who approves internal/external messaging; what gets logged.
• Recovery checkpoint: who authorizes failover; how you prioritize services; how third parties are contacted.
• Return-to-normal checkpoint: who validates data integrity; who closes the incident; who triggers lessons learned.

Artifact: Exercise agenda/script with embedded checkpoints; participant list.

6) Capture results in a single after-action report that spans plans

Your after-action report should not be per-team. Make it integrated:

• What worked across teams (handoffs, contact paths, authority lines)
• What broke at interfaces (missing escalation criteria, inconsistent severity definitions, outdated call trees)
• Corrective actions mapped to a plan/runbook/training owner
• Target dates and status tracking

Artifact: After-action report + corrective action plan (CAPA) tracker.

7) Close the loop: update plans and retrain where needed

CP-4(1) becomes defensible when improvements are real:

• Update affected plans/runbooks.
• Update on-call lists and notification tooling.
• Run focused “re-test” drills on corrected interfaces.

Artifact: Change log for each updated plan; training/briefing records; re-test evidence.

8) Map CP-4(1) to ownership, procedure, and recurring evidence

Make the control assessable. Maintain a control record that states:

• Control owner
• Implementation procedure
• Evidence produced each cycle and where stored

If you use Daydream, treat this as a living control card: owner, workflow, tasks, and an evidence checklist that prompts teams before each exercise and collects artifacts after. That reduces the most common CP-4(1) gap: missing proof of coordination even when the exercise was solid.

Required evidence and artifacts to retain (audit-ready checklist)

Keep evidence that proves coordination happened before, during, and after testing:

Evidence item	What it proves	Good-enough standard
Related plans register + owners	You identified related plans intentionally	Dated, versioned, scoped to system/service
Annual test plan / calendar	Coordination is planned, not ad hoc	Shows joint tests and participating plan owners
Planning meeting notes/emails	Cross-team input into scope and objectives	Attendees, decisions, action items
Exercise script/agenda	Test design included cross-plan handoffs	Checkpoints and decision points documented
Attendance/participant roster	Related plan owners actually participated	Roles/teams shown; substitutes noted
After-action report	Outcomes captured across plans	Issues include interface failures, not only team issues
CAPA tracker	Fixes assigned and tracked	Owner, due date, status, closure evidence
Plan updates/change logs	Learnings updated the right documents	Links/versions; approvals if required

Common exam/audit questions and hangups

Auditors commonly ask:

• “Show me how you determined which plans are ‘related’ for this system.” Expect to produce your related plans register.
• “Who owns coordination? What happens if they leave?” They want a role-based assignment and SOP.
• “Where is the evidence that IR and DR tested together?” Meeting notes + joint script + integrated after-action report.
• “How do you ensure corrective actions update the right plan?” CAPA linkage to plan change logs.
• “Do third parties participate when they are part of the recovery path?” If not, document the constraint and how you test the interface (for example, simulated provider notifications, contract-based exercise participation).

Hangup to avoid: presenting separate IR tabletop notes and separate DR restore logs with no connective tissue.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating coordination as “FYI” distribution.
   Fix: Require pre-test sign-off from related plan owners on objectives and success criteria.

2. Mistake: Testing technical recovery without business decision points.
   Fix: Add checkpoints for declaration, prioritization, customer communications, and legal/regulatory notification triggers.

3. Mistake: No single after-action narrative.
   Fix: Publish one integrated after-action report with cross-functional CAPA assignments.

4. Mistake: Evidence scattered across chats and personal drives.
   Fix: Define a system of record (GRC tool or controlled repository) and an evidence checklist per test.

5. Mistake: Ignoring third-party dependencies.
   Fix: Include supplier outage scenarios or explicitly test the escalation and comms path to the provider, even if you cannot run a full joint exercise.

Risk implications (why operators should care)

The operational risk is not “failing a NIST control.” The risk is a preventable outage or prolonged disruption because teams disagree on authority, triggers, or sequence. Coordination gaps tend to surface during:

• ransomware containment vs. recovery sequencing,
• cloud region failures requiring business prioritization,
• identity outages that block recovery actions,
• third-party disruptions where contracts and contacts are stale.

CP-4(1) reduces this risk by forcing your tests to reflect real governance and dependencies. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

Days 0–30: Establish the coordination foundation

• Assign CP-4(1) control owner and backups (role-based).
• Build the related plans register and identify owners.
• Publish the coordination SOP and evidence checklist.
• Create a draft annual test calendar with at least one cross-plan exercise scheduled.

Days 31–60: Run one coordinated exercise end-to-end

• Hold a planning session with all related plan owners.
• Run a tabletop or functional exercise with documented checkpoints.
• Produce an integrated after-action report and CAPA tracker.
• Log plan/runbook changes required; assign owners.

Days 61–90: Close CAPA and make the process repeatable

• Close the highest-risk corrective actions first (handoffs, contacts, authority lines).
• Update plans and document approvals/change history.
• Run a targeted re-test on the fixed interface.
• Operationalize ongoing evidence collection (Daydream or equivalent) so every future test auto-generates an audit packet.

Frequently Asked Questions

Do we need to combine incident response and disaster recovery into one plan to meet CP-4(1)?

No. CP-4(1) requires coordinated testing, not a single consolidated document. Keep separate plans if that fits your operating model, but test the handoffs and document joint planning and outcomes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What counts as a “related plan” in practice?

Any plan that must activate, approve actions, or communicate during a contingency event. Common examples include IR, DR, business continuity, crisis communications, emergency management, and physical security plans. (NIST SP 800-53 Rev. 5 OSCAL JSON)

If we run a DR restore test, is that automatically compliant?

Not by itself. You still need evidence that the DR test was coordinated with related plan owners (for example, IR declaration triggers, comms approvals, business prioritization) and that results fed back into those plans. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle third-party providers who won’t join exercises?

Document the dependency, invite them, and record the constraint. Then test what you control: escalation paths, contract notification requirements, internal decision-making, and simulated provider responses based on documented SLAs and contacts.

What is the minimum evidence set an auditor will accept?

Keep a related plans register, a documented test plan, proof of cross-team planning, an exercise package (agenda/script + attendance), and an integrated after-action report with tracked corrective actions to closure. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who should own CP-4(1) in a mature organization?

Assign ownership to the function that runs contingency exercises end-to-end (often BCM, IT resilience/DR, or GRC), with named stakeholders from security/IR and communications as required participants. The key is role-based accountability and repeatable evidence.