Assessing residual risk after remediation is a mandatory practice for organizations handling Controlled Unclassified Information (CUI) that must comply with NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (Control RA.L2-3.11.3); this post explains a practical, auditable approach you can implement now to quantify, document, and accept residual risk following vulnerability remediation or corrective actions within your Compliance Framework.
Understanding the objective of RA.L2-3.11.3 in your Compliance Framework
The core objective of RA.L2-3.11.3 is to ensure that when you remediate vulnerabilities or apply other security fixes, you do not assume risk has been eliminated without evidence — instead you must measure and document what risk remains (residual risk), who accepts that risk, and any compensating controls or continuous monitoring required. In the context of your Compliance Framework, residual risk assessment is an evidence-driven activity that ties vulnerability management, change control, and risk acceptance into the System Security Plan (SSP) and Plan of Action & Milestones (POA&M).
Step-by-step process to assess residual risk after remediation
Follow these steps inside your Compliance Framework to produce defensible residual risk judgments: (1) baseline the pre-remediation risk using a consistent scoring model (e.g., CVSS for technical vulnerabilities combined with business-impact modifiers), (2) apply remediation and record exact changes made (patch IDs, configuration changes, version numbers), (3) re-test the asset with the same tooling and methodology (network scan + targeted validation or pen test), (4) recalculate likelihood and impact and compute residual risk, and (5) document the results, rationale, and the authorized acceptor of any remaining risk.
Documentation, acceptance, and evidence collection
For compliance evidence, produce: pre- and post-remediation scan reports (timestamps and hashes of results), remediation tickets (JIRA/Ticket ID), test remediation validation (screenshots, logs, or re-scan output), updated SSP/POA&M entries, and a signed risk acceptance form where an Authorizing Official or delegated manager records the rationale and compensating controls. Automate linking of scan results to tickets in your ticketing system to reduce human error and create an audit trail.
Technical verification and measurement details
Use consistent metrics: CVSS v3.1 can provide base technical severity; translate that into a business impact scale (High/Medium/Low) to reflect CUI exposure. Calculate residual risk with a simple formula: Residual Risk = Residual Likelihood × Residual Impact. Example: a vulnerability’s initial CVSS-derived likelihood = 0.9 and impact = 0.8 gives a raw score of 0.72; after patching likelihood drops to 0.2 and impact to 0.6 so residual risk = 0.12 (an ~83% reduction). Validate remediation efficacy with authenticated scans, targeted exploit checks, and where feasible, focused penetration testing to uncover chained or compensating weaknesses.
Small business scenario: web application CVE remediation
Example: a small defense subcontractor hosts a portal that processes limited CUI. A web app vulnerability (CVE) with CVSS 8.3 is discovered. Steps taken: patch the CMS, update plugins, enforce WAF rules, and apply least privilege for database access. Re-scan shows CVSS-equivalent technical risk reduced to 3.1; however, residual risk remains because the WAF is a mitigating control (not a fix) and the codebase still exposes an uncommon admin endpoint. The owner documents residual risk, implements monitoring (file integrity, web request logging), sets a 30-day recheck SLA, and an executive risk acceptor signs the POA&M entry. This combination of remediation + compensating controls + monitoring is exactly the evidence auditors expect for RA.L2-3.11.3.
Compliance tips and best practices
Practical tips: (1) Standardize your scoring method (map CVSS to business impact) and apply it uniformly across assets; (2) Automate scans and ticket creation so pre/post scan evidence is timestamped and immutable; (3) Maintain a current SSP and POA&M that directly reference remediation tickets and residual risk entries; (4) Use short remediation SLAs for high-severity findings and require formal risk acceptance for anything not remediated within the SLA; (5) Where remediation isn’t practical, implement compensating controls (segmentation, MFA, encryption) and monitor continuously with IDS/EDR.
Risks of not implementing residual risk assessment
Failing to measure and document residual risk exposes your organization to undetected security gaps, increased chance of CUI compromise, contract penalties, and likely failure during a CMMC assessment. Beyond compliance consequences, attackers exploit assumptions — for example, believing patching reduces exploitability when a weak configuration or chained vulnerability still allows access. Lack of documented residual risk also prevents informed business decisions and leaves executive leadership without a clear picture of exposure.
In summary, to comply with RA.L2-3.11.3 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, implement a repeatable process that baselines pre-remediation risk, applies consistent technical re-verification, calculates residual risk with clear metrics, documents acceptance and compensating controls in the SSP/POA&M, and retains time-stamped evidence; doing so not only satisfies auditors but materially reduces the likelihood of CUI compromise for small businesses operating under a Compliance Framework.
