DFARS 7012 cyber incident reporting: the 72-hour rule explained

How the DFARS 7012 72-hour rule works for your contract

If your DoD contract or subcontract carries DFARS 252.204-7012, a cyber incident must be reviewed for evidence of compromise and reported to DIBNet within 72 hours of discovery. Reporting requires a DoD-approved medium assurance certificate, so the certificate has to be in hand before an incident occurs, not obtained during one. People searching for DFARS 7012 incident reporting are usually at this point: they have found the clock, and now need to know who starts it, who decides what counts, and what they must have ready. The organization owns its incident response, and DeployOpen does not report incidents on its behalf. The clock, the content of the report and the evidence you preserve depend on your own systems, your contracts and your incident definitions. Confirm with your contracting officer and prime which contracts in your portfolio carry the clause, which systems hold covered defense information, and where your incident response plan records the moment of discovery. Then test whether your monitoring, ticketing and escalation paths would let a security analyst recognize a reportable event and start the review inside the same working day.

The review itself is where most gaps appear. Your team needs to check computers, servers, data stores and user accounts for signs of compromise, and the DFARS definition of compromise includes copying information to unauthorized media, not only intrusion. Document each step with timestamps, because the discovery time anchors the 72-hour window. Confirm with your own counsel and contracting team what counts as a reportable cyber incident for each contract, since the answer determines whether the clock is running at all. Your incident handling capability should also record what your organization has defined for the parameters of NIST SP 800-171 requirement 03.06.02, including the time limit for reporting suspected incidents internally and the authorities that receive incident information. For subcontractors, the same review feeds two obligations: reporting to DoD and giving the prime the DoD-assigned incident report number as soon as practicable. Ask your primes now how they expect that number to arrive and who owns the handoff. Keep in mind that DFARS 252.204-7012 does not replace other reporting duties under other clauses, statutes or regulations, so a single incident can trigger several notices. Build a register that lists each contract, its reporting authority and its deadline, and rehearse the sequence with the people who would need to act.

What happens from discovery to the DIBNet report

This sequence turns a suspected intrusion into a documented, timely report to DoD, with each step leaving a record that the contractor can show later. The 72-hour window under DFARS 252.204-7012 starts at discovery, so the steps below should run in parallel with containment rather than after it.

Detect and record the discovery
Security monitoring, a user, a vendor or a partner flags unusual activity on a system that handles covered defense information. The security team opens a ticket that records what was seen, which system is involved, who was told and the time of discovery. That timestamp matters because the 72-hour window in DFARS 252.204-7012 runs from discovery of any cyber incident. Confirm with counsel and your contracts team which internal time standard you will use to establish discovery, and write it into your incident response plan before you need it.
Contain the activity and preserve evidence
The incident response team limits further damage, for example by isolating a host or disabling a compromised account, while keeping volatile data, logs and affected systems intact for later review. Containment steps are logged with their times. The output is a preserved evidence set and a short timeline. Preservation later supports the malware submission and media preservation duties that follow a report, so coordinate with the people who hold those duties in your contract.
Review for evidence of compromise
Paragraph (c) of the clause requires the contractor to review for evidence of compromise of covered defense information. The review checks computers, servers, data repositories and user accounts that were in the affected environment. The analyst asks whether unauthorized disclosure, modification, destruction, loss or copying to unauthorized media may have occurred. The output is a written compromise determination that names the systems and data reviewed, the evidence considered and the reviewer. Record the reasons for a negative finding as carefully as a positive one.
Decide to report and notify the right people
Based on the compromise review, the accountable officer decides whether the event is a reportable cyber incident and records the decision with its rationale. Legal, the contracts lead and the security lead should be told at this point. If the contractor is a subcontractor, the prime or next higher tier must be notified as well. The output is a signed decision record. Do not let the decision process consume the 72-hour window; agree on who decides and how fast before an incident happens.
Obtain the medium assurance certificate
Paragraph (c)(3) requires a DoD-approved medium assurance certificate to report cyber incidents. Public guidance on obtaining one is at the public.cyber.mil ECA page linked from the clause. Certificate issuance is handled outside the incident itself, so the contractor should confirm it holds a valid certificate, and the people authorized to use it, before any incident occurs. The output is a verified certificate on a named reporting workstation, with its expiry date tracked. Confirm the current process with the certificate provider and DoD guidance, since the steps are not part of this page.
Submit the report at DIBNet
The authorized reporter logs in to dibnet.dod.mil with the medium assurance certificate and submits the cyber incident report. The report must include at least the elements listed on the DIBNet site, which may change, so check the current list before submission. Under paragraph (c)(2), the report is treated as information created by or for DoD. The output is a submitted report and a confirmation record. Submit with the facts you have, and file updates as the investigation proceeds rather than holding the report until the investigation is complete.
Record the DoD-assigned incident report number
After reporting, DoD assigns an incident report number. Paragraph (m)(2) requires subcontractors to give that number to the prime as soon as practicable, and the prime should record it against the incident file. The output is the number stored in the incident record, shared with the contracting team and any affected prime or subcontractor. Keep the report, the number and the compromise review together, because the file is what you will show an assessor or contracting officer if questions come later.

