IR-4: Incident Handling

IR-4 requires you to run an incident handling capability that matches your incident response plan and consistently executes the full lifecycle: preparation, detection and analysis, containment, eradication, and recovery ¹. To operationalize it fast, define an end-to-end workflow, assign decision rights, and retain evidence that proves each phase ran for real incidents and exercises.

Key takeaways:

• IR-4 is an operational capability requirement, not a policy-only requirement ¹.
• Your evidence must show the lifecycle steps happened and were consistent with the IR plan ¹.
• Ownership, triggers, and a minimum evidence bundle prevent audit failures tied to “we do this, but can’t prove it.”

IR-4: Incident Handling is where incident response stops being a document and becomes a repeatable operating model. The requirement is narrow but demanding: you need a working capability for handling incidents that is consistent with your incident response plan and covers the standard lifecycle phases: preparation; detection and analysis; containment; eradication; and recovery ¹. Auditors and assessors will look for more than a plan and a ticketing tool. They want to see that your team can intake a signal, declare an incident using defined criteria, coordinate technical and business actions, and close the loop with recovery and documented outcomes.

For a CCO, GRC lead, or security compliance owner, the fastest path is to treat IR-4 like a production control with: (1) a control card (owner, triggers, steps, exceptions), (2) an evidence bundle per incident, and (3) recurring health checks that prove the capability stays functional under real conditions. This page gives requirement-level guidance you can hand to an incident response owner and then audit internally for completeness.

Regulatory text

Requirement (IR-4): “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;” ¹

What the operator must do:

• Build and run an incident handling workflow that maps directly to your incident response plan ¹.
• Demonstrate that each incident, from initial detection through recovery, follows defined steps, roles, and decision points across the five phases ¹.
• Produce evidence that the capability works in practice (tickets, timelines, approvals, comms, and post-incident outputs), not only that it exists on paper.

Plain-English interpretation

IR-4 means you need a functioning “assembly line” for incidents. Signals come in (alerts, reports, third-party notifications). Your team triages and decides whether it’s an incident. If it is, you contain impact, remove the cause, restore services/data, and document what happened.

“Consistent with the incident response plan” is the test that gets teams in trouble. If the plan says Legal must approve external notifications, you need proof Legal was engaged when applicable. If the plan defines severity tiers and response timelines, your tickets need those fields and show they were used. If the plan requires forensics capture before rebuilding a host, your worknotes should show the capture happened or document a justified exception.

Who it applies to

Entity scope

• Federal information systems and contractors operating systems that handle federal data commonly map to NIST SP 800-53 controls, including IR-4 ².

Operational scope

• Security operations (SOC), incident response (IR), IT operations, cloud/platform engineering.
• Legal, privacy, HR, communications, and business owners who approve actions and messaging.
• Third parties who provide monitoring, hosting, managed security services, incident response retainers, or critical software components. Your IR-4 capability must account for third-party dependencies because they affect detection, containment, and recovery execution.

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

1) Create an IR-4 control card (one page)

Build a “requirement control card” that an auditor and an on-call responder can both use. Minimum fields:

• Objective: Execute end-to-end incident handling aligned to the IR plan and lifecycle phases ¹.
• Owner: Named IR owner (role) plus an alternate.
• Trigger events: SIEM/EDR alerts, user reports, third-party notifications, CSP/security advisories, data loss alerts, fraud anomalies.
• Inputs: Alert payloads, affected asset inventory, logs, identity events, change records.
• Execution steps: The workflow below (phases 2–6).
• Exceptions: What qualifies as an exception, who can approve, and how you record rationale.
• Evidence bundle: Point to the artifact list in this page (and your repository location).

This is also where Daydream fits naturally: store the control card, map it to your IR plan, and standardize evidence bundle checklists per incident so you can answer audits without rebuilding context from scattered tickets.

2) Preparation: make the workflow runnable

Preparation is not “training exists.” It is operational readiness:

• Stand up your incident intake channels (ticket queue, hotline, on-call paging, email alias).
• Define severity criteria and who can declare an incident.
• Ensure access to tools and authority: EDR isolation rights, firewall rule change path, cloud IAM break-glass, comms templates, forensics storage.
• Pre-stage stakeholder rosters: Legal, privacy, HR, comms, business owners, third-party contacts.

Deliverable: an “IR readiness checklist” that your team can execute without guessing.

3) Detection & analysis: make triage consistent

Detection and analysis must produce a defensible conclusion and a case file:

• Triage: Confirm signal quality, identify impacted assets/users/data, and determine if it meets your incident definition.
• Classify: Set severity, category (malware, BEC, data exposure, availability), and scope.
• Preserve: Capture logs and volatile evidence where feasible, per your plan.
• Decision log: Record who made the incident declaration and why.

Practical tip: require a short “analysis summary” field in every incident record. If your assessor can’t see the rationale quickly, they assume it doesn’t exist.

4) Containment: stop spread without breaking evidence

Containment actions must be controlled and recorded:

• Choose short-term containment (isolate host, disable accounts, block indicators, segment network).
• Decide system vs. business trade-offs (shutdown vs. keep running under monitoring).
• Track approvals for high-impact actions (production shutdowns, customer-facing changes), aligned to your IR plan.

Containment is also where third parties matter: if a cloud provider, SaaS, or MSP must act, your evidence must show the handoff, timestamps, and outcomes.

5) Eradication: remove root cause, not just symptoms

Eradication closes the hole:

• Remove malware/artifacts, patch vulnerable components, rotate secrets/keys, reset credentials, remove persistence mechanisms.
• Validate controls are restored (EDR healthy, logging re-enabled, vulnerable service disabled).
• Document root cause (even if “likely” with confidence level) and what you changed to prevent recurrence.

6) Recovery: restore service and verify integrity

Recovery is successful only when service is restored and trusted:

• Restore from known-good backups or rebuild systems from clean images.
• Verify integrity and monitoring coverage (logging, alerts, access controls).
• Re-enable normal operations with a recovery validation checklist (tests passed, owners sign off).

7) Closeout: post-incident outputs and control health

IR-4 doesn’t explicitly say “post-incident review,” but you need closure artifacts to prove the capability functions:

• Complete a post-incident report (timeline, actions, impact, lessons learned, follow-ups).
• Create remediation tickets with owners and due dates; track to validated closure.
• Run recurring “control health checks” (tabletop exercises, on-call drill, evidence sampling) and record results so you can show sustained operation.

Required evidence and artifacts to retain

Keep an evidence bundle per incident (and per exercise). Minimum set:

• Incident record/ticket with unique ID, dates/times, severity, category, affected assets, incident commander.
• Timeline of actions across phases (detection/analysis/containment/eradication/recovery) ¹.
• Decision/approval artifacts: chat exports, email approvals, change tickets, bridge notes.
• Forensic and logging references: what was collected, where stored, chain-of-custody if applicable.
• Containment/eradication/recovery worknotes: commands run, configurations changed, patches applied, credentials rotated.
• Communications: internal stakeholder notifications; third-party communications; customer/regulator communications if applicable (retain drafts and approvals when required by your plan).
• Post-incident report and remediation tracking to closure.
• Exception records where you deviated from the plan, with approver and rationale.

Retention period is program-specific; set it in your IR plan and data retention schedule, then follow it consistently.

Common exam/audit questions and hangups

Auditors tend to probe for operability and consistency with the plan:

• “Show me the last incident end-to-end. Where is preparation reflected, not just response?”
• “How do you declare an incident? Who has authority? Show the decision record.”
• “Where do you document containment actions and approvals?”
• “How do you prove eradication happened and wasn’t just a reboot?”
• “How do you validate recovery and return-to-service?”
• “How do third parties participate, and how do you track their actions?”
• “Show evidence your process matches what your IR plan says you do” ¹.

Hangup to expect: teams have good technical notes but no structured timeline mapped to the lifecycle phases. Fix this with required fields and an evidence checklist in the incident template.

Frequent implementation mistakes and how to avoid them

1. Policy-plan mismatch with operations
   Avoid by aligning ticket templates and runbooks to the IR plan sections (roles, severities, approvals).

2. No single owner for IR-4 operation
   Avoid by naming an IR-4 control owner and backup, and making them accountable for evidence quality.

3. Containment actions happen “in chat” and never make it into the record
   Avoid by requiring a running timeline and attaching chat exports or bridge notes.

4. Eradication and recovery blur together
   Avoid by explicitly recording “cause removed” steps separately from “service restored” steps, with validation checks for each.

5. Third-party handoffs are undocumented
   Avoid by requiring a third-party interaction log: who was contacted, when, what they did, and confirmation.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list specific cases. Practically, IR-4 failures create predictable business risk: extended outages, uncontrolled data exposure, incomplete root-cause removal, and audit findings tied to inability to demonstrate that the incident response plan is executed consistently ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize the minimum viable capability)

• Assign IR-4 owner and alternate; publish on-call and escalation paths.
• Build the IR-4 control card and map each lifecycle phase to your IR plan sections ¹.
• Standardize an incident ticket template with mandatory fields: severity, incident declaration, timeline, approvals, phase checkboxes, post-incident report link.
• Define the minimum evidence bundle and where it is stored (single system of record).

Days 31–60 (make it repeatable and auditable)

• Write phase-specific runbooks (detection/analysis, containment, eradication, recovery) with decision points and approvers.
• Test third-party contact paths (MSSP, cloud/SaaS, IR retainer) and document the handoff process.
• Run a tabletop exercise and produce a complete evidence bundle as if it were a real incident.
• Create remediation tracking and validation steps for closure.

Days 61–90 (prove sustained operation)

• Perform an internal evidence review on a sample of incidents/exercises and document gaps.
• Tune logging and tooling coverage so investigation and recovery validation can be evidenced.
• Establish recurring control health checks (evidence sampling, drill outcomes, remediation aging review).
• Put IR-4 into your GRC monitoring workflow (Daydream can track required artifacts per incident and flag missing evidence before audit season).

Frequently Asked Questions

Do we need to show evidence for every phase on every incident?

You need evidence that your incident handling capability includes all phases and that each incident follows the IR plan ¹. For small events, the evidence can be lightweight, but it should still document detection/analysis, action taken, and closure rationale.

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

Use your incident definition from the incident response plan and apply it consistently ¹. Your evidence should show the declaration decision and severity classification, including when you decide an event is not an incident.

How do we handle third-party incidents (SaaS breach, MSP compromise) under IR-4?

Treat third-party notifications as detection inputs, open an internal incident record, and document your containment/eradication/recovery actions within your scope. Retain third-party communications and confirmations as part of the evidence bundle.

We have a SOC tool and tickets. Why do auditors still write findings?

Findings usually come from inconsistency: the plan says one thing, tickets show another, or key decisions and approvals exist only in chat. Fix it with a required timeline, mapped phases, and a minimum evidence checklist embedded in the ticket workflow.

Can we outsource incident handling and still meet IR-4?

Yes, but you still own the capability and the proof. Your contracts and operating procedures should ensure the third party provides the artifacts you need (timestamps, actions taken, evidence collected), and your internal team documents oversight and approvals.

What is the fastest way to make IR-4 “audit-ready” without slowing response?

Standardize the incident template and evidence bundle so responders capture proof as they work, not after. A GRC workflow in Daydream can predefine required artifacts per severity and flag missing items before you close the incident.

Footnotes

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

2. NIST SP 800-53 Rev. 5