- Inventory the exchanges first: partner transfers, supplier portals, managed-service data flows, cloud-to-cloud integrations — most organizations find more than they expected.
- Match the agreement type to the relationship — a formal interconnection security agreement for a system-to-system link, contract clauses or service agreements where that is unrealistic — and document interface characteristics and responsibilities in each.
- Set the review cycle and honor it; exchanges change faster than the paperwork that authorized them.
03.12.05OFFICIAL TITLEPENDING NIST SME REVIEW
03.12.05 — Information Exchange
03.12 Security Assessment and Monitoring · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires approving and managing the exchange of CUI between the system and other systems using agreements — such as interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, or service-level agreements — documenting interface characteristics, security requirements, and responsibilities in those agreements, and reviewing and updating the agreements at an organization-defined frequency.
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
When CUI moves between your system and someone else's, both sides need to have agreed — in writing — on what crosses, how it is protected, and who is responsible for which half. This requirement turns 'we email them files and assume they handle it properly' from a habit into an identifiable gap.
Across revisions
New as a standalone requirement in Rev. 3, with no Rev. 2 counterpart requirement. The nearest Rev. 2 touchpoint was the system security plan's expectation to describe connections to other systems; Rev. 3 gives CUI exchange its own approval, agreement, and review obligations with their own evidence.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- A register of CUI exchanges with the agreement covering each
- Agreements documenting interface characteristics, security expectations, and responsibilities
- Dated agreement reviews on the defined frequency
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
No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |