# How to Draft a Data Access Agreement for Multi-Institutional Projects

By the end of this guide you will be able to draft a complete data access agreement (DAA) for a multi-institutional research project, decide whether your consortium should move data to a central location or analyze it where it sits, and write the deposition terms that govern what eventually goes into a public repository. You will also know which clauses reviewers and institutional legal offices treat as non-negotiable.

Have these items on hand before you start drafting:

- The full list of participating institutions, with a named principal investigator and a named administrative or legal contact at each one
- Your protocol or study synopsis, including the data types you plan to collect or reuse
- Your funder's data sharing policy, if one applies
- Draft consent language or a summary of the consent model, since consent terms constrain what the agreement can permit
- The name of the data repository you are considering for eventual public release
- A version number and date for the draft, because these agreements get revised many times

## What a Data Access Agreement Actually Does

A data access agreement is a written contract that specifies who may access a dataset, for what purpose, under which security conditions, and with what restrictions on reuse, redistribution, and publication. It sits between two other documents you may already know. A material transfer agreement governs the physical exchange of biological samples. A data use agreement, in the US clinical context, is a specific regulatory instrument permitted under the HIPAA Privacy Rule for sharing limited data sets. A DAA is the broader contractual document that consortia use to govern access to research datasets, whether those datasets are de-identified, coded, or controlled-access genomic data.

The DAA answers five questions in plain contractual language:

1. Which datasets are covered, described precisely enough that a stranger could identify them
2. Who may touch the data, at which institutions, under whose supervision
3. What the data may and may not be used for
4. How the data must be protected, stored, and eventually destroyed or returned
5. What happens when the project ends, when a new institution joins, or when someone breaches the terms

Research data sharing has become an expected part of scholarly practice over the last few decades, driven substantially by requirements from federally funded research programs [1]. That expectation makes the DAA a routine document rather than an exceptional one. If your consortium has never written one, you are not being overly cautious. You are catching up to standard practice.

## Start Before the Data Move

The single most repeated finding in studies of multi-institutional collaborations is that data sharing terms must be negotiated prospectively, not after disputes arise. Singh and Daar surveyed practical problems in multi-national, multi-institutional genomic collaborations and concluded that a data sharing policy should be negotiated and concluded between collaborators as early as possible, and that sponsors should issue detailed guidance on these issues to facilitate research [2].

The cost of waiting is not hypothetical. A Canadian case study followed a multi-region project that needed to link administrative data to clinical trial data at the individual level. Barriers included inability to share data across provincial borders, incompatible data access request forms, and mismatched [research ethics](/blog/guides/research-ethics-fundamentals-a-practical-guide-for-early-career-scientists) board review processes. The project could not continue past 2022 because those barriers proved too great, even though the team documented solutions along the way for data sharing agreements, data flows, and reviews [3].

Two practical consequences follow. First, put the DAA on the critical path of your project plan, with the same urgency as protocol finalization and ethics approval. Second, use harmonized templates wherever your consortium spans multiple jurisdictions or institutions. An analysis of harmonized documentation for multi-stakeholder data access requests found that consent forms without the language required by administrative data stewards slowed the entire access process down, and that harmonizing consent forms, data access request forms, and research agreements was a priority for reducing delay [4].

## The Clause Architecture Used by Major Consortia

You do not need to invent your agreement from a blank page. A document analysis published in Genetics in Medicine examined 29 different data access agreements used by human biomedical research consortia around the world, identified the most common categories of clauses, characterized the legal positions for each element, and synthesized the results into 15 unique model data access clauses. The authors concluded that such model clauses can drive administrative efficiencies and institutional compliance for managing access to human genomic data, and noted that additional machine-readable consents and software solutions are needed to communicate data use conditions throughout the data life cycle [5].

The Global Alliance for Genomics and Health (GA4GH), an international standards organization, published that work through its Ethical Provenance Subgroup. Those 15 model clauses give you a checklist. At minimum, your draft should contain sections covering each of the following, which recur across consortium agreements as general contract categories:

1. Parties and recitals, naming every institution and the purpose of the collaboration
2. Definitions, especially "Data," "Recipient," "Authorized Personnel," and "Permitted Purpose"
3. Permitted use and prohibited use, including a prohibition on re-identification of de-identified data
4. No redistribution and no secondary sharing without written permission
5. Security safeguards, including institutional security review and incident notification
6. Data security breach notification duties and timelines
7. Publication policy, including prepublication review windows and attribution rules
8. Intellectual property treatment of derived datasets and analysis results
9. Compliance with applicable laws and institutional policies at each site
10. Subcontractors, students, and visiting researchers as bound agents of the institution
11. Auditing rights and record keeping
12. Termination, data return, and data destruction
13. Amendment procedures when a new site joins the consortium
14. Dispute resolution and governing law
15. Signatures from authorized institutional officials

You can find the GA4GH model clauses publicly on the GA4GH website and use them as a starting skeleton. Because they were synthesized from real consortium agreements, they tend to survive institutional legal review with fewer revisions than an agreement drafted from scratch.

## Choose Your Sharing Architecture Before You Draft

![Comparison of centralized deposit, controlled-access federation and public repository release, showing where data go, key clauses and best fit.](/article-images/illustrations/data-access-agreement-template-multi-institutional-architecture-compare.webp)

The architecture you choose determines which clauses matter most. There are three main options, summarized here.

| Architecture | Data moves where | Primary clauses to emphasize | Best fit |
|--|--|--|--|
| Centralized deposit | All sites send data to one hub or repository | Security of transfer, de-identification standard, deposition timeline | Small, homogeneous datasets with consent that permits transfer |
| Controlled-access federation | Data stay at each site, queries or model training move instead | Federated analysis protocol, audit rights, results-only disclosure | Human genomic or clinical data with restrictive consent |
| Public repository release | Data go to an open or registered-user repository at project end | Deposition terms, embargo period, metadata standards, citation | Data collected with broad consent, no re-identification risk |

Federated approaches deserve special attention because they change what the DAA has to protect. In federated learning, model training is distributed to the data-owning institutions and only the learned model updates are aggregated, so patient data never move between sites. In a demonstration across 10 medical institutions, federated models reached 99 percent of the quality achieved by models trained on centrally pooled data [6]. A multi-center PET imaging study applied the same principle across six centers with 50 patients each, using scanners, acquisition protocols, and reconstruction methods that varied across sites, and trained correction models without direct data sharing [7]. A 2025 review of federated learning in medical imaging highlights why this matters for drafting: the time and effort required to convey ethical agreements, manage acquisition procedures, and handle anonymization is a pivotal challenge, and heterogeneity in hardware vendors and acquisition protocols complicates integration [8].

If your consortium can achieve its scientific goals by exchanging model parameters or summary statistics instead of row-level patient data, write the DAA around that fact. A security-oriented clause set for a federated project covers different risks than one for a centralized warehouse. Privacy research on multi-institutional healthcare data sharing has pushed in this direction, proposing attribute-based encryption schemes with partially hidden access policies to protect encrypted data stored across healthcare institutions while still supporting fine-grained, updatable access control [9]. Those technical mechanisms only work if the contract describes who holds decryption authority and how access policies may change, so the legal text and the security design must be drafted together.

## Step-by-Step Walkthrough

![Flowchart from data inventory and regulatory mapping through architecture choice, clause drafting, governance and machine-readable conditions.](/article-images/illustrations/data-access-agreement-template-multi-institutional-drafting-flowchart.webp)

Work through the following ten steps in order. Each step produces a piece of the final document.

### Step 1: Inventory and classify your data

List every dataset the project will generate or reuse. For each one, record the data type, whether it contains direct identifiers, coded identifiers, or none, the consent language that covers it, and the institution of origin. A spreadsheet with one row per dataset is sufficient. This inventory becomes Annex A of your agreement, and every clause that follows refers back to it.

### Step 2: Map your regulatory obligations

Human-subjects data in US clinical research typically implicate the HIPAA Privacy Rule and, for federally funded human-subjects research, the Common Rule. Stakeholders at US academic cancer centers interviewed about grid-based data federation raised concerns rooted in HIPAA and 21 CFR Part 11 and emphasized that new data sharing models pose new challenges for regulatory communities and adopters alike [10]. Your institutional compliance office will tell you which rules apply to each site. Record them per institution, because a multi-state consortium can have different obligations at different sites.

