The Incident Response Domain: detecting, containing, reporting, and learning

What the Incident Response Domain Is For

The Incident Response domain defines how the organization handles a security incident from the moment it is detected through the post-incident analysis that improves the response capability over time. The three requirements look compact on paper, but each encompasses a multi-step operational capability that must be designed, documented, tested, and exercised.

For defense contractors, the IR domain also carries an obligation that extends beyond the CMMC framework itself. DFARS 252.204-7012 requires reporting of cyber incidents affecting covered defense information to the Department of Defense Cyber Crime Center within 72 hours of discovery. This reporting obligation is contractual rather than a CMMC requirement per se, but it interacts directly with IR.3.6.2, and the incident response plan must integrate the DFARS timeline into its reporting procedures. A contractor that satisfies IR.3.6.2 through internal reporting without addressing the DFARS external reporting obligation has a compliance gap that will surface during assessment or, more consequentially, during an actual incident.

The practitioner reading of IR is that the domain is less about the existence of a plan than about the organization's demonstrated ability to execute the plan under pressure. A document that describes an incident response capability is not the same as an operational capability. Assessors evaluate evidence that the plan has been exercised, that personnel know their roles, and that the last time an incident occurred, the response matched the plan.

The Three Controls

IR.L2-3.6.1Incident Handling

The organization must establish an operational incident-handling capability that includes preparation, detection and analysis, containment, recovery, and user response activities. The control covers the full incident lifecycle. Preparation is the work done before an incident, including plans, tools, and training. Detection and analysis is the capability to recognize an event and characterize it. Containment limits the impact. Recovery restores operations. User response addresses the personnel and communication dimensions of the event. Each stage must be documented and operational, not just defined on paper. The assessable question is not whether a plan exists but whether the plan describes a capability that the organization has actually built.

IR.L2-3.6.2Incident Reporting

Incidents must be tracked, documented, and reported to designated officials and authorities both internal and external to the organization. The control requires a reporting structure that covers internal stakeholders (leadership, legal counsel, affected business units) and external authorities (DoD, law enforcement, regulators, customers where contracts require it). For defense contractors, the DFARS 252.204-7012 reporting requirement to the DoD Cyber Crime Center is the most significant external obligation, and the reporting procedure must integrate the 72-hour DFARS window. Internal tracking must produce records that support both the CMMC evidence requirement and any subsequent investigation. The tracking system must survive the incident itself, meaning it cannot depend on systems that the incident may have compromised.

IR.L2-3.6.3Incident Response Testing

The organizational incident response capability must be tested. The testing requirement is the control that separates a documented plan from an operational capability. Tabletop exercises, functional drills, and simulated incidents all satisfy the testing obligation, but the testing must be substantive rather than ceremonial. A tabletop that consists of a slide presentation describing what would happen is not a test. A tabletop that walks a scenario with decision-makers actually making decisions against time pressure, with findings documented and acted on afterward, is. The cadence of testing is an organizational decision, typically annual at minimum, and the assessment evidence includes both the test records and the demonstration that findings from prior tests were addressed.

Where Incident Response Intersects with Other Domains

Incident Response consumes output from several other domains as its primary investigative input and feeds findings back into the rest of the framework.

Audit and Accountability provides the primary investigative resource that IR relies on. When an incident requires reconstruction of events, the audit trail is what makes that reconstruction possible. The AU correlation and reporting capabilities under 3.3.5 and 3.3.6 determine how effectively an IR team can characterize an incident and identify its scope. A weak AU foundation produces an IR capability that cannot produce defensible timelines.

System and Information Integrity provides the detection capability that most frequently initiates the IR lifecycle. SI monitoring generates the indicators that IR investigates. The interaction between the two domains is tight enough that some organizations merge their detection and response functions operationally, though the assessment evidence for each domain remains distinct.

Awareness and Training produces the personnel capability that IR depends on. Users recognize incidents because AT taught them what to recognize. Incident responders perform their roles effectively because AT prepared them. The insider threat training under AT.3.2.3 directly supports the detection capability that IR subsequently activates on.

Access Control provides the containment mechanisms that IR uses during active response. Disabling compromised accounts, restricting access pathways, and isolating affected systems are AC operations that IR directs. A flexible AC implementation supports faster containment than a rigid one, because the response team needs to make quick authorization decisions under pressure.

