Vulnerability scanning is foundational to CMMC. You cannot know what to fix if you don’t know what’s broken. RA.L2-3.11.2 requires that you scan everything in scope, on a schedule that actually works, and that you respond when new vulnerabilities hit the wire.
Scanning feeds your risk assessment and your remediation process. Every vulnerability you find must go somewhere: either fixed, or documented in your POA&M. The findings also feed into your configuration management baseline since misconfigurations often show up as scan findings.
What the assessor is actually evaluating
The assessor will verify three things:
Scope completeness: They will ask you to list all systems in scope. Then they will ask you to show scans of all those systems within the past 30-90 days (depending on your policy). They will spot-check by selecting 3-5 systems and asking “Show me the most recent scan of this server.” If you cannot, that is a finding.
Scan frequency: Your policy states a schedule (e.g., “monthly scans of all systems, weekly scans of internet-facing systems”). The assessor will pull scan logs and verify the schedule was actually followed. Missed scans are gaps.
New vulnerability response: When CVEs are released (especially critical ones), your organization should respond. This might mean scanning within 24-48 hours of a high-severity disclosure, or at minimum, having a documented process for when and how you scan for new threats. The assessor wants to see proactive action, not passive waiting until the next scheduled scan. When you find a critical vulnerability in scan results, your incident handling process should kick in to determine if it’s been exploited.
What a realistic SSP definition looks like
Policy: “The organization performs vulnerability scans on all in-scope systems quarterly and after each major system update. Internet-facing systems are scanned monthly. When a critical CVE is announced, IT performs an emergency scan within 48 hours.”
Supporting details:
- Scan tool: Tenable Nessus, configured with up-to-date plugins.
- In-scope systems: 12 servers, 8 workstations, 3 network devices, 2 cloud resources.
- Scan schedule: First Tuesday of each month (all systems), within 48 hours of critical CVE disclosure.
- Remediation process: Scans are reviewed by the IT manager within 24 hours. Findings are logged and assigned remediation dates based on severity.
How to present your evidence
- Scan policy document: Defines scope, frequency, tools, and roles. Should be approved and dated.
- Scan reports: Pull 4-6 recent reports covering the past 90 days. Show scans of different system types (servers, workstations, cloud, network devices). Include the scan date and the systems scanned.
- Scan execution logs: From your scanner’s management interface or SIEM. Shows scan start/end times and which systems were targeted.
- New vulnerability response log: Document your process for responding to CVE disclosures. Show 1-2 examples where you scanned within your defined timeframe after a high-severity CVE.
- Asset inventory: A list of all in-scope systems with dates verified. The assessor will cross-reference this against scans to confirm nothing was missed.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Assessor: “Walk me through your vulnerability scanning process. How often do you scan, and what systems are included?”
You: “We scan all 23 in-scope systems quarterly, and internet-facing systems monthly. The scan tool is Nessus. We pull reports monthly and track remediation.” [Pull up scan policy and last three monthly reports]
Assessor: “Show me the most recent scans of those three servers over there.” [Points at a list of specific systems]
You: [Pull up scan reports from the past 30 days showing all three systems were scanned]
Assessor: “What happens when a critical CVE is released?”
You: “We scan within 48 hours and prioritize any findings. Here’s our response to the Log4Shell CVE in December. We scanned on December 10th, two days after disclosure.” [Pull up scan report with timestamp]
Common failures
Scanning only production: Many organizations scan servers but skip workstations, network devices, or test environments. If it is in scope, it must be scanned. The assessor will ask for a complete list of in-scope systems and then ask to see scan coverage of each type.
Inconsistent scan execution: Policy says “monthly,” but you have scans from January, March, and then nothing until June. Explanations like “we were busy” will not work. Document that the scan schedule was followed or update the policy to match reality.
No response to new vulnerabilities: A critical CVE is announced, and your next scan happens 6 weeks later at the regularly scheduled time. The assessor may ask about your process for urgent threats. Have a documented response procedure, even if it is brief.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Evidence of a strong scanning program: Scan reports with findings, then separate records showing how and when those findings were remediated. This shows the full cycle: discover, prioritize, fix, verify.
Proactive new-vulnerability monitoring: A documented process that references sources like CISA alerts or vendor security bulletins. When a critical CVE drops, you know how to respond and can show you did.
If you use an MSP/MSSP
If your MSP performs vulnerability scans on your behalf, you are still responsible for ensuring the process meets CMMC requirements. Get copies of scan reports monthly, verify that all your systems are being scanned, and confirm that the MSP’s scan schedule aligns with your policy. Include the MSP’s scanning process in your SSP and document the agreement that they will scan on your defined schedule.
This guide is for reference only and does not replace official CMMC documentation or professional compliance advice.