DFARS 7012 malware submission and media preservation

What DFARS 7012 requires after you report a cyber incident

Once a DIBNet incident report is filed, three duties apply under DFARS 252.204-7012: submit isolated malware to DC3 as DC3 or the contracting officer instructs, preserve images of affected systems and relevant monitoring and packet capture data for at least 90 days from the report, and give DoD forensic access and preserved damage assessment data on request. The contractor owns these duties, and they fall on the prime and on any subcontractor that discovered the incident. Malware goes to the DoD Cyber Crime Center (DC3), not to the contracting officer, so the first task is to confirm the submission route with DC3 or the contracting officer before anything is sent.

An implementation partner can prepare the groundwork before an incident happens: centralized logging with retention that covers the 90-day minimum, documented imaging procedures for affected systems, hash-verified evidence storage, and a runbook that names who may release media and who holds the chain of custody. A partner does not perform DoD's forensic analysis or damage assessment, and it does not decide what DoD may keep. Ask the partner for a written list of the artifacts it will capture, where they are stored, and who can access them, and confirm that retention periods are set in your own systems rather than assumed from the clause.

Confirm with your counsel and contracting officer whether the 90-day clock is the only retention period that applies. The DHS clause in HSAR 3052.204-72 uses a 180-day period for civilian contracts, so a contract with both DoD and DHS requirements may need the longer period. Read the DFARS 252.204-7012 text on eCFR and the HSAR clause together, and set your retention to the longest period that applies to each contract.

How the post-report sequence unfolds

This sequence takes an incident from the moment malware is isolated to DoD's decision on whether it wants the preserved media. Each step produces a record that shows what was kept, where it went and who asked for it.

Isolate the malicious software and hold it
Your incident responders identify the malicious software during the investigation and separate it from the affected environment so it cannot spread. Under DFARS 252.204-7012(d), the contractor and any subcontractor that discover and isolate malware in connection with a reported cyber incident must hold it for submission. Nothing should be sent yet. The output is a documented copy of the file with a hash, the time it was isolated, and the name of the person who handled it.
Confirm the submission route with DC3 or the contracting officer
The clause says malware is submitted as DC3 or the contracting officer instructs. Ask the DoD Cyber Crime Center how it wants the sample delivered and confirm any handling instructions in writing before transfer. The output is a recorded instruction from DC3 or the contracting officer that names the submission method and the recipient.
Submit the malware to DC3
Send the isolated malware to the DoD Cyber Crime Center using the method DC3 or the contracting officer specified. The clause prohibits sending it to the contracting officer unless that officer is the one giving the instruction. Keep the transfer logs and the hash values so the submitted file can be matched to your records later. The output is a transfer record that shows what was sent, when and to whom.
Preserve images of all known affected systems
Under DFARS 252.204-7012(e), you must preserve and protect images of all known affected information systems. Capture them before rebuilding, reimaging or patching, and store them under controlled access with hash values recorded. Keep the images for at least 90 days from the date you submitted the cyber incident report. The output is an inventory of preserved images that lists each system, its capture time and its storage location.
Preserve monitoring and packet capture data
The same paragraph requires you to preserve all relevant monitoring and packet capture data for at least 90 days from submitting the report. Export logs from the security monitoring tools and packet captures covering the incident window before retention policies overwrite them. The output is a labeled archive of log and capture data with its time range and the source system for each file.
Respond to DoD requests for forensic access and information
Under DFARS 252.204-7012(f), you must give DoD access, on request, to additional information or equipment needed for forensic analysis. Route requests through your incident response lead and legal counsel, and log each request, what was provided and when. The output is a request log that matches each DoD request to the items delivered or the reason an item was unavailable.
Decide on damage assessment and DoD's media request
If DoD elects to conduct a cyber incident damage assessment, DFARS 252.204-7012(g) requires you to provide the damage assessment information you preserved. DoD may also request the media itself or decline interest, and the preservation period in paragraph (e) is what keeps that option open. Confirm the outcome in writing before any preserved media is released or destroyed. The output is a written DoD response that records whether media was requested, declined or still under review.

Submitting malware to DC3 without sending it to the contracting officer

When your team discovers and isolates malicious software in connection with a reported cyber incident, DFARS 252.204-7012(d) requires you to submit that malware to the DoD Cyber Crime Center (DC3). The key instruction is the destination: you submit it to DC3 as DC3 or the contracting officer directs, and you do not send it to the contracting officer. Treat the sample as evidence that belongs in DoD's forensic channel, not in a contract file or an email to the buyer. Before anything leaves your environment, confirm in writing with DC3 and your contracting officer what the submission mechanics are, including the accepted transfer method, packaging, whether the sample should be encrypted or archived, and who receives it.

Chain of custody is what makes the submission defensible later. Record who isolated the sample, the host and file identifiers, hash values computed at collection, the date and time of each handoff, and the storage location and access list while the sample is held. Keep a copy of the DIBNet report number and any DC3 acknowledgment alongside these records. Ask DC3 whether it wants the original file, a copy, or a forensic image of the affected host, and store the sample in a restricted, logged location so that no one can alter it without a trace. Use a dedicated, non-production analysis workstation for any handling, and do not execute the sample outside an isolated environment.

Also plan for the subcontractor case. DFARS 252.204-7012(d) applies to subcontractors as well as contractors, so a subcontractor that finds malware must follow the same DC3 route and keep equivalent records. Document in your incident response plan who is authorized to make the submission, how the decision is recorded, and what happens if DC3 asks for the sample after you have already cleaned the host. Confirm these steps with your DC3 point of contact and contracting officer before an incident occurs, because the mechanics are set by DoD's instructions rather than by the clause text alone.

What you must preserve and what DoD can ask for

After a DFARS 252.204-7012 incident report, four obligations run in parallel: keeping the affected evidence intact, handing over additional material on request, and supporting a damage assessment if DoD opens one. Each card below names one of these duties and the proof a compliance lead should be able to produce.

Images of affected systems

The clause requires you to preserve and protect images of all known affected information systems from the moment you submit the cyber incident report. Preservation is not the same as keeping a backup: the image must capture the system as it was when the incident was detected, with hashes recorded at creation. Check that your incident runbook names who triggers imaging, where images are stored, and who can access them. Confirm the list of affected systems is complete and traceable to your system security plan.

Monitoring and packet capture data

You must also keep all relevant monitoring data and packet capture data for the same retention window. This material shows how the attacker entered, moved and exfiltrated, so it is often more useful to DoD than the system image itself. Verify that your logging and capture tools write to storage that is separate from the systems being investigated, and that retention settings have not been shortened by routine rotation. A quick test is whether you can pull a specific day's network captures for an affected host without asking a vendor.

Forensic access on request

If DoD asks for additional information or equipment needed for forensic analysis, you must provide it. This is an access obligation, so the practical question is whether your team can retrieve a device, a disk or a log set within a short window and with a documented chain of custody. Ask whether your agreements with managed service providers and cloud hosts let you hand over data they control. Keep a written record of every item released, to whom and when.

Damage assessment information

If DoD elects to conduct a cyber incident damage assessment, you must provide the damage assessment information you preserved. This is the material that lets DoD judge what covered defense information was affected and how far the compromise reached. Confirm you can export it in a usable form, identify which records relate to covered defense information, and separate them from unrelated company data. Assign one owner who can answer DoD questions about the preserved set.

Malware and evidence handling

Malicious software you isolate during the response goes to DC3 as DC3 or the contracting officer instructs, and not to the contracting officer. Record how each sample was isolated, stored and hashed, so the submission can be traced back to the affected system. Confirm that your team does not run or redistribute samples outside the isolation environment while preserving the images and captures that support them.

Keeping images and packet captures for 90 days

