Vulnerability Management for CMMC Level 2: Building a Program That Survives a C3PAO Assessment

Vulnerability management sounds simple on paper. Scan the environment. Find the weaknesses. Patch them. Move on.

In practice, it is one of the most common areas where defense contractors lose points during a CMMC Level 2 assessment.

Assessors do not just want to see a scan report. They want to see a program. They want evidence that scans run on a defined cadence, that findings are triaged, that critical vulnerabilities have owners and deadlines, that unpatched risks are tracked through a Plan of Action and Milestones, and that the whole cycle is documented, repeatable, and produces outcomes. A one-time Tenable scan run the week before an assessment does not clear this bar.

The Risk Assessment family in NIST SP 800-171 — practices 3.11.2 and 3.11.3 in Rev 2, and their expanded equivalents in Rev 3 — is where most of this lives. But vulnerability management also touches System and Information Integrity (3.14.1 flaw remediation), Configuration Management (3.4.1, 3.4.2), Audit and Accountability, and even Security Assessment and Monitoring. It cuts across the program.

This article walks through what a defense contractor's vulnerability management program should look like in 2026, what C3PAO assessors actually test, and where small and mid-sized contractors most often stumble.

The Requirements, In Plain English

The DoD does not tell contractors which scanner to buy or how often to patch. It tells them what outcomes to produce.

The two NIST 800-171 practices doing most of the work here are:

• 3.11.2 — Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
• 3.11.3 — Remediate vulnerabilities in accordance with risk assessments.

Read those two sentences carefully. There are actual verbs in there. Scan. Periodically. When new vulnerabilities are identified. Remediate. In accordance with risk assessments.

Every one of those verbs becomes a question during an assessment.

• How often do you scan?
• What triggers an off-cycle scan?
• How do you know about new vulnerabilities before your scanner catches them?
• How do you prioritize what to fix first?
• How fast do you fix critical issues?
• Where does the evidence live?

If the answers to those questions are not documented, defensible, and consistently applied across the CUI environment, the practice is not "MET" — it is "NOT MET" or, at best, "MET" with heavy qualification.

Rev 3 of NIST 800-171 sharpens the expectation. The updated controls emphasize continuous vulnerability monitoring, authenticated scanning where feasible, and integration with software supply chain risk information. Defense contractors still assessed against Rev 2 today should design programs that satisfy Rev 3 too. The transition is coming, and rebuilding a program under audit pressure is expensive.

Start With Scope, Not Scanners

The first question is not "which tool?" It is "what am I scanning?"

The scope of vulnerability management should mirror the CUI assessment boundary. Every system that processes, stores, or transmits Controlled Unclassified Information — plus every system that provides security functions to those systems — needs to be in scope.

That includes:

• Workstations and laptops used by employees who touch CUI
• Servers hosting CUI file shares, ERP systems, engineering data, or contract documents
• Network infrastructure inside the CUI boundary: firewalls, switches, wireless controllers, VPN concentrators
• Cloud tenants and SaaS platforms where CUI is stored (GCC High tenants, cloud file stores, engineering platforms)
• Managed devices used by remote workers
• Security tooling itself — the SIEM, EDR consoles, MFA platforms, backup systems

Assessors will ask for an inventory. If the inventory does not match what is scanned, that mismatch alone can cause findings. Practice 3.4.1 — establish and maintain baseline configurations and inventories — is where this evidence starts. The scan target list and the asset inventory should reconcile.

External service providers complicate this. If a Managed Service Provider or a cloud provider is scanning parts of the environment on the contractor's behalf, the contractor still owns the outcome. Assessors will ask for the MSP's scan reports, the shared responsibility matrix, and evidence that the contractor reviews the results — not just that they are produced.

Scan Cadence: What "Periodically" Actually Means

NIST does not define a frequency. The DoD does not define a frequency. Assessors do not have a fixed number either. But there is an emerging norm.

For most defense contractors handling CUI at Level 2, a defensible cadence looks like:

• Authenticated vulnerability scans of the CUI environment: monthly, at minimum. Weekly is better and increasingly expected for critical infrastructure.
• External-facing systems: weekly.
• Web applications that expose CUI or authentication surfaces: at least quarterly, with dynamic testing.
• Ad hoc scans: immediately after significant changes — a new firewall rule, a new application deployed, a new server built, a major software update, a new office location joined to the network.
• Emergency scans: within days of major CVE disclosures affecting technology in the environment.

Whatever cadence is chosen, it needs to be written down in a Vulnerability Management Policy or Standard, followed consistently, and evidenced with dated scan artifacts. A policy that says "monthly" and a scan history that shows a 47-day gap will be flagged.

Authenticated scanning matters more than most contractors realize. Unauthenticated scans miss the majority of real risk on modern endpoints and servers. Assessors have seen the industry data too. If scans run without credentials against systems that could accept credentials, expect questions.

Prioritization: The Part That Gets Skipped

Every scanner will produce hundreds — sometimes thousands — of findings the first time it runs against a defense contractor's network. The temptation is to sort by severity, patch the criticals, and stop.

That approach fails assessments and fails engineering reality.

A defensible prioritization model considers three things:

1. Severity of the vulnerability — CVSS score, but also whether the vulnerability is known to be exploited in the wild. The CISA Known Exploited Vulnerabilities catalog is treated by assessors as a floor. Anything on the KEV list needs a fast remediation timeline.
2. Exposure of the asset — a critical vulnerability on an internet-exposed server is not the same as a critical vulnerability on an air-gapped test machine. Compensating controls change the calculus.
3. Business context of the asset — a server holding engineering CAD files for a live DoD program is more important than a print server.

The output of that prioritization should be documented service level agreements — patch SLAs — that the contractor commits to and can prove they follow. A common structure:

• Critical (KEV or CVSS 9.0+ on CUI-relevant systems): 15 days
• High: 30 days
• Medium: 60 days
• Low: 90 days or accepted risk

Numbers can vary. What matters is that they exist, they are written down, and the evidence shows they are honored — with documented exceptions where they are not.

Where the POA&M Fits

Not every vulnerability gets patched on schedule. That is normal. Legacy applications, vendor-locked systems, integration testing windows, and business-critical downtime windows all create real constraints.

CMMC anticipates this. Vulnerabilities that cannot be remediated on the standard schedule should be moved into the Plan of Action and Milestones with:

• A description of the vulnerability and the affected assets
• Why it cannot be remediated on the normal cadence
• What compensating controls are in place
• The target remediation date
• The owner
• A status field that is updated on a regular cycle

A POA&M is not a graveyard. Assessors expect movement. If the POA&M shows the same twelve items with the same target dates for eighteen straight months, the program is not managing risk — it is deferring it.

TalonPoint's PolicyPack includes a Vulnerability Management Policy template and a POA&M tracker that ties findings to owners and dates, which is where most contractors need help. The policy without the tracker is a piece of paper. The tracker without the policy is a spreadsheet. Both need to work together.

Patch Management as an Operational Discipline

Vulnerability management is not just scanning. It is closing the loop. And closing the loop means a working patch management process.

For defense contractors, patch management needs to cover:

• Operating system patches on servers, workstations, and network equipment
• Application patches for browsers, PDF readers, engineering tools, ERP clients, remote access clients
• Firmware updates on network gear, storage, and out-of-band management interfaces (iDRAC, iLO, BMC)
• Cloud and SaaS platform updates where the contractor has responsibility
• Container and image updates in any containerized workloads
• Managed device fleet updates for remote workers

Each of these needs an owner. Each needs a testing path — even if that testing path is "test in a small pilot ring, then push widely." Each needs deployment evidence — patch reports from the endpoint management platform, WSUS or Intune reports, cloud tenant compliance dashboards.

Assessors will ask for randomly sampled evidence. "Show me that KB5049622 was applied to workstation LT-EXAMPLE-047." If the answer is "let me get back to you tomorrow," the finding is written.

The Cloud and SaaS Blind Spot

One of the most common blind spots in defense contractor vulnerability management programs is the cloud.

Microsoft 365 GCC High, AWS GovCloud, cloud engineering platforms, DevOps toolchains, project management SaaS — all of these can hold CUI or authentication surfaces to CUI systems. The shared responsibility model means the contractor is not scanning the underlying infrastructure, but the contractor is absolutely responsible for the configuration, the identity layer, and the access policies.

