03.06.02 Incident monitoring and reporting: NIST SP 800-171

What 03.06.02 requires for incident monitoring and reporting

03.06.02 requires you to track and document system security incidents, report suspected incidents to your incident response capability within a defined time, report incident information to defined authorities, and give system users a support resource that advises and assists them with incidents. If you are the compliance lead or engineer preparing for an assessment, the assessor will want to see four things working together: a dated record for each incident, a reporting clock that people actually follow, a named list of who receives incident information, and a documented contact point that users can reach. The requirement addresses three failure modes: incidents that go unrecorded, incidents reported too late or to no one, and users who do not know whom to call. The source controls NIST used for this requirement are IR-5, IR-6 and IR-7 from SP 800-53 Rev. 5, which cover incident monitoring, incident reporting and incident response assistance. You do not need to read those controls to meet 03.06.02, but they explain why the requirement is split this way.

The hard part is usually the two organization-defined parameters (ODPs). NIST does not set them for you. The first is the time period within which a suspected incident must be reported to the organizational incident response capability, and the second is the list of authorities to whom incident information is reported. Until you write both values down, the requirement is not complete, and SP 800-171A Rev. 3 includes separate checks that these values are defined. Confirm the reporting window and recipient list with your contracting officer, your prime contractor or your sector regulator before you set them, because a value that is shorter or broader than a contract requires will fail the review even if your process works. Also confirm which Revision applies to your contract, since the Rev. 2 requirement this maps to is handled differently under CMMC.

Start with the record. Decide which system your incident tracker is, whether that is a ticketing tool, a case management platform or a log of sign-off entries, and make sure every suspected incident gets an entry with timestamps, affected systems and the actions taken. Then test the reporting path: pick a sample incident, trace it from detection to the recipient list and check that the timing matches the value you wrote down. Finally, confirm that the user support resource exists, has a published contact route and has a record of requests. Evidence for each of these points is what an assessor will ask to see, so keep it dated and retrievable. Note that 03.06.02 sits between detection and recovery work covered by 03.06.01, and its reporting path depends on the response plan described in 03.06.05.

Which systems, teams and third parties 03.06.02 reaches

Scoping 03.06.02 starts with one question: which parts of the environment process, store or transmit CUI, and so fall under the incident monitoring and reporting capability. The cards below cover the decisions that most change the effort, from system boundaries and monitoring roles to the user support resource and third-party services.

CUI system boundary sets monitoring scope

The incident monitoring and tracking duties apply to systems that handle CUI, so the boundary decision determines how many log sources, endpoints and cloud accounts must feed the capability. Confirm with the contracting agency and your system security plan which assets are in the CUI boundary, and record any shared services that touch that boundary. A narrow enclave shrinks monitoring work, but every connected system that can reach it still needs review.

Named monitoring and assistance roles

03.06.02 assumes people hold monitoring, tracking and response assistance duties. Assign these roles to named teams, such as a security operations group for monitoring and a help desk for user support, and write down who records incidents and who reports them outward. Assessors interview these people, so role gaps that exist only on paper tend to surface during the interview method.

Reporting clock and authorities

The two organization-defined parameters for this requirement are the time allowed to report a suspected incident internally and the authorities that receive incident information. Set both values in writing, because NIST does not assign them and the organization must. For DoD contract work, check the DFARS 252.204-7012 reporting timeline against your internal limit so the internal clock does not consume the external window.

User help resource coverage

The requirement calls for a support resource that advises and assists system users with handling and reporting incidents. Decide whether this is a ticket queue, a phone line, a chat channel or a named contact, and confirm it reaches every user group that touches CUI, including remote and contractor staff. Keep the contact details current and test that users can reach the resource outside business hours if your contracts require it.

Managed SOC and cloud logging providers

A managed security operations provider or cloud logging service that stores or processes CUI-related logs becomes part of the monitoring capability for assessment purposes. Ask each provider where logs are stored, who can access them, how quickly alerts are passed to your team, and how they support your reporting clock. Put these obligations in the service agreement, because the organization remains responsible for meeting the requirement even when a provider performs the work.

Incident tracking platform scope

The system used to record incidents, such as a case management tool, becomes an in-scope component if it holds CUI or details of CUI incidents. Decide whether tracking runs on an internally hosted platform, which keeps all records under your control, or a hosted service with its own boundary review. Either way, confirm that the tracking record can show each incident's timeline and reporting decisions for an assessor.

