The 12 clauses and what each one must name
Most published data sharing agreement templates are complete as documents and unusable as controls, because the operative values are left as prose. Use this table while drafting or reviewing. The middle column is the value a release reviewer will have to compare a request against, and the right column is the check that value makes possible.
| Clause | The value it must state | Release check it produces |
|---|---|---|
| 1. Parties and authority | Legal names of the disclosing and receiving organizations, signatories, the agreement owner on each side, and the statute, policy, or protocol the sharing rests on | Is this request under the agreement that actually covers these two parties |
| 2. Term and amendment | Effective date, expiration date, renewal mechanism, amendment process, and order of precedence among the body, exhibits, and any prior agreement | Is the governing version current on the proposed release date |
| 3. Permitted purpose | The approved purpose in specific language, plus any purposes expressly prohibited | Does the stated request purpose match the permitted purpose |
| 4. Recipients and authorized users | Named recipient entity, eligible user roles or a named user list, collaborators, subcontractors and processors, and the process to add or remove a user | Is every user on this release inside the authorized set |
| 5. Data scope | Field list or data dictionary reference, population or cohort definition, time period covered, source systems, and refresh cadence | Does the proposed schema contain a field outside the allowlist |
| 6. Derived data and linkage | Whether linkage to other datasets is permitted, which datasets, and who owns derived data and aggregate outputs | Is a linkage or derived output proposed that the agreement does not permit |
| 7. Environment and location | Named approved environment or platform, permitted geographies, and whether local copies or exports are allowed | Is the proposed environment the approved one |
| 8. Transfer and security | Transfer method, encryption in transit and at rest, authentication, logging, and the assurance standard the recipient must meet | Does the proposed transfer method match the permitted one |
| 9. Retention and destruction | Access end date, maximum retention period, destruction or return obligation, treatment of backups and derived copies, and the evidence of destruction required | Has the access end date passed, and is retention within the maximum |
| 10. Publication and redisclosure | Whether results may be published, any review or notice period, attribution, and whether onward disclosure to a third party is permitted | Does the stated publication or redisclosure intent exceed the permitted scope |
| 11. Incident and non-compliance | Notification window in days, the named contact, recipient duties on suspected misuse, and the disclosing party cure and termination rights | Is an open incident blocking further release under this agreement |
| 12. Audit and records | Audit rights, the records the recipient must keep, the retention period for those records, and the reporting cadence | Can the disclosing party evidence what was released and to whom |
Five fields most templates leave vague, and what to write instead
These are the places where a signed agreement most often turns out to be unenforceable in practice. Each has a common default that cannot be checked, and a checkable alternative.
- Purpose: "research purposes" is not checkable. Write the project title, the protocol or grant number, and the specific analysis.
- Users: "employees of the Recipient with a need to know" is not checkable. Reference a named user list held as an exhibit, with a stated update process.
- Data: "the Data described in Exhibit A" is checkable only if Exhibit A is a field list. Attach the data dictionary or schema, not a narrative description.
- Environment: "a secure environment" is not checkable. Name the platform, the account or tenant, and the region.
- Retention: "for the duration of the project" is not checkable. State a date, or a fixed period running from a named event, and state what evidence of destruction is required.
Where to start from a real base document
Model agreements are maintained by institutions with counsel behind them. Georgetown Law's Institute for Technology Law and Policy publishes model data sharing agreements, and the UK Information Commissioner's Office data sharing code of practice sets out the content a sharing agreement is expected to cover. Many universities and public agencies publish their own executed templates, which are useful precisely because they have survived a real negotiation.
If the data is protected health information under HIPAA, the required terms are set by regulation rather than by preference. See the annotated data use agreement sample for the five recipient undertakings required at 45 CFR 164.514(e)(4), and the limited data set identifier reference for what such a dataset may still contain.
Filled example: the release schedule attached to an agreement
The following values are fictional and illustrate an operational attachment for review, not a ready-to-sign contract or a statement of legal sufficiency. They show how the clause table becomes a checkable request. Counsel and the responsible data owner must determine the applicable lawful basis, rights, jurisdiction and required terms for the real arrangement.
| Field | Fictional schedule value | Check before release |
|---|---|---|
| Parties and version | Example University and Example Research Institute; DSA-EXAMPLE version 2 | Both named parties and this governing version match the request |
| Purpose | Project EXAMPLE-17: study service waiting times | The proposed analysis stays within the approved project scope |
| Data | Exhibit A version 3: study code, service month and waiting-time band | Compare the actual schema and payload; a free-text notes column needs separate review |
| Users and environment | Two named researchers in the approved institutional workspace | Check the current user list and the actual destination |
| Term and retention | Access ends 30 June 2027; approved retention schedule attached | Check the release date and the approved treatment of copies and backups |
| Changes | New field, recipient or purpose goes to the named agreement owner | Hold an out-of-scope request for authorized review; do not silently widen the schedule |
Review the proposed extract, not just the completed template
Suppose the request above adds an email-address field. The agreement may still be correctly signed, but the release no longer matches the attached field list. Record the added field, the relevant exhibit version and the review owner before anything is transferred. The appropriate outcome depends on the governing terms and authorized decision; the template itself does not grant an exception.
Repeat the same check when the destination, project purpose, authorized users or dates change. Keep the requested value, the permitted value, the source reference, the finding and the final approval or hold in the same review record. This provides a useful handoff even when the review is performed manually and the planned Audarel service is unavailable.
After execution: turning the template into controls
A signed agreement changes nothing operationally until each clause value is recorded as a structured control with a citation back to the clause. A field list becomes an allowlist. A cohort definition becomes a row predicate. An access end date becomes an expiry check. A named environment becomes an equality check against the request.
Audarel is in development. Its planned workflow proposes candidate controls from the executed document, asks a named reviewer to confirm each against its source clause, and connects release checks, decisions and evidence. The schedule and manual checks above can be used without signing up or waiting for that product.
Keep decisions human and evidence explicit.
Practical guidance that connects policy documents to observable release controls.
Confirm requirements against current source material.
Requirements and vendor capabilities change. Confirm the current source and your approved QC plan before changing a production process.