Risk-Based Vulnerability Management

Why: The practice's ranking inputs — exploitability, exposure, asset criticality — are risk-assessment reasoning applied at the finding level, and its outputs (exposure trends, open known-exploited findings) are among the concrete inputs a periodic organizational risk assessment should consume.

What this does not claim: The requirement is a full organizational assessment — plausible threats and the consequences of CUI exposure for operations, assets, and individuals — which no vulnerability-management program performs. The practice informs one input to that assessment; the assessment itself, its cadence, and its record are separate governance work that must exist independently.

Review status: Pending NIST SME review.

Why: The practice is the scan cycle this requirement names: authenticated scanning across the full inventory on a cadence, with known-exploited disclosures triggering off-cycle attention. Its coverage metric — assets scanned over assets inventoried — makes the requirement's usual weak point measurable.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement covers applications as well as systems, and every asset in the assessed boundary — including network devices, cloud configuration, and whatever the scanner cannot reach — while the practice's coverage claim is only as good as the inventory it scans against. An assessor evaluates actual scope and cadence, not the existence of a scanning program.

Review status: Technical review complete.

Why: Remediating in accordance with risk is the practice's defining move: findings ranked by known-exploited status, exposure, and asset criticality rather than raw scanner severity, with remediation windows by severity that the organization holds itself to and measures.

What this does not claim: Supports implementation without satisfying the requirement alone: 'in accordance with risk assessments' ties remediation to 3.11.1's organizational assessment, which the practice consumes rather than produces. Exception handling must also hold up — an unremediated finding without a recorded decision and compensating control is precisely where this requirement fails under assessment.

Review status: Technical review complete.

Why: The practice's remediation tracking — findings with owners and windows, plus an exception register with expiry dates — produces exactly the deficiency-correction records the vulnerability slice of a plan of action draws on and closes against.

What this does not claim: Provides evidence relevant to the requirement rather than implementing it: a plan of action spans every kind of deficiency — policy gaps, training shortfalls, assessment findings — not just scanner output, and it must exist as a maintained document with milestones regardless of how well the underlying tickets flow. Feeding the ledger is not the same as keeping it.

Review status: Pending NIST SME review.

Why: Identify, report, and correct system flaws in a timely manner is a one-sentence description of vulnerability management. The practice's scan-prioritize-remediate cycle works on the requirement's exact substance, with risk-based ordering giving 'timely' an operational meaning per flaw.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. System flaws are wider than scanner findings — functional defects, misconfigurations without CVEs, and firmware the scanner cannot see are in scope too — and the requirement's reporting expectation needs a defined internal path with named recipients, not just a dashboard nobody is obligated to read.

Review status: Pending NIST SME review.

Why: Vendor and CISA advisories are an input the practice's triage queue already consumes: advisory monitoring is how new vulnerabilities affecting the estate become scan targets and remediation tickets rather than news items.

What this does not claim: Contributes the acting-on half for flaw-type advisories only. The requirement also covers alerts and directives that demand non-patching responses — configuration changes, threat hunting, disabling a feature — and the watching of advisory sources itself needs a named owner and a routine that the scanning platform does not supply.

Review status: Pending NIST SME review.

Why: Current, risk-ranked vulnerability data is one of the strongest inputs a periodic risk assessment can draw on — it grounds the exposure picture in what is actually reachable and exploitable in the environment rather than in generic threat lists.

What this does not claim: Feeding a risk assessment is not performing one. The requirement covers risk to operations, assets, and individuals — supply chain risk included — at a scope no scanner output reaches, and it needs a documented assessment updated on the defined frequency, which the practice neither produces nor schedules.

Review status: Pending NIST SME review.

Why: The practice's scan-prioritize-remediate cycle — authenticated scanning across the inventory, ranking by exploitability and asset criticality, remediation held to defined windows — is the substance of this requirement, which in Rev. 3 includes remediation directly rather than in a separate item.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. Rev. 3's scanning frequencies and remediation response times are organization-defined parameters — the practice's fourteen- and thirty-day windows are a defensible starting point, not the defined values an assessor will test against until the organization adopts and records them. The requirement also expects the set of vulnerabilities scanned for to be kept current, which depends on feed and scanner maintenance beyond the remediation cycle itself.

Review status: Technical review complete.

Why: Risk-ranked remediation is a standing risk-response mechanism for one class of findings: every vulnerability gets a decision — fix within a window, defer with an owner and a date, or compensate — which is the explicit response behavior this new requirement asks for.

What this does not claim: The requirement spans findings from security assessments, monitoring, and audits — not only vulnerability scans — so most of its scope arrives through channels the practice never sees. Response options beyond mitigation (acceptance, avoidance, transfer) and the stated risk tolerance those decisions are made within are separate work the practice does not produce.

Review status: Pending NIST SME review.

Why: The practice's remediation tracking — findings, owners, dates, windows held or missed — is the same shape of record a plan of action and milestones draws on for its known-vulnerability entries, so the practice's normal operation keeps that portion of the plan supplied with current, truthful input.

What this does not claim: Provides evidence relevant to the requirement rather than implementing it. A plan of action and milestones is a governance document spanning weaknesses in any security requirement, produced and updated through the assessment process; a patch queue does not become one by renaming it, and deficiencies outside vulnerability management never appear in the practice's records at all.

Review status: Pending NIST SME review.

Why: Risk-based vulnerability management is flaw remediation run as a discipline: identify exposures across the asset population, prioritize by exploit likelihood and exposure, and drive fixes on a schedule. The practice's core loop is the requirement's substance.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement's clock is the organization-defined time periods for installing security-relevant updates — risk-based prioritization must operate inside those periods, not replace them — and 'flaws' reaches beyond scanner findings to defects surfaced by tests, vendor notices, and incident analysis, which all need a route into the same queue.

Review status: Pending NIST SME review.