Incident reporting sounds like it should be straightforward: something bad happens, you tell people. In reality, the gap between awareness and actual, documented reporting trips up a lot of organizations. You might know an incident occurred. Your SOC might know. But tracking it, documenting exactly what happened, and getting the right notification to the right people at the right time requires a defined process and discipline.
This is where IR.L2-3.6.2 lives: making sure that when an incident happens, it doesn’t stay local knowledge. It gets tracked, documented, and reported according to your plan.
What the assessor is actually evaluating
The assessor wants to see three things:
- You have an incident definition. Not every security event is an incident. Your IRP should define what crosses the threshold.
- Incidents are tracked somewhere dedicated. Not in your general ticketing system mixed with change requests. A separate queue or log that shows incident ID, discovery date, who was told, what actions taken.
- You have reporting procedures. Who inside the organization gets told immediately? Who gets told later? Are there external authorities (law enforcement, regulators, the government customer) who need notification? When? By whom?
That last point matters a lot. If your contract has DFARS language, you already know reporting windows exist. If not, your IRP still needs to spell out the “when and who” for internal and external notification.
Incidents vs. alerts: get this right first
This distinction determines everything:
- An alert is output from a security control. Antivirus quarantined malware. Firewall blocked an unusual destination. IDS flagged a pattern. The control worked. Event logged. Move on.
- An incident is unauthorized activity that resulted in, or could result in, damage, loss of CUI, service disruption, or compromise. A user’s credentials were stolen and the attacker accessed a system holding CUI. That’s an incident.
A phishing email that arrived in someone’s inbox, the user didn’t click it, and the mail filter logged it? Alert. A user was socially engineered, clicked a link, entered their password on a fake login page, and you confirmed the attacker logged into their account? Incident.
Your IRP must define this for your organization. Once you do, alerts are routine. Incidents trigger the reporting process.
Tracking and documentation
When an incident is confirmed, it goes into a dedicated tracking system. For most contractors using an MSSP, this is a separate board or queue in the PSA tool (ConnectWise, Halo, Autotask, etc.). In practice, the MSSP usually discovers the incident through their monitoring. If the client discovers something on their own, they submit a SOC ticket letting the MSSP know, the MSSP formally declares it an incident, and then moves it to the dedicated incident response board. The tracking form covers:
- Incident ID and date discovered
- Brief description of what was confirmed
- Who discovered it
- Initial severity assessment (binary: is it or isn’t it)
- Notifications sent (to whom, when)
- Initial containment actions
- Follow-up investigation details as they emerge
Don’t overthink the severity matrix. You don’t need Sev 1-4 colors. You need to know if this is an actual incident that requires escalation and reporting, or if it’s an alert that’s closed.
Internal and external reporting
Internal reporting usually flows to leadership immediately: the incident response team lead, your information security lead, and whoever in your organization is responsible for risk decisions. If someone outside IT needs to know (your customer, if you’re on contract), that gets decided here.
External reporting might include law enforcement (FBI, Secret Service), your government customer (if you have a DFARS contract and this touches CUI), or your cyber insurance carrier. Your IRP should identify the trigger for each. The assessor typically doesn’t dig deep into your external reporting obligations. They focus on making sure the role of who handles external reporting is defined (usually the FSO) and that your internal tracking and process are solid.
The reporting obligation lands on your organization, not your MSSP. If you use one, they gather the data and timeline, but your leadership team makes the call about who gets notified and when.
"Our organization maintains an Incident Response Plan (IRP) that defines what constitutes a reportable incident: confirmed unauthorized access to systems or data, malware execution resulting in persistence or exfiltration, credential compromise with verified abuse, or denial of service causing service loss. All alerts are logged in our monitoring platform. Incidents are identified by our incident response team when they meet this definition and are immediately escalated to the CISO and Chief Operations Officer. Confirmed incidents are recorded in a dedicated incident tracking log within our ticketing system (separate from routine change tickets), at least within 1 hour of confirmation. Each incident record documents the discovery date, timeline of initial actions, systems affected, and any external notification made. External reporting is coordinated by our FSO according to contractual obligations and applicable law. For any incident involving CUI, we notify our customer's facility security office at least within 24 hours of confirmation."
How to present your evidence
Bring the IRP to the assessment. The assessor will scan it for the incident definition and notification procedures. Have an example of a completed incident form or log entry (redacted if needed for confidentiality, but real). If you’ve had an incident, show the tracking record, the notification email, and the timeline of actions taken. If you’ve never had an incident, have a blank form template showing the fields you’d populate, plus evidence of a tabletop exercise or incident response drill that proves the team knows the process.
Your ticketing system should show a dedicated incident queue or board separate from regular work. The assessor will pull up a few tickets to confirm incidents aren’t mixed with change requests or help desk tickets. The ticket doesn’t get closed until lessons learned are documented in it. Meeting notes, a recording of the review, whatever format works. But the lessons learned review has to happen and has to be captured in the ticket before it’s marked complete. This is a documented process and it is enforced.
Common failures
No incident definition in the IRP. "We report incidents" doesn't cut it if you haven't defined what an incident is. An assessor can't evaluate whether you're reporting correctly if you haven't said what you're looking for.
Incidents mixed with alerts in general logs. If your incident tracking is "we log everything to Splunk and search for keywords," you're not separating incidents from noise. Use a dedicated queue or form.
IRP clearly defines incident criteria. Incident log exists and is separate from routine work. At least one completed or templated incident record is available. For small contractors with no incidents, a tabletop exercise or annual IRP drill shows the team knows how to execute the process.
Q&A: What the assessor asks and what good answers sound like
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
If you use an MSSP or MSP
Your service provider should detect and contain incidents, but reporting decisions stay with your organization. Their role: investigate the incident, gather forensic data, and provide you a factual timeline. Your role: decide if it meets your incident criteria, notify your leadership, and coordinate external reporting. Make sure your contract clearly assigns these responsibilities. The assessor will ask who reports to the customer and when. The answer should be you, not your MSSP.
Disclaimer: This guide reflects NIST 800-171 Rev 2 and common assessment practices as of March 2026. Your specific contract, industry, and location may impose additional reporting requirements. Work with your FSO and legal counsel to align your IRP with those obligations.