### Step 3: Select the sharing architecture

Use the table above. Write one sentence in your draft stating the architecture, for example, "Data shall remain at the Contributing Institution and analysis shall proceed by federated methods in which only model parameters and summary statistics leave the site." That single sentence eliminates or simplifies many later clauses.

### Step 4: Draft the preamble, parties, and definitions

Open the document with a template skeleton. Here is a working skeleton in Markdown that you can paste into any text editor:

```markdown
# DATA ACCESS AGREEMENT
**Project title:** {{PROJECT_TITLE}}
**Lead institution:** {{LEAD_INSTITUTION}}
**Participating institutions:** {{FULL_LIST}}
**Effective date:** {{YYYY-MM-DD}}
**Agreement version:** {{v1.0}}

## 1. Definitions
1.1 "Data" means the datasets described in Annex A.
1.2 "Recipient" means {{INSTITUTION}} and the Authorized Personnel
    listed in Annex B.
1.3 "Permitted Purpose" means {{RESEARCH_AIM_IN_ONE_SENTENCE}}.
1.4 "Authorized Personnel" means employees, students, and
    contractors of a party who are listed in Annex B and have
    signed a confidentiality acknowledgment.

## 2. Permitted Use and Restrictions
2.1 The Recipient may use the Data solely for the Permitted Purpose.
2.2 The Recipient shall not attempt to re-identify de-identified data.
2.3 The Recipient shall not redistribute the Data to any party
    not named in this Agreement without prior written consent
    of the Contributing Institution.

## 3. Security
3.1 Each party shall apply institutional information security
    safeguards consistent with its own policies and applicable law.
3.2 Each party shall notify all other parties of any suspected
    data breach within {{NUMBER}} hours of discovery.

## 4. Publication
4.1 Manuscripts shall include all Contributing Institutions in
    authorship per the project publication policy (Annex C).
4.2 Manuscripts shall be provided to all parties {{NUMBER}} days
    before journal submission for review of confidentiality
    and data use compliance.
```

The expected output after filling it in for a real project looks like this:

```markdown
## 1. Definitions
1.1 "Data" means the coded MRI scans and clinical variables
    listed in Annex A, version 3, deposited 2026-05-01.
1.2 "Recipient" means Riverside University and the Authorized
    Personnel listed in Annex B.
1.3 "Permitted Purpose" means development and validation of a
    segmentation model for gross tumor volume delineation in
    pancreatic cancer radiotherapy planning.
```

Note what a good definition of "Data" accomplishes. It pins the agreement to a versioned, dated, named dataset. Without that anchor, disputes later about whether a new data wave is covered are almost guaranteed.

### Step 5: Write the permitted use clause around consent, not ambition

The Permitted Purpose must never be broader than what participants consented to and what ethics approvals cover. Copy the operative consent sentence into the agreement's recitals so that any future reviewer can see the alignment. If consent permits oncology research generally but not commercial use, say both things explicitly in clause 2.

### Step 6: Write the security section with your information security office

Generic security clauses fail institutional review. Bring the draft to each participating site's information security office and ask what they can actually commit to. Common commitments include encryption at rest and in transit, multi-factor authentication for the analysis environment, logging of data access events, and annual attestation. If you chose a federated architecture in Step 3, the security section should describe where computation happens and what leaves the site.

### Step 7: Write the publication and attribution clauses

Multi-institutional projects fail over authorship more often than over data. Decide before signatures whether all contributing institutions appear on every manuscript, whether a consortium name is used instead, and how the prepublication review window works. Thirty days is a typical review window in consortium agreements, but the exact number is yours to negotiate. State it in days, not "reasonable time."

### Step 8: Establish the governance committee

Name a small data access committee with one representative per site that approves additions to Annex B, reviews deviation requests, and handles breach response. The experience of five large consortia formed during the COVID-19 pandemic to analyze real world data showed that consortium composition, governance structure, data sharing, data analysis, and evidence dissemination were the dimensions that determined success, and that different governance approaches all proved workable when priorities were centrally aligned [11]. Your DAA should at least name the committee, its decision rule (for example, consensus or majority), and its escalation path.

