NIST SP 800-53 IR Incident Response: Key Controls, Enhancements and How to Evidence Them

Most incident response findings are not about a missing plan, they are about a plan whose parameters were never filled in, whose tests never happened and whose lessons never reached the procedures. This guide works through the Incident Response (IR) family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for. It is written for control owners, system security plan authors, incident response leads and assessors. For how to run the response itself, see the NIST SP 800-61 Incident Response Guide and the Incident Response Guide. This page stays at the level of the controls and their evidence.

Key takeaways

• IR-1, IR-2 and IR-4 to IR-8 apply at Low. Seven IR base controls sit in all three security baselines and in the privacy baseline. IR-3 testing joins at Moderate, and High adds simulated-event training, information correlation and an integrated response team.
• IR-4 is coordination as well as handling. Beyond preparation, detection and analysis, containment, eradication and recovery, IR-4 requires coordination with contingency planning, lessons learned fed back into procedures, training and testing, and consistent rigour across the organisation.
• IR-6 needs two parameters, not one. You must set how quickly personnel report suspected incidents internally and which authorities you report to externally. Many plans fill the second and leave the first blank.
• IR-8 defines what counts. The plan must define reportable incidents, provide metrics, address information sharing and be protected from unauthorised disclosure and modification. Undefined "reportable" is the most common IR-8 gap.
• Supply chain reporting is baseline at Moderate. IR-6(3) requires you to give incident information to the provider of the affected product or service and others in the supply chain. Keep supplier security contacts in the plan before you need them.

The IR family at a glance

The table lists every current IR base control with its baseline allocation, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High, P = Privacy). IR-10 is withdrawn and omitted.

The privacy baseline in SP 800-53B applies to systems irrespective of impact level, so a Low system processing PII still picks up IR-2(3) and IR-8(1). For selection and tailoring method, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

IR-1, IR-2 and IR-3: policy, training and testing

• IR-1 Policy and Procedures: an incident response policy at the level you select (organisation, mission or business process, or system) and procedures to implement it, a designated official to manage them, and review at a frequency and after events you define. Name the events: a major incident, a reorganisation, a new regulator or reporting rule.
• IR-2 Incident Response Training: role-based training within a time period you define of someone taking an IR role or gaining system access, when system changes require it, and at a frequency you define thereafter, with the training content itself reviewed on a schedule. At High, IR-2(1) incorporates simulated events and IR-2(2) provides an automated training environment. IR-2(3), in the privacy baseline, covers how to identify and respond to a breach, including the organisation's breach reporting process.
• IR-3 Incident Response Testing (M, H, P): test the effectiveness of the capability at a frequency you define, using tests you name. IR-3(2) at Moderate and High coordinates testing with the owners of related plans, which in practice means the contingency plan, continuity of operations plan and crisis communications plan.

IR-3 is about effectiveness, not attendance. A tabletop that produces no measured result and no change is weak evidence. Write the test types into the plan (tabletop, functional exercise, full-scale exercise) and record what each found. For exercise design, see the Cyber Incident Exercises Beyond Tabletop Guide and the Identity Attack Tabletop Exercise Scenarios.

IR-4: incident handling and its enhancements

IR-4 has four parts: (a) a handling capability consistent with the incident response plan covering preparation, detection and analysis, containment, eradication and recovery; (b) coordination with contingency planning; (c) lessons learned incorporated into procedures, training and testing, with the resulting changes implemented; (d) rigour, intensity, scope and results that are comparable and predictable across the organisation.

IR-4b and IR-4c are where evidence is thin. An assessor will ask to see a record that an incident triggered a contingency decision, and a post-incident review whose actions closed in a procedure or training change. Keep the link from review action to changed document. For non-human identities, IR-4 containment should name the steps for revoking and rotating API keys, tokens, service account credentials and certificates, and the owners who can do it. See the Identity Incident Response Playbook.

IR-5, IR-6 and IR-7: tracking, reporting and assistance

• IR-5 Incident Monitoring: track and document incidents. IR-5(1) at High tracks incidents and collects and analyses incident information using automated mechanisms. A ticket or case system with required fields (category, severity, affected systems and identities, timeline, decisions) is the minimum.
• IR-6 Incident Reporting: (a) require personnel to report suspected incidents to the incident response capability within a time period you define; (b) report incident information to authorities you define. IR-6(1) at Moderate and High reports using automated mechanisms, and IR-6(3) at Moderate and High provides incident information to the product or service provider and other organisations in the supply chain. IR-6(2), a tailoring candidate, reports vulnerabilities associated with reported incidents to roles you name.
• IR-7 Incident Response Assistance: a support resource, integral to the capability, that advises users on handling and reporting incidents. IR-7(1) at Moderate and High increases availability of that information and support with automated mechanisms, such as a self-service reporting form and knowledge base. IR-7(2), a tailoring candidate, establishes a direct relationship with external providers of system protection capability.

For federal systems, the IR-6b authority includes CISA. CISA's Federal Incident Notification Guidelines, effective 1 April 2017, require agencies to notify CISA within one hour of the incident being identified by the agency's top-level CSIRT, SOC or IT department, and list the information to supply, including functional impact, information affected, detection time, number of systems, records and users affected, and a point of contact. Outside government, IR-6b lists your regulators, sector bodies and contractual parties. See the Cyber Incident Reporting Requirements Map and the Breach Notification Laws by Country Guide.

