03.12.05 Information exchange: requirements and evidence

What 03.12.05 information exchange requires before CUI leaves your system

If a contract now requires Rev. 3 and your system sends or receives CUI from another system, 03.12.05 requires you to approve each exchange through a written agreement before CUI moves, and to document the interface, the security requirements and each side's responsibilities in that agreement. The agreement must then be reviewed and updated on a schedule you define. The requirement does not prescribe a single document type. It asks you to choose agreement types from a defined list, such as interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, user agreements, non-disclosure agreements or other agreements, and to record which types you use. Two organization-defined parameters (ODPs) make this concrete: the agreement types you select and the review frequency. NIST does not set those values. If your federal customer has not specified them, you must assign them yourself, and an assessor will check that both are defined and that your practice follows them.

This is a new requirement in Rev. 3. NIST's change analysis lists 03.12.05 among the 19 requirements added in Rev. 3 and maps no Rev. 2 requirement to it. It has no matching requirement ID in the 110 Rev. 2 requirements that CMMC Level 2 assesses, so a CMMC-based assessment will not show you where it sits. Confirm with your contracting officer which revision your contract names, because that determines whether this requirement is in scope at all. The assessment procedure in SP 800-171A Rev. 3 tests it by examining written agreements and procedures, and by interviewing the people who approve and manage system connections and information exchanges. No technical test applies, so the evidence is documentation and the people who can explain it.

In practice the difficulty is inventory. Most organizations can name their major connections, but fewer can list every feed that carries CUI out to a cloud service, a subcontractor's portal, a shared file transfer tool or an email gateway, and many of those flows were never approved by anyone with authority to approve them. Start by listing every interface that carries CUI in or out of your system boundary, then match each to an agreement or record that you can produce on request. Assign an owner to each agreement, record the security requirements the other party must meet, and set a review date. Where a connection is a standing service, such as a managed file platform, check whether the provider's standard terms already cover the required content. Ask your implementation partner and your assessor which documents they will expect to see, and confirm the agreement types and review frequency with your customer before you write them.

Which connections and agreements fall under 03.12.05

03.12.05 applies wherever CUI leaves your system boundary and reaches another system, whether that is a cloud provider, a subcontractor, a prime contractor or a government portal. The work starts with an inventory of those flows, then a decision for each flow about whether it needs a formal agreement and which type fits.

Cloud and hosted services

Any SaaS email, file sharing, ticketing or backup service that stores or processes CUI receives an exchange of CUI, even when no one on your team opens a connection by hand. Check whether the provider's terms, data processing addendum or service agreement already define security responsibilities, incident notice and data handling, and whether your system security plan records each service. Where those terms are standard and cannot be changed, document the gap and the compensating controls instead of assuming they are covered.

Subcontractor and teaming links

Subcontractors that receive CUI from your system need an agreement that sets the interface, the security requirements each party must meet and who responds to an incident. Flow-down of DFARS requirements belongs here, but 03.12.05 asks for more: a documented description of how the data moves and who approves it. List every subcontractor that receives CUI, the channel used and the person who signed off on the exchange.

Government and prime links

Portals, secure file drops and direct connections to a prime or a federal agency are often where the agreement type matters most. A direct system-to-system connection to a government or prime system calls for a formal interconnection or information exchange agreement, while a manual upload through a portal the other party operates is usually governed by that party's terms and your user responsibilities. Confirm with the contracting officer or prime which agreement they expect before the first transfer.

True interconnections versus user transfers

The most consequential scoping decision is whether a flow is a true interconnection, meaning an automated, persistent connection between two systems, or a user-driven transfer, meaning a person sends files by email, portal or removable media. Interconnections need interface documentation, security requirements for both ends and a formal agreement with a review schedule. User transfers are usually covered by rules of behavior, media controls and the transfer procedure, though the organization still defines which agreement type applies. Record the classification for every flow so the assessor can trace the decision.

API and file transfer integrations

Scheduled file transfers (SFTP jobs), message queues and REST APIs that move CUI between your system and another party are automated exchanges and need their own entry in the inventory. Document the endpoints, authentication method, data elements carried, encryption in transit and the owner on each side. Changes to an endpoint or payload are a reason to review the agreement before the change goes live, not after.