The 90-day minimum under DFARS 252.204-7012(e) runs from the day you submit the cyber incident report, not from the day you discovered the incident. During that window you must preserve and protect images of all known affected information systems and all relevant monitoring and packet capture data. The point of the requirement is to give DoD time to decide whether it wants the media, either to request it or to decline interest. Your job is to make sure that when DoD asks, the evidence is intact, complete and retrievable within a practical timeframe, not to guess which artifacts they will want. Treat the report date as the start of a retention clock and write that date into your incident record.

Storage design decides whether you can meet that obligation without disrupting operations. Keep forensic images in a separate, access-restricted repository rather than on the systems being rebuilt, and make sure the repository is covered by your system security plan. Restrict read and write access to named incident responders and records staff, log every access, and keep images encrypted at rest with keys managed under your key management process. Compute a cryptographic hash, such as SHA-256, of each image and packet capture when it is written, store the hash in a separate record, and re-verify it before any transfer. Record who collected each artifact, from which system, and when. A hash that was never recorded at collection cannot prove integrity later. Confirm the hashing and chain-of-custody format with your incident response plan and your forensic provider before an incident, not during one.

If you keep these artifacts with a cloud provider, a managed security service or a backup vendor, the obligation does not move with the data. You still have to preserve the images for the full period and be able to produce them on request, so confirm the provider's retention settings, deletion lock or legal hold capability, and log export path in writing. Check that the provider's lifecycle rules will not expire or overwrite captures before day 90, and that any cloud or external service holding CUI meets the requirements that apply to it. Finally, confirm the retention period against your specific contract and any direction from the contracting officer, because subcontract terms, agency-specific clauses and later DoD instructions can change what you must keep and for how long.

How DoD protects your information and how DHS's 180-day rule differs

Under paragraphs (h) through (j) of DFARS 252.204-7012, the Government takes on specific duties for information you provide under the clause. The protected category covers attributional and proprietary information, which can reveal your identity, your security posture or your business data. DoD must protect that information, ask you to identify and mark it, and limit release outside DoD to purposes the clause lists.

Marking duty: Identify and mark attributional or proprietary material in your incident report package so DoD can apply the protection. Build marking into the reporting workflow rather than leaving it to the person who files the report.
Listed release purposes: Release outside DoD is limited to purposes such as cyber incident mitigation, counterintelligence or law enforcement, and national security.
Support contractors: Release to support contractors is limited to those bound by DFARS 252.204-7009, the clause that restricts use and disclosure of reported cyber incident information.
Scope of the protection: The duties attach to information obtained under the clause, so keep a record of what you sent, when, and how it was marked.

Ask your contracting officer and counsel how DoD will apply your markings and which of your materials are likely to qualify as attributional or proprietary before an incident occurs.

What to have in place before an incident happens

Most of what determines how an incident response goes is settled long before an alert fires. The cards below cover the documents, logs, images, retention settings, contacts and rehearsals that a contractor needs ready so that malware submission and media preservation can happen on time and in order.

A documented incident response plan

Write down who declares an incident, who decides whether covered defense information may be affected, who prepares the DIBNet report, and who speaks to the contracting officer. Name a backup for each role. Check that the plan matches the system security plan and the incident handling control in your NIST SP 800-171 scope, since assessors will compare the two. Ask your implementation partner to draft it against your actual systems, then have your own leadership approve it.

Logging that supports forensic work

Forensic reviewers can only analyze what was recorded. Confirm that authentication, administrative, file access and network events are logged on every system that handles covered defense information, that timestamps are synchronized, and that audit records cannot be altered by ordinary administrators. Check that log forwarding to a central store still works after a host is isolated. Gaps found during an incident cannot be recreated afterward.

Imaging and packet capture procedures

Write a step-by-step procedure for taking forensic images of affected systems and for starting packet capture on the relevant network segments. Specify who has authority to take a host offline, how images are hashed and stored, and where chain of custody records are kept. Test the procedure on a non-production host with the open-source imaging and capture tools you have chosen. Confirm that the team can image a system without destroying volatile evidence.

Retention settings that cover the window

