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

03.15.02System Security Plan

03.15 Planning · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Develop a system security plan that describes the system boundary, the operating environment, how the security requirements are implemented, and relationships with or connections to other systems; review and update the plan at an organization-defined frequency; and protect it from unauthorized disclosure.

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

The SSP is the document of record: what the system is, where it ends, and how each requirement is implemented within it. Rev. 3 moves it from the assessment family into Planning and adds two operational teeth — a defined update frequency instead of 'periodically', and protection of the plan itself, which is, after all, a map of your defenses.

Across revisions

Moved from Rev. 2's Security Assessment family (3.12.4) into the new Planning family, with the update cadence now an organization-defined frequency and protection from unauthorized disclosure added as an explicit obligation.

Mapped practices

Brilliant at the Basics practices that support this requirement

Evidence supportModerate confidence

Why: An SSP describes the system boundary, its components, and its connections — and the reconciled asset inventory is where those descriptions come from and how they stay true. The practice's normal operation keeps the plan's factual backbone current.

What this does not claim: An SSP is authored governance work — implementation statements, boundary decisions, and update discipline that no inventory produces. The practice provides evidence relevant to the plan's accuracy, while the plan itself, its defined update frequency, and its protection from disclosure are separate obligations this practice does not touch.

Practice-side activities
  • Reconcile the inventory on a cadence and flag deltas that change the SSP's boundary or connection descriptions
  • Feed new systems and integrations into the SSP owner's review queue
Evidence this produces
  • Inventory reconciliation reports aligned to SSP revision history
  • A delta list connecting infrastructure changes to plan updates

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
  • Write implementation statements that name the actual mechanism — the enforcing policy, the specific configuration — rather than restating the requirement; an assessor reads the SSP first and checks reality against it.
  • Treat boundary and connection descriptions as living architecture records: every new SaaS integration and network change is a potential SSP delta, and the defined update frequency is the floor, not the trigger.
  • Restrict access to the plan to the people who need it; a system's full defensive layout in an open file share undercuts the plan's own purpose.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The current SSP with version history measured against the defined update frequency
  • Access-restriction configuration for wherever the plan lives
  • Change records connecting system modifications to plan updates

Suggested owners, derived from the mapped practices and artifacts: IT leader · 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

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