Artifact
Scan-evidence checklist: NIST SP 800-171 Rev 2, 3.11.2 / 3.11.3 / 3.14.1
Published · Last reviewed
Print this page using your browser’s print command.
Companion to What your vulnerability scanning evidence needs to show an assessor · version 1.0
Each objective is assessed on its own, and one NOT MET objective fails the whole requirement. For every line, write down where the evidence lives and who owns it. Evidence must be final and approved (no drafts or working papers) and dated so it covers the review period. Objective wording is paraphrased from NIST SP 800-171A (June 2018), as used in the DoD CMMC Assessment Guide, Level 2 (v2.13); use the official text in your SSP. This is a working aid, not legal advice and not a substitute for the assessment guide.
Before you start: scope
- In-scope asset inventory (CUI assets and security protection assets) exported and dated
- Scan target lists for the period exported and matched against the inventory
- Every inventory asset with no scan result listed with a reason, an owner and a date (remote laptops, printers, network gear, containers, cloud workloads, lab segments)
- Every asset scanned without a successful authenticated login or without completion of the intended checks listed the same way. Unless agent or patch-management records cover them, failed login or incomplete checks mean not assessed for patches, not clean.
- Specialized assets and enduring exceptions documented in the SSP, not left out without explanation
RA.L2-3.11.2: Vulnerability scanning (5 points; not eligible for an assessment POA&M)
| Obj. | Determine if… | Evidence to have ready | Location / owner |
|---|---|---|---|
| [a] | scan frequency for systems and applications is defined | Approved, dated policy or procedure stating frequency for systems and applications (and per asset class, if they differ) | |
| [b] | systems are scanned at that frequency | Scan history for the whole period: job IDs, start/end timestamps, targets; per-host authentication status | |
| [c] | applications are scanned at that frequency | Web application / dependency / code-analysis scan history, kept separate from infrastructure scans | |
| [d] | systems are scanned when new vulnerabilities are identified | Scanner feed/plugin update log with dates; where warranted, an out-of-cycle scan linked to the advisory that triggered it | |
| [e] | applications are scanned when new vulnerabilities are identified | Same as [d], for applications |
RA.L2-3.11.3: Vulnerability remediation (1 point)
| Obj. | Determine if… | Evidence to have ready | Location / owner |
|---|---|---|---|
| [a] | vulnerabilities are identified | Retained native scan exports (not only dashboards) tied to the 3.11.2 runs; pen test and advisory findings | |
| [b] | vulnerabilities are remediated in accordance with risk assessments | Documented prioritization method linked to the RA.L2-3.11.1 risk assessment; tickets with severity, owner, opened/closed dates; a decision for every finding (remediate, accept, avoid, transfer) |
- Every risk acceptance has an owner, rationale, compensating control (if any), approval date and review date
- Accepted findings remain visible in reports as accepted; they are not suppressed or deleted
- Open items appear in the operational plan of action (CA.L2-3.12.2) with milestones
SI.L2-3.14.1: Flaw remediation (5 points; not eligible for an assessment POA&M)
| Obj. | Determine if… | Evidence to have ready | Location / owner |
|---|---|---|---|
| [a] | the time to identify flaws is specified | Policy: vendor-advisory review cadence and scan cadence | |
| [b] | flaws are identified within that time | Dated advisory review log, scan runs, feed updates | |
| [c] | the time to report flaws is specified | Policy: who is told (named role) and within how long | |
| [d] | flaws are reported within that time | Ticket or notification timestamps compared with the scan/advisory date | |
| [e] | the time to correct flaws is specified | Approved remediation time frames (typically a severity-based SLA in days), including firmware | |
| [f] | flaws are corrected within that time | Patch/change records, test results for updates, rescan with sufficient access in which the relevant check ran 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, proving the fix; late items each with a plan-of-action entry or exception |
Evidence quality: quick test
- Every record carries a date and a scope (asset, scan ID or ticket ID). No undated screenshots.
- Records cover the whole review period, not just last week
- Policies and SLAs are approved versions, not drafts
- Five randomly picked closed tickets each trace to: the finding scan → report time → SLA → fix → rescan or patch record
- At least two people can explain and demonstrate the process (interviews and tests are assessment methods)
- You can run a scan report or open a ticket live if the assessor asks
Sources
- NIST SP 800-171A (June 2018): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171A.pdf
- DoD CMMC Assessment Guide, Level 2, v2.13: https://dowcio.war.gov/Portals/0/Documents/CMMC/AssessmentGuideL2v2.pdf
- Point values and POA&M rules: 32 CFR 170.24 and 170.21 — https://www.ecfr.gov/current/title-32/section-170.24 , https://www.ecfr.gov/current/title-32/section-170.21
- Asset categories: 32 CFR 170.19(c) — https://www.ecfr.gov/current/title-32/section-170.19
Licensed CC BY 4.0: free to copy and adapt with attribution. No sign-up required.