8.3 Incident Response (IR), System Integrity (SI) & Risk Assessment (RA/CA) Domains

Incident Response, System Integrity, Risk & Security Assessment

IR, SI, RA, and CA form a cycle: prepare for incidents, detect flaws and attacks, assess risk and implementation, correct problems, monitor performance, and maintain the SSP. Their CMMC objectives are separate from contract incident reporting and from the limited assessment POA&M process.

Incident Response

The IR family has three Level 2 requirements:

• 3.6.1 establishes an operational incident-handling capability including preparation, detection, analysis, containment, recovery, and user response.
• 3.6.2 tracks, documents, and reports incidents to designated officials and/or authorities inside and outside the organization.
• 3.6.3 tests the organizational incident-response capability.

The organization selects test methods appropriate to its environment, such as a tabletop, simulation, or functional exercise. Under 32 CFR §170.14(d), an organization-defined value described as “periodically” may be no longer than one year. The rule does not mandate one exercise scenario, participant list, or after-action template.

Separate DFARS duties

When DFARS 252.204-7012 applies and the contractor discovers a cyber incident affecting a covered contractor information system or the covered defense information residing in it, or affecting required operationally critical support, the contractor reviews the compromise and rapidly reports within 72 hours through DIBNet. The clause requires the contractor or subcontractor to have a DoD-approved medium-assurance certificate for reporting.

The contractor preserves and protects images of all known affected information systems identified through the required review, plus relevant monitoring and packet-capture data, for at least 90 days after submission of the incident report. The text does not say to create a new complete forensic disk image of every enterprise device. When malicious software is discovered and isolated in connection with a reported incident, it is submitted according to DC3 or contracting-officer instructions; it is not sent to the contracting officer.

The IR CMMC objectives and DFARS report support one another, but a CMMC assessment team does not submit the OSC’s incident report or administer containment. A reported incident alone is not automatic proof that every CMMC requirement is NOT MET.

System and Information Integrity

The SI family has seven Level 2 requirements. Four also map to Level 1: 3.14.1, 3.14.2, 3.14.4, and 3.14.5.

“Timely” remediation is risk-based and organization-defined. CMMC does not publish universal 14-, 30-, or 60-day patch deadlines. A SIEM, EDR, IDS, antivirus product, or managed service may implement objectives, but none is universally mandated. The team evaluates coverage and operation across the actual scope.

Risk Assessment

The RA family contains three requirements. 3.11.1 periodically assesses risk to operations, assets, and individuals from operating systems and processing, storing, or transmitting CUI. 3.11.2 scans organizational systems and hosted applications periodically and when new vulnerabilities affecting them are identified and reported. 3.11.3 remediates vulnerabilities according to risk assessments.

Credentialed scanning often provides useful host visibility, but the requirement does not prescribe one scanner or say every asset always uses the same scan method. Specialized assets, applications, cloud responsibilities, network devices, and provider services may need different evidence. Scan coverage, authentication success, exclusions, false-positive handling, prioritization, and verified remediation matter more than a dashboard total.

Security Assessment and the two plan concepts

The CA family contains four requirements:

• 3.12.1 periodically assesses security requirements to determine whether they are effective in their application.
• 3.12.2 develops and implements plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities.
• 3.12.3 monitors security requirements on an ongoing basis for continued effectiveness.
• 3.12.4 develops, documents, and periodically updates the SSP, including system boundaries, operating environment, implementation of requirements, and relationships or connections to other systems.

32 CFR part 170 clarifies that the operational plan of action associated with CA.L2-3.12.2 addresses temporary vulnerabilities and deficiencies as threats and systems change. The OSA chooses its format, and the definition does not impose the assessment POA&M’s 180-day remediation timeline.

An assessment POA&M under §170.21 is different. It exists only after an assessment supports Conditional status, is restricted by the score ratio, point rule, narrow SC.L2-3.13.11 exception, and named exclusions, and must close within 180 days. Level 1 permits no assessment POA&M. Do not reject an operational plan merely because it contains an item that could not appear on an assessment POA&M; first identify which plan the scenario describes.

Evidence sequence

1. Trace incident roles, records, testing, and any applicable DFARS reporting path.
2. Sample flaw, malware, alert, scan, attack-monitoring, and unauthorized-use evidence across the scope.
3. Compare vulnerability findings with risk decisions and completed remediation.
4. Review periodic assessment and ongoing monitoring results.
5. Reconcile the SSP with the inventory, network diagram, providers, and current implementation.
6. Classify each plan correctly as operational or assessment-related before applying deadlines or exclusions.

This evidence chain prevents attractive but wrong shortcuts: every incident is not a CMMC failure, every vulnerability is not due in 30 days, and every item called a POA&M is not governed by the Conditional-status rules.