Data Transfer Agreement Template (US)

Updated on October 1, 2026

Data Transfer Agreement records how data is transferred from one party or jurisdiction to another under a defined transfer mechanism and security plan. Jotform's source document is too generic: it uses broad promises about security and confidentiality but leaves the role analysis, data schedule, permitted purpose, retention, onward transfer, breach routing and local-law interface underdeveloped.

This US master is written as a practical agreement with a data schedule. It separates the business purpose from the data categories, names privacy roles, limits use, sets security expectations, controls onward disclosure, requires incident notice, and tells users when a separate DPA, SCC module, sector addendum or official form may be needed. It does not claim GDPR, HIPAA, GLBA or state privacy compliance.

0 of 12 blanks filled

Tap any highlighted blank in the document below and type straight into it.Free — no sign-up, no watermark

Data Transfer Agreement

This agreement is made on between , with an address at , and , with an address at .

1. Purpose and Data Schedule

The data is provided only for this permitted purpose:

Data covered by this agreement:

2. Roles and Instructions

Privacy, security, controller, processor, exporter, importer, service-provider, research protocol or other role statement:

3. Permitted Use and Prohibited Use

The recipient may use the data only for the permitted purpose. Prohibited uses, onward sharing or onward transfer limits include:

4. Security, Incident Notice and Onward Disclosure

Security measures: . The recipient must report suspected unauthorized access, loss, misuse or disclosure promptly to the provider and preserve relevant evidence.

5. Outputs, Retention, Return and Deletion

Outputs, publication review, retention, return, deletion or destruction requirements:

6. Governing Law and Disputes

This agreement is governed by the law of . The parties will first try to resolve disputes through good faith discussion between authorized representatives. Either party may seek urgent court relief for confidentiality, safety, data security, intellectual property, collection, or child-protection issues where delay could cause material harm.

7. Entire Agreement and Changes

This document and any attached schedule form the entire agreement for the subject described here. Any change must be in writing and signed by authorized representatives of both parties.

Data Exporter

Date signed:

Data Importer

Date signed:

A data schedule is the heart of the document

The agreement starts by naming the exact dataset, data subjects, identifiers, sensitivity, source system, format, transfer method and permitted purpose. Without that schedule, the parties only have a vague confidentiality promise.

The schedule also reduces purpose creep. A recipient who receives payroll data for migration should not later use it for analytics, model training, marketing or product testing unless the agreement and privacy notices support that new use.

Roles drive obligations

A data sharing, transfer or use agreement should say whether the parties are independent controllers, joint controllers, controller and processor, service provider, researcher, recipient, importer, exporter or another role. Those labels are not decoration; they drive instructions, audit rights, data subject rights, breach notice and return or deletion duties.

The template does not force one universal role. It asks the parties to state the role and link to the controlling DPA, SCC, business associate agreement, public-sector authority, research protocol or vendor agreement where one exists.

Security terms should match the data

Jotform documents often promise "appropriate measures" without a schedule. This template asks for concrete controls: access limits, encryption, MFA, logging, segregation, approved storage, subcontractor access, incident contact and backup handling. The more sensitive the data, the more specific the schedule should be.

Security language also needs ownership. The recipient should know who approves users, who investigates incidents, who pays for remediation, and what evidence can be requested.

Onward sharing is where many agreements fail

A recipient may need affiliates, subcontractors, researchers, auditors or cloud vendors. The agreement should state whether onward disclosure is prohibited, pre-approved, generally authorized with notice, or allowed only under equivalent written terms.

International transfer and onward transfer issues need special care. If EU, UK, Swiss or similar personal data is transferred, the parties may need SCCs, a transfer impact assessment or local mechanism. This master flags that instead of pretending a generic clause is enough.

End-of-use obligations prevent quiet retention

Data should not remain with a recipient forever by default. The agreement includes return, deletion, anonymization, archival and legal-hold language. It also asks whether derived outputs, models, aggregated reports, backups or audit logs remain after the raw dataset is returned.

The document uses careful language because deletion can be limited by law, backups, dispute holds or technical systems. The right answer is a documented process, not a promise nobody can technically perform.

Clause and field guide

Parties and roles: Names the provider/exporter/discloser and recipient/importer/user and states their privacy roles.
Data schedule: Describes data categories, data subjects, identifiers, format, source and sensitivity.
Permitted purpose: Limits the data to a specific business, research, compliance or service purpose.
Prohibited use: Bans sale, unrelated use, re-identification, model training, onward disclosure or publication unless allowed.
Security measures: Sets access, encryption, storage, logging, incident contact and subcontractor controls.
Incident notice: Requires prompt notice, cooperation and evidence preservation for suspected compromise.
Onward transfer: Controls affiliates, subcontractors, cloud vendors, regulators and cross-border transfer mechanisms.
Return or deletion: Explains what happens to raw data, copies, derived outputs, backups and logs at termination.

US compliance checklist

Use this as a data agreement framework. It is not a substitute for a required DPA, SCC module, HIPAA BAA, GLBA Safeguards program, FERPA agreement, research protocol or state privacy assessment.

Document roles and purposes
A data sharing agreement should make purposes, roles, standards and data lifecycle clear.
European Commission standard contractual clauses for international transfers
Use Article 28 terms when one party is a processor
Controller-processor relationships may need mandatory contract terms or approved clauses.
European Commission controller/processor standard clauses
Check international transfer mechanisms
EU/EEA transfers to third countries may need SCCs or another valid transfer mechanism and transfer assessment.
European Commission standard contractual clauses for international transfers
Limit onward sharing
Affiliates, subcontractors and cloud vendors should be named or controlled by equivalent written terms.
Align retention with purpose
Return, deletion, anonymization and backup handling should match the permitted purpose and retention policy.
ICO storage limitation and retention policy guidance

How to use this template

Classify the relationship. Decide whether this is sharing, transfer, processing, research access, vendor service or another arrangement.
Complete the data schedule. List data categories, data subjects, sensitivity, format, source, destination and permitted purpose.
Add security controls. State access, storage, encryption, logging, incident and subcontractor controls appropriate to the data.
Check transfer and sector rules. Add SCCs, DPA terms, BAA terms, FERPA terms or other required addenda when they apply.
Set end-of-use handling. Agree return, deletion, anonymization, retained outputs, backups and legal holds before data moves.

Frequently asked questions

Is this the same as a data processing agreement?

Not always. A DPA is for controller-processor processing. This template may be used for sharing, transfer or use, but a processor relationship needs DPA terms.

Can it replace SCCs?

No. If standard contractual clauses are required, attach and complete the correct module rather than relying on generic transfer language.

Should anonymized data be covered?

Often yes, especially if re-identification, linkage or derived outputs are possible. State the standard and prohibited uses clearly.

Can the recipient use the data for AI training?

Only if the permitted-use clause and notices allow it. If not, model training should be expressly prohibited.

What happens to backups?

Backups should be addressed separately. They may be retained until rotation but should remain protected and not restored for ordinary use.

Who handles breach notice?

The agreement should name incident contacts and cooperation duties, but actual legal notice depends on data type, law, sector and contract.

Related templates

Disclaimer

This template and guide are general information only, not legal, tax, employment, privacy, licensing, financial, safety, or childcare advice. No attorney has reviewed your facts, and nothing here is certified as compliant or approved by a regulator. Federal, state, local, industry, and contract rules differ and change. Check the current rules that apply to you and take professional advice before you sign, send, publish, or rely on this document.