Information Exchange is a net-new requirement in R3 that governs the agreements behind sharing Controlled Unclassified Information (CUI) between systems. It completes the Security Assessment and Monitoring (03.12) family, and it is the contractual and documentary side of the technical flow controls in Information Flow Enforcement (03.01.03). Information Exchange (03.12.05) has three (3) parts: approve and manage the exchange of CUI between systems using selected agreement types, document the interface characteristics, security requirements, and responsibilities for each system in those agreements, and review and update the agreements on a defined frequency. Per the NIST discussion, information exchange applies to exchanges between two or more systems both internal and external, and the type of agreement depends on the relationship between the organizations and the level of access involved.
A common difficulty with this requirement is exchanging CUI with partners, service providers, or other systems without formal agreements that define the security responsibilities on each side. This requirement is new for R3, so most organizations have no explicit information exchange agreement process. For Department of Defense (DoD) contractors, the agreement types follow the contract, and the review cadence is specified.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.12.05 Information Exchange. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts:
The source control is CA-03 from NIST 800-53. The bracketed selection in part a and the assignment in part c are the Organization-Defined Parameters (ODPs): the agreement types and the review frequency. Per the NIST discussion, organizations may incorporate agreement information into formal contracts, especially for exchanges between federal agencies and nonfederal organizations, and the agreements include interface characteristics, security requirements, controls, and responsibilities for each system. You can read the requirement directly at NIST 800-171 R3, 03.12.05 (p. 57).
Two (2) values sit inside this requirement. Depending on your contract, your organization may be permitted to define them. Organizations in the DIB subject to CMMC are not, because the DoD has defined them as policy.
The values below come from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.12.05 into nine (9) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and seven (7) determination statements. These AOs are:
If you are a DoD contractor, the ODPs are specified. Per the DoD-specified ODP values in ComplianceForge's NIST 800-171 R3 Transition Guide, the agreement types (ODP[01]) are the requirements as described in the contract, and the review and update frequency (ODP[02]) is at least every twelve (12) months. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.12.05 (p. 74).
Examine: access control policy and procedures; procedures for system connections; system and communications protection policy and procedures; system interconnection security agreements; information exchange security agreements; service-level agreements; memoranda of understanding or agreements; non- disclosure agreements; system design documentation; enterprise architecture; security architecture; system configuration settings; system security plan.
Interview: personnel with development, implementation, and approval responsibilities for system interconnection agreements; personnel who manage systems to which the exchange agreements apply; personnel with information security responsibilities.
03.12.05 is net new for R3 and has no corresponding requirement in NIST 800-171 R2:
Mapped against the nine (9) AOs, all nine (9) are net new (significant effort), with none direct, indirect, or unmapped. The source control, CA-03, was an assumed control in R2 rather than one that R2 separately assessed, so there is no transition path. Build a documented information exchange agreement process rather than assuming your R2 external-connection handling covers it.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.12.05 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The pitfalls for this net-new requirement are about formal agreements and their contents, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.12.05 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.12.05 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.12.05 recording the ODP values you adopted.
With all nine (9) AOs net new, 03.12.05 is a significant lift built as a program. A realistic sequence:
What value does the DoD require for the first parameter in NIST 800-171 R3 03.12.05? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.12.05.a: requirements as described in the contract.
How many assessment objectives does NIST 800-171 R3 03.12.05 have? NIST 800-171A R3 breaks 03.12.05 into nine (9) assessment objectives: two (2) Organization-Defined Parameters (ODPs) and seven (7) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.12.05 come from? CA-03.
Where does NIST 800-171 R3 03.12.05 sit in the NIST 800-171 R3 Kill Chain? Phase 8, Segmented Network Architecture. The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.12.05 Information Exchange approves and manages CUI exchanges through formal agreements, documents each system's interface characteristics, security requirements, and responsibilities, and reviews the agreements on a defined frequency. It is net new for R3 with no R2 predecessor, so all nine (9) objectives are new work. The recurring problem is exchanging CUI without formal agreements. Put agreements in place (for DoD, the types the contract requires), document each side's responsibilities, and keep the agreements current at least every twelve months.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
