Data use agreements are signed at the beginning of a research project, when the focus is on getting access to the data. The permitted purpose is drafted to describe the study as proposed, the security commitments are reviewed by an information security team, and the agreement is filed once the data transfer completes. From that point forward almost nobody involved in the research reads it again.
The obligations it creates then run for years. Most of them are passive, in the sense that compliance consists of not doing things, and passive obligations are the ones organisations are worst at monitoring. There is no deliverable to chase and no date to diarise, so they generate no activity until something goes wrong. Nobody notices a permitted purpose being exceeded, because the act of exceeding it looks exactly like ordinary research being done well.
The active obligations are worse served still. A retention period ends, a destruction certificate is owed by a date, and the research team that would have to produce it has dispersed to other institutions. This is the familiar pattern of an instrument whose inventory is the real problem, which is the same conclusion reached about business associate agreement tracking: the drafting is usually fine and nobody can find the population.
The five obligations and where each fails
A standard research data use agreement creates five duties. Each has a characteristic failure mode that follows directly from how research is actually conducted rather than from carelessness.
- Permitted purpose limitation, exceeded when a dataset is reused for an adjacent question without an amendment or a new agreement.
- Recipient restriction, breached quietly as new team members gain access to a shared analysis environment without being added to the approved list.
- Re-identification prohibition, strained when a dataset is linked to another source, which can be re-identifying in effect if not in intent.
- Retention limit, unenforceable in practice because the event that starts the clock, usually study completion, was never recorded anywhere.
- Destruction or return with certification, missed because the obligation matures long after the project team has moved on.
Linkage deserves particular care. A limited data set is constructed on the assumption that it cannot reasonably identify individuals on its own. Combining it with another dataset changes that calculus, and the combination is often the entire scientific point of the second study. Most agreements prohibit linkage without approval, and most researchers do not think of a linkage as a re-identification attempt, because from their perspective it is not one. The gap is conceptual rather than deliberate, which is exactly why a contractual control works better here than a training module.
Almost every downstream obligation in a data use agreement runs from study completion, and almost no organisation records that date. Make it a deliberate step with an owner, and the retention clock, the destruction deadline and the reporting duties all become calculable instead of theoretical.
What belongs on the agreement record
Five fields turn a filed document into something the research compliance function can monitor without reading every agreement each quarter. None of them is difficult to capture at signature, and all of them are expensive to reconstruct two years later from a document and a departed investigator.
- Permitted purpose summary. A short plain statement of what the data may be used for, readable by a researcher who will not open the agreement.
- Approved recipient list. Current names with the date each was added, plus whether provider approval is needed before additions.
- Linkage and re-identification terms. Whether linkage is prohibited outright or permitted with approval, and who grants it.
- Retention trigger and period. The event starting the clock, the duration, and the resulting end date once the trigger is recorded.
- Destruction deliverable. The certificate owed, its due date, its recipient and the scope it must cover including backups.
A five-step implementation roadmap
Step 1, Build the inventory
Find every active data use agreement across the institution. They are executed by research administration, by individual departments and occasionally by principal investigators directly, so a single repository rarely holds them all and the first pass is a search rather than a query.
Step 2, Abstract the five fields
Capture the permitted purpose, recipients, linkage terms, retention trigger and destruction deliverable for each agreement. Where the retention trigger is study completion and no completion date exists, flag it for the principal investigator to confirm while they are still contactable.
Step 3, Give recipient lists an owner
Assign responsibility for maintaining each list to someone on the study team, and review annually against the actual access list for the analysis environment. The two diverge faster than anyone expects, and the divergence is itself the breach.
Step 4, Publish the purpose in plain language
Attach a short readable statement of permitted use to the dataset itself, wherever researchers encounter it. The constraint has to be visible at the point of use, because that is where the decision to run an additional analysis is actually taken.
Step 5, Schedule destruction well in advance
Create the destruction obligation with a lead time long enough to locate copies in backups, collaborator environments and archived analysis workspaces. A certificate signed without that search is a statement nobody has verified and should not be offered to a data provider.
Keep data duties visible after close
Purpose limits, recipient lists, retention clocks and destruction certificates on one record.
Why the inventory is the hard part
Organisations that have examined this closely usually find more agreements than expected, held by more parties than expected, and with retention periods that expired some time ago. That is uncomfortable, and the instinct to stop looking is understandable. It is also the single most valuable output of the exercise, because an expired retention period with data still held is the finding a data provider is most likely to raise and the one hardest to explain after the fact. Building the inventory first, then the field set, then the monitoring, is the sequence that works, and it mirrors the approach that makes business associate agreement obligations manageable across a large vendor base.
Obligations, triggers and evidence
The table summarises the duty set with the evidence that closes each one. Specific terms vary by agreement and by the data provider's own policies, so the governing document should always be read before relying on a summary.
| Obligation | Duration | Typical failure | Closing evidence |
|---|---|---|---|
| Permitted purpose limitation | Life of the dataset | Reuse for an adjacent study | Amendment or new agreement on file |
| Approved recipients only | Life of the dataset | Team turnover without list update | Annual list reconciliation |
| No re-identification or linkage | Life of the dataset | Linkage treated as ordinary method | Approval record for each linkage |
| Retention limit | From recorded trigger | Trigger date never captured | Recorded completion with end date |
| Destruction and certification | At retention end | Team dispersed before the deadline | Signed certificate with scope stated |
Research data access depends on data providers trusting that their terms are honoured after the transfer. That trust is rebuilt at every new request, and the organisations that can produce a destruction certificate promptly when one is due tend to find the next dataset easier to obtain than those that cannot. The administrative work is modest; what it buys is continued access, and in a competitive funding environment the reputation of being an institution that handles other people's data properly is worth considerably more than the hours involved.
For related guidance, see Provider contract management for health systems, Value-based care contract administration, simplified and Staffing agency contract control for health systems.
