What is a data sharing agreement

A data sharing agreement (DSA) is a contract between two or more organizations that sets out what data one will give the other, for what purposes, under what safeguards, and what the recipient may not do with it. It names the datasets, fixes the permitted uses, allocates responsibility for security and breaches, and says what happens to the data when the arrangement ends.

The defining feature is that the recipient usually gets to use the data for its own purposes, within the limits the agreement sets. That is what separates a data sharing agreement from a data processing agreement, where a vendor processes data only on the customer's documented instructions and holds no independent purpose of its own. Under the European Union (EU) General Data Protection Regulation (GDPR) that instruction-only relationship is what a processor contract must lock down, including confidentiality commitments, security measures, sub-processor conditions, and deletion or return of the data at the end of the service [1]. A data sharing agreement is a different shape: two organizations, each with its own reason for wanting the data.

This guide describes United States practice. Several rules below come from a specific federal regime or a single state statute rather than a general national rule, and each is named in the sentence where it applies. This is general information, not legal advice about a specific arrangement.

The label on the cover page carries no legal weight. The UK Information Commissioner's Office (ICO), whose data sharing code is one of the most detailed public treatments of the document, notes that organizations use titles including information sharing agreement, data or information sharing protocol, and personal information sharing agreement for the same instrument [2]. In US practice you will also see data use agreement, data transfer agreement, data exchange agreement, and simply a data schedule bolted onto a larger contract.

Some documents that look adjacent are not the same thing. The ICO code states that a memorandum of understanding does not on its own constitute a data sharing agreement, except between government departments and certain other public bodies such as regulators and law enforcement bodies, and that neither a list of standards nor an addendum to a purchase agreement or purchase order qualifies [2]. That is UK guidance, but the underlying point travels: a document that records goodwill without binding either side to specific data handling obligations will not do the job.

Two US subtypes are regulatory instruments with fixed contents rather than freely negotiated commercial documents.

The first is the Health Insurance Portability and Accountability Act (HIPAA) data use agreement. A covered entity may disclose a limited data set for research, public health, or health care operations only if it enters into a data use agreement with the recipient. The regulation prescribes what that agreement must do: establish the permitted uses and disclosures, establish who is permitted to use or receive the data, and bind the recipient not to use or further disclose the information other than as permitted, to use appropriate safeguards, to report any use or disclosure not provided for, to hold its agents to the same restrictions, and not to identify the information or contact the individuals [3]. A limited data set is not de-identified data. It is data stripped of a specified list of direct identifiers including names, street address, phone and fax numbers, email addresses, social security and medical record numbers, device identifiers, Internet Protocol (IP) addresses, biometric identifiers, and full face images, while dates and town, state, and zip code may remain [3].

The second is the federal inter-agency family. At the Centers for Medicare & Medicaid Services (CMS), the type of agreement follows the data and the purpose: a data use agreement when another agency requests disclosure of personally identifiable information (PII) or protected health information (PHI) from CMS, an information exchange agreement when CMS PII is exchanged with another federal or state agency without adverse impact on an individual's benefits, and a computer matching agreement when automated systems of record are compared in a way that affects federal benefits or is used to recoup payments or investigate fraud [4]. If a counterparty asks for "a DSA," it is worth confirming which of these they mean before drafting anything.

Purpose and common uses

A data sharing agreement exists to make the terms of the exchange provable before the data moves, and to give both sides something to point at afterwards. It records why the sharing is necessary, what was actually handed over, who authorized it, and what constraints the recipient accepted. The ICO code frames this as accountability: a data sharing agreement is not mandatory under UK law, but having one helps an organization demonstrate that it considered and documented the relevant compliance issues, and the ICO says it will take a relevant agreement into account when assessing a complaint about data sharing [2].

In some US contexts a written agreement is not optional at all.

Research. Controlled-access data is released to approved users under a signed agreement rather than downloaded freely. NIH's genomic data sharing framework runs on a Data Use Certification Agreement carrying terms such as non-transferability, which is why an imputation server may hold uploaded genotypes only briefly before deletion. NIH published a proposal in December 2025 to establish a broader Controlled-Access Data Policy and to revise the Genomic Data Sharing Policy, with comments due by March 18, 2026, so institutions running research data flows should expect this framework to move [5].

