3.6.2 — Track and Report

The One-Liner

If a cyber incident affects CUI and you don’t report to DIBCAC within 72 hours, you’ve violated your DFARS contract.

What It Says

Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.

What It Actually Means

Every incident — from a phishing attempt to a confirmed breach — must be tracked, documented, and reported to the right people. Three activities:

1. Track. Every incident is logged in a ticketing system or incident tracker with: what happened, when it was detected, severity, affected systems, CUI impact assessment, actions taken, current status, and resolution. The incident lives in the tracker from detection through closure.

2. Document. Each incident has a record that captures the full lifecycle: initial detection, analysis findings, containment actions, recovery steps, and lessons learned. Evidence is preserved — screenshots, log exports, forensic images where applicable.

3. Report. Internal: notify the people who need to know based on severity — IT management, executive leadership, legal, and the prime contractor. External: for incidents involving CUI, report to DIBCAC via DIBNet within 72 hours of discovery per DFARS 252.204-7012. The 72-hour clock starts at discovery, not at confirmation.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are incidents tracked?	Incident tracking system with entries from detection through closure
2	Are incidents documented?	Incident records with timeline, actions, evidence, and resolution
3	Are external reporting authorities identified?	DIBCAC identified; DIBNet portal access verified; 72-hour procedure documented
4	Are internal officials identified?	Escalation matrix: who is notified at each severity level
5	Are external authorities notified?	Evidence of DIBCAC reporting for past CUI incidents (or documented procedure if no incidents have occurred)
6	Are internal officials notified?	Internal notification records for past incidents

---

What to Have Ready on Assessment Day

Documents they’ll review: Incident response policy; incident tracking records; incident documentation; internal notification records; DIBCAC reporting procedures; DIBNet portal access evidence; escalation matrix

People they’ll talk to: Personnel with incident monitoring and reporting responsibilities; management who receive incident notifications; personnel with DIBCAC reporting responsibility

Live demos they’ll ask for: “Show me your incident tracking system.” “Walk me through a past incident record.” “Show me your 72-hour reporting procedure and DIBNet access.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me your incident tracking system. Walk me through a recent entry.”
• “Who gets notified internally when an incident is detected? Show me the escalation matrix.”
• “How do you report to DIBCAC? Show me the procedure and DIBNet access.”
• “When does the 72-hour clock start? Who is authorized to file the report?”
• “Show me documentation from a past incident — or your template if you haven’t had one.”

Real-World Example

A defense contractor tracks incidents in their ITSM ticketing system with a dedicated “Security Incident” category. Each ticket captures: detection timestamp, source (SIEM alert, user report, EDR), affected systems, CUI impact assessment (yes/no/unknown), severity level, assigned responder, timeline of actions, evidence attachments, and resolution. The internal escalation matrix: Low/Medium → IT Security Lead + IT Manager within 4 hours. High → add CEO within 2 hours. Critical (CUI breach) → full IR team + attorney within 1 hour, 72-hour DIBCAC clock starts. The IT Security Lead has DIBNet portal credentials and the DIBCAC reporting procedure is a step-by-step checklist in the IR plan. Even though the company hasn’t had a CUI incident, they verify DIBNet access annually and have a pre-filled reporting template ready. The assessor reviews the tracking system, the escalation matrix, and the DIBCAC reporting procedure.

---

Where Companies Trip Up

No incident log. Incidents are handled but not tracked. The assessor asks “show me your incident records” and there are none. Use a ticketing system — even a dedicated spreadsheet — but track everything.

No 72-hour awareness. The IR team doesn’t know about the DFARS 252.204-7012 reporting requirement or has never accessed DIBNet. Train the team, verify portal access annually, and include the procedure in the IR plan.

Internal only. Incidents are handled and reported internally but the external reporting requirement is ignored. DIBCAC reporting is a contractual obligation for CUI incidents.

No evidence preservation. Incidents are resolved but logs, screenshots, and forensic evidence aren’t preserved. Document as you go — evidence is needed for DIBCAC reporting and lessons learned.

---

How to Talk About This

To a CEO or Board

Every incident is tracked from detection through resolution. For CUI incidents, we report to the DoD within 72 hours as required by our contract. Internal stakeholders are notified based on severity within hours.

To an Engineering Team

Incident tracking in ITSM with Security Incident category. Escalation: Low/Med → 4h, High → 2h + CEO, Critical → 1h + full team + attorney. DIBCAC: 72h clock from discovery, DIBNet portal access verified annually, pre-filled template ready. Evidence preserved: log exports, screenshots, forensic images. Post-incident review within 2 weeks.

---

Connected Requirements

Requirement	Why it matters here
3.6.1 — Have a Plan	The IR plan that establishes the capability this requirement exercises
3.6.3 — Test the Plan	Testing validates that tracking and reporting procedures work
3.3.6 — Search and Report	On-demand log queries support incident investigation and documentation

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: IR.L2-3.6.2 | SPRS Weight: 5 points | POA&M Eligible: No