CUI incident vs cyber incident: what must be reported

What counts as a cyber incident or CUI incident for a contractor handling CUI

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, and the contractor must rapidly report it within 72 hours of discovery. The June 2026 FAR overhaul proposed rule would narrow a CUI incident to unauthorized disclosure, improper modification or destruction of CUI, or unauthorized access to the system holding it. If you are deciding whether an event is reportable, start by reading the clause your contract actually carries, because the definition and the deadline depend on it. Confirm the clause and its version with your contracting officer, and check whether the proposed FAR rule has been finalized before you rely on its narrower test.

Three questions usually decide the answer. First, which clause applies: DFARS 7012 uses a broad definition that includes potentially adverse effects, while the proposed FAR language is narrower and treats unmarked or mismarked CUI as an incident only if it led to one of its listed outcomes. Second, whether the affected data is marked as CUI, since an unmarked file may not trigger the same duty even when it was handled as sensitive. Third, whether the affected system is a covered contractor information system, meaning one that stores, processes or transmits covered defense information. An event on a system outside that boundary may still matter to your SP 800-171 incident handling, but it may not be reportable under the clause. Record each decision in your incident log so the reasoning is available to an assessor.

Your organization owns its incident response and its reporting obligations. DeployOpen can help define the triage criteria, build the incident log and tracking fields that SP 800-171 requirement 03.06.02 expects, and run tabletop exercises that test who decides and who files. DeployOpen does not report to DoD, the contracting officer or CISA on your behalf, and it does not make the reportability determination for you. Ask your counsel and contracts team to sign off on the decision criteria before an event occurs, and confirm who holds the DIBNet medium assurance certificate needed to submit a report to dibnet.dod.mil.

Which definition and deadline applies to which contract

This table compares the incident definitions and reporting deadlines in force today with those in proposed rules, along with where each report goes. Check the status row first, because a proposal does not bind a contract until a final rule or a contract clause adopts it. Confirm the clause your contract actually includes before you plan reporting.

Rule	What triggers a report	Deadline and destination	Status
DFARS 252.204-7012 (cyber incident)	Actions through computer networks that result in compromise, or an actual or potentially adverse effect on an information system or its information, with compromise covering disclosure, modification, destruction, loss or copying to unauthorized media	Rapidly report within 72 hours of discovery to DoD at dibnet.dod.mil	In force in DoD contracts that include the clause
June 2026 FAR overhaul (CUI incident)	Unauthorized disclosure, improper modification or destruction of CUI, or unauthorized access to the system holding it; unmarked or mismarked CUI alone is not an incident	Proposed 72 hours from discovery to dibnet.dod.mil (DoD) or CISA (non-DoD), with notice to the contracting officer and next higher tier contractor	Proposed; not final as of October 2026
January 2025 FAR CUI proposal	Suspected or confirmed CUI incidents, unless a CUI category or federally controlled facility sets a different period	Proposed 8 hours from discovery, with the same category exceptions	Proposed; superseded in part by the June 2026 proposal
HSAR 3052.204-72 (PII or sensitive PII)	Known or suspected incidents involving PII or sensitive PII	1 hour from discovery to the DHS Component SOC or DHS Enterprise SOC	In force in DHS contracts that include the clause (JUL 2023 version)
HSAR 3052.204-72 (all other incidents)	Known or suspected incidents not involving PII or sensitive PII	8 hours from discovery to the DHS Component SOC or DHS Enterprise SOC	In force in DHS contracts that include the clause (JUL 2023 version)
SP 800-171 requirement 03.06.02	Suspected incidents affecting systems that handle CUI, tracked and documented internally	Report within a defined time to the organization's incident response capability, then to organization-defined authorities; the contract sets the external deadline	Current control requirement under Rev. 3; Rev. 2 is the baseline in DoD contracts
Mismarked or unmarked CUI	Information that is not marked as CUI, or is marked incorrectly, with no resulting disclosure, modification, destruction or unauthorized access	No incident report under the June 2026 proposal unless an outcome occurred; reporting such CUI would move to 72 hours	Proposed; confirm with the contracting officer

How the 2026 FAR proposal narrows a CUI incident

The June 2026 FAR overhaul proposed rule would narrow what counts as a CUI incident. Under the proposal, a CUI incident is limited to three outcomes: unauthorized disclosure of CUI, improper modification or destruction of CUI, or unauthorized access to the system holding CUI. Unmarked or mismarked CUI is not an incident unless it led to one of those outcomes. The broader DFARS 252.204-7012 definitions of cyber incident and compromise, which also reach loss and copying to unauthorized media, do not carry over into this proposal. A contractor that treats every marking error as a reportable event will be reporting more than the proposal would require, so the marking review and the incident triage need to be separate decisions.

The proposal also changes the clock and the recipients. It would require reporting a CUI incident within 72 hours of discovery, to dibnet.dod.mil for DoD contracts and to CISA for non-DoD contracts. The contractor would also notify the contracting officer and the next higher tier contractor. Incidents at FedRAMP authorized cloud providers would be reported under FedRAMP procedures instead. Reporting unmarked or mismarked CUI would move to 72 hours as well. Confirm the reporting path in your own contracts and flow-down clauses, because a cloud provider's FedRAMP status does not automatically relieve you of notifying the contracting officer.

The rule was proposed and not final as of October 2026. Until a final rule is published, the clause in your contract governs what you must report and when. Ask the contracting officer which version of DFARS 252.204-7012 or FAR clause is incorporated, and check whether any class deviation changes the reporting terms. Build your incident runbook so that it can be updated quickly once the final text is known, and confirm the current wording of each clause with the contracting officer or your counsel before relying on any summary, including this one.

How unmarked and mismarked CUI changes the reporting duty

Whether a loss of CUI triggers a report, and how fast, depends on how the information was marked and what happened to it. The cards below separate the cases that a proposed FAR rule would treat differently from the cases that remain fully reportable today. Each one ends with a check the contractor can perform before the clock starts.

Unmarked CUI without a harmful outcome

The June 2026 FAR overhaul proposed rule says unmarked CUI is not an incident unless it led to unauthorized disclosure, improper modification or destruction, or unauthorized access to the system holding it. An unmarked file that sits in the right place and is never touched by an unauthorized party therefore does not start a reporting clock under that proposal. Check whether the outcome, not the label, is what happened. Under the current DFARS 252.204-7012 definitions, the analysis is different, so confirm which clause your contract applies before you decide.

Mismarked CUI and the 72-hour track

Mismarked CUI, such as information labeled with a legacy marking or a marking that does not match its category, is handled differently under the proposal. The proposed rule would move reporting of unmarked or mismarked CUI that did not produce one of the defined outcomes to a 72-hour timeframe. Treat a mismarking as a finding to correct and record, and escalate it immediately if the information has also been disclosed or modified. Your marking practice should be verified against the marking requirements before you rely on this track.

CUI the contract did not identify

A contract may not mark or list every CUI category it transmits, and the prime contractor decides what flows down. When your team receives or creates information that looks sensitive but was never identified, the reporting question becomes whether that information was CUI at all. Record the contract language, the prime's guidance and the date you raised the question. Ask the contracting officer or prime to confirm in writing before you treat an event as outside scope.

Documents found in the wrong place

A controlled document discovered on a shared drive, a personal device or a public website is often the first sign of an incident. The key facts are where the file was, who could reach it and whether anyone outside authorized users accessed it. Those facts decide whether the event is an unauthorized disclosure or access, which is reportable under the current clause, or a handling error. Preserve logs and access records before any cleanup so the reporting decision can be reviewed later.

Confirm marking with the prime

Marking questions should go to the prime or contracting officer before a reporting decision is made, not after. Ask which CUI categories apply, which markings the subcontract requires, and whether a specific incident type must be reported to the contracting officer and the next higher tier contractor. Keep the written answer with the incident record. Marking and CUI identification rules are covered in the CUI marking and identification pages in this group.

How NIST SP 800-171 03.06.02 shapes your incident process

Requirement 03.06.02 turns incident handling into a documented sequence: log every incident, route suspicions to an incident response capability within a defined time, report to the right authorities, and give users a named support resource. Each step leaves a record an assessor can check.

