Trackr.Live The landing site for Trackr Services
§ Trackr.Live

IR — Incident Response

Incident Response is the control family that decides whether a 0200 alert turns into a documented, contained, reported incident or into a forty-message Slack thread where nobody can find the on-call number. IR-1 through IR-9 in SP 800-53 Rev 5 cover the policy, the training, the testing, the actual handling, the monitoring, the reporting clock, the support resources, the written plan, and spillage response. It does not detect the incident for you (that is SI-4 and AU doing the work), and it is not your recovery-and-restoration story (that is Contingency Planning, CP). Keeping IR distinct from CP matters, because the single most common SSP error in this family is a narrative that quietly turns IR-4 into a disaster-recovery plan.

A schematic incident timeline running left to right: a detection spark, a containment gate, and a reporting clock face with a short deadline marked, the whole thing feeding into a coordination hub.

IR is a control catalog family from SP 800-53, not a phase of the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. IR controls get pulled in at Select, written up and stood up at Implement, and graded at Assess, with the gaps landing in the POA&M and riding into continuous monitoring. The thing continuous monitoring tends to expose for IR specifically is decay: a plan that was current at ATO and is stale eighteen months later because the contact roster rotted and nobody re-ran the tabletop.

What’s actually in the family

The framing the orchestrator’s family notes get right, and most SSPs get wrong, is the split between IR-4 and IR-8. IR-4, Incident Handling, is the operational lifecycle: preparation, detection and analysis, containment, eradication, recovery, and post-incident coordination, lined up against SP 800-61. IR-8, Incident Response Plan, is the written document that names roles, defines reportable-incident thresholds, sets the metrics, and gets distributed and reviewed. Handling is the muscle. The plan is the binder. They are different controls, and an SSP that describes “essential functions, recovery objectives, and restoration priorities” under IR-4 has copied CP-2 language into the wrong family. Recovery objectives are a CP concept. If you see RTO/RPO under IR, flag it.

The live controls in Rev 5:

  • IR-1, Policy and Procedures. Rev 5 retitled every -1 control to plain “Policy and Procedures.” If your SSP still calls this “Incident Response Policy and Procedures,” that long form is a Rev 4 artifact, the same dated-ness tell as an SSP still calling AC-11 “Session Lock.”
  • IR-2, Incident Response Training. Role-based training for incident responders. IR-2(1) adds simulated events to the training, IR-2(2) adds automated training environments. This overlaps the AT family, and the overlap is where assessors find double-counting: training tracked once for AT-3 and re-cited verbatim for IR-2 without the IR-specific content actually existing.
  • IR-3, Incident Response Testing. Exercises. Tabletop at the low end, functional/live-fire at the high end (SP 800-84 is the testing methodology reference). IR-3(1) is automated testing; IR-3(2), the one people forget, requires coordinating IR testing with related plans, meaning the CP exercise and the IR exercise should not be two disconnected calendar events.
  • IR-4, Incident Handling. The lifecycle above. IR-4(1) requires automated support for the handling process (think a case-management or SOAR layer, not a shared mailbox). Recovery in IR-4 means returning the system to operation as part of handling, which hands off to CP for the actual continuity machinery.
  • IR-5, Incident Monitoring. Tracking and documenting incidents across their lifecycle. Not “buy a SIEM.” The point is that every incident has a record from declaration to closure, with status you can reconstruct months later when an assessor or an IG asks. IR-5(1) automates that tracking. The evidence feeding IR-5 comes from AU (the audit records) and the detection signal comes from SI-4 (system monitoring); IR-5 is the layer that turns those into a tracked case.
  • IR-6, Incident Reporting. The reporting clock, covered on its own below because it is where the findings actually live.
  • IR-7, Incident Response Assistance. Support resources, internal and external. The internal half is the help-desk/IR-team availability of advice and assistance to users handling an incident. IR-7(1) is automation support for that availability; IR-7(2) is the external piece, coordination with outside providers. An SSP that frames IR-7 as “obtain third-party assistance” has collapsed the control into its own enhancement and dropped the internal half.
  • IR-8, Incident Response Plan. The written plan, its distribution list, and its review-and-update cadence. The control nobody reads until 0200.
  • IR-9, Information Spillage Response. Response when information ends up somewhere it is not authorized to be (classified onto an unclassified system, CUI into the wrong enclave). IR-9(2) training, IR-9(3) post-spillage operations, IR-9(4) handling exposure of personnel who saw data they were not cleared for. IR-9 is its own animal and is allocated separately from the rest of the family.

Baselines and where these get pulled in

The baselines live in SP 800-53B, not in the catalog. FIPS 199 sets your categorization, FIPS 200 sets the floor, and 800-53B turns the impact level into a starting control set you then tailor. For national-security systems, CNSSI 1253 overlays it; FedRAMP and DoD (DoDI 8510.01) layer their own selections on top.

