CASRAI’s Data Sharing Agreement (DSA) entry defines the term; CASRAI’s Data Sharing Agreements Between Collaborators and Institutions guide explains what a DSA typically covers and how it differs from a Data Management Plan, a Data Use Agreement, and a Material Transfer Agreement. Neither shows what a filled-in agreement actually reads like. This guide fills that gap: a complete, clause-by-clause worked example, so you can see what specific language looks like in each section rather than a list of headings to fill in yourself.
These are illustrative examples, not a real agreement. The document below describes a fictional, composite multi-site research collaboration invented specifically for this guide. No institution, investigator, IRB protocol, or dataset referenced is real, and the clause language should not be copied word-for-word into an actual agreement — a research-contracts office or program officer can generally tell when boilerplate has been lifted from a public example rather than negotiated for the specific project. Its purpose is narrower and more useful than a copy-paste source: to show the level of specificity a working DSA needs, and to make the abstract clause categories in CASRAI’s DSA guide concrete. Every real DSA still needs to be drafted or reviewed by your institution’s research-contracts, sponsored-programs, or general counsel’s office — see the “what this example doesn’t replace” section near the end.
Illustrative study snapshot (fictional)
A three-site observational cohort study examining post-surgical recovery outcomes, coordinated by a lead site (“Institution A”) that designed the protocol and holds the original IRB approval of record, with two collaborating clinical sites (“Institution B” and “Institution C”) each enrolling a subset of the roughly 900 total participants and transmitting de-identified clinical and patient-reported outcome data back to Institution A for pooled analysis. The study is funded by a federal grant that requires a Data Management Plan at the application stage; this DSA is the separate, binding contract executed once the three institutions were ready to actually start moving data, consistent with how CASRAI’s broader DSA guide describes the relationship between the two documents.
Clause-by-clause worked example
1. Parties and recitals
Filled-in version: “This Data Sharing Agreement (‘Agreement’) is entered into by and between Institution A, acting through its Office of Sponsored Programs, as the coordinating site and data recipient for pooled analysis purposes, and Institution B and Institution C (each a ‘Contributing Site’ and together with Institution A, the ‘Parties’), each acting through its own Office of Sponsored Programs, in connection with the study ‘Post-Surgical Recovery Outcomes: A Three-Site Observational Cohort’ (the ‘Study’), funded under [award identifier]. Each Contributing Site is an independent legal entity with its own Institutional Review Board approval for the Study, obtained prior to the transfer of any data under this Agreement.”
Why it’s written this way: naming the actual office that binds each institution (not the individual investigator) reflects who really signs a DSA — see CASRAI’s guide on who negotiates and signs a DSA. Stating that each site holds its own IRB approval, obtained before any transfer, heads off a common review-office objection.
2. Definitions
Filled-in version: “‘Shared Data’ means the de-identified dataset described in Exhibit A, consisting of clinical assessment scores, patient-reported outcome measure responses, and structured demographic variables, and expressly excludes any directly identifying information as defined under the applicable IRB-approved consent and de-identification protocol. ‘Derivative Data’ means any new dataset, variable, or analytic output created by a Party through analysis of the Shared Data.”
Why it’s written this way: defining exactly what counts as “Shared Data” — by reference to a concrete Exhibit A, not a general description — is what makes the permitted-use and security clauses that follow enforceable rather than aspirational. Separating “Shared Data” from “Derivative Data” up front avoids the later ownership dispute CASRAI’s broader guide flags as a common failure point.
3. Permitted use and purpose limitation
Filled-in version: “Each Contributing Site grants Institution A a non-exclusive right to use the Shared Data solely for the pooled statistical analysis described in the Study protocol dated [date] and any protocol amendments approved by all Parties’ IRBs. Institution A may not use the Shared Data for any purpose outside the Study protocol, and may not transfer the Shared Data to any third party, including a Party’s own affiliated researchers not named on the Study protocol, without the prior written consent of the Contributing Site that provided it. Any proposed secondary use requires either an amendment to this Agreement or a new agreement between the relevant Parties.”
Why it’s written this way: this is the clause that actually operationalizes the “permitted use” category CASRAI’s general DSA guide describes — note it names who can say no to onward transfer (the originating site, not the recipient) and requires an amendment rather than leaving re-use silently implied.
4. Data security and privacy obligations
Filled-in version: “Institution A will store the Shared Data on an access-controlled server meeting its institution’s minimum security standard for de-identified human-subjects research data, restrict access to the named study statisticians listed in Exhibit B, and will not attempt to re-identify any participant. Institution A will notify all Contributing Sites within 5 business days of discovering any unauthorized access to, or loss of, the Shared Data. Where any Shared Data is later determined to contain personal data within the meaning of the GDPR, the Parties agree the terms of Exhibit C (data processing terms consistent with GDPR Article 28) will govern that data in addition to this clause.”
Why it’s written this way: a specific notification deadline (not “promptly”) and a named access list are the difference between an enforceable security clause and a vague one. The conditional GDPR reference reflects that a US-based multi-site study may still capture EU-resident participants; where personal data genuinely is in scope, Article 28 requires a written controller-processor contract covering the subject matter, duration, nature, and purpose of processing — see CASRAI’s guide for how that requirement layers onto a DSA, and CASRAI’s entries on GDPR and the HIPAA Privacy Rule for the underlying frameworks where they apply.
5. Publication rights and attribution
Filled-in version: “Any Party may submit a manuscript or abstract using the Shared Data or any pooled analysis for publication, provided a draft is circulated to all other Parties no fewer than 21 days before submission for comment, and provided that the manuscript acknowledges each Contributing Site’s role in data collection consistent with a CRediT role assignment (see CASRAI’s CRediT author statement samples guide) agreed among the Parties’ investigators before submission. No Party may unreasonably withhold comment or delay submission beyond the 21-day review period.”
Why it’s written this way: a fixed review window with a stated length, rather than an open-ended “review period,” is the same mechanism CASRAI’s broader guide points to in a Material Transfer Agreement context — see the MTA entry. Tying attribution to an explicit CRediT role assignment gives the publication clause something concrete to point to instead of a vague “appropriate credit.”
6. Retention and destruction
Filled-in version: “Institution A will retain the Shared Data for the duration of the Study and for [X] years following the Study’s final publication, consistent with its institution’s research-data retention policy and any applicable funder requirement, after which it will securely destroy all copies and provide written confirmation of destruction to each Contributing Site within 30 days. A Contributing Site may request destruction on 60 days’ written notice if it withdraws from the Study, subject to any data already incorporated into a completed or in-progress analysis.”
Why it’s written this way: naming an actual retention trigger (years past final publication, not “as long as necessary”) and a concrete deliverable (written confirmation of destruction, not just an assertion) is what makes a retention clause auditable. See CASRAI’s retention period entry for how the same concept appears in a Data Management Plan, where it is a planning statement rather than, as here, a contractual obligation between named parties.
7. Liability and term
Filled-in version: “This Agreement takes effect upon execution by all Parties and remains in effect until the retention period in Section 6 concludes, unless terminated earlier by mutual written agreement. Each Party is responsible for any breach of this Agreement’s security obligations arising from its own acts or omissions and will indemnify the other Parties for direct damages resulting from such a breach, to the extent permitted under applicable state or institutional law.”
Why it’s written this way: allocating liability to whichever party actually caused a breach, rather than joint-and-several liability by default, is the typical starting position institutional counsel negotiates from — but this is exactly the clause most likely to be redrafted by your own general counsel’s office to match institutional risk tolerance and state law, so treat this line as illustrative of the category, not as language to reuse.
What this example does not replace
As CASRAI’s broader DSA guide explains, there is no single universal template that works across institutions, funders, and jurisdictions, because the right agreement depends on factors a generic form cannot account for. This worked example does not substitute for:
- Your institution’s own template. Most research-contracts or sponsored-programs offices maintain a starting template they adapt per agreement — start there, not with this page.
- A Data Use Agreement, if the actual arrangement is one-directional (a single recipient accessing a single source’s restricted-access data) rather than the multilateral exchange modeled above — see CASRAI’s Data Use Agreement entry and the DSA vs. Data Processing Agreement comparison for the adjacent distinctions.
- A Material Transfer Agreement, if physical specimens or materials are moving alongside the data — standard templates for that include the Uniform Biological Material Transfer Agreement (UBMTA) and the NIH Simple Letter Agreement, discussed further in CASRAI’s MTA process guide.
- Legal review, in every case, particularly where personal data subject to GDPR or HIPAA is in scope, or the transfer crosses a national border and needs a GDPR Article 46 safeguard such as the current Standard Contractual Clauses.
Frequently asked questions
Can I use this worked example as an actual agreement template?
No. It is a fictional, illustrative composite written to show what filled-in clause language looks like, not a vetted legal template. Every real DSA needs review by your institution’s research-contracts or general counsel’s office, which will adapt language to your institution’s risk tolerance, applicable state or national law, and the specific data and funder involved.
Why does the example split data recipient and contributing sites instead of treating all parties identically?
Multi-site studies commonly have one coordinating site that receives pooled data from several contributing sites, which is a realistic and common DSA structure — but a DSA can equally be drafted so every party is symmetrically both a source and a recipient. The asymmetric structure here was chosen because it makes the permitted-use and onward-transfer clauses easier to illustrate concretely.
Does a worked example like this need to mention GDPR even for a US-only study?
Only if personal data within GDPR’s scope is actually involved — for example, if any participant is an EU/EEA resident. The clause above is written conditionally for that reason. Where GDPR genuinely applies, Article 28 requires a written controller-processor contract with specific minimum content, and Article 46 adds a further requirement if data crosses outside the EU/EEA.
How is this different from CASRAI’s other Data Sharing Agreement guide?
CASRAI’s Data Sharing Agreements Between Collaborators and Institutions guide explains what a DSA is, what it typically covers at a conceptual level, and how it differs from adjacent instruments. This page assumes that background and instead shows what filled-in clause language looks like, section by section, for one illustrative composite study.
For the broader research data management landscape this fits into, see CASRAI’s Research Data Management cluster hub.
