Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
03.11.02OFFICIAL TITLEPENDING NIST SME REVIEW

03.11.02Vulnerability Monitoring and Scanning

03.11 Risk Assessment · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires monitoring and scanning for vulnerabilities in the system and its applications at organization-defined frequencies and whenever new vulnerabilities affecting the system are identified, remediating what is found within organization-defined response times, and updating the set of vulnerabilities scanned for as new ones are identified and reported.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal SystemsNIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

Know your exposures before an attacker does, and close them on a clock. Scanning tells you what is reachable and vulnerable; the defined response times are the promise that critical findings do not sit open for a quarter. Rev. 3 folds remediation into the same requirement because a scan report nobody acts on protects nothing.

Across revisions

Merges Rev. 2's vulnerability scanning (3.11.2) and vulnerability remediation (3.11.3) into a single requirement, and parameterizes both the monitoring frequency and the remediation response times as organization-defined values.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

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.

Practice-side activities
  • Run authenticated scans on a schedule reconciled against the asset inventory
  • Adopt and record severity-based remediation windows as the organization's defined response times
  • Track remediation aging with owners and dated decisions for anything past its window
Evidence this produces
  • Scan schedules and coverage reconciliation reports
  • The recorded response-time parameters with remediation metrics held against them
  • Aging reports showing findings past window, each with a decision

Where this holds: Holds for IT estates the scanner can reach with credentials; weakens for unscannable or fragile assets, which need documented alternative monitoring.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Partial implementation supportModerate confidence

Why: The practice runs the same monitor-and-remediate cycle for the OT estate, adjusted to production reality: vulnerability identification through passive discovery and vendor advisories, patching inside maintenance windows, and compensating measures where patching would threaten operations.

What this does not claim: May partially address the requirement for the OT portion of an assessed boundary. Active scanning can crash fragile controllers, so the practice often substitutes passive discovery and advisory monitoring — a legitimate method, but one an assessor will expect to see documented as the organization's defined approach rather than assumed. Where a vulnerability cannot be remediated within the defined response times, the compensating measure and its formal acceptance must be recorded, or the gap between the parameter and the plant's reality becomes the finding.

Practice-side activities
  • Maintain OT vulnerability visibility through passive discovery and vendor advisory tracking
  • Schedule remediation into maintenance windows with production and safety sign-off
  • Document compensating measures and their acceptance where patching is deferred
Evidence this produces
  • OT vulnerability tracking records tied to the validated asset list
  • Maintenance-window remediation records
  • Documented compensating measures with acceptance and review dates

Where this holds: Holds for OT environments where active scanning is constrained; the documented-method and compensating-measure records are what carry the relationship.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Run authenticated scans against the full inventory and reconcile scanned assets against the asset list every cycle — coverage gaps are silent risk acceptance.
  • Define the response times per severity and write them down; an assessor tests the parameters you defined, and 'as soon as possible' is not a parameter.
  • Rank remediation by exploitability and asset criticality, not raw severity scores — a known-exploited flaw on an internet-facing system outranks a critical on an isolated one.
  • Keep vulnerability feeds and scan definitions current so the scan set updates as new vulnerabilities are reported — that update loop is part of the requirement, not an assumption.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Scan schedules and results with coverage reconciled against the inventory
  • The written response-time parameters per severity, with remediation records held against them
  • Aging reports for findings past their window, each carrying an owner and a decision

Suggested owners, derived from the mapped practices and artifacts: IT leader / MSP · OT engineer · IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated