72-Hour Cyber Incident Reporting Under DFARS 252.204-7012

Define discovery in your internal escalation process

The clause's clock is tied to discovery, so your organization needs an internal rule for getting potential covered-system incidents to the right decision-makers immediately. Do not let a help-desk ticket sit in a normal queue while someone waits to prove that CUI was definitely taken. The first escalation can be based on reasonable suspicion; the reporting determination can follow quickly.

Train employees and providers on examples relevant to your environment: a lost managed laptop, suspicious sign-in to the CUI tenant, malware on an engineering workstation, unauthorized forwarding of CUI email, or evidence that a cloud account was accessed. The aim is rapid routing, not asking every user to interpret DFARS.

Pre-stage the facts required for a report

During an incident, teams lose time looking for contract numbers, CAGE information, system names, points of contact, and access to the reporting mechanism. Keep a protected incident reference sheet with the contracts tied to each covered system, responsible program managers, system owners, and the credentials or certificate process needed for authorized reporting.

Test the sheet quarterly. People change roles, certificates expire, contracts close, and after-hours numbers stop working. A tabletop exercise should include logging in to the reporting portal up to the point where a real incident submission would begin, without creating a false report.

Investigate enough to report, but do not wait for perfect certainty

The clause requires review for evidence of compromise and identification of affected systems, data, and user accounts. That investigation should begin immediately, but the 72-hour window means the organization cannot wait for a weeks-long forensic conclusion before acting. Your incident procedure should define the minimum facts needed for an initial report and how follow-up information will be handled.

Preserve decision notes. Record when the event was discovered, who was notified, what systems were considered in scope, what evidence was available, and when the reporting decision was made. A simple timeline helps explain the response later and exposes bottlenecks during exercises.

Preservation is a separate obligation

For a reported incident, 252.204-7012 requires preservation and protection of images of known affected information systems and relevant monitoring or packet-capture data for at least 90 days from submission of the cyber incident report. That is easy to promise and hard to execute if normal backup, log-rotation, or endpoint-reimaging processes overwrite the material.

Define a legal-and-forensic hold procedure for security artifacts. Identify who can suspend log deletion, acquire disk or endpoint images, preserve cloud audit data, and protect chain-of-custody information. If an MSP or cloud provider controls those functions, the contract should require timely cooperation.

Plan for malicious software and forensic requests

The clause also addresses handling of malicious software and Government access to additional information or equipment needed for forensic analysis. Your incident plan should say who coordinates those requests, who authorizes access, how sensitive commercial data is handled, and how affected equipment is preserved while business recovery continues.

Do not email suspicious binaries casually to a contracting officer. Follow the specific clause and current Government instructions for malicious-software submission. Include the official source links in the incident runbook so responders are not searching the open web for procedures during a crisis.

Run a realistic 60-minute exercise

Use one narrow scenario: a CUI-enabled user's laptop shows suspicious credential use on a Saturday morning. Walk through discovery time, escalation, contract mapping, decision authority, portal access, evidence capture, provider notification, and the 90-day preservation hold. Stop the exercise whenever the team has to say 'we would find that person later.'

Afterward, fix the contact list, permissions, and missing evidence before writing a long lessons-learned report. The best exercise result is not a polished slide deck; it is a shorter path from first alert to informed reporting decision. Repeat with a cloud-provider or subcontractor scenario because those dependencies often expose different delays.

The first 12 hours matter more than the last 12

A well-designed response process aims to reach an informed reporting decision long before hour 72. The first hour is for containment and escalation, not for writing a perfect report. The next several hours should establish whether covered systems or covered defense information may be involved, what contracts are implicated, and what evidence must be preserved immediately.

Create an incident bridge that includes technical response and contract context. Security can determine what systems are affected; the contracts or program owner can identify the relevant agreement and information. Neither group should work in isolation. A technically accurate incident report can still be delayed if nobody can identify the contract facts.

Use a decision log with timestamps. Record discovery, first security notification, first management notification, scope decision, preservation action, portal access, and submission time. During a tabletop, that log exposes delay in the process more clearly than a general after-action discussion.

Set an internal decision target that leaves substantial margin before the 72-hour outside reporting window. The exact target should reflect your staffing and incident process, but it should be early enough to absorb contract lookup, executive escalation, provider delays, and incomplete facts. The clause's 72 hours are not a recommended point to begin deciding whether an incident is reportable.

Keep the runbook usable under stress. Put portal instructions, internal escalation numbers, contract lookup steps, preservation actions, and provider contacts in one controlled location that responders can reach if the normal collaboration platform is unavailable. Test access from a backup communications path during exercises; an incident that disables the primary tenant should not also disable the procedure for reporting it.

Practice the handoff between technical responders and the person who can submit the report. An incident team may know what happened but not have the contract data, while contracts may know the affected programs but not understand the technical facts. A short incident worksheet that both groups can use—discovery time, systems, programs, CUI involvement, containment status, report owner, and preservation actions—can save hours without encouraging speculation. The first version should be useful even when several facts remain unknown.

Common questions

Official sources used for this guide

Open the primary source before making a contract-specific decision. Regulations and program implementation can change.