IR-8 and IR-9: the plan and spillage

IR-8a lists ten things the plan must do. Use it as a table of contents.

IR-8b to IR-8e add distribution to named personnel, updates after system changes or problems found in execution or testing, communication of changes, and protection of the plan from unauthorised disclosure and modification. Keep an offline copy: a plan stored only in the environment under attack fails when that environment is unavailable. IR-8(1), in the privacy baseline, adds a breach process for PII: deciding whether notice is needed, assessing harm to individuals and identifying applicable privacy requirements. The Incident Response Plan Template and Incident Response Policy Template give a starting structure.

IR-9 Information Spillage Response is outside the baselines but worth tailoring in wherever sensitive data could land in the wrong system: assign responsibility, identify the information, alert through a channel not associated with the spill, isolate, eradicate, find other contaminated components and take further actions you define. A secret or credential pasted into a ticketing system, chat channel or public repository is a spill in this sense, and IR-9 steps map directly to finding every copy and rotating the credential.

How to evidence IR controls

SP 800-53A Rev. 5 assessment procedures use examine, interview and test. The table turns them into evidence an assessor can accept in one pass.

For assessment depth, see the NIST SP 800-53A Guide and the Incident Response Readiness Assessment Checklist.

Implementing the IR family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system with an informal response capability.

1. Write the parameters. Fill IR-1c, IR-2a, IR-3, IR-6a, IR-6b, IR-8a.9 and IR-8b in the system security plan. Every later test measures against them.
2. Define reportable incidents and severity. Agree categories and severity levels, including identity events such as a leaked secret, an abused service account or a compromised OAuth integration.
3. Stand up the record. One case system with required fields satisfies IR-5 and feeds IR-8a.6 metrics.
4. Build the contact list. Internal roles, external authorities for IR-6b, and supplier security contacts for IR-6(3). The Incident Response Contact and Call Tree Template helps.
5. Train by role. Responders, system owners, communications and legal staff, each with content matched to their IR-8 responsibilities.
6. Test and coordinate. Run a tabletop with the contingency plan owner present (IR-3(2)), record findings and assign actions.
7. Close the loop. After every significant incident and test, update procedures and training and record the change, which is your IR-4c evidence.

Introduce automated containment playbooks under IR-4(1) in a monitoring or approval-required mode first. Roll back an over-eager playbook by switching it to manual approval rather than deleting it, so the case history stays intact.

Decision guidance

• Low versus Moderate: Low already requires policy, training, handling, monitoring, reporting, assistance and a plan. Moderate adds testing, coordination with related plans, automation and supply chain reporting.
• Inherit or implement: a cloud or managed service provider can supply parts of IR-4 and IR-5 for its own layer, but IR-6 reporting decisions, IR-8 and the coordination in IR-4b stay with you. Record the split and the provider's notification commitments.
• Retainer or in-house: IR-4(11) and IR-4(12) are often met with a retainer. Check the retainer's activation time against the IR-4(11) time period. See the Incident Response Retainer Buyer's Guide.
• Small organisations: one plan, one case log, an annual tabletop and named external contacts meet the Low intent. Depth of IR-8 definitions matters more than tooling.

Detection and measurement

• Median time from detection to internal report, against the IR-6a period.
• Median time from declaration to containment by severity, reported under IR-8a.6.
• Share of post-incident and test actions closed within the agreed period.
• Share of IR role holders trained within the IR-2a period.
• Days since the plan was last approved, against the IR-8a.9 frequency.

Framework mapping

The SP 800-171 Rev. 3 column follows that publication's own Incident Response family. CSF and CIS mappings are "intersects with", not equivalence, and are our reading of the texts. Check them against NIST's published informative references before using them in an audit. See the CIS Control 17 Incident Response Management Guide.

Common failure patterns

• Parameters left blank: "incidents are reported promptly" in place of an IR-6a period, so nothing can be measured.
• Testing without learning: annual tabletops run, attendance recorded, no findings or actions tracked.
• Contingency planning in a separate silo: the IR and CP teams never test together, so IR-4b and IR-3(2) fail when ransomware forces a recovery decision.
• Identity steps missing from playbooks: containment covers hosts and accounts of people but not API keys, tokens and service accounts, which remain usable after the response ends.
• No supplier contacts: IR-6(3) cannot be met at speed because nobody knows who to call at the affected provider.
• Plan only online: the plan and contact list live on the file share that is encrypted during the incident.

Practitioner checklist

• Fill every IR organisation-defined parameter in the system security plan with a measurable value.
• Define reportable incidents and severity levels, including non-human identity compromise.
• Keep one incident register with required fields and use it for IR-8 metrics.
• List external reporting authorities and supplier security contacts with tested routes.
• Train each IR role within the set period and record completion.
• Test at least annually with the contingency plan owner and track every finding to closure.
• Store an offline, access-controlled copy of the plan and contact list.
• Tailor in IR-9 for spills of sensitive data and credentials into the wrong system.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Federal Incident Notification Guidelines
• NIST: SP 800-171 Rev. 3

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST SP 800-61 Incident Response Guide · NIST SP 800-53 AU Audit and Accountability · Incident Response Plan Template