Exchange Agreements

You meet the HITRUST “exchange agreements requirement” by putting written agreements in place for any information or software exchanged with a third party, and by making those agreements explicit about data classification, each party’s responsibilities, and protections for information in transit (for example, encryption and secure transfer methods) ¹.

Key takeaways:

• Maintain a defined “exchange agreement” standard clause set and trigger it whenever data or software moves to/from a third party.
• Require each exchange to state the security classification of what’s exchanged, responsibility boundaries, and in-transit protections ¹.
• Keep audit-ready evidence: signed terms, data flow descriptions, and proof that secure transfer controls were selected and used.

“Exchange agreements” are easy to misunderstand because most organizations assume their standard contract template already covers them. HITRUST is narrower and more operational: if you exchange information or software with an external party, you need an agreement that specifically addresses (1) the security classification of what’s exchanged, (2) responsibilities on both sides, and (3) controls protecting information in transit ¹. Auditors tend to look for crisp, repeatable execution: a trigger that identifies exchanges, a standard set of clauses or an addendum, and deal-by-deal evidence that the right requirements were attached.

This control shows up across common workflows: file transfers to a claims processor, sending test datasets to a development contractor, exchanging HL7/FHIR messages with a partner, pushing code to a third-party repository, sharing reports via email, or enabling SFTP/API connectivity. The goal is to prevent “shadow exchanges” where teams move sensitive data or software outside your boundary without agreed rules and safeguards.

The rest of this page is written for a CCO, compliance officer, or GRC lead who needs to operationalize the requirement quickly, drive consistent contracting behavior, and pass assessment interviews with clean artifacts.

Regulatory text

Requirement (verbatim): “Agreements shall be established for the exchange of information and software between the organization and external parties. Exchange agreements shall define the security classification of exchanged information, responsibilities of each party, and controls for protecting information in transit.” ¹

What the operator must do:

1. Identify every external exchange of information or software.
2. Ensure there is an agreement governing that exchange (contract clause, addendum, DPA, SOW language, interconnection agreement, or partner agreement).
3. Confirm the agreement explicitly states:

• Security classification of exchanged information (your classification scheme; map to the dataset or interface).
• Responsibilities (who does what, who is accountable, notification duties, subcontractor rules).
• In-transit protection controls (approved transfer channels and security requirements for data in motion).
  All three elements must be present for the exchange to satisfy the control ¹.

Plain-English interpretation (what auditors expect)

Auditors generally test this control by sampling third parties and asking: “Show me the agreement that governs the data/software exchange, and show me where it spells out classification, responsibilities, and transit protections.” If you respond with a generic NDA that doesn’t describe data types or transmission controls, you will likely fail the intent.

Treat this as a repeatable contracting and intake control:

• Intake identifies that an exchange exists.
• Contracting attaches the right terms.
• Security/IT confirms the transfer method matches the promised controls.
• Records management retains the evidence package.

Who it applies to

Entity scope: All organizations implementing HITRUST CSF controls ¹.

Operational scope (what “exchange” includes in practice):

• Data exchanges: ad hoc files, scheduled batch transfers, portal uploads, shared drives, secure email, APIs, EDI, HL7/FHIR interfaces, analytics feeds, support ticket attachments.
• Software exchanges: providing code to a third party, receiving code from a contractor, distributing scripts or executables, sharing container images, sending software updates, granting repo access where code is pushed/pulled.
• External parties: any third party (vendors, partners, contractors, consultants, customers, affiliates outside your boundary).

If a third party can receive your information/software or send you theirs, you have an exchange. If it’s sensitive, regulated, or business-critical, you need the agreement to be explicit and enforceable.

What you actually need to do (step-by-step)

1) Define your “exchange agreement” standard (one-pager + clause library)

Create an internal standard that answers:

• Trigger: When does an exchange agreement apply? (Any third party exchange of information or software.)
• Minimum terms: Classification, responsibilities, in-transit controls ¹.
• Allowed patterns: Contract clause set, standalone addendum, interconnection/security agreement for technical links.

Build a clause library your legal/procurement team can drop into:

• Master services agreements (MSAs)
• Statements of work (SOWs)
• Data processing addenda
• Partner agreements / BAAs (if used in your environment)

2) Inventory exchanges and connect them to third parties

You need a way to answer: “Which third parties exchange what, and how?” Practical approaches:

• Start with your third-party inventory and add fields: “Data exchanged,” “Software exchanged,” “Transfer method,” “System/interface,” “Owner.”
• Cross-check with IT lists: SFTP accounts, API gateways, VPN peers, partner interfaces, shared SaaS folders, repo collaborators.

Deliverable: a living Exchange Register (can be a spreadsheet at first, but it must be owned and maintained).

3) Classify what is exchanged (use your existing classification scheme)

For each exchange, document:

• Data type (e.g., patient data, employee data, financial data, telemetry logs).
• Classification label (e.g., Public/Internal/Confidential/Restricted).
• Whether the dataset is production, test, or synthetic (don’t assume “test” means low risk).

Then ensure the agreement references the classification and applies requirements consistent with that classification ¹.

4) Assign responsibilities on both sides (make boundaries explicit)

In the agreement language (or addendum), spell out:

• Who can initiate transfers and approve access.
• Security responsibilities (encryption, key management model, endpoint security expectations, access control).
• Incident notification responsibilities and coordination points.
• Subcontractor/4th party handling rules (flow-down obligations).
• Data/software handling on termination (return, destroy, certify).

This is where many programs fail: responsibilities are implied, not written.

5) Define and enforce controls for protecting information in transit

Your agreement should reference approved transfer methods and baseline technical requirements, such as:

• Approved secure channels (e.g., SFTP, TLS-protected APIs, secure portals, managed file transfer tools).
• Prohibited channels for certain classifications (e.g., “no unencrypted email attachments” for restricted data).
• Authentication requirements (service accounts, MFA where applicable).
• Integrity protections (hashing/signing) if relevant to software exchange.

Then make it real operationally:

• Security/IT publishes a list of approved transfer patterns.
• Teams must pick from that list (or request an exception with compensating controls).
• The selected method is recorded in the Exchange Register and matches the contract language ¹.

6) Embed the control into procurement + onboarding workflows

Add gates so exchanges cannot “sneak through”:

• Third-party intake form includes “Will data or software be exchanged?” and “How will it be transmitted?”
• Procurement checklist requires exchange agreement terms when “Yes.”
• Security review confirms transit controls for the stated classification.
• Contract repository tags agreements as “Exchange terms present: Yes/No.”

If you use Daydream to manage third-party risk and due diligence workflows, make “exchange agreement required” a rule tied to intake answers and auto-generate the evidence checklist (signed agreement, classification, transfer method confirmation) for each third party.

Required evidence and artifacts to retain

Keep an evidence package per sampled third party. Examiners want traceability from exchange to agreement to control execution.

Minimum artifacts:

• Signed agreement (or executed addendum) covering the exchange and containing:
  • Security classification of exchanged information
  • Responsibilities of each party
  • In-transit protection controls ¹
• Exchange Register entry linking third party ↔ system/interface ↔ data/software ↔ classification ↔ transfer method.
• Data flow or interface description (diagram, ticket, integration design doc, or onboarding worksheet).
• Configuration evidence for the transfer method (examples: SFTP configuration summary, API gateway policy snippet, secure portal settings, repo access controls).
• Exceptions (if any): documented approval, compensating controls, expiration/renewal conditions.

Common exam/audit questions and hangups

Use these as your pre-audit readiness checklist:

1. “Show me the agreement for this exchange.”
   Hangup: agreement exists, but it’s only an NDA or generic MSA.

2. “Where does it identify the classification of the exchanged data?”
   Hangup: classification exists internally but is not referenced in the agreement or addendum.

3. “What controls protect the information in transit?”
   Hangup: teams say “it’s encrypted,” but can’t show the approved method, configuration, or contractual requirement ¹.

4. “How do you ensure new exchanges get captured?”
   Hangup: no intake trigger; exchanges are discovered only after incidents.

5. “Does this apply to software/code?”
   Hangup: program focuses only on data. HITRUST text includes software exchanges explicitly ¹.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Relying on NDAs	NDAs rarely define classification, responsibilities, and transit controls	Use a specific exchange addendum or required MSA clauses 1
Classifying data only in a spreadsheet	Auditors need the agreement to define classification for the exchange	Add classification language tied to dataset/interface
“Encryption in transit” stated without specifics	Vague controls are hard to test and enforce	Name approved transfer methods and minimum requirements
No ownership	Exchanges sprawl across business units	Assign an exchange owner per third party and per interface
Ignoring ad hoc sharing	One-off transfers often contain the most sensitive data	Require secure portal/MFT and record the exchange even if temporary

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this control. Operationally, weak exchange agreements increase the chance of: unauthorized disclosure during transfer, unclear incident accountability, and disputes about whether security controls were required for a specific interface. That translates into harder breach response, slower containment, and poorer audit outcomes because you cannot prove expectations were set in writing.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Publish an internal Exchange Agreement Standard: scope, trigger, minimum terms (classification, responsibilities, in-transit controls) ¹.
• Build the clause/addendum and get legal/procurement approval.
• Identify the top set of third parties with active data connections (start with integrations, file transfers, and outsourced processing).
• Stand up an initial Exchange Register with owners and transfer methods.

By 60 days (Operational rollout)

• Update third-party intake/procurement workflows to ask exchange questions and require the approved clause set.
• Perform a focused remediation sprint: for high-risk exchanges, confirm the agreement has the required terms and amend where gaps exist.
• Publish the approved list of transfer methods and an exception process.
• Train procurement, security, and business owners on the trigger and evidence expectations.

By 90 days (Audit-ready and repeatable)

• Expand coverage to remaining third parties and smaller exchanges (including one-off transfers).
• Implement periodic review: confirm exchanges are still accurate, transfer methods haven’t changed, and agreements are current.
• Run an internal “mock sample” test: pick several third parties and assemble the evidence package end-to-end.
• If you run third-party risk workflows in Daydream, configure required tasks and artifact collection so every new third party exchange produces an audit-ready file automatically.

Frequently Asked Questions

Does an MSA count as an exchange agreement?

Yes, if it explicitly defines the security classification of exchanged information, each party’s responsibilities, and controls protecting information in transit. If it doesn’t, add an exchange addendum or amend the MSA ¹.

Do we need a separate agreement for every file transfer?

You need an agreement that covers each exchange relationship and clearly covers the specific types of data/software and transfer methods involved. For many organizations, one addendum per third party plus an exchange register entry per interface is workable.

What if the third party refuses to name specific transit controls in the contract?

Push for at least an agreed baseline (approved secure channels, encryption requirements, and prohibited methods for sensitive classes). If you accept alternative language, document the risk decision and align the actual technical configuration to what the contract does require ¹.

Does this apply to API integrations and real-time interfaces?

Yes. APIs are information exchanges with external parties. The agreement should identify the classification of data in the API payload, responsibilities, and in-transit protections such as TLS and authentication expectations ¹.

How do we handle “temporary” data sharing with a consultant?

Treat it as an exchange. Use a short-form exchange addendum, require an approved transfer method, and record the exchange in your register with an end date and data disposition requirement.

Are software exchanges really in scope, or only data?

Software is explicitly in scope. If you provide or receive code, scripts, binaries, or updates from a third party, your agreement should cover classification (for example, proprietary), responsibilities, and secure transfer requirements ¹.

Footnotes

1. HITRUST CSF v11 Control Reference