IR-3(2): Coordination with Related Plans

IR-3(2) requires you to coordinate incident response (IR) testing with the owners of related organizational plans so exercises validate real cross-functional dependencies, not just the IR team’s playbook. Operationalize it by defining which plans are “related,” setting joint test objectives, running integrated scenarios, and retaining evidence that planning owners participated and actions were tracked to closure. ¹

Key takeaways:

• IR tests must be coordinated with owners of related plans, not run in isolation. ¹
• Your pass/fail bar is evidence of coordination: shared scope, participation, outputs, and tracked remediation. ¹
• The fastest path is a repeatable “integrated exercise” package: RACI, scenario map, joint after-action report, and POA&M-style tracking.

IR-3(2): Coordination with Related Plans is a deceptively small sentence that drives real operational maturity: “Coordinate incident response testing with organizational elements responsible for related plans.” ¹ For a CCO, GRC lead, or compliance owner, the practical question is predictable: which plans count, who must show up, what does “coordinate” mean in an exam, and what evidence will survive turnover and tool changes?

Treat this requirement as an integration control. Your incident response tests need to validate the handoffs between security, IT operations, legal, privacy, communications, HR, third-party management, and business continuity. Most failed audits here are not because an organization never runs a tabletop, but because the tabletop is run by the IR team alone, without the planning owners whose decisions and actions determine whether the organization can actually respond.

This page gives you a requirement-level implementation approach: define the “related plan” inventory, establish a coordination model, run integrated tests, and retain an evidence bundle that proves coordination occurred and drove corrective action.

Regulatory text

Requirement (verbatim): “Coordinate incident response testing with organizational elements responsible for related plans.” ¹

What the operator must do:

• Identify the organizational plans that intersect with incident response.
• Involve the owners of those plans in the design and execution of incident response tests (tabletops, functional exercises, simulations).
• Produce joint outputs (after-action results and improvements) that update those plans or their procedures where gaps are found.
• Keep evidence that coordination occurred, not just that an IR exercise happened. ¹

Plain-English interpretation

Your IR testing must be run as a coordinated, cross-functional exercise with the teams that own plans IR depends on. If your incident affects customer communications, regulatory reporting, continuity of operations, third-party containment, or disaster recovery, the plan owners for those domains must be part of the test design, the exercise itself, and the corrective-action follow-through. ¹

Who it applies to

This requirement commonly applies in environments aligned to NIST SP 800-53, including:

• Federal information systems
• Contractor systems handling federal data ¹

Operationally, it applies anywhere you run incident response tests and maintain related plans such as:

• Business continuity / continuity of operations
• Disaster recovery and IT service continuity
• Crisis communications / media response
• Legal and regulatory notification procedures
• Privacy incident response (breach response)
• Third-party incident handling and supplier communications
• Physical security / facilities response (if applicable)
• HR/employee relations procedures for insider or workforce-related incidents

You do not need every plan owner in every test. You do need a defensible method for selecting which plan owners must participate based on scenario scope and impact.

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

Step 1: Build the “related plans” register

Create a simple register (spreadsheet is fine) that includes:

• Plan name
• Executive owner (accountable)
• Operational owner (day-to-day)
• Where it lives (system of record)
• Last updated date
• How it interfaces with incident response (1–2 sentences)
• Trigger conditions (what types of incidents activate it)

Practical tip: If you can’t describe the interface in one or two sentences, you probably have overlapping plans that need normalization.

Step 2: Define coordination rules (your minimum bar)

Write a short standard for integrated testing. Keep it operational:

• Coordination trigger: Which incidents require related-plan participation (examples: ransomware, cloud compromise, third-party breach affecting your data, major outage with security cause).
• Participation requirement: Related plan owners must help set objectives, attend the exercise, and sign off on the after-action report for their domain.
• Change requirement: Action items that affect related plans must be routed into the plan’s change process and tracked to closure.

This is where many teams fail: they run a tabletop and write a report, but no one outside security accepts ownership of the fixes.

Step 3: Map scenarios to plan owners (the “invite list” logic)

For each planned test scenario, create a one-page mapping:

• Scenario summary and assumptions
• In-scope assets and services
• Expected decision points (who decides what)
• Related plans activated
• Required participants by role (not just names)

Example mapping (abbreviated):

• Scenario: Third-party SaaS compromise exposing regulated data
• Related plans: Third-party incident intake and escalation, privacy breach response, customer communications, legal/regulatory reporting, business continuity (if service interruption)
• Required participants: Security IR lead, privacy officer, legal counsel, comms lead, third-party risk manager, service owner

This is “coordination” made auditable.

Step 4: Set joint test objectives and success criteria

Define objectives that require cross-plan behavior, such as:

• Validate the decision path for engaging outside counsel and forensic support.
• Validate the internal approval path for customer notifications.
• Validate how third parties are contacted, what evidence is requested, and where it is stored.
• Validate that continuity and recovery steps align with containment steps (no restoring compromised images, no reintroducing known-bad credentials).

Write success criteria in observable terms (completed actions, timestamps captured, approvals recorded), not “team performed well.”

Step 5: Run the exercise with a coordinator and a scribe model

Assign:

• Exercise director/coordinator: keeps the test aligned to objectives and ensures every related plan owner is called on at the right decision points.
• Domain scribes: capture actions, decisions, and gaps for their plan area.
• Timekeeper: captures when key decisions would have happened.

If you rely on one person’s notes, you will miss cross-functional gaps and produce weak evidence.

Step 6: Produce an integrated after-action report (AAR) and remediation tracker

Your AAR should include:

• What happened (scenario timeline)
• Decisions made and by whom
• Where related plans worked as intended
• Where related plans conflicted or were unclear
• Action items with owners and due dates
• Which documents/procedures must be updated

Then track action items to closure using a remediation log (ticketing system, GRC workflow, or a controlled spreadsheet). The audit expectation is sustained operation, not a one-time exercise.

Step 7: Update plans and re-test targeted fixes

When remediation changes a plan materially, schedule a targeted retest or incorporate the change into the next integrated test. Coordination is proven when the plan owners change their materials based on the test results and can show the updated version history.

Step 8: Operationalize in a control “card” (so it survives staff changes)

Create a requirement control card that documents:

• Control objective (IR test coordination with related plan owners)
• Owner (usually IR program owner) and co-owners (BCP/DR, privacy, legal, comms, third-party risk)
• Frequency/cadence (set your internal standard)
• Triggers (material incidents, organizational changes, new critical third parties)
• Execution steps (Steps 1–7 condensed)
• Exceptions process (how you document a missed participant or deferred test) This aligns with the operator-friendly best practice of making the requirement runnable, not theoretical. ¹

Required evidence and artifacts to retain

Build a repeatable “minimum evidence bundle” per exercise cycle:

1. Related plans register (current version, dated)
2. Exercise charter (scope, objectives, scenario-to-plan mapping, participant list)
3. Invites and attendance (calendar invites, sign-in sheet, or meeting attendance export)
4. Exercise materials (injects, scripts, facilitator guide)
5. Exercise notes (scribe notes, timelines, decision logs)
6. After-action report with sign-offs/acknowledgments from related plan owners
7. Remediation tracker (action items, owners, due dates, closure evidence)
8. Plan updates (revised procedures, version history, approvals)

Evidence should be stored in a controlled repository with consistent naming and retention rules. If you use Daydream, treat the evidence bundle as the standard attachment set for the control so each cycle produces the same outputs, and gaps are obvious during control health checks.

Common exam/audit questions and hangups

Auditors and assessors tend to probe three areas:

1. “Which related plans?”
   Expect to explain your selection method and show the register plus scenario mapping.

2. “Show me coordination.”
   They will look for plan-owner participation and outputs. Attendance and sign-offs matter because they prove the exercise was not isolated to the IR team.

3. “Did anything change?”
   AARs without tracked remediation read like theater. Be ready to show closed actions and updated documents tied back to the test.

Common hangup: the organization has great BCP/DR tests and separate IR table tops, but no integrated testing where containment, recovery, communications, and notification decisions collide.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Running IR tabletop with only security	No proof that related plan owners can execute their responsibilities	Require scenario-based participant mapping and minimum roles per scenario
Treating “coordination” as “we emailed them the report”	Coordination must occur during test design and execution	Add co-authored objectives and required participation in the charter
No action tracking	Findings never become plan changes	Maintain a remediation tracker with closure evidence
Unclear ownership across plans	Action items bounce between teams	Use a RACI for decision points and record decision owners in the AAR
Testing a “happy path”	Related plans are stressed during ambiguity	Include injects that force policy and authority decisions (legal hold, comms approval, third-party non-responsiveness)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement, so you should treat this primarily as an assurance and mission-risk requirement rather than a penalty-driven one.

Operational risk is still concrete: uncoordinated testing produces false confidence. In real incidents, the failures happen at the seams, such as recovery steps that destroy forensic evidence, communications sent without legal review, or third-party engagement that stalls because procurement and security disagree on escalation authority. IR-3(2) is designed to force those seams into your test plan. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Name the IR-3(2) owner and the related-plan owner list.
• Build the related plans register and identify gaps (missing owners, outdated locations).
• Publish the coordination rules (minimum participation bar, sign-off requirement, remediation tracking method).
• Choose a single high-value scenario and draft the mapping and exercise charter.

Days 31–60 (run one integrated exercise)

• Hold the integrated tabletop/functional exercise with required plan owners.
• Produce the after-action report within a short window while details are fresh.
• Log remediation items with owners and due dates; route plan changes into each plan owner’s change process.
• Capture the full evidence bundle in your system of record (GRC tool, controlled drive, or Daydream).

Days 61–90 (prove sustained operation)

• Close the highest-risk remediation items and capture closure evidence.
• Update at least one related plan based on exercise outcomes and record approvals/versioning.
• Run a targeted retest for the highest-risk seam (for example: notification approvals, recovery/containment coordination, third-party engagement).
• Add a lightweight control health check: confirm the register is current, evidence bundles are complete, and open actions are on track.

Frequently Asked Questions

Which “related plans” do auditors expect us to include for IR-3(2)?

Include any plan that would be activated or materially consulted during your incident scenarios, such as BCP/DR, crisis communications, privacy breach response, legal/regulatory notification, and third-party incident handling. Your scenario-to-plan mapping is the defensible way to prove you chose the right participants. ¹

Does IR-3(2) require an integrated exercise every time we test IR?

The control requires coordination with related plan owners for incident response testing, but it does not prescribe that every test must involve every plan. Set rules for when coordination is required based on scenario impact, then retain evidence that you followed the rules. ¹

What is the minimum evidence that proves “coordination”?

Keep the exercise charter with the scenario-to-plan mapping, proof of attendance/participation by plan owners, and an after-action report with assigned actions and owners. Add remediation tracking and plan updates to show the coordination produced changes. ¹

Our BCP team runs continuity tests separately. Can we count those as IR-3(2)?

You can reuse continuity test outputs if the scenario explicitly includes incident response decision points and the IR team and related plan owners coordinate on objectives and execution. A pure continuity exercise that never engages IR processes usually won’t satisfy IR-3(2) on its own. ¹

How do we handle third parties in coordinated testing?

For scenarios where third-party failure is a driver, include third-party management and procurement/legal in the exercise and test escalation paths, evidence requests, and communication templates. You can run the test without inviting the third party, but you should validate your internal playbooks for engaging them. ¹

What if a required plan owner can’t attend the exercise date?

Document the exception, obtain a delegate with decision authority, and capture that delegation in the evidence bundle. If neither is possible, reschedule or run a focused follow-up session and attach the follow-up notes and approvals to the same AAR. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON