Field guide

What your vulnerability scanning evidence needs to show an assessor

Published 2026-11-09 · Last reviewed 2026-11-09

This is practical guidance on evidence, not legal advice. Your contract, your contracting officer and your counsel decide what applies to you.

I’m not a C3PAO, and I’m not listed in the Cyber AB Marketplace as a Registered Practitioner or Registered Provider Organization.

An assessor does not grade your scanner. They grade your evidence, one assessment objective at a time, and a single objective without evidence fails the whole requirement. A scan program that runs every week but can’t prove its scope, its authentication, or its fixes looks, on paper, like a program that doesn’t run. Missing evidence is not a clean result.

This guide walks through the three NIST SP 800-171 requirements that vulnerability scanning feeds most directly, lists every assessment objective for each, and says what evidence demonstrates it. It is written for IT and security managers in the defense industrial base preparing for a CMMC Level 2 assessment (self or third-party), but the same objectives make a good internal audit standard for any enterprise vulnerability management program.

Where things stand (as of 9 November 2026)

Which revision. CMMC assesses against NIST SP 800-171 Revision 2 and the June 2018 SP 800-171A assessment procedures. Both are incorporated by reference in 32 CFR 170.2. NIST withdrew Rev 2 on 14 May 2024 when it published Rev 3, but DoD has kept contractors on Rev 2: first through Class Deviation 2024-O0013, and now through the July 2026 implementing memo and the DFARS Part 240 class deviation (2026-O0025), both of which require “baseline compliance with NIST SP 800-171 Rev 2” under DFARS 252.204-7012.
Phase 2 is suspended. Under 32 CFR 170.3(e), Phase 2 was to begin on 10 November 2026, one year after the DFARS CMMC rule took effect on 10 November 2025. In Phase 2, DoD intended to require a Level 2 (C3PAO) status as a condition of award for applicable solicitations and contracts. Until 9 November 2028, the CMMC clause (DFARS 252.204-7021) goes only into solicitations and contracts where the program office or requiring activity specifies a CMMC level (Class Deviation 2026-O0025 Rev 3), so it was never every award. On 13 July 2026 the Department of War suspended that transition (DoW CIO memo), with implementing instructions from the Under Secretary of War for Acquisition and Sustainment. While the suspension lasts, requiring activities may designate only Level 1 (Self) or Level 2 (Self), and existing C3PAO and Level 3 requirements are being removed from solicitations and contracts.
What didn’t change. DFARS 252.204-7012 still applies. Level 1 and Level 2 self-assessments and SPRS submissions continue, and DoD says it will enforce Rev 2 through those self-assessments “and select Government-led assessments”. A Level 2 self-assessment uses the same objectives, findings and scoring as a certification assessment (32 CFR 170.16, 170.24), and a senior official affirms the result in SPRS after every assessment and annually thereafter (170.22). The CIO’s 60-day reform review ended in September; its report had not been published when I checked.

The suspension changes who checks your evidence and when. It doesn’t change what the evidence has to show.

How an assessor reads your evidence

The CMMC Assessment Guide, Level 2 (v2.13) is the current DoD guide, and it borrows its method from SP 800-171A. Four points from it shape everything below.

Three methods: examine, interview, test. The assessor reviews documents and records, talks to the people who do the work, and exercises the mechanism to “compare actual with expected behavior”. The guide says that interviews tell the assessor what staff believe, documents show policy, and testing “demonstrates what has or has not been done”. It adds: “Most objectives will require testing.” Expect to run a report or open a ticket live.
Findings are per objective. “One NOT MET assessment objective results in a failure of the entire security requirement.” Eleven of your thirteen scanning-related objectives being solid doesn’t help if the other two aren’t.
Evidence must be final. “Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies.” A scan SLA that lives in a draft procedure is not a defined SLA.
The scores are uneven. Under 32 CFR 170.24, RA.L2-3.11.2 (scanning) and SI.L2-3.14.1 (flaw remediation) are 5-point requirements, while RA.L2-3.11.3 (remediation) is worth 1 point. Under 170.21, a requirement worth more than 1 point can’t go on an assessment POA&M to earn a Conditional status (the one exception is SC.L2-3.13.11 when encryption is used but not FIPS-validated), and Conditional status also needs a score of at least 80%. If 3.11.2 or 3.14.1 is NOT MET, you have no Conditional status to fall back on.

Terms used here

Assessment objective: one of the lettered “determine if” statements ([a], [b], …) under each requirement in SP 800-171A. Each one gets its own MET, NOT MET or N/A finding.
Periodically: the guide defines it as a regular interval set by the organization “that may not exceed one year”.
Assessment POA&M vs operational plan of action: the assessment POA&M (32 CFR 170.21) lists requirements that are NOT MET at assessment time and must be closed within 180 days. An operational plan of action (CA.L2-3.12.2) is your day-to-day tracker for vulnerabilities and deficiencies. Per the guide, temporary deficiencies “appropriately addressed in operational plans of action” are assessed as MET.
Temporary deficiency / enduring exception: both are defined in 32 CFR 170.4. A temporary deficiency has a known fix that is available or in progress and is tracked in an operational plan of action. It arises after implementation, not from an in-progress initial rollout, except for issues found in a very limited subset of equipment during rollout. An enduring exception is a system where full remediation isn’t feasible (test equipment, OT, some medical devices) and is documented in the SSP.
Authenticated (credentialed) scan: a scan that logs in to the target to read installed software and configuration, rather than probing it from the network.

RA.L2-3.11.2: Vulnerability scanning

Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

Objective (paraphrased from SP 800-171A)	Evidence that demonstrates it
[a] the frequency to scan systems and applications is defined	An approved policy or procedure (signed, versioned, dated) stating scan frequency for systems and applications, including laptops and remote endpoints. If the frequency varies by asset class, the classes must match your asset inventory.
[b] systems are scanned at the defined frequency	Scan history covering the review period: job names, start and end timestamps, target lists. One scan from last week shows that a scan ran once. A year of dated runs shows a frequency.
[c] applications are scanned at the defined frequency	The same history for applications: web application scans, and for custom-developed code the static or dynamic analysis the guide mentions. Separate this from the infrastructure scan. Many programs can show [b] and have nothing for [c].
[d] systems are scanned when new vulnerabilities are identified	Scanner feed or plugin update records with dates, showing new checks reached the next scans. Where an advisory warranted it, an out-of-cycle scan with the ticket or message that triggered it is strong extra evidence.
[e] applications are scanned when new vulnerabilities are identified	The same for applications: a dependency or web scan rerun after a relevant advisory, with dates.

Scope has to reconcile with the asset inventory. The guide’s Further Discussion is blunt: “All assets that are within the scope of the CMMC assessment must be scanned, including assets such as laptop computers that may not routinely connect to an organization’s network.” It also names printers, scanners, copiers, containers, firewalls and switches. Under 32 CFR 170.19(c), CUI assets and security protection assets are both in scope and both belong in the asset inventory. The evidence an assessor can test is a reconciliation: the in-scope inventory on one side, the assets your scans actually reached on the other, and an explanation for every difference. Not every asset category is treated the same way: the same section handles contractor risk managed assets and specialized assets differently, so record each asset’s category next to its scan status.

Illustrative example, not from a client: the inventory lists 212 in-scope assets. Last month’s scans reached 188, of which 161 had a successful authenticated login. That is 24 assets with no scan result and 27 checked only from the network. Those 51 rows are your evidence gap, and listing them with a reason and a date is far stronger than a summary that says “scans complete”.

Authentication is part of the evidence. The Rev 2 discussion that the guide quotes notes that “privileged access authorization to selected system components facilitates thorough vulnerability scanning”. An unauthenticated scan of a Windows or Linux host mostly sees open ports and banners. It can’t read installed packages, so it misses most missing patches, though it still reports what’s visible from the network. Keep the scanner’s own per-host record of whether the login succeeded, and treat a failed login as a gap, not a pass.

“When new vulnerabilities are identified” is about the feed. The guide’s example meets [d] and [e] by verifying “that the scanner application receives the latest updates on vulnerabilities and that those are included in future scans”. One of its assessment considerations asks whether “the list of scanned system vulnerabilities [is] updated on a defined frequency or when new vulnerabilities are identified and reported”. Show the feed update history, and say in the policy how fast an out-of-cycle scan follows a critical advisory, where one is warranted.

In my experience the gap is rarely a few stray laptops. It’s often whole subnets. Most scan programs are set up at one point in time and never wired to pull in new data. The network team adds a subnet, nobody tells the scan team, and it never makes it into the scanner. Or the scan scope is a fixed list of hostnames and IP addresses rather than ranges, so nothing outside the original list is ever found. The fix is to connect the scanner to your inventory source, or keep the inventory in the scanner if it supports that. The manual version works too: export the full host list from the scanner and compare it side by side with the inventory export. Without either, the gap is usually found by accident. A team mentions its devices are missing from the reports, or an audit of one device type shows they haven’t been scanned in a year.

RA.L2-3.11.3: Vulnerability remediation

Remediate vulnerabilities in accordance with risk assessments.

Objective	Evidence that demonstrates it
[a] vulnerabilities are identified	Retained scan results (native exports, not just dashboards) that tie to the scan runs under 3.11.2, plus other sources you use: vendor advisories, penetration test findings.
[b] vulnerabilities are remediated in accordance with risk assessments	A documented prioritization method tied to your risk assessment (RA.L2-3.11.1), and records showing it applied: tickets with severity, owner, opened and closed dates, and a decision for each finding.

The phrase that matters is in accordance with risk assessments. The guide’s assessment considerations ask whether risk assessment results are used to prioritize remediation, whether “for any given vulnerability” action is taken “for remediation, acceptance, avoidance, or transference”, and whether all high-risk vulnerabilities are prioritized. Its Further Discussion adds: “Track all vulnerability remediation to ensure completion; also track vulnerabilities that you have determined not to remediate.”

So the evidence has two halves. One is the closed tickets. The other is the decision record for what you didn’t fix: who accepted the risk, why, what compensates for it, and when the decision will be reviewed again. A finding that disappears from the report because someone suppressed it, with no record, is the opposite of evidence.

Remediation proof is a rescan or a patch record, not a ticket status. “Closed” in the ticket system shows that someone said it was fixed. A later authenticated scan of the same asset in which the relevant check ran with sufficient access and no longer detects the finding, or a patch installation record applicable to that host with evidence that any required restart, reboot or redeployment took effect, shows that it was. Link the two in the ticket.

SI.L2-3.14.1: Flaw remediation

Identify, report, and correct system flaws in a timely manner.

This requirement is the one most often answered with “we patch monthly”. Its six objectives ask for three defined time frames and proof of meeting each one.

Objective	Evidence that demonstrates it
[a] the time to identify flaws is specified	Policy text giving the cadence for vendor-advisory review and scanning, e.g. advisories reviewed weekly, scans at the 3.11.2 frequency.
[b] flaws are identified within that time	Dated records: the advisory review log, scan runs, feed updates.
[c] the time to report flaws is specified	Policy text saying who is told about a flaw (“designated personnel with information security responsibilities”, in the Rev 2 discussion) and how fast.
[d] flaws are reported within that time	Ticket creation or notification timestamps compared with the scan or advisory date.
[e] the time to correct flaws is specified	Defined remediation time frames, typically a severity-based SLA in days, in an approved policy. The guide’s example uses weekly patching for end-user computers and monthly for servers; you set your own.
[f] flaws are corrected within that time	Patch and change records and rescan results, with the time to correct measured against [e]. Show the late ones too, each with its plan-of-action entry or exception.

The guide’s examine list for this requirement is specific: a “list of recent security flaw remediation actions performed on the system (e.g., list of installed patches…)”, “test results from the installation of software and firmware updates”, and “installation/change control records”. Firmware counts. Network gear, printers and BMCs are where defined time frames tend to quietly stop applying.

The report objectives ([c] and [d]) are the ones I see skipped most. “The scanner found it” is identification. Reporting is the step where a named person learns about it within a defined time, and that needs a timestamp.

I’ve seen every version of this: an SLA that existed only in a draft or in someone’s head, remediation tracked in email threads, and tickets closed with no rescan behind them. I’ve seen it in organizations of very different sizes. The answers are plain. Document the SLA, review it, and make sure every team held to it has read it. Email is fine for coordinating the work, but nothing counts as remediated until a ticket shows it. And no ticket closes without a rescan or a patch record, verified by the scanning team.

The minimum evidence for a fix is a rescan in which the relevant check ran with sufficient access and no longer detects the finding, or a patch installation record. A finding that disappears because the check couldn’t run proves nothing. The harder case is a mitigation or compensating control the scanner can’t see. That needs its own evidence of what was done, plus an expiry date and a plan for the patch that will eventually replace it.

What scanning can’t show

A vulnerability scanner is good evidence for a small part of NIST SP 800-171 and weak or irrelevant evidence for most of the 110 requirements. It can’t show that people were trained, that visitors were escorted, that media was sanitized, that incidents were reported, or that your SSP describes the real system. Even for the requirements it touches, a scanner shows the state of a host on the day it ran. It doesn’t show that your policy was approved, that your SLA was defined and approved, or that exceptions were reviewed.

Be wary of any tool or provider that offers to “map” its output to all of 800-171 or to declare you compliant. Ask which objectives its output actually demonstrates, which it only supports, and which it can’t speak to at all. Ask what the report says about an asset it couldn’t reach or log in to. If the answer is nothing, the report is overstating your coverage.

Common evidence failures

These are the patterns that turn a working program into NOT MET findings.

Unauthenticated scans presented as patch evidence. A port-and-banner scan shows what’s visible from the network, not the patch level. If the scanner fell back to unauthenticated for some hosts, those hosts have no scan evidence of their patch level for 3.14.1 unless agent or patch-management records cover them, whatever the dashboard colour says.
Scope gaps. Assets in the inventory with no scan result: laptops off the VPN, printers, a lab subnet, cloud workloads. No result means no evidence, not no vulnerabilities.
No proof of frequency. The policy says monthly, and the history shows March, June and August. Objective [b] isn’t met.
Applications forgotten. Infrastructure scans for [b] and [d], nothing for [c] and [e].
Undated or uncontextualized screenshots. A dashboard image with no date, scope or scan ID shows that a dashboard existed. Keep native exports with the tool’s own timestamps and retain them for the whole review period.
No rescan proof. Tickets closed on a statement, with no later scan or patch record.
Exceptions that delete findings. Suppressed or “accepted” items with no owner, rationale, compensating control or review date, or that vanish from reports instead of staying visible as accepted.
SLAs in drafts. Time frames that exist only in a working document, which the guide rules out as evidence.
One person who knows how it works. Interviews are an assessment method. If only one administrator can explain the process, the assessor will notice.
Ignored scan warnings. “Incomplete scan” or “credential failure” alerts suppressed or skipped, and the resulting clean-looking report filed anyway.
Findings outside the risk register. A critical finding that can’t be patched without breaking a legacy system, with no recorded risk decision, no compensating controls and no exception in the SSP. That is a NOT MET.

What to do Monday

Reconcile scope. Export your in-scope asset inventory and last month’s scan targets, match them, and write a reason next to every asset that wasn’t scanned or wasn’t authenticated. Fix the list or document the exception.
Put the three time frames in an approved policy. Identify, report and correct (3.14.1 [a], [c], [e]), plus scan frequency for systems and applications (3.11.2 [a]). Get the policy signed and dated, so it isn’t a draft.
Start an evidence index. One row per objective in this guide: the record that demonstrates it, where it lives, who owns it, and how long it’s kept. The companion checklist is a starting point.
Pick five closed tickets and trace them. For each, can you show the scan that found it, when it was reported, the SLA it was held to, and the rescan or patch record that proved the fix? If not, change the ticket template now.
Run an out-of-cycle scan after the next significant advisory and keep the trigger, the feed update date and the results together. That strengthens your evidence for 3.11.2 [d] and [e].

If you want a second pair of eyes on your scan evidence before an assessment, get in touch.

Sources

All checked on 8 October 2026.

NIST SP 800-171A (June 2018), requirements 3.11.2, 3.11.3 and 3.14.1: nvlpubs.nist.gov
DoD CMMC Assessment Guide, Level 2, v2.13 (September 2024): dowcio.war.gov
32 CFR part 170 (CMMC program): eCFR
DFARS CMMC final rule (90 FR 43560, effective 10 November 2025): Federal Register
DoW CIO, Removing Barriers to Defense Industrial Base Expansion: Immediate Suspension and Strategic Review of CMMC Requirements (13 July 2026): dowcio.war.gov
Under Secretary of War (A&S), Implementing Department of War Chief Information Officer’s Suspension of the Advancement to CMMC Phase 2 Requirements (13 July 2026): dowcio.war.gov; CMMC program page: dowcio.war.gov/CMMC
DFARS Part 240 class deviation 2026-O0025: original, December 2025; Revision 3 (supersedes Rev 2 of 16 July 2026; listed on the DPCAP DFARS RFO deviations page as 3 September 2026)
NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: csrc.nist.gov