How an assessor tests 03.06.02 in SP 800-171A Rev. 3

This table pairs the examine, interview and test methods that SP 800-171A Rev. 3 uses for 03.06.02 with the objects each method covers, the evidence an assessor typically asks for and the findings that appear most often. The assessment uses five determination statements and two checks that the organization-defined parameters (the reporting time period and the authorities) have values, so define both before the assessment begins.

Assessment object	Method	Evidence requested	Common findings
Incident response policy and procedures	Examine	Approved policy and procedures covering monitoring, reporting and response assistance, with an owner and review date	Policy does not state the reporting time period or the authorities
Procedures for incident monitoring and response assistance	Examine	Monitoring procedure naming each log source and triage steps, plus the documented support path for users	Monitoring sources are not named, or the user support resource is not described
Incident response records and documentation	Examine	Incident register with timestamps, status changes, assigned owners and closure records	Records have gaps in timestamps or cannot be traced to a monitoring source
Incident response plan	Examine	Plan sections that set the reporting time period and list the authorities that receive incident information	Authorities in the plan do not match contract or agency obligations
Defined ODP values (reporting time period and authorities)	Examine	Written values for both parameters, approved and visible in the policy and plan	Parameters are left blank, so the two ODP checks cannot pass
Personnel with incident monitoring responsibilities	Interview	Confirmation of how alerts are watched, triaged and escalated, consistent with the procedures	Staff describe a reporting window or escalation path that differs from the documented one
Personnel with incident response assistance and information security duties	Interview	Confirmation of who users contact, how they reach that contact and how reports are followed up	Users do not know the support resource exists or how to reach it
Incident reporting processes	Test	Exercise in which a suspected incident is reported, timed and delivered to the defined authorities	Reporting path has never been exercised, so timing and delivery cannot be shown
Incident monitoring capability	Test	Demonstration that alerts from monitored sources create tracked, documented incident records	Monitoring output is not connected to the incident record, so reports cannot be traced to a source

Why the two organization-defined parameters decide the work

The two organization-defined parameters (ODPs) in 03.06.02 decide what the organization must build. The first sets the time period for reporting suspected incidents to the organizational incident response capability. The second names the authorities that receive incident information. NIST does not assign either value. If the federal agency that holds the contract or agreement specifies them, the organization adopts those values. If the agency does not, the organization must assign them itself, or the requirement is incomplete. Confirm in the contract, the agency's instructions and any DFARS terms that apply which values are already fixed, and whether the agency expects a particular form for them.

NIST's Rev. 2 to Rev. 3 change analysis classifies the change for 03.06.02 as significant, because the Rev. 3 requirement asks for more detail and foundational tasks than its Rev. 2 predecessor, 3.6.2. For teams that already track incidents, the shift is less about owning a ticketing tool and more about writing down who is told, how quickly, and through which channel. SP 800-171A assesses 03.06.02 with determination statements that check the ODP values are defined, so an assessor will ask for the written values before anything else. Read the SP 800-171A Rev. 3 assessment procedure for 03.06.02 to see which objects will be examined.

Assessors also check that the values are followed in practice. They interview the people who monitor for incidents and the people who support users, then sample incident records and compare detection times, notification times and recipients against the written values. A value that appears in a policy but never appears in a record will weaken the test. A practical step is to map each authority to its trigger in the incident response procedure, define the moment the reporting clock starts, and keep a record of each notification. For illustration, a record showing the first alert, the time of notification and the recipient list lets an assessor check the outcome without relying on memory.

The order to implement 03.06.02, and the output of each step

This sequence turns the 03.06.02 requirement into a working reporting path with defined parameters, consistent incident records, a published user support channel and tested evidence an assessor can sample. Each step closes with an artifact the organization can show.

