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

3.13.16CUI at rest

3.13 System and Communications Protection · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Independent interpretation

What this requirement is after

CUI sitting still — on servers, endpoints, removable media, backups, cloud storage — is protected. Encryption at rest is the usual answer, but the requirement is about the outcome: wherever CUI rests, its confidentiality has a named protection.

Across revisions

Notable consolidation: Rev. 3 withdraws the standalone at-rest requirement (03.13.16) and merges its substance with transmission confidentiality into Transmission and Storage Confidentiality, 03.13.08.

Mapped practices

Brilliant at the Basics practices that support this requirement

Contextual relationshipModerate confidence

Why: Deciding which AI services may receive, retain, or train on sensitive data — the data-protection half of this practice — determines where CUI is permitted to come to rest in the first place, which is the scoping decision at-rest protection depends on.

What this does not claim: Informs the requirement without acting on its substance: the practice encrypts no storage and configures no at-rest protection anywhere. Every location where CUI legitimately rests — file servers, endpoints, cloud tenants, backups — needs its own protection decisions and evidence, and an AI-usage policy governs only the new resting places AI adoption would otherwise create.

Practice-side activities
  • Maintain an approved-tool list with data-handling and retention terms reviewed
  • Block or constrain CUI flows to unapproved AI services
  • Include approved AI services in the CUI-at-rest location inventory
Evidence this produces
  • AI acceptable-use policy naming data classes and approved services
  • Proxy or DLP rules restricting data flows to AI endpoints

Mapping limitations: The relationship depends on the organization treating AI services as CUI locations at all; where CUI is prohibited from AI tools entirely and that prohibition is enforced, the mapping reduces to policy evidence.

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
  • Find where CUI actually rests before protecting it — file shares, laptops, email archives, SaaS tenants, backup sets; the unknown location is the finding.
  • Full-disk and platform encryption cover the common cases cheaply; the deliberate work is recovery-key custody and the locations platform encryption misses.
  • Physical protection can carry part of the load for media in controlled areas, but that claim has to be explicit in the system security plan, not assumed.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A CUI-at-rest location inventory with the protection named per location
  • Encryption status reporting for endpoints and servers holding CUI

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 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