IR-5 Incident Monitoring

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High, Privacy	Organization	1 (1 in a baseline)

Related controls: AU-6, AU-7, IR-4, IR-6, IR-8, PE-6, PM-5, SC-5, SC-7, SI-3, SI-4, SI-7

Control statement

Track and document incidents.

NIST discussion

Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. IR-4 provides information on the types of incidents that are appropriate for monitoring.

Control enhancements

IR-5(1) Automated Tracking, Data Collection, and Analysis

Baselines: High

Track incidents and collect and analyze incident information using [Assignment: organization-defined automated mechanisms].

Discussion and assessment objectives for IR-5(1)

Automated mechanisms for tracking incidents and collecting and analyzing incident information include Computer Incident Response Centers or other electronic databases of incidents and network monitoring devices.

Determine if:

• IR-05(01)[01] incidents are tracked using [Assignment: organization-defined automated mechanisms];
• IR-05(01)[02] incident information is collected using [Assignment: organization-defined automated mechanisms];
• IR-05(01)[03] incident information is analyzed using [Assignment: organization-defined automated mechanisms].

Examine: Incident response policy; procedures addressing incident monitoring; incident response records and documentation; system security plan; incident response plan; other relevant documents or records.

Interview: Organizational personnel with incident monitoring responsibilities; organizational personnel with information security responsibilities.

Test: Incident monitoring capability for the organization; automated mechanisms supporting and/or implementing the tracking and documenting of system security incidents.

Assessment objectives (SP 800-53A)

Objectives and methods for IR-5

Determine if:

• IR-05[01] incidents are tracked;
• IR-05[02] incidents are documented.

Examine: Incident response policy; procedures addressing incident monitoring; incident response records and documentation; incident response plan; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with incident monitoring responsibilities; organizational personnel with information security and privacy responsibilities.

Test: Incident monitoring capability for the organization; mechanisms supporting and/or implementing the tracking and documenting of system security incidents.

Policy statement

• The Incident response team shall track and document incidents. (IR-5)

IR-5(1) Automated tracking, data collection and analysis

• The Incident response team shall track incidents and collect and analyze incident information using Fill in: automated mechanisms Typical: the incident case management system integrated with the security operations platform. (IR-5(1))

From the Incident Response Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

IR-5 asks you to track and document every incident. NIST’s IR-5 discussion says that means keeping records about each incident, its status, and the other information needed for forensics and for evaluating incident details, trends and handling. Incidents come from many sources: network monitoring, incident reports, user complaints, supply chain partners, audit and physical access monitoring, and user and administrator reports. IR-5 is in the Low, Moderate, High and Privacy baselines.

NIST SP 800-61 Rev. 3 (April 2025; current as of October 2026) recommends, in its Incident Management (RS.MA) rows, tracking each incident’s status with an incident summary, the indicators of compromise, the status and expected time frame of each assigned action, and next steps. Its Incident Analysis (RS.AN) rows add that actions taken during an investigation are recorded, and that incident records are protected so only authorized personnel can see them, since they hold data on exploited weaknesses and on people.

Common implementations. One incident record per incident, opened when the incident response team declares it, as section 6 of the Incident Response Plan describes. The record lives in a case management system or ticketing queue that only the team and named staff can read, separate from the general service desk queue. Typical fields:

• Identifier, title, type and severity, and the systems and data affected
• How it was reported or detected, by whom, and when it was discovered, reported and declared
• A time-stamped log of actions, decisions and who made them
• Evidence collected and where it is kept
• Notifications made under IR-6, to whom and when
• Root cause, closure date and lessons-learned actions (IR-4c)

The incident report form is the first report that opens a record: it holds the reporter, what happened, the information involved, the triage, the notifications and the closure, and its register lists every report with when it was discovered, received and declared. The incident handling playbook names the record each step leaves. Trend reports from the records (incidents by type, severity and time to contain) feed the plan’s metrics (IR-8a.6) and the risk assessment.

Organization-defined parameters. IR-5 has none. In the policy, the incident response team tracks and documents incidents. The High enhancement IR-5(1) adds a parameter for its automated mechanisms.

Evidence assessors ask for.

• The incident tracking system or log, and a list of incidents for the assessment period
• A sample of incident records, drawn by the assessor, showing status, actions, notifications and closure
• The access list for the tracking system
• A trend report or metrics produced from the records

Inheritance. Incident tracking is usually a common control, provided by the incident response team or security operations center for every system. The system owner makes sure incidents found by the system’s own staff or tools reach the team and are recorded, not handled informally. Record the split in the system security plan.

Common findings.

• Incidents handled through email threads or chat, with no record to show the assessor.
• Records with no time stamps, so nobody can tell whether reporting deadlines were met.
• Records closed with no root cause or lessons learned.
• Incident records in the general service desk queue, readable by everyone who works it.

Enhancements in the Moderate baseline. None. High adds IR-5(1) automated tracking, data collection and analysis.

Federal systems (as of October 2026). The CISA Federal Incident Notification Guidelines (effective April 1, 2017) list the information agencies must give CISA: functional impact, information impact, recoverability, when the activity was first detected, the number of systems, records and users affected, the network location, and a point of contact. Build those fields into the incident record so the one-hour report on the IR-6 page can be filed from it; the incident report form’s federal block lists them.

Artifacts

• Incident Handling Playbook
• Incident Report Form
• Incident Response Decision Worksheet
• Incident Response Plan
• Incident Response Policy