Confirm the organization-defined parameters
Start by settling the two ODP values for 03.06.02: the time period for reporting suspected incidents to the organizational incident response capability, and the authorities that receive incident information. Ask the contracting officer or agency in writing which values they specify, and if they specify none, the organization must assign them. Leaders should record the decision, its owner and the approval date. The output is a signed ODP decision that names both values and links to the contract or agreement it applies to, which an assessor will check against the determination statements that test whether the values are defined.
Define the incident record and its fields
Design one incident record template that captures what the organization needs to track and document: detection source, date and time observed, reporter, affected systems and CUI involved, a classification, actions taken, the time of each report made under the defined period, the authorities notified and closure. Map the fields to the ODP values so the reporting timestamps can be compared against the defined period. The output is a sample incident record, populated with an illustrative case, and a field definition document that the incident response team has approved. Case management tools such as DFIR-IRIS can hold this structure, but the organization should confirm the fields it needs before configuring any tool.
Set up monitoring intake and tracking
Connect the sources that generate suspected incidents, such as the SIEM, endpoint detection tooling and security mailboxes, to a single intake point where every item becomes a tracked record. Assign an owner for triage and set how each record is numbered, timestamped and kept, with an audit trail of changes. Where automation helps, workflow tools such as Shuffle can route alerts into the case record, but the workflow should be tested against sample events before it is trusted. The output is a monitoring procedure and a log export showing that test events created tracked records with timestamps, owners and status changes.
Publish the user support and reporting channel
Give system users an incident response support resource they can reach to ask for advice and report suspected incidents. Publish the contact method, what users should report, how quickly they should report it in line with the defined period, and what information to include. Brief users on the channel as part of training so the reporting path is known before an event. The output is a published user procedure with the support contact, along with dated evidence of its distribution, such as an intranet page version or a training acknowledgement.
Rehearse the report path and keep the records
Run a test of the full path, from a simulated user report through triage, the incident record, the report to the defined authorities and closure. Use an illustrative scenario that involves CUI so the team checks the authority list and the reporting period. Record what happened, where the path slowed down, and what changed afterward. The output is the completed test record, the corrective actions with owners, and the updated procedure. Keep these records with the incident log, because an assessor will sample the incident records and the procedures together to confirm the capability operates as written.

Which evidence passes 03.06.02 and how to keep it current

An assessor testing 03.06.02 samples documents and records rather than taking statements on trust. The six artifacts below each answer a different determination statement, and together they show that incidents are tracked, suspected incidents are reported on time, the right authorities are informed, and users have a support resource. Confirm the refresh interval for each artifact against your own policies and your assessor's expectations, since SP 800-171A Rev. 3 does not set calendar intervals for most of them.

Incident response policy and procedures

The written policy and procedures show that monitoring, reporting and response assistance are defined before any incident occurs. The assessor checks that the documents name who monitors, who receives suspected-incident reports, and which authorities receive incident information. Confirm that the document owner has approved the current version and that it matches the incident response plan. Review it after any change to reporting channels, contacts or the systems in scope, and record each review with a date and approver.

Incident monitoring and assistance procedures

These procedures describe how alerts from logs, endpoint tools and other sources are triaged into incidents, and how users reach help. An assessor compares the procedure with the tools in use and interviews the staff who run monitoring. Keep a dated record of each review, and update the procedure when a monitoring source is added, removed or re-routed. Screenshots or exported configurations of the monitoring tools help show the procedure matches reality.

Incident records with timestamps and disposition

Each incident record should show detection time, the time it was reported to the incident response capability, the actions taken and the final disposition. Assessors sample records to test whether suspected incidents were tracked and reported within the time period your organization defined. Export the full record set on a fixed schedule and check that no entries are missing timestamps. Retain records for the period your contracts and the incident response plan require.

Reporting section of the incident response plan

The reporting section names the internal reporting deadline, the internal recipients and the external authorities who receive incident information. It is the document that gives the two organization-defined parameters for 03.06.02 their values. Confirm that the deadline and contact list match what staff were trained on and what the records show. Re-approve the section whenever contacts, contractual reporting duties or authorities change, because a stale contact list is a common reason reports fail.

Support resource evidence

Evidence of the support resource shows that system users have a named channel and a responsible owner for help with incidents. Keep the published contact method, the on-call or help desk roster, and sample responses to user questions or reports, with dates. Assessors interview the owner and may test the channel. Test the channel on a set schedule and record the result, and refresh the roster whenever staff change roles.

Records of reports to defined authorities

These records prove that incident information reached the authorities named in your plan, such as a contracting agency or other party your agreements require. Keep each transmission with its date, recipient, content summary and any acknowledgment. Assessors check whether reports were made within the defined period. Review the list of authorities against each active contract at least once a year and whenever a contract is added, amended or closed.

What meeting 03.06.02 costs in money and effort

This table lists the cost components of meeting 03.06.02, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to structure a written scope and to see where self-hosted open-source tooling shifts spend from licenses to engineering time. No figures are given because none were supplied for this requirement, so request an itemized quote for each line.

