IR-5 Incident monitoring: requirements and evidence

What IR-5 incident monitoring requires and why assessors check it

If an audit, customer contract or authorization requires NIST SP 800-53 and IR-5 Incident monitoring appears on the list, the short answer is this: IR-5 requires the organization to track and document incidents, keeping a record of each incident, its status and the other information needed for forensics and for evaluating incident details, trends and handling. The control is about the record itself. It is not about how the incident was contained (IR-4) or who was told about it (IR-6), although all three depend on the same case data. The risk is simple: if the record is incomplete, the organization cannot reconstruct what happened, cannot prove when containment began, and cannot answer trend questions after the next incident. SP 800-53B allocates IR-5 to the low, moderate and high baselines and to the privacy baseline, so it applies to nearly every system in scope. The high baseline adds the enhancement IR-5(1).

What makes IR-5 hard in practice is rarely the absence of a tool. Incident details are usually spread across a ticketing system, a chat channel, several mailboxes, a SIEM console and a shared drive, and no single place shows the status of each incident or the evidence attached to it. An assessor working from SP 800-53A will ask to examine the incident response policy, the procedures that address incident monitoring, the incident response records and the incident response plan, and will interview the people who maintain those records. The assessor will also test whether the monitoring capability and the mechanisms that track and document incidents actually work as described. Before any assessment, confirm which system is the authoritative incident record, who may change its status, and whether a closed incident can still be reopened and traced.

Open-source platforms can hold that record without changing how the organization responds. DFIR-IRIS keeps each case as one record with assets, indicators of compromise, tasks, evidence and a full audit trail, and it logs evidence with SHA-256 verification and chain of custody. Alert sources such as Wazuh or OpenSearch Security Analytics can open or feed cases, so the record starts with the detection rather than a manual copy. The organization still owns the decisions about what is recorded, retention periods and access rights, and an independent assessor, not the implementation partner, decides whether the evidence meets the control. Ask the assessor early which record fields and retention rules they expect, and confirm with your vendors which audit trail and export features each tool actually provides in your version.

Which systems, incident types and teams fall under IR-5

IR-5 applies to whatever the organization defines as its incident scope, so the work depends on a handful of scoping decisions made before any record is opened. Each card below is one decision that changes what the incident record must hold, who writes to it, and which baseline or enhancement applies.

Systems that feed the incident record

Start with the systems whose security events should become incident records: identity providers, endpoints, network boundary devices, cloud control planes and the business applications that hold regulated data. An incident record is only as complete as its inputs, so list each source, the owner who maintains it and whether it sends events automatically or by manual upload. Assessors will compare this list with the systems in your system security plan, so gaps between the two are worth closing before the assessment. Confirm that each in-scope system can be reached by your tracking tool, not only by the SOC that monitors it.

Incident categories that get logged

Decide which categories of event open an incident record and which stay as routine alerts. Common categories include malware, unauthorized access, data exposure, denial of service and insider misuse, but the organization must define the threshold for each. Write the categories into the incident response plan and the monitoring procedure so that analysts apply the same rule across shifts. Records for false positives still matter for trend analysis, so decide whether closed benign events are kept as a separate class and how long they are retained.

Teams that contribute records

IR-5 records are only useful when each contributing team writes to them in the same format. The security operations center usually opens and triages records, IT operations adds system changes and recovery actions, legal records notification and preservation decisions, and privacy staff record whether personal data was involved. Assign one owner for the record's status field and define which team may change it. Ask each team to state its handoff points in writing so that a record does not stall when work moves between groups.

Third-party and cloud detection sources

Many detection sources sit outside your direct control, including managed detection providers, cloud-hosted logging services and software-as-a-service audit feeds. For each one, record the contractual access you have to its alerts, the time it takes to deliver them and who on your side receives them. Where a provider holds the detection logic, IR-5 still expects your organization to track the incidents it produces. Confirm in writing how the provider's case identifiers map to yours so that the same event is not recorded twice or lost between systems.

Baseline and enhancement scope

IR-5 is allocated to the low, moderate and high baselines and to the privacy baseline. The high baseline adds the enhancement IR-5(1), which is a further automation requirement on incident monitoring, so high-impact systems need more than a manual record. The privacy baseline also carries IR-5, which means personal data incidents need records even where the system is otherwise lower impact. Confirm which baseline each system is categorized under before you build the record workflow, because the scope changes the tooling and the evidence you must keep.

How an assessor tests incident monitoring under SP 800-53A

An assessor testing IR-5 Incident monitoring under SP 800-53A works through three methods: examine, interview and test. The assessment procedure sets two determination statements, and the assessor's job is to gather enough evidence to decide whether the organization tracks and documents incidents in a way that supports forensics and trend analysis. Examination comes first. The assessor reads the incident response policy, the procedures that address incident monitoring, the incident response plan and a sample of incident response records. The question at this stage is whether the documents say who opens and maintains an incident record, which fields it must carry, how status changes are recorded and where the records are kept. Ask your own team to confirm which document owns each of those answers before the assessor arrives, because a gap between the policy and the practice is usually the first finding.

Interviews test whether the people named in the documents know their part. The assessor speaks with personnel who have incident monitoring responsibilities, such as the analyst who opens cases, the shift lead who reviews open items and the engineer who maintains the tracking tool. Each person should describe the same lifecycle the policy describes, from intake through closure, and explain what they record and where. Inconsistent answers are a common reason an examination is extended. Prepare these people by walking them through the procedure and the sample records, not by scripting their answers.

Testing is where the assessor checks the capability itself. The usual approach is to select a sample of incidents from a defined period, including closed ones and any that are still open, and trace each one through the tracking mechanism. The assessor checks that every sampled incident has a record with a status history, that the details needed for later analysis are present and that changes are attributable to a person and a time. A passing walkthrough shows a complete record for each sampled item, consistent statuses from first report to closure, and the ability to pull the same records into a trend view. Confirm with your assessor which period and sample size they intend to use, and rehearse the trace on a few incidents yourself so that a missing field is found by you first.

What assessors request for IR-5 and common findings

This table compares the four assessment approaches SP 800-53A uses for IR-5: records review, staff interviews, live testing of tracking mechanisms, and policy and plan review. Read each row as a question the assessor asks, the evidence they expect to see, and the gap that most often leads to a finding. Records that lack status history or timestamps are the most common reason an IR-5 test fails.

Test approach	Evidence requested	Common findings
Records review (examine)	Incident records for a sample period with ID, category, status, owner, open and close times, and linked evidence	Records exist but lack status history, close dates or links to related alerts and tickets
Interview with monitoring staff (interview)	Named staff describe how incidents are logged, who updates status and what details are kept for forensics	Staff describe informal logging in chat or email rather than the system of record
Live test of tracking mechanisms (test)	Assessor opens a test incident, changes its status and confirms the audit trail and timeline update	Status changes overwrite prior values, or edits leave no record of who changed them
Policy and plan review (examine)	Incident response policy, monitoring procedures and IR plan name the record fields, retention and review owner	Procedures do not define required fields, or the plan is not aligned with the tool actually used

How to implement incident monitoring in six steps

This sequence turns IR-5 from a policy statement into a working incident record system that captures each incident, its status and the details needed for forensics and trend analysis. Each step produces a artifact an assessor can examine, interview against and test.

