Stealth Technology Group Team
Ask a defense contractor whether they scan for vulnerabilities and the answer is almost always yes. Ask them to show the evidence that supports it, and the conversation changes. A single scan report from last month. A dashboard screenshot. A spreadsheet of findings with no dates, no owners, and no indication that anything was ever fixed. The security work may be real, but the proof of it is thin, and in a CMMC Level 2 assessment the proof is what gets scored.
Vulnerability management sits in the Risk Assessment and System and Information Integrity domains, and it is one of the places where the gap between doing the work and demonstrating the work is widest. This article explains what assessors are actually evaluating, which artifacts answer their questions, and where scan evidence most often falls short.
What the Practices Actually Require
Several NIST SP 800-171 requirements bear directly on vulnerability management. Practice 3.11.1 calls for periodically assessing risk to operations and assets from the operation of systems that process CUI. Practice 3.11.2 requires scanning for vulnerabilities periodically and when new vulnerabilities affecting those systems are identified. Practice 3.11.3 requires remediating vulnerabilities in accordance with risk assessments. Practice 3.14.1 requires identifying, reporting, and correcting system flaws in a timely manner, and 3.14.3 requires monitoring security alerts and advisories and acting on them.
Read together, these describe a cycle rather than an event: define how often you scan, scan that often, scan again when something significant is disclosed, prioritize findings by risk, fix them within a defined timeframe, and keep monitoring advisories for what the scanner has not yet learned about. The NIST SP 800-171 text states the requirements, and the companion NIST SP 800-171A assessment guide breaks each one into determination statements that assessors use to decide Met or Not Met. Reading the 800-171A objectives for these practices is the most direct way to understand what your evidence has to support.
The important point is that every objective is about whether something happened, repeatedly, within a defined framework. A scan report proves that one scan ran. It does not prove that your program defined a frequency, followed it, prioritized findings, and closed them.
The Evidence Assessors Expect to Examine
Assessors work through three methods: examine documents and records, interview the people responsible, and test the technical implementation. For vulnerability management, the artifacts that satisfy the examine method generally fall into six groups. A documented policy or procedure that defines the scanning frequency, the scope, the scanning method, and the remediation timelines. If the frequency lives only in someone’s head, objective 3.11.2 has no defined frequency to measure against.
A scan history rather than a single scan. Reports from multiple periods, showing the schedule was followed. Assessors are looking for continuity, and a series of dated reports across several months communicates something a lone report cannot. Scope reconciliation. Evidence that the assets scanned match the assets in scope, which means comparing scan targets to the asset inventory in the System Security Plan. Systems that appear in the inventory but not in the scan results are the finding that surprises organizations most.
Prioritization records. Documentation of how findings were ranked, ideally showing more than raw severity scores. Remediation records. For each significant finding, the date identified, the owner, the target date, the date fixed, and confirmation that the fix worked.
Exception records. For findings that remained open past their target, a documented decision with compensating controls and a review date. When these six groups exist and connect to each other, the assessor is verifying a program. When only the first scan report exists, the assessor is investigating one.
Scan Scope: The Most Common Place to Lose Points
Scope problems account for a disproportionate share of vulnerability management findings, and they usually come from good intentions. The team scans what is easy to scan and assumes the rest is covered.
The assessment boundary is defined by where CUI is stored, processed, or transmitted, plus the security protection assets that support it. Your scan scope needs to include all of it. That means servers and workstations, but also firewalls, switches, VPN concentrators, hypervisors, and cloud resources inside the boundary. Edge devices deserve particular attention because they are directly exposed and frequently omitted. Our guide on how to scope your CMMC environment correctly explains how the boundary is drawn, and the scan scope has to follow it.
Method matters as well. Unauthenticated scans, which probe a system from the network, miss much of what lives on the host: missing patches, vulnerable third-party applications, insecure configurations. Authenticated scans log in using a service credential and see the system from the inside. Assessors often ask whether scans are authenticated, and a scan configuration that shows credentialed access is stronger evidence than a report that does not say. If some systems cannot be scanned with credentials, document why and what compensates.
Finally, the asset inventory has to stay current. A scan scope built from a spreadsheet that has not been updated since the last refresh will faithfully scan systems that no longer exist and silently skip the ones that do. Mature programs tie scanning to discovery so that new assets enter the scope when they appear.
Frequency: Define It, Follow It, and Trigger Extra Scans
Practice 3.11.2 has two parts that organizations often collapse into one. The periodic scan happens on a schedule you define. The event-driven scan happens when new vulnerabilities affecting your systems are identified.
For the periodic part, the CMMC rules do not dictate a specific interval, which means yours has to be defensible and followed. Monthly is common for internal systems, with more frequent scanning for internet-facing assets. What assessors look for is that the stated frequency matches the evidence. A policy that says monthly, backed by quarterly reports, is a gap even though quarterly scanning might have been reasonable on its own.
The event-driven part is less often addressed. When a significant vulnerability is disclosed, especially one being actively exploited, the program should be able to show that it assessed exposure and scanned for it. The CISA Known Exploited Vulnerabilities catalog is a good trigger source, because entries there represent confirmed exploitation rather than theoretical risk. A short log showing that a newly listed vulnerability was reviewed against your environment, scanned for, and addressed demonstrates exactly the responsiveness 3.11.2 describes and 3.14.3 expects. The National Vulnerability Database supports the same workflow for broader coverage.
Prioritization and Remediation Timelines
Scanners produce long lists. The value of a vulnerability program shows in how it decides what to fix first, and assessors want to see that decision-making reflected in the records.
A defensible approach starts with severity but does not stop there. Active exploitation, available exploit code, internet exposure, and the system’s role in the CUI environment all change real-world risk. A medium-severity flaw on an internet-facing system that is being exploited should outrank a critical flaw on an isolated internal system with compensating controls, and your records should show that reasoning when it applies.
Remediation timelines should be defined in advance and tied to priority tiers. The specific durations are your decision, but a common structure gives the shortest windows to actively exploited vulnerabilities, a few weeks to high-severity findings, and longer windows to lower tiers. What matters is that the policy states the timelines, the records show findings closed within them, and exceptions are documented when they were not.
Verification closes the loop. A finding is not remediated because a ticket says patched. It is remediated when a follow-up scan no longer detects it. Programs that rescan after remediation and keep the confirming results have evidence that the fix actually worked, which is stronger than evidence that a fix was attempted. For help building this discipline without dedicated security staff, see our guide to vulnerability management as a service.
Handling Exceptions Without Creating Findings
Every real environment contains systems that cannot be patched on schedule. A vendor has not released a fix. A production system cannot be restarted until the next maintenance window. A legacy device runs software that breaks when updated. These are normal, and a well-run program handles them openly.
The record for an exception should state the finding, the reason it cannot be remediated on schedule, the risk assessment, the compensating controls in place, the approver, and an expiration or review date. Compensating controls might include network isolation, restricted access, or enhanced monitoring of the affected system. Exceptions that carry these elements show risk-based decision making. Exceptions that do not, meaning findings that simply sit past their deadlines with no explanation, are what assessors cite.
Operational technology deserves specific mention. Shop floor systems and inspection equipment often cannot take patches or agents, and an unpatchable machine on a flat network is exactly the kind of exposure that turns into an incident. The scenario in Second Shift, a Ransom Note on the Shared Drive, and Nothing Ships This Week shows how an unpatchable inspection PC became the entry point, which is a useful reminder that documenting a limitation is not the same as managing it. Segmentation and monitoring are the compensating controls that make an exception credible, and our guide on CMMC for manufacturers covers how to document them for OT environments. Where a gap cannot be closed before an assessment, it belongs in your plan of action. See our POA&M guide for how to record it credibly.
Connecting Scan Evidence to the System Security Plan
Evidence does not stand alone. Assessors compare what the System Security Plan says with what the records show, and inconsistencies between the two are findings in their own right.
The SSP’s description of how vulnerability scanning works should match reality in specifics: which tool, how often, authenticated or not, what scope, who reviews results, and how remediation is tracked. If the SSP says weekly and the history shows monthly, or names a tool the organization no longer uses, the document undermines the evidence. Our guide on creating a System Security Plan covers how to write control descriptions that point to verifiable artifacts instead of making general claims.
The risk assessment is the other connection point. Practice 3.11.1 expects periodic risk assessment, and vulnerability findings should feed it. A risk assessment that references scan results, open exceptions, and remediation trends shows that vulnerability data informs decisions rather than sitting in a folder. The same continuity applies to the POA&M. Findings that cannot be closed on time and are not covered by an accepted exception should appear there, with owners and dates.
Interviews and Technical Testing
Documents are one of three methods. Assessors will also talk to the people who run the program and may verify the technical implementation directly.
In interviews, expect questions like these. How often do you scan, and who decides? What happens when a critical vulnerability is announced? How do you know a patch worked? Who approves an exception? The person responsible should be able to answer from daily practice. An administrator who has never seen the scan configuration, or who describes a process different from the documented one, creates doubt about the whole program. Preparation that matters here comes from involving the right people in the work throughout the year, not from briefing them the week before.
Technical testing can include reviewing the scanner configuration, checking credentials and scan policies, sampling a few findings and tracing them to remediation, and comparing patch levels on selected systems against what the reports claim. If a report says a system is patched and a spot check shows otherwise, the finding extends beyond that system to the reliability of the reporting. This is one reason verification rescans are valuable: they make the reports trustworthy.
Common Gaps in Vulnerability Evidence
The patterns that appear most often are consistent enough to check for in advance.
Scan history that is too short or irregular, with gaps between reports that contradict the stated frequency. Scope that does not match the asset inventory, particularly missing network devices and cloud resources. Unauthenticated scanning presented as comprehensive. Findings lists with no owners, dates, or closure records. Open critical findings well past their targets with no documented exception. Event-driven scanning that is claimed but never evidenced. And SSP language that describes a more mature program than the records support.
Each of these is fixable, and most are fixable cheaply if addressed early. A readiness assessment applying assessor standards will surface them while there is time to build the history that fixes them, which is the point of the preparation steps in our CMMC audit preparation guide. Scan history in particular cannot be created retroactively, so starting the cadence early is the one fix that cannot be rushed later.
Making the Evidence a Byproduct of Operations
Organizations that struggle with vulnerability evidence usually treat it as a documentation task performed before an assessment. Organizations that handle it well treat it as an output of a program that runs continuously, so the evidence exists whether or not anyone is about to ask for it.
That is the design principle behind a managed approach. When scanning, patching, remediation tracking, and exception handling are operated as a single service, the scan history, remediation records, and verification results accumulate automatically, in a consistent format, and map to the practices they support. Stealth Technology Group’s CMMC compliance program and cybersecurity services are built this way, with managed IT services handling patching under the same accountable team so findings and fixes stay connected.
For organizations with internal IT staff, a co-managed IT arrangement can take on the scanning and evidence discipline while internal staff retain their operational role. A vCIO adds the reporting that gives leadership visibility into remediation performance, and the broader compliance program keeps the evidence organized for assessment. Our guide on strengthening cybersecurity covers how vulnerability work fits within a sequenced security program, and defense contractors in Boston, Tampa, and Sarasota can work with a team that has produced this evidence for regulated clients.
Conclusion
Assessors are not asking whether you own a scanner. They are asking whether your organization defined a vulnerability management process, followed it consistently, prioritized by risk, fixed what it found, verified the fixes, and handled the exceptions responsibly. A single report answers none of that. A history of scans, matched to your asset inventory, with prioritization, remediation, verification, and documented exceptions, answers all of it.
Start the cadence early, keep the scope honest, rescan after fixes, and make sure the System Security Plan describes what you actually do. The evidence that results will also be the evidence that your environment is genuinely harder to attack.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
