RMFInsider

An incident response plan that passes IR-8 does four things: it lays out the NIST SP 800-61 lifecycle (preparation, detection and analysis, containment, eradication and recovery, post-incident activity) as procedures specific to your system, it names the roles who execute each phase and the authority they have, it defines what counts as an incident using the CJCSM 6510.01B categories, and it states exactly who gets notified, by what channel, within what timeline. In DoD that means your Cybersecurity Service Provider (CSSP) is the first call, the timelines are measured in hours, and a PII breach adds a parallel reporting lane with its own one-hour clock to US-CERT. The plan also has to be reviewed annually, distributed to the people named in it, and exercised under IR-3 with a report to prove it.

This post gives you the section outline I use, the reporting timelines to write into it, the roles the assessor expects to see, and how IR-8 connects to IR-4, IR-5, IR-6, and the rest of the family so one document covers as much of the family as possible.

What IR-8 requires, in plain terms

NIST SP 800-53 Rev 5 IR-8 requires an incident response plan that provides a roadmap for implementing the capability, describes the structure and organization of it, provides a high-level approach for how it fits into the overall organization, meets the unique requirements of the organization (mission, size, structure, functions), defines reportable incidents, provides metrics for measuring the capability, defines the resources and management support needed, addresses the sharing of incident information, and is reviewed and approved by defined personnel. Then: distribute copies to incident response personnel and organizational elements by name or role, update the plan to address changes and problems found during implementation, execution, or testing, communicate changes, and protect the plan from unauthorized disclosure.

Each of those clauses maps to a CCI in eMASS, and the distribution and update clauses are the ones that fail. A plan with no distribution record and no change history is Non-Compliant on two CCIs even if the procedures are perfect. Keep a distribution table and a record of changes inside the document.

The NIST 800-61 structure and what goes in each phase

SP 800-61 Rev 2 is still the structure DoD assessors expect to see, even though Rev 3 (published in 2025) reorganized the guidance around the CSF 2.0 functions. Use the four-phase model as your section headings and reference Rev 3 in your supporting information; you get credit for currency without confusing the reader.

Preparation

The tools, access, and contacts that have to exist before an incident. List the logging sources the team will rely on (host logs, ESS/HBSS, ACAS, the SIEM, network sensors), the jump kit or forensic tools, the communication channels including an out-of-band option in case email is the compromised system, and the contact list by role. Reference the training requirement under IR-2 and state when the team last completed it.

Detection and analysis

How incidents come to your attention (CSSP notification, user report, SIEM alert, ACAS finding, an anomaly the sysadmin noticed) and how the first responder triages them. This is where you define the incident categories and the precursors and indicators for each. Include the documentation requirement: from the first minute, someone is keeping a timeline with timestamps, actions taken, and who took them. That timeline is the single most useful artifact in the entire response and the one that never exists when the after-action review starts.

Containment, eradication, and recovery

Containment strategies by incident type, with the decision criteria: isolate the host, block at the boundary, disable the account, preserve evidence first or contain first. State who has authority to disconnect a system from the network, because during an incident that question comes up and the answer needs to already be written down. Eradication covers removing the cause (malware, the compromised credential, the vulnerable service). Recovery covers restoring from known-good media, validating, and monitoring for recurrence, and it should reference your contingency plan under CP-2 rather than duplicating it.

Post-incident activity

The lessons-learned meeting within a defined window (two weeks is reasonable), the after-action report, evidence retention, and the feed back into the plan and into POA&M items where a control weakness was the root cause. IR-4(1) and IR-8 both expect you to update the plan from what you learned; keep the record of changes current.

DoD incident categories and the reporting chain

CJCSM 6510.01B, Cyber Incident Handling Program, defines the categories your plan should use so your reporting language matches what the CSSP and JFHQ-DODIN expect. The categories cover incidents (root-level intrusion, user-level intrusion, denial of service, malicious logic) and events (unsuccessful activity attempt, non-compliance activity, reconnaissance, investigating, explained anomaly). Write them into the plan with an example of each for your system so a first responder can classify what they are looking at without opening the manual.

The reporting chain in DoD is not “call US-CERT.” It is:

