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

03.13.08Transmission and Storage Confidentiality

03.13 System and Communications Protection · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires implementing cryptographic mechanisms that prevent the unauthorized disclosure of CUI both during transmission and while in storage. A single Rev. 3 requirement covers CUI confidentiality in motion and at rest.

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

CUI stays unreadable to anyone who intercepts it in transit or takes the storage it rests on — one requirement, both states. In practice: protected channels for every path CUI crosses, and encryption for the disks, databases, backups, and portable media where it lands.

Across revisions

Merges Rev. 2's transmission confidentiality (3.13.8) and CUI at rest (3.13.16) into one cryptographic requirement spanning both states — an environment that encrypted in transit but relied on physical protection at rest now answers a single, broader question.

Mapped practices

Brilliant at the Basics practices that support this requirement

Contextual relationshipModerate confidence

Why: The practice's data-protection work — deciding which AI services may receive which data, and blocking CUI from leaving approved boundaries — determines where CUI is transmitted and stored, which is the scope this requirement's cryptographic mechanisms must then cover.

What this does not claim: The practice informs the requirement's scope without acting on its substance: it implements no cryptography. Whether CUI in transit to, or at rest within, an approved service is cryptographically protected is a property of that service's configuration and the organization's parameter choices, and it must be assessed on its own evidence regardless of how well AI data flows are governed.

Practice-side activities
  • Maintain the approved-service list that bounds where CUI may be transmitted or stored
  • Feed newly approved AI data flows into the CUI flow map that scopes cryptographic protection
Evidence this produces
  • The approved AI service register with data-category decisions
  • CUI flow map updates reflecting AI-related paths and stores

Mapping limitations: The relationship is scoping-only by design; it would not survive being read as implementation support and should not be presented as such.

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
  • Map CUI's paths and resting places first; the requirement is only as strong as the flow map behind it.
  • Cover the unglamorous transit paths — email to partners, transfers between sites, system-to-system integrations — not just the browser edge.
  • At rest, layer deliberately: full-disk encryption answers stolen hardware but not a compromised account on the running system; file- or record-level protection answers more.
  • Check the mechanisms against the cryptography types defined under 03.13.11 — encryption of an unaccepted type will not stand in for this requirement.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A CUI flow map naming the protecting mechanism per path and per store
  • Configuration evidence: transport encryption policies, storage and backup encryption status
  • Sampled verification that the mechanisms are active, not merely available

Suggested owners, derived from the mapped practices and artifacts: Engineering lead. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

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