Incident Monitoring IR-5

Incident Response · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds IR-5 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Incident Response family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

IR-5 (Incident Monitoring) is one of the Incident Response (IR) family of controls, and it is about tracking and documenting incidents from the moment they are spotted to the moment they are closed. Every incident gets a record: what happened, when it started, what was affected, and how it was resolved. Keeping that record is what stops things from falling through the cracks and lets you see patterns over time. It is a Low-baseline control.

What good looks like

Keep an incident record for each event: what happened, when it started, what was affected, and how it was resolved.
Pull the facts from more than one source so the record is complete — system logs, auth logs, and any alerts.
Track each incident through its full life: detected, being worked, resolved, and closed.
Store the records somewhere durable and searchable, not in someone's memory or a chat thread.
Review the records over time to spot repeats and recurring weak spots.

Framework mapping

NIST CSF 2.0 — DE.AE-03 — Information is correlated from multiple sources
CIS Controls v8 — Control 17 — Incident Response Management

How to move it toward Implemented

Make sure the server is logging enough to reconstruct an incident — check that journalctl is persistent (/var/log/journal exists) and that auditd is running (systemctl status auditd).
Start a dated incident register (a simple table or file): one row per incident with time, source, impact, and resolution.
When an incident occurs, gather the evidence from more than one place — for example journalctl --since the event window plus /var/log/auth.log — and save it with the record.
Attach the incident register (and a sample incident record) as hardening evidence on the asset, naming IR-5 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.