DFARS Compliance

DFARS 7012 Incident Reporting: What to Do in the First 72 Hours

Q: What starts the 72-hour clock under DFARS 252.204-7012?

Discovery. Rapidly report is defined as within 72 hours of discovery of any cyber incident, and discovery means the moment you become aware an incident occurred or may have occurred, not when you finish confirming it. There is no grace period for internal investigation.

By The Defense Compliance Report Editorial Team · Last reviewed: July 2026· Last verified: July 3, 2026

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DC3/DCISE, DCMA DIBCAC, NIST, SPRS, or any U.S. government agency. This is educational regulatory research, not legal, contractual, incident-response, or compliance advice.

DFARS 7012 incident reporting means that if you hold a contract with DFARS clause 252.204-7012 and you discover a cyber incident that affects covered defense information (CDI), the systems that store, process, or transmit it, or your ability to provide operationally critical support, you must report it to the Department of Defense within 72 hours of discovery. Preserve affected-system images and monitoring data for 90 days, submit any isolated malware to the DoD Cyber Crime Center (DC3) — never by email — and flow the requirement down to subcontractors.

Here’s the wrinkle that trips up almost everyone: the clause text still tells you to report at DIBNet ( dibnet.dod.mil) — but that is no longer where mandatory reports are entered. DC3 now routes mandatory 252.204-7012 reports through its Incident Collection Format portal. If your incident-response plan still says “go to DIBNet,” it’s pointing at a redirect. We’ll show you exactly where it goes now, what to have ready before the clock starts, and how to structure each step — including the moves that protect you legally.

Inside the 72-hour window? Jump to the current reporting path and the ICF fields. Everything else can wait until the report is filed.

What we actually verified for this page: On July 3, 2026, we read the DFARS 252.204-7012 clause text on Acquisition.gov and the eCFR; we cross-checked the reporting procedures, third-party-provider rule, and preservation rules against 32 CFR 236.4; and we verified current DC3/DCISE operational guidance at dc3.mil. Every time-sensitive fact on this page is dated. This is educational research, not legal or incident-response advice.

Your first move, by situation

If this is you…	Do this first	Why
You discovered a possible compromise of a system that stores, processes, or transmits CDI/CUI	Start the evidence-preservation and 72-hour reporting workflow now	The 72-hour clock runs from discovery, and preservation has to happen before you remediate
You don’t yet know whether CDI was involved	Preserve evidence, then review your contract and data map immediately	Don’t wait for certainty if a covered system may be involved; the “suspected” bar is low
Your IR plan still says “report at DIBNet”	Use the current DC3/DCISE Incident Collection Format path and document the destination you used	The clause names DIBNet; DC3 now routes mandatory reports to the ICF portal
You don’t have credentialed portal access	Contact DCISE using the assistance path below; don’t assume you can finish account or certificate setup inside the incident window	Filing through the portal requires established access, which takes time to obtain
You isolated malware	Do not email it; use the DC3 submission process	The clause and DC3 both require malware to go to DC3, and DC3 says not to email malicious files
You’re a subcontractor	Report the incident yourself, then give the DoD-assigned report number to your prime	The impacted company must report; you can authorize your security provider to file for you, but you can’t report an unrelated company’s incident

Inside the 72-hour window? Jump to the current reporting path and the ICF fields. Preparing before an incident? Skip to what your IR plan needs.

The regulation vs. reality gap you need to know about

The clause and the operational instructions no longer say the same thing, and reading the clause alone will not surface that. Here’s the reconciliation, verified July 3, 2026:

What the DFARS 7012 clause text says	What DC3/DCISE does today
Submit the required report elements “at `https://dibnet.dod.mil`”	DC3 routes mandatory 252.204-7012 reports through the Incident Collection Format portal at `icf.dcise.cert.org`; the old DIBNet link now redirects to DC3/DCISE
Report within 72 hours of discovery	Unchanged — 72 hours from discovery, submitting what you can obtain in that window
You need a DoD-approved medium assurance certificate; see the ECA program	Still referenced; DC3 lists approved ECA vendors as IdenTrust and WidePoint (formerly ORC) — and a 2024 update to 32 CFR 236.4 also references a PIEE account for portal access
Submit isolated malware to DC3	Unchanged — via the Electronic Malware Submission (EMS) portal or a one-time link; do not email malware
Preserve affected images and monitoring data	At least 90 days from report submission

Sources: DFARS 252.204-7012; 32 CFR 236.4; DC3 DCISE.