DFARS 252.204-7012(e) requires preservation of images and monitoring and packet capture data for at least 90 days from the incident report. Configure log, backup and capture retention on self-hosted platforms so that this window is met without manual steps. Check that the storage holding preserved material is access-controlled, encrypted and separate from the systems under investigation. Note that HSAR 3052.204-72 uses a longer 180-day period for certain civilian contracts, so confirm which clause your contract includes.

Named contacts for DC3 and the contracting officer

Keep a current list of the people who will submit malware to DC3 and the people who will communicate with the contracting officer, with phone numbers and alternates. Confirm how your team obtains DC3 instructions for malware submission, because the clause requires submission as DC3 or the contracting officer directs, not to the contracting officer by default. Store the list where it can be reached if your email or identity systems are down.

A tested incident runbook

Run a tabletop exercise that walks through a simulated incident from detection to report, malware isolation, image preservation and DC3 contact. Record where the runbook was unclear or where a step depended on one person. Repeat the exercise after major system changes and keep the records as evidence for your incident response assessment. Your implementation partner can design the scenario and facilitate the first run, but the organization owns the outcome and the corrections.

Who owns the evidence and who analyzes it

The organization owns its incident response, its evidence and the decisions made about both. Under DFARS 252.204-7012, the contractor must isolate the incident, submit any malicious software to DC3 when instructed, and preserve images and monitoring data for at least 90 days after the report. Those duties sit with the contractor and its subcontractors, not with an outside firm. An implementation partner can help prepare the systems that make those duties possible, such as centralized logging, retention settings, forensic-ready image procedures and a written incident response runbook, but the partner does not decide what counts as a compromise, what is reported, or what is kept.

DoD or its designated analysts perform the forensic analysis and any cyber incident damage assessment. The contractor's role is to provide access to additional information or equipment on request and to hand over the damage assessment information it preserved. Analysts then draw their own conclusions. A partner that collects logs or prepares a timeline is supporting the contractor's response, and its work product is not a DoD finding, a damage assessment or a determination about the incident. Any document that says otherwise should be treated as a warning sign.

Before an incident occurs, confirm in writing who holds each duty: who signs the report in DIBNet, who authorizes release of images to DoD, who receives requests for equipment, and who speaks for the company to the contracting officer. Ask any partner to state in its statement of work that it prepares evidence and does not issue reports, attestations or determinations on DoD's behalf. Also confirm with your contracting officer and counsel how DoD will treat attributional and proprietary material you mark, since that marking is the contractor's job under the clause.

Common questions about DFARS 7012 incident evidence

Can we handle DFARS 7012 incident evidence entirely in-house?

Yes, a contractor can handle these duties with its own staff, but the clause places the duties on the contractor, so the organization must have the people, logs and procedures ready before an incident occurs. The work covers isolating and submitting malware to DC3 when instructed, preserving system images and monitoring and packet capture data, and responding to DoD requests for forensic access and damage assessment information. Teams without forensic experience usually need to confirm who will perform imaging, chain-of-custody handling and log retrieval, and how quickly they can do it. Outside help can prepare these procedures and test them, but an independent assessor does not replace the contractor's own incident response duties.

What does preparing for DFARS 7012 evidence duties involve, and what drives the effort?

Preparation involves identifying every system that could be a known affected information system, confirming that logging and packet capture cover those systems, and writing procedures for malware handling, imaging and retention. The main drivers are how many systems hold covered defense information, how centralized the logging already is, whether cloud and third-party hosts store the data, and whether the team has tested an incident response plan. Costs are mostly staff time and any tooling needed to retain logs and images. Ask any provider for a written scope that lists the systems, log sources, retention targets and the test exercises included, since those items set the effort.

How long must we keep images and packet captures after an incident report?

DFARS 252.204-7012(e) requires the contractor to preserve and protect images of all known affected information systems and relevant monitoring and packet capture data for at least 90 days from submitting the cyber incident report. That period gives DoD time to request the media or decline interest. Keep records in a way that protects their integrity, and confirm with your contracting officer whether any additional retention applies under your specific contract. Your retention settings should be tested before an incident so that the 90-day window is not lost to rotation or overwriting.