Shared platforms and agreement mapping

Shared platforms, such as a parent organization's identity service or a joint research data repository, can hold CUI for more than one entity. Each party's responsibilities must be written down, and the agreement type should match the relationship: an interconnection security agreement for technical connections, a memorandum of understanding for a shared governance arrangement, a service-level agreement for performance commitments, and a non-disclosure agreement where the exchange involves confidential information without a technical link. Confirm the organization-defined agreement types and review frequency in your own policy, since 03.12.05 leaves those values to you.

Choosing the agreement type for each exchange

The first decision under 03.12.05 is which agreement types the organization will use to govern CUI exchanges. The requirement treats the type as an organization-defined parameter (ODP), chosen from a fixed list: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, user agreements, non-disclosure agreements or other agreements. NIST does not pick the type for you, and no federal agency has been confirmed in this guidance as requiring a particular one for a given exchange. Confirm the expectation with the contracting officer or the agency that holds your contract before you commit to a list, because the answer changes what the assessor will look for. The practical work is mapping each exchange, such as a link to a subcontractor's file transfer service, a shared managed security provider, or a cloud tenant that receives CUI, to the agreement that best governs its security obligations.

Document the selection in a single register that lists each exchange, the system on the other side, the agreement type chosen for it, the owner who approved it, and the review frequency you have set for the second ODP. Selecting an agreement type is only defensible if the register explains why that type fits: for example, why an interconnection-style agreement covers a persistent system link, while a user agreement or non-disclosure agreement covers an individual's access and does not replace the technical terms. Expect the assessor to examine the register against the actual agreements and to interview the people who approve system connections, so each entry should name them. Where you use other agreements, state precisely what they cover, because a generic label will not satisfy an examiner who is checking that the agreement addresses interface characteristics, security requirements and responsibilities.

Defend the choice before the assessment rather than during it. Check that every exchange that carries CUI has at least one agreement of an approved type, that no exchange relies only on an informal email or a vendor's standard terms, and that the register and the agreements agree on the systems and data involved. Ask your legal, procurement and security leads to confirm who signs for each type under your internal delegation rules. Recheck the register whenever a connection changes, because an agreement that describes a retired interface gives an assessor a reason to question the rest of your records.

How an assessor tests 03.12.05

This table shows how an assessor tests 03.12.05 Information exchange under SP 800-171A Rev. 3, which uses only the examine and interview methods. Read each row as one part of the assessment, from the determination statements to the evidence and the findings that most often cause problems.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Determination statements (seven)	Whether the system's CUI exchanges are approved and managed through agreements, the interface and security responsibilities are documented, and agreements are reviewed on schedule	Inventory of every external connection that carries CUI, with the agreement covering each one	Exchanges with partners or cloud services that have no agreement on file
ODP checks (two)	Whether the agreement types and the review frequency are defined for the organization	Written parameter values, such as the agreement types chosen and the review interval, approved by the owner	Agreement types or review frequency left undefined, so the requirement cannot be met
Examine: policies and procedures	Access control and system and communications protection policies, and the procedures for setting up system connections	Current versions with approval dates and owners, showing the procedure for approving a new exchange	Procedures that describe connections in general terms without naming approvers or steps
Examine: agreements	The interconnection security agreements, information exchange security agreements or MOUs in force, and whether each one lists interface characteristics and responsibilities	Signed agreements with interface descriptions, data types, security requirements and named responsibilities for each side	Agreements that are unsigned, expired or do not describe the security responsibilities of both systems
Interview: approvers and managers	Staff who develop, approve and implement system interconnection agreements can explain the approval path and the review cycle	Approval records and a walkthrough of a recent agreement from request to sign-off	Staff unable to name who approves an exchange or when agreements are next reviewed
Interview: system owners	Personnel who manage the systems on each side of an exchange know which agreement covers their connection and what it requires of them	Owner-level list of connections mapped to agreements and their responsibilities	Owners unaware that a feed, API or file transfer is an information exchange under an agreement
Review on schedule	The organization reviews and updates each agreement at the defined frequency and records the outcome	Review log with dates, reviewer names and any changes made after each review	Agreements past their review date with no record of review

Implementing 03.12.05 in order

This sequence turns 03.12.05 from a general expectation into a working inventory of every CUI exchange, approved agreements that describe each interface and its owners, and a review calendar that keeps those agreements current. Each step produces a record an assessor can examine and a person can be interviewed about.

Inventory every exchange of CUI
Start by listing every connection through which CUI leaves or enters the system, including links to other organizations, cloud services, managed providers, shared file transfers, email gateways, and APIs. Assign an owner on each side of the connection and note the data types moving across it. Include exchanges that look informal, such as a scheduled file drop to a partner, because assessors test the whole population of exchanges, not only the ones with signed paperwork. The output is a register of exchanges with one row per interface, reviewed by the system owner and the information security lead, and confirmed as complete against network diagrams and integration records.
Set the agreement types and review frequency
Decide which agreement types your organization will use for each exchange, selected from the types the requirement names: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, user agreements, non-disclosure agreements, or other agreements. Then set the frequency at which those agreements are reviewed and updated. These two choices are the organization-defined parameters for 03.12.05, so they must be written down in the system security plan or the policy that governs it. Confirm with the federal agency or prime contractor whether it has specified any values, because NIST does not assign them and a nonfederal organization must set them when the agency does not. The output is a short parameter record approved by the accountable executive.
Draft agreements with interface details and responsibilities
For each exchange, draft the agreement using the type chosen in the previous step. Document the interface characteristics, such as protocol, endpoints, data classification, encryption method, authentication, and transfer schedule. Document the security requirements each side must meet, and assign responsibilities for monitoring, incident notification, access changes, and decommissioning. Engineering staff who run the interface should review the technical content, while legal or contracting staff review the obligations. The output is a draft agreement per exchange that a reviewer can compare against the inventory row and the interface diagram to confirm nothing is missing.
Obtain approval from the responsible authority
Route each draft through the approval path your policy defines, which typically includes the system owner, the information security function, and the authority that accepts risk for the connection. Approval should happen before the exchange goes live or, for an existing exchange, before the next scheduled transfer. Record the reviewers, the decision, and the date of each approval. Interviews are part of how assessors test this requirement, so the people who approve and manage these agreements must be able to explain what they approved and why. The output is an approved agreement with a traceable approval record for every active exchange.
Record signatories and retain the signed set
Capture the signature of each party that the agreement binds, including the other organization's authorized representative where the agreement is bilateral. Store the executed copies in the same controlled repository as the inventory and the approval records, with version history so you can show the agreement in force on any given date. Where an exchange relies on an existing master agreement, reference that agreement and the schedule or annex that covers the interface. The output is a complete signed set in which each active exchange in the register links to an executed agreement and its approval record.
Build the review calendar and assign owners
Convert the review frequency from the parameter record into a calendar entry for each agreement, with a named owner responsible for starting the review. Add triggers that force an earlier review, such as a change to the interface, a change in data classification, a change of personnel responsible for the exchange, or a security incident involving the connection. Track reviews in the same system as the register so overdue items are visible. The output is a review schedule that shows the next review date for every agreement and the owner for each one.
Verify the set and prepare the evidence file
Before any assessment, check that every exchange in the register has an approved, signed, and current agreement, that the parameter values appear in the policy, and that the review calendar covers every agreement. Walk through two or three exchanges as if you were an assessor, and confirm that the responsible people can describe the interface, the security requirements, and their own responsibilities without looking at the document. Close any gaps and file the results with the system security plan. The output is an evidence package that supports the examine and interview methods used to assess this requirement.

Evidence that satisfies an assessor

An assessor testing 03.12.05 Information exchange examines documents and interviews the people who run them, so the evidence has to show what connects to the system, what was agreed, who approved it and when it was last reviewed. The cards below cover each artifact the assessor will ask for and how to keep it current between assessments.

Exchange inventory

A single register listing every system that exchanges CUI with the system in scope, the direction of flow, the data categories involved and the agreement that governs each link. Assessors start here because it shows whether the agreements they read cover every connection. Check it against network diagrams and integration records each time a connection is added, changed or removed, and record the date of the last reconciliation.

Signed agreements

The executed interconnection security agreements, information exchange security agreements, memoranda, service-level agreements or other agreement types chosen for the organization's ODP values. An unsigned draft does not satisfy the requirement. Confirm that each agreement names both parties, carries signature dates and identifies its review due date.

Interface specifications

Technical documents describing each interface: protocols, ports, endpoints, encryption in use, data formats and the security requirements that apply to each side. These are the interface characteristics the requirement asks you to document. Keep them in the same change process as the systems they describe so a firewall or API change cannot leave the specification stale.

Responsibility matrix

A table showing which party owns each security responsibility for each connection, such as access approval, monitoring, incident notification and key management. Gaps appear quickly when one side assumes the other handles logging. Have both parties sign off on the matrix, and reconcile it whenever a named owner changes role.

Approval and review records

Evidence of who approved each agreement, the approval date and the review cycle set for it, plus the logs of completed reviews. Assessors interview the personnel who develop, implement and approve these agreements, so approval records should name those roles. Keep a dated log of each review, including reviews that found no change.

Version history and policy

Version history showing when each agreement, specification or matrix changed and who made the change, paired with the written policy and procedures for system connections. The history proves the documents were maintained between assessments, and the policy shows the process behind them. Confirm the wiki or document store retains prior versions, so you can show what the agreement said on a past date.

What meeting 03.12.05 costs in money and effort

This table breaks down the cost components of approving and maintaining CUI exchanges under 03.12.05, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a scope and to ask potential partners and auditors for itemized quotes. No dollar figures are supplied here because the cost depends on the number of connections and counterparties in your environment.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it and what to ask for
Legal review of agreements	Internal counsel or outside counsel	Both: initial drafting and negotiation are one-time, amendments recur	Number of counterparties and agreement types chosen for the ODP. Ask for a per-agreement estimate with assumptions stated.
Engineering time for interface documentation	Internal engineering or an implementation partner	One-time per connection, with updates when interfaces change	Number of connections and how many protocols, data flows and boundary devices each one uses. Ask for the documentation deliverable list.
Governance time for approvals and reviews	Internal security, risk and system owners	Recurring, tied to the review frequency you define	Review cadence and the number of signatories per agreement. Ask how approval routing and sign-off records are handled.
Tooling and document management	Software vendors or self-hosted open-source platforms	Open-source licenses can remove license spend; hosting and maintenance remain	Whether agreements and interface records live in a version-controlled wiki or document system. Confirm license terms and support model with each vendor.
Evidence preparation	Internal compliance staff or an implementation partner	Recurring at each assessment cycle	Number of agreements an assessor will examine and whether records are current. Ask for a sample evidence package.
External review	Independent assessor, auditor or outside counsel	Recurring, typically at each assessment or contract renewal	Scope of the assessment and whether assessors interview personnel responsible for agreements. Confirm fees and scope in writing before work starts.
Ongoing maintenance of agreements	Internal owners or a retained support provider	Recurring for as long as exchanges continue	Rate of change in connected systems and counterparties. Ask whether a support retainer covers updates and how change requests are priced.

Who owns the agreements, who prepares the evidence, and who assesses it

Your organization owns 03.12.05 in full. The requirement asks you to approve and manage each exchange of CUI with another system, choose the agreement types and review frequency your organization defines, and keep the agreements current. That work sits with people who can bind the organization: legal counsel who reviews terms, system owners who understand both ends of each connection, and security approvers who accept the risk and sign.

Legal and contracts: confirm that each interconnection security agreement, memorandum of understanding or other agreement is enforceable and names the correct parties.
System owners: describe the interface, data flows and responsibilities on each side, and tell the approvers when a connection changes.
Security approvers: decide which agreement types apply, sign off on security requirements and keep a record of the approval.
Review owner: set the review frequency your organization defines and track due dates for each agreement.
Records: keep signed copies where an assessor can find them and retire agreements for connections that no longer exist.

Confirm with your organization's leadership who holds signing authority and how it is delegated, because an assessor will ask who approved each exchange.

Keeping exchange agreements current between assessments

Scheduled reviews of exchange agreements usually fail for a simple reason: nobody owns the date. The agreement sits in a shared drive, the review frequency is written into a policy, and when the review falls due the person who signed the agreement has changed roles. For 03.12.05, the organization must set the review frequency as an organization-defined parameter, so the first decision is to name one accountable owner per agreement and record the next review date next to the interface description it governs. An assessor will ask for the agreement, the last review, and proof that the interface still matches what the system actually does.

Documentation tools can make that trail easier to keep. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. An ISA or MOU page kept there gives a reviewer a dated history of interface changes, security requirements and responsibility edits. BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. That allows the agreement owner and the system owner to edit an exchange page while other staff can only read it, which supports the separation of duties a reviewer expects to see.

Neither tool decides whether an agreement is adequate, and neither replaces the signed document or the counterpart's sign-off. Before adopting either, confirm that the version history meets your retention and evidence needs, that exported or archived copies are accepted by your assessor, and that role inheritance matches who really approves exchanges. Confirm these points against your own environment, and check each tool's current documentation for capabilities not described here.

Where organizations fall short on information exchange

Information exchange gaps usually come from the same root: the organization knows its CUI flows exist but has not written down who owns each side, which agreement covers it, and when it was last reviewed. Each card below names one gap, why an assessor will notice it under 03.12.05, and the check that closes it.

Undocumented API and file feeds

Scheduled file transfers, webhooks and API integrations often get built by engineering teams and never enter the agreement register. An assessor who walks the system boundary and finds a feed carrying CUI with no agreement will record a finding against the requirement. Check every outbound and inbound interface at the boundary, including feeds to backup, reporting and support tools. Document the interface characteristics for each one before it is counted as approved.

Agreements that name no owner

A signed memorandum of understanding is not enough if it does not say which party is responsible for security on each side of the exchange. Many agreements name the organizations but leave out the accountable roles, the security requirements each system must meet and the contacts for incidents. Review each agreement and confirm it assigns responsibilities per system, with a named role on both ends who can approve changes.

ODP values left unassigned

03.12.05 has two organization-defined parameters: the types of agreements in use and the review frequency. NIST does not set these values, and if the federal agency does not specify them, the nonfederal organization must assign them. An exchange program that never records the agreement types or the review interval leaves the requirement incomplete even when the agreements exist. Record both values in the system security plan and confirm the agreement types match what is actually in place.

Lapsed agreement reviews

Agreements are often reviewed at signing and then forgotten. Once the defined review interval passes without a review, the requirement is not being met, even if the documents are current on paper. Assessors check the dates on review records against the frequency the organization set. Put each agreement on a calendar tied to its review date, and record who reviewed it, what changed and whether the interface is still needed.

No inventory linking agreements to flows

A list of agreements and a list of interfaces can each look complete while describing different things. Without a single inventory that maps each agreement to the exact flows it covers, nobody can show that a given feed is authorized. Build the inventory from network and application data rather than from memory, then reconcile it against the agreement register each review cycle. Unmatched flows should be stopped or documented before the next assessment.

Policy that does not cover exchanges

Procedures for system connections often sit in a network team's runbook while the information exchange policy covers only file sharing with partners. That split leaves cloud connectors, service accounts and vendor integrations outside any approval step. Confirm the policy and procedures name who may approve a new exchange, what evidence is required and how a connection is withdrawn. Test the procedure by picking one recent integration and tracing it through approval.

Questions about 03.12.05 cost, effort and outside help

Can an in-house team implement 03.12.05 without an outside partner?

Yes, in principle. The organization owns its controls, so an internal team can write the agreements, build the interface inventory and set the review schedule without a partner. The harder part is usually time and independence: the people who write the agreements also tend to run the systems they connect, and the assessment team needs evidence that someone other than the builder has reviewed. Teams that lack staff with experience drafting interconnection security agreements or memoranda of understanding often bring in outside help for the drafting and the evidence pack, then keep ownership of every signature and decision. Confirm the scope of any help in writing before work starts.

What drives the effort needed to meet 03.12.05?

The effort follows the number of external connections and how many of them already have a signed agreement. Each exchange needs its agreement type chosen from the list the requirement allows, the interface characteristics and security responsibilities documented on both sides, and a review cycle set. Effort rises when connections are undocumented, when agreements are spread across procurement and business units, or when the other party refuses to sign. The review frequency and agreement types are organization-defined parameters, so the policy decisions take time before any document is written. An inventory of exchanges is the first step that sizes the rest of the work.

Do Rev. 2 or CMMC assessments include an information exchange requirement?

No. 03.12.05 is new in Rev. 3, and NIST maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for 03.12.05. That does not remove the need. A contract that requires Rev. 3 can assess the control, and the organization should still manage its CUI exchanges because the same agreements support other Rev. 2 expectations. Check which revision your contract names before you plan the work, because the DoD and FAR rules discussed in the pillar are still changing.

Who sets the ODP values for 03.12.05 when no agency specifies them?

The nonfederal organization does. NIST does not assign organization-defined parameter values. If a federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. For 03.12.05 that means choosing which agreement types it uses and how often it reviews and updates them. Record those choices in the system security plan and get the contract owner's agreement where possible. Ask the agency or prime contractor early, because a later change to these values can change the work.

What does the work need from the organization?

It needs named owners, access and decisions. Someone must own the inventory of connections and the agreement register. Legal or contracts staff must sign off on agreement templates, and system owners must describe interface characteristics accurately. Security staff must agree on the review frequency and who approves new exchanges. The assessor will interview people with development, implementation and approval responsibilities for these agreements, so those people must be available and able to explain the process. Without this ownership, even a well-drafted agreement will not show that the exchange is managed.

What does an outside partner cost, and what is one-time versus recurring?

No DeployOpen price is published, and any quote follows from a written scope. Costs fall into two groups. One-time work includes the connection inventory, drafting or updating agreements, documenting interfaces and setting the review schedule. Recurring work includes reviewing agreements at the chosen frequency, approving new exchanges and keeping the evidence current. Ask any provider to separate those groups, to state which deliverables are included, and to say who signs each agreement. The NIST assessment guidance itself gives no fixed price for this work, so the figure depends on your environment.

What evidence should we prepare before an assessment?

Prepare the agreements themselves, a register listing each exchange with its agreement type, the interface characteristics and security responsibilities for each side, the approval record, and the review history. The SP 800-171A assessment looks at procedures for system connections and at policy and procedures, so keep those documents current too. Store the register and agreements in a version-controlled wiki or document system so you can show what changed and when. Confirm with your assessor which artifacts they expect in their sample.

How DeployOpen prepares information exchange evidence

DeployOpen's part in 03.12.05 is preparation. Under a fixed written scope, DeployOpen plans the exchange paths between the CUI system and other systems, documents their interfaces, and prepares the agreement packages and supporting records inside the client's own infrastructure. The organization owns its agreements, decides which types of agreements apply to each connection, and signs them. Only an independent assessor examines the evidence and issues assessment results. DeployOpen does not write findings, score the requirement or certify that an exchange is compliant.

In practice, the preparation work starts with an inventory of every connection that moves CUI: partner systems, cloud services, managed providers, and file transfer or API endpoints. For each one, DeployOpen can draft the interface characteristics, the security requirements each side must meet, and the named responsibilities for operating and reviewing the link. The organization then selects the agreement types its own ODP decisions require, such as an interconnection security agreement for a technical link or a memorandum of understanding for a partner relationship. The organization must assign the review frequency and the agreement types, because NIST does not set those values. Confirm them with your contracting officer or agency where a federal requirement applies.

Evidence is kept in the systems the client already runs. Agreements and interface records can be held in a versioned wiki such as XWiki, where each change is recorded with its author and date, or in a documentation platform such as BookStack, where view and edit rights are set per shelf, book or page. Before the assessment, ask the assessor which examine objects they expect, such as the signed agreements, connection procedures and the records of the review cycle, and confirm that each one can be produced from the client's own repositories.

03.12.05 Information exchange