System and Communications Protection provides the network-level containment mechanisms. Segmentation, boundary controls, and traffic inspection are SC capabilities that IR leverages during active incidents. The quality of network segmentation under SC directly affects how effectively a contained incident can be prevented from spreading.

Configuration Management supports recovery by providing the baseline that affected systems are restored against. A system that has been compromised must be restored to a known good state, and the CM baseline is what defines that state. Without reliable baselines, recovery becomes rebuild.

Common Implementation Pitfalls

Several patterns come up repeatedly in Incident Response readiness work.

The plan exists but has never been tested. The organization has a documented incident response plan, often pulled from a template or inherited from a previous security program, but no exercise has actually been conducted against it. The 3.6.3 testing requirement cannot be satisfied by the plan's existence. When an actual incident occurs against an untested plan, the response tends to reveal gaps that testing would have surfaced in a controlled setting.

The 72-hour DFARS reporting window is not integrated into the plan. The plan addresses internal reporting to leadership and the IR team but does not integrate the external reporting obligation to the DoD Cyber Crime Center that DFARS 252.204-7012 imposes. When an incident occurs, the team focuses on investigation and containment, and the 72-hour reporting window passes before anyone recognizes that the external reporting obligation was distinct from the internal process.

Tabletop exercises that function as briefings rather than as exercises. The organization holds an annual tabletop, but the event is a presentation about what the plan says rather than a scenario walk-through with decision-makers making decisions under time pressure. A tabletop where no decisions are forced and no disagreements surface has not tested the capability. The value of the exercise comes from the friction it produces, not from the coverage of the slides.

Undefined incident criteria. The plan does not clearly define what constitutes an incident versus a minor event, an anomaly, or a routine system alert. The ambiguity means that borderline events are either escalated to full IR activation unnecessarily or dismissed entirely without documentation. The criteria do not need to be exhaustive, but they need to exist and be applied consistently.

Containment decisions not pre-approved at leadership level. The IR plan calls for containment actions (disconnecting systems, disabling accounts, blocking network segments) that have operational consequences. If those actions require real-time leadership approval during an incident, the approval delay becomes part of the incident impact. Pre-approving specific containment actions under specific scenarios speeds response and reduces the cost of the incident.

Post-incident lessons learned skipped. The incident is resolved, operations resume, and the review that should update the plan and improve the capability is deferred indefinitely. Without the post-incident analysis, the next incident will repeat the same pattern. The 3.6.1 preparation component implicitly requires ongoing learning from actual events.

Tracking systems that depend on systems the incident may have compromised. The ticketing system, email, or file share that the IR team uses to track the incident sits inside the same environment that is under attack. When the attack progresses, the tracking capability becomes unreliable or unavailable. Out-of-band tracking mechanisms, even if simple, protect against this scenario.

Where to Start

For an organization new to the IR domain, the first work is the incident response plan itself.

The foundational deliverable is a written plan that addresses preparation, detection and analysis, containment, recovery, and user response. The plan must name roles rather than individuals, describe decision authorities, define incident criteria, and integrate the DFARS 252.204-7012 reporting timeline for incidents involving covered defense information. A template-based plan is an acceptable starting point if it is then tailored to the organization's actual operational environment, systems, and personnel. An untailored template does not survive contact with an actual incident.

The second deliverable is the external reporting procedure. Who reports, to whom, within what timeline, with what content. The DoD Cyber Crime Center reporting requirement is the most consequential external obligation for defense contractors, and the procedure must be specific enough that the person on call at 2 a.m. can execute it without improvisation. The procedure should also address customer reporting obligations that may flow from prime contractor relationships.

The third deliverable is the first tabletop exercise. Not the most elaborate exercise the organization will ever run, but a first exercise that produces findings, demonstrates the plan's weaknesses, and establishes a baseline for future testing. The evidence from the exercise satisfies 3.6.3 initially, and the findings become the backlog for plan refinement over the following weeks.

With the plan, reporting procedure, and first exercise in place, the IR domain becomes a matter of ongoing operational discipline rather than a documentation exercise. The controls are few, but the capability they describe is where compliance and operational resilience most directly converge.