For IR, most of the family (IR-1, IR-2, IR-4, IR-5, IR-6, IR-7, IR-8) is allocated across Low/Moderate/High. IR-3 typically first appears at Moderate. IR-9 sits in no 800-53B baseline at all; it lands only through an overlay (CNSSI 1253, for one) or deliberate tailoring. Several enhancements (IR-4(1) and IR-3(2) among them) come in at Moderate and High, while IR-2(1) is a High-only addition. So a Low system can legitimately have a thin IR footprint and no formal exercise requirement; a High system that skips IR-3 functional testing has a gap it cannot tailor away with a hand-wave.

Control Typical first live at What an assessor actually checks
IR-1 Low Policy exists, is current, and uses Rev 5 titling. Procedures map to the actual org, not a template’s org chart.
IR-2 Low Responders trained on IR content specifically, with dates; not the same record reused from AT-3.
IR-3 Moderate An exercise actually happened. Ask for the after-action. “We test annually” with no artifact is a finding.
IR-4 Low Walk a real incident through the lifecycle. Containment and eradication evidence, not just a ticket that says “resolved.”
IR-5 Low Pull the incident log. Can you reconstruct status on a closed incident from declaration to closure?
IR-6 Low Reporting timelines documented AND met. Sample a major incident and check the clock against CISA.
IR-7 Low The contact roster is current. Call the number. (Figuratively. But check the date on it.)
IR-8 Low The plan exists, is distributed to the named list, and was reviewed within its stated cycle.
IR-9 Not in baselines (overlay/tailoring only) A spillage procedure exists and someone knows where it is before they need it.

Treat the “first live at” column as directional. Your overlay moves things, and FedRAMP pulls several IR enhancements above the bare 800-53B set.

IR-6 and the reporting clock that bites

This is the section that decides assessments. “Report to law enforcement and regulatory agencies” is not an IR-6 implementation; it is a placeholder. Federal incident reporting runs to CISA (the US-CERT function folded into CISA), and the clocks are short. Under FISMA and the OMB annual reporting guidance (the M-series memos), a confirmed major incident triggers reporting to CISA and notification to Congress on a compressed schedule, with the Congressional notification window measured in days (the 7-day figure is the one people quote, and it traces to the OMB guidance, not to 800-53 itself). Agency-internal reporting to your own SOC and ISSO is faster still, often measured in an hour or less per local policy.

The trap is that the clock starts at determination, not at convenience, and “major incident” has a definition you do not get to negotiate at 0200. If your IR-8 plan does not pre-define the major-incident threshold and the escalation path, the team burns the first hour arguing about whether this counts, and the reporting clock is already running while they argue. Write the threshold into the plan, name who makes the call, and rehearse it in the IR-3 exercise.

The enhancements matter here too. IR-6(1) is automated reporting (a real feed to CISA, not a human re-keying a form). IR-6(2) covers reporting vulnerabilities associated with the incident. IR-6(3), added focus in Rev 5, is supply-chain incident coordination, which ties straight into the SR family and is the one most programs have not operationalized at all.

Deeper: the plan-exists trap.
Here is the opinion, and I’ll mark it as one. Most IR programs pass IR-8 and fail IR-3 and IR-4 in practice, and the gap between those two outcomes is the whole ballgame. IR-8 is satisfiable with a document. A plan exists, it names roles, it’s distributed, it was reviewed in March. Tick. But IR-4 handling and IR-3 testing are about whether the team can run that plan under pressure, and that is muscle memory, not paperwork. The assessor who only reads the binder grades the family as Satisfied. The assessor who says “walk me through the last real incident, show me the after-action from the last functional exercise, and tell me who you called and when” finds the daylight. A program with a beautiful plan and no exercise cadence is a program that will discover at 0200 that the on-call roster in the plan has three people who left last year. The paper passes. The room does not. If you own this family, optimize for the room.

Where it goes brittle, and the cross-family ties

Contact-roster rot. IR-7 and IR-8 both depend on a current roster, and rosters decay faster than anything else in the family. This is where IR leans on PS (Personnel Security): PS-4/PS-5 offboarding and transfer should be the trigger that updates the IR roster, and when that link is informal, the roster goes stale between assessments. An assessor checking IR-7 will look at the date on the contact list before anything else.

The IR-5 / AU / SI-4 evidence chain. IR-5 tracking is only as good as its inputs. AU supplies the audit records that become incident evidence, and SI-4 supplies the monitoring signal that declares the incident in the first place. If audit retention is too short (an AU problem) or the SI-4 alerting is tuned so loosely that real incidents drown in noise, IR-5 inherits the failure. The first round of detection tuning is where this shows: a SOC that floods on false positives will under-declare, and under-declared incidents never make it into the IR-5 record at all.

IR-2 versus AT double-counting. Responder training overlaps general security-awareness training, and SSPs love to cite one record for both. Assessors pull the actual course content. If the “IR-2 training” is the same annual awareness module everyone takes, the IR-specific responder content does not exist, and the control is Other Than Satisfied no matter how current the completion dates look.

The fastest way to fail an IR assessment is the same as anywhere else in 800-53: an SSP that restates the catalog text back at the assessor instead of describing what this system actually does when something breaks. They have read 800-61. They want to know who gets paged, what the threshold is, and whether anyone has run it.

Sources

Adjacent material on this site