Incident Handling

An incident response plan plus the security tools you already run is the capability. A security operations center is not.

Objective [a] asks whether an operational capability exists, not whether anyone watches a screen around the clock. A written incident response plan, an endpoint protection tool that raises alerts, a named reporting channel, and people who know their roles establish the capability. Buy monitoring services when your risk justifies them, not because this requirement demands them.

Write the plan around the six activities the objectives name.

Objectives [b] through [g] each check one phase: preparation, detection, analysis, containment, recovery, and user response. Give each phase its own section that says who acts and what they do. An assessor walks the letters in order, and a plan organized the same way answers each one directly.

Preparation is a short list of concrete artifacts.

Preparation needs four things. List the people inside and outside the organization you would call. Name a reporting channel, such as an email address or phone number. Set up a way to track incidents from open to closed, and a place to store evidence. Those four items carry [b], and none of them requires new tooling. Detection and analysis then run on what you already have. Antivirus and endpoint alerts, log entries that raise concern, and user reports are the sources for [c]. Analysis under [d] means someone compares what they see against normal operations and writes down what happened, including the associated log entries.

User response means every user knows how to recognize and report an incident, and responders know their parts.

Objective [g] is about people. Ordinary users need to know what looks suspicious and who to call. Administrators need the containment and recovery steps for the systems they run. Put the reporting path in your awareness training under AT.L2-3.2.1, and the responder duties in role-based training under AT.L2-3.2.2. Objective [g] then falls out of training you already owe.

Build your DFARS reporting duties into preparation without mistaking them for this requirement's objectives.

DFARS 252.204-7012, the safeguarding clause in your DoD contracts, sets a 72-hour clock. It covers a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to provide operationally critical support. The report goes to DoD within 72 hours of discovery. It also requires preserving images and logs for at least 90 days from submission of the report. None of the seven objectives here measures that clause. Incident reporting has its own requirement, IR.L2-3.6.2, and the 72-hour clock stays a contract obligation either way. Put the DoD reporting steps, the address of DIBNET, DoD's incident reporting portal, and the preservation duty into the plan now. The 72-hour clock is not the time to learn them.

A stolen laptop with CUI on it is an incident.

The capability covers physical loss and theft of equipment holding CUI, Controlled Unclassified Information, not just network intrusions. Cover it in the same plan or in a separate physical loss procedure. Either way, both paths exist and name their owners.