StealthTech
A prime contractor’s compliance lead once told us their vulnerability management program consisted of a monthly Nessus report that landed in an inbox and stayed there. Nobody was assigned to remediate anything. Nobody tracked how long a critical finding sat open. The scan ran, the PDF got filed, and the box got checked. That approach might have survived a self-attestation under the old model. It will not survive a C3PAO assessor asking to see remediation timelines against a documented policy.
Vulnerability management under CMMC is not a single control you can knock out with a scanning tool and a calendar reminder. It sits at the intersection of RM.L2-3.11.2 (scan for vulnerabilities), RM.L2-3.11.3 (remediate them in accordance with risk), and a handful of supporting practices around configuration baselines, audit logging, and system inventory. Assessors don’t just want to see that scans happen. They want evidence that findings move through a defined lifecycle, on a defined schedule, with defined ownership — and that the organization can prove it did this consistently, not just in the weeks before the assessment.
Why Vulnerability Management Became a Scored Control, Not a Best Practice
Under DFARS 252.204-7012, contractors handling Controlled Unclassified Information have been on the hook for NIST SP 800-171 compliance since 2017. What changed with CMMC is verification. Self-attestation gave organizations room to describe their vulnerability program in aspirational terms. A third-party assessment strips that away, because the assessor is asking for artifacts: scan logs, ticket histories, remediation SLAs, and proof that exceptions went through a documented risk acceptance process rather than just quietly aging past their due date.
This matters more for vulnerability management than almost any other control family because it’s inherently a moving target. A firewall configuration, once set correctly, tends to stay correct until someone changes it. A vulnerability posture changes every time a new CVE gets published, which happens daily. NIST’s National Vulnerability Database adds hundreds of new entries a month, and any one of them could apply to software your organization runs. A static compliance posture doesn’t work here — the program has to be built to run continuously, or it starts drifting out of alignment the day after the assessment ends.
The Scanning Cadence Assessors Actually Expect
There’s no single number written into 800-171 that says “scan every 30 days.” What assessors look for instead is a documented, risk-informed cadence that you actually follow. In practice, across the contractors we’ve worked with in Boston, Tampa, and Sarasota, a defensible baseline looks like this:
- Authenticated vulnerability scans of internal infrastructure at least monthly, covering servers, workstations, and any system in the CUI boundary
- External-facing scans of any internet-exposed assets weekly, since those are the systems most likely to be probed by opportunistic attackers
- A full scan immediately following any significant change — a new server build, a major application deployment, a network segmentation change
- Ad hoc scans triggered by newly disclosed critical CVEs affecting software in your environment, independent of the regular schedule
The mistake we see most often isn’t infrequent scanning. It’s scanning that isn’t authenticated, meaning the tool never logs into the host and only sees what’s visible from the network layer. That produces a report that looks thorough but misses local privilege escalation paths, missing patches on installed applications, and misconfigurations that only an authenticated scan surfaces. An assessor who understands scanning tools will ask directly whether scans are credentialed, and an unauthenticated scan history is a fast way to lose confidence in the rest of your evidence package.
Patching Windows: Setting SLAs You Can Actually Defend
Once a scan surfaces a finding, the clock that matters to an assessor is the one between discovery and remediation. Organizations that try to wing this — remediating “as soon as possible” — end up with wildly inconsistent timelines that are impossible to defend in an interview. A tiered SLA structure holds up much better:
Critical vulnerabilities, generally CVSS 9.0 and above or anything with known active exploitation, should carry a remediation target measured in days, not weeks — many contractors land on 15 days, some tighten it to 7 for internet-facing systems. High severity findings typically get 30 days. Medium and low severity findings can reasonably extend to 90 days, provided the organization isn’t using that window to simply ignore them.
The number itself matters less than consistency and documentation. An assessor reviewing your program isn’t going to argue that 15 days should have been 10. They will absolutely flag a program where the SSP says 30 days for critical findings and the ticket history shows findings sitting open for four months with no explanation. If you’re going to commit a number to paper, build a workflow that can actually hit it — which usually means integrating vulnerability findings directly into your ticketing system rather than managing them from a spreadsheet that someone updates sporadically. This is one of the areas where managed IT services infrastructure pays for itself: automated ticket creation from scan results removes the manual step where most remediation timelines quietly fall apart.
Scoping the Program Correctly Before You Scan Anything
A vulnerability management program that scans the wrong boundary produces evidence that doesn’t hold up under scrutiny, no matter how disciplined the cadence is. This is where scoping work has to happen before the scanning tool gets deployed, not after. CMMC assessors evaluate your environment against defined asset categories, and each category carries different expectations for how deeply it needs to be scanned and patched.
We’ve written in more depth about how scoping actually sorts your environment, but the short version for vulnerability management is this: CUI assets and Security Protection Assets need full authenticated scanning and aggressive remediation SLAs. Contractor Risk Managed Assets and Specialized Assets — think OT equipment, medical devices, or legacy manufacturing controllers that can’t tolerate a standard agent — need a documented alternative approach, whether that’s network-based scanning, compensating controls, or isolation. What an assessor will not accept is a Specialized Asset that got excluded from scanning with no explanation at all. The exclusion has to be a decision, not an oversight.
Where Contractors Get Caught: Undocumented Exceptions
The single most common finding we see in mock assessments isn’t a missing patch. It’s a patch that’s missing and nobody can explain why. A vulnerability sat open past its SLA, and there’s no record of a risk acceptance, no compensating control, no documented rationale — just silence. Assessors read that silence as a program that isn’t actually being managed, even if the underlying technical risk is low.
The fix is procedural, not technical. Every vulnerability that blows past its remediation SLA needs a decision trail: either it gets patched, or someone with the authority to accept risk signs off on why it’s being deferred, what compensating control is in place in the meantime, and when it will be revisited. NIST SP 800-171A, the assessment procedures document that C3PAOs actually use to structure their interviews, spells out exactly what examine, interview, and test activities apply to RM.L2-3.11.3 — and “produce a document showing the exception was reviewed and approved” is squarely within what an assessor will ask to see. Building this into your process doesn’t need to be elaborate. A short-form risk acceptance memo, reviewed monthly by whoever owns cybersecurity oversight for the organization, closes this gap almost entirely.
Turning Scan Output Into Evidence an Assessor Can Actually Use
Raw scanner output is not evidence. It’s data. The distinction matters because a folder of PDF exports from your scanning tool tells an assessor that scans ran, but it doesn’t tell them anything about what happened after. The evidence package that actually satisfies an assessor connects three things: the scan that found the vulnerability, the ticket or work order that tracked its remediation, and the closure record showing when and how it was fixed.
This is also where audit logging intersects with vulnerability management in a way a lot of contractors don’t anticipate. If a critical finding gets remediated by applying a patch, the assessor may reasonably ask for log evidence that the patch was actually installed on the date claimed, not just that a ticket got marked closed. We cover the retention expectations around this in our piece on what AU.L2 requires and how long you have to keep logs, and the short answer is that your log retention window needs to comfortably outlast your remediation SLA, or you’ll have closed tickets with no way to substantiate them by the time the assessment happens.
Vulnerability Management and Configuration Management Are the Same Conversation
Organizations frequently build these as two separate programs — a vulnerability team running scans, a different function (or the same overworked engineer wearing two hats) managing configuration baselines — and then wonder why the two data sets contradict each other. A scan flags a missing patch on a server that configuration management documentation says is fully current. One of those two records is wrong, and an assessor who cross-references them will find the gap immediately.
The more durable approach treats patch level as a component of the configuration baseline itself, not a separate tracking exercise. When a system’s documented baseline includes its current patch state, a vulnerability scan becomes a verification mechanism against that baseline rather than an independent process running on its own schedule. We go into this in more detail in our article on why “it works” isn’t the same as a documented baseline, and the overlap with vulnerability management is exactly the kind of connective tissue assessors are trained to look for during interviews — they’ll often ask your configuration management owner and your vulnerability management owner the same question in different words just to see if the answers match.
Coordinating Vulnerability Management With Your MSP or ESP
If your IT is outsourced in whole or in part, vulnerability management is one of the control areas where the division of responsibility needs to be spelled out in writing, not assumed. CMMC assessors have gotten considerably more precise about how they evaluate External Service Providers, and a scanning and patching responsibility that’s unclear between a contractor and its MSP is a common gap. We break down what actually counts as an ESP and how that designation affects scoring in our guide on external service providers under CMMC, but the practical takeaway for vulnerability management specifically is that your shared responsibility matrix needs to state, in plain language, who runs the scans, who owns remediation SLAs, and who documents exceptions.
This is also a case where a co-managed IT model tends to outperform a fully outsourced or fully in-house approach, because it keeps an internal stakeholder with visibility into the CUI environment involved in prioritization decisions, while still giving the organization access to the scanning infrastructure and patch management tooling that a dedicated provider maintains. If you’re vetting a provider’s credentials on this front, the CyberAB Marketplace is the authoritative place to confirm whether a firm is a Registered Practitioner Organization rather than just claiming the designation on its website. A vCIO relationship works well here too, since remediation prioritization is ultimately a risk conversation, not a purely technical one — and someone needs to own that conversation at a level above the engineer running the scanner.
What Happens When a Vulnerability Turns Into an Incident
Vulnerability management doesn’t operate in isolation from incident response, and assessors will sometimes probe the connection directly: what happens if a critical vulnerability is discovered because it was already exploited, rather than caught by a routine scan? At that point you’re no longer in a remediation workflow, you’re in an incident response workflow, and the organization needs to know where that line is and who makes the call. We’ve written about the distinction between a policy document and an actual response plan in our piece on what IR.L2 actually demands, and the same principle applies here: a vulnerability management program that has no defined trigger for escalating to incident response is missing a control an assessor will specifically ask about.
CISA’s guidance on nation-state threat actors is worth building into internal training on this point, since a meaningful share of the exploitation activity targeting defense industrial base contractors traces back to state-sponsored groups specifically hunting for unpatched, internet-facing systems. A vulnerability that sits open for 90 days on a low-severity finding is a manageable risk. The same vulnerability sitting open on a system exposed to the internet, in an environment holding CUI, is a materially different conversation — and your program needs to be able to make that distinction without someone having to think it through from scratch every time.
Building a Program That Survives Staff Turnover and Audit Cycles
The programs that hold up year over year share a common trait: they don’t depend on one person’s institutional knowledge to function. If your entire vulnerability management process lives in the head of a single IT administrator, you have a single point of failure that an assessor will eventually expose, usually by asking a second person on your team a question they can’t answer.
A resilient structure documents four things clearly enough that a new hire could pick up the process from the written policy alone: the scanning schedule and tooling, the remediation SLA tiers, the exception and risk-acceptance workflow, and the escalation path into incident response. Backing all of this with reliable backup and data recovery practices matters too — if a patch deployment goes wrong on a production system, the ability to roll back cleanly is what keeps a routine remediation from turning into an outage that then becomes its own incident.
This kind of program design tends to look different depending on the environment. A defense manufacturing floor with legacy OT equipment has different scanning constraints than an engineering firm running mostly modern endpoints, and both look different again from a healthcare-adjacent contractor balancing CUI requirements against separate regulatory obligations. Whatever the environment, the underlying discipline is the same: scan on a defined cadence, remediate on a defined timeline, document every exception, and keep the records long enough to prove it.
Conclusion
Vulnerability management under CMMC rewards consistency over sophistication. An assessor doesn’t need to see the most advanced scanning platform on the market — they need to see a program that runs the same way every month, ties findings to tickets, closes tickets with evidence, and documents the handful of cases where something didn’t get fixed on schedule. Contractors who treat this as an ongoing operational discipline, rather than a pre-assessment scramble, consistently score better and spend far less time in the interview chair defending gaps in the record.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