The quiet part, out loud: The confusion is real, and it’s not your fault. The clause text hasn’t been updated to match DoD’s operational change, so a contractor following the letter of the clause lands on a redirect. That does not erase the 72-hour requirement. It means your IR plan needs to reflect the current DC3/DCISE process and keep a record of the destination you actually used. For the full clause anatomy, see our full DFARS 252.204-7012 clause breakdown.

Do you have to report this cyber incident within 72 hours?

Yes, if DFARS 252.204-7012 is in your contract and you discover a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to perform operationally critical support. The 72-hour clock is tied to discovery— the moment you become aware an incident occurred or may have occurred — not the moment you finish confirming it. The practical response is to preserve evidence, review for compromise, and report what you can obtain within the window, then file a follow-on Incident Collection Format (ICF) as more information becomes available.

The clause defines “rapidly report” precisely: within 72 hours of discovery of any cyber incident (DFARS 252.204-7012(a), Acquisition.gov). There’s no built-in grace period for internal investigation, legal review, or executive sign-off. If your monitoring flags behavior consistent with unauthorized access to a CUI system, the clock is running while you investigate.

What counts as a “cyber incident” here

A cyber incident, in the clause’s own terms, is any action through computer networks that results in a compromise or an actual or potential adverse effect on a covered information system or the information on it. “Compromise” is defined broadly enough to include cases where unauthorized access or disclosure may have occurred. Read plainly: the bar for a suspectedincident is intentionally low. When you’re genuinely unsure whether something crossed the line, the defensible posture is to treat it as mandatory and report — DC3 can handle a follow-on ICF clarifying that CDI was not ultimately affected. A missed 72-hour deadline is much harder to walk back.

Mandatory vs. voluntary — the distinction most pages blur

Not every security event is a mandatory report. DC3 and 32 CFR 236.4 draw a clear line:

Mandatory reporting under DFARS 252.204-7012 is triggered by a cyber incident that affects CDI, the systems that store/process/transmit CDI, or your ability to provide operationally critical support. That report goes to the ICF portal within 72 hours.
Voluntary reporting is encouragedfor activity that doesn’t compromise CDI — things the regulation explicitly treats as voluntary, including suspected advanced-persistent-threat activity, vulnerability scanning and exploitation attempts, phishing emails, suspicious files, and network compromises that don’t touch DoD information.

So a phishing email that nobody clicked, hitting a system with no CDI on it, is a voluntaryreport — useful to DoD, not a mandatory 72-hour obligation. The same phishing email that leads to unauthorized access on a CUI system is a mandatoryreport. The trigger is the effect on CDI or operationally critical support, not the scariness of the alert. When you can’t yet tell whether CDI was affected, report within 72 hours and refine later.

Situation	Reporting status
Unauthorized access, ransomware, or exfiltration touching a CDI/CUI system	Mandatory — report within 72 hours
A suspected incident where CDI involvement is unclear	Treat as mandatory; report within 72 hours, refine via follow-on ICF
Phishing, scanning, or attempts that do not compromise CDI	Voluntary — encouraged, not required
An event entirely outside covered systems with no CDI or operational-support impact	Track internally; consider a voluntary report

Reporting is not an admission of guilt

A reported cyber incident is not, by itself, treated as evidence that you failed to provide adequate security or failed to meet 252.204-7012. The Contracting Officer is directed to consider a report in the context of your overall compliance, in consultation with the DoD cybersecurity office (DFARS 204.7302(d), Acquisition.gov). That matters, because the instinct to delay reporting to “understand it better” first is exactly backward. The protection exists specifically because DoD wants reports to come in, even when the picture is incomplete.

Where do you report a DFARS 7012 cyber incident now — DIBNet or DC3/DCISE?

Answer: You report to the DoD Cyber Crime Center’s DCISE — the Defense Industrial Base Collaborative Information Sharing Environment — which DoD designates as the single focal point for DIB cyber incident reporting under DFARS 252.204-7012 and 10 U.S. Code §§ 391 and 393. The clause text still lists dibnet.dod.mil, but DC3 now routes mandatory reports through its Incident Collection Format (ICF) portal at icf.dcise.cert.org. Confirm the live destination on DC3’s site before you file.

The clean operating sequence for an active incident:

1Preserve first. Capture forensic images of affected systems and protect your logs before you remediate (details in the 90-day section below).
2Go to the current destination. Start at the DC3 DCISE page and follow its “Report a Cyber Incident” link to the ICF portal. Document the destination you used.
3Submit what you have within 72 hours. You are not expected to have complete information on the first submission; file a follow-on ICF as you learn more.
4Handle malware separately. Submit isolated malware to DC3 through EMS or a DoD SAFE link — never by email, never to the Contracting Officer.
5Keep the report number. DoD assigns an incident report number; you’ll need it for follow-on filings and, if you’re a subcontractor, to pass up the chain.

