NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control RA.L2-3.11.3 requires organizations handling Controlled Unclassified Information (CUI) to prioritize and remediate vulnerabilities according to risk assessments — a practical, repeatable program that ties scanning results to asset criticality, business impact, and defensible remediation timelines. This post explains how a small business can implement that control in real operational terms, with tools, SLAs, examples, and compliance-focused evidence generation.
Understanding the requirement and scope
The control expects that you do more than run scans: you must use a documented risk assessment process to prioritize which findings get fixed first and then remediate those issues in line with prioritized risk. For organizations subject to NIST SP 800-171/CMMC Level 2, this means focusing on systems that store, process, or transmit CUI and applying the risk-based prioritization consistently across servers, endpoints, network devices, cloud assets, and applications.
Step-by-step implementation
1) Asset inventory and classification
Begin with a definitive asset inventory (hostnames, IPs, OS, owner, function, CUI presence). Tag assets by criticality (e.g., Tier 1: CUI storage and authentication servers; Tier 2: application servers; Tier 3: user desktops). Use an authoritative CMDB or a simple CSV maintained in version control if your environment is small. Example tools: ServiceNow, NetBox, or a business-managed Google Sheet plus automation via Ansible or Powershell to validate state weekly.
2) Vulnerability identification and scoring
Run authenticated and unauthenticated vulnerability scans on a defined cadence: internet-facing assets weekly, internal servers monthly, and endpoints quarterly. Use scanners like Tenable Nessus, Qualys, Rapid7, or OpenVAS. Normalize findings with CVSSv3 scores and map to your asset tags. Enrich scan results with threat intelligence (exploit availability, public weaponization) and EDR/SIEM telemetry (indications of attempted exploitation) to raise priority for actively targeted CVEs.
3) Prioritization and remediation SLAs
Translate risk assessments into measurable SLAs. A reasonable small-business starting point: Critical (CVSS ≥ 9.0 or exploited in the wild and CUI exposure): remediate or mitigate within 7 days; High (7.0–8.9 or high business impact): 30 days; Medium (4.0–6.9): 90 days; Low (<4.0): patch in the next standard release cycle or 6 months. Adjust based on compensating controls, system uptime windows, and vendor patch availability. Record the decision rationale (asset owner approval + risk acceptance) in your ticketing system for audit evidence.
4) Remediation methods and compensating controls
Remediation options include patching, configuration change (disable services, tighten ACLs), redeploying to patched images, or isolating the asset in a segmented VLAN. Where immediate patching breaks operations, deploy compensating controls: virtual patching via WAF or IPS rules, host-based firewall rules, privilege reduction, or temporary removal of CUI from the asset. Use automation (SCCM/Intune, Ansible, Chef) to reduce human error and document every change through change control tickets and rollback plans.
5) Exception & risk acceptance process
Implement a formal exception process for unavoidable delays: require a documented risk acceptance form that includes compensating controls, residual risk assessment, approver (e.g., CISO or designated senior manager), and an expiration date for the acceptance. Log exceptions in the CMDB and make sure they are re-reviewed before expiration. This process is key evidence for auditors reviewing RA.L2-3.11.3 compliance.
Real-world small business scenario
Example: A 50-person defense subcontractor runs a near-term project with CUI on an on-prem application server (Ubuntu LTS), an Azure SQL DB, and several Windows 10 user laptops. The vulnerability scan finds a critical kernel CVE on the application server and a high-priority RCE in a publicly exposed Tomcat instance. The team tags the app server as Tier 1, applies an emergency kernel patch during a maintenance window (7-day SLA), places the Tomcat host behind a WAF rule to block the exploit signature immediately, and schedules a full Tomcat upgrade within 14 days. All actions are recorded in JIRA with links to scan findings and approvals — evidence for a future CMMC assessment.
Compliance tips and best practices
Keep these practical habits: (1) integrate scanner output with your ticketing system so findings create actionable tickets with owner and SLA, (2) use EDR/SIEM correlation to prioritize vulnerabilities that show exploitation patterns, (3) automate repetitive remediation tasks and baseline images, (4) review and tune scanner configurations quarterly to reduce noise, and (5) maintain a metrics dashboard (open vulnerabilities by age, MTTR, percentage of criticals remediated within SLA) to demonstrate continuous improvement to assessors.
Risks of non-compliance
Failing to prioritize and remediate per a documented risk assessment exposes you to data breaches, loss or exposure of CUI, contractual penalties, delayed or failed CMMC certification, and reputational harm. For small businesses, a single exploited vulnerability can lead to lost DoD contracts and costly incident response — making a measurable, documented vulnerability management program operationally and financially necessary.
Summary: To meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 RA.L2-3.11.3, build a repeatable process that ties asset classification to scan results, enriches findings with risk context, enforces SLA-based remediation, documents exceptions, and uses automation and compensating controls where necessary. For small businesses, focus on a tight inventory, prioritized SLAs, integrated tooling, and traceable evidence — those are the elements auditors and assessors look for when validating compliance.
