Vulnerability scanning is one of the most visible, measurable controls an organization can use to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control RA.L2-3.11.2; building a defensible schedule that defines frequency, scope, and reporting in practical terms is what turns a checkbox into real risk reduction. This post provides a step-by-step approach to design and operate a scanning program tailored to small and mid-size organizations operating under the Compliance Framework, with concrete examples, tool guidance, reporting templates, and SLAs so you can present evidence to auditors and reduce the likelihood of compromise.
Understanding RA.L2-3.11.2 and how to interpret "frequency, scope and reporting"
RA.L2-3.11.2 expects an organization to perform vulnerability scanning at a frequency sufficient to identify and remediate vulnerabilities in systems that process, store, or transmit Controlled Unclassified Information (CUI). Translate that into a policy that states: (1) how often you scan by asset criticality, (2) what assets are in scope, and (3) the content and retention of scan reports and remediation evidence. For Compliance Framework implementation, map assets to your System Security Plan (SSP) and Plan of Action & Milestones (POA&M) so scans are tied to formally documented CUI boundaries.
Designing a practical scanning schedule
Use a risk-based cadence rather than a single universal frequency. A practical sample schedule for a small business (50–250 employees) might be: weekly authenticated internal scans for critical servers (domain controllers, CUI hosts), biweekly authenticated scans for business-critical applications and databases, monthly external internet-facing scans, quarterly full internal scans (credentialed), and immediate scans after any major change or patch cycle. For environments using cloud services, add automated container/image scans on build and weekly host/agent scans. Document the schedule in your vulnerability management policy and implement it in your scanning tool's scheduler.
Authenticated vs unauthenticated scans and scan configuration
Authenticated (credentialed) scans are essential for accurate coverage—configure SSH or Windows service account credentials stored in a secrets vault (e.g., HashiCorp Vault, AWS Secrets Manager) and allow scanner access with least privilege. Use credentialed checks for missing patches, configuration issues, and local checks; use unauthenticated scans externally to verify exposed services. Technical scan configuration examples: run full TCP/UDP port discovery on 1–65535 for internal scans where permitted, limit UDP scans to common ports (53, 123, 161) if you lack bandwidth, and enable plugin families for OS/patch checks. Log scanner versions, plugin set, and scan policy as part of each report to show reproducibility.
Defining scope and maintaining an asset inventory
Scope everything that processes or stores CUI and its supporting infrastructure—application servers, databases, admin workstations, cloud instances, network devices, remote access gateways. Use an authoritative asset inventory (CMDB or spreadsheet) with tags: business owner, criticality, CUI present (Y/N), scanner grouping. For small businesses with hybrid environments, a practical approach is to maintain three scan groups: Internet-facing (external IPs), Internal CUI class (critical hosts, authenticated scans), and General internal (workstations, non-CUI systems). Use network segmentation to reduce scan blast radius and limit scheduling windows for production systems.
Reporting: what auditors expect and how to present evidence
Reports should be structured, repeatable, and retained. At minimum, each scheduled report must include: scan date/time, scanner/tool/version, scope (IP list / asset IDs), scan policy and credential type used, vulnerability list with CVSS scores and plugin IDs, remediation status and ticket references, and raw export (XML/CSV). Small-business example: produce a weekly remediation digest for technical teams (detailed list with ticket links) and a monthly executive summary for auditors showing open counts by severity over time, SLA compliance, and any accepted risks with documented compensating controls. Retain raw scan data and reports for at least 12 months to demonstrate trend analysis during an assessment.
Operational details: tools, scheduling windows, and false positives
Choose tools that match your environment and budget—Nessus, OpenVAS/Greenbone, Qualys, and Rapid7 InsightVM are common; cloud-native options include AWS Inspector and Azure Security Center. For endpoints, consider lightweight agents (e.g., Qualys/InsightVM agents) to increase coverage and reduce network impact. Schedule scans during low business hours where possible and use non-destructive checks for sensitive systems; document exceptions and maintenance windows in change control. To handle false positives, implement a documented triage workflow that includes validation steps, proof-of-concept checks, and marking plugins as false positive with memos stored alongside the scan evidence.
Triage, remediation SLAs and integration with change management
A schedule without a remediation pathway is ineffective. Define severity thresholds and SLAs (example: Critical—24–72 hours; High—7 days; Medium—30 days; Low—90 days) and enforce these through ticketing (Jira, ServiceNow) and patch automation (WSUS/SCCM, Ansible, cloud provider tools). For small businesses, a pragmatic SLA might be Critical 72 hours, High 14 days, Medium 30–60 days, Low 90 days—document any deviations as accepted risks with owners and timelines in your POA&M. Integrate scans into your change-management pipeline so that a successful remediation (patch applied + verification scan) automatically closes the remediation ticket, producing an audit trail.
Failing to implement a repeatable schedule increases the risk of undetected vulnerabilities being exploited—this can lead to breach of CUI, contract loss, notifications, and penalties. From a compliance perspective, missing documented frequency, inconsistent scope, or insufficient reporting will result in findings during a CMMC assessment or NIST-based audit. Beyond compliance, attackers frequently exploit known, unpatched vulnerabilities; regular scanning with timely remediation materially reduces exposure.
Summary: build a risk-based schedule tied to your SSP, use authenticated scanning for internal hosts, perform regular external scans, retain and structure reports to show frequency and remediation, and enforce SLAs through ticketing and change management. For small businesses, start with a practical cadence (weekly for critical assets, monthly external, quarterly full scans), use affordable or cloud-native tools, and keep evidence organized—this delivers both security benefit and defensible compliance with RA.L2-3.11.2.