Open and log every security incident
Your security staff or the incident response capability opens a record for each suspected or confirmed system security incident, whether or not it later proves to involve CUI. The incident log captures the date and time of discovery, the systems and data affected, who was notified and what was done. Assessors look for a log that is complete, dated and kept current, so ask who owns the log and how entries are reviewed.
Route suspected incidents to the response capability
Staff who notice a suspicious event, such as a lost laptop, a phishing click or unexpected file access, report it to the organizational incident response capability. Requirement 03.06.02 requires that reporting happen within a defined time, so the organization must write that window into its incident response plan. Evidence is the reporting procedure, the intake channel and sample tickets showing reports were logged quickly.
Set the reporting window and authorities in writing
Under Rev. 3, the reporting timeframe and the list of authorities to notify are organization-defined parameters. NIST does not set them, and if the federal agency has not specified values, the nonfederal organization must assign them to complete the requirement. Confirm with the contracting agency or prime contractor whether it has set values, then document the window, the contacts and the criteria for escalation in the incident response plan.
Triage whether the event is a reportable incident
The response team decides whether the event meets the definition in the contract clause or agreement, such as the DFARS cyber incident definition or a narrower CUI incident definition in a proposed rule. Triage notes record the facts used for the decision, the person who made it and the time it was made. Keep these notes even when the answer is no, because an assessor may ask why an event was not reported.
Report to the authorities you documented
Once an incident is confirmed as reportable, the team sends the required information to the authorities named in the contract or plan, such as the DoD reporting portal for DFARS cyber incidents or the agency security office for other contracts. The report, the submission confirmation and any follow-up correspondence are stored with the incident record. Ask counsel and your prime or contracting officer which channels apply to your contract before an incident occurs.
Provide a named incident response support resource
Requirement 03.06.02 also calls for an incident response support resource that advises and assists system users. In practice this is a named help desk, security contact or on-call role that users can reach during and after an incident. Evidence includes the published contact details, the role description and records showing users were advised during past events. Confirm the resource is staffed outside business hours if your contract or agency expects that.
Close the record and feed lessons back
When containment and reporting are complete, the team records the root cause, the corrective actions and the owner of each action in the incident log. Lessons learned update the incident response plan, the training content and the risk register. Assessors typically sample closed incidents to confirm this loop, so ask your team how often closed records are reviewed and by whom.

How the rules differ for DoD, civilian and DHS contracts

Under DFARS 252.204-7012, a prime contractor that discovers a cyber incident must rapidly report it within 72 hours of discovery to the DoD at dibnet.dod.mil. 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 clause also requires the contractor to review for evidence of compromise of covered defense information, which extends the search beyond the first affected system.

Trigger: A compromise includes unauthorized disclosure, modification, destruction or loss of information, or copying information to unauthorized media. Each of these outcomes can start the clock.
Destination: Reports go to dibnet.dod.mil, the DoD portal for defense industrial base incident reporting.
Deadline: The clock runs for 72 hours from discovery, so the internal triage step must be fast enough to leave time for a report.
Review scope: Paragraph (c) of the clause covers compromised computers, servers, data and user accounts, so the review must reach identities and data stores as well as hosts.
Ownership: Your organization decides whether an event meets the definition and files the report. A managed service provider or consultant can prepare the material, but the decision and the filing remain with the contractor.

Check which clause version your contracting officer issued and whether your incident response plan names the person who makes the 72-hour call.

Questions contractors ask about CUI incident reporting

Is a lost file reportable if it was never marked as CUI?

Usually it depends on what happened to the file, not on its marking. Under the June 2026 FAR overhaul proposed rule, unmarked or mismarked CUI is not an incident unless the loss led to unauthorized disclosure, improper modification or destruction of CUI, or unauthorized access to the system holding it. Under DFARS 252.204-7012, the definition of compromise includes unauthorized disclosure, modification, destruction or loss of information, so a lost file that contained covered defense information can still trigger reporting under the clause in effect on your contract. The practical driver is whether the file was covered defense information at all. Confirm with your contracting officer which clause applies, and document the reasoning for any decision not to report.

Does a phishing click count as a cyber incident?

A click alone is not automatically a cyber incident, but it can become one. The DFARS definition covers actions taken through computer networks that result in a compromise or an actual or potentially adverse effect on an information system or its information. If the click led to credential theft, malware execution, or access to systems holding covered defense information, the event meets that test and must be reviewed. Your incident response process should record the click, the investigation steps and the conclusion, even when the conclusion is that no compromise occurred. Under 03.06.02, tracking and documenting security incidents is itself a requirement, so the record matters even for events you decide not to report.