What counts as a cyber incident and what counts as compromise

Under DFARS 252.204-7012, a cyber incident is an action taken through computer networks that results in a compromise, or an actual or potentially adverse effect on an information system or the information in it. The definition is broad on purpose. It does not require proof that an attacker stole data, and it does not require a confirmed breach. An event that could adversely affect a system holding covered defense information can qualify, so the trigger is the event itself rather than a finding that the event caused harm. The 72-hour clock described in the clause starts from discovery of a cyber incident, which makes it important to know when your organization can say it discovered one.

The clause defines *compromise* to include disclosure, modification, destruction or loss of information that is not authorized, and copying information to unauthorized media. Each part is a test you can apply to an event. A misdirected email with CUI attached is a disclosure. A ransomware encryption event that makes files unavailable is a destruction or loss. Copying a CUI repository to a personal USB drive is copying to unauthorized media, even if no outsider ever sees it. Your incident procedures should translate these four categories into plain examples that help engineers and help desk staff recognize them, because most incidents first appear as ordinary technical alerts.

Under paragraph (c), the contractor must review for evidence of compromise of covered defense information, including compromised computers, servers, data and user accounts. The organization makes that determination, not the Government, so the decision needs an owner, a documented method and a record. Write down what was reviewed, when the review started and finished, who made the call and the reasoning, including events you concluded were not compromises. Confirm with your contracting officer and counsel how to handle an event you cannot rule out within the time available, because the clause ties the report to discovery and a documented review is the evidence that your timing was sound.

Certificate, report content, subcontractors and other duties

Filing a DFARS 7012 report is more than submitting a form within 72 hours. The contractor needs a working credential to log in, a complete set of report elements, a clear path for subcontractors to pass along the DoD incident report number, and a check that other reporting obligations still apply.

Medium assurance certificate for DIBNet

Paragraph (c)(3) requires the contractor or subcontractor to have or acquire a DoD-approved medium assurance certificate before it can report a cyber incident. The certificate is the identity credential used to access DIBNet, so it must be in place before an incident occurs, not requested during one. Start the application through the External Certification Authority route at public.cyber.mil/eca, confirm who in the organization holds the credential, and test the login during a tabletop exercise so the 72-hour clock is not spent on paperwork.

Required report elements

The cyber incident report must include at least the elements listed at dibnet.dod.mil. Under paragraph (c)(2), the report is treated as information created by or for DoD, so the contractor should draft its internal incident record against the current element list rather than from memory. Keep a template that maps each element to a field in the ticketing or incident response system, and confirm the list again each time the clause or DIBNet changes.

Subcontractor report numbers to primes

Under paragraph (m)(2), a subcontractor that reports a cyber incident must give the prime, or the next higher tier subcontractor, the DoD-assigned incident report number as soon as practicable. Without that number, the prime cannot tie the event to its own contract records or reporting. Flow-down agreements should name who sends the number, through which channel, and how quickly, so the number does not sit unsent in a subcontractor's inbox.

Other reporting duties still apply

Paragraph (l) states that safeguarding and cyber incident reporting under this clause do not relieve the contractor of other safeguarding or incident reporting required by other contract clauses, statutes or regulations. A DFARS 7012 report therefore does not close out obligations under other clauses, privacy laws or sector rules. Map each contract and regulatory notification path before an incident, assign an owner for each, and record which notices were sent and when.

Which reporting route applies to your contract

If your contract includes DFARS 252.204-7012, the clause sets the reporting rule. When you discover a cyber incident that affects covered defense information or the systems that store, process or transmit it, you must report to DoD through DIBNet within 72 hours of discovery. The clock starts at discovery, so begin the review for evidence of compromise as soon as an event is identified, without waiting for a complete investigation.