Cost component	One-time or recurring	Who is paid and what drives the cost
Tooling or licenses (case management, SIEM or alert intake, workflow automation)	Recurring for commercial licenses, one-time for setup	Vendor license fees scale with users, data volume and connectors. Self-hosted open-source case management and workflow tools remove license fees but still need hosting and maintenance.
Engineering time to build intake and tracking	One-time, with ongoing change	Internal staff or implementation partner connect log sources, alert feeds and ticket queues into one incident record. Driven by the number of log sources and alert feeds in scope.
Writing the reporting procedure and defining the ODPs	One-time, reviewed periodically	Organization staff define the time period for internal reporting and list the authorities that receive incident information. Driven by the number of reporting authorities and contract obligations that apply.
Support resource for system users	Recurring	Staff time for a named contact or help channel that advises users on handling and reporting incidents. Driven by user population and the number of CUI systems.
Evidence upkeep (incident records, timelines, reports, review logs)	Recurring	Analysts keep case records complete and retain them for assessment. Driven by alert volume and the number of incidents tracked each period.
External testing or independent review	Recurring or periodic	A qualified outside firm tests whether reporting and monitoring work in practice. Priced from the written scope, so ask for the test objects and sample size up front.
Assessor effort	Periodic, per assessment cycle	The independent assessor examines records and interviews staff against the determination statements. Driven by the number of records to sample and the number of people to interview.

Open-source tools that can produce 03.06.02 evidence

Two self-hosted open-source tools can generate much of the record that 03.06.02 asks for: tracked incidents, timestamps, reporting trails and support workflows. Neither tool makes an organization compliant. The organization still defines its reporting windows, authorities and support resource, and an independent assessor decides whether the evidence meets the requirement.

DFIR-IRIS case records

DFIR-IRIS keeps each incident as one case that holds assets, indicators of compromise, tasks and evidence, with a full audit trail. Alerts from SIEM, EDR and REST sources can be triaged into cases, which gives assessors a single place to examine how suspected incidents were tracked and documented. Check that the case fields capture the time each suspected incident was reported to the incident response capability, since that is the ODP the organization must set. Its license is LGPL-3.0-or-later, so confirm how your deployment and any modifications will be distributed.

DFIR-IRIS timelines and evidence logs

DFIR-IRIS builds a consolidated investigation timeline from case activity and logs evidence with SHA-256 verification and chain of custody. For 03.06.02, these records show what happened, when it was recorded and who handled each item, which supports interview and examine testing. Confirm that evidence hashes, custody entries and timeline edits are retained under the organization's own retention rules, and that access to them is restricted to authorized responders.

Shuffle reporting workflows

Shuffle workflows are event-driven automations that start from a webhook, a schedule or a manual run. App nodes can connect a SIEM, a ticketing system and a firewall, so a suspected incident can be routed to the right internal responders and authorities without custom code. Document each workflow as a reporting path, including its trigger, recipients and the time it runs, so the defined reporting period in the organization's procedures can be shown in operation. Its license is AGPL-3.0-only, which can require source disclosure when a modified version is offered to users over a network, so review this with counsel before customizing it.

Shuffle routing to authorities

A workflow can also send incident information to the authorities the organization has defined for 03.06.02, such as a legal team, a contracting officer or a sector regulator, by posting to chat or ticketing channels. Each automated notification leaves a run history that can serve as evidence of who was told and when. Confirm which authorities are required by your contracts and regulations, and test each route before an incident occurs. Automation supports these reports but does not replace the decision about what must be reported.

Who does what: your team, an implementation partner and the auditor

Your organization owns the control. NIST's requirement is a statement about what your system does, so the people accountable for incidents must be your people, and they must be able to show the records themselves. Under 03.06.02 that means tracking and documenting security incidents, reporting suspected incidents to your incident response capability within the time period you define, reporting incident information to the authorities you name, and staffing the support resource that advises users.

ODP decisions: Set the reporting time period for suspected incidents and list the authorities that receive incident information. NIST does not assign these values, so if your contract or agency does not specify them, your organization must.
Incident records: Keep the tracking system, case documentation and the register of suspected and confirmed incidents under your control, with named owners.
Reports to authorities: Decide who files, what each report contains and who signs off, and keep copies of what was sent.
Support resource: Name the people or queue that advises and assists users who report or handle incidents.

Before any outside party touches the work, confirm that your staff can explain each decision and produce its records without help.

How long, costly and hard is 03.06.02 to meet?

