IR-4: Incident Handling

IR-4 requires you to run a working incident handling capability that matches your incident response plan and covers the full lifecycle: preparation, detection and analysis, containment, eradication, and recovery (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON). To operationalize it fast, assign ownership, define severity-based procedures, instrument detection and triage, and retain evidence that shows incidents were handled end-to-end.

Key takeaways:

• IR-4 is tested on execution, not policy language: you must prove incidents move through all lifecycle phases.
• Your biggest audit risk is missing artifacts that tie real tickets/timelines to your IR plan and playbooks.
• Start by mapping IR-4 to a control owner, procedures, and recurring evidence artifacts (NIST SP 800-53 Rev. 5 OSCAL JSON).

IR-4: incident handling requirement is one of the fastest ways an assessor can tell whether your incident response program is operational or aspirational. The control is simple on paper, but it fails in practice for predictable reasons: unclear decision rights, inconsistent severity triage, weak handoffs between SecOps and IT Ops, and incident records that don’t show containment and eradication happened (or who approved the risk when they didn’t).

IR-4 does not ask you to prevent incidents. It asks you to handle them in a controlled, repeatable way that is consistent with your incident response plan and explicitly covers preparation, detection and analysis, containment, eradication, and recovery (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON). For a Compliance Officer, CCO, or GRC lead, the job is to translate that into: (1) clear procedures and playbooks operators actually follow, (2) evidence you can produce quickly, and (3) governance that keeps the process working through organizational change, tool changes, and third-party involvement.

This page is requirement-level guidance you can implement without re-architecting your entire security program.

Regulatory text

Requirement (excerpt): “Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery” (NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5).

Operator interpretation: what you must do

• Maintain an incident handling capability (people, process, and tools) that matches what your IR plan says you do.
• Prove the capability covers all phases:
  1. Preparation
  2. Detection and analysis
  3. Containment
  4. Eradication
  5. Recovery
     (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON)
• Demonstrate execution with real incident records (or tightly controlled exercises if you truly have none), plus supporting artifacts that show actions taken, approvals, communications, and closure criteria.

Plain-English interpretation (what “good” looks like)

You pass IR-4 when an auditor can pick a recent incident and you can show, end-to-end:

• you were ready (on-call, tooling, access, playbooks),
• you detected and triaged the event into an incident,
• you contained impact quickly and intentionally,
• you removed the cause and foothold (or documented why full eradication wasn’t possible),
• you restored services/data, validated health, and closed with lessons learned.

You fail IR-4 when your “incident process” is really just ad hoc Slack threads, tool alerts without triage, or IT tickets that show recovery but not containment/eradication.

Who it applies to (entity and operational context)

IR-4 is written for federal information systems and contractor systems handling federal data (NIST SP 800-53 Rev. 5). Operationally, it applies wherever you have:

• production systems and endpoints,
• monitoring and alerting,
• privileged access and change control,
• a service desk / IT operations function,
• third parties that can trigger or participate in incidents (cloud providers, MSPs, SaaS, forensics firms).

Scope it to the boundary you assess. If you have multiple environments, make sure the incident handling capability is defined per environment or clearly centralized with documented coverage.

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

Use the steps below as an implementation checklist. The goal is to make incident handling repeatable and provable.

1) Assign ownership and decision rights

• Name an IR-4 control owner (often Head of Security Operations or IR Manager) and a GRC accountable owner to ensure evidence and reviews happen.
• Define a RACI for: incident commander, comms lead, forensics lead, IT ops lead, legal/privacy liaison, and executive approver for major incidents.
• Set escalation triggers based on severity (for example, “major incident” vs “standard incident”). Avoid tool-specific definitions; tie to business impact.

Practical tip: If you can’t name who can declare an incident, you don’t have an incident handling capability.

2) Align the IR plan to operational playbooks

IR-4 explicitly requires consistency with the incident response plan (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON). Do a quick alignment pass:

• Map each phase (prep/detect/contain/eradicate/recover) to:
  • a procedure,
  • an owner,
  • a system of record (ticketing/IR platform),
  • required timestamps and approvals.

