RMFInsider

You need an Interconnection Security Agreement (ISA) when your system exchanges data over a dedicated or persistent connection with a system that sits under a different authorization boundary, and especially when that other system answers to a different Authorizing Official. That is the direct answer to the CA-3 question. If the connection is a one-off file transfer through an already-authorized enterprise service, you usually do not need a standalone ISA, but you still need to document the exchange. If the connection is a VPN tunnel, a database replication link, a dedicated circuit, or an API integration that runs every day, you need the agreement, signed by both sides, before the assessor shows up.

I have written and renewed more ISAs than I would like to admit, and the pattern is always the same: the connection has existed for years, the engineers know exactly how it works, and nobody has a signed document that says so. CA-3 exists to fix that. This post covers what CA-3 actually requires in NIST SP 800-53 Rev 5, how ISAs differ from MOUs and MOAs, what NIST SP 800-47 Rev 1 says an ISA should contain, and how to write one that survives an SCA-V without a rewrite.

What CA-3 actually requires

In 800-53 Rev 5, CA-3 was renamed from “System Interconnections” to “Information Exchange,” and that rename matters. Rev 4 focused narrowly on interconnections. Rev 5 broadens the control to cover any exchange of information between your system and another system, and it names the agreement types you can use: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service level agreements, user agreements, and non-disclosure agreements. The control has three parts you have to satisfy:

• CA-3(a): Approve and manage the exchange using one of those agreement types. The organization picks which type fits the exchange.
• CA-3(b): Document, as part of each agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, plus the impact level of the information communicated.
• CA-3(c): Review and update the agreements on an organization-defined frequency. In DoD the default expectation, driven by the CNSSI 1253 parameter values, is at least annually and whenever the connection changes.

The CCIs behind CA-3 in eMASS map to those three parts, so you will need three pieces of evidence: the signed agreement, the technical content inside it, and proof you reviewed it within the last year. A five-year-old ISA with no review signature fails CA-3(c) even if the connection has not changed.

ISA vs MOU vs MOA: which document do you need?

These three get bundled and signed as one package so often that they are treated as synonyms. They are not:

• MOU (Memorandum of Understanding): The business-level agreement. It states that two organizations intend to share data, why, and who is responsible at the executive level. It does not contain port numbers. It is signed by the system owners or their commanders, not the ISSOs.
• MOA (Memorandum of Agreement): Functionally the same layer as an MOU, but with binding terms: cost sharing, funding, specific obligations. In practice a DoD component picks MOU or MOA based on its own legal office preference. Either one is the “why” document.
• ISA (Interconnection Security Agreement): The technical security document. It defines the connection itself: topology, protocols, ports, encryption, data types, impact levels, security controls each side is responsible for, incident reporting, and the points of contact. This is the CA-3 artifact.

NIST SP 800-47 Rev 1, Managing the Security of Information Exchanges (2021), says the MOU/MOA and the ISA can be one document or separate ones. Write them as separate appendices under one signature page. The MOU rarely changes; the ISA changes every time the firewall rule set does, and you do not want to drag a colonel back to the signature block for a port change.

When you actually need one (and when you do not)

The test is not “does data leave my system.” Data leaves your system every time a user sends an email. The test is whether there is a dedicated, persistent, or system-to-system connection that crosses an authorization boundary. Work through these questions:

• Is the other system inside your authorization boundary? If yes, it is an internal component, not an interconnection. Document it in the SSP and the hardware/software list, not in an ISA.
• Is the other system authorized by the same AO, under the same organization? You still need CA-3 documentation, but an internal information exchange agreement or a signed boundary addendum is often accepted in place of a full ISA. Ask your SCA what the AO wants; this varies by component.
• Does the other system belong to a different AO, a different DoD component, another federal agency, or a contractor? You need a full ISA, signed by both sides.
• Is the exchange through an enterprise service that already holds its own ATO (DISA-provided email, an enterprise identity service, a GCC High tenant)? You inherit the connection controls from the provider and reference their authorization. Record the exchange, but a bilateral ISA is not usually required.

The one that catches ISSOs is a contractor-operated development environment that pushes builds into production. The engineers call it “our pipeline.” The assessor calls it an external system connected to an authorized boundary. That is an ISA, and a conversation to have before the kickoff, not during the outbrief.

The boundary diagram and the SSP have to agree with the ISA

An ISA does not live alone. Every interconnection in the ISA must appear as an external connection on your authorization boundary diagram, and every external connection on the diagram must have a corresponding agreement or a documented reason it does not need one. Assessors do this cross-check on day one because it is easy and it is revealing. If the diagram shows four external connections and the package holds two ISAs, the next question is what the other two are, and “legacy” is not an answer.

The same goes for the interconnections section of your System Security Plan. The SSP should carry a table of information exchanges: partner system name, partner organization, connection type, data type and classification, direction of flow, agreement type, agreement date, and review date. The ISA is the detailed backing document; the SSP table is the index. When the two disagree on something as simple as the partner system name (this happens when a partner system gets renamed after a migration), the finding gets written against CA-3(b) and you spend a week reconciling three documents.

How to write the ISA: section by section

800-47 Rev 1 gives a model outline, and DoD components generally accept it as long as the mandatory items are present. Here is the structure I use, in order, with what actually goes in each section.

1. Interconnection statement of requirements

One paragraph: what the connection is for, what mission it supports, and the business need. Name both systems by their registered names and their eMASS or authorization identifiers. State the authorization status of each side (ATO date and expiration, or IATT, or the provisional authorization for a cloud service).

2. System security considerations

This is the technical heart of the document. Cover:

• General information and data description: What data crosses the connection, its classification, and its CUI category or PII status. State the impact level (Low, Moderate, High for confidentiality, integrity, and availability) of the information exchanged, because CA-3(b) requires it explicitly.
• Services offered: What each side provides to the other: file transfer, database query, authentication, web services, print, or whatever it is.
• Data sensitivity and direction: One-way or bidirectional, push or pull, scheduled or real-time.
• User community: Who on each side can use the connection and what clearance or need-to-know they hold.
• Information security controls: Encryption in transit (specify FIPS 140-validated modules and the protocol version), boundary protection on each side, authentication method between systems (certificates, service accounts, API keys and how they are protected), logging and audit responsibilities, and vulnerability scanning responsibilities.
• Trusted behavior expectations: What each side promises about patching and notification before changes.
• Incident reporting: Who calls whom, within what timeframe, and which CSSP is notified. Align this with your IR-6 procedures.

3. Topology drawing

A focused diagram of the connection only: both boundaries, the edge devices (firewalls, VPN concentrators, guards), the path between them, and the protocol and port on each hop. Label the demarcation point where one system’s responsibility ends and the other begins.

4. Signatory authority and review

Signature blocks for each side’s AO or designated representative, plus the ISSMs, and a review log with one row per annual review. That log is your CA-3(c) evidence.

Selecting and tailoring around CA-3

CA-3 is in every CNSSI 1253 baseline, so you cannot tailor it out, but the parameters and enhancements depend on how you selected and tailored your controls in Step 2. Systems with no external connections at all can mark CA-3 not applicable with a justification statement and a boundary diagram showing no external interfaces. Be honest here: a “standalone” system that syncs its time from an external NTP server and pulls patches from a WSUS server outside the boundary is not standalone. It has two information exchanges, and both are trivially documented if you just admit they exist.

Decide early who owns each control on the connection. Write a responsibility matrix into the ISA (SC-8 to the demarcation point, SC-7 at each edge, AU-6 on each side) so your implementation statements can point to it instead of repeating it.

Common ISA findings from assessments

Every one of these has shown up on a SAR I was handed:

• Unsigned or expired agreements. An ISA in draft, or one signed in 2019 with no review log, is a CA-3 finding regardless of how well the connection is secured.
• Partner authorization not verified. You connected to a system whose ATO expired eight months ago. CA-3 expects you to know the authorization status of the other side and to react when it lapses.
• Diagram, SSP, and ISA disagree. Different port numbers, different partner names, or an interconnection on one document that is missing from another.
• No impact level stated. CA-3(b) requires it; pre-Rev 5 templates omit it.
• Encryption described vaguely. “Encrypted VPN” is not a control statement. Name the protocol, version, cipher suite family, and the FIPS validation status.

Maintaining the ISA after signature

Put the ISA review date on the same calendar as your hardware and software baseline review, because the architecture changes that alter one usually alter the other. Trigger an out-of-cycle update for any change to ports or protocols, partner authorization status, hosting location, or data classification. Update the annex, log the review, collect ISSM signatures, and upload the new version to eMASS linked to CA-3.

When the connection is retired, write a short termination memo, get both ISSMs to sign it, and upload it. An assessor who finds an ISA with no termination record will assume the connection still exists, and proving a negative is an unpleasant way to spend an assessment week.

Putting it together for the package

For the authorization package, the ISA set should be complete, current, and consistent with the rest of your RMF artifacts. If you are building or rebuilding a package and want the artifact list, the required agreements, and the cross-checks assessors run in one place, the RMF Checklist is the working document I use for exactly that.