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

3.12.4 — System security plan

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, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other 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

The system security plan is the document of record: what the system is, where its boundary runs, how each requirement is implemented, and what it connects to. Assessors read it first and score against it — so an SSP describing a system that no longer exists is worse than a gap; it is a misstatement.

Across revisions

Rev. 3 withdraws the 03.12.04 slot: the system security plan moves to the new Planning family as 03.15.02. The document itself survives unchanged in purpose — but its catalog home moves, and policy cross-references and assessment preparation need to follow it.

Mapped practices

Brilliant at the Basics practices that support this requirement

Evidence supportModerate confidence

Why: An SSP's boundary description and component story stand on the inventory: a reconciled register of devices, identities, applications, and connections is the factual substrate the plan's system description must match. Where the inventory is current, the SSP can be checked against reality instead of memory.

What this does not claim: An SSP is authored governance work that no practice produces: the boundary judgment, environment description, implementation statements, and interconnection details are written, owned, and updated deliberately. The inventory keeps the descriptive sections truthful — it writes none of them, and a plan without an owner and an update cadence goes stale regardless of inventory quality.

Practice-side activities
  • Reconcile the SSP's component and boundary description against the inventory at each plan review
  • Flag inventory changes that alter the boundary as SSP update triggers
Evidence this produces
  • A reconciliation between SSP system-description sections and the inventory
  • SSP revision history citing inventory-driven changes

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

Contextual relationshipModerate confidence

Why: Segmentation is where the boundary the SSP describes becomes physical: zone design, deny-by-default edges, and documented cross-zone paths are the material behind the plan's boundary and interconnection sections. A segmented environment gives the plan defensible edges to draw.

What this does not claim: The practice shapes what the SSP describes; it does not draft, maintain, or update the plan, which remains deliberate governance work with an owner and a cadence. Nor does segmentation settle boundary scope by itself — CUI flow analysis, external-service relationships, and enclave decisions are inputs the practice does not provide.

Practice-side activities
  • Keep zone diagrams and boundary rule documentation current enough for the SSP to cite
  • Record approved cross-zone paths so the interconnection description reflects enforcement, not intention
Evidence this produces
  • Current segmentation diagrams referenced by the SSP's boundary section
  • Documentation of approved cross-zone allow rules

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
  • Describe the boundary honestly: which systems store, process, or transmit CUI, where enclaves and cloud tenants sit, and which external services are inside the story.
  • Write implementation statements that describe how each requirement is actually implemented today — aspirational statements belong in the plan of action, not the SSP.
  • Update on a defined cadence and on significant change, with versioning and dates, and keep the plan consistent with the inventory and network documentation it summarizes.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A current, dated SSP with boundary description and per-requirement implementation statements
  • A revision history showing the plan tracks system change
  • Consistency between the SSP and the asset inventory and network documentation

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

WORKSHEET · REVIEW SEMIANNUALSystem Boundary Definition WorksheetWORKSHEET · REVIEW QUARTERLY WHILE THE SSP IS BEING DRAFTED; THEREAFTER REFRESHED BEFORE EVERY SSP UPDATESystem Security Plan Development Worksheet
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