CMMC Incident Reporting: A 72-Hour Contractor Checklist

A suspected compromise involving Controlled Unclassified Information can put a defense contractor on a clock before the facts are complete. I tell clients to treat the first alert as a reporting decision, not only an IT troubleshooting ticket.

CMMC incident reporting depends on prepared people, preserved evidence, and clear contract responsibilities. While the 72-hour requirement stems from DFARS 252.204-7012, your obligations are deeply tied to the security controls found in NIST SP 800-171. Ultimately, your CMMC Level 2 certification assesses whether your security practices can support a controlled, timely response to these threats.

Key Takeaways

• DFARS 252.204-7012 requires covered defense contractors to meet the 72-hour reporting requirement for all qualifying cyber incidents.
• The reporting clock starts when your organization discovers the incident, not after forensics confirm the full scope.
• Reports generally go through the DIBNet portal and should identify affected systems, contracts, and the impact on Controlled Unclassified Information or CDI.
• Preserve affected system images, logs, and relevant forensic data for at least 90 days after reporting.
• Confirm your contract clauses, subcontractor obligations, and established roles and responsibilities with counsel and your contracting officer before an incident occurs.

Know What Triggers the 72-Hour Reporting Clock

The 72-hour rule applies when a cyber incident affects Covered Defense Information (CDI), systems handling CDI, or a contractor’s ability to provide operationally critical support. CDI includes Controlled Unclassified Information that your contract requires you to safeguard, specifically under the requirements of DFARS 252.204-7012.

When an event occurs, you must identify if it qualifies as one of the reportable cyber incidents. This category includes unauthorized access, malware and ransomware, suspected data theft, or a loss of availability that affects a system containing CUI. The event does not need to become a public breach before you act. Waiting for perfect certainty can consume the reporting window, and the DoD’s DIB Cybersecurity Program guidance confirms that contractors must report the information available within 72 hours of discovery. That wording matters, as early reports can be updated as your investigation develops.

Achieving compliance under CMMC Level 2 requires robust incident-response capabilities, including documented processes, trained personnel, testing, and post-incident learning. These practices are often mapped to the security controls found in NIST SP 800-171. However, I separate the two core questions for my clients:

1. Does the incident meet the DFARS reporting threshold?
2. Can the organization show that its CMMC incident-response practices worked as documented?

Both questions deserve immediate attention. A mature response process helps your team address them without confusion or delay.

A 72-hour reporting period is not a 72-hour investigation period. Report what you know, preserve what you can, and continue the investigation after submission.

CMMC Incident Reporting Checklist by Time Window

A written incident response plan should clearly define roles and responsibilities for every action. In a small company, one person may hold several roles, but the responsibilities still need clear ownership.

Immediate response: first minutes and hours

• Record the exact discovery date, time, reporting person, affected user, and initial indicators.
• Activate the Incident Response Team, executive contact, IT provider, and counsel according to your incident response plan.
• Engage your Security Operations Center to isolate affected endpoints or accounts when containment will not destroy evidence or disrupt safety-critical operations.
• Preserve volatile data when possible, including active connections, memory details, authentication activity, and cloud audit logs.
• Identify whether the affected device, mailbox, server, cloud tenant, or application stores, processes, or transmits Controlled Unclassified Information or CDI.
• Stop unauthorized remote access, reset exposed credentials, and revoke suspicious sessions related to phishing attempts without deleting logs.
• Open an incident record with a single source of truth for facts, decisions, timestamps, and evidence locations.

Endpoint security tools can alert on suspicious behavior, but alerts alone do not determine reportability. Your team must connect the alert to system scope, data type, contract obligations, and operational impact.

First 24 hours: contain, classify, and prepare

• Determine the affected contract numbers, CAGE code, physical locations, IP addresses, hostnames, and business functions.
• Identify the suspected incident type, such as unauthorized access, credential theft, or possible exfiltration.
• Review Controlled Unclassified Information data flows, Microsoft 365 audit activity, firewall logs, VPN records, endpoint telemetry, and backup status.
• Document every step taken for containment and eradication, including account disables, host isolation, network blocks, and restoration decisions.
• Confirm that the person authorized to submit through DIBNet possesses a valid Medium Assurance Certificate and required credentials.
• Notify your contracting officer if DIBNet is unavailable and document that notification.
• Assess whether a subcontractor, managed service provider, cloud host, or other third party handled the affected CDI.

For a practical overview of the data expected in a submission, review this 72-hour DoD incident reporting guide. Your internal worksheet should follow the official Incident Collection Format to collect the same facts before the pressure of a live incident.

Before 72 hours: submit the DoD report

• Submit the cyber incident report through the DIBNet portal within 72 hours of discovery.
• Include the company name, CAGE code, point of contact, relevant contract numbers, and discovery date and time.
• Describe affected systems, locations, IP addresses, system functions, suspected attack method, and current containment status.
• Identify the categories of sensitive data involved without placing unnecessary information into the narrative.
• State whether the incident affected confidentiality, integrity, availability, operational capability, or potential data exfiltration.
• Save proof of submission, report identifiers, screenshots, and the final narrative in your incident file.
• Escalate discovered and isolated malware through the approved DoD Cyber Crime Center process. Do not email malware samples.