### Step 9: Write the amendment and accession clause for new sites

Multi-institutional projects grow. Write a clause that lets a new institution join by executing a simple joinder document that incorporates the existing agreement by reference. Without this clause, every new site triggers a full renegotiation.

### Step 10: Add machine-readable use conditions

Because consortia increasingly need to communicate data use conditions across the data life cycle with software rather than prose alone [5], attach a structured record of the core permissions. A simple YAML record looks like this:

```yaml
data_use_conditions:
  dataset_id: "PROJ-2026-CRC-SEQ-v3"
  permitted_purpose: "disease_research: colorectal cancer genomics"
  no_reidentification: true
  no_redistribution: true
  commercial_use: false
  publication_review_days: 30
  contact: "dac@lead-institution.example.edu"
```

This record travels with the dataset into the repository and lets downstream systems verify the conditions automatically. The expected output when a downstream tool reads it is a yes-or-no compliance check against each requested use, which is far faster than email negotiation.

## Depositing Data and Choosing a Repository

Most DAAs include a final clause on public or controlled-access release. A quick data repository comparison on the dimensions that matter will save you a rewrite later. Evaluate candidates on these five criteria:

1. **Access model.** Open download, registered-user download, or managed access with a data access committee. Your consent language decides this, not your preference.
2. **Identifier stability.** The repository should mint a persistent identifier such as a DOI so the dataset can be cited.
3. **Metadata completeness.** Metadata quality across published research datasets is uneven, with key fields such as author affiliation often missing or incomplete [1]. Prefer repositories with required, validated metadata fields.
4. **Curation support.** Some repositories review and improve submissions. Others accept files as deposited.
5. **Cost and sustainability.** Ask about storage duration guarantees before you commit in the agreement.

The Chilean Soil Organic Carbon database shows what a successful multi-institutional compilation looks like when it reaches this stage. CHLSOC compiled 13,612 soil organic carbon data points from numerous sources, including unpublished and hard-to-access records, and released the database freely to registered users under a persistent identifier [12]. Notice the agreement-like discipline behind it: a defined scope, a defined access model, and a citable release.

An analysis of where academic research data are actually shared, using DataCite and Crossref records from six US institutions between 2012 and 2022, found that the top 10 repository publishers accounted for 89.0 to 99.8 percent of the datasets connected with those institutions, and that known repositories, including institutional ones, were initially missed because of inconsistent metadata practices [1]. The lesson for your DAA is to name the repository explicitly in the agreement rather than promising vaguely to deposit "in an appropriate repository," and to assign responsibility for complete metadata.

## Common Mistakes and Limitations

**Drafting after the first data transfer.** Waiting until data have moved turns a negotiation into a remediation. Every analysis of multi-institutional collaborations that examined timing reached the same conclusion, that prospective negotiation is the norm and retrospective negotiation is the failure mode [2].

**Assuming consent language travels across institutions.** Each site's consent forms and ethics approvals differ. An analysis of multi-stakeholder data access found that consent form templates supporting ethics board requirements often lacked the text required by administrative data stewards, which slowed access requests [4]. Verify consent text at every site before the agreement states a Permitted Purpose.

**Ignoring jurisdictional borders.** A multi-region Canadian project terminated because data could not legally cross provincial borders in the required way [3]. Map cross-border data flow rules for every participant before you promise a centralized analysis in the agreement.

**Overpromising security in the text.** Write only the security commitments your institutions can actually meet and verify. Interviews with regulatory decision makers at US cancer centers about data federation showed that adopters struggled with assumptions about how sharing models would interact with existing regulatory obligations [10]. Concrete, auditable commitments beat aspirational ones.

**Leaving the repository unnamed.** A clause promising eventual deposit without naming the repository, access model, and embargo terms defers the hardest decision to the project's end, when everyone is tired and the funding clock has run out.

**Treating the DAA as pure paperwork.** Institutional data integration maturity, measured across indicators such as interface coverage, mapping completeness, and auditability, varies widely across institutions and correlates with collaboration performance outcomes [13]. The agreement is the contract, but the operational readiness behind it is what makes the collaboration work.

