DKDavid Koran& Associates
Home The CMMC Guide Part III · Incident Response IR.L2-3.6.1
The CMMC Guide · Incident Response Family

IR.L2-3.6.1  Incident Handling

Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.

Family
Incident ResponseIR, 3 requirements
Point Value
5Highest weight in the methodology
POA&M Eligible
NoCannot remain open at assessment
Objectives
SevenPer NIST SP 800-171A

1Overview

IR.L2-3.6.1 opens the Incident Response family and is one of its two five-point requirements. It requires that the organization establish an operational incident-handling capability covering preparation, detection, analysis, containment, recovery, and user response, so that when something goes wrong there is a real capability to handle it rather than improvisation. It is a five-point requirement that cannot be deferred on a plan of action.

Incidents are a matter of when, not if, and the difference between a contained event and a disaster is usually whether the organization was ready. This control asks for an operational capability, not just a written plan, spanning the full life cycle of an incident: preparing in advance, detecting that something has happened, analyzing what it is, containing it, recovering from it, and handling the user response. The word "operational" is doing real work, because a plan that no one could actually execute is not a capability. Its five-point weight reflects that the ability to respond well is what limits the damage of the incidents that will come.

The requirement · NIST SP 800-171 Rev 2, 3.6.1

Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.

The requirement names six activities that together form the incident-handling life cycle. Preparation is the readiness built in advance; detection is recognizing an incident; analysis is understanding it; containment is stopping its spread; recovery is restoring normal operation; and user response is handling the people side, including how users report and are guided. The capability has to be operational, meaning staffed, resourced, and executable, across all six, and it is the foundation the rest of the family builds on.

2The Assessment Objectives

NIST SP 800-171A decomposes 3.6.1 into seven objectives: establish the capability, and confirm it includes each of the six activities.

[a]

An operational incident-handling capability is established. The organization has a real, executable capability to handle incidents.

MeetsAn operational capability with defined roles, procedures, and resources for handling incidents.
FailsNo capability exists, or only a plan that could not actually be executed.
[b]

The capability includes preparation. The organization prepares for incidents in advance.

MeetsPreparation such as procedures, tools, and roles is in place before an incident.
FailsNothing is prepared, so response begins from scratch.
[c]

The capability includes detection. The organization can recognize that an incident has occurred.

MeetsDetection through monitoring and reporting recognizes incidents.
FailsIncidents go unnoticed because nothing detects them.
[d]

The capability includes analysis. The organization can understand an incident.

MeetsAnalysis determines the nature and scope of an incident.
FailsIncidents are detected but not understood.
[e]

The capability includes containment. The organization can stop an incident from spreading.

MeetsContainment limits the spread and impact of an incident.
FailsAn incident spreads unchecked because nothing contains it.
[f]

The capability includes recovery. The organization can restore normal operation.

MeetsRecovery restores systems and operations after an incident.
FailsNo recovery capability exists, so restoration is improvised.
[g]

The capability includes user response activities. The organization handles the user side of an incident.

MeetsUser response covers how users report incidents and are guided during them.
FailsThe user role in incidents is undefined.

The seven objectives are the capability itself plus its six required activities. The common gap is a plan that names the activities on paper but is not operational, so it could not actually be executed under pressure. The assessor looks for a capability that is real and covers the full life cycle, not a document alone.

3Failure Patterns

The failures are about missing activities and plans that are not truly operational.

A plan that is not operational

A written incident-response plan that no one is trained on, resourced for, or able to execute is not an operational capability. The control requires a capability that can actually be carried out, not just described.

Detection without the rest

Where an organization can detect incidents but has no containment or recovery, the life cycle is incomplete, and a detected incident still runs its course. All six activities have to be present.

No user response role

Leaving out how users report and are guided during an incident omits the user response activity. Users are often the first to notice an incident, so their role has to be defined.

Undefined roles and resources

Without defined roles and the resources to act, response collapses into improvisation when an incident hits. Preparation includes establishing who does what with what tools before the incident.

The common root
This control fails when the capability exists only on paper. An incident tests whether the organization can actually detect, understand, contain, and recover, and a plan that was never made operational falls apart under the pressure of a real event. Building a capability that people can execute is what the control requires.

4Ownership

This is an IT and security-owned control, though an effective capability draws in leadership and users across the organization.

RoleResponsibility for this control
Security or compliance leadEstablishes the operational capability across the six activities, defines roles and procedures, and owns the incident-handling evidence.
IT and system administratorProvides the detection, containment, and recovery capabilities the response depends on.
Leadership and usersSupport the capability with resources and, for users, the reporting and response role that begins many incidents.
See also: This control depends on the detection that the audit family enables, pairs with the incident tracking and reporting of IR.L2-3.6.2, and is exercised by the testing of IR.L2-3.6.3.

5Tooling

The control is delivered by an incident-response program: procedures, roles, and the technical capabilities for each phase.

ObjectivesToolingWhat it provides
[a], [b]Incident response plan, defined roles, resourcesThe operational capability and its preparation.
[c], [d]Monitoring, alerting, and analysis capabilityDetection and understanding of incidents.
[e], [f]Containment procedures, backups and recoveryStopping spread and restoring operation.
[g]User reporting and response proceduresThe user side of incident handling.

The caveat is that tooling supports the capability but does not constitute it; the capability has to be operational, with people who can execute it. A plan and tools that no one has exercised may not hold up in a real incident, which is why the testing of 3.6.3 matters. The assessor examines whether the capability is real and complete, so the operational substance has to be demonstrable.

6Evidence

The satisfied version of 3.6.1 shows an operational capability across all six activities.

EvidenceWhat it demonstrates
Incident response planObjectives [a], [b]. The operational capability and preparation.
Detection and analysis capabilityObjectives [c], [d]. Recognition and understanding of incidents.
Containment and recovery proceduresObjectives [e], [f]. Stopping spread and restoring operation.
User response proceduresObjective [g]. The user role in incidents.

The evidence should show an operational capability covering preparation, detection, analysis, containment, recovery, and user response, backed by defined roles and resources. The plan together with the technical and procedural capabilities for each phase is the clearest demonstration, and because this control cannot sit on a plan of action, the capability has to be real at the time of assessment.

Incidents are a matter of when, not if

The difference between a contained event and a disaster is usually whether the organization was ready, and this five-point control asks for an operational capability across the full incident life cycle. Building a response capability that people can actually execute is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.

Start CMMC Readiness or call 802-335-2662

7Sources

  1. NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.6.1. csrc.nist.gov
  2. NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.6.1[a] through 3.6.1[g]. csrc.nist.gov
  3. 32 CFR 170.24, CMMC Scoring Methodology, listing IR.L2-3.6.1 among the five-point basic security requirements. ecfr.gov
← Previous: Identification and Authentication
IA.L2-3.5.11 · Obscure Authentication Feedback
Next in Incident Response →
IR.L2-3.6.2 · Incident Tracking and Reporting
About the Author
David W. Koran is a CyberAB Registered Practitioner Advanced and the author of The CMMC Decision, now in its second edition. He works onsite with defense contractors and their counsel, from the first leadership briefing through the pre-assessment review. Reach him at 802-335-2662 or dkoran@davidkoran.com.
Entry IR.L2-3.6.1 · Edition 2026.1 · Last reviewed July 12, 2026