How does the 180-day HSAR rule for DHS contracts differ from DFARS 7012?

The HSAR 3052.204-72 clause, which applies to certain DHS contracts, requires contractors to preserve images of affected systems and keep monitoring and packet capture data for at least 180 days from the incident report, compared with the 90 days in DFARS 252.204-7012(e). The HSAR clause also allows incident response to include inspections, forensic reviews and revocation of the authority to operate. Contractors with DHS work should check which clause appears in their contract and set retention to the longer period where both could apply. Confirm the exact clause language with the contracting officer rather than relying on a summary.

How does DoD protect the contractor's information it receives during an incident?

DFARS 252.204-7012(h) to (j) require the Government to protect attributional or proprietary information obtained under the clause. The contractor is asked to identify and mark such information, and DoD may release it outside the Department only for listed purposes, such as cyber incident mitigation, counterintelligence or law enforcement, national security, and support contractors bound by DFARS 252.204-7009. Marking matters, so teams should label proprietary material clearly when they submit it. Legal counsel should review what is shared and confirm how the marking requirements apply to each submission.

What should we ask a partner before hiring one for incident evidence work?

Ask for a written scope that names the systems, log sources, retention settings, malware handling steps and forensic support included, and confirm which deliverables the partner produces. Ask who performs each task, how they document chain of custody, and how they test the procedures against a realistic incident exercise. Clarify that the partner prepares systems, procedures and evidence, while the contractor owns its controls and reporting duties, and that only an independent auditor or assessor issues assessment reports. Request a quote that separates one-time setup from any recurring retainer for support and testing, and ask what is excluded.

Who submits malware and responds to DoD forensic requests on our side?

The contractor is responsible for these duties under the clause, so the organization should name an accountable owner and a backup. Malware found during isolation goes to DC3 as DC3 or the contracting officer instructs, and it is not sent to the contracting officer, so the procedure should state that routing clearly. The same owner should coordinate requests for additional information or equipment under DFARS 252.204-7012(f) and (g). Keep named contacts, reporting channels and approval steps current in the incident response plan so responses are not delayed during an incident.

How DeployOpen prepares incident evidence on self-hosted platforms

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, so the systems that hold covered defense information can be imaged, logged and preserved in an orderly way. We prepare the systems and evidence; the contractor keeps ownership of its controls, its reporting decisions and its dealings with DoD.

How we scope

Engagements are fixed-scope, with systems, log sources and retention targets agreed in writing before work starts.
The written scope lists which systems hold covered defense information and which images, monitoring and packet capture data must be preserved.
Scope names who at the contractor receives forensic requests and who owns the decision to submit malware to DC3.
Ask whether the scope includes the 90-day preservation period and any separate 180-day requirement that applies to your contract.

How we build

We configure logging and packet capture on self-hosted platforms so monitoring data can be retained for the period your scope sets.
Forensic image procedures are documented for each affected system, including how images are stored, hashed and access-controlled.
Malware isolation steps are written so that suspect files stay contained and are handled for DC3 submission rather than sent to the contracting officer.
Storage for preserved evidence is built inside the client's environment, with access limited to named roles.

How we hand over

Runbooks describe the steps from incident detection to isolation, imaging, malware packaging and preservation.
Evidence inventories map each preserved image and capture to the system, time window and retention end date.
Handover includes a test of the preservation and retrieval procedure, with results recorded for the contractor's records.
Documentation for DoD requests covers where evidence sits, who can release it and how it is marked as attributional or proprietary.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover maintenance of logging, storage and runbooks as platforms change.
Ask in any quote which parts are one-time build work and which recur under a retainer.
Independent assessors and DoD decide how evidence is judged; DeployOpen prepares the material for their review.

DFARS 7012 malware submission, media preservation and forensic access