Do we need interconnection security agreements under NIST 800-53?
If a contract, agency or assessor asks you to document your connections, the answer under NIST SP 800-53 is yes for most systems: CA-3 requires the organization to approve and manage each information exchange between the system and other systems through agreements such as interconnection security agreements (ISAs) or memoranda of understanding (MOUs). The organization owns those agreements and the decisions in them, while an independent assessor only tests whether the agreements exist, are current and match what the system actually does. Under CA-3, each agreement must document the interface characteristics, security and privacy requirements, controls, responsibilities and impact level of the exchange, and the organization must review agreements at a defined frequency that it sets in its own documentation.
What changes from system to system is the volume and sensitivity of the exchanges. A system with a handful of internal feeds and one external partner needs a short, well-maintained set of agreements, while a system with dozens of connections, including cloud services, payment processors or outside APIs, needs an inventory that ties every interface to an agreement and an owner. The impact level of the data in each exchange should drive how much detail each agreement carries. The baseline also matters: SP 800-53B Release 5.2.0 selects CA-3(6) (transfer authorizations) in the high baseline only, so a moderate or low system does not inherit that enhancement by default. Confirm your selected baseline and any tailoring decisions in your system security plan before you decide which agreements and transfer authorizations you need.
ISA, MOU, SLA or NDA: which agreement fits which exchange
An interconnection security agreement (ISA) fits when two systems exchange information over a technical connection and the security of that connection has to be governed in writing. SP 800-47 Rev. 1 treats the agreement as a management tool, not a template, so the organization tailors what the ISA covers to the risk of the exchange. CA-3 expects each agreement to record the interface characteristics, security requirements, controls, responsibilities and impact level of the exchange, which makes the ISA the natural home for those details when the connection is a network link or an API.
- Interface characteristics: Describe the protocols, ports, endpoints, data flows and direction of each connection so both parties document the same interface.
- Security requirements and controls: State the protections each side applies to data in transit and at rest, along with authentication and logging expectations.
- Responsibilities: Assign who operates, monitors and changes each end of the connection and who responds when it fails.
- Impact level: Record the impact level of the information carried so the agreement matches the categorization of both systems.
- Review and termination: Set the review frequency and the conditions for ending the connection.
Confirm with your authorizing official whether the ISA must be approved as a separate document and whether the counterparty's system is in scope for the same review cycle.
A memorandum of understanding or agreement (MOU or MOA) fits when the parties agree on roles, shared responsibilities and governance for an exchange, and the technical detail sits elsewhere or is handled by the systems themselves. SP 800-37 Rev. 2 lists memorandums of agreement or understanding among the artifacts an authorizing official approves, so an MOU often carries the high-level commitments that the ISA then implements. Many organizations use an MOU between agencies or business units and an ISA for the connection beneath it.
- Parties and purpose: Name the organizations, the business purpose of the exchange and the legal authority that permits it.
- Shared responsibilities: Define what each party commits to at the governance level, including points of contact and escalation.
- Relationship to the ISA: State which technical details live in a separate ISA and which document controls when the two conflict.
- Dispute and change handling: Describe how changes to scope, parties or information types are proposed and approved.
Confirm with the contracting office whether an MOU is binding, what signature authority applies, and whether the authorizing official must review it before the exchange starts.
A service level agreement (SLA) fits when a provider delivers a service that the system depends on and the organization needs measurable commitments on availability, response and support. SA-9 requires that external service providers meet the organization's security and privacy requirements and that the organization monitors their compliance on an ongoing basis, so the SLA is one place where those expectations become enforceable. An SLA on its own does not establish the security terms of an information exchange, so it works best alongside an ISA or MOU that covers the data flows.
- Measurable service targets: Define availability, support response and restoration expectations the organization can verify.
- Security obligations: Reference the security requirements the provider must meet, consistent with SA-9 oversight expectations.
- Reporting and monitoring: Specify what evidence the provider supplies, how often, and who reviews it.
- Remedies: State the consequences of missed targets and the process for corrective action.
Confirm the targets and remedies with the contracting office, since SLA terms are usually negotiated commercially and must match what the authorizing official accepted in the system documentation.
A nondisclosure agreement (NDA) fits when information is shared with a party that needs to see it, such as a vendor evaluating a proposal or a partner reviewing design documents, but no ongoing technical connection or service exists. SP 800-47 Rev. 1 lists nondisclosure agreements among the agreements that protect information exchanges, so an NDA is appropriate when protection is needed before or outside a formal system connection. An NDA does not replace an ISA where data flows into a system on a recurring basis.
- Scope of information: Identify the categories of information covered and whether they include controlled or personal data.
- Permitted use and recipients: Limit who may receive the information and the purposes for which it may be used.
- Handling and return: Set expectations for storage, marking, and return or destruction when the engagement ends.
- Duration: Define how long the obligations last, which may extend beyond the engagement.
Confirm with legal and the contracting office that the NDA's terms match any handling rules that apply to the information, and check whether a recurring exchange later requires an ISA.
SP 800-47 Rev. 1 is written to be tailored, so the choice of agreement type belongs to the organization. The sensible approach is to inventory each exchange, classify it by whether it is a technical connection, a governance relationship, a service dependency or a pre-disclosure review, and then select the agreement that records the controls the exchange needs. Many exchanges need more than one document, and the set should be consistent with the system security plan and the assessment evidence the authorizing official relies on.
- Inventory each exchange: List the systems, parties, data types and direction of every information flow.
- Map each flow to an agreement: Use the table above to decide which document or combination of documents records the controls.
- Check for overlap: Avoid contradictory terms between an MOU, ISA and SLA covering the same exchange.
- Align with the authorizing official: Confirm the agreement set before signing, because the official approves the plans and agreements.
- Record the decision: Keep the rationale for each choice so an assessor can trace it.
Confirm the agreement types, signature authority and review frequency with your authorizing official and contracting office before any exchange goes live.
How an ISA gets approved by the authorizing official
This sequence moves an interconnection from an identified data exchange to a signed agreement that the authorizing official has reviewed, so the approval decision rests on documented interface and protection requirements. Each step produces a record that the next step depends on.
Identify each information exchange
The system owner and the security team list every connection and data flow that crosses the authorization boundary, including the other system, the data categories, the direction of transfer, the mechanism and the business purpose. The output is an inventory of exchanges that maps each one to the CA-3 requirement, so no connection is left undocumented. Confirm the list with the people who operate the interfaces, because informal feeds and file transfers are the most common omissions.
Document interface and protection requirements
For each exchange, the team records the interface characteristics, the security and privacy requirements, the controls that protect the data before, during and after transfer, the responsibilities of each party and the impact level of the information. SP 800-47 Rev. 1 is a useful reference for matching protection to risk without assuming a specific connection type. The output is a requirements sheet per exchange that the agreement can reference directly.
Draft the agreement with the other party
The organization drafts the interconnection security agreement or memorandum of understanding and sends it to the counterpart system owner, who reviews it against their own environment. Both parties agree on the controls each will operate, the review frequency, incident notification responsibilities and how changes will be communicated. The output is a draft that both sides have read and marked up, with open questions tracked to resolution.
Review by security and privacy staff
The information system security officer and the privacy officer check the draft against the exchange inventory and requirements sheet. They confirm that protections match the impact level, that personally identifiable information is covered where it is exchanged and that the agreement names the controls on each side. The output is a review record listing findings and their resolution, which the authorizing official will later see.
Sign by the responsible owners
The system owners of both systems sign the agreement, and where the organizational process requires it, the senior officials who accept the risk of the exchange also sign. Signatures should be dated and tied to the version reviewed in the previous step. The output is a signed agreement stored with the system's authorization documentation, and the team should confirm which roles their own policy designates as signatories.
Submit the agreement to the authorizing official
The package goes to the authorizing official with the signed agreement, the requirements sheet, the review record and the related plan of action and milestones entries for any open weaknesses. Under SP 800-37 Rev. 2, the authorizing official approves the agreement as part of the authorization decision. The output is a recorded approval decision, or a return with requested changes.
Track changes that may require reauthorization
After approval, the team monitors every change to the exchange, such as a new data field, a new endpoint or a change in the counterpart's environment, and checks each against the approved agreement. The authorizing official decides whether a significant change to the system or its environment requires reauthorization. The output is a change log tied to each agreement, which the team reviews at the frequency the agreement sets.
What must be in place before an assessor reviews the agreements
An assessor cannot judge an interconnection agreement in isolation. The agreement only holds up when the connection it describes is known, traceable to the system boundary and owned by named people on both sides. The six items below are the groundwork that makes each agreement testable.
Complete inventory of external connections
Start with a list of every system, service, API, file transfer and shared network path that crosses the authorization boundary, including connections that were added informally and never documented. Each entry should name the counterpart organization and the direction of flow. To check it, compare the inventory against firewall rules, API gateway routes, VPN tunnels and cloud peering configurations. Any connection visible in configuration but absent from the list is a gap an assessor will find.
Data flow documentation
For each connection, document what information moves, its classification, the protocol and the systems at each end of the path. Show where data is stored, cached or logged on the way, because intermediate copies are where exchanges usually fall outside the agreement. To check it, trace a sample record end to end from source to destination and confirm the diagram matches what the logs and configuration show.
Named owners on both sides
Each agreement needs a responsible owner in the organization and a named technical and business contact at the external party. Names should appear in the agreement itself, not only in a directory. To check it, confirm that each contact is still employed in the role, that the owner has authority to accept risk for the connection, and that escalation paths work when a contact is unavailable.
Agreed review schedule
CA-3 requires agreements to be reviewed at a defined frequency, so the organization must set that frequency and record it in each agreement. Tie reviews to triggers as well as dates, such as significant system changes, new data types or a change of counterpart. To check it, look for a dated review history and confirm that the schedule was set by the organization and agreed with the other party.
Register linking agreements to boundary and plan
Maintain one register that maps every agreement to the system it covers, the boundary segment it touches, the system security and privacy plan section that describes the connection, and the impact level. An assessor will test whether the plan and the agreements describe the same connections. To check it, pick three agreements at random and confirm each appears in the plan and the boundary diagram with matching details.
Evidence of the last review
Keep signed review records showing what was checked, who checked it, what changed and which decisions the authorizing official made. Without this record, the agreement looks like a one-time document. To check it, confirm that the most recent review predates any significant change in the connection, that open findings have plan of action and milestones entries, and that approvals are dated and signed by the right officials.
How SA-9 external services overlap with information exchange agreements
An external service provider usually needs two records, not one. SA-9 (External System Services) in the System and Services Acquisition family requires that providers of external system services comply with the organization's security and privacy requirements, that the oversight and user roles for those services be documented, and that provider control compliance be monitored on an ongoing basis through defined processes. CA-3 (Information Exchange) covers something different: the data flows between your system and another system, approved and managed through an interconnection security agreement, memorandum of understanding or similar agreement. A hosted analytics vendor that receives nightly extracts from your system is a case where both controls apply. The SA-9 record shows how the vendor is held to your requirements and watched over time. The CA-3 agreement records the interface, the data moving across it, the controls on each end, responsibilities and impact level.
Work through the relationship one connection at a time. For each external provider, list the services it delivers and the data or system interfaces it touches. A provider that operates part of your system, such as a managed hosting environment or a managed security service with administrative access, needs its SA-9 oversight documented and its compliance monitored. Any interface that moves information between your boundary and the provider's systems also needs a CA-3 entry and an agreement that names interface characteristics, controls and responsibilities on both sides. Some providers will need both, and some will need only one. Record the decision for each provider so that the split is traceable.
Confirm this split with your assessor before you rely on it. Assessors examine SA-9 and CA-3 against the SP 800-53A assessment procedures for each control, and they may read the boundary differently from your team, particularly for shared administration or vendor-managed tooling. Ask the assessor which provider relationships they expect to see covered by each control, and whether the authorizing official expects the agreement and the service record to be the same document or linked documents. The review frequency in each agreement and the SA-9 monitoring cycle should also be set so that they can be shown to run on the same calendar.
Questions buyers ask about interconnection agreements under NIST 800-53
Is an interconnection security agreement always required under NIST 800-53?
Not for every data exchange, but CA-3 requires the organization to approve and manage every information exchange between the system and other systems, and an interconnection security agreement or memorandum of understanding is the usual instrument for doing so. The control does not list which connections need a formal agreement. The organization decides that through its own risk-based review, and the authorizing official can challenge the decision during authorization. Confirm with your authorizing official or contracting office whether a given exchange, such as a one-way file feed or a vendor API, needs a signed document or is covered by existing agreements.
Can a memorandum of understanding replace an interconnection security agreement?
Only if the MOU contains the content CA-3 expects and your authorizing official accepts it as the approved instrument. CA-3 names interconnection security agreements and memoranda of understanding as acceptable vehicles, and each one must document interface characteristics, security requirements, controls, responsibilities and the impact level of the exchange. Many agencies use an MOU for the business relationship and an ISA for the technical detail, so a single MOU that omits the technical content may not satisfy an assessor. Ask the authorizing official which template and sections they expect before drafting.
Who signs an interconnection agreement?
The authorizing officials of the connected systems sign, or their designated representatives do, because the agreement commits each side to controls and responsibilities. Under SP 800-37 Rev. 2, authorizing officials approve plans, memorandums of agreement or understanding and plans of action and milestones, so the signature reflects an accepted risk decision rather than a technical sign-off. Engineers prepare the technical sections, but a signature from a party without that authority can leave an exchange unapproved. Confirm the signatory chain for each partner organization early, because it often sets the timeline more than the technical work does.
How often should interconnection agreements be reviewed?
CA-3 requires agreements to be reviewed at a frequency the organization defines, so the answer comes from your own policy and the agreement's terms, not from a number in NIST's text. Reviews are also triggered by events: a significant change to either system, a change in the impact level of the data, a new interface, or a change in the partner's authorization may require reauthorization decisions under SP 800-37 Rev. 2. Record the review frequency in the agreement and in your continuous monitoring plan so an assessor can trace each review to a dated record. Ask your authorizing official whether they expect an annual review or a review tied to a defined trigger.
What drives the effort of writing and approving an interconnection agreement?
Effort rises with the number of partners, the sensitivity of the data, and how many interface details must be verified. Each agreement needs interface characteristics, protection requirements, control responsibilities on both sides, and the impact level, and each of those items depends on evidence from engineering, security and legal teams. Negotiation time with partners who run different authorization processes usually costs more than drafting. NIST does not estimate compliance costs or set federal implementation timelines, so treat any schedule as something to build from your own inventory of exchanges and to confirm with the authorizing official.
Can our team write these agreements without outside help?
Yes, the organization owns its CA-3 agreements and can write them internally, and many teams do. The work becomes harder when the team lacks an up-to-date inventory of data flows, has no common template with partners, or must reconcile controls inherited from a cloud provider or other external service under SA-9. An implementation partner can prepare the technical inventory, interface documentation and evidence that the agreed controls exist, while the authorizing official and the partner's leadership make the decisions and sign. DeployOpen implements, documents and supports self-hosted open-source platforms in the client's own environment and prepares systems and evidence for assessments. It does not issue audit reports or approvals, so the agreement and its acceptance remain the organization's responsibility.
Where interconnection documentation usually stalls
Interconnection agreements rarely fail because teams lack templates. They stall when the inventory of connections is incomplete, when agreements do not record the impact level, when reviews are not triggered by change, and when the authorizing official receives paperwork that does not match the system boundary. Each card below names one of these points and the check that catches it before an assessor does.
Connections nobody inventoried
Most interconnection gaps start with a connection that exists in code or cloud configuration but not in the documentation. Service accounts, API integrations, managed database replicas, vendor support tunnels and scheduled file transfers are often missing from the system's list of external exchanges. Before drafting any agreement, pull firewall rules, API gateway routes, VPN peers and data pipeline definitions, then reconcile them against the boundary diagram. Ask the system owner to confirm each entry in writing so that CA-3 coverage is based on evidence rather than memory.
Agreements that lack impact level
CA-3 expects each agreement to state the impact level of the information exchanged, along with interface characteristics, controls and responsibilities. Agreements drafted from a generic template often omit the impact level or copy one from another system without checking it. A reviewer will then be unable to tell whether the exchange is protected at the right level. Check that every agreement names the categorization of the data crossing the interface and that the controls listed match that categorization.
Reviews that lapse after a system change
Agreements describe a system as it was when they were signed. A new endpoint, a changed data field, a moved hosting location or a new partner can make an agreement inaccurate while the document still shows a valid review date. CA-3 requires agreements to be reviewed at a defined frequency, and significant changes can also raise reauthorization questions under SP 800-37 Rev. 2. Tie agreement reviews to the change management process so that any change touching an interface reopens the related agreement.
Approvals sent without the boundary
Authorizing officials approve plans, memorandums of understanding and plans of action and milestones, but they cannot judge an interconnection they cannot see. Submitting an agreement without the current boundary diagram, the exchange inventory and the responsibility matrix forces the official to either approve blindly or return the package. Before submission, confirm that the agreement, the system security plan and the boundary diagram describe the same connections with the same names and identifiers.
Who owns the agreements, who prepares them and who assesses them
The organization that operates the system owns every information exchange and every agreement that governs it. Under CA-3, the organization decides which exchanges are approved, signs or approves the interconnection security agreements and memoranda of understanding, and sets the review frequency. The organization also makes the risk decision: it determines the impact level of each exchange and accepts or rejects residual risk, which is the authorizing official's decision to make on its behalf.
- Approval of exchanges: Name the owner who approves each exchange before data moves, and keep that approval on file.
- Signed agreements: Ensure each interconnection security agreement or memorandum of understanding is signed by the parties with authority to bind them.
- Risk acceptance: Document the impact level and the accepted residual risk for each connection.
- Review schedule: Set and track the review frequency defined in your control parameters.
- Decommissioning: Assign an owner to end connections that no longer have a current agreement.
Check that every connection on your inventory has a named owner, a signed agreement and a current review date.
An implementation partner such as DeployOpen can prepare the systems, inventories and documents that the organization reviews and signs. In practice this means mapping the actual data flows between the system and external parties, drafting agreement templates, recording interface characteristics and controls, and assembling the evidence an assessor will request. The partner works inside the client's own infrastructure and does not take ownership of the agreements, sign them, or decide on risk acceptance.
- Flow inventory: Map each exchange, including protocols, endpoints, data types and directions, from the live environment rather than from memory.
- Draft agreements: Prepare interconnection security agreement and memorandum of understanding drafts for legal and security review.
- Control documentation: Record the security controls, responsibilities and interface details each agreement must state.
- Evidence packages: Collect configuration exports, firewall rules and logs that show each exchange behaves as documented.
- Change tracking: Update inventories and drafts when connections change, so review cycles start from accurate records.
Confirm in the scope document exactly which artifacts the partner delivers and which remain with your legal and security staff.
An independent assessor tests whether the documented exchanges and agreements are in place and operating as described. Assessors use the SP 800-53A procedures for CA-3, which call for examining the agreements, interviewing responsible staff and testing the actual connections. Only an independent assessor, auditor or certification body issues an assessment report or certification. DeployOpen does not issue reports, attestations or certifications, and neither does an implementation partner that prepared the evidence.
- Examination: The assessor reviews agreements for the required content, approval and review dates.
- Interviews: Staff who own the connections explain how exchanges are approved and monitored.
- Testing: The assessor compares documented flows with observed traffic and configuration.
- Findings: Each determination is recorded as satisfied or other than satisfied in the assessment report.
- Independence: Confirm the assessor is separate from the team that built the evidence.
Ask any assessor which SP 800-53A procedures they will apply to CA-3 and what evidence they expect before work begins.
How to choose a partner for agreement documentation
An interconnection agreement is only as good as the system boundary, data flows and control responsibilities it describes. The cards below set out what to check in a partner before work starts, and the questions to put to them in writing.
Experience with SP 800-53 system boundaries
Ask whether the partner has mapped system boundaries under SP 800-53 for systems similar to yours, including how they decide what sits inside the boundary and what sits outside it. CA-3 agreements only make sense once the boundary is fixed, so a partner who cannot explain boundary decisions will produce agreements that describe the wrong interfaces. Ask for a sample boundary description, with the interfaces it lists, from a prior engagement with identifying details removed.
Familiarity with SP 800-47 Rev. 1
SP 800-47 Rev. 1 is the NIST guide for managing information exchanges, and it is written to be tailored rather than applied as a checklist. Confirm that the partner can explain how it identifies exchanges, decides the protection each one needs and selects the right agreement type, whether an interconnection security agreement, memorandum of understanding, service level agreement or nondisclosure agreement. Ask which parts of the guide they tailor and why.
Willingness to work in your environment
Interface details, data flow diagrams and configuration of boundary controls live in your environment, so the partner needs access to them without copying sensitive material out. Confirm that the work will run in your cloud accounts, data center or air-gapped network, under your access rules and logging. Ask who holds the accounts, how access is granted and removed, and where drafts and working files are stored.
Fixed written scope
Agree the scope in writing before work starts: which systems and connections are covered, which agreements are drafted or revised, who signs off each one and what happens when a connection changes. A fixed scope makes the price and timeline comparable across bidders. Ask for the list of deliverables, the review cycle assumed by CA-3, and the change process for adding a new interface after approval.
Evidence handover
Agreements, interface diagrams, data element lists and review records should transfer to you in editable, versioned form, with the approval history intact. Ask what the handover package contains, in which formats, and whether the partner will explain each document to your staff so the next review does not depend on them. The authorizing official relies on this record, so gaps here delay approval.
Independence from the assessor
The partner that drafts agreements should not also assess them. Only an independent assessor or auditor issues findings on whether controls are in place, and a firm that prepared the evidence cannot test it impartially. Ask who will assess the agreements, confirm that the partner will not sign assessment results or attestations, and confirm that you can share their documents with your chosen assessor without restriction.
How DeployOpen prepares connection documentation and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the connections those platforms make to other systems can be inventoried, described and evidenced for CA-3. Your organization owns the agreements and approves them, and the authorizing official decides whether they are acceptable.
How we scope
- Engagements are fixed-scope, with the connections, partner systems and agreement types covered agreed in writing before work starts.
- The written scope lists which interfaces, data flows and impact levels are documented for each system in the boundary.
- Ask us to confirm whether the scope includes drafting agreements or only preparing the technical content for your legal and security teams.
How we build
- We map each interface on the platform, recording protocols, endpoints, data types, ports and the systems on each side.
- We prepare interconnection security agreement and memorandum of understanding drafts with technical sections completed for your review.
- We configure and document the controls each agreement assigns to each party, then test that the stated protections are in place.
How we hand over
- You receive a dated register of information exchanges with owners, review dates and the agreements that govern each one.
- Documents are delivered in formats your assessors can examine, such as the system's CA-3 records and supporting configuration evidence.
- Your organization and its authorizing official review, approve and sign agreements. DeployOpen does not issue approvals or attestations.
How we support
- Ongoing support and upgrades can be arranged as a retainer, so the exchange register stays current as connections change.
- We flag changes to interfaces or partner systems that may require agreement updates or reauthorization review by your team.
- Ask us to confirm during scoping how review frequency, change triggers and support hours will be handled under your retainer.
