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
03.01.20OFFICIAL TITLEPENDING NIST SME REVIEW

03.01.20 — Use of External Systems

03.01 Access Control · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires prohibiting the use of external systems unless they are specifically authorized; establishing organization-defined security requirements as a condition of their use; permitting authorized individuals to access the system from, or handle CUI on, external systems only after those security requirements are verified and approved connection or processing agreements are retained; and restricting the use of organization-controlled portable storage devices on external systems (aligned to SP 800-53 AC-20 with enhancements).

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 Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

An external system is anything you do not control that touches your data — a partner's network, an employee's home PC, a personal cloud account, an unvetted SaaS tool. The default answer is no; the yes cases get named conditions, verification, and an agreement on file. The everyday version of this failure is CUI opened on a home computer or pasted into a web service nobody reviewed.

Across revisions

Absorbs Rev. 2's portable-storage limitation (3.1.21) as the consolidated requirement's final element, and reshapes 3.1.20's verify-and-limit language into an explicit prohibit-unless-authorized structure with defined security conditions and retained agreements.

Mapped practices

Brilliant at the Basics practices that support this requirement

Contextual relationshipModerate confidence

Why: External AI services are external systems in this requirement's sense the moment CUI could reach them, and the practice's sanction-and-boundary decisions about AI tools inform which such uses are authorized and under what conditions.

What this does not claim: Informs the approach; it does not implement the requirement's machinery. The default prohibition, defined security conditions, verification, retained agreements, and portable-storage restriction span every external system — partner networks, home computers, all unvetted SaaS — of which AI services are one slice. A strong AI-adoption stance leaves the rest of the external-system population unexamined.

Practice-side activities
  • Fold sanctioned AI services into the external-system authorization list with their conditions
  • Block unsanctioned AI tools from CUI repositories at the network or endpoint layer
Evidence this produces
  • The sanctioned AI-service entries within the external-system register
  • Blocking or DLP policy covering unsanctioned AI services

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
  • State the default prohibition in policy and name the authorized exceptions — partner portals, a vetted BYOD arrangement — each with its conditions.
  • Put technical teeth behind the policy: conditional-access rules that block unmanaged devices from CUI repositories do more than any memo.
  • Retain the agreements — the connection or processing agreement with the entity hosting the external system is itself part of the requirement.
  • Restrict company portable storage from use on external systems; the requirement covers your drives on their machines, not only the reverse.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The external-system policy with authorization conditions and the current exception list
  • Conditional-access or equivalent configuration limiting unmanaged-device access to CUI
  • Retained connection or processing agreements for authorized external systems

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

Artifacts

Templates and worksheets with a mapped relationship

INVENTORY · REVIEW QUARTERLY FULL REVIEW; NEW SERVICES ADDED WITHIN A WEEK OF DISCOVERY OR PROCUREMENTCloud Service and SaaS InventoryWORKSHEET · REVIEW QUARTERLYAI Use-Case and Data-Handling Worksheet
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