The credential you need — set it up before you need it

Two things determine whether you can actually file, and both take time to arrange:

The clause requires a DoD-approved medium assurance certificate (an External Certification Authority, or ECA, certificate). DC3 lists two approved vendors: IdenTrust and WidePoint (formerly ORC) (ECA program at public.cyber.mil/eca).
A 2024 update to 32 CFR 236.4 also references a Procurement Integrated Enterprise Environment (PIEE) account for portal access (32 CFR 236.4(e); PIEE at piee.eb.mil).

Because the access mechanism has been changing and the sources aren’t fully harmonized, the reliable move is to establish your access in advance and confirm the current requirement on DC3’s sitebefore you rely on it. The single most common failure in DFARS tabletop exercises is a credential that’s missing or expired at the exact moment someone needs to file.

If you need to report and don’t have working access: DC3 says to email DC3.DCISE@us.af.mil or call the DCISE hotline at (410) 981-0104, which operates 24/7/365. Do not send malicious files to that email.

Can an MSP, MSSP, law firm, or security provider file the report for you?

Answer: The impacted contractor stays responsible for the report — but you are not necessarily filing alone. Under 32 CFR 236.4(f), a contractor that uses a third-party service provider for information system security services may authorize that provider to report cyber incidents on its behalf. What you cannot do is file an unrelated company’s incident report as an outside party.

A DFARS 7012 report is not a product you buy your way out of. The obligation lives with the impacted contractor, and DC3 does not allow a vendor to submit a mandatory report for another company’s incident as an unrelated party. But if you use a third-party security service provider — an MSSP running your security operations, for example — you can authorize them to report on your behalf, and that authorization is expressly permitted. If a provider helps you file, document the authorization, keep the DoD-assigned report number, and make sure your organization still owns the evidence hold and the follow-on ICF process.

The right help isn’t the same for every contractor

Whether you need an MSSP, a DFIR firm, a vCISO, an RPO/RP, or just a better internal runbook depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. The contract clause sets your level, not a checklist. Because a general answer can’t resolve those for you, use The Defense Compliance Report’s Find My CMMC Path tool to map your situation to the right provider category before you request quotes.

Map your DFARS 7012 readiness →

Do not submit CUI, drawings, malware, or sensitive contract details through any form.

What information goes in the Incident Collection Format (ICF)?

Answer: DC3 directs contractors to report as much of a defined set of information as can be obtained within 72 hours, then file a follow-on ICF if you learn more later. The bottleneck in a real incident is almost never the cyber details — it’s losing hours hunting for your UEI, CAGE code, contract number (PIID), and program contacts. Stage those before an incident and you buy back most of the clock.

Here is the set of fields DC3 lists for a mandatory DFARS 252.204-7012 report (DC3 DCISE). Report what you can within 72 hours; the clause does not require perfect completeness on the first submission.

1Company name
2Unique Entity Identifier (UEI)
3Facility CAGE code
4Facility clearance level
5Contract number (Procurement Instrument Identifier, or PIID)
6Company point-of-contact information (name, position, phone, email)
7U.S. Government Program Manager point of contact
8Contract number(s) or other agreements affected or potentially affected
9Contracting Officer or agreement point of contact
10Contract or agreement clearance level
11Impact to Covered Defense Information
12Ability to provide operationally critical support
13Date incident discovered
14Location(s) of compromise
15Incident location CAGE code
16DoD programs, platforms, or systems involved
17Type of compromise (unauthorized access, unauthorized release, unknown, not applicable)
18Description of the technique or method used
19Incident outcome (successful compromise, failed attempt, unknown)
20Incident/compromise narrative
21Any additional information

Two things worth flagging. First, notice the form asks for your UEI and CAGE — not a DUNS number. Any incident-response plan or vendor guide still referencing “DUNS” is out of date; the current ICF uses the Unique Entity Identifier. Second, field 19 explicitly allows “failed attempt” as an outcome — you can and sometimes should report an attempt, but the mandatory trigger still hinges on the effect on CDI.

Who should own each field before an incident

Most of these fields live in departments that aren’t awake at 2 a.m. Assign an owner now so nobody is chasing a contract number during a breach.

ICF field group	Where it lives	Who should own it
Company name, UEI, CAGE, facility clearance	Contracts / FSO records	Contracts administrator + FSO
Contract number (PIID), affected agreements, CO and Program Manager contacts	Contract files	Contracts + program manager
Impact to CDI, systems involved, location of compromise	Security telemetry + data-flow map	Security lead / MSSP
Discovery date/time, type of compromise, outcome, narrative	Incident log	Incident commander
Malware indicators (if isolated)	EDR / DFIR	Security / DFIR

