DFARS Evidence and Incident Support for Defense Contractors

Start With the Contract and the Covered Information

Every DFARS engagement we take on begins with three questions. Which contracts carry the safeguarding clause, which information those contracts treat as covered defense information, and which systems store, process or transmit it. The answers set the boundary for everything that follows, and in our experience they are rarely as tidy as the architecture diagram suggests. Email, file shares, cloud tenants, engineering tools and subcontractor exchanges all move covered information, and each one is a place an assessor or an incident responder will look.

A word on terms, because they get mixed up in ways that cost contractors time. DFARS is a procurement regulation. NIST SP 800-171 is the security requirements publication the clause points to. CMMC is the Department's assessment program. A technical review, a gap analysis or a penetration test builds the evidence your position under those requirements rests on, and knowing which of the three you are answering to keeps that evidence pointed at the right reader.

If you are not certain which clauses your contracts carry, work through the defense contractor preparation guide before the scoping call.

What DFARS 252.204-7012 Requires When an Incident Happens

DFARS 252.204-7012 addresses covered defense information, covered contractor information systems and cyber incident reporting. Whether the clause applies to a given contract, and which version of the NIST publication it points to, has to be read from the solicitation, the contract and any authorized direction. Cloud service use and subcontractor arrangements each need their own review, because the clause follows the information wherever it goes.

For a cyber incident covered by the clause, rapid reporting means reporting within 72 hours of discovery. The clause also requires preservation of images of the affected systems and the relevant monitoring and packet capture data for at least 90 days after the report is submitted. Those two obligations are where forensic discipline matters most, and they are the reason a contractor should know before an incident how an image will be taken and where the network records live. Read the official DFARS 252.204-7012 text for the complete reporting conditions and requirements.

If the 72 hour clock may already be running, call (800) 868-8189 now and we will tell you what to image first while your team prepares the report.

Where CMMC Stands and Why the Contract Still Governs

The CMMC Phase II transition that had been scheduled for November 2026 is suspended, and the Phase I self assessment requirements remain in place. The September 3, 2026 DFARS class deviation keeps NIST SP 800-171 Revision 2 as the baseline under DFARS 252.204-7012, so the publication of Revision 3 does not by itself change what your contract requires. The solicitation, the contract and any modifications set the assessment route, and we read them with you on the first call.

Assessment support, a self assessment and a required third party certification are three different activities with three different owners. We prepare the technical evidence and close the technical gaps for whichever route your contract requires, so you walk into a self assessment or a third party assessment with the record already in order.

Unsure which route your contract requires? Describe the contract and the assessment level and we will scope the technical evidence work around it.

Put Your DFARS Boundary in Front of a Senior Examiner

Tell us which contracts are in play, which systems hold covered information and what decision or date you are working toward. A senior examiner will tell you where the evidence gaps likely sit and how we would scope the work. The first consultation is free.

Scope Your Assessment

Map the Evidence Boundary Around Covered Defense Information

We trace the covered information itself: who owns it, where it originates and how it moves through email, endpoints, servers, cloud applications and external providers. We record the administrators and service accounts that can reach it, and we include the places boundary diagrams habitually forget, which are backups, remote access paths and the exchanges with subcontractors. A synchronization service or an unmanaged laptop left off the diagram is a material gap in the assessment, and it is also where an incident tends to begin.

The output ties the system boundary to evidence that actually exists: inventories, network diagrams, configuration settings, logs and documented processes. Where the facts are uncertain or a scope decision belongs to someone else, we record the assumption and the open question for the responsible decision maker rather than papering over it.

Ask for the boundary map as a written scope of its own; the control evidence register can follow once the boundary is agreed.

Build a Control Evidence Register an Assessor Can Follow

For every requirement in the agreed scope we identify the implementation, the evidence source, the responsible owner and any known gap. The distinction we hold to is between a written policy and proof that a control operates. Access reviews, configuration exports, training records, change records and exercised procedures each prove a different thing, and an assessor will ask for the one that fits the requirement.

Every artifact carries its collection date and the environment it came from, because a screenshot from a test tenant presented as a production control is a credibility problem you do not want to discover during an assessment. Remediation tasks state the affected system, the action, the owner and how the fix will be verified. We retest the change and keep the supporting record rather than closing an item on an assurance.

If an assessor has already set a date, tell us how long you have and we will say which controls to evidence first.

Prepare to Report and Preserve Before a Reportable Incident

The 72 hour reporting window leaves no time to decide who calls whom. We help you agree escalation contacts, reporting responsibility and evidence handling in advance, and we identify how responders will preserve endpoint images, identity records, cloud audit data and network telemetry while containment is under way. We also check that logging and retention settings can actually support the 90 day preservation requirement, because a short log retention default quietly defeats it.

During an incident we maintain the chronology of discovery, decisions, collection and containment, recording what is known, what is uncertain and which sources are unavailable. Originals are preserved separately from analysis copies and custody is tracked from the first image. When the incident has already happened, our incident analysis examiners take that work on directly, and a forensic readiness assessment tells you in advance whether your environment could support it.

Send us the incident response plan and we will mark where it falls short of the clause's preservation requirements.

Scope the Technical Support You Actually Need

Bring the applicable requirements, the system boundary, your current documentation and the decision or deadline in front of you. An engagement can concentrate on source mapping, evidence organization, technical gap analysis, authorized security testing or incident readiness, and most contractors need two of those rather than all five. Every deliverable states the methods used, the findings, the limitations and the recommended next steps so it can be handed to an assessor, to leadership or to a contracting officer without translation.

Start with a brief description of the environment and the support you need. Controlled information, evidence and credentials move only after we arrange handling that fits the contract, so the first conversation can stay at that level.

Related Technical Services

Explore the cybersecurity practice behind this work

Meet the examiners who would do it