Data Use Agreement Template: A Worked Example, Clause by Clause

A Data Use Agreement (DUA) entry defines what the instrument is and when it is required — most commonly for HIPAA limited datasets under 45 CFR §164.514(e), for restricted-use data from federal statistical agencies, and for controlled-access datasets released through repositories such as dbGaP or the UK Data Service. What that definition cannot do is show you what a real DUA reads like clause by clause, or where the negotiable language actually sits. This guide fills that gap with two fully worked, clause-annotated examples.

These are illustrative composite examples, not real agreements. Both documents below describe fictional institutions, studies, and datasets invented specifically for this guide. No institution, investigator, IRB protocol, dbGaP study accession, or dataset referenced is real, and neither example should be copied into an actual agreement without your institution’s own legal/privacy office review — a DUA is a binding contract, and the specific language a counterparty’s counsel will accept varies by institution, data type, and jurisdiction. Their purpose is to show what specific, enforceable clause language looks like in contrast to the placeholder text a blank template invites, and to walk through the two most common DUA situations a research administrator encounters: a bilateral institution-to-institution agreement for identifiable health data, and a repository-mediated controlled-access certification.

What every DUA needs to contain, regardless of format

Before the worked examples, it helps to fix the checklist a DUA is built from. Regardless of whether the counterparty is another university, a federal statistical agency, or a repository’s data access committee, a defensible DUA answers the same core questions:

• Who is bound? A DUA is signed by an institutionally authorised official (a Signing Official, sponsored-programs officer, or equivalent) on each side, and binds the recipient institution as a legal entity — not the individual researcher personally, even though the researcher is typically named as the responsible investigator.
• What is the permitted purpose? A specific, bounded research purpose, not “research use” generally. Use outside the stated purpose is a breach even if the recipient institution still controls the data securely.
• Who are the authorised users? A named list (or a defined process for adding personnel) — not “the recipient’s research team” left undefined.
• What re-identification and re-disclosure restrictions apply? A DUA for de-identified or limited data almost always prohibits attempting to re-identify individuals and prohibits onward transfer to any third party not named in the agreement.
• What security and access controls are required? Encryption at rest/in transit, access logging, and physical or network isolation appropriate to the data’s sensitivity.
• What happens at the end of the study? A defined data destruction or return obligation, usually with a certification of destruction required from the recipient.
• What is the term, and how is breach handled? An effective date, expiration or renewal mechanism, and the consequences (typically immediate termination of access plus a reporting obligation) if a term is violated.

A weak DUA answers each of these with vague language — “data will be used appropriately,” “access will be limited to necessary personnel” — that satisfies the letter of a template prompt while giving neither side’s counsel anything concrete to enforce. The worked examples below show the same checklist answered with specific, auditable language instead.

Worked example 1: a bilateral DUA for a HIPAA limited dataset

This is the most common DUA scenario for a US-based research administrator: your institution wants to receive a limited dataset (identifiable dates and geographic detail retained, but direct identifiers like name, address, and medical record number removed) from another covered entity, under 45 CFR §164.514(e). HIPAA makes the DUA itself mandatory in this scenario — a limited dataset cannot be disclosed for research without one.

Fictional scenario: Northfield University Medical Center (discloser) is providing a limited dataset of emergency-department visit records to Alden State University (recipient) for a study of regional respiratory-illness patterns.

1. Recitals and defined terms

“This Data Use Agreement (‘Agreement’) is entered into by Northfield University Medical Center (‘Discloser’) and Alden State University (‘Recipient’) to govern Recipient’s use of a Limited Data Set, as that term is defined at 45 CFR §164.514(e)(2), disclosed by Discloser for the Research Project described in Exhibit A.”

Why it matters: naming the specific regulatory definition (§164.514(e)(2)) rather than writing “de-identified data” is deliberate — a limited dataset is a distinct, narrower category than a fully de-identified dataset, and still retains some indirect identifiers. Conflating the two is a common drafting error that understates the compliance obligation.