Get your identifiers ready now: Use Find My CMMC Path to map your reporting readiness — including who owns each ICF field — before you need it. Never put CUI, drawings, malware, or sensitive contract details into any web form, ours included.

What must you preserve — and can you remediate first? (the 90-day rule)

Answer: DFARS 252.204-7012 and 32 CFR Part 236 require you to preserve and protect images of all known affected systems and all relevant monitoring and packet-capture data for at least 90 days from the date you submit your report, so DoD can request the media or decline interest. In practice, that means forensic imaging happens before remediation — before you reimage, restore from backup, rotate logs, or wipe a compromised account.

The exact language: the contractor “shall preserve and protect images of known affected information systems… and all relevant monitoring/packet capture data for at least 90 days from submission of the cyber incident report to allow DoD to request the media or decline interest” (32 CFR 236.4(i)).

The tension: Your instinct after finding ransomware is to isolate, restore, and get back to work — and operationally, speed is right. But the preservation duty runs first. The 90-day clock starts at report submission, not when you finish cleaning up. Your response procedure needs an explicit “capture forensic images before touching anything” step, or you risk destroying the evidence you’re contractually required to keep.

Evidence type	Preserve this	Common failure
Endpoints & servers	Full forensic images of affected systems before reimaging	Reimaging the box before imaging it
Logs & telemetry	SIEM data, EDR telemetry, authentication and email logs	Routine log rotation quietly overwrites the window
Network	Relevant packet-capture data	No capture retained; only summary alerts kept
Cloud	Audit logs and relevant tenant data	Cloud audit window closes before export
Malware	Isolated sample, preserved for submission	Deleting the sample during cleanup

The uncomfortable question this raises: can your current environment actually do this? If your MSP reimages endpoints on a schedule, your SIEM retains 14 days, or your cloud audit logs expire fast, you may be unable to meet a 90-day hold when it counts.

Map your MSP, MSSP, SIEM, cloud, and endpoint setup against the right provider category with Find My CMMC Path before you’re relying on them in a live incident.

What do you do with malware, logs, and system images? (do NOT email malware)

Answer: Isolated malicious software goes to the DoD Cyber Crime Center (DC3) — never to your Contracting Officer, and never by email. DC3 accepts malware through its Electronic Malware Submission (EMS) portal, or via a one-time upload link or DoD SAFE link that you request from DCISE using your ICF number. Other media and equipment may be requested later for forensic analysis or a damage assessment.

The clause is specific: when you discover and isolate malicious software connected to a reported incident, submit it to DC3 per DC3’s instructions, and do not send it to the Contracting Officer (DFARS 252.204-7012(d)). DC3’s operational instructions add the how:

With a PKI certificate, get an EMS portal account and submit at ems.dc3on.gov.
Or request a one-time upload link or a DoD SAFE link by emailing DC3.DCISE@us.af.mil with your ICF number in the subject line, or by calling (410) 981-0104.
Do not use email to submit malicious files.

Artifact	Where it goes	What not to do
Isolated malware sample	DC3 via EMS or a one-time/DoD SAFE link	Don’t email it; don’t send it to the CO
System images & packet capture	Preserve for 90 days; provide on DoD request	Don’t wipe before imaging
Additional info / equipment for forensics	Provide on DoD request	Don’t assume the initial report ends your obligation
Damage-assessment information	Provide through the CO if DoD elects a damage assessment	Don’t release evidence without counsel’s coordination

How do subcontractors report a DFARS 7012 incident?

Answer: A subcontractor with 252.204-7012 flow-down obligations reports its own incident directly through the DCISE ICF portal, then provides the DoD-assigned incident report number to its prime contractor (or next higher-tier subcontractor) as soon as practicable. A subcontractor cannot satisfy the requirement by telling only the prime — and no company can file an unrelated company’s incident report on its behalf.

The rule is direct: contractors flow the reporting requirement down to subcontractors handling CDI or providing operationally critical support, and require those subcontractors to report rapidly both directly to DoD andto the prime — including providing the DoD-assigned incident report number to the prime (or next higher-tier subcontractor) as soon as practicable (32 CFR 236.4(d) and DFARS 252.204-7012(m)).

Responsibility	Prime contractor	Subcontractor
Report the incident to DoD	Report your own incidents	Report your own incidents directly
The report number	Collect it from the sub for contract management	Provide it up the chain as soon as practicable
Flow-down	Ensure the clause is in subcontracts involving CDI	Flow it down further if you have lower-tier subs handling CDI
What to share upward	—	The report number — not raw technical detail through insecure channels

One caution on channels: give the prime what the contract requires — typically the report number and coordination — without oversharing sensitive technical detail or CDI through email or a portal that isn’t cleared for it.

Does reporting a cyber incident mean you failed DFARS 7012 or CMMC?

No.DFARS 204.7302 states that a reported cyber incident is not, by itself, evidence that a contractor failed to provide adequate security or meet 252.204-7012. But that protection is narrow. It does not cover missing the 72-hour deadline, failing to preserve evidence, misrepresenting your SPRS score, or lacking the SSP and cloud terms the clause requires — and those failures carry real False Claims Act exposure.

The reassurance is genuine: the Contracting Officer weighs a report in context, not as an automatic mark against you (DFARS 204.7302(d), Acquisition.gov). The risk is separate — and it’s not theoretical.

Case study — primary source: U.S. Department of Justice

On March 26, 2025, DOJ announced that defense contractor MORSECORP Inc. of Cambridge, Massachusetts agreed to pay $4.6 million to resolve False Claims Act allegations tied to cybersecurity requirements in its Army and Air Force contracts. Among the admitted facts: MORSE used a third-party email host that did not meet FedRAMP Moderate-equivalent security or the requirements of DFARS 252.204-7012(c)–(g)— the very paragraphs covering cyber incident reporting, malware submission, media preservation, forensic access, and damage assessment — from January 2018 to September 2022; it had not fully implemented all NIST SP 800-171 controls; it lacked a consolidated system security plan for each covered system; and it posted an SPRS score far higher than a later third-party assessment supported.

Two details worth sitting with. The DOJ release identifies the case as United States ex rel. Berich v. MORSECORP Inc. et al., No. 23-cv-10130 — a qui tam action brought by a company insiderunder the False Claims Act’s whistleblower provisions, who received an $851,000share of the settlement. And it was brought under DOJ’s Civil Cyber-Fraud Initiative (launched October 2021), which continues to pursue contractors that misrepresent cybersecurity compliance.

Sources: DOJ press release · Settlement agreement (PDF). This is one settlement, not a claim about typical outcomes.

The takeaway isn’t fear — it’s clarity. MORSE didn’t settle over a missed 72-hour report. It settled over admitted facts tied to DFARS 252.204-7012(c)–(g), NIST SP 800-171 implementation, SSP documentation, and SPRS scoring — including obligations that flow to a cloud provider under (c)–(g). The lesson for incident reporting: report honestly and on time, keep your SPRS score defensible, and make sure the security controls behind your representations actually exist.

If this incident exposed a readiness gap— no credentialed access, no preservation capability, a shaky SPRS score — the right next step depends on what broke. Map the provider category that fits before you start calling vendors: compare provider categories with Find My CMMC Path.

How does DFARS 7012 incident reporting connect to CMMC, NIST 800-171, and SPRS?

Answer: DFARS 252.204-7012 is the safeguarding-and-incident-reporting clause, and it was left unchanged by the February 2026 DFARS reorganization. The assessment clauses around it changed: DFARS 252.204-7019 was deleted and 252.204-7020 was renumbered to 252.240-7997. DFARS 252.204-7021 adds the CMMC certification requirement. CMMC does not replace 7012 — the 72-hour reporting obligation stands regardless— and CMMC Level 2 is assessed against NIST SP 800-171 Revision 2.

Clause	What it obligates	Report or assessment?
DFARS 252.204-7012 (unchanged)	Implement NIST SP 800-171; report cyber incidents within 72 hours; preserve evidence; flow down	Incident reporting + safeguarding
DFARS 252.240-7997 (replaces 252.204-7020 as of Feb 1, 2026; 252.204-7019 deleted)	Government (DCMA DIBCAC) Medium/High NIST SP 800-171 assessment access and SPRS posting	Assessment / SPRS mechanics
DFARS 252.204-7021 (unchanged)	Have and maintain the required CMMC status; complete annual SPRS affirmations; provide CMMC UID information; flow down	CMMC status + affirmation

Sources: DFARS 252.204-7012; DFARS 252.204-7021; DoD class-deviation memo 2026-O0025 (PDF).

7012 still applies, unchanged. The February 1, 2026 class deviation (2026-O0025) reorganized the DFARS cybersecurity clauses — deleting 252.204-7019, renumbering 252.204-7020 to 252.240-7997, and moving FAR 52.204-21 to 52.240-93 — but it made no changes to DFARS 252.204-7012 or 252.204-7021. Because these are class deviations that aren’t yet codified, contractors will see both the legacy numbers (in the Code of Federal Regulations) and the new numbers (in recent solicitations) during the transition. Confirm the exact clause in your specific contract.
A CMMC certification does not satisfy the 72-hour reporting duty, and the reporting duty does not depend on your CMMC status. They are separate obligations.
CMMC Level 2 is assessed against NIST SP 800-171 Rev. 2 — not Rev. 3. Read literally, the codified 7012 clause pulls the current version of NIST SP 800-171 (now Rev. 3), but a DoD class deviation (2024-O0013, May 2024) directs contractors to implement Rev. 2, and CMMC Level 2 is pinned to Rev. 2. Build your Level 2 program to Rev. 2 unless and until DoD amends the rule. See our CMMC Final Rule timeline and 32 CFR Part 170 explainer.
The CMMC timeline is phased. The CMMC Program rule (32 CFR Part 170) took effect December 16, 2024, and the DFARS acquisition rule carrying 252.204-7021 took effect November 10, 2025. Phase 1 runs November 10, 2025 through November 9, 2026 (Level 1 and Level 2 self-assessments); Phase 2 begins November 2026 (third-party assessments expand); Phase 3 begins November 2027; Phase 4 begins November 2028.
A DFARS report doesn’t satisfy every other reporting duty. The clause says its requirements don’t abrogate other obligations you may have — to your prime, your cyber insurer, state breach-notification law, or export-control authorities (DFARS 252.204-7012(l)). One ICF submission is not a universal breach notice.

What your DFARS 7012 incident-response plan needs before an incident

Answer: A DFARS 7012 incident-response plan should do more than say “report within 72 hours.” It should name a submitter and a backup, keep credentialed portal access current, pre-stage your contract-metadata packet, define an evidence-preservation hold, spell out the malware path, set the subcontractor report-number workflow, and be tested with a tabletop that proves your team can act before the clock runs out.

The contractors who hit the deadline calmly are the ones who prepared these eight things in advance:

1A named submitter and a backup submitter— both with working portal access.
2Credential readiness— your medium assurance certificate and/or PIEE account established, current, and on a renewal calendar; confirm the current requirement on DC3’s site.
3A contract-metadata packet— UEI, CAGE, PIIDs, CO and Program Manager contacts, ready to paste.
4An evidence-preservation hold— “image before you remediate,” log retention protected, cloud-export procedure documented.
5A malware path— an EMS account or the DoD SAFE process, and a hard rule never to email malware.
6A subcontractor report-number workflow— who collects it, who sends it up the chain; and any authorized-provider reporting arrangement documented.
7Escalation— counsel, DFIR, MSP/MSSP, and executive decision-makers, with contact paths that work after hours.
8A quarterly tabletop— a realistic scenario on a compressed clock, with at least one curveball (an expired credential, the primary submitter unavailable).

Turn this into a plan: Map your gaps to the right provider category with Find My CMMC Path — it takes your level, scope, environment, and timeline and points you to the category that fits. Do not enter CUI, drawings, malware, or sensitive contract details.

Which provider category fits DFARS 7012 incident-response readiness?

Answer: Active incident response and CMMC assessment are different jobs, and they call for different providers. A live or suspected incident usually points first to a DFIR firm, counsel, and your security-operations support. Readiness gaps point to an RPO/RP, an MSP/MSSP, a GRC platform, or a CUI enclave. A C3PAO performs a Level 2 certification assessment — and only when your contract requires that path and you’re assessment-ready.

Your situation	Category that usually fits	Why this boundary matters	Not the first call
Live or suspected incident, need forensics and containment	DFIR firm + counsel + security operations (often an IR retainer)	Speed, evidence handling, and privilege matter in the first hours	A C3PAO
Reporting readiness — IR plan, credentials, metadata packet, evidence hold	MSP/MSSP or vCISO	These run the log retention, imaging, and security operations that make the 72-hour and 90-day duties achievable	A GRC platform alone
Broader CMMC readiness gaps — SSP, POA&M, scoping, remediation	RPO/RP, MSP/MSSP, or CUI enclave	Readiness and remediation guidance, distinct from formal assessment	A C3PAO doing both remediation and assessment
Evidence, control mapping, continuous compliance operations	GRC platform (a supporting layer)	Software organizes evidence; it does not by itself make you compliant	Treating software as full compliance
Your contract requires CMMC Level 2 (C3PAO) and you’re assessment-ready	Authorized C3PAO	Level 2 certification is a third-party assessment; the assessor must be independent of your remediation	A remediation vendor also assessing the same work
You’re pursuing CMMC Level 3 after a Final Level 2 (C3PAO)	DCMA DIBCAC government assessment	Level 3 adds NIST SP 800-172 requirements and is a government assessment, not a normal C3PAO engagement	Treating Level 3 like a standard Level 2 assessment

This category logic is The CMMC Path Framework— the mapping of your required CMMC level, FCI/CUI handling, assessment type, environment, and timeline to the provider category you need. It routes to a category, not a named provider, and it is not a score, a ranking, or compliance advice. One hard rule worth stating plainly: software alone does not satisfy CMMC, and a firm that remediates your environment generally should not also perform your formal C3PAO assessment where independence rules apply.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

Get matched with Find My CMMC Path →Do not submit CUI, drawings, malware, or sensitive contract details.

What are the most common DFARS 7012 incident reporting mistakes?

Answer: Most reporting failures are operational, not legal-text failures: waiting for perfect forensics, reporting only to the prime, reimaging before preserving evidence, having no credentialed access ready, running an IR plan that still points to DIBNet, using a cloud provider that can’t support the clause, and confusing a CMMC certification with the reporting duty.

Mistake	Why it matters	Prevention
Waiting for root cause before deciding to report	The 72-hour clock runs from discovery, not confirmation	Start the workflow at first credible detection
Reporting only to the prime	The impacted company must report to DoD directly	Report through the ICF portal, then send the number up the chain
Reimaging or restoring before imaging	Destroys evidence you must keep 90 days	“Image before remediate” as a required step
No credentialed portal access	You can’t file through the portal	Establish your certificate and/or PIEE account in advance; track renewals
IR plan still says “DIBNet only”	Points at a redirect, wastes clock	Update to the current DC3/DCISE ICF process
Cloud/SaaS can’t meet 7012(c)–(g)	Creates the exact exposure seen in MORSECORP	Verify FedRAMP Moderate equivalency before you rely on a provider
Emailing malware	Violates DC3 instructions	Use EMS or a DoD SAFE link
Treating a CMMC cert as covering reporting	7012 applies independently	Keep both obligations live in your plan
No follow-on ICF	Initial report is rarely complete	Plan to update as facts develop

What we verified, and how current this page is

Verified on July 3, 2026:

DFARS 252.204-7012 clause text — 72-hour definition, report elements, medium assurance certificate, malware, preservation, flow-down.
DFARS 204.7302 — “a reported incident is not by itself evidence of failure.”
32 CFR 236.4 — mandatory reporting procedures, PIEE-account reference, third-party-provider authorization, 90-day preservation, malware to DC3, subcontractor report number.
DC3 DCISE — current reporting destination, ICF fields, ECA vendors, hotline, malware/EMS process, and subcontractor rule.
DoD class-deviation memo 2026-O0025 (PDF) — February 1, 2026 DFARS renumbering (252.204-7019 deleted, 252.204-7020 → 252.240-7997; 7012 and 7021 unchanged).
NIST SP 800-171 Rev. 2 — current Level 2 baseline.
MORSECORP settlement — DOJ press release and settlement agreement, March 26, 2025.

What could change, and how often we re-check it: the DC3/DCISE reporting portal, ICF fields, and credential instructions (monthly); the clause text, class deviations, and any codification of the Revolutionary FAR Overhaul renumbering (quarterly); the CMMC phase timing and any Rev. 2-to-Rev. 3 transition (quarterly). If DoD updates the reporting portal, we update this page the same day.

Do not submit CUI, drawings, malware, classified information, export-controlled technical data, or sensitive contract details through any Defense Compliance Report form.

See our editorial standards · corrections policy · methodology.

Frequently asked questions about DFARS 7012 incident reporting

What is DFARS 7012 incident reporting?

It is the requirement, under DFARS clause 252.204-7012, that a DoD contractor or subcontractor report a cyber incident to the Department of Defense within 72 hours of discovery when the incident affects covered defense information, the systems that store or process it, or the ability to provide operationally critical support. It also requires preserving evidence for 90 days and submitting isolated malware to DC3.

What starts the 72-hour clock under DFARS 252.204-7012?

Discovery. “Rapidly report” is defined as within 72 hours of discovery of any cyber incident, and discovery means the moment you become aware an incident occurred or may have occurred — not when you finish confirming it. There is no grace period for internal investigation.

Do I report to DIBNet or to DC3/DCISE?

The clause text still lists dibnet.dod.mil, but DC3 now routes mandatory 252.204-7012 reports through its Incident Collection Format portal at icf.dcise.cert.org. Confirm the live destination on the DC3 DCISE site before you file, and update any IR plan that still says DIBNet.

