IR-6 Incident reporting: requirements and evidence

IR-6 incident reporting: what the requirement asks and why timing decides outcomes

IR-6 requires two things: personnel must report suspected incidents to the organization's incident response capability within a time period the organization defines, and incident information must be reported to the external authorities the organization names. NIST does not set either the deadline or the recipient list. When an assessor or contract asks for IR-6 evidence, the compliance lead's first task is to produce the organization's own answers to those two questions, written down and approved, and then show that people actually followed them. Timing decides outcomes because a late report can turn a contained event into a larger one, and a missed notification to a regulator or customer can create a separate finding even when the technical response went well.

Three problems make this control harder than its one-sentence summary suggests. The first is the definition of a suspected incident. If staff cannot tell whether an odd login, a vendor alert or a misdirected file counts, they wait for confirmation and the clock starts late. The second is ownership. Reports need a named intake point, with a named backup, and someone accountable for deciding which external authorities receive information. The third is records. Reports that live only in email or chat cannot show when a report was made, who received it, or what happened next. Assessors look for a timestamped record that links the first report to the case that followed.

Start by confirming the reporting period and the external recipient list with your incident response owner and with each contract, regulator or customer that sets its own notice terms. Then run one illustrative test: pick a suspected event, trace it from the first report to the intake record and to any external notice, and note every gap in time or ownership. Self-hosted case management tools such as DFIR-IRIS can hold that trail in one case record with an audit trail, which gives assessors something concrete to examine. Your independent assessor will decide whether the evidence is sufficient, and the implementation work to make the records reliable is a scoped activity you can agree with an implementation partner in writing.

Which systems, people and baselines IR-6 covers

IR-6 applies to the low, moderate and high baselines and to the privacy baseline, with two enhancements added at moderate and high. The scope an assessor tests is set by the systems you classify, the people you require to report, and the external authorities your contracts and regulations name, so each decision below should be written down before testing begins.

Baseline selection by impact level

IR-6 is allocated to the low, moderate and high baselines in SP 800-53B, so every system in the boundary inherits the control at whichever baseline its impact level selects. The moderate and high baselines add IR-6(1) and IR-6(3), which means a system categorized at moderate or high needs the enhancements in its plan and its assessment, not only the base control. Confirm the categorization in the system security plan before you scope the reporting procedures.

Personnel who must report

The control requires personnel to report suspected incidents within an organization-defined time period, so the reporting population must be named, not implied. Employees, contractors, administrators and staff at managed service providers all touch systems and may see the first signs of an incident. Write down who is in the population, how they reach the incident response capability, and how the time period is stated, because assessors interview these people to confirm they know the rule.

Cloud and third-party managed components

Components run by a cloud provider, a hosting partner or a managed security service still sit inside the system boundary when your organization owns the data or the incident. Reporting paths must cover those components, including how a provider's alert reaches your internal capability and how quickly it must be escalated. Check the provider contract for notification duties, then confirm that the reporting procedure names the provider as a source and the internal contact who receives its notices.

Privacy baseline systems

The privacy baseline applies regardless of impact level, so systems that process personally identifiable information carry IR-6 even when their security categorization is low. A privacy incident can trigger reporting duties to regulators and affected individuals that run on their own clocks, separate from the security reporting path. Identify which systems hold personal data, then confirm the reporting procedure routes privacy-relevant incidents to the people who manage those obligations.

External authorities named by obligations

IR-6 requires incident information to be reported to authorities the organization defines, so the recipient list is your decision, shaped by contracts, sector regulators and data protection law. Build the list from each obligation: the agency, the sector authority, the customer, and any information-sharing body you have joined. Ask legal and compliance to confirm each entry and its required content, since the control does not name the recipients for you.

Scope tied to contracts and regulations

