Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.14.01OFFICIAL TITLEPENDING NIST SME REVIEW

03.14.01 — Flaw Remediation

03.14 System and Information Integrity · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Identify, report, and correct system flaws, and install security-relevant software and firmware updates within organization-defined time periods of the updates' release.

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 Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Every system accumulates flaws — bugs, vulnerable versions, misconfigurations — and this requirement is the discipline of finding them, telling the people who need to know, and fixing them on a clock. Rev. 3 puts a number on the clock: the organization defines how long a security-relevant update may wait after release, and then has to live by that number.

Across revisions

Carried from Rev. 2's 3.14.1 with the timing made explicit: 'timely manner' becomes organization-defined time periods for installing security-relevant updates after release.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

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.

Practice-side activities
  • Scan the full asset population and rank findings by exploitability and exposure
  • Drive remediation to defined timelines with dated exceptions for what cannot move
  • Feed non-scanner flaw reports — advisories, penetration-test findings — into the same remediation queue
Evidence this produces
  • Scan coverage reconciled against the asset inventory
  • Time-to-remediate reporting against the defined periods
  • Exception records with owners and revisit dates

Where this holds: Strongest for managed endpoints and servers; appliance firmware and unmanaged devices need deliberate inclusion or the practice's coverage understates the requirement's scope.

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

Partial implementation supportModerate confidence

Why: The practice handles known OT vulnerabilities the way control environments demand — patching in maintenance windows where vendors allow it, compensating with isolation and monitoring where they do not — which advances flaw remediation for the OT systems inside an assessed boundary.

What this does not claim: May partially address the requirement, and only where OT assets fall within the CUI system boundary — much OT does not. A compensating measure manages a flaw's risk without correcting the flaw, so each one needs its own documented justification, and the organization-defined update periods still govern wherever patching is possible.

Practice-side activities
  • Track vendor-approved updates per platform and schedule them into maintenance windows
  • Document compensating measures where patching is barred, with owners and revisit dates
Evidence this produces
  • The OT patch decision log per asset class
  • Compensating-measure records tied to specific unremediated flaws

Where this holds: Applies only to OT assets within the assessed CUI boundary; the enterprise-IT majority of the requirement's scope is untouched by this practice.

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
  • Define the update time periods deliberately and tier them by severity and exposure — one blanket number is either unachievably tight for everything or uselessly loose for the internet-facing systems that matter most.
  • Cover firmware and appliances, not just operating systems and applications; the flaws that linger longest live in the devices no agent reaches.
  • Treat 'identify' and 'report' as their own obligations — a flaw surfaced by a penetration test, a vendor notice, or an incident needs a route into the same remediation queue as scanner output.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The written time periods for installing security-relevant updates, tiered by severity or system class
  • Remediation records showing time-to-fix measured against the defined periods, with dated exceptions
  • Update and configuration reporting across the full asset population, including firmware

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

Artifacts

Templates and worksheets with a mapped relationship

TRACKER · REVIEW UPDATED EVERY PATCH CYCLE (MONTHLY FOR MOST PLATFORMS); RING DEFINITIONS REVIEWED SEMIANNUALLYPatch Deployment Tracker
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