CA-3 Information exchange: requirements and evidence

What CA-3 information exchange requires in plain terms

CA-3 asks you to approve every information exchange between your system and another system, and to record that approval in a written agreement. If your application already sends data to a vendor, a partner bank or an internal reporting platform, and nobody has signed off on that link in a document, you have the gap this control targets. The control does not care whether the other party is external or internal, whether the link is an API, a file drop or a database replication job. It cares that the exchange is known, authorized, described and reviewed.

The control names agreement types such as interconnection security agreements and memoranda of understanding, and leaves room for similar instruments like information exchange security agreements or service level agreements that cover the same ground. Each agreement should document the interface characteristics (what connects, how, over which protocol and at what frequency), the security requirements and controls on both sides, the responsibilities of each party, and the impact level of the information moving across the link. The impact level matters because it should match the categorization of your system. Confirm the exact required elements and review frequency in your organization's own control parameters, since the control leaves those values to the organization to define.

Three problems make this control hard in practice. Interfaces are often undocumented because they were built by a developer years ago and never added to the architecture diagram. Agreements end up owned by no one, so the vendor manager, the system owner and the security team each assume another has them. And periodic reviews never happen because no date is attached to them. Start by pulling interface data from firewall rules, API gateway logs and integration platform configurations, then assign an owner and a review date to each agreement. The assessor will test this against the agreements themselves, so the inventory has to match what the system actually does.

Which exchanges and systems fall under CA-3 in the baselines

CA-3 is selected in the SP 800-53B low, moderate and high baselines but not the privacy baseline, so the first scoping question is whether a system is in a baseline at all. The cards below cover the boundary decisions that determine which connections need an agreement, and which belong to a different control.

Baseline selection comes first

CA-3 is selected in the low, moderate and high baselines but not in the privacy baseline. Confirm the impact level of the system in its security categorization before listing exchanges, because the baseline determines whether CA-3 applies. Where a system is handled only under the privacy baseline, record that CA-3 is not selected and why, so an assessor does not have to reconstruct the decision later.

Transfer authorizations apply only in high

CA-3(6) covers transfer authorizations and is selected only in the high baseline. For a high-impact system, check each exchange that moves data across a boundary where the receiving party must authorize the transfer before it happens. Moderate and low systems still need CA-3 agreements but do not need this enhancement unless the organization adds it through tailoring.

Same system components versus external systems

A connection between components of the same authorization boundary, such as a mobile device, printer or sensor, is governed by CA-9 internal system connections rather than CA-3. CA-3 covers exchanges with other systems outside the boundary. Draw the boundary first, then sort each connection, because a misclassified link either escapes the agreement process or gets documented twice.

Cloud and SaaS integrations

Each API, webhook or managed service that exchanges data with the system is a candidate for a CA-3 agreement, even when the provider's terms are the only paper in place. Ask whether the provider's standard terms document interface characteristics, security requirements, responsibilities and impact level. Where they do not, a separate interconnection or exchange agreement is needed.

Recurring data feeds

Scheduled file transfers, database replication and message queues often run for years without a formal owner. Inventory each feed with its source, destination, data classification and transport method, then confirm that an agreement names the responsible party on each side. Feeds added informally by integration teams are the most common gap an assessor finds under CA-3.

Shared services and enterprise platforms

A system that depends on a shared identity provider, logging platform or network service exchanges information with that service. Decide whether the shared service is an external system with its own agreement or part of a common control set documented elsewhere. Record the decision and the owner, since the answer changes which party signs and which party reviews the agreement.

Third parties under service and confidentiality agreements

Vendors that receive or return data are often covered only by a service level agreement or a non-disclosure agreement. SP 800-53A lists both as examine objects for CA-3, but neither automatically documents interface characteristics or impact level. Check whether each such agreement covers the required elements, and add an interconnection or exchange agreement where it does not.

How an assessor tests CA-3 against SP 800-53A

This table compares the parts of the SP 800-53A assessment for CA-3: the examine objects, the interview objects and the findings that assessors commonly record. Read each row as a question the assessor will ask and the document or person that answers it. The main takeaway is that CA-3 is largely a documentation and ownership test, so each agreement must be traceable to a live interface and a named owner.

Assessment element	What the assessor checks	Common finding
Determination statements	SP 800-53A Rev. 5 assesses CA-3 with 8 determination statements, covering approval, documented interface details, impact level, responsibilities and periodic review of each exchange.	Some statements are met for one agreement but not for the full set of exchanges in scope.
Examine: interconnection security agreements	Whether an ISA exists for each system interconnection, is approved, and states the interface characteristics, security requirements and controls.	ISAs are signed but do not describe the actual ports, protocols or data flows.
Examine: information exchange agreements and MOUs	Whether non-interconnection exchanges, such as file transfers or data feeds, are covered by an agreement with defined responsibilities.	Exchanges with third parties run on informal emails or legacy scripts with no agreement.
Examine: service level and non-disclosure agreements	Whether service levels and confidentiality terms that govern the exchange are documented and tied to the agreement it supports.	Service levels exist in a vendor contract but are not referenced in the exchange agreement.
Examine: enterprise architecture	Whether every interface in the agreements appears in the architecture documents, and whether the architecture matches the live environment.	Interfaces missing from the architecture, or architecture diagrams older than the current connections.
Interview: approving personnel	Whether people who develop, implement or approve system interconnection agreements can explain the approval path and the impact level decision.	Approvers cannot say who accepted the risk or on what basis an impact level was set.
Interview: system managers	Whether personnel who manage the connected systems know which agreements apply to them and what their responsibilities are.	Operators are unaware that an exchange exists or that it is due for review.
Periodic review	Whether each agreement is reviewed at the frequency the organization defined, and whether changes to the interface trigger a review.	Reviews are overdue against the organization's own defined frequency, or no review record exists.

Steps to approve and manage each information exchange

This sequence moves an information exchange from discovery to periodic review, so that every connection between the system and another system has an approved agreement, a documented interface and a review record that an assessor can trace. Each step names the output the assessor will ask to see.

Inventory every external information exchange
Start by listing every path that carries information between the system and another system, including APIs, file transfers, message queues, database replication, email gateways and managed service connections. The system owner and the engineers who built the interfaces do this work, with the security team checking that nothing is missed. Record the other party, the data types, the direction of flow and the network path for each exchange. The output is an interface inventory that the assessor can compare against the architecture. The step is done when every interface traced in network and application configuration appears in the inventory.
Classify each exchange by impact level
Assign each exchange the impact level of the information it carries, using the categorization already recorded for the system. The system owner and the information owner agree on the level, and the security team records the rationale. This classification decides how strict the agreement and its controls must be, so it should be confirmed before any drafting starts. The output is a classified inventory where each row shows the data, the impact level and the accountable owner on each side. The step closes when the owners on both sides have signed off the classification.
Draft the agreement for each exchange
Draft an interconnection security agreement, an information exchange security agreement, a memorandum of understanding or another agreement type your governing authority accepts. The drafting team includes the system owner, the security team and counterparts from the other organization, with legal review where contracts are involved. Each draft should describe the interface characteristics, security requirements, controls on each side, responsibilities for incident notice and change, and the impact level. The output is a draft agreement per exchange with a matching interface description. The step is done when both parties agree the technical content is accurate.
Reconcile agreements with architecture and configuration
Check each draft against the architecture diagram, data flow diagrams and the actual configuration of firewalls, gateways, API gateways and integration platforms. Where the agreement says one thing and the configuration does another, either the agreement or the system must change before approval. The engineers who run the systems do this check, and the security team reviews the differences. The output is a reconciliation record listing each mismatch, its resolution and the date it was closed. This step matters because an assessor will test whether the diagram and the agreement describe the same interface.
Approve and sign each agreement
Route each reconciled agreement to the officials who are authorized to accept the risk of the connection, as defined in the organization's policy. Approval should record who approved, when, and on which version of the agreement, so that later changes can be traced. The output is a signed agreement for each exchange, stored with its version history and linked to the inventory row it covers. The step is complete when no exchange in the inventory operates without a signed agreement that matches its current configuration.
Implement and enforce the agreed controls
Configure the controls named in each agreement, such as encryption in transit, allowlisted endpoints, authentication for the interface, logging of transfers and rate or volume limits. The engineers who operate the systems do the work and record the configuration changes through the change process. The output is a configuration baseline per interface and evidence from a test transfer showing that the control works as the agreement states. The step is done when the configuration evidence matches the signed agreement line by line.
Review agreements at the defined frequency
Review each agreement at the frequency the organization defines in its policy and procedures, and again when the interface, the data or the counterparty changes. Your organization sets the review frequency, so confirm it against the governing authority, such as the authorizing body or the contract, before writing it down. Reviewers check that the inventory is still complete, the configuration still matches the agreement and the impact level still applies. The output is a dated review record for each agreement that states the outcome and any follow-up actions.
Retire or update exchanges and keep records
When an exchange ends or changes, update the inventory, close or revise the agreement, and remove the configuration that is no longer needed. Findings from review that cannot be fixed immediately go to the plan of action and milestones so they remain tracked. The output is an updated inventory, a closure or revision record and a link from each open finding to its remediation entry. The step closes when the inventory, the agreements, the configuration and the review records all describe the same set of exchanges, which is the set an assessor will sample.

Which agreements and records pass CA-3 testing

An assessor testing CA-3 looks for a complete, current set of exchange agreements and the records that show someone reviewed them. The cards below cover the agreements themselves, the technical records behind them and the review trail that proves they stay accurate between assessments.

Signed interconnection security agreements

An interconnection security agreement (ISA) is the core CA-3 artifact for a connection between systems. Each one should name both parties, the interface characteristics, the security requirements each side must meet, the responsibilities for operating the link and the impact level of the information exchanged. Keep the signed version, the approval date and the named approvers together. When an interface changes, the ISA is reopened and re-signed before the new traffic flows. Confirm with your assessor whether they expect ISAs for every connection or only for connections that cross an authorization boundary.

Memoranda of understanding and service agreements

Where a connection is governed by a memorandum of understanding (MOU), a service level agreement (SLA) or a non-disclosure agreement (NDA), the assessor expects to see that document referenced from the relevant ISA. The MOU or SLA should state who is accountable for availability, support hours and incident notification across the exchange. Track the expiration or renewal date of each instrument in your inventory so no exchange runs on a lapsed agreement. Changing a service provider or a support contact is a trigger to update the referencing record.

Interface specifications

The interface specification describes the technical detail behind each agreement: protocols, ports, data formats, message fields, authentication method, encryption and expected volumes. An assessor compares this document against the ISA to confirm the agreement describes what the systems actually do. Store specifications under version control so each revision shows who changed a port or protocol and when. A pull request, change ticket or firewall rule change that alters the interface should link back to the specification and the affected agreement.

Architecture diagrams showing each exchange

Enterprise and system architecture diagrams show every exchange in context, including the boundary, the direction of data flow and the systems on each side. Examiners use them to check that no connection exists without an agreement. Generate or export diagrams from a source you control, and reconcile them against the connection inventory each time a new integration is approved. Stale diagrams are a common finding because they show the design from the original authorization, not the current network.

Impact level recorded per agreement

Each agreement should record the impact level of the information it carries, consistent with the system's security categorization. Assessors check that the level in the ISA matches the categorization in the system security plan and that controls on the exchange reflect that level. Keep the categorization source and the date it was approved in the same repository as the agreement. A change in data sensitivity, such as adding a new field containing personal data, requires re-categorization and an updated record before the change goes live.

Dated review records

CA-3 requires the agreements to be reviewed at a frequency the organization defines, so the review schedule and its completion record are evidence in their own right. Record each review with the date, the reviewer, the agreements examined and any decisions to renew, amend or terminate. Open a POA&M item for any agreement found outdated and close it only when the update is signed. Between audits, use reminders tied to each agreement's review date and retain the record history, so the assessor can see a continuous trail rather than a single snapshot.

Who owns CA-3, who can help, and where the auditor stops

The organization owns CA-3. Someone inside the company must decide which information exchanges exist, who approves them and who answers for them when an interface changes or fails. In practice this usually spreads across three roles: the agreement owner, who keeps the paperwork current and tracks review dates; the system owner, who knows the interface characteristics, data types and connected parties; and the approving official, who accepts the risk of each exchange and signs. Where the organization's governance requires it, the approving official is a senior manager with authority over both systems, not a technical contributor.

Agreement owners: Hold the register of agreements and chase renewals before the review date passes.
System owners: Confirm interface characteristics, data sensitivity and connected parties, and report changes that would make an agreement stale.
Approving officials: Accept the residual risk of each exchange and sign the agreement before data flows.
Legal and procurement staff: Review memoranda of understanding, service level terms and non-disclosure terms with external parties.
Security staff: Confirm the impact level and required controls recorded in each agreement match the system's categorization.

Before the first assessment, confirm in writing who holds each role, because an assessor will ask for that evidence first.

What approving information exchanges costs in money and effort

This table breaks down the cost of approving and managing CA-3 information exchanges into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build your own estimate from your interface and agreement counts, then use the quote checklist to compare written proposals on the same basis.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it
Interface inventory	Internal staff, sometimes an implementation partner	One-time, then updated on change	Number of external connections and internal system boundaries to document
Agreement negotiation	Staff time from security, IT and business owners, plus counterparty time	One-time per agreement, recurring at renewal	Count of third parties and whether each needs an ISA, MOU or simpler exchange agreement
Legal review	Internal counsel or outside counsel billed by the hour or by fixed fee	One-time per agreement, recurring when terms change	Data sensitivity, liability terms and how many counterparties use non-standard language
Technical documentation	Engineers and architects, or an implementation partner under a written scope	One-time, with recurring updates	Protocols, data flows, ports, authentication methods and how often interfaces change
Tooling and licenses	Software vendors for any commercial registers or GRC tools; open-source options carry no license fee	Licenses recur; hosting and setup are one-time	Whether agreements live in a self-hosted register or a commercial platform, and the number of users
Periodic review	Control owners and reviewers within the organization	Recurring at the review frequency the organization sets	Number of active agreements, impact level of each, and the frequency defined in the control
Independent assessment	Independent assessor or auditor, paid under a separate engagement	Recurring with each assessment cycle	Assessment scope, number of agreements sampled and whether the authorization boundary is complex
Evidence upkeep	Staff who keep agreements current and retrievable for assessors	Recurring	Turnover of agreement owners, number of revisions and how quickly changes are recorded

Self-hosted open-source tools that keep exchange evidence current

CA-3 evidence is spread across agreements, interface documents, architecture diagrams and review records, and it goes stale quickly when nobody tracks it. The three tools below cover different parts of that job: one tracks control status across frameworks, one versions the documents themselves, and one controls who can edit them. None of them creates an agreement or replaces the independent assessor, so the organization still owns the content and its approval.

Tracking CA-3 across frameworks

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including NIST CSF, and can run audits and compliance assessments against them with automatic mapping between frameworks. That lets a team record the status of CA-3 once and see where the same exchange evidence also answers controls in other frameworks. Check that the mapping is one your assessor accepts, because an automatic mapping is a starting point and not a determination. Confirm the AGPL-3.0-only license terms for your own use before deploying it, especially if you modify the software and offer it to others.

Versioned agreement and interface pages

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions of an interconnection security agreement or interface description and roll back to an earlier one if an unapproved edit appears. This record helps show that the agreement reviewed at the defined frequency is the one actually in force. Confirm that the version history retention meets your own records policy and that restored versions still go through your approval workflow.

Role-based editing of exchange records

BookStack (MIT) gives each user abilities through the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. An organization can let system owners edit their interface descriptions while limiting approval or publishing rights to the people who sign the agreements. Map those roles to the personnel the assessment method interviews, such as those responsible for approving interconnection agreements. Check that the role settings are reviewed as personnel change, because stale permissions undermine the approval record.

Questions buyers ask about CA-3 before bringing in help

How long does CA-3 readiness take?

The timeline depends mostly on how many information exchanges exist and how many of them already have a signed agreement. CA-3 asks for agreements that cover each exchange, so an organization with a current agreement for every interface can move quickly, while one with informal data feeds has to inventory, negotiate and sign each one first. Other drivers include whether the system already has an accurate interface inventory, how many third parties must review and sign, and whether the authorizing official wants the agreements tied to a specific authorization cycle. NIST does not set implementation timelines for SP 800-53 (that is left to OMB Circular A-130), so ask any partner to base its schedule on the written scope and on your interface count, and to show which steps depend on counterparties outside your control.

How much effort does CA-3 need from our internal team?

Most of the effort falls on people who know the interfaces. Someone must list every connection to another system, identify the data crossing it, and record the interface characteristics, requirements, controls and responsibilities that CA-3 expects each agreement to document. Security and legal reviewers must check the impact level and sign off, and system owners on the other side must agree to terms. Expect recurring effort too, because CA-3 requires periodic review of each agreement, so the interface inventory must be kept current when systems change. Ask any implementation partner which of these tasks it will draft, which it will only prepare for your review, and which your people must complete themselves.

Can a small team handle CA-3 without outside help?

A small team can handle CA-3 alone when it has few interfaces, a single owner for each connection and a clear view of who signs. The work becomes harder when the system exchanges data with many parties, when agreements are split between procurement, legal and engineering, or when no one maintains an interface inventory. Outside help is usually used to prepare the inventory, templates and evidence structure, and to check that each agreement addresses the points CA-3 names, while your staff keeps ownership of the decisions. Whether to bring in help is a capacity question, so compare your interface count and review cadence against the people available to maintain them.

What does an implementation partner handle, and what must we sign?

An implementation partner such as DeployOpen can prepare systems, documentation and evidence for the assessment: the interface inventory, draft agreement structure, records of who approved each exchange, and the review schedule. The organization owns its controls and must approve and sign every agreement, because the agreements bind the organization and its counterparties. Only an independent assessor or certification body issues assessment results or any formal determination. In a written scope, ask the partner to list each deliverable, the people who will review it, and the items it will not touch, such as legal terms or the counterparties' own controls.

What will the auditor ask to see for CA-3?

The assessor will expect to see the agreements themselves and evidence that they are managed. NIST's assessment procedure for CA-3 relies on examining documents such as interconnection security agreements, information exchange security agreements, memoranda of understanding, service level agreements, non-disclosure agreements and architecture documents, and on interviewing the people who develop, approve and manage those agreements and the systems they cover. Expect to show that each agreement records interface characteristics, requirements, controls, responsibilities and impact level, and that a review has happened at the defined frequency. Keep the agreements in version control so you can show what changed and when.

How should we scope CA-3 when many third parties are involved?

Scope CA-3 by system boundary first, then by exchange. List every connection the system makes to another system, including cloud services, payment processors, data feeds and managed providers, and note the data and direction of each. Group exchanges that share the same counterparty, data type and impact level so one agreement can cover them where that is appropriate. Then decide which exchanges need a formal agreement and which need only a documented entry in the inventory, and record the reason. This keeps the review workload proportional. Confirm the approach with your assessor before work starts, because the boundary you choose determines which agreements are in scope.

How DeployOpen prepares CA-3 evidence for your assessment

DeployOpen approaches CA-3 Information exchange as a documentation and evidence problem tied to real system interfaces. We help your team inventory each exchange, draft the agreements that govern it, and keep the records assessors ask for, while your organization keeps ownership of its controls and approvals.

How we scope

We agree a written scope listing which systems, interfaces and external parties fall under CA-3 Information exchange.
We confirm the impact level and the baseline in force, since CA-3 applies to the low, moderate and high baselines.
We record which exchanges need an interconnection security agreement, information exchange agreement or memorandum of understanding.

How we build

We set up a register of exchanges that records interface characteristics, data types, controls and named responsibilities for each one.
We draft agreement templates that cover interface requirements, security controls, roles and impact level, for your legal and security reviewers.
We configure self-hosted tooling so agreement reviews, owners and review dates are tracked and linked to the system security plan.

How we hand over

We deliver the exchange register, completed agreement drafts and review schedule as documents your organization owns and can version.
We map each deliverable to the examine and interview objects assessors use for CA-3, so your team knows where evidence sits.
We document the review cadence and change triggers, and hand over runbooks so your staff can maintain the records after the engagement.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic review of agreements are available as a retainer.
An independent assessor or auditor evaluates your controls and issues any report, since DeployOpen prepares evidence but does not assess or certify it.