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.11.04OFFICIAL TITLEPENDING NIST SME REVIEW

03.11.04 — Risk Response

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

Independent summary of the official requirement

Requires responding to findings from security assessments, security monitoring, and audits in accordance with organizational risk tolerance.

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

Findings without decisions are documentation of neglect. Every finding — from an assessment, from monitoring, from an audit — gets an explicit response: fix it, accept it with a name attached, avoid it by changing the plan, or transfer it. And the deciding happens inside a risk tolerance the organization has actually stated, not inside one person's comfort level.

Across revisions

New as a standalone requirement in Rev. 3, with no direct Rev. 2 counterpart. Rev. 2 implied responses through vulnerability remediation (3.11.3) and plans of action (3.12.2); Rev. 3 makes the response decision itself — mitigate, accept, avoid, or transfer — an explicit, evidenced requirement.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Attach an explicit decision — remediate, defer, or compensate — to every vulnerability finding
  • Record deferrals as risk acceptances with a named owner and expiry
Evidence this produces
  • The findings queue showing per-finding decisions and owners
  • Dated deferral and acceptance records

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
  • Route findings from every source — assessments, monitoring, audits, scans — into one queue with owners and due dates, so nothing depends on someone remembering an email.
  • Make acceptance a real decision: written, made by someone with the authority to carry the risk, and carrying an expiry date rather than lasting in perpetuity.
  • State the organizational risk tolerance the decisions are made within; without it, every acceptance is a guess an assessor can challenge.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A findings register showing each finding, its response decision, its owner, and its status
  • Signed risk-acceptance records with deciding authority and expiry
  • The stated risk tolerance the decisions reference

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

Artifacts

Templates and worksheets with a mapped relationship

REGISTER · REVIEW MONTHLY FOR OPEN HIGH-RATED RISKS; THE FULL REGISTER QUARTERLY AND AFTER EVERY INCIDENT OR ASSESSMENTRisk Register
The other revision

Where this came from in Rev. 2

No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →

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