Because the organization defines both the recipients and the time periods, scope follows its contracts, regulations and agency requirements rather than a fixed list in the standard. Keep a single register that maps each system and each reporting obligation to the time period it imposes, then review it when contracts renew or a new system joins the boundary. An assessor will compare that register with your procedures and your incident records, so gaps between them show up quickly.

Which external authorities receive incident information

IR-6 requires that incident information reach the authorities the organization itself defines, so the work starts with a written recipient register rather than with a reporting tool. The register should list every external party that may need incident information and, for each one, the source that obliges or permits the disclosure: a customer or partner contract, a sector regulator or supervisor, a government agency, a law enforcement contact, an information sharing body, or an internal legal or insurance requirement. Legal and contract owners should review each entry, because a missing source is the most common gap an assessor finds. Confirm the exact wording of each obligation with counsel and the contract owner, since this page does not state which authorities apply to any particular sector or jurisdiction.

The register should be owned by a named role, reviewed on a set schedule and updated whenever a contract, regulation, system boundary or service provider changes. Each entry should record the recipient's contact route, the information it expects, the person authorized to send it and the version of the register in force on the date of an event. Changes to the register should be traceable to a decision, so an assessor can see why a recipient was added or removed. Because the register is an input to the incident response plan, its current version should be referenced from the plan rather than copied into it, which avoids two documents drifting apart. Confirm with the plan owner how IR-8 governs approval and distribution of that reference.

The register only works if the handling process calls it. Under IR-4, the triage step should classify each incident against the notification triggers written beside each recipient, such as a category of data affected, a service impact threshold or a system in scope of a contract. The case record should then show, for each triggered recipient, the decision made, the time it was made, who approved it and the time the notification was sent or the reason it was not required. Test this path during exercises so that the reporting decision is observed, not assumed. Ask your legal team to confirm any time limit tied to a trigger before it is written into the process, because this page does not supply reporting deadlines.

How an assessor tests IR-6 and what they ask to see

This table sets out the two SP 800-53A Rev. 5 determination statements for IR-6 and the examine, interview and test methods attached to each, with the common gaps assessors record. Read each row as a question the assessor will ask, the evidence they expect to see and the place where weak programs usually fail.

Assessment object	What the assessor examines, interviews or tests	Evidence that passes	Common findings
Incident response policy	Examine whether the policy addresses incident reporting, including who must report, to whom and within what period	Approved policy with a reporting section naming the internal capability, the reporting window and the external authorities	Policy silent on reporting, or the reporting period is left undefined
Procedures for incident reporting	Examine the procedures that turn the policy into steps for staff, managers and responders	Procedures with reporting channels, contact points, required fields and escalation steps, dated and version controlled	Procedures exist only as tribal knowledge or point to a channel that no longer exists
Incident reporting records	Examine logs of reported incidents, including timestamps, reporter, recipient and any external notifications	Ticket or case entries showing when the report was made, when it reached the response team and when authorities were informed	No record of who was told and when, or reports held in personal inboxes
Incident response plan	Examine whether the plan defines reporting roles, internal and external reporting paths and timing	Plan with a reporting section matching the policy, contact lists kept current and approved	Plan contacts are outdated or the plan omits external authorities the organization has defined
Interview: staff with reporting responsibilities	Interview personnel assigned to receive, triage or forward incident reports about their duties and timelines	Consistent answers on who receives reports, how quickly they act and how they pass information on	Responders describe different timelines or cannot say which external authority they notify
Interview: staff who have or should have reported	Interview users and administrators about reports they made and how they would report a suspected incident	Staff name the reporting channel, the time expectation and what to include without looking it up	Staff who could not name the reporting channel or who waited to confirm an incident before reporting
Test: reporting processes and mechanisms	Test that reporting paths work, such as submitting a test report through each channel and tracing it to the response team	Test results with timestamps showing delivery, receipt and acknowledgment through each channel	Reporting channel fails outside business hours or a mailbox is unmonitored

How to implement IR-6 incident reporting in six steps

This sequence turns IR-6 into working reporting practice: a shared definition of suspected incidents, a documented reporting time period, a named internal capability, a list of external authorities, a stamped reporting channel and a tested path, each step leaving an artifact an assessor can examine.

Define what counts as a suspected incident
The organization owns this step. Security, IT, privacy and business leads agree a written definition of a suspected incident, with examples of what staff should report, such as unexplained account lockouts, lost devices, suspected phishing and unexpected system behavior. The output is a definitions note approved by the incident response owner and distributed to personnel who use or administer the system. It is done when every role that could observe an event can point to the definition and the examples.
Set and document the reporting time period
IR-6 requires personnel to report within an organization-defined time period, so the organization must choose that period itself and record why. Risk owners, the incident response lead and, where relevant, contract or regulatory obligations inform the decision. The output is a time-period decision record stating the period, the events it applies to, the approver and the review date. Confirm any period a contract, regulator or customer imposes before setting yours, since NIST does not set one for you.
Name the internal incident response capability and intake channels
Identify the internal incident response capability that receives reports and name the people or team accountable for it. Then configure the intake channels personnel will use, such as a monitored mailbox, a service desk queue, a hotline or a case management form, with a backup route if the primary is unavailable. The output is a channel configuration record listing each channel, its owner, its hours of monitoring and its escalation path. It is done when a test message through each channel reaches a named responder.
Write the list of external authorities and their triggers
Work with legal, privacy and compliance leads to list each external authority that may need incident information, such as regulators, law enforcement, sector computer emergency response teams, customers or contracting agencies. For each, record the trigger condition, the information required, the person authorized to send it and the contact route. The output is an external authority register approved by legal counsel. Assessors check that the list reflects the organization's actual obligations, so keep it current when contracts or regulations change.
Deploy a reporting mechanism that stamps and records each report
Deploy the intake channels on a system that assigns each report a unique identifier, records the time received, the reporter, the description and the initial triage decision, and keeps the record unchanged after entry. Open-source case management tools such as DFIR-IRIS can hold these reports as cases with an audit trail and link them to later investigation records, though the organization must confirm the exact features against its own requirements. The output is a working reporting configuration with sample records and an audit log that shows who viewed or changed each report.
Train staff and test the path with a sample report
Train personnel on the definition, the time period, the channels and the external authority process, and record attendance. Then run a sample report from a non-technical user through each channel, confirm the timestamp, triage and escalation, and send a test notification along the external authority route using a dummy case. The output is a test report documenting each step, the elapsed time measured against the defined period, the gaps found and the corrective actions assigned. Repeat the test after significant changes to channels, staffing or the reporting tool.

Evidence that passes an IR-6 assessment

An assessor testing IR-6 wants proof on two fronts: that personnel know how and when to report suspected incidents, and that every report and external notification is traceable from the first signal to the authority that received it. The cards below list the artifacts that connect those two fronts, with the checks to run before the assessment starts.

Reporting procedure with defined time period

The organization must set the time period within which personnel report suspected incidents, and the procedure is where that period is written down. Assessors compare the stated period against what staff describe in interviews, so the procedure should name who reports, to which channel, and by when. Check that the time period is an organization-defined value you can defend, not a placeholder, and that the procedure version matches the one staff were trained on.

Register of external authorities and triggers

IR-6 requires incident information to go to the authorities the organization defines, so assessors look for a written list of those authorities. Each entry should name the authority, the contract, regulation or agreement that creates the obligation, and the trigger that starts the notification. Confirm the list with legal and contract owners, because an incomplete list is one of the most common gaps found in reviews.

Intake channel configuration and access records

Reports must reach the incident response capability through a channel that is configured, monitored and restricted to authorized staff. Keep exports of the channel settings, such as mailbox rules, ticket queue permissions or form routing, plus the access list and recent change records. Ask the tool owner which events are logged for the channel and how long those logs are kept before you rely on them as evidence.