2. Permitted purpose (Exhibit A)

“Recipient shall use the Limited Data Set solely for the purpose described in Exhibit A: ‘Characterizing seasonal and geographic patterns of emergency-department respiratory-illness presentations across the study region, 2023-2025, under IRB Protocol #[fictional] approved by Alden State University’s Institutional Review Board.’ No use of the Limited Data Set outside this stated purpose is permitted without Discloser’s prior written consent and an amended Exhibit A.”

Why it matters: tying the purpose to a specific, dated IRB protocol — rather than “public health research” broadly — is what makes the clause enforceable. A recipient who later wants to reuse the same dataset for an unrelated secondary analysis needs a new agreement, not an assumption that the original DUA covers it.

3. Authorised users and no re-disclosure

“Recipient shall limit access to the Limited Data Set to the individuals listed in Exhibit B (‘Authorised Users’), each of whom has completed HIPAA research-privacy training within the preceding 12 months. Recipient shall not disclose the Limited Data Set, in whole or in part, to any person or entity not listed in Exhibit B, and shall not sell, lease, or otherwise transfer the Limited Data Set to any third party.”

4. No re-identification

“Recipient shall not use the Limited Data Set, alone or in combination with any other information, to identify or contact any individual who is the subject of the data, and shall not attempt to determine the identity of any such individual.”

5. Security safeguards

“Recipient shall store the Limited Data Set on an encrypted, access-logged institutional server; shall not store the Limited Data Set on portable media, personal devices, or non-institutional cloud storage; and shall restrict network access to Authorised Users via role-based permissions.”

6. Data destruction or return

“Upon completion of the Research Project or termination of this Agreement, whichever occurs first, Recipient shall destroy the Limited Data Set (including all copies and derivative extracts containing the Limited Data Set) within 30 days and shall provide Discloser with written certification of destruction signed by the responsible investigator.”

7. Breach notification and term

“Recipient shall notify Discloser in writing within five (5) business days of discovering any use or disclosure of the Limited Data Set not permitted by this Agreement. This Agreement is effective as of the date of last signature and terminates on [fixed date], subject to renewal by written amendment.”

Worked example 2: a controlled-access data use certification (dbGaP-style)

The second common scenario is not a bilateral negotiation at all — it is a standardised certification process run by a repository’s Data Access Committee (DAC), most visibly the NIH/NCBI’s dbGaP repository for controlled-access genomic and phenotype data. Here the “template” is fixed by the repository, and the researcher’s job is to complete it accurately rather than negotiate its terms.

Fictional scenario: Dr. Priya Andal, a genetics researcher at Meridian State University, requests controlled-access data from a fictional dbGaP study (accession phs999999, invented for this example) to investigate a candidate gene association.

How the process actually runs

1. Project Request. The PI, logged into the dbGaP Authorized Access System via an eRA Commons account, submits a Project Request specifying the requested study/dataset, the research use statement, and the personnel who will access the data.
2. Data Use Certification (DUC) Agreement. The PI electronically agrees to the DUC Agreement and the Genomic Data User Code of Conduct — the standardized terms that substitute for a negotiated bilateral contract. These commit the requesting team to using the data only for the stated research use, not attempting re-identification, and reporting any data security incident.
3. Institutional co-signature. The requesting institution’s eRA Commons Signing Official co-signs the request before it reaches NIH review — the same institutional-accountability structure as a bilateral DUA, just executed through a portal rather than a wet-signature contract.
4. DAC review. The specific study’s Data Access Committee — dbGaP has many DACs, not one central body — reviews the request against the data-use limitations set by the original study participants’ informed consent (for example, “health/medical/biomedical research use only,” which is more restrictive than “general research use”).
5. Approval and access period. Approval grants “Approved User” status for a defined data access period (commonly one year), renewed via an annual Project Renewal with a progress update, or formally closed out. An account that submits neither within 42 days of expiration is suspended.

