Flaw Remediation is the first requirement in the System and Information Integrity (03.14) family, and it is patching discipline written down as a control. It covers finding flaws, telling the right people about them, fixing them, and getting security-relevant updates installed inside a defined window. Flaw Remediation (03.14.01) has two (2) parts: identify, report, and correct system flaws, and install security-relevant software and firmware updates within a defined time period of their release. Per the NIST discussion, security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures, and organizations can take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases when remediating system flaws.
A common difficulty with this requirement is patching software on a schedule while firmware quietly falls years behind. R3 separates software updates and firmware updates into distinct assessment objectives with their own time periods, so a patch program that never touches firmware leaves objectives open. For Department of Defense (DoD) contractors the installation windows are specified and tied to flaw risk level.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.14.01 Flaw Remediation. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source control is SI-02 from NIST 800-53. The bracketed assignment in part b is the Organization-Defined Parameter (ODP): the update installation time period, which NIST 800-171A R3 splits into separate parameters for software and firmware. Per the NIST discussion, organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling, and the time periods may vary based on factors including the criticality of the update. You can read the requirement directly at NIST 800-171 R3, 03.14.01 (p. 63).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
Note the asymmetry: NIST 800-171A R3 decomposes this requirement into two (2) Organization-Defined Parameters, while the DoD memorandum addresses them with one (1) entry, because a single bracketed assignment in the requirement text covers more than one parameter under assessment. Each ODP still needs its own answer in the System Security Plan (SSP).
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.14.01 into seven (7) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and five (5) determination statements. These AOs are:
Note that the single time period in the requirement text becomes two separate parameters in the assessment: one for software (ODP[01]) and one for firmware (ODP[02]). If you are a DoD contractor, the ODPs are specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the installation time period is thirty (30) days for high-risk flaws (including both critical and high), ninety (90) days for moderate-risk flaws, and one hundred eighty (180) days for low-risk flaws. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.14.01 (p. 83).
Examine: system and information integrity policy and procedures; procedures for flaw remediation; procedures for configuration management; list of recent security flaw remediation actions performed on the system; list of flaws and vulnerabilities that may potentially affect the system; test results from the installation of software and firmware updates to correct system flaws; installation and change control records for security-relevant software and firmware updates; system security plan.
Interview: personnel responsible for installing, configuring, or maintaining the system; personnel responsible for flaw remediation; personnel with configuration management responsibilities; personnel with information security responsibilities; system administrators.
Test: processes for identifying, reporting, and correcting system flaws; processes for installing software and firmware updates; mechanisms for supporting or implementing the reporting and correction of system flaws; mechanisms for supporting or implementing the testing software and firmware updates.
03.14.01 maps from NIST 800-171 R2 requirement 3.14.1 (identify, report, and correct system flaws in a timely manner):
Mapped against the seven (7) AOs, three (3) are direct (minimal effort), three (3) have no clear mapping, and one (1) is net new, with the last two (2) categories both counting as significant effort. Identifying, reporting, and correcting flaws carries forward cleanly. What changed is where the clock lives: R2 attached timeframes to identifying, reporting, and correcting flaws, while R3 attaches defined time periods to installing security-relevant software and firmware updates. Four of the seven (7) objectives are significant effort, and firmware update installation is the fully net-new one.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.14.01 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about firmware and the defined windows, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.14.01 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.14.01 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.14.01 recording the ODP values you adopted.
With three (3) AOs mapping directly, three with no clear mapping, and one net new, 03.14.01 is a significant lift concentrated on update windows and firmware. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.14.01? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.14.01.b: thirty (30) days for high-risk flaws (including both critical and high), 90 days for moderate-risk flaws, and 180 days for low-risk flaws.
How many assessment objectives does NIST 800-171 R3 03.14.01 have? NIST 800-171A R3 breaks 03.14.01 into seven (7) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and five (5) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.14.01 come from? SI-02.
Where does NIST 800-171 R3 03.14.01 sit in the NIST 800-171 R3 Kill Chain? Phase 15, Attack Surface Management (ASM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.14.01 Flaw Remediation identifies, reports, and corrects system flaws, and installs security-relevant software and firmware updates within defined time periods. It maps from R2 3.14.1 with the identify, report, and correct objectives transitioning directly, while the update installation windows are new work and firmware updates are net new. The recurring problem is patching software on schedule and letting firmware drift. Define both windows (for DoD, thirty days for high-risk, ninety for moderate, one hundred eighty for low), report flaws as well as fix them, and prove updates landed inside the window.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