What does it cost to meet 03.06.02?

No single price applies to 03.06.02 because the cost comes from the surrounding work, not the requirement itself. Costs fall into four groups: staff time to define the reporting window and authorities, tooling to track and document incidents, log and alert integration, and any outside help. Some of these are one-time (setting up the case record, defining the ODPs, building workflows) and some recur (keeping the tracking current, running the support resource, reviewing records). Costs rise with the number of systems in scope, the number of alert sources and the number of reporting authorities. To compare quotes, ask each provider to itemize one-time versus recurring work and to state which systems and log sources the scope includes. No external figure for this requirement has been supplied, so confirm estimates directly with the vendors or partners you are considering.

How long does it take to implement 03.06.02?

The time depends on scope, and no duration is supplied for this requirement. The main variables are how many systems hold CUI, whether an incident tracking tool already exists, how many alert sources need to feed it, and how quickly leadership decides the ODP values. Organizations that already run a ticketing or case process usually need less time to document incidents than those starting from email threads and spreadsheets. Ask any partner for a written schedule tied to a fixed scope, and confirm that the schedule includes time for your internal reviews and for an assessor's evidence review.

Can a small team meet 03.06.02 without outside help?

A small team can meet 03.06.02 alone if its environment is small and it has a clear owner for incident records. The requirement is largely about discipline: every suspected incident is logged, the reporting clock starts from a defined point, the right authorities receive information, and users have somewhere to ask for help. The difficult parts are usually the ODP decisions, the evidence trail and staff availability when an incident is live, not the technology. A small team should confirm that one person can run the process end to end, including after hours, and that the records would satisfy an examiner who interviews staff and reviews procedures.

What does 03.06.02 require from our staff and systems?

The work needs three inputs from the organization. First, decisions: leadership must assign values to the two organization-defined parameters, the time period for reporting suspected incidents to the incident response capability and the authorities that receive incident information. Second, people: named staff must own monitoring, support and recordkeeping, and users must know how to reach the support resource. Third, access: the team needs log and alert data from the systems in scope, such as SIEM, endpoint and identity sources, plus permission to create and retain incident records. The organization owns these decisions and access. An implementation partner can prepare the records, workflows and evidence, but the organization must make the policy choices.

Do we need an implementation partner for 03.06.02?

An implementation partner is optional, and the decision depends on in-house capacity and the complexity of the environment. A partner can plan the work, install and configure a self-hosted incident case platform, connect alert sources, build automations and document the evidence an assessor will examine. DeployOpen prepares systems, controls and evidence for compliance assessments, under a written, fixed scope. It does not issue assessment reports or certifications. Assessment decisions rest with the organization's sponsoring agency or the independent assessor, depending on the assessment type. Ask any partner to state in writing which parts of the work it performs and which remain with your team.

What happens if the reporting window or authorities change?

If the reporting window or the list of authorities changes, the ODP values and the procedures that rely on them must be updated, approved and communicated to staff. The organization should record the change, the reason and the effective date, and keep the earlier version so that past incidents can be assessed against the rule in force at the time. Contract terms can also change these values, so review the contract and any agency direction when they are updated. Confirm with the contracting agency and your counsel which current values apply, and check the status of pending federal rules before committing to a fixed design. Building the window and authority list as configurable settings in the case workflow makes later changes faster to implement.

How DeployOpen scopes and prepares 03.06.02 evidence

DeployOpen plans and implements self-hosted open-source platforms that can record, track and report security incidents inside your own environment for 03.06.02. The organization keeps ownership of its controls, while an independent assessor decides whether the requirement is met.

How we scope

The written scope names the systems that generate suspected incidents and the teams that receive them.
Scope records the two organization-defined parameters: the reporting period and the authorities that receive incident information.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Set up a case management platform so each incident is one record with assets, indicators, tasks and evidence.
Connect alert sources such as SIEM, EDR and REST feeds so suspected incidents enter cases automatically.
Configure audit trails and evidence hashing so records show who changed what and when.

How we hand over

Provide test records showing that suspected incidents were logged and reported within the defined period.
Document the reporting workflow, the defined authorities and the support contact for system users.
Deliver evidence packages mapped to the examine, interview and test objects in SP 800-171A Rev. 3, for your assessor to review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover updates to reporting timelines and authority lists when your contracts change.
Confirm with your assessor which evidence formats they accept before the build begins.

03.06.02 Incident monitoring, reporting, and response assistance