**A note on limits.** This guide covers the drafting process and standard clause categories. It is not legal advice. Every institution's counsel will revise specific language, and individual projects face individual constraints that only your own legal and compliance offices can resolve.

## Frequently Asked Questions

### Is there a free data access agreement template multi-institutional option I can use?

Yes. The GA4GH model data access clauses are publicly available and were synthesized from 29 real consortium agreements, which makes them a strong free starting point [5]. Combine them with the skeleton in this article and adapt with your legal office.

### When should the data access agreement be signed?

Before any data moves and ideally before data collection begins. Studies of multi-institutional collaborations consistently recommend prospective negotiation as early as possible in the project [2].

### What is the difference between a DAA and a data use agreement?

A DAA is a general contractual document governing access to research datasets. A data use agreement is a specific HIPAA-defined instrument for sharing limited data sets in the US clinical context. Many projects need both, with the DAA governing consortium conduct and the data use agreement satisfying the regulatory requirement.

### What happens if one institution will not share its data?

Federated approaches let collaboration proceed without data leaving the source institution. Models can be trained by distributing computation to data owners and aggregating only the results, an approach demonstrated across ten medical institutions [6].

### How does federated analysis change the clauses I need?

The permitted use clause should describe federated computation and restrict what leaves each site to model parameters or summary statistics. Security clauses focus on the computation environment and result disclosure rather than bulk transfer.

### Which repository should we name in the agreement?

Choose based on access model fit with your consent, identifier stability, metadata requirements, curation support, and sustainability. Name it explicitly, because repository choice and metadata quality determine whether the deposited dataset is actually findable and reusable [1].

### Do we still need an agreement if the data are de-identified?

Usually yes. De-identified data still carry confidentiality obligations, use restrictions, publication terms, and re-identification prohibitions. The DAA is the instrument that makes those obligations enforceable across institutions.

### Who owns data that are derived during the project?

Derived datasets and analysis outputs are typically governed by the intellectual property clause, which the consortium negotiates before signing. Common arrangements grant each contributing institution rights to its own contributions while defining joint terms for merged outputs, but the specific allocation is a negotiation, not a default.

## Sources

1. [Seek and you may (not) find: A multi-institutional analysis of where research data are shared](https://pubmed.ncbi.nlm.nih.gov/38662676/)
2. [Intra-consortium data sharing in multi-national, multi-institutional genomic studies: gaps and guidance.](https://pubmed.ncbi.nlm.nih.gov/20535402/)
3. [ENavigating the barriers to multi-regional research administrative data access: Forward thinking solutionsnada](https://doi.org/10.23889/ijpds.v9i5.2629)
4. [Navigating Legal and Ethical Requirements for Multi-Stakeholder Data Access Requests Through Harmonized Documentation](https://doi.org/10.23889/IJPDS.V3I4.746)
5. [Toward ethical provenance tracking: The GA4GH model data access agreement (DAA)](https://pubmed.ncbi.nlm.nih.gov/41046474/)
6. [Federated learning in medicine: facilitating multi-institutional collaborations without sharing patient data](https://pubmed.ncbi.nlm.nih.gov/32724046/)
7. [Decentralized collaborative multi-institutional PET attenuation and scatter correction using federated deep learning](https://pubmed.ncbi.nlm.nih.gov/36508026/)
8. [Federated learning: A new frontier in the exploration of multi-institutional medical imaging data](https://pubmed.ncbi.nlm.nih.gov/42190445/)
9. [Privacy-Enhanced Data Sharing in Multi-Institutional Healthcare](https://doi.org/10.1109/ICCCBDA61447.2024.10569224)
10. [Security and privacy requirements for a multi-institutional cancer research data grid: an interview-based study.](https://pubmed.ncbi.nlm.nih.gov/19527521/)
11. [Mobilizing data during a crisis: Building rapid evidence pipelines using multi-institutional real world data.](https://pubmed.ncbi.nlm.nih.gov/38531228/)
12. [CHLSOC: the Chilean Soil Organic Carbon database, a multi-institutional collaborative effort](https://doi.org/10.5194/essd-2019-161)
13. [Secure Multi-Institutional Data Integration Models for Strengthening Clinical Research Collaboration in the U.S. Health Sector](https://doi.org/10.63125/qqe4sh98)