Search demand for a “data sharing agreement template” is high because research-contracts and sponsored-programs offices are repeatedly asked to produce one quickly, but as CASRAI’s guide to data sharing agreements between collaborators and institutions explains, no single universal template works across every institution, funder, and jurisdiction. This page fills a different, narrower need: a concrete, clause-by-clause illustrative example of what a generic, reusable DSA skeleton actually looks like, so that a research administrator drafting one from scratch has a structural starting point rather than a blank page.
When a generic template is (and isn’t) the right starting point
A generic DSA skeleton is genuinely useful for three situations: orienting a new research administrator to what a DSA typically contains before their first negotiation; giving two collaborating labs or offices a shared vocabulary to negotiate from, rather than starting from nothing; and drafting an internal discussion draft to hand to the institution’s contracts office as a starting point rather than asking that office to build one from a blank page. It is not a substitute for institutional review, and it should not be used as-is for any agreement involving personal data, protected health information, export-controlled data, or Indigenous data — those each trigger obligations (GDPR, HIPAA, EAR/ITAR, or the CARE Principles for Indigenous Data Governance) that a generic template cannot responsibly pre-answer. See CASRAI’s guide to GDPR data protection compliance in research and the HIPAA Privacy Rule entry for what those specific obligations add on top of the generic structure below.
Illustrative generic data sharing agreement — clause by clause
The clauses below follow the same five core areas CASRAI’s DSA guide identifies (ownership, permitted use, security and privacy, publication rights, and retention/destruction), plus the surrounding contract mechanics — parties, term, liability, and signatures — that turn those provisions into an executable agreement.
1. Parties and effective date
Identifies the two (or more) institutions entering the agreement — not the individual researchers — and the date the agreement takes effect. As CASRAI’s DSA guide notes, a DSA is normally executed at the institutional level, with a research-contracts or sponsored-programs office signing on the institution’s behalf.
Illustrative clause: “This Data Sharing Agreement (“Agreement”) is entered into as of [EFFECTIVE DATE] (“Effective Date”) by and between [PROVIDING INSTITUTION], having its principal address at [ADDRESS] (“Provider”), and [RECEIVING INSTITUTION], having its principal address at [ADDRESS] (“Recipient”), collectively the “Parties.””
2. Background / recitals
A short, non-binding statement of context: the underlying project or grant, the Parties’ roles, and the general purpose of the data exchange. Useful for interpreting ambiguous clauses later, but it does not itself create obligations.
Illustrative clause: “WHEREAS Provider has collected certain research data in connection with [PROJECT NAME/GRANT NUMBER]; and WHEREAS Recipient wishes to receive and use such data for the Permitted Purpose described in Section 4 below; NOW THEREFORE the Parties agree as follows:”
3. Definitions
Defines the core terms used throughout the agreement precisely enough that “Shared Data” and “Permitted Purpose” can’t be argued about later. At minimum, a working template should define what counts as the dataset itself, what counts as a derivative or downstream work product, and what the approved use case is.
Illustrative clause: ““Shared Data” means the dataset(s) described in Exhibit A, together with any documentation, codebooks, or metadata provided alongside it. “Permitted Purpose” means the specific research use described in Exhibit B. “Derivative Data” means any new data, analysis, or output created by Recipient using the Shared Data.”
4. Data description
Describes exactly what is being shared — typically as a schedule or exhibit rather than in the body of the agreement, since the dataset description often changes independently of the legal terms. Should specify format, volume, whether it contains personal or identifiable information, and the applicable de-identification standard if any was applied before transfer.
Illustrative clause: “The Shared Data is described in Exhibit A and consists of [DESCRIPTION, e.g. de-identified survey response data, n=X records, in CSV format]. Provider confirms the Shared Data has been processed in accordance with [DE-IDENTIFICATION STANDARD, e.g. HIPAA Safe Harbor] prior to transfer, where applicable.”
5. Permitted uses and restrictions
States what Recipient may and may not do with the data — reuse for a different project, sub-licensing, or onward transfer to a third party each normally require a separate amendment or new agreement. CASRAI’s DSA guide flags silence on this point as a common source of later disputes.
Illustrative clause: “Recipient shall use the Shared Data solely for the Permitted Purpose. Recipient shall not: (a) attempt to re-identify any individual represented in the Shared Data; (b) transfer, sublicense, or otherwise make the Shared Data available to any third party without Provider’s prior written consent; or (c) use the Shared Data for any purpose other than the Permitted Purpose without a written amendment to this Agreement.”
6. Data security requirements
Specifies the technical and organizational safeguards Recipient must maintain, and the breach-notification obligation and timeline if those safeguards fail. Where the Shared Data includes personal data subject to the GDPR, this clause needs to satisfy Article 28 controller-to-processor obligations (or joint-controller obligations), and if the data moves outside the EU/EEA, an Article 46 transfer mechanism such as the current Standard Contractual Clauses — see CASRAI’s GDPR and data subject rights under GDPR entries.
Illustrative clause: “Recipient shall maintain administrative, technical, and physical safeguards for the Shared Data no less protective than [STANDARD, e.g. Provider’s own data security policy / NIST 800-53 moderate baseline], including encryption at rest and in transit and role-based access controls limiting access to personnel with a legitimate need. Recipient shall notify Provider in writing within [NUMBER] business days of discovering any actual or suspected unauthorized access to, or disclosure of, the Shared Data.”
7. Publication rights
Covers whether Recipient may publish results derived from the Shared Data, any pre-publication review period Provider retains, and how both Parties are credited or cited. This is the same clause type CASRAI’s Material Transfer Agreement entry describes as a fixed review window before submission, adapted here for data rather than physical materials.
Illustrative clause: “Recipient may publish results derived from the Shared Data, provided Recipient furnishes Provider a copy of any proposed manuscript at least [NUMBER] days prior to submission for Provider’s review and comment. Provider shall not unreasonably withhold comment, and this review right does not extend to withholding consent to publish. Recipient shall acknowledge Provider’s contribution of the Shared Data in accordance with [CITATION FORMAT / DATA CITATION PRINCIPLES].”
8. Ownership and intellectual property
States who retains title to the original dataset and clarifies that ownership of the underlying data and ownership of any downstream publication, database, or derivative work product are separate questions that should not be left implied.
Illustrative clause: “Provider retains all right, title, and interest in and to the Shared Data. Recipient owns any Derivative Data it creates, subject to Provider’s underlying rights in the Shared Data itself and the restrictions in Section 5. Nothing in this Agreement transfers ownership of the Shared Data to Recipient.”
9. Term, retention, and destruction
Sets how long the agreement runs, how long Recipient may retain the Shared Data after the Permitted Purpose is complete, and what counts as acceptable proof of destruction or return.
Illustrative clause: “This Agreement is effective as of the Effective Date and continues until [END DATE / completion of the Permitted Purpose], unless earlier terminated by either Party upon [NUMBER] days’ written notice. Within [NUMBER] days of termination or expiration, Recipient shall, at Provider’s election, destroy or return the Shared Data and certify such destruction or return in writing, except that Recipient may retain a copy solely as required by law or institutional record-retention policy.”
10. Liability and indemnification
Allocates responsibility if the Shared Data is misused or a security obligation is breached, and typically disclaims warranties about the data’s fitness for any particular purpose beyond what was represented.
Illustrative clause: “The Shared Data is provided “as is” without warranty of any kind. Each Party shall indemnify the other against third-party claims arising from that Party’s breach of this Agreement or negligent or wrongful acts in connection with the Shared Data, except to the extent caused by the indemnified Party’s own acts or omissions.”
11. Governing law and dispute resolution
Names the jurisdiction whose law governs the agreement and, often, an escalation or mediation step before litigation — particularly relevant for cross-institutional or cross-border agreements.
Illustrative clause: “This Agreement is governed by the laws of [JURISDICTION], without regard to conflict-of-laws principles. The Parties shall attempt in good faith to resolve any dispute through escalation to each Party’s designated institutional signatory before initiating formal proceedings.”
12. Signatures
Executed by each institution’s authorized signatory — typically the research-contracts, sponsored-programs, or general counsel’s office, not the individual Principal Investigator, consistent with CASRAI’s DSA guide.
How to adapt this skeleton for a real agreement
- Route it through your contracts office first. Treat this as a discussion draft, not a final document — most institutions have their own required boilerplate (indemnification caps, export-control representations, institutional signatory chains) that a generic template cannot anticipate.
- Add privacy-specific terms if personal or health data is involved. Under GDPR, this typically means satisfying Article 28 controller/processor obligations directly in the security clause, plus an Article 46 transfer mechanism (currently the modernized Standard Contractual Clauses) if data crosses outside the EU/EEA. Under HIPAA, it typically means the agreement needs to function as, or reference, a Business Associate Agreement or a limited data set arrangement — see the HIPAA Privacy Rule entry.
- Confirm this is actually the right instrument. A Data Use Agreement is the correct instrument instead of a DSA when access is unidirectional (a single recipient obtaining a dataset from a single source, as with restricted-access repository data); a Material Transfer Agreement is needed instead of, or alongside, a DSA when physical materials are moving, not just data; and multi-party consortium projects sometimes fold these terms into a broader consortium agreement rather than a free-standing DSA. See CASRAI’s comparison of a data sharing agreement vs. data processing agreement for a related but distinct instrument used in controller/processor relationships.
- Check whether human-subjects consent already constrains what you can agree to. Where the underlying research involves human subjects, an IRB or equivalent ethics body typically needs to confirm the proposed data sharing is consistent with participants’ original informed consent before the agreement is finalized — see CASRAI’s IRB/REC Approval Process guide.
- If the obligation is confidentiality only, a simpler instrument may fit better. Confidential but non-personal data (proprietary methods, unpublished results shared for peer feedback) is sometimes covered by a non-disclosure agreement instead of a full DSA, if no restricted-use or retention obligations are needed beyond confidentiality.
Frequently asked questions
Is there a free, ready-to-sign data sharing agreement template?
Not one that should actually be signed without review. As CASRAI’s main DSA guide explains, no single universal template works across institutions, funders, and jurisdictions — what applies depends on whether personal or health data is involved, whether data crosses a border, and each institution’s own contracting standards. The illustrative skeleton on this page shows the standard clause structure so a discussion draft can move faster, but every real agreement needs institutional legal review before execution.
What clauses does a data sharing agreement need at minimum?
At minimum: identification of the parties, a description of the data being shared, permitted uses and restrictions on onward transfer, data security and breach-notification obligations, publication rights, ownership of the underlying data versus any derivatives, term/retention/destruction terms, and liability allocation. CASRAI’s DSA guide groups these into five core areas: ownership, permitted use, security and privacy, publication rights, and retention/destruction.
Who signs a data sharing agreement?
Normally the institution, not the individual researcher — a research-contracts, sponsored-programs, or general counsel’s office negotiates and countersigns on the institution’s behalf, binding the institution rather than the Principal Investigator.
Does a generic template need to change for GDPR or HIPAA data?
Yes, substantially. Personal data subject to the GDPR typically needs the security clause to satisfy Article 28 controller/processor obligations, plus an Article 46 transfer safeguard if data leaves the EU/EEA. Health data subject to HIPAA typically needs the agreement to function as, or accompany, a Business Associate Agreement or limited data set arrangement. A generic template without these additions should not be used for either data type.
How is this different from CASRAI’s main data sharing agreement guide?
The main data sharing agreements between collaborators and institutions guide covers what a DSA is, when you need one instead of (or alongside) a Data Management Plan, and how it differs from a Data Use Agreement or Material Transfer Agreement. This page is the worked-example companion: an illustrative, clause-by-clause generic template built to show that guide’s five core areas in concrete document form.