Define the incident record schema
The incident response lead and the forensic or SOC lead agree on the fields every incident record must carry: a unique identifier, detection time, reporter, affected systems, classification, severity, status, assigned owner, indicators of compromise, actions taken, and links to related evidence and lessons learned. Include fields that support trend analysis, such as root cause category and detection source, so records can be compared over time. The output is a written schema approved by the organization, with a short note on which fields are mandatory at creation and which are completed later. Confirm the schema against the organization's own IR-4 and IR-6 requirements before moving on.
Choose the system of record
Select one authoritative location for incident records, such as a self-hosted case management platform like DFIR-IRIS, and decide how it is deployed inside the organization's own infrastructure. Configure the schema as case fields, enable the audit trail, and set up evidence logging with hash verification and chain of custody if forensic artifacts will be stored there. Confirm that changes to records are attributed to a user and time-stamped. The output is a configuration record listing the platform version, hosting location, enabled modules and the schema mapping, plus a test showing that an edited field retains its audit entry.
Define the status lifecycle and owners
Document the statuses an incident can move through, such as new, triaged, under investigation, contained, resolved and closed, and state the entry and exit criteria for each. Assign a named owner role for every transition, and define who may reopen a closed record and who approves closure. The workflow should align with the handling steps covered under IR-4 so that status changes reflect real progress. The output is a status workflow diagram or table, approved by incident response management, with the role responsible for each transition. Configure the platform to reject transitions that skip required fields.
Connect detection sources
Inventory every source that can open an incident record, including SIEM alerts, EDR detections, the Wazuh or OpenSearch Security Analytics alert outputs where deployed, vulnerability findings, help desk reports and manual submissions. For each source, document how alerts reach the case system, whether through a native integration or a REST-based intake, and what fields are mapped. Test that a sample alert from each source creates a record with the expected fields and that duplicate alerts are grouped or flagged. The output is a source list with the intake method, mapping, owner and last test date for each source.
Set retention and access controls for records
Define how long incident records and their attached evidence are kept, who may read, edit and delete them, and how that access is reviewed. Base the retention period on the organization's legal, regulatory and contractual obligations, which the organization must confirm with its counsel and compliance team. Restrict edit rights to the incident response team, grant read access to defined oversight roles, and log all access to records containing personal or sensitive data. Coordinate with the AU family for audit log retention so that records and their supporting logs are preserved together. The output is a written retention rule, an access matrix, and a configuration export showing that the rules are enforced in the platform.
Run a sample test and document the results
Run a controlled exercise that pushes a set of sample incidents, including a simple event, a multi-stage event and a duplicate, through every source and every status. Check that each record matches the schema, that the owner and timestamps are correct at every transition, that the audit trail is complete, and that trend reports can be produced from the data. Keep the test plan, the sample inputs, the screenshots or exports showing results, and a list of any defects with their fixes. Assessors examining IR-5 typically ask for this evidence alongside the policy and the incident response plan, so store it with the control documentation. The output is a signed test record that shows the monitoring capability works as designed.

Evidence that passes an IR-5 assessment

IR-5 is tested by looking at records: what the organization logged about each incident, how the status changed, and whether the monitoring behind those records is documented. The six artifacts below are the ones an assessor can trace from a sample incident back to its source, so keep each one exportable and dated between assessments.

Incident register export with status history

The register is the master list of every tracked incident, with an identifier, category, severity, dates opened and closed, owner and current status. Assessors usually pick a sample from the register and then check the source records against it, so a register without a history of changes proves little. Export the full register on a fixed schedule, keep the exports unaltered, and confirm that closed incidents still appear with their final status. Check that no incident can be deleted without a trace.

Case records with audit trail

Each case record should hold the assets involved, indicators of compromise, tasks, notes and attached evidence, together with an audit trail showing who changed what and when. DFIR-IRIS is one open-source option that keeps each case as a single record with a full audit trail. Confirm that the audit trail itself is protected from routine edits and that responders cannot quietly remove their own entries. Assessors often ask how an entry was created and whether the timestamps can be trusted.

Incident timeline and forensic detail

The timeline consolidates detection events, analyst actions and containment steps into one ordered sequence for each incident. It supports the forensic and trend analysis that IR-5 names as the purpose of the records. Evidence items should carry hash values and chain of custody entries, so an assessor can confirm the record matches what was collected. Ask your platform owner to confirm which timeline and evidence features are included in the version you deploy.

