IR-5: Incident Monitoring

Quick-reference card

What this control requires

IR-05 requires organizations to track and document every security incident from initial detection through final resolution. That means maintaining structured records about each incident’s status, severity, timeline, and handling decisions so the information remains available for forensics, trend analysis, and post-incident review.

Without a disciplined monitoring process, incident data fragments across ticketing systems, email threads, and individual analysts’ notes. The control exists because scattered records undermine two capabilities that mature security programs depend on: the ability to identify patterns across incidents and the ability to demonstrate due diligence to auditors. When incident records aren’t centralized and consistently maintained, organizations lose the forensic trail they’ll need during regulatory inquiries or litigation holds.

In practice, IR-05 pulls from multiple data streams. Network monitoring tools, user complaints, incident response team reports, audit logs, supply chain partner notifications, and physical access monitoring all feed the tracking process.

What the control requires of those records is consistency. The standard doesn’t prescribe a specific tool or format, but it does require that tracking and documentation happen systematically rather than on an ad hoc basis.

Why it matters

Most organizations don’t fail at incident monitoring because they ignore incidents entirely. They fail because their tracking is inconsistent, decentralized, or too shallow to reveal the patterns that matter. A single missed incident rarely triggers a compliance finding, but a pattern of undocumented incidents signals systemic weakness in the incident response program.

The result is measurable exposure during audits. Auditors evaluating IR-05 look for two things: evidence that incidents are tracked in a structured system and evidence that the documentation is detailed enough to support trend analysis and forensic review. Without both, organizations risk findings during FISMA assessments, FedRAMP authorization reviews, and any audit that maps to NIST SP 800-53. Those findings don’t just delay authorizations. They create remediation obligations that consume security team resources for months.

The compliance risk compounds in environments with third-party dependencies. When vendors experience incidents that affect your data or systems, the absence of monitoring records on your side creates a gap that auditors and regulators will flag. You can’t demonstrate appropriate oversight of your supply chain without documented evidence that you tracked vendor-related incidents alongside your own.

The consequences extend beyond audits. Governance teams that treat incident monitoring as a checkbox exercise miss the operational value entirely. Trending data from well-documented incidents reveals which controls are underperforming, which threat vectors are intensifying, and where response playbooks need revision. That feedback loop between monitoring and incident handling is what separates reactive programs from ones that genuinely improve over time.

What attackers exploit

• Gaps in logging coverage that allow intrusions to persist without generating trackable incident records
• Decentralized or informal tracking where incidents are recorded in personal notes or email rather than a centralized system, making pattern detection impossible
• Shallow documentation that captures “what happened” but not the forensic detail needed to understand lateral movement, persistence mechanisms, or data exfiltration paths
• Delayed incident recognition from supply chain partners who don’t report events promptly, leaving monitoring windows dark during the most critical phase

How to implement

The most common failure mode for IR-05 isn’t the absence of an incident tracking system. It’s the gap between what the system captures and what auditors, forensic investigators, and trending analysis actually need.

For your organization

Start by establishing a single, authoritative incident tracking system. Whether you use a dedicated security incident and event management (SIEM) platform, a ticketing system with incident-specific workflows, or a purpose-built incident management tool, the requirement is centralization. Every incident, regardless of severity, must flow into the same system.

Centralization is only useful if what goes into the system is consistent. Define a minimum data standard for each incident record that captures, at a minimum, the detection source, initial classification, severity rating, affected systems, timeline of key actions, status changes, assigned personnel, and resolution summary. This baseline ensures that records are detailed enough to satisfy both the “tracked” and “documented” assessment objectives from the control.

But even a well-defined data standard can’t protect against the gaps manual logging creates. Configure your monitoring infrastructure to feed the tracking system automatically where possible. Network monitoring alerts, intrusion detection system notifications, malware detection events, and physical access anomalies should generate incident records or pre-populated tickets without manual intervention. Automation reduces the risk that incidents slip through during high-volume periods.

Collecting records isn’t enough on its own. Build a periodic review cadence into your incident response plan, with monthly or quarterly reviews that examine incident types, response times, and resolution effectiveness.

Those review findings and corrective actions become direct evidence of IR-05 compliance. They also feed into the broader incident response plan improvement cycle.

All of this analysis becomes inaccessible without proper retention. Retain incident records according to your organization’s records retention policy, ensuring they remain accessible for the full retention period. Auditors may request records from prior assessment periods, and forensic investigations can require data going back years.

For your vendors

Evaluating vendor compliance with incident monitoring requires a combination of contractual provisions, evidence requests, and ongoing oversight.

Start by including incident monitoring requirements in vendor contracts and service-level agreements. Specify that the vendor must maintain a centralized incident tracking system, define minimum documentation standards, and provide incident reports within agreed timelines. Without contractual obligations, you have limited leverage to request evidence.

