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.
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 performs that step: it extracts candidate controls from the executed document, requires a named reviewer to confirm each one against its source clause, evaluates each proposed release against the confirmed controls, and freezes the decision, approvals, exceptions, and artifact hashes into an evidence pack.
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.