When does the 72-hour reporting clock start?

DFARS 252.204-7012 requires rapid reporting within 72 hours of discovery of a cyber incident. The clock starts at discovery, which is the point at which your organization knows or has reason to believe an incident occurred, so delays in internal triage do not pause it. Build your escalation path so that a suspected incident reaches the person who can make the reporting decision quickly. The June 2026 FAR overhaul proposed rule would also use 72 hours from discovery for CUI incidents, but it is not final. Confirm the discovery trigger and the deadline in the clause in effect, because the wording of the clock and the reporting channel can change between versions.

Must the contractor report an incident at a cloud provider?

It depends on the contract and on the cloud service model. DFARS 252.204-7012 places reporting duties on the contractor, and the clause's cloud provider requirements also apply when a cloud service stores covered defense information. The June 2026 FAR overhaul proposed rule would exclude incidents at FedRAMP authorized cloud providers that are reported under FedRAMP procedures, which means the provider may report instead. Ask your cloud provider how it notifies customers, what its contractual duties are, and whether its FedRAMP authorization level covers your data. Keep the provider's notices as evidence in your own incident file.

What should a team put in place before an incident happens?

Preparation is mostly documentation and rehearsal. Start with an incident response plan that names who decides whether an event is reportable, how discovery is recorded, and who submits to the reporting portal. Confirm your access to the reporting channel and your process for preserving images and logs, since DFARS requires review for evidence of compromise. Train staff to escalate suspicious events quickly, and test the plan with a tabletop exercise. Your system security plan should reference these procedures. Your own documents and the clause in effect determine the exact steps, so confirm them with your contracting officer or legal counsel.

Can DeployOpen report incidents to DoD or DHS for us?

DeployOpen does not report incidents on behalf of a client, and it does not decide whether an event is reportable. Your organization owns its incident response and its reporting obligations. DeployOpen can help plan and implement the logging, monitoring and incident response procedures your team uses, document them, and support testing of the process through security testing and cyber range exercises. Reports are submitted by your organization through the channels the contract specifies, such as dibnet.dod.mil for DoD contracts. Scope and deliverables for any such work are agreed in writing before work starts.

How DeployOpen prepares incident response evidence for your team

DeployOpen helps organizations prepare the systems, logs, procedures and records that show how a potential CUI incident or cyber incident was detected, classified and reported. The organization owns its incident response decisions and reporting obligations, and an independent assessor reviews the evidence.

How we scope

Engagements are fixed-scope, with the incident categories, systems and contracts covered agreed in writing before work starts.
Scope names which events count as reportable for your contracts, such as cyber incidents, compromises and suspected CUI incidents.
Scope confirms which reporting deadlines apply to each contract and who in your organization owns each reporting decision.

How we build

We configure logging and alerting in your environment so incident records capture the detection, triage and escalation steps you need.
We draft or adapt incident classification criteria and reporting procedures that map each event type to a documented response path.
We test the procedures through tabletop exercises so staff can show how a suspected incident moves from discovery to reporting.

How we hand over

You receive the written procedures, classification criteria, logging configuration records and exercise reports as documented deliverables.
Incident tracking templates and reporting checklists are delivered in formats your team can maintain and audit.
We walk your staff through how each record supports the evidence an assessor will ask to see, including reporting timestamps.

How we support

Ongoing support is available as a retainer for updates when contract clauses or federal rules on incident reporting change.
Retainers can cover periodic exercises, review of new incident records and adjustments to reporting paths as your contracts change.
Confirm with your contracting officer or counsel which current rule governs each contract before relying on any reporting deadline.

What counts as a CUI incident or cyber incident

What counts as a cyber incident or CUI incident for a contractor handling CUI

Which definition and deadline applies to which contract

How the 2026 FAR proposal narrows a CUI incident

How unmarked and mismarked CUI changes the reporting duty

Unmarked CUI without a harmful outcome

Mismarked CUI and the 72-hour track

CUI the contract did not identify

Documents found in the wrong place

Confirm marking with the prime

How NIST SP 800-171 03.06.02 shapes your incident process

Open and log every security incident

Route suspected incidents to the response capability

Set the reporting window and authorities in writing

Triage whether the event is a reportable incident

Report to the authorities you documented

Provide a named incident response support resource

Close the record and feed lessons back