Create a short library of playbooks tied to your top incident types (phishing, endpoint malware, privileged account compromise, cloud key exposure, data exfiltration suspicion, third-party outage with security impact). Keep them operational: “do X in tool Y, collect artifact Z.”

3) Build detection and analysis into a documented triage workflow

You need a consistent path from “signal” to “incident”:

• Define intake channels: SIEM alerts, EDR, user reports, third-party notifications, automated detections.
• Define triage steps: validate signal, gather context, scope affected assets/identities/data, assign severity, open incident record.
• Require a minimum incident record header: unique ID, timestamps, reporter/source, impacted assets, initial assessment, severity, incident commander.

Common hangup: Teams “investigate” in chats but don’t open an incident record until late. Fix it by opening a record at first triage and updating as you learn more.

4) Make containment explicit and time-bounded by procedure

Containment is a distinct phase in IR-4 (NIST SP 800-53 Rev. 5). Your procedures should specify typical containment actions and required approvals:

• isolate host/account, disable keys/tokens, block IOCs, segment network access, suspend integrations, restrict egress, take snapshots for forensics.
• define “containment achieved” criteria and who signs off.

Containment should be recorded as actions with timestamps in the incident record, not a narrative paragraph.

5) Define eradication actions and “residual risk” handling

Eradication proves you removed the cause/foothold:

• remove malware/persistence, patch exploited vuln, rotate credentials/keys, remove rogue accounts, fix misconfigurations, remove vulnerable package, rebuild hosts.
• If eradication cannot be fully confirmed (common in SaaS or limited telemetry cases), require:
  • documented rationale,
  • compensating controls,
  • management risk acceptance,
  • additional monitoring period defined by your team.

6) Recovery needs validation, not just restoration

Recovery is not “systems are back.” Require:

• restore from clean backups or known-good images,
• validate integrity and monitoring,
• re-enable integrations stepwise,
• confirm business service health,
• confirm containment/eradication preconditions are met before returning to normal operations.

7) Close the loop with post-incident actions

IR-4 doesn’t spell out lessons learned in the excerpt, but operationally you need closure discipline to prove the capability works:

• post-incident review notes,
• corrective actions with owners and due dates,
• detection rule tuning outcomes,
• updates to playbooks and the IR plan where gaps were found.

8) Operationalize evidence: map IR-4 to artifacts

Make IR-4 audit-ready by design. A simple approach is to map IR-4 to: owner, procedure, and recurring evidence artifacts (NIST SP 800-53 Rev. 5 OSCAL JSON). Daydream can help you maintain this mapping as a living control record so evidence collection is routine instead of a fire drill.

Required evidence and artifacts to retain

Keep evidence in a single “IR-4 evidence binder” (folder structure or GRC system). Minimum set:

• Incident response plan and version history showing it is current (NIST SP 800-53 Rev. 5).
• IR playbooks/runbooks mapped to the phases (prep/detect/contain/eradicate/recover).
• On-call roster and escalation matrix (current and historical snapshots).
• Incident records (tickets/cases) with:
  • timestamps for detection, declaration, containment start/complete, eradication actions, recovery validation, closure,
  • approvals (containment decisions, risky recovery decisions, risk acceptance),
  • communications log (internal/external where applicable),
  • forensic notes and collected artifacts inventory.
• Tooling evidence that supports detection and response (alert screenshots, EDR isolation logs, SIEM case notes), sampled and linked to incidents.
• Post-incident review outputs and remediation tracking (tickets in backlog with status).

Evidence standard: An assessor should be able to reconstruct what happened without interviewing three engineers.

Common exam/audit questions and hangups

Expect these and pre-answer them in your documentation:

• “Show me an incident from the last period and walk me through each IR-4 phase with evidence.”
• “How do you ensure the incident handling process is consistent with the IR plan?” (NIST SP 800-53 Rev. 5)
• “Who can declare an incident? Who can approve containment actions that impact production?”
• “How do third parties report incidents to you, and how do you coordinate containment/eradication when they control the environment?”
• “How do you know eradication occurred versus temporary containment?”
• “Where is the system of record? Are Slack/Teams messages preserved and linked to the incident record?”