The report is a factual notification, not a final forensic conclusion. I advise clients to avoid speculation and separate confirmed facts from preliminary findings.

Post-reporting: preserve evidence and improve the response

• Prioritize forensic data preservation by creating images of affected systems, relevant logs, and data for at least 90 days.
• Adhere to strict 90-day evidence retention policies, including incident notes, tickets, email approvals, vendor communications, and evidence chain-of-custody records.
• Respond promptly if the DoD requests additional information, media, or access to affected cloud environments.
• Conduct a lessons-learned review after containment and recovery.
• Update the incident response plan, System Security Plan, risk register, training content, and technical controls where gaps appear.
• Flow applicable reporting and evidence-preservation terms down to subcontractors handling CDI.

A strong after-action review can expose issues that routine audits miss, such as missing administrator logs or unclear executive authority. CMMC incident-response guidance for contractors can help teams compare their response process with common defense-sector expectations.

Build a Reporting Process That Works Under Pressure

The incident report becomes easier when your environment has known data boundaries. I begin by mapping where Controlled Unclassified Information (CUI) enters the Defense Industrial Base, where it resides, who can access it, and which vendors touch it. That map should include cloud infrastructure, endpoints, SaaS applications, backups, remote access tools, and any on-premises data center technology. Ensuring these boundaries are clearly defined is a fundamental component of CMMC Level 2 compliance.

An Office 365 migration requires the same discipline, particularly when CUI moves into Microsoft 365 GCC High or another approved environment. Secure cloud architecture, cloud management, and careful identity controls support reporting because they produce usable audit evidence when an incident occurs. By aligning your environment with NIST SP 800-171 controls, you ensure that your documentation is ready for a future C3PAO assessment.

Device hardening and endpoint security also reduce the number of ambiguous alerts. For example, an endpoint platform that records process activity, isolation actions, and user sign-ins gives investigators a defensible timeline. A vague alert with no retained logs creates costly uncertainty that hampers your incident handling capability.

My Small Business IT work often includes restaurant POS support and kitchen technology solutions. Those systems may have no relationship to CUI, yet they can share networks, identity services, support accounts, or backup platforms with the Defense Industrial Base operations. I document those boundaries and restrict access accordingly to prevent lateral movement.

Cybersecurity services should connect incident response to business continuity and security, not operate as a separate technical exercise. A tested recovery plan protects availability, while the reporting plan protects your contractual position and evidence. Regularly scheduling tabletop exercises ensures your team knows how to execute these recovery procedures under pressure.

As a business technology partner, I use technology consulting to connect innovative IT solutions and tailored technology services to actual contract risk. That can include infrastructure optimization, digital transformation planning, IT strategy for SMBs, and managed IT for small business support. Each decision should preserve the logs, access controls, recovery options, and accountability needed during an incident.

Frequently Asked Questions

Does every security alert trigger the 72-hour reporting requirement?

No, the requirement specifically applies to incidents involving Covered Defense Information (CDI) or systems that support your contract obligations. Your team must evaluate whether the alert represents unauthorized access, malware, or data exfiltration that impacts sensitive information or system availability. Use your internal incident response plan to filter out false positives while ensuring reportable events are escalated promptly.

Can I wait until my forensic investigation is complete before reporting?

No, waiting for a full investigation will likely result in missing the 72-hour deadline established by DFARS 252.204-7012. You are expected to report the information available at the time of discovery and provide updates as your investigation proceeds. The clock begins when the incident is discovered, not when the full scope or root cause is confirmed.

What happens if I am unable to access the DIBNet portal during an incident?

If technical issues prevent you from submitting your report through the official DIBNet portal, you must notify your contracting officer immediately. Document this communication, including the date, time, and method used to reach them, as part of your incident record. Maintaining this documentation is essential for proving your good-faith effort to comply with your contractual reporting obligations.

Keep the 72-Hour Clock From Becoming a Compliance Failure

A CMMC-ready response process begins long before the first suspicious alert. To maintain compliance within the Defense Industrial Base, I recommend assigning reporting authority, confirming DIBNet access, mapping systems that house Controlled Unclassified Information, testing evidence collection, and rehearsing the first day workflow.

The strongest control is a practiced incident response plan that turns confusion into documented action. CMMC incident reporting becomes manageable when your team knows who acts, what to preserve, and when to submit. Because DFARS 252.204-7012 mandates a strict 72-hour reporting requirement, your team must be prepared to act immediately upon discovering a cyber incident.

Your readiness for a future C3PAO assessment often hinges on how well you have implemented NIST SP 800-171 security controls. By integrating these requirements into your daily operations, you ensure that the 72-hour reporting requirement does not result in a compliance failure. Remember that DFARS 252.204-7012 carries significant weight, and your documentation must prove you are ready to meet these obligations.

This article provides general information, not legal advice. Confirm contract-specific reporting duties with qualified counsel and your contracting officer before relying on any incident-response checklist.