• Your CSSP is the first report for any incident or suspected incident. The CSSP reports up through the tiered structure to JFHQ-DODIN. Your plan names the CSSP, the reporting method (usually the Joint Incident Management System or the CSSP’s designated portal, plus phone), and the timeline.
• Timelines: CJCSM 6510.01B measures initial reporting in hours, not days, and the higher-severity categories (root-level and user-level intrusion, malicious logic, denial of service) require initial notification within one hour of identification. Write “within one hour” in your plan, not “as soon as possible,” because “as soon as possible” is a phrase assessors circle.
• Your chain of command: the ISSM, the system owner, the AO or AO representative for anything that affects the authorization, and the commander or director per your local policy.
• Law enforcement and counterintelligence: DCSA, NCIS, OSI, or Army CI depending on your component, for incidents with an insider or foreign nexus. The plan states who makes that call, and it is not the ISSO acting alone.
• Privacy breach lane: under DoDI 5400.11 and DoD 5400.11-R, a breach involving PII is reported to US-CERT within one hour of discovery and to the component Senior Component Official for Privacy within 24 hours. This lane runs in parallel with the CSSP report, not instead of it.
• Contractor systems: if the system holds Covered Defense Information, DFARS 252.204-7012 requires a report to DIBNet within 72 hours of discovery. That clock is separate from the CSSP clock and both apply.

The wry truth about incident reporting is that nobody has ever been reprimanded for reporting a Category 7 (reconnaissance) that turned out to be a misconfigured vulnerability scanner. ISSOs have been reprimanded for sitting on a Category 1 for a day to “make sure.” Write the plan so the default is to report early and downgrade later.

Roles the assessor expects to see

• Incident Response Team Lead: usually the ISSM or a designated senior analyst. Owns the response and the decision to escalate.
• ISSO: initial triage, documentation, coordination with the CSSP, updating the eMASS record if the authorization is affected.
• System administrators and network staff: execute containment and recovery.
• System owner and program manager: mission impact decisions and resourcing.
• AO or AO representative: informed for any incident that changes the risk posture; decides on continued operation.
• Privacy officer: engaged for any PII involvement.
• Public affairs and legal: named so nobody has to look them up at 3 a.m.

Name positions, not people, in the body, and keep the people-to-position mapping in an appendix that can change without re-approval. Include primary and alternate for each role. An IR plan whose team lead is one person with no alternate is a plan that does not work during that person’s leave, and assessors know when leave season is.

IR-3 testing: the evidence that makes IR-8 believable

IR-3 requires testing the incident response capability at a defined frequency (annually in DoD practice) using defined tests, and IR-3(2) requires coordinating the test with related plans. A tabletop exercise is the minimum: a written scenario relevant to your system (a phished credential with lateral movement, ransomware on a file server, a USB device found plugged into a workstation), the team walking through detection, classification, reporting, containment, and recovery, and a facilitator noting where the plan was unclear or the timeline was missed. The after-action report records the date, participants by role, the scenario, the findings, and the corrective actions with owners. Those corrective actions are either plan updates or POA&M items.

Run the tabletop jointly with your contingency plan test under CP-4 when the scenario allows it. A ransomware scenario exercises both plans naturally, and you get two after-action reports out of one afternoon. Your continuous monitoring plan should list the IR-3 test as a recurring annual event with a target month, so it does not become the thing you remember two weeks before the assessment.

How IR-8 connects to the rest of the IR family

One well-structured plan can serve as the primary artifact for the entire family if you write it with the other controls in mind. IR-4 (Incident Handling) is satisfied by the phase procedures. IR-5 (Incident Monitoring) needs a statement of how incidents are tracked and documented, so include a tracking log format or reference the ticketing system. IR-6 (Incident Reporting) is the reporting chain and timelines section. IR-7 (Incident Response Assistance) is a paragraph describing the CSSP’s support role and how to reach them. IR-2 (Training) and IR-3 (Testing) are satisfied by the training and exercise records, which you reference in the plan and upload separately. Associate the plan artifact with every one of those controls in eMASS and write each implementation statement to point at the section that answers it. The structure for those statements is covered in how to write a control implementation statement.

Keep the plan consistent with the System Security Plan: same system name, same boundary, same CSSP, same personnel appendix. When the assessor cross-reads the SSP and the IR plan and finds two different CSSPs named, the conversation that follows is not about incident response.

Checklist before you upload

• Four 800-61 phases present as procedures specific to this system, not generic text.
• CJCSM 6510.01B categories defined with system-specific examples.
• CSSP named, reporting method and one-hour timeline stated, privacy and DFARS lanes included where applicable.
• Roles by position with primary and alternate; personnel appendix dated.
• Out-of-band communication method identified.
• Distribution list and record of changes inside the document.
• Approval signature and date; review frequency stated and met.
• IR-3 after-action report from the last twelve months uploaded separately.

An assessor reading an IR plan is asking one question: if this system were compromised tonight, would the people named here know what to do and who to call before the CSSP calls them? Write to that question and the CCIs take care of themselves. If you want to see how the IR plan fits with the rest of the evidence an assessor walks through, how to pass an RMF audit covers the whole package, and the RMF Checklist gives you the complete artifact list, family by family, so the IR plan is not the only document that is ready.