Status change logs

Status change logs show each transition an incident made, such as new, under analysis, contained and closed, along with the person responsible and the reason. Assessors compare these logs against the handling steps described in your procedures to see whether the recorded status matches what happened. Gaps, backdated entries or closures without a stated reason are the findings most often raised. Review a sample of transitions each quarter and record the outcome of that review.

Trend review reports

IR-5 expects the records to support evaluation of incident details and trends. Trend reports group incidents by category, source, affected system and time period, and they show whether recurring causes are being addressed. Keep dated versions of each report, the questions it answered and the actions it triggered. An assessor who sees a report that led to no decision will ask why the monitoring was collected at all.

Monitoring configuration and rule inventory

The monitoring configuration explains where incident data comes from: which log sources feed the platform, which detection rules are active, and how alerts become cases. Wazuh, for example, compares collected events against a ruleset of built-in and custom rules and writes matching alerts for review, while OpenSearch Security Analytics runs detectors built on Sigma rules. Version-control the configuration, record every rule change and review the source list whenever a system is added or retired.

What meeting IR-5 costs in money and effort

This table compares the cost components of meeting IR-5 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. Read it as a checklist for building a quote, since no dollar figure or duration is stated here. The main takeaway is that open-source tooling removes license spend, but configuration, evidence upkeep and assessor sampling still carry most of the effort.

Cost component	One-time or recurring	What drives it and what to ask for in a quote
Tooling and licenses	Recurring where commercial	Commercial case managers or SIEM add-ons are priced by vendor terms. DFIR-IRIS (LGPL-3.0-or-later), OpenSearch Security Analytics (Apache-2.0) and Wazuh (GPL-2.0-only) carry no license fee, so ask for a quote that separates any paid support from the software itself.
Engineering time to configure records and sources	One-time, with later changes	Effort rises with the number of log sources, case types and integrations with SIEM, EDR and REST feeds. Ask the implementer to list each source, the record fields agreed for incidents, and the status workflow before pricing.
Hosting and infrastructure in the client's environment	Recurring	Storage and compute scale with log volume and retention. Ask who pays for cloud or data center capacity, and whether the quote includes sizing for the indexer and case database.
Evidence upkeep	Recurring	Records must stay complete, with the audit trail, status history and evidence chain of custody intact. Ask who reviews incident records on a schedule and who maintains the evidence register.
Rule and detection tuning	Recurring	Rule sets from Sigma or Wazuh need review as the environment changes, which affects alert volume and the quality of incident records. Ask how many rules are reviewed per cycle and who signs off changes.
External testing or review	Periodic	A tabletop or independent review of the monitoring capability is optional but common before an assessment. Ask for scope, deliverables and whether the test is separate from the implementation work.
Auditor or assessor sampling	Per assessment	Assessors examine records, interview monitoring staff and test the tracking mechanism, so effort depends on how many incidents and records they sample. Only an independent assessor issues findings, so budget for their fees separately from implementation.

Who owns IR-5 work and who only tests it

Your organization owns IR-5. The incident monitoring requirement is about keeping records of each incident, its status and the details needed for forensics and for judging trends and handling quality, and those records are your operational and governance responsibility. Your team decides what counts as an incident, who opens and closes records, and who approves that a record is complete. An assessor will ask your staff, not a vendor, how monitoring works day to day.

Status definitions: Write the lifecycle states an incident can take (for example, new, triaged, contained, closed) and who may move a record between them.
Record ownership: Name the role accountable for the incident record system and for keeping its content accurate.
Sign-off: Document who approves closure and the minimum fields that must be complete first.
Retention and access: Decide how long records are kept and who can read or change them.
Operating routine: Set a recurring review of open records and trends, with the reviewer named.

Before an assessment, confirm that these decisions exist in writing and that staff can explain them without reading from a script.

Where IR-5 usually fails and how to close each gap