A vulnerability management program that stops at the on-prem firewall is incomplete. Cloud posture needs to be reviewed at least as often as on-prem systems are scanned. That means:

• Cloud Security Posture Management tooling or equivalent manual review
• Regular review of admin roles and privileged access
• Regular review of external sharing configurations
• Conditional Access and identity policy review
• SaaS third-party integration inventory

The contractor's Vulnerability Management Policy should explicitly name cloud tenants as in-scope.

Common Failure Modes

After watching enough defense contractor assessments, the failures cluster around the same handful of themes.

1. Scans run but no one reads them. Reports sit in a folder. No triage. No tickets. No follow-through.
2. The scanner does not cover the whole environment. A subnet is missed. Remote worker laptops are not enrolled. A cloud tenant is out of scope.
3. Scans run unauthenticated. Findings look clean. Reality does not match.
4. Patch SLAs exist on paper but not in practice. Critical vulnerabilities linger for months without POA&M entries.
5. No integration between vulnerability findings and change management. A patch gets deployed, but there is no ticket, no approval, no rollback plan.
6. No differentiation between CUI and non-CUI systems in prioritization. Everything is treated equal, which usually means nothing gets prioritized.
7. External Service Provider evidence is missing. The MSP scans, but the contractor cannot produce the reports on request.

Every one of these is preventable with a written policy, a documented process, and evidence retention discipline.

The Assessor's Evidence Checklist

When a C3PAO arrives, they will ask to see, at a minimum:

• The Vulnerability Management Policy
• The scan schedule and configuration
• The last six to twelve months of scan reports
• The remediation ticket queue or POA&M
• Evidence of patches deployed on the required timeline
• Change management records tied to remediation
• Exception documentation for anything not patched on schedule
• Evidence that findings are reviewed by security leadership on a recurring basis
• Coverage evidence tying scan targets to the asset inventory
• Any external service provider scan reports for systems in scope

Contractors who can produce all of this in one working session tend to pass. Contractors who need to reconstruct it during the assessment tend to struggle.

Building the Program If You Do Not Have One Yet

For a small or mid-sized defense contractor starting from close to zero, a realistic six-week build looks like:

• Week 1: Document the CUI boundary and asset inventory. Reconcile against DHCP, endpoint management, and cloud tenant admin consoles.
• Week 2: Select and deploy an authenticated scanner covering the boundary. Configure credentials, schedules, and scope. Common choices in this market include Tenable Nessus/Tenable.io, Rapid7 InsightVM, Qualys, and Microsoft Defender for Endpoint's built-in vulnerability management.
• Week 3: Draft the Vulnerability Management Policy. Define cadence, prioritization, SLAs, roles, and exception handling. TalonPoint's PolicyPack ships a Level 2-ready template that maps cleanly to 3.11.2, 3.11.3, and 3.14.1.
• Week 4: Stand up the ticketing and POA&M workflow. Every finding above the threshold becomes a ticket with an owner and a due date.
• Week 5: Run the first full authenticated scan cycle. Triage the results. Kick off the first remediation waves.
• Week 6: Review with security leadership. Document the review. Add cloud posture review to the recurring calendar. Set the next scan and next review dates.

At the end of six weeks the contractor does not have a mature program. They have a defensible foundation. Maturity comes from repeating the cycle month after month and letting the evidence build.

The Bottom Line

Vulnerability management is not glamorous. There is no dashboard that turns a red program green overnight, no product that eliminates the need for the operational discipline underneath. The contractors who do this well have three things in common: a written policy that matches what actually happens, an operational cadence that produces evidence without heroics, and a POA&M that is honest about what is not yet fixed.

That is the program a C3PAO wants to see. That is the program the DoD is asking for when it points to 3.11.2, 3.11.3, and 3.14.1. And that is the program that keeps CUI safe long after the assessment is over — which, in the end, is the actual point.

If your team is putting a vulnerability management program together for a Level 2 assessment and wants a starting policy pack, TalonPoint's PolicyPack includes the Vulnerability Management Policy, the POA&M template, the Configuration Management Policy, and the surrounding controls in one bundle. It will not run the scans for you. It will keep you from writing the policy from scratch at 11 p.m. the week before your assessor arrives.