A cyber incident involving a Department of Defense contractor or subcontractor requires two processes to begin at the same time. The organization must respond technically to the threat while also determining whether contractual or regulatory reporting requirements apply. A good DFARS cyber incident response does not begin by assuming that data was stolen. It begins by establishing facts, stopping continued unauthorized activity, preserving evidence, determining what systems and information were involved, and making reporting decisions before applicable deadlines expire.
| If This Happens | What the Organization Should Do |
|---|---|
| A security alert occurs | Investigate it and determine whether an actual security event or cyber incident occurred. |
| Unauthorized or malicious activity is confirmed | Begin the incident-response process. |
| A cyber incident affects, or may have affected, a system that handles CDI | Verify the applicable contract and evaluate DFARS reporting immediately. |
| Reporting applicability is uncertain | Escalate quickly and seek authoritative guidance before the reporting window expires. |
| Reporting is required | Submit the initial report before the deadline. |
| The threat has been contained | Continue evidence preservation, investigation, recovery, validation, and follow-up reporting when applicable. |
Key Point
A cyber incident does not automatically mean Controlled Unclassified Information was stolen, the organization failed CMMC, or its cybersecurity protections failed. Incident response is the process of containing the event, preserving evidence, determining what was affected, meeting applicable obligations, recovering safely, and improving the environment afterward.
Reference Note: This article is educational guidance. The current contract or subcontract, applicable DFARS clauses, CMMC requirements, System Security Plan, incident-response plan, actual system configuration, legal and export-control requirements, insurance policy, and current government guidance remain the source of truth.
The goal is not to prove immediately that nothing happened. The goal is to act quickly, preserve reliable evidence, understand the scope, meet applicable obligations, and make decisions based on confirmed facts.
Several terms are commonly grouped together during cybersecurity discussions. They do not mean the same thing, and the distinction matters when determining which requirements apply.
| Term | Why It Matters |
|---|---|
| Federal Contract Information (FCI) | Nonpublic information provided by or generated for the Government under a federal contract. FCI is relevant to federal safeguarding requirements and CMMC Level 1. |
| Controlled Unclassified Information (CUI) | Unclassified information that requires safeguarding or dissemination controls under applicable law, regulation, or Government-wide policy. |
| Covered Defense Information (CDI) | The DFARS 252.204-7012 term for certain unclassified controlled technical information or other CUI that requires safeguarding or dissemination controls and has the required connection to DoD contract performance. |
| ITAR/EAR-Controlled Information | Export-controlled information that may create separate legal or contractual responsibilities. It is not interchangeable with FCI, CUI, or CDI. |
For DFARS 252.204-7012 incident reporting, two of the most important concepts are Covered Defense Information (CDI) and the systems that process, store, or transmit it.
CDI is a specific DFARS term. It includes qualifying controlled technical information and other qualifying information described in the CUI Registry when the information meets the contract-related criteria established by the clause. Not every piece of CUI is automatically CDI under every DoD contract.
A covered contractor information system is an unclassified information system owned, or operated by or for, a contractor that processes, stores, or transmits CDI.
See DFARS 252.204-7012 for the complete definitions and contract-performance criteria.
Modern cybersecurity systems generate alerts for many reasons. An alert may identify malicious activity, suspicious behavior, a configuration issue, a false positive, or something that simply requires additional investigation.
Operationally, it is useful to separate an alert from a confirmed incident:
The first two terms above are operational concepts used for triage. They are not being presented as special legal definitions under DFARS. DFARS defines a cyber incident as actions taken through the use of computer networks that result in a compromise or an actual or potentially adverse effect on an information system or the information residing within it.
An Alert Is Not Automatically Reportable
A failed login, blocked phishing message, antivirus detection, or other security alert does not automatically require a DoD cyber incident report. The event should first be investigated and classified. Once an actual cyber incident is discovered, applicable reporting obligations should be evaluated without unnecessary delay.
Check the applicable contract or subcontract as early as practical while the technical response continues. Confirm whether DFARS 252.204-7012 applies and identify any additional reporting requirements. Review the contract, subcontract, purchase order, incorporated clauses, supplier terms, and cybersecurity addenda. For subcontractors, identify the prime contractor or next higher-tier subcontractor connected to the affected work. Do not delay urgent containment or an approaching reporting deadline while locating contract documentation.
CMMC status, possession of CUI, and DFARS 252.204-7012 are related concepts, but they are not interchangeable.
Under DFARS 252.204-7012, the reporting question begins when the contractor discovers a cyber incident that affects:
Operationally critical support is a defined DFARS term and should not be interpreted as simply meaning any important contract work or business interruption. The applicable contract must identify the operationally critical support requirement. DFARS defines rapidly report as reporting within 72 hours of discovery of a cyber incident. This does not mean every successful unauthorized login is automatically reportable. The affected system, available information, access paths, applicable contract, and investigative evidence still need to be evaluated.
| Question | Why It Matters |
|---|---|
| Did the incident affect a covered contractor information system? | This can trigger DFARS reporting. |
| Did it affect CDI residing within that system? | This can trigger DFARS reporting. |
| Did it affect required operationally critical support? | This is another DFARS reporting trigger. |
| Is the affected system clearly outside the covered environment? | The incident may fall outside mandatory DFARS 252.204-7012 reporting, depending on the facts and other contractual requirements. |
| Is the answer still uncertain? | Escalate the reporting question before the 72-hour period expires. |
Exfiltration Is Not the Only Test
DFARS reporting does not depend only on proving that files were downloaded or stolen. The clause also considers whether a covered contractor information system or CDI residing within it was affected.
The first 72 hours should be treated as a coordinated technical and compliance process. Several activities will normally happen at the same time. A company should not wait until containment is complete before considering evidence preservation. It also should not wait for a final forensic report before beginning the reporting evaluation.
| Stage | Primary Goal |
|---|---|
| Detect | Establish what happened and when it was discovered. |
| Contain | Stop continued unauthorized activity. |
| Preserve | Protect evidence before it is changed, overwritten, or destroyed. |
| Scope | Determine which identities, systems, information, and contracts may be involved. |
| Evaluate / Report | Determine the reporting path before the deadline. |
Start by recording the facts that are known. Important timestamps can include when suspicious activity occurred, when the organization became aware of the incident, who or what detected it, when investigation began, and when containment actions occurred. Attack time and discovery time are not always the same. An attacker may have acted before the organization detected the incident. For an incident subject to the clause’s reporting requirement, DFARS defines rapid reporting as within 72 hours of discovery.
Preserve original security-system timestamps whenever possible. Document timezone conversions or later corrections separately so the original evidence remains clear.
Create a central incident record as early as practical. Track discovery time, affected systems and users, containment actions, evidence collected, decisions, external communications, and assigned report numbers. This is an incident-response best practice, not a separate DFARS requirement.
Containment is intended to stop continued unauthorized activity while allowing the investigation to continue. Depending on the incident, containment may include disabling a compromised identity, revoking active sessions or tokens, isolating a potentially affected endpoint, blocking malicious infrastructure, disabling unauthorized applications, or restricting access to affected systems. A password reset may be necessary during an identity incident, but investigators may also need to review active sessions, authentication methods, device registrations, application permissions, and other potential persistence mechanisms. Do not delay urgent containment while waiting to build a perfect evidence package. Stop active unauthorized access first using the least destructive reasonable method, document what was changed, and preserve remaining evidence as soon as practical.
Contain Without Unnecessarily Destroying Evidence
Containment and evidence destruction are not the same thing. Reimaging a computer, deleting browser data, clearing logs, removing files, or resetting systems may eliminate information needed to determine what happened.
Evidence preservation should begin early. Relevant evidence may include security alerts, incident reports, sign-in logs, audit logs, suspicious emails, attachments, browser artifacts, endpoint information, network-security logs, remediation timestamps, and system images when required or appropriate.
For a cyber incident subject to DFARS 252.204-7012, the contractor must preserve and protect images of all known affected information systems identified through the required incident review, along with relevant monitoring or packet-capture data, for at least 90 days from submission of the cyber incident report.
This does not mean every computer that had some connection to an incident automatically requires a forensic image. The required review includes covered systems that were part of the incident and other systems on the contractor’s networks that may have been accessed as a result of the incident. A normal recovery backup should not automatically be treated as a forensic image. Backups are primarily designed for recovery. Forensic acquisition is intended to preserve investigative evidence and data integrity.
Scoping answers one central question: What could the incident actually reach or affect?
The investigation should consider:
DFARS specifically requires a review for evidence of compromise of CDI. The clause identifies compromised computers, servers, specific data, and user accounts as examples. The review also extends to other information systems on the contractor’s networks that may have been accessed because of the incident.
Organizations may intentionally restrict CUI or CDI to a defined security environment or enclave. Proper separation can reduce the systems that process, store, or transmit CUI and can limit the potential reach of an incident.
However, CMMC scope is broader than only the systems that directly contain CUI. Security Protection Assets and other applicable assets may remain within the assessment scope based on the functions they provide. See the DoD CMMC Level 2 Scoping Guide for current scoping guidance.
A written policy stating that CUI belongs in a secure environment does not prove that controlled information has never existed somewhere else. Actual use must also be reviewed.
During an incident, this may include determining whether historical CUI or CDI remained in ordinary email, local downloads, shared folders, cloud storage, endpoints, or other systems outside the intended enclave.
Shared Responsibility
The IT or cybersecurity team can document systems, authentication paths, technical access, logs, and security controls. Client leadership and compliance personnel must also confirm where controlled information is actually received, created, stored, transmitted, and used.
Cyber investigations develop over time. Conclusions should reflect the evidence available at that moment.
| Avoid | Prefer |
|---|---|
| Nothing happened. | No additional unauthorized activity has been identified as of [date/time] |
| No data was stolen. | No evidence of data exfiltration has been identified as of [date/time] |
| The computer was clean. | No evidence of endpoint compromise was identified in the evidence reviewed. |
| CUI was safe. | No evidence of unauthorized access to the reviewed CUI environment has been identified. |
This language does not weaken a conclusion. It makes the conclusion more precise and easier to defend. The goal is to clearly distinguish among confirmed, not observed, unknown, and not applicable.
Some incidents cannot be fully classified during the first few hours. The organization may know that an account or system was compromised while still investigating whether CDI, a covered contractor information system, or operationally critical support was affected.
Do not use the 72-hour reporting period simply to try to prove that the incident was harmless.
Review the applicable contract, affected systems, information locations, access paths, and available evidence immediately. If the reporting question cannot be resolved promptly, escalate it to the appropriate compliance, legal, contracting, or DCISE resources while the technical investigation continues.
Current DCISE cyber incident reporting guidance allows contractors to provide the information available within the initial reporting period and provide additional information through follow-on reporting as the investigation develops.
The Initial Report Does Not Require a Finished Forensic Investigation
Incident reporting and forensic investigation can continue in parallel. Report what is known when required. Clearly identify what remains unknown or under investigation. Additional information can be provided as the investigation develops.
A DoD-approved Medium Assurance Certificate is required for the normal secure DCISE reporting process. If the organization does not yet have the required certificate and needs to report an incident, do not wait for the certificate process to finish. Current DCISE guidance instructs organizations in this situation to contact DCISE for reporting assistance at DC3.DCISE@us.af.mil or 410-981-0104.
Follow the Reporting Instructions DCISE Gives You
Contacting DCISE for assistance and formally submitting the report are not necessarily the same step. Follow the instructions provided by DCISE for the specific situation and preserve documentation showing when the reporting process was initiated.
Cyber incident response is a shared process, but the responsibilities are not interchangeable.
| Role | Primary Responsibility |
|---|---|
| Contractor or subcontractor | Owns the business, contractual, and reporting obligations. |
| Internal IT or MSP/MSSP | Investigates, contains, preserves evidence, documents technical findings, and supports the reporting process. |
| Client leadership | Provides authorization, business context, contract information, and organizational decisions. |
| Compliance personnel | Evaluate applicable contractual and regulatory requirements and maintain compliance documentation. |
| Legal counsel | Advises on legal interpretation, privilege, notification, and disclosure obligations. |
| Export-control personnel | Evaluate ITAR or EAR implications when applicable. |
| Prime or higher-tier contractor | May have separate contractual notification requirements and may need the DoD-assigned incident report number. |
An MSP, MSSP, consultant, or outsourced IT department can perform substantial work during the incident. This may include investigation, containment, evidence preservation, documentation, contacting DCISE for assistance, preparing reporting information, and coordinating communications with the client. However, the impacted contractor or subcontractor retains its contractual reporting responsibility. Current DCISE guidance states that a third party cannot submit the impacted company’s mandatory ICF on its behalf. The practical distinction is simple: the service provider can help run the process, but the impacted company owns the report.
DFARS 252.204-7012 contains a flow-down requirement for subcontracts involving operationally critical support or subcontract performance involving CDI. Identify the prime contractor or next higher-tier subcontractor connected to the affected contract early in the incident. Review the subcontract for any separate notification deadline. When a subcontractor submits a required cyber incident report to DoD, DFARS requires the subcontractor to provide the DoD-assigned incident report number to the prime contractor or next higher-tier subcontractor as soon as practicable. The subcontract may require an earlier or additional notification. Do not assume every subcontract uses the same reporting process.
No. A cyber incident can occur even when cybersecurity controls are operating. DFARS policy specifically states that a reported cyber incident, by itself, should not be interpreted as evidence that the contractor or subcontractor failed to provide adequate security or otherwise failed DFARS 252.204-7012. See DFARS 204.7302. An incident may still reveal an actual control implementation problem, incorrect scope, configuration drift, outdated documentation, or a difference between documented policy and actual system use. Those findings should be evaluated based on evidence.
Do not change a CMMC assessment result or create a Plan of Action and Milestones solely because an attack occurred. If the investigation establishes that a required practice was not implemented as assessed, the affected compliance records should be reevaluated based on that evidence. CMMC requirements can also change independently of the DFARS incident-reporting clause. Use the current DoD CMMC Resources and Documentation when evaluating CMMC requirements for a specific contract.
DFARS reporting may be only one part of the organization’s responsibility.
If ITAR or EAR-controlled information may be involved, involve the organization’s export-control personnel and qualified legal counsel. The determination depends on the information involved, who could access it, applicable authorizations, and the protections in place.
DFARS 252.204-7012 does not remove other applicable safeguarding or reporting responsibilities.
This article was developed using primary government sources and recognized federal cybersecurity guidance. Direct source material should always take precedence when determining requirements for a specific organization, contract, or incident.
No. Security tools routinely generate alerts that require investigation. A failed login, blocked phishing email, antivirus detection, or suspicious event is not automatically a DFARS-reportable cyber incident. The organization should investigate the alert, determine what occurred, and then evaluate whether the DFARS reporting criteria apply.
No. A successful unauthorized login may be evidence of a cyber incident and should be investigated immediately. DFARS reporting depends on whether the resulting cyber incident affects a covered contractor information system, CDI residing within that system, or operationally critical support identified in the contract. The organization should determine what the compromised identity or system could access and what systems or information were affected.
No. Confirmed exfiltration is not the only reporting consideration. DFARS also considers whether the cyber incident affected a covered contractor information system or CDI residing within that system.
DFARS defines rapidly report as within 72 hours of discovery of a cyber incident. The attack may have begun before the organization discovered it. Record both the attack timeline and the discovery timeline when they are known.
Do not wait for a perfect forensic investigation before completing a required initial report. Report the information that is available and continue the investigation. Current DCISE processes allow additional information to be provided as the investigation develops.
Escalate the reporting question immediately. Uncertainty does not automatically mean that mandatory reporting applies. It also should not be used as a reason to let the reporting period expire while attempting to prove that nothing happened. Review the contract, affected systems, information locations, access paths, and available evidence. Seek current DCISE or other authoritative guidance when needed.
No. A separate CUI environment can reduce scope, but actual system architecture, access paths, security functions, and actual information use matter. Investigators may still need to determine whether controlled information was stored elsewhere or whether the affected identity or system could reach the protected environment.
No. Reimaging can destroy evidence. Contain the threat first, then determine what evidence needs to be preserved before destructive remediation occurs.
No. A backup is primarily intended for recovery. A forensic image is intended to preserve investigative evidence while maintaining data integrity.
No. An incident does not, by itself, prove that required cybersecurity controls were not implemented or that the organization failed CMMC. The incident should still be reviewed for actual control failures, configuration problems, scope issues, or documentation changes that may affect compliance.
No. ITAR is a separate export-control framework. Whether an ITAR violation or disclosure obligation exists depends on the specific facts, including the information involved, who could access it, whether a foreign person was involved, and the applicable authorization and encryption conditions. Organizations should involve qualified export-control personnel and legal counsel when ITAR-controlled technical data may be involved.
No. Other contractual, regulatory, legal, insurance, customer, or government reporting obligations may apply separately.
No. A cyber incident does not automatically require notification to every customer or business contact. Identify the contracts, systems, information, and organizations actually connected to the incident. Notify the prime contractor, next higher-tier subcontractor, government customer, insurer, affected parties, or other organizations when an applicable contract, law, regulation, policy, or reporting requirement requires it. Avoid describing an incident as a confirmed data breach or customer-data exposure unless the evidence supports that conclusion.
Do not wait for the certificate process to finish if a reporting deadline may apply. Current DCISE guidance instructs organizations without the required certificate to contact DCISE for reporting assistance and follow the instructions provided for that incident.
Review the subcontract first because it may contain its own notification deadline. Under DFARS 252.204-7012, when a subcontractor submits a required cyber incident report to DoD, it must provide the DoD-assigned incident report number to the prime contractor or next higher-tier subcontractor as soon as practicable.
No. An outsourced IT provider can perform substantial technical investigation, evidence preservation, documentation, and reporting support. The impacted contractor or subcontractor remains responsible for its contractual obligations. Current DCISE guidance also states that a third party cannot submit a mandatory ICF on behalf of the impacted company.