Hangups that cause delays:

• incidents logged as “problems” or “service requests,” so containment/eradication is missing from the record.
• multiple tools (SIEM, ticketing, EDR) with no linking identifier.

Frequent implementation mistakes (and how to avoid them)

1. Policy without procedure. Fix: require phase-based checklists in playbooks, not just narrative.
2. No severity model that drives actions. Fix: map severity to mandatory steps, approvers, comms, and evidence fields.
3. Containment done but not recorded. Fix: create structured fields for containment actions/timestamps.
4. Eradication skipped or hand-waved. Fix: define eradication acceptance criteria and require risk acceptance when incomplete.
5. Recovery equals “service restored.” Fix: add recovery validation gates (monitoring enabled, credentials rotated, integrity checks).
6. Third-party incidents fall outside IR. Fix: add third-party coordination steps and contractual notification/assist requirements into playbooks.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, IR-4 gaps drive two types of risk:

• Operational risk: longer dwell time, repeated incidents, and incomplete remediation.
• Compliance risk: inability to demonstrate control operation. For many programs, the audit failure is “show me,” not “tell me.”

Practical 30/60/90-day execution plan

Use this as a sequenced rollout. Adjust to your environment size and incident volume.

First 30 days (stabilize and make it provable)

• Assign IR-4 control owner and approve RACI.
• Confirm the IR plan exists and is the authoritative reference for handling steps (NIST SP 800-53 Rev. 5).
• Standardize the incident record template (required fields, timestamps, linking).
• Publish minimum viable playbooks for top incident types.
• Create the IR-4 evidence binder and start collecting artifacts from current operations.

Days 31–60 (make it repeatable across teams and tools)

• Integrate triage workflow with SIEM/EDR and ticketing (consistent IDs, required fields).
• Train responders and IT ops on containment/eradication documentation expectations.
• Add third-party coordination procedures (intake, escalation, evidence requests, roles).
• Run a tabletop or simulated incident to validate each phase produces evidence aligned to the plan.

Days 61–90 (tighten controls and improve assurance)

• Implement QA reviews of incident records (completeness checks against phase requirements).
• Add post-incident remediation tracking with governance (owner, due date, closure).
• Review metrics qualitatively for bottlenecks (triage backlog, containment delays) and tune playbooks.
• In Daydream, maintain the mapping from IR-4 to owners, procedures, and recurring evidence artifacts so audits pull from an always-current control record (NIST SP 800-53 Rev. 5 OSCAL JSON).

Frequently Asked Questions

What counts as an “incident” for IR-4 purposes?

Use your incident response plan’s definition, then make the declaration step explicit in the workflow so you can show when an event became an incident (NIST SP 800-53 Rev. 5). Auditors care that you apply your definition consistently and document the decision.

Do we need evidence for every incident, including low severity?

Keep records for all declared incidents, but you can scale the depth of evidence by severity. Document the scaling rule in your procedures so the reduced evidence set is intentional and repeatable.

How do we show eradication if the affected system is owned by a cloud/SaaS third party?

Record what you can control (credential rotation, integration suspension, scoping) and retain the third party’s incident communications, attestations, or ticket updates. If eradication cannot be independently validated, document residual risk and compensating monitoring.

Our responders work in Slack/Teams. Is that acceptable?

Yes, if the system of record (ticket/IR case) captures decisions, timestamps, and actions. Link or export key chat artifacts into the incident record to avoid losing evidence.

How do we prove “consistent with the incident response plan” without rewriting everything?

Create a crosswalk that maps IR plan sections to playbooks, workflow steps, and evidence fields, then show that real incident records follow that structure (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON).

What’s the fastest way to get audit-ready on IR-4?

Standardize your incident record template, require phase-based timestamps/actions, and backfill a small sample of recent incidents with linked artifacts. Then map IR-4 to an owner, procedure, and recurring evidence artifacts so collection becomes routine (NIST SP 800-53 Rev. 5 OSCAL JSON).