Timestamped incident reporting records

Each report should record when the person observed the activity, when the report was submitted and when it reached the incident response capability. The gap between those times is what an assessor uses to test the stated time period. DFIR-IRIS keeps each case as a single record with a full audit trail, can triage alerts from SIEM, EDR and REST sources into cases, and can generate reports from case data, which helps assemble these records. Confirm how your own tool records timestamps and time zones before relying on them.

Notifications to external authorities with copies

For every notification sent to an external authority, keep a copy of the message, the recipient, the sending time and the name of the person who approved it. Assessors check that notifications match the triggers in the authority register and that the content reflects the incident record. Store these copies in the case record or a linked repository so that the incident and its external reporting can be reviewed together.

Training and awareness records for the channel

Staff who must report incidents need to know that the channel exists and how to use it. Keep attendance records, awareness campaign materials and results from any test reports, such as a simulated phishing report sent to the channel. Interviews with personnel who have or should have reported an incident are a standard assessment method, so these records help show that the people you name in interviews received the training.

What meeting IR-6 costs in money and effort

This table compares the main cost components of meeting IR-6, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and how self-hosted open-source case management changes the picture. No prices or durations are given because none are supplied; figures depend on the written scope and your own environment, so request a quote built from that scope.

Cost component	One-time or recurring	What drives it, and how to keep it down
Internal policy and procedure work	One-time to draft, recurring to review	Drives: number of reporting paths, systems in scope and how many teams own reporting. Keep down: write one reporting procedure with a single intake point and reuse it across business units.
Legal or contract review of the external authority list	One-time, then recurring when rules change	Drives: number of regulators, sector obligations and customer contracts that name notification windows. Keep down: maintain one reviewed matrix of authorities and triggers, and assign a named owner to update it.
Intake tooling and licenses	Commercial: recurring license fees. Self-hosted open source: no license fee, but recurring hosting and operations	Drives: user count, alert sources and whether intake is integrated with SIEM or EDR. Self-hosted case management such as DFIR-IRIS removes license spend, but you still pay for infrastructure, patching and integration work. Confirm license terms and supported integrations with the project before committing.
Engineering time to configure channels and timestamps	One-time build, recurring maintenance	Drives: number of reporting channels (email, web form, phone, alert forwarding), time zone handling and how many sources must stamp detection and report times. Keep down: standardize on fewer channels and record each timestamp field from the start so auditors can trace it.
Staff training on reporting duties	Recurring, usually tied to role changes and periodic refreshers	Drives: headcount, turnover and the number of non-security staff expected to report suspicions. Keep down: short role-specific modules, with completion records kept as evidence.
Evidence upkeep and reporting drills	Recurring	Drives: how often reports are logged, how many drills run each year and how much manual reconciliation is needed. Keep down: generate case records from the tool with consistent fields, and run drills that test both internal reporting and external notification.
External review or assessment support	Periodic, tied to the assessment cycle	Drives: scope size, evidence quality and whether the assessor needs interviews with reporting personnel. An independent assessor issues the findings. Ask any implementation partner to prepare evidence, and confirm in writing that it does not issue assessment results.

Who owns IR-6, what a partner prepares and what the auditor tests

The organization owns IR-6 in full. Its leadership must define the time period within which personnel report suspected incidents, decide which external authorities receive incident information, and assign the incident response capability that receives internal reports. No outside party can make these decisions on its behalf, because they depend on the organization's contracts, regulatory duties and risk appetite.

Reporting time period: Set and approve the organization-defined period for internal reporting, and record the rationale in the incident response policy.
Authority list: Maintain the list of external authorities that receive incident information, including any sector regulator, contract counterpart or law enforcement contact, and review it when obligations change.
Incident response capability: Staff the internal team that receives reports, and document who triages them and who can declare an incident.
Staff training: Train personnel on what counts as a suspected incident, how to report it and the deadline that applies to them.
Owned records: Keep the reporting records and their review over time, since assessors will ask the organization, not a vendor, to produce them.