Education. The Family Educational Rights and Privacy Act (FERPA) permits disclosure of education records to organizations conducting studies for or on behalf of schools, to develop or validate predictive tests, administer student aid, or improve instruction, but only under a written agreement that specifies the purpose, scope, and duration of the study and the information to be disclosed, restricts use to that purpose, prevents personal identification by anyone outside the organization's representatives, and requires destruction of all personally identifiable information when it is no longer needed [6].

Commercial disclosure under state privacy law. California requires a business that sells personal information to a third party, shares it with a third party, or discloses it to a service provider or contractor to enter into an agreement that specifies the limited and specified purposes, obligates the recipient to provide the same level of privacy protection the statute requires, grants the business rights to take reasonable steps to ensure consistent use, requires the recipient to notify the business if it can no longer meet its obligations, and grants the business the right to stop and remediate unauthorized use [7].

Joint programs and referrals. Two organizations running a shared service, a co-marketing arrangement, or a referral flow each hold their own purpose for the data, so neither is processing on the other's instructions. Under the GDPR, where two or more controllers jointly determine the purposes and means of processing, they are joint controllers and must set out their respective responsibilities in an arrangement between them, and the essential elements of that arrangement have to be made available to the individuals concerned [1].

Parties to a data sharing agreement

There are normally two named parties: the disclosing organization, sometimes called the data provider or source, and the receiving organization, sometimes called the recipient or data user. Getting the legal entity right matters as much here as in any contract. If the recipient is a research institution, the signature that binds it is usually an institutional signing official rather than the individual investigator who wants the data.

The disclosing party is responsible for having the authority or lawful basis to disclose in the first place, for handing over only the fields the agreement specifies, and for accuracy at the point of transfer. Under HIPAA it is also on the hook afterwards: if a covered entity knows of a pattern of activity or practice by the recipient that constitutes a material breach of the data use agreement, it must take reasonable steps to cure the breach or end the disclosure, and report the problem to the Secretary if neither is possible [3].

The receiving party takes on the operational load. It holds the data to the stated purposes, applies the agreed safeguards, keeps its own staff and agents inside the same restrictions, reports incidents, and returns or destroys the data on schedule.

Two more groups matter without signing. Agents, subcontractors, and downstream recipients need to be bound by flow-down terms, and the HIPAA data use agreement requires exactly that of any agent [3]. And the individuals the data describes are not parties but retain rights against the organizations holding their data, which is why the agreement has to say who answers an access request. Under the GDPR a data subject may exercise rights against each joint controller regardless of what the controllers agreed between themselves [1].

Key terms and clauses

Most workable data sharing agreements cover the same ground. The clause names vary; the questions do not.

Data specification. Exactly which datasets, tables, and fields move. The ICO code calls for this level of precision, noting that in some cases only certain information in a file should be shared while more sensitive material is omitted, and that permissions can be attached to individual data items so only trained staff in specific roles may access them [2]. A specification that says "customer records" is not a specification.

Purpose and permitted uses. What the recipient may do with the data, stated narrowly enough to be testable. Every regime above builds on this clause, and it is the one that decides whether a later use is a breach or business as usual.

Permitted recipients and access. Who inside the receiving organization may touch the data, and whether named individuals, roles, or affiliates are covered.

Legal basis or authority. The power under which each side is sharing or receiving. The ICO code notes that the lawful basis for one organization in a sharing arrangement may not be the same as for the other, and that the agreement should record the legal power relied on [2].

Security and safeguards. Technical and organizational measures, transmission method, storage location, and access controls. Common practice is to specify a standard rather than a vague duty of care.

No re-identification and no contact. A standard term in health and research sharing, and a mandatory element of the HIPAA data use agreement [3].

Incident reporting. What counts as a reportable event and how fast it must be reported, from recipient to discloser and onward to any regulator.

Onward transfer. This clause has become load-bearing for US companies sharing data across borders. The Department of Justice rule implementing Executive Order 14117, effective April 8, 2025, prohibits a US person from knowingly engaging in data brokerage giving a foreign person access to government-related data or bulk US sensitive personal data unless the US person contractually requires that foreign person to refrain from onward data brokerage of the same data with a country of concern or covered person, and reports any known or suspected violation of that contractual requirement within 14 days [8]. Countries of concern are China including Hong Kong and Macau, Cuba, Iran, North Korea, Russia, and Venezuela [8].

Individual rights. Who handles access, objection, rectification, and erasure requests, and who is the single point of contact. The ICO code is explicit that all controllers remain responsible for compliance even where the agreement assigns tasks, and that the agreement should name who takes overall responsibility for helping an individual reach all their shared data [2].

Retention, return, and destruction. How long the recipient may hold the data and what proof of destruction is required. FERPA's studies exception makes destruction a condition of the disclosure rather than a courtesy [6].

Audit and remediation rights. California's statute requires the disclosing business to hold rights to take reasonable and appropriate steps to help ensure consistent use, and, on notice, to stop and remediate unauthorized use [7]. Under the United States Department of Justice (DOJ) rule, a US person engaging in restricted transactions must have an independent audit performed once for each calendar year in which it engages in them, covering the preceding 12 months [8].

Term, termination, and survival. Which obligations outlive the agreement. Confidentiality, non-re-identification, and destruction duties normally do.

Important dates and lifecycle events

Data sharing agreements fail quietly, because most of what goes wrong is a date nobody was watching. The dates worth capturing on day one:

Event	Why it matters
Effective date and term	Fixes when the permitted use starts and stops
Underlying approval expiry	An IRB approval, consent, or grant period can end before the contract does
Data refresh or feed schedule	An unscheduled extra transfer is an unauthorized one
Destruction or return deadline	Usually tied to project end, not contract end
Incident reporting clock	The DOJ rule sets 14 days for reporting a suspected onward-transfer violation [8]
Annual audit	Required for each calendar year with restricted transactions under the DOJ rule [8]
Review date	Not a legal deadline, but the only thing that keeps the document current

The review date deserves its own line. The ICO code says arrangements should be reviewed regularly and particularly when circumstances or the rationale for sharing change, that the agreement should be updated to reflect any change, and that a significant complaint or a security breach should itself trigger a review [2]. Adding an organization to the arrangement is another trigger, and the ICO recommends the agreement contain procedures for including additional organizations and for excluding one [2].

Risks and common mistakes

Using the wrong instrument. A processor arrangement dressed as a data sharing agreement gets the wrong clause set. If the other side only ever acts on your documented instructions, you need a processing agreement, not a sharing agreement. See what is a data processing agreement (DPA)? for that side of the line.

Assuming de-identification puts the data out of scope. It often does not. The DOJ rule defines bulk US sensitive personal data as data meeting its thresholds "regardless of whether the data is anonymized, pseudonymized, de-identified, or encrypted," and the thresholds are lower than most people expect: more than 100 US persons for human genomic data, more than 1,000 US persons for other human omic data or biometric identifiers, more than 1,000 US devices for precise geolocation data, more than 10,000 US persons for personal health or personal financial data, and more than 100,000 US persons for covered personal identifiers [8].

Assuming a defined term means what it sounds like. Under California law, "share" is not a general word. It means disclosing personal information to a third party for cross-context behavioral advertising, and "sell" is the broader term covering disclosure for monetary or other valuable consideration [7]. An internal policy that says "we don't share data" may be describing something narrower than the reader thinks.

An open-ended purpose clause. "For business purposes" gives the recipient everything and gives you nothing to enforce.

No flow-down. If the recipient's subcontractor is not bound, the restrictions stop at the first hop.

No destruction evidence. A destruction obligation with no certificate and no deadline is an obligation nobody performs.

Signing once and filing it. The single most common failure. The agreement is signed, the data starts flowing, and three years later nobody can name the current permitted uses, the destruction date, or who owns the relationship.

No named owner. When the person who negotiated the agreement leaves, the arrangement continues without anyone accountable for it.

Contract-management checklist

When the agreement is signed

1. Record the two legal entities exactly as signed, plus the signatory and the internal owner on your side.
2. Capture the dataset specification as structured metadata, not as a sentence in a PDF, so you can answer "what did we send them" without reopening the document.
3. Record the permitted purposes verbatim in a field someone can read in ten seconds.
4. Log the security standard the agreement commits each side to, and confirm it matches what your systems actually do.
5. Note whether flow-down to agents and subcontractors is present, and list any downstream recipients already known.

Diarise before you need it

6. Set the term expiry, the destruction or return deadline, and any notice window as separate reminders, each with lead time rather than on the day.
7. Diarise the expiry of anything the sharing depends on: IRB approval, consent, grant period, license, or funding award.
8. Diarise the annual audit if the arrangement involves restricted transactions under the DOJ rule [8].
9. Set a standing review date, and add review triggers to your incident process so a breach or a significant complaint pulls the agreement back onto someone's desk [2].

Review on a cadence

10. Once a year, reconcile the data actually flowing against the specification in the agreement. Feeds grow fields.
11. Re-check the recipient list. New affiliates, acquisitions, and offshore support teams change who has access without anyone amending the contract.
12. Confirm every expired arrangement actually reached destruction or return, and that you hold the evidence.
13. Amend in writing when the purpose, the datasets, or the parties change, and attach the amendment to the record rather than emailing it.
14. Reassign the internal owner whenever the previous one changes role, and check no agreement is left without one.

Most of this is tracking work, and it is the part that decays first. Contracko is AI contract management software built for it. AI contract analysis reads an uploaded agreement and surfaces the important dates, unfavorable terms, and problems that are easy to miss, the contract repository keeps the signed document, its files, and its metadata searchable in one place, and expiration reminders can be set more than once per contract, assigned to whoever owns the record, and set to repeat when a contract renews. For the wider operating routine, see contract management best practices, and pricing for commercial context.

Start a free trial with the data sharing agreements you already have, and see every destruction deadline, review date, and permitted-use clause in one view.

Sources

[1] European Union, General Data Protection Regulation, Articles 26 and 28 (joint controller arrangements, and what a processor contract must stipulate). gdpr-info.eu/art-26-gdpr and gdpr-info.eu/art-28-gdpr

[2] UK Information Commissioner's Office, Data sharing: a code of practice, the data sharing agreements chapter (alternative names, what to include, and when to review). ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/data-sharing-agreements

[3] HIPAA Privacy Rule, 45 CFR 164.504(e) and 164.514(e) (business associate contracts, the limited data set, and every required element of a data use agreement). govinfo.gov/content/pkg/CFR-2023-title45-vol2/xml/CFR-2023-title45-vol2-sec164-514.xml

[4] Centers for Medicare and Medicaid Services Information Security and Privacy Program. When CMS requires a data use agreement, an information exchange agreement, or a computer matching agreement. security.cms.gov/learn/data-sharing-agreements

[5] National Institutes of Health, NIH Controlled-Access Data Policy and Proposed Revisions to NIH Genomic Data Sharing Policy, 90 FR 59131 (the Data Use Certification Agreement, and the March 18, 2026 comment deadline). govinfo.gov/content/pkg/FR-2025-12-18/html/2025-23246.htm

[6] FERPA regulations, 34 CFR 99.31(a)(6) (the studies exception and the written agreement it requires). govinfo.gov/content/pkg/CFR-2023-title34-vol1/xml/CFR-2023-title34-vol1-sec99-31.xml

[7] California Consumer Privacy Act, Cal. Civ. Code 1798.100(d) and 1798.140 (the required agreement terms, and the definitions of share and sell). leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.100

[8] Department of Justice, 28 CFR part 202, sections 202.205, 202.206, 202.301, 202.302, 202.401, and 202.601 (bulk thresholds, the onward-transfer contract requirement and 14-day report, the annual audit, and the countries of concern). govinfo.gov/content/pkg/FR-2025-01-08/html/2024-31486.htm

Images in this article were generated with the assistance of AI.