Contracts establish the obligation, but artifacts confirm it’s being met. During vendor assessments, request specific artifacts that demonstrate active incident monitoring. Ask for redacted samples of incident records, a description of their incident tracking system and workflow, and evidence of periodic incident trend analysis. A vendor that can produce these artifacts is far more likely to have a functioning IR-05 program than one that can only point to a policy document.

Specifically, your questionnaires should target process maturity rather than policy existence. Ask how many incidents the vendor tracked in the past quarter, what system they use for tracking, and whether they conduct trend analysis on incident data.

Evasive or vague answers are a red flag. A vendor that can name its tracking system and cite recent incident counts is far more credible than one that defers to policy language.

Where this often breaks down is in cross-referencing. Monitor vendor incident notifications against your own records. If a vendor reports an incident that affected your data, verify that your internal incident tracking system captured the event, documented your response actions, and recorded the vendor’s remediation timeline. Gaps between vendor-reported incidents and your own monitoring records indicate a breakdown in your third-party incident oversight process.

The risk doesn’t end at onboarding. Reassess vendor incident monitoring capabilities periodically. Incident monitoring maturity can degrade when vendors experience staff turnover, system migrations, or budget cuts. Annual reassessment ensures that the vendor’s program hasn’t regressed since the initial evaluation.

Evidence examples

Cross-framework mapping

Related controls

• AU-06 — Audit Record Review, Analysis, and Reporting: Audit record analysis feeds incident monitoring by identifying anomalies and suspicious activity patterns that warrant incident tracking.
• AU-07 — Audit Record Reduction and Report Generation: Provides summarized audit data that supports incident trend analysis and reduces noise in monitoring workflows.
• IR-04 — Incident Handling: Defines the response actions taken once an incident is detected and tracked; IR-05 monitoring provides the data foundation that IR-04 processes depend on.
• IR-06 — Incident Reporting: Governs how tracked incidents are reported to designated authorities and stakeholders, building on the documentation IR-05 requires.
• IR-08 — Incident Response Plan: Establishes the overarching plan within which incident monitoring operates, defining roles, responsibilities, and escalation paths.
• PE-06 — Monitoring Physical Access: Physical access monitoring events contribute to the incident data streams that IR-05 requires organizations to track.
• PM-05 — System Inventory: An accurate system inventory ensures that incident monitoring covers all organizational systems rather than leaving gaps in visibility.
• SC-05 — Denial-of-service Protection: Denial-of-service events are a category of incident that must be tracked under IR-05’s monitoring requirements.
• SC-07 — Boundary Protection: Boundary protection mechanisms generate alerts and logs that feed directly into incident detection and monitoring.
• SI-03 — Malicious Code Protection: Malware detection events are a primary input to the incident tracking process, requiring documentation under IR-05.

Frequently asked questions

What is NIST SP 800-53 IR-05

IR-05 requires organizations to track every security incident in a centralized system and maintain detailed documentation covering detection, status, response actions, and resolution. The control’s two assessment objectives, incident tracking and incident documentation, ensure that records are complete enough for forensic analysis, trend identification, and audit evidence. IR-05 applies across LOW, MODERATE, HIGH, and PRIVACY baselines, making it a universal requirement for federal systems and organizations adopting the NIST SP 800-53 framework.

What happens if IR-05 is not implemented

Failing to implement IR-05 means your organization lacks a verifiable record of how security incidents were detected, classified, and resolved. Auditors will issue findings when incident response records can’t demonstrate systematic tracking, and those findings can delay or block system authorizations under FISMA and FedRAMP. Beyond compliance consequences, the absence of incident documentation eliminates your ability to conduct meaningful trend analysis, which means recurring attack patterns go undetected and your incident response plan can’t improve based on historical data.

How do you audit IR-05

Auditing IR-05 focuses on verifying that the organization’s incident tracking system contains records for all reported incidents and that each record meets the documentation standard defined in the incident response policy. Auditors typically request exported incident response records from the tracking system, review them for completeness against the minimum data fields, and cross-reference entries with other data sources like audit logs and physical access monitoring records. They’ll also look for evidence of periodic trend analysis, confirming that documented incidents aren’t just stored but actively reviewed and used to improve the incident response plan.

What is the difference between incident monitoring and incident handling

Incident monitoring (IR-05) covers the tracking and documentation of incidents, while incident handling (IR-04) covers the actual response actions taken to contain, eradicate, and recover from an incident. Monitoring ensures that every incident has a structured record in the tracking system, including its detection source, status, and resolution. Incident handling defines how responders triage, investigate, and remediate the incident itself. The two controls are interdependent: IR-05’s incident documentation provides the data that IR-04’s handling processes act on, and the outcomes of handling actions feed back into IR-05’s records as status updates and resolution details.