Confirm internally that the defined time period and authority list match the approved policy and the contracts that require them.

Where IR-6 programs usually fall short and how to close each gap

IR-6 asks for two things: that personnel report suspected incidents within a defined time period, and that incident information reaches the authorities the organization names. Most shortfalls come from those two requirements being written down but not operated, or from the reporting path sitting disconnected from the plan, monitoring records and tests that assessors look at alongside it.

No defined reporting time period

IR-6 requires personnel to report suspected incidents within an organization-defined time period, so an unstated window cannot be tested. Many programs say reports should be made "promptly" and stop there. The fix is to set a specific period per incident category, approve it, and write it into the incident response policy and the incident response plan. Check that the period matches the notification duties in your contracts and regulations. The artifact is the approved reporting standard showing the period and its owner.

Staff unsure of the reporting channel

An assessor interviewing personnel who have or should have reported incidents will ask how they would do it. If answers vary, the reporting path is not working even if a document exists. Publish one primary channel, a backup channel for when the primary is the affected system, and a single contact for after-hours reports. Include the channel in onboarding and in role-based training. The artifact is the interview record and training content showing staff can name the channel without looking it up.

Reports land in an untimed mailbox

A shared mailbox cannot show when a report arrived, who saw it first, or whether anyone acted. Without timestamps, the organization cannot show it met its defined period. Route reports into a ticketing or case system that records submission time, acknowledgment time and assignee. Set the time period as an alert threshold so overdue reports escalate. The artifact is the case or ticket export showing submission and acknowledgment timestamps for sampled reports.

External authority list never reviewed

IR-6 requires reporting to the authorities the organization defines, and those lists change with contracts, regulators and sector rules. A list written at a past audit and never revisited is a common finding. Assign an owner, record each authority with the trigger, the contact route and the information required, and review the list on a set schedule and after contract or regulatory changes. The artifact is the dated authority register with its review record and approvals.

Reporting not linked to IR-8 and IR-5

Reporting is one step in the incident lifecycle. If the reporting path is not written into the incident response plan (IR-8), assessors see two documents that disagree. If incident monitoring records (IR-5) do not carry the report time, reporter and reporting decisions, the organization cannot reconstruct what happened. Cross-reference the reporting steps in the plan and make every report create or update an IR-5 record. The artifact is a traceability view linking each sampled report to its plan section and monitoring record.

Reporting path never tested

The reporting path can fail quietly: contact details go stale, a mailbox is unmonitored, or the after-hours route is unknown. Testing it is the only way to find these faults before an incident. Include reporting in tabletop exercises and in announced or unannounced checks of the channels, and record how long each report took against the defined period. The artifact is the test plan and after-action report showing which reporting steps were exercised and what was corrected.

IR-6 questions buyers ask before hiring outside help

How much does meeting IR-6 cost and what drives the price?

No supplied fact gives a price for IR-6, and DeployOpen does not publish a price list, so a quote follows from a written scope. The cost has three parts: staff time inside your organization for policy, reporting contacts and records, the fees for any outside help that prepares reporting procedures, tooling and evidence, and the independent assessment, which an assessor performs and charges for separately. Costs rise with the number of systems in scope, the number of reporting authorities you must notify, how many teams have reporting duties, and whether reporting tooling must be built or only configured. Ask any provider to separate one-time setup from recurring retainer or support work, and to state what the quote excludes.

How long does IR-6 work take to complete?

The timeline depends on how much reporting structure already exists, not on a period NIST sets. The main variables are how many systems and teams fall under the reporting duty, whether a reporting time period has already been defined, how many external authorities your sector requires you to notify, and how long it takes legal and management to approve the defined period and the contact lists. Work that needs a new case management tool or integration with existing alerting systems takes longer than configuring a reporting process on tools you already run. Request a schedule in the written scope with milestones for each deliverable and for client review.