IR-5 is tested on whether the organization keeps reliable, complete records of each incident and can use them later. The gaps below are the ones assessors most often find when they examine incident records and interview the people who maintain them. Each card names the failure and the action that closes it.

Incidents tracked in chat or email

Many teams open incidents in a message thread and never create a record. The facts then live in people's inboxes and chat scrollback, so an assessor asking for the incident records finds nothing consistent to examine. Close this by requiring a single case record for every incident, created at the moment someone declares it, with chat and email linked into that record rather than serving as the record. Check by picking three recent incidents at random and confirming each one has a record that predates the first response message.

No status history

A case that only shows its current state cannot prove how it was handled. Overwriting a status field from open to closed erases the time spent in containment and the decisions made along the way. Configure the case tool to keep every status change with a timestamp and the person who made it, and review a sample of closed cases to confirm the transitions are visible. This history is what lets an assessor reconstruct the sequence of handling.

Missing forensic fields

Records that hold a title and a severity rarely give investigators what they need later. Fields for affected assets, indicators of compromise, timestamps of first detection, actions taken, and evidence custody are often left blank or absent. Define a minimum field set for every case type, make the key fields required before closure, and confirm that evidence entries record hashes and handlers. Without these fields, forensic reconstruction and trend analysis both fail.

Records editable without audit trail

If anyone with access can change a closed incident's timeline or severity without leaving a trace, the record loses its value as evidence. Restrict edit rights on closed cases, log every modification with the editor and the old and new values, and protect the audit log itself from ordinary users. Test this by making a change to a closed case in a non-production copy and confirming the change appears in the trail.

No link between alerts and cases

Detection tools generate alerts that never reach the case record, or they create cases that cannot be traced back to the triggering alerts. Either gap breaks the chain from detection to handling that an assessor follows. Connect the alerting pipeline to the case system so each alert that becomes an incident carries its identifier, and each case lists its source alerts. Sample a detection rule that fired last month and trace it to its case, or confirm why none was opened.

No trend review

IR-5 expects records to support evaluation of incident details and trends, yet many organizations store cases without ever reviewing them in aggregate. Recurring root causes and slow handling steps stay hidden. Schedule a recurring review of case data by category, severity and time to containment, record the findings, and feed them into the incident response plan and detection rules. Ask for the most recent review record and what changed as a result.

IR-5 questions buyers ask before hiring help

How much effort does IR-5 incident monitoring take?

The effort depends mainly on how many systems feed incident records and how much of the recording already happens in tools you run. IR-5 asks for a record of each incident, its status and the details needed for forensics and trend analysis, so the one-time work is designing the record format, the status workflow and the fields, and the recurring work is keeping records complete as incidents arrive. Teams with a case management tool that already tracks assets, indicators, tasks and evidence usually need less configuration than teams that track incidents in email or spreadsheets. Ask any partner to estimate effort from a written list of systems in scope, the existing ticketing or case tools, and the incident volume you expect, and to state which parts are one-time and which recur.

Can an in-house team implement IR-5 without outside help?

Often yes, if the team already owns incident handling and has someone who can maintain the records. IR-5 is one of the more contained IR controls because it concerns the tracking record rather than the full response process, so an internal team can define the fields, set up a case tool and write the procedure. Outside help tends to add value in three places: mapping the record fields to what forensics and trend analysis actually need, checking that the records are evidence-ready if an incident goes to legal action, and preparing the documents an assessor will request. Your organization owns the control in every case. An implementation partner prepares systems and evidence, and only an independent assessor can judge whether the control is met.

What does the work need from our team?

The work needs named owners for the incident record, access to the systems that generate alerts and tickets, and someone who can approve the procedure. In practice this means:

A policy owner who approves what counts as an incident and which statuses an incident moves through.
Administrators for the alert sources and case tooling, so records can be created and linked to logs.
Responders who will use the record during real cases, since a record nobody updates fails the control.
A reviewer who samples records each cycle to check completeness.