Reporting channel: File through DIBNet, the DoD portal the clause names for cyber incident reports.
Certificate first: You need a DoD-approved medium assurance certificate before you can report. Obtaining one takes lead time, so confirm your certificate is current before an incident occurs.
Required elements: The report must include at least the data elements listed on DIBNet. Build a fill-in template so the security team can complete it quickly.
Other duties continue: The clause does not relieve you of reporting required by other contract clauses, statutes or regulations, so check your other agreements for separate deadlines.
Compromise review: Document the review for compromised computers, servers, data and user accounts, since the report depends on it.

Confirm with your contracts team which clause date and version your contract incorporates, and verify your certificate status with your security lead.

How NIST SP 800-171 requirement 03.06.02 supports the 72-hour clock

Requirement 03.06.02 in NIST SP 800-171 Rev. 3 is the place where your internal incident handling meets the external reporting duty. It asks you to track and report incidents, and it leaves two values for the organization or the agency to define: the time period within which suspected incidents must be reported to your organizational incident response capability, and the authorities to whom incident information must be reported. Under DFARS 252.204-7012, the outer limit is fixed at 72 hours from discovery to DIBNet, but the internal window that sits inside it is not. Confirm both ODP values in the contract or agreement before you write the procedure, because a federal agency that does not specify them leaves the nonfederal organization to assign them, and an internal window set too loosely will consume the 72 hours before anyone with reporting authority has seen the incident.

Practically, the internal window should be set so that an analyst who sees a suspicious event can escalate it to the incident response lead, the lead can decide whether the review for evidence of compromise is triggered, and someone holding a DoD-approved medium assurance certificate can file the report in time. Document who the reporting authorities are, including the DoD channel and any other authority the contract names, and make sure the named people are the ones who can actually act on a weekend or overnight. Ask your contracting officer or prime whether they expect notification of suspected incidents earlier than discovery of a confirmed cyber incident, since that expectation changes the trigger you write into the plan.

An assessor testing 03.06.02 will look for the defined ODP values, a written incident response plan that carries them, and evidence that the plan is used. Expect to show the approved plan with the parameter values visible, the escalation path with named roles, and records of past incidents or exercises that show the time from detection to escalation and to the reporting decision. Tabletop exercises with dated notes, after-action reports and any tickets that show escalations handled within the defined window are the evidence types to prepare. The assessor's findings depend on your actual records and the scope of your system, so treat the outcome as unknown until your own evidence has been reviewed by the assessor.

Questions buyers ask about DFARS 7012 incident reporting

Does every cyber incident require a DIBNet report under DFARS 7012?

No, not every event is reportable. The clause defines a cyber incident as actions taken through computer networks that result in a compromise or an actual or potentially adverse effect on an information system or its information. The duty starts when you discover a cyber incident, and you then review for evidence of compromise of covered defense information, including compromised computers, servers, data and user accounts. If you find compromise or potential adverse effect, the report is due within 72 hours of discovery. Document your review decisions either way, because the assessor and the contracting officer will ask how you decided. Confirm your triage criteria with your contracting officer and counsel before an incident happens.

How long does a DoD medium assurance certificate take, and who pays for it?

Timing and cost depend on the External Certification Authority process and your sponsor, not on DeployOpen. DFARS 252.204-7012(c)(3) requires a DoD-approved medium assurance certificate before you can report, and the clause points to public.cyber.mil/eca for how to obtain one. Ask the certificate provider which identity-proofing steps apply to your organization, who must sponsor the request, what the fees are and whether they recur on renewal. Plan the request before you need it, because a missing certificate can block a report inside a 72-hour window. Confirm each of these points directly with the provider and your sponsor.

Can an implementation partner file the DIBNet report for us?

The report must be made by the contractor or subcontractor, using its own medium assurance certificate, so the filing and the certificate should stay in your organization. A partner can prepare what the report needs: a log timeline, affected system inventory, a compromise review checklist and an incident runbook that names who decides. DeployOpen supports this kind of preparation on self-hosted platforms inside your own environment. Clarify in writing which steps the partner performs and which your staff performs, and confirm with your contracting officer how the report should be submitted.

What does preparing for incident reporting cost, and what drives it?

Preparation costs come from three areas: the internal time to write and test the incident response plan, the tooling that captures evidence such as centralized logs and endpoint telemetry, and any outside help you buy. Costs rise with the number of systems that handle covered defense information, the maturity of existing logging, the number of subcontractors who must report to you, and how many tabletop exercises you run. Most of the work is one-time (plan, runbooks, log configuration), while testing and log retention recur. Ask any provider for a written scope listing deliverables, systems covered and who performs each step before accepting a quote.