What if we don’t have credentialed portal access?

DC3 says to email DC3.DCISE@us.af.mil or call the DCISE hotline at (410) 981-0104 for assistance. Filing through the portal requires established access — a medium assurance (ECA) certificate and, per a 2024 update to 32 CFR 236.4, a PIEE account — so set that up before an incident rather than during one, and confirm the current requirement on DC3’s site.

Can a vendor or MSSP file the report for us?

The impacted contractor remains responsible for the report, and no company can file an unrelated company’s incident report on its behalf. However, under 32 CFR 236.4(f), a contractor that uses a third-party service provider for security services may authorize that provider to report cyber incidents on its behalf. Document the authorization and keep the report number.

What information is required in the ICF?

DC3 lists 21 elements, including company name, UEI, CAGE code, contract number (PIID), points of contact, impact to CDI, discovery date, type and outcome of the compromise, and an incident narrative. Report what you can within 72 hours and file a follow-on ICF as you learn more.

Can we submit follow-on information after the initial 72-hour report?

Yes. DC3 directs contractors to report what can be obtained within 72 hours and to submit a follow-on ICF if additional information is obtained later. You are not expected to have complete information on the first submission.

What evidence do we preserve, and for how long?

Images of all known affected systems and all relevant monitoring and packet-capture data, for at least 90 days from the date you submit your report, so DoD can request the media or decline interest. Capture forensic images before you remediate.

Do we send malware to the Contracting Officer?

No. Isolated malware goes to DC3, via the EMS portal or a one-time or DoD SAFE link requested from DCISE, never to the Contracting Officer, and never by email.

Do subcontractors report directly to DoD?

Yes. A subcontractor with flow-down obligations reports its own incident directly and provides the DoD-assigned incident report number to the prime or next higher-tier subcontractor as soon as practicable. Telling only the prime does not satisfy the direct-reporting requirement.

Does reporting a cyber incident mean we failed DFARS 7012?

No. DFARS 204.7302 states a reported incident is not, by itself, evidence of a failure to provide adequate security. The Contracting Officer considers it in context. The real exposure comes from not reporting, missing the deadline, or misrepresenting compliance.

Is CMMC incident reporting the same as DFARS 7012 incident reporting?

They’re related but distinct. DFARS 7012 sets the 72-hour reporting obligation. CMMC’s incident-response requirements require you to have and test an incident-handling capability that is evaluated in the applicable CMMC assessment path — a C3PAO assesses it if your contract requires Level 2 (C3PAO); you perform a self-assessment if your contract requires Level 2 (Self). A CMMC status does not satisfy the 72-hour reporting duty, and the reporting duty applies regardless of your CMMC status.

Did the 2026 DFARS changes affect incident reporting?

No. The February 1, 2026 Revolutionary FAR Overhaul class deviation deleted DFARS 252.204-7019 and renumbered 252.204-7020 to 252.240-7997, but it made no changes to DFARS 252.204-7012 or 252.204-7021. The 72-hour incident-reporting obligation is unchanged.

Does NIST SP 800-171 Rev. 3 change DFARS 7012 incident reporting?

Not currently. CMMC Level 2 is assessed against NIST SP 800-171 Rev. 2, and a DoD class deviation directs contractors to implement Rev. 2 even though the codified clause would otherwise pull the current version. Build your Level 2 program to Rev. 2 unless and until DoD amends the rule.

Does a DFARS 7012 report satisfy every other breach-reporting obligation?

No. The clause says its requirements do not abrogate other obligations — to your prime, your cyber insurer, state breach-notification laws, or export-control authorities. Treat the ICF submission as one report among potentially several.

Should we hire a C3PAO after an incident?

Usually not as the first step. A live incident points to DFIR and counsel; readiness gaps point to an RPO/RP, MSP/MSSP, GRC platform, or CUI enclave. A C3PAO performs a Level 2 certification assessment when your contract requires that path and you’re assessment-ready, and its role must stay independent from your remediation.

What should we update in our incident-response plan right now?

Change any “DIBNet” reference to the current DC3/DCISE ICF process, confirm credentialed access for a primary and backup submitter, pre-stage your UEI/CAGE/PIID metadata, add an “image before remediate” step, document the malware path, and run a tabletop.

Need help deciding what type of CMMC or DFARS 7012 readiness provider you need?

Tell us your level, scope, incident-readiness gap, and timeline, and we’ll match you with source-checked provider-category options.

Find My CMMC Path →

Do not submit CUI, drawings, malware, or sensitive contract details.