Does NIST set the time period for personnel to report incidents?

No. IR-6 requires personnel to report suspected incidents within a time period that the organization defines, and NIST leaves that number to you. NIST's risk management FAQ also states that it does not set implementation timelines for federal systems, which it leaves to OMB Circular A-130. Your period should come from your own risk tolerance, sector rules, contracts and the authorities you must notify, and it must be written into your incident response policy and procedures. An assessor will check that the period exists, that it is documented, and that personnel know it. Any consultant who tells you a fixed number is required is describing a rule that your contracts or regulator set, not the control.

What must our organization supply before outside help can start?

Your organization owns the control, so several inputs must come from your staff before the work can proceed. Policy owners need to confirm the reporting period, the internal reporting channels and who receives reports. Legal and contract staff need to list the external authorities and customers that require incident information, along with any notification duties in your contracts. Engineering and security operations need to grant access to the systems that generate alerts, the ticketing or case tools, and the logs used to test reporting. Expect to name a single decision-maker who approves scope changes. Your written scope should list these inputs, their owners and the dates by which they are due.

Can our internal team implement IR-6 without a partner?

Yes, an internal team can implement IR-6 if it has the time and skills to define the reporting period, document the reporting paths, configure the tools that accept reports, and produce records an assessor can inspect. The work that most often stalls internal teams is testing: showing that real personnel report suspected incidents through the defined channel and that the reports reach the response capability. Outside help is usually considered when the team lacks people to build and maintain the tooling, when systems span several platforms, or when an assessment is approaching and evidence is incomplete. Whichever route you choose, the organization still owns the control and the decisions behind it.

What parts of IR-6 will an auditor not do for us?

An independent assessor examines, interviews and tests your controls, but does not design or build them, and does not issue findings on controls that were never implemented. The assessor will not write your incident reporting period, choose your reporting authorities, configure your alerting or case management tools, or keep your reporting records current. Those are your responsibilities, and a partner can prepare them, but only an independent assessor or certification body can issue an assessment result or certificate. Ask any provider to confirm in writing which deliverables are preparation and which are assessor work, so no one assumes the other party covers a gap.

What records will an assessor ask to see for IR-6?

Assessors look for the incident response policy and procedures that address reporting, the reporting records themselves, the incident response plan, and evidence that staff know how to report. They also interview people who have reporting responsibilities and people who have or should have reported incidents, and they test the reporting process and the mechanisms that support it. Prepare a dated log of reports with timestamps, a list of authorities and the reports sent to each, training or awareness records, and a test record showing a report moving from a user to the response capability. Your partner can prepare these records, but the assessor decides whether they are sufficient.

How DeployOpen prepares IR-6 systems and evidence

DeployOpen works on IR-6 Incident reporting as an implementation partner: we prepare the reporting paths, records and test evidence inside your own infrastructure. Your organization owns the control and the reporting decisions, and only an independent assessor issues the assessment result.

How we scope

Engagements are fixed-scope, with the IR-6 reporting paths and systems agreed in writing before work starts.
We confirm the organization-defined reporting time period and the list of external authorities with your control owner.
The written scope names which systems, teams and reporting records fall inside the IR-6 evidence package.

How we build

We configure the internal reporting channel so personnel can report suspected incidents to the incident response capability.
We set up incident records that capture report time, reporter, and forwarding to authorities for later review.
We test the reporting mechanisms end to end and document the results for the assessor's examine and test methods.

How we hand over

You receive documented reporting procedures, configuration records and the test results mapped to the IR-6 assessment objects.
We walk your incident response and compliance staff through where each reporting record lives and how to retrieve it.
Handover includes a list of items only you can confirm, such as legal reporting obligations and contact details for authorities.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover periodic re-testing of reporting paths when systems, staff or authority contacts change.
Any assessment, attestation or certification decision remains with the independent assessor or certification body.