Ask the partner to list these roles in the written scope so the commitments are visible before work starts.

How long does IR-5 implementation take?

The timeline depends on scope and existing tooling, and no fixed duration applies to every organization. A team that already runs a case management platform with defined statuses can move quickly, while an organization that must select a tool, integrate alert sources and agree on fields will need more time. Scope drives the schedule more than the control itself: the number of systems that feed incidents, the number of teams that open cases and any integration with ticketing or SIEM platforms all add work. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for milestones tied to named deliverables rather than a general estimate.

What does an assessor sample when testing IR-5?

An assessor typically examines the incident response policy, the procedures that address incident monitoring, the incident response records and the incident response plan, then interviews the people who maintain the records. For testing, the assessor checks whether the monitoring capability actually tracks and documents incidents and whether the mechanisms that support this work. In practice, expect requests for a sample of incident records showing identifiers, status history, timestamps, assigned owners and the forensic details collected, plus evidence that the records feed trend review. Prepare these before the assessment by running a few realistic exercises through the workflow and keeping the output. Confirm the exact sample size and method with your assessor, since NIST does not set it.

Does NIST publish prices for SP 800-53 compliance?

No. NIST does not estimate compliance or certification costs, and it does not offer or endorse any compliance program or tool. Its risk management guidance leaves timelines for federal implementation to OMB Circular A-130. Cost estimates for IR-5 therefore come from your own environment and from the partners and assessors you engage, not from NIST. When you request quotes, ask each provider to break the price into one-time design and setup, recurring record review and evidence preparation, and the independent assessment, which an outside party performs and charges for separately.

Which open-source tools can keep IR-5 records?

Open-source tools can hold the incident record and the alerts that open it, but you must confirm each tool meets your record requirements. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, indicators, tasks and evidence with an audit trail, and it can triage alerts from SIEM and EDR sources into cases. Wazuh (GPL-2.0-only) writes matching alerts to alerts.log and alerts.json and maps them to MITRE ATT&CK, which can feed a case record. OpenSearch (Apache-2.0) Security Analytics records matches as findings with rule, log type and severity. Confirm with each vendor how the tool stores status history and whether it meets your retention and access needs before relying on it as the system of record.

How DeployOpen scopes and prepares IR-5 evidence

DeployOpen starts with a written scope that names the systems whose incidents must be recorded, the people who open and close records, and the fields each record carries. The organization owns IR-5 and decides what counts as an incident for its environment, how status values are defined, and how long records are kept. DeployOpen then plans the self-hosted stack around those decisions, typically a case management platform such as DFIR-IRIS alongside the detection sources that feed it, and sets out in the quote which systems are integrated, which log sources are onboarded and which reports are produced. The scope should also state who is responsible for the monitoring and tracking capability, because an assessor will interview those people directly.

DeployOpen implements the components inside the client's own cloud accounts, data centers or air-gapped network, then prepares the evidence an assessor will examine: the incident response policy and procedures that govern monitoring, sample incident records with their status history and audit trail, the incident response plan references, and documented tests showing that detections create cases that can be traced end to end. Where a detection source such as Wazuh or OpenSearch Security Analytics is in scope, the team confirms that the configured rules and alert outputs are retained and reviewable. Teams should confirm with their assessor which record samples and retention periods are expected for their system impact level, since SP 800-53B sets the baseline and the assessor sets the test.

Audit conclusions stay with independent assessors. DeployOpen does not determine whether IR-5 is satisfied, does not issue assessment reports or authorizations, and does not state a compliance outcome. The organization or its assessor decides whether the evidence meets the control. Security testing, such as exercising detection content against simulated activity, and cyber range exercises that rehearse incident tracking are optional additions that can be scoped separately if the organization wants to test the monitoring capability before an assessment. The practical next step is a short scoping call followed by a written proposal that lists systems, deliverables and the assessor's evidence requests.

IR-5 Incident monitoring