Do non-DoD contracts need a separate incident reporting process?

Yes, you should plan for a separate path. The DFARS 7012 rule applies to DoD contracts, and the June 2026 FAR overhaul proposed rule would have required reporting CUI incidents within 72 hours to dibnet.dod.mil for DoD contracts and to CISA for non-DoD contracts, with notice to the contracting officer and the next higher tier contractor. That rule was not final as of October 2026, so confirm the current requirement in the contract and with the contracting officer. Also note that DFARS 7012(l) keeps other reporting duties in force, so a single incident may trigger several notifications. Build your runbook to route by contract type.

What does the assessor look for in 03.06.02 on incident reporting?

The assessor checks whether you have defined the reporting time period and the authorities that receive incident information, and whether your process meets both. NIST SP 800-171 Rev. 3 requirement 03.06.02 has two organization-defined parameters: the time period to report suspected incidents to the organizational incident response capability, and the authorities to whom incident information is reported. Under SP 800-171A Rev. 3, the assessor examines the documented values and interviews staff who perform reporting, then looks for evidence such as tickets, timestamps and report records. Assign the parameter values in writing, since NIST does not assign them and the nonfederal organization must do so when the agency does not. Confirm the values with the contracting agency.

Who owns the report and who prepares the evidence

The contractor owns its incident response and the report submission under DFARS 252.204-7012. The obligation to review for evidence of compromise, report to DoD at dibnet.dod.mil within 72 hours of discovery, and hold the medium assurance certificate sits with the contractor or subcontractor that holds the contract, not with any outside firm. An implementation partner such as DeployOpen can help plan that process before an incident: deciding who makes the compromise call, who speaks to the contracting officer and the prime, and how the 72-hour clock is recorded from the point of discovery. Confirm internally who is authorized to file the report and who holds the certificate, because a lapsed certificate or an unnamed owner is the kind of gap that surfaces only during an incident.

DeployOpen can also prepare the material that the contractor will rely on when it reports. That includes centralized logging that captures the events needed to establish compromise, runbooks for the review of computers, servers, data and user accounts, a template that gathers the required report elements, and records that tie each step to the incident response requirements in NIST SP 800-171 Rev. 3, including 03.06.02. The ODP values for the reporting time period and the authorities to receive incident information should be set in writing and tested. Tabletop or technical exercises can rehearse the process with the people who will actually file. Ask any partner to show how these deliverables are documented and handed over, since the contractor must be able to run the process without the partner present.

Compliance itself is judged by others. DoD and the federal agency that holds the contract determine how contractor compliance is verified, and independent assessors, not DeployOpen, evaluate whether the controls and evidence meet the requirements. DeployOpen does not issue reports, certificates or attestations, and an exercise or readiness review is not an assessment result. Before engaging a partner, ask for a written scope that names each deliverable, the person who will own it after handover, and what the partner will not do, such as file a DIBNet report on the contractor's behalf or represent the contractor in a DoD review.

How DeployOpen prepares incident reporting readiness

DeployOpen helps organizations prepare the systems, logging, procedures and records that a DFARS 7012 incident report depends on. The organization owns its incident response obligations and its report to DIBNet, and DeployOpen does not file reports or make compromise determinations on its behalf.

How we scope

Engagements are fixed-scope, with the systems, incident response processes and reporting steps agreed in writing before work starts.
The written scope names which systems hold covered defense information and which logs feed the compromise review.
The scope states who on the client side owns the review decision, the DIBNet submission and the medium assurance certificate.

How we build

Logging and alerting are configured on the in-scope self-hosted platforms so the compromise review has records to examine.
The incident response plan is written to match the client's roles, escalation path and the 72-hour clock from discovery.
Reporting checklists list the required report elements so the team can gather them quickly during an incident.

How we hand over

Deliverables include configuration records, the written procedures and evidence that the logging and response steps work.
Handover covers how to run a tabletop exercise of the reporting steps, with the outputs recorded for the assessor.
Documentation states which steps remain with the organization, its subcontractors and its cloud provider.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover log review, procedure updates and periodic exercises as systems change.
Ask the auditor or DoD contracting officer which evidence they expect before the written scope is signed.

DFARS 7012 cyber incident reporting: the 72-hour rule

How the DFARS 7012 72-hour rule works for your contract

What happens from discovery to the DIBNet report

Detect and record the discovery

Contain the activity and preserve evidence

Review for evidence of compromise

Decide to report and notify the right people

Obtain the medium assurance certificate

Submit the report at DIBNet

Record the DoD-assigned incident report number