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
3.12.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.12.2 — Plans of action

3.12 Security Assessment · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Every known deficiency gets a plan: what is wrong, what will fix it, who owns it, and when it will be done. The plan of action is the honest ledger of the gap between intention and reality — and it only counts if it is maintained and worked, not filed.

Across revisions

Carried into Rev. 3 as 03.12.02, under the explicit official title Plan of Action and Milestones.

Mapped practices

Brilliant at the Basics practices that support this requirement

Evidence supportModerate confidence

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.

Practice-side activities
  • Promote overdue and excepted findings into plan-of-action entries with owners and milestone dates
  • Close plan-of-action items using remediation records as the evidence
Evidence this produces
  • Plan-of-action entries traceable to scan findings
  • Closure evidence drawn from remediation 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
  • Give every item an owner, milestone dates, and the resources it needs. A spreadsheet is fine; the discipline is in the updates, not the tool.
  • Feed the plan from every source that finds deficiencies — self-assessments, vulnerability findings, incidents, audits — so it is one ledger, not four.
  • Close items with evidence and treat aging items as governance signals: a plan of action where nothing moves is documentation of inaction, and assessors read it that way.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The maintained plan of action with dated updates and named owners
  • Closure evidence attached to completed items
  • Records of the review cadence at which the plan is actually worked

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

TRACKER · REVIEW MONTHLY WORKING REVIEW OF ALL OPEN ENTRIES; EXECUTIVE REVIEW QUARTERLY AND AT EVERY SCHEDULED-COMPLETION SLIPPlan of Action & Milestones (POA&M) Template
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

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