IR-3(2): Coordination with Related Plans

To meet the ir-3(2): coordination with related plans requirement, you must run incident response tests in a way that is intentionally coordinated with the teams that own related organizational plans (for example, disaster recovery, continuity, crisis communications, and cybersecurity operations). Operationalize it by defining which plans are “related,” assigning owners, building a joint test calendar, and retaining cross-plan evidence from each exercise. ¹

Key takeaways:

• Define the universe of “related plans” and name accountable owners for each one.
• Design incident response tests that trigger and validate dependencies across those plans, not just the IR plan in isolation.
• Keep evidence that proves coordination occurred: invitations, agendas, injects, attendance, issues, and joint after-action outputs.

IR-3(2) is a coordination control. Auditors read it as: “Show me that your incident response testing is connected to how the organization actually survives and communicates through a disruption.” The control does not require a specific test type, tool, cadence, or maturity model. It requires that incident response testing is not a siloed IT/security activity and that the organizational elements responsible for related plans participate in, or are formally integrated into, the test approach. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat IR-3(2) as a governance and evidence problem. Governance: identify the related plans (BCP/DR, crisis comms, legal/regulatory reporting, physical security, privacy, third-party management, etc.), map the touchpoints, and define who must be in the room for which scenarios. Evidence: produce repeatable artifacts that show coordination was planned, executed, and improved after testing.

This page gives you requirement-level implementation guidance: applicability, a step-by-step procedure, what artifacts to retain, and the exam questions that typically stall teams.

Regulatory text

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

What the operator must do:
You must structure incident response testing so it is planned and executed jointly with the owners of plans that intersect with incident response. Coordination must be visible in the test design (scope and injects), participation (roles invited and present), and outputs (shared lessons learned and tracked remediation). ¹

Plain-English interpretation

IR-3(2) expects incident response testing to prove “organizational choreography,” not just technical containment. If your tabletop ends with security declaring victory while Communications, Legal, Privacy, Business Continuity, and IT Operations were never engaged, you will struggle to demonstrate compliance.

A practical interpretation you can implement quickly:

• Identify which plans have actions that occur during or immediately after an incident.
• For each incident test, pre-stage which related plan owners must participate and what decisions they must practice.
• Capture decisions, handoffs, and dependencies as test objectives and evaluate them in the after-action review.

Who it applies to

Entities: Organizations implementing NIST SP 800-53 controls, including federal information systems and contractor systems handling federal data. ²

Operational context: Any environment where incident response intersects with other organizational response mechanisms, including:

• Regulated operations with notification duties (privacy, regulators, customers, or contractual reporting).
• Organizations with formal continuity/disaster recovery planning.
• Environments with centralized comms, legal hold/eDiscovery, fraud, physical security, or safety programs.
• Organizations dependent on third parties for infrastructure, SaaS, incident response retainers, or managed security services.

If you have multiple “plans” that activate under stress, IR-3(2) applies in practice.

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

Step 1: Define “related plans” for your environment

Create an inventory of plans that are triggered by incidents or materially support incident response. Common examples:

• Business Continuity Plan (BCP)
• Disaster Recovery (DR) / IT Service Continuity
• Crisis Communications / PR
• Legal & Regulatory Reporting playbooks
• Privacy incident response / breach notification procedures
• Cybersecurity operations runbooks (SOC, detection engineering)
• Third-party incident notification and escalation procedures
• Physical security / workplace safety response

Deliverable: “Related Plans Register” with plan name, owner, last review date, and IR touchpoints.

Step 2: Map IR test objectives to cross-plan dependencies

For each incident response test type you run (tabletop, functional, technical simulation), document which related plans must be exercised and why.

A simple mapping table works:

Incident scenario	IR test objective	Related plan(s) to coordinate	Owner(s) required	Evidence expected
Ransomware with service outage	Validate decision to isolate systems and declare disaster	DR/BCP, Crisis Comms, Legal	IT Ops/BCP lead, Comms, Legal	Agenda, injects, attendance, AAR actions
SaaS compromise at key third party	Validate notifications and contractual escalations	Third-party mgmt, Legal, Privacy	TP risk owner, Legal, Privacy	Notice templates used, escalation log

Tip: Keep the scenarios realistic enough that non-security teams have real decisions to make (customer messaging, outage declarations, procurement actions, regulatory analysis).

Step 3: Establish a joint test governance model

You need explicit ownership and operating rules:

• Control owner: Usually IR program owner (CISO org) with GRC support.
• Plan owners: Named leaders for BCP, DR, Comms, Legal, Privacy, IT Ops, TP risk, HR, Facilities as applicable.
• RACI: Who must approve the test plan, who runs the exercise, who records minutes, who owns remediation items.

Minimum governance artifacts:

• Exercise governance charter or SOP covering coordination expectations.
• Contact roster for plan owners and delegates.
• Decision on how conflicts are resolved (for example, who can declare a disaster, who approves external comms).

Step 4: Build a coordinated exercise plan and calendar

Create an annual (or rolling) exercise plan that explicitly lists:

• Scenarios to be tested
• Which related plan owners are required participants
• Preconditions (systems in scope, data sets, communications channels)
• Evidence to capture
• How findings flow into corrective action tracking

Operator reality: calendars slip. The compliance win is to show planned coordination plus rescheduling discipline and make-up execution, not perfection.

Step 5: Execute tests with coordination “hooks”

During the test, force cross-plan activation with designed injects:

• “Customer asks for statement by 3pm.” (Comms)
• “Outside counsel requests legal hold.” (Legal)
• “Critical system RTO is at risk.” (BCP/DR)
• “Third party has not responded to incident notice.” (TP management)
• “Potential personal data exposure identified.” (Privacy)

Your facilitator guide should show when each plan owner is expected to act, what decision they must make, and what artifact they must produce during the exercise (draft statement, decision log entry, notification decision).

Step 6: Produce a joint after-action review (AAR) and track remediation

AAR content should explicitly address coordination:

• What handoffs failed (security to comms, IT ops to BCP, legal to privacy).
• What plan conflicts exist (for example, IR says isolate immediately; BCP says keep minimal service running).
• What updates are required to each plan and who owns them.

Track corrective actions to closure in a system your auditors accept (GRC tool, ticketing system, or a controlled spreadsheet with approvals).

Step 7: Prove repeatability with a control record

Turn IR-3(2) into a repeatable control record:

• Control statement (what you do)
• Scope (systems, business units)
• Frequency (how you decide when to test)
• Evidence list (what you retain every time)
• Exceptions process (how you document when coordination could not occur)

If you use Daydream, this is where it fits naturally: map IR-3(2) to a control owner, link the exercise calendar, and collect recurring artifacts as evidence so assessments do not become a document chase.

Required evidence and artifacts to retain

Auditors typically accept evidence that answers three questions: Did you plan coordination, did it happen, and did you improve based on it?

Retain these artifacts per exercise:

• Exercise plan / test script with named related plan participants
• Meeting invites or distribution list showing cross-functional attendance
• Agenda and scenario injects
• Attendance record (sign-in, minutes, or facilitator notes)
• Decision log (who decided what, when)
• Communications drafts (internal/external) if part of the scenario
• AAR document with findings tied to related plans
• Corrective action register entries and closure evidence (updated plans, training, tickets)

Retain these program-level artifacts:

• Related Plans Register
• RACI for incident exercises
• Annual/rolling exercise calendar
• Evidence retention standard (where stored, access controls, retention period)

Common exam/audit questions and hangups

Expect these questions:

• “Which plans are ‘related’ in your environment, and who owns them?”
• “Show me an incident response test where BCP/DR and Communications participated.”
• “Where in the exercise materials do you test handoffs between teams?”
• “How do findings from the IR test update the BCP/DR plans?”
• “How do you ensure third-party dependencies are included when they are part of the incident path?”

Common hangups:

• No definition of ‘related plans’. Teams assume it is obvious and never document it.
• Attendance without integration. A plan owner “joined the call,” but there were no objectives requiring their actions.
• Findings not routed. AAR stays in security; BCP or Comms never gets assigned actions.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating coordination as “CC’ing stakeholders.”
   Avoidance: Put at least one explicit decision or deliverable on each related plan owner during the test (draft statement, DR declaration decision, notification analysis).

2. Mistake: Testing only one scenario repeatedly.
   Avoidance: Rotate scenarios so different plan dependencies activate (outage-focused, data exposure-focused, third-party compromise, insider misuse).

3. Mistake: IR plan and BCP/DR plan conflicts discovered during a real event.
   Avoidance: Add injects that force tradeoffs (containment vs availability), then update plans to resolve conflicts.

4. Mistake: Evidence scattered across chat logs and personal drives.
   Avoidance: Establish a single controlled evidence repository and name an evidence steward for each exercise.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement. Practical risk still exists: if tests do not include related plans, real incidents often degrade into misaligned decisions, delayed communications, and inconsistent regulatory or contractual notifications. From a governance standpoint, IR-3(2) is also an “auditability” control: you can be operationally decent and still fail an assessment if you cannot prove cross-functional coordination occurred. ¹

Practical 30/60/90-day execution plan

First 30 days (get to a defensible design)

• Identify and document your related plans and owners in a Related Plans Register.
• Publish an IR testing coordination SOP: participation rules, RACI, evidence checklist.
• Select one high-value scenario and rewrite it to include at least three related plan decision points.

By 60 days (run one coordinated exercise end-to-end)

• Schedule and run one coordinated tabletop with IR + at least two related plan owners.
• Capture evidence in a single repository using a standardized naming convention.
• Produce an AAR with cross-plan corrective actions and assign owners and due dates.

By 90 days (make it repeatable and audit-ready)

• Build a rolling exercise calendar that shows future coordination across plan owners.
• Close or materially progress the top corrective actions (plan updates, contact lists, comms templates).
• Create a standing control record for IR-3(2) with linked evidence locations and an exceptions log.

Frequently Asked Questions

Which “related plans” count for IR-3(2)?

Any organizational plan that has required actions during an incident or immediately after it counts in practice. Document your list and rationale so an auditor can see you made an intentional scope decision. ¹

Do related plan owners need to attend every incident response test?

No. You need coordinated testing with the owners of the plans that are relevant to the scenario being tested. Use scenario-based participation rules and record why you selected those participants. ¹

What’s the minimum evidence set to prove “coordination”?

Keep the exercise plan showing cross-plan roles, proof of participation (invite/attendance), and an AAR that assigns corrective actions to the related plan owners. If you cannot show those three elements, audits tend to stall.

We have separate BCP and DR exercises. Does that satisfy IR-3(2)?

Separate exercises help, but IR-3(2) expects incident response testing to be coordinated with those plans. Run at least one exercise where IR and BCP/DR test the handoffs together and produce a joint AAR. ¹

How do we handle third parties in coordinated incident testing?

Coordinate internal testing with the team that owns third-party incident notification and escalation procedures, and include injects that test notice timelines, escalation paths, and evidence capture. If the third party participates, document rules of engagement and what data can be shared.

What if a plan owner refuses to participate or is unavailable?

Document the exception, name an alternate delegate, and reschedule or adjust the scenario so the dependency is still tested. Auditors look for disciplined exception handling more than perfect attendance.

Footnotes

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

2. NIST SP 800-53 Rev. 5