What this worked example shows that the bilateral one doesn’t: when a DUA is repository-mediated rather than bilaterally negotiated, the researcher’s actual leverage is in writing a precise, honest research-use statement that fits within the original participants’ consent limitations — not in redlining contract clauses. A research-use statement written too broadly is the single most common reason a DAC sends a request back for revision.

Common weaknesses a reviewer or counterparty will flag

• Undefined “appropriate” security. “Recipient will maintain appropriate security” gives a privacy office nothing to audit against. Name the actual control: encryption standard, access logging, network isolation.
• Open-ended authorised-user language. “The research team” is not a defined set of people. List names, or define a documented process for adding them, in an exhibit that can be updated without re-executing the whole agreement.
• No destruction deadline. “Data will be destroyed when no longer needed” has no enforcement date. Use a fixed number of days from project completion or agreement termination, and require written certification.
• Purpose creep. A DUA purpose statement broad enough to cover future, unspecified secondary analyses is a red flag to a discloser’s counsel and, in the dbGaP case, to a Data Access Committee checking the request against participant consent.

How a DUA differs from adjacent agreements

A DUA is easy to confuse with three related instruments that CASRAI covers in more depth elsewhere:

• A Data Sharing Agreement (DSA) is the broader bilateral instrument for institution-to-institution data exchange generally — a DUA is often the specific sub-type used when the shared data is a HIPAA limited dataset or otherwise carries re-identification risk. See Data Sharing Agreements Between Collaborators and Institutions for the DSA-level view, and DSA vs. DPA for how a DSA differs from a GDPR-style processing agreement.
• A Material Transfer Agreement (MTA) governs physical or biological materials, not data — a study exchanging both tissue samples and the associated clinical data typically needs an MTA and a DUA as companion documents, not one instrument covering both.
• De-identification is a technical/statistical property of a dataset (via HIPAA Safe Harbor or Expert Determination); a DUA is the contractual instrument. Fully de-identified data under Safe Harbor generally does not require a DUA to disclose, which is exactly why the limited-dataset category — retaining some identifiers but requiring a DUA — sits in between fully identifiable and fully de-identified data.

Frequently asked questions

Is a Data Use Agreement legally binding?

Yes. A DUA is a signed contract between institutions, enforceable under the same contract-law principles as any other institutional agreement, with the added regulatory backing of HIPAA (for limited datasets) or a funder’s data access policy (for repository-mediated agreements like dbGaP’s DUC).

Who actually signs a DUA — the PI or the institution?

An institutionally authorised official signs on behalf of the recipient institution (a Signing Official, sponsored-programs office representative, or equivalent), because the institution — not the individual investigator — is the party legally bound by the agreement’s obligations. The PI is typically named as the responsible investigator and, in repository-mediated processes like dbGaP, submits the request that the Signing Official then co-signs.

Do I need a DUA for fully de-identified data?

Generally no, if the data meets HIPAA’s Safe Harbor or Expert Determination standard for full de-identification. A DUA becomes necessary specifically because a limited dataset retains some indirect identifiers (dates, geographic detail) that Safe Harbor would otherwise require removed — see De-identification for the distinction.

How long does DUA negotiation typically take?

For a bilateral institution-to-institution DUA, several weeks to a few months is common, since it usually routes through both institutions’ legal or privacy offices in addition to sponsored programs. Repository-mediated certifications like dbGaP’s DUC process are typically faster once a research-use statement is well-drafted, since there is no bilateral redlining — the main variable is Data Access Committee review time.

Can one DUA cover multiple studies or datasets?

Only if the agreement is drafted that way explicitly, with each covered use listed in an exhibit. The default, and the safer practice, is one DUA per defined research purpose — reusing an existing DUA for a new, unrelated analysis is a common source of purpose-creep findings in an audit.