CASRAI Dictionary

Tag: data sharing agreement

  • What Is a Data Trust? Research Data Governance

    A data trust is a legal and technical framework in which an independent trustee, bound by fiduciary duty, makes decisions about a pool of data on behalf of the people or organisations who contributed it. For research data, this offers a genuine alternative to depositing datasets individually in a repository: instead of each contributor negotiating access terms alone, a trustee stewards shared data collectively, with accountability built into the governance structure itself.

    A data trust can be defined precisely: it is an independent steward, holding data under a formal duty of impartiality, prudence, transparency and undivided loyalty to the beneficiaries whose data it manages, according to the Open Data Institute (ODI), which coined and refined the term from 2018.

    What is a data trust?

    A data trust is a legal structure in which one party authorises an independent trustee to make decisions about data on their behalf, for the benefit of a defined group of stakeholders. The ODI, which published its first explainer on the concept in July 2018 and adopted a working definition later that year, models the idea on established asset trusts such as land trusts, transposing the same fiduciary logic onto data.

    The clearest working example is UK Biobank, established in 2006 as a charitable company with trustees to steward genetic data and biological samples from around 500,000 participants. The ODI itself trialled the concept in practice with the UK Government’s Office for AI in April 2019, testing whether fiduciary stewardship could work as applied governance rather than theory alone. Separately, the University of Cambridge’s Data Trusts Initiative has examined data trusts as a mechanism for pooling individuals’ legal data rights into a single negotiating and stewardship entity.

    How does a data trust govern research data differently from repository deposit?

    Under the standard deposit model, a researcher or institution submits a dataset to a repository, which applies institutional policy and a licence to govern reuse — the repository itself owes no fiduciary duty to depositors. Under a data trust, an independent trustee holds ongoing decision-making authority over the pooled data and is legally obliged to act in the beneficiaries’ interests, not merely to apply a static licence at the point of deposit.

    This distinction matters most for sensitive, re-identifiable, or commercially valuable research data, where a one-off licence cannot anticipate every future access request. A trust structure allows collective, ongoing renegotiation of terms as new uses arise, rather than requiring each depositor to individually vet every downstream request.

    Feature Data trust Repository deposit
    Legal basis Formal trust or fiduciary agreement Institutional policy plus a data licence
    Decision-maker Independent trustee(s) with ongoing authority Depositor sets terms once, at submission
    Fiduciary duty Yes — legally binding to beneficiaries No — repository is a custodian, not a fiduciary
    Best suited to Sensitive, re-identifiable, or contested data Open, low-risk, citation-ready datasets

    Data sharing agreement vs data processing agreement: where does a data trust fit?

    A data sharing agreement sets out the terms under which two or more parties exchange data they each control, while a data processing agreement — required under UK GDPR Article 28 wherever a processor handles data on a controller’s behalf — fixes the narrower, instructed relationship between a data controller and a processor acting only on its instructions.

    A data trust does not replace either instrument; it changes who holds the authority to agree them. Rather than each institution separately negotiating a data sharing agreement for every new research collaboration, the trustee negotiates and monitors compliance centrally, on behalf of all contributors, reducing duplicated legal effort across a research consortium.

    What does a data trust mean for FAIR data stewardship?

    The FAIR Principles — Findable, Accessible, Interoperable, Reusable, formalised by Wilkinson and colleagues in Scientific Data in 2016 — govern how research data should be described and made available, but they do not specify who decides access terms. A data trust supplies exactly that missing governance layer.

    • Findability and interoperability metadata can still be maintained in a conventional repository even where the trust governs access rights.
    • Accessibility becomes a trustee decision rather than a fixed licence, allowing tiered or conditional access for sensitive datasets that would otherwise be withheld entirely.
    • Reusability is strengthened where beneficiaries trust the stewardship arrangement enough to contribute richer, less redacted data in the first place.

    Institutions bound by research data management policy obligations — including UKRI’s Common Principles on Data Policy — can treat a data trust as a compliance mechanism that satisfies funder access requirements without forcing full open deposit of sensitive material.

    Indigenous data sovereignty and the CARE Principles

    The Global Indigenous Data Alliance published the CARE Principles — Collective Benefit, Authority to Control, Responsibility, and Ethics — in 2019, explicitly to complement FAIR by centring people and purpose rather than data alone. CARE was developed in direct response to concerns that FAIR-only stewardship could enable extraction of Indigenous data without consent or benefit-sharing.

    A data trust structure is one of the few governance mechanisms that can operationalise CARE’s “Authority to Control” principle in practice: it gives a defined community, rather than a repository operator, the standing to appoint trustees and set binding terms. This is a genuinely distinct information-gain point rarely covered in generic data-trust explainers, most of which address corporate or civic data rather than research data sovereignty.

    Answer-first Q&A

    What is a data trust?

    A data trust is a legal and technical structure that manages data on behalf of contributors through an independent trustee. The trustee holds a fiduciary duty — impartiality, prudence, transparency, and undivided loyalty — to the people or organisations whose data is pooled, rather than to any single commercial interest.

    What is the data trust structure?

    The structure places data under the control of a board of trustees who owe a fiduciary responsibility to the beneficiaries. Terms of access, use, and onward sharing are set collectively and can be renegotiated over time, unlike a fixed licence attached to a single dataset at deposit.

    What is a public data trust?

    A public data trust is governed by community, government, or non-profit board members committed to widening access to data affecting a defined population. In a research setting, this model supports population studies, public-health cohorts, and civic datasets where public benefit and consent are central governance concerns.

    What is the role of a data trustee?

    A data trustee manages, protects, and ensures the integrity and appropriate use of pooled data. Trustees identify sensitivity and risk, approve or decline access requests, and enforce the trust’s terms — a standing, ongoing role rather than a one-time licensing decision made at the point of deposit.

    Implications and outlook for research administrators

    For research administrators, the practical implication is that data trusts are not a substitute for repository infrastructure — findability, persistent identifiers, and metadata still depend on conventional deposit systems. What a trust adds is a governance layer above the infrastructure, suited to consortium data, population cohorts, and datasets involving Indigenous or otherwise sovereignty-sensitive communities.

    Institutions weighing a data trust model should expect higher upfront legal cost than a standard repository licence, offset against lower recurring negotiation cost across a multi-year, multi-partner project. As FAIR-compliant infrastructure matures and CARE-aligned governance expectations grow, data trusts are likely to remain a minority but increasingly cited option for exactly the categories of research data — sensitive, collectively owned, or community-governed — that pure open deposit handles least well.

  • Indigenous Data Sovereignty: Why FAIR Needs CARE

    Indigenous data sovereignty is the right of Indigenous peoples and nations to govern the collection, ownership, interpretation, and application of data about their own communities, lands, and knowledge. Blanket “open by default” research-data mandates built on the FAIR Data Principles can override that right when they treat findability and accessibility as unconditional. The fix is not to abandon FAIR, but to add a CARE-informed consent layer — tiered access controls, negotiated data-sharing agreements, and governance authority held by the originating community — that sits inside FAIR’s own accessibility principle rather than outside it.

    As funders push open-data compliance deeper into grant conditions, research offices increasingly reconcile a mandate to publish with a community’s right to say no, say later, or say “only under these conditions.”

    What is indigenous data sovereignty?

    Indigenous data sovereignty describes the inherent right of Indigenous peoples to govern data about their own communities, resources, and lands — a right that derives from tribal and national self-determination rather than from any single data-protection statute. The Global Indigenous Data Alliance (GIDA) traces the movement’s institutional roots to country-specific networks: the Aotearoa New Zealand-based Te Mana Raraunga (Māori Data Sovereignty Network, formed 2015), Australia’s Maiam nayri Wingara Aboriginal and Torres Strait Islander Data Sovereignty Collective (2017), Canada’s First Nations Information Governance Centre, and the US Indigenous Data Sovereignty Network.

    These networks converged on a shared position: data collected about Indigenous peoples should remain subject to the governance of the nation or community it describes — including tribal law — not solely the policies of the funder, institution, or repository that hosts it. This is a governance claim, not merely a privacy preference, and it applies whether the data in question is health records, environmental monitoring, ceremonial knowledge, or genomic samples.

    How do CARE principles relate to FAIR data principles?

    The CARE Principles for Indigenous Data Governance — Collective Benefit, Authority to Control, Responsibility, and Ethics — were developed specifically to sit alongside the FAIR Data Principles (Findable, Accessible, Interoperable, Reusable), not to replace them. The Research Data Alliance’s International Indigenous Data Sovereignty Interest Group formalised CARE in 2019 to address what FAIR, on its own, does not: who benefits, who decides, and under what ethical obligations data circulates.

    Principle set Primary question it answers Governing focus
    FAIR (Findable, Accessible, Interoperable, Reusable) How usable is the data, technically? Data as an object
    CARE (Collective Benefit, Authority to Control, Responsibility, Ethics) Who benefits, and who decides? Data as a relationship

    Framing these as rivals misreads FAIR’s own text. FAIR principle A1.2 explicitly states that the accessibility protocol must “allow for an authentication and authorisation procedure, where necessary” — meaning FAIR was never a synonym for unconditional open access. Data can be fully findable, with rich metadata, a persistent identifier, and a documented access route, while the underlying content sits behind a governed permission gate. That gap between “discoverable” and “downloadable” is precisely where a CARE-informed consent layer belongs.

    Do open data mandates override indigenous data sovereignty?

    Open data mandates do not automatically override Indigenous data sovereignty, but poorly designed ones can function that way in practice. Funder policies such as UKRI’s research data policy and cOAlition S’s Plan S commitments require data to be made available with “as open as possible, as restricted as necessary” language — a formulation that already anticipates legitimate restriction, yet is frequently implemented by institutions as a default push toward maximal openness.

    PLOS’s own editorial position, published in its EveryONE blog in October 2023, states plainly that Indigenous Data Sovereignty is the right of Indigenous peoples to own and govern data about their communities, resources, and lands — and that open-access publishing policies must accommodate, not override, that right through mechanisms such as data-access statements that explain restrictions rather than force disclosure. The Australian Institute of Aboriginal and Torres Strait Islander Studies (AIATSIS) Code of Ethics for Aboriginal and Torres Strait Islander Research similarly requires researcher agreements on data ownership, access, and storage to be negotiated with communities before collection begins, not retrofitted at publication.

    • Where mandates and sovereignty align: both frameworks require documented data-management plans, clear provenance, and persistent identifiers.
    • Where friction emerges: “open by default” clauses that treat non-disclosure as an exception requiring justification, rather than a governance decision requiring respect.
    • The resolvable middle: metadata and access statements can be fully open even when the underlying dataset is access-controlled.

    A consent layer is a set of governance and technical controls — inserted between data creation and data reuse — that lets a community set the terms under which its data is discovered, accessed, and re-used, without removing that data from the research record entirely. In practice this combines four elements research administrators already have tools for:

    1. Tiered metadata: a public, FAIR-compliant record (title, abstract, provenance, persistent identifier via DataCite or Crossref) that is fully findable even when the dataset itself is restricted.
    2. Governance-holder sign-off: a named Indigenous governance body (tribal council, iwi authority, data sovereignty collective) with authority to approve, condition, or decline each reuse request — not a one-time blanket consent captured at initial collection.
    3. A trusted research environment (TRE): a controlled-access computing environment where approved researchers can analyse restricted data without exporting raw records, satisfying reusability without unconditional distribution.
    4. Biocultural or Traditional Knowledge labels: machine-readable metadata tags (the Local Contexts initiative’s TK and BC Labels) that travel with a dataset to signal provenance, cultural protocols, and permitted uses wherever it is indexed or mirrored.

    None of these four elements block findability. They condition access — which is exactly what FAIR’s accessible principle already permits.

    Data sharing agreement vs data processing agreement — which applies?

    A data sharing agreement (DSA) and a data processing agreement (DPA) serve different legal functions, and conflating them is a common source of failure in Indigenous data governance. A DSA governs the transfer of data between two parties who each have independent authority over how it is subsequently used — the correct instrument for Indigenous data sovereignty, because it lets the originating community retain and exercise ongoing authority to control, per CARE’s second principle.

    A DPA, by contrast, is used when one party (a processor) handles data strictly on behalf of another (the controller) with no independent decision-making rights — the model built into contract templates under UK GDPR. Using a DPA where a DSA is required strips the originating community of ongoing authority.

    Instrument Who holds decision authority Fit for Indigenous data sovereignty
    Data Sharing Agreement (DSA) Both parties, independently Appropriate — preserves community authority to control
    Data Processing Agreement (DPA) Controller only; processor has none Inappropriate as a standalone instrument — reduces community to data subject

    Implications for research administrators

    Research data management (RDM) policy templates written purely around funder compliance checklists will systematically under-serve Indigenous data governance unless they build in a consent layer as a standard clause, not an exception process. Institutions should require, at the data-management-plan stage, an explicit question: does this dataset describe an Indigenous community, and if so, has a governance body with authority to control been identified and consulted before collection?

    Research data repositories that host Indigenous-derived datasets should support tiered access controls and TK/BC Label metadata natively, rather than treating restricted-access as a bespoke workaround bolted onto an open-by-default platform. Institutions building or procuring a trusted research environment for sensitive data should evaluate whether it can enforce community-set reuse conditions per dataset, not merely per project.

    Conclusion: consent is compatible with findability

    Indigenous data sovereignty and the FAIR Data Principles are not opposed frameworks competing for the same ground — FAIR governs how data is described and discovered, while CARE and a CARE-informed consent layer govern who decides what happens next. A research data management policy that hard-codes this distinction, uses the right agreement type for the right relationship, and gives Indigenous governance bodies a standing role rather than a one-off consultation, satisfies funder open-data requirements and Indigenous data sovereignty at the same time. The two are compatible by design; the mandates just need to stop assuming otherwise.

  • Data Transfer Agreement vs MTA and CTA Explained

    A data transfer agreement (DTA) is the legal instrument that makes a specific movement of clinical trial data — to a third-party analyst, a data repository or a partner institution — lawful, bounded and auditable. It is not the same instrument as a material transfer agreement (MTA), which covers physical specimens, or a clinical trial agreement (CTA), which governs the whole trial relationship between sponsor and site. Research administrators who conflate the three risk leaving a data movement with no defined retention period, no cross-border transfer mechanism and no liability clause.

    A data transfer agreement is a standalone contract, separate from the CTA and the MTA, that fixes the permitted use, security safeguards, retention limits and legal transfer mechanism for a defined dataset moving from a data controller to a recipient. This article sets out what a clinical trial DTA covers that the other two instruments do not, and what clauses a compliant version must contain.

    What is a data transfer agreement in a clinical trial?

    A data transfer agreement is triggered whenever clinical trial data — identifiable, coded or fully anonymised — moves to a party not already bound by the trial’s main contracts: a central statistics unit, an academic secondary-use researcher, a data repository, or a partner sponsor in a licensing deal. The CTA the site signed with the original sponsor does not automatically extend data-handling obligations to that new recipient; the DTA is what does.

    Unlike a CTA, a DTA is narrow by design. It does not govern how the trial is run, who is paid what, or how adverse events are reported. It governs one thing only: the terms under which a defined dataset can be received, used, stored and eventually destroyed or returned.

    DTA vs MTA: data versus physical materials

    The distinction between a DTA and an MTA is the distinction between data and matter. A material transfer agreement governs blood, tissue, biopsies, cell lines or investigational compounds moving between institutions — tangible items that can be depleted, contaminated or physically lost. A DTA governs the dataset, not the specimen it may have been derived from.

    The two frequently travel together. A central laboratory sending biopsy slides to a specialist pathology reader needs an MTA for the slides and, if genomic or clinical annotation data accompanies them, a separate DTA for that dataset. Trying to cover data terms inside an MTA’s materials clauses is one of the most common gaps flagged in institutional research-contracting reviews.

    Instrument What moves Core legal basis Typical parties What it governs
    Data Transfer Agreement (DTA) Data — identifiable, coded or anonymised UK GDPR/EU GDPR Chapter V transfer mechanisms; HIPAA Data Use Agreement (US) Data controller/holder and a data recipient outside the original trial team Permitted use, retention, security, cross-border transfer mechanism
    Material Transfer Agreement (MTA) Physical specimens or compounds Institutional IP and biobanking policy Material provider and recipient institution or laboratory Ownership, permitted use, derivatives, liability
    Clinical Trial Agreement (CTA) The whole trial relationship ICH-GCP E6(R2); EU Clinical Trials Regulation 536/2014 Sponsor and investigator/site institution Protocol conduct, funding, indemnity, publication rights

    DTA vs CTA: a narrow instrument inside a broader contract

    A clinical trial agreement is the master contract between sponsor and site: it fixes protocol adherence, payment schedules, indemnification and publication rights for the entire study. Some CTAs include a data-ownership clause stating who holds the master dataset — but that clause states an outcome, not a transfer mechanism. It does not specify the cross-border legal basis, security controls, or destruction deadline that apply once data actually moves to a third party.

    This gap is exactly where a DTA sits. When a sponsor later licenses anonymised trial data to a third-party analytics firm, or a site shares a dataset with an unaffiliated academic collaborator, the CTA’s ownership clause tells you who owns the data — it does not tell you the terms on which someone else may now receive it. A separate DTA closes that gap, keeping the CTA focused on trial conduct and the DTA focused on data movement — a single-purpose separation that research-contracting offices coordinated through ARMA, EARMA and INORMS increasingly recommend.

    What clauses must a clinical trial DTA cover?

    A compliant clinical trial DTA is built around a defined clause set. Where cross-border transfer is involved, the legal transfer mechanism clause is not optional under UK GDPR/EU GDPR Chapter V (Articles 44–49), which requires an adequacy decision, Standard Contractual Clauses, or an equivalent safeguard before personal data leaves the UK or EEA.

    • Purpose limitation — the exact research use(s) the recipient may apply to the data, with no implied right to broader secondary use.
    • Legal transfer mechanism — for cross-border transfers, the EU Standard Contractual Clauses (Implementing Decision (EU) 2021/914, June 2021) or the UK ICO’s International Data Transfer Agreement (IDTA), in force since 21 March 2022 and mandatory for new UK transfer contracts from 21 September 2022.
    • Confidentiality and re-identification prohibition — an express bar on attempting to re-identify anonymised or pseudonymised participants.
    • Security safeguards — encryption in transit and at rest, access controls, and breach-notification timelines.
    • Retention and destruction/return — a fixed deadline by which the recipient must destroy or return the dataset, with certification of destruction.
    • Audit and inspection rights — the data holder’s right to verify the recipient’s compliance.
    • Publication and attribution terms — how the recipient may cite or publish findings derived from the data, and what data-sharing statement language applies.

    Two further reference points shape this clause set. Under the HIPAA Privacy Rule (45 CFR §164.514(e)), a US covered entity sharing a “limited data set” must do so under a Data Use Agreement with materially the same content requirements as a clinical trial DTA. Since July 2018, the ICMJE has required a data-sharing statement as a condition of publication for trials reporting individual patient-level data — so the DTA’s publication and attribution clause is a downstream publication requirement, not a courtesy.

    Frequently asked questions

    What is a data transfer agreement in clinical trials?

    A data transfer agreement (DTA) is a legally binding contract that sets the terms for moving clinical trial data from a data controller to a third-party recipient. It defines permitted use, retention limits, security safeguards and cross-border transfer mechanisms, and applies whenever data — not physical specimens — moves outside the originating study team.

    What is the difference between a DPA and a DSA?

    A Data Processing Agreement (DPA) binds a processor acting strictly on a controller’s instructions, as required by UK GDPR Article 28. A Data Sharing Agreement (DSA) — the closer relative of a clinical trial DTA — governs transfers between two independent controllers who each decide their own purposes for the data.

    What is a material transfer agreement in clinical trials?

    A material transfer agreement (MTA) governs the transfer of tangible items — blood, tissue, biopsies or investigational compounds — between institutions, covering permitted use, ownership of derivatives and liability. Unlike a DTA, an MTA never addresses data itself; a single trial commonly needs both when biological samples travel with associated datasets.

    What is the purpose of a data transfer agreement?

    The purpose of a data transfer agreement is to make a specific transfer of clinical trial data lawful and auditable. It fixes the legal transfer mechanism, restricts secondary use, sets retention and deletion deadlines, and assigns liability if the recipient breaches confidentiality or re-identifies anonymised participants.

    What this means for sponsors, sites and data recipients

    Treating the DTA as a genuine standalone instrument — not a subset of the CTA, and not interchangeable with an MTA — closes a compliance gap that institutional research-contracting offices flag repeatedly. As secondary use of trial data grows through repositories, federated analytics and cross-sponsor licensing, data movements that fall outside the original CTA’s scope will keep rising.

    Research administrators, data protection officers and sponsors gain most by maintaining a standing DTA template — pre-cleared for common transfer scenarios and distinct from their MTA and CTA templates — so a new data recipient can be onboarded against a known, auditable clause set rather than a bespoke renegotiation each time.

    For definitions of related contracting and data-governance terms, research administrators can consult the CASRAI dictionary of research-administration terms; broader context on how these agreements sit within institutional research operations is covered in CASRAI’s research administration content.

  • Data Sharing Agreement Template UK: Research Collaboration Guide

    A data sharing agreement is legally required under UK GDPR when two or more institutions act as joint controllers of personal data in a research collaboration — Article 26 makes this a binding obligation, not a discretionary policy choice. It is a legal contract, distinct from a data management plan, with no equivalent status in data protection law. Searching for a generic data sharing agreement template UK institutions can copy is the wrong starting point: the correct document depends on your controller status, not a fill-in-the-blank form.

    A data sharing agreement is a written contract between two or more organisations that sets out the purpose, scope, lawful basis, security standards, and responsibilities governing an exchange of personal data. For research administrators coordinating multi-institution studies, knowing exactly when one is mandatory — and how it differs from a data management plan or a data processing agreement — determines whether a project is compliant before the first dataset moves.

    Data sharing agreement vs data management plan: what’s the difference?

    These two documents are frequently conflated in research administration, but they serve different functions. A data sharing agreement is a legally binding contract between institutions. A data management plan (DMP) is a research-planning document, usually required by a funder as a grant condition, describing how data will be collected, stored, and archived over a project’s life.

    • Legal status — a data sharing agreement can be a binding contract; a DMP is a funder deliverable with no contractual force.
    • Trigger — a data sharing agreement responds to UK GDPR obligations; a DMP responds to funder grant terms.
    • Audience — a data sharing agreement binds the named institutions; a DMP is submitted to and reviewed by the funder.
    • Content focus — a data sharing agreement covers lawful basis, security, and liability; a DMP covers data formats, repositories, and preservation.

    UKRI’s data policy expects funded researchers to produce a DMP, and Horizon Europe’s Model Grant Agreement requires one as part of its open science obligations. Neither substitutes for a data sharing agreement where personal data crosses institutional boundaries — the two are complementary, not interchangeable.

    When does UK GDPR require a data sharing agreement?

    UK GDPR does not impose a blanket legal requirement to have a written data sharing agreement for every instance of data sharing. Whether one is mandatory depends on the legal relationship between the parties, not on the existence of a research project alone.

    Under Article 26 of UK GDPR, organisations that jointly determine the purposes and means of processing personal data — for example, two universities co-designing a study and jointly deciding what data to collect and how to use it — are joint controllers. The law requires them to set out their respective responsibilities in an arrangement, including who handles privacy notices, subject access requests, and the primary contact point for data subjects.

    Where institutions instead act as independent controllers — each using the shared data for its own separate purpose, such as one university passing anonymised cohort data to a partner for an unrelated secondary analysis — UK GDPR does not legally mandate a written agreement. The Information Commissioner’s Office (ICO) nonetheless recommends one as good practice, since it helps demonstrate the UK GDPR accountability principle.

    The regulatory landscape shifted further with the Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025 and amends both UK GDPR and the Privacy and Electronic Communications Regulations — institutions should check DSIT’s commencement timetable before assuming legacy practices remain unchanged.

    What must a data sharing agreement contain?

    The ICO’s statutory Data Sharing Code of Practice sets out what a data sharing agreement should cover, regardless of whether it is legally mandatory in a given case. A research-focused agreement should address:

    • The identity of every party, including a named Data Protection Officer contact.
    • The specific research purpose and why the sharing is necessary to achieve it.
    • A precise description of the data items shared, flagging any special category or criminal offence data.
    • The lawful basis each party relies on, which may differ between institutions.
    • The designated point of contact for data subjects — mandatory for joint controllers under Article 26.
    • Security, retention, and end-of-project deletion or return arrangements.
    • Breach-notification procedures and safeguards for any international data transfer.

    The table below distinguishes the three documents most often confused.

    Document Legally mandatory? Governs Typical owner
    Data sharing agreement Only for joint controllers (Article 26) Lawful basis, roles, security, liability Data Protection Officer / legal team
    Data processing agreement Yes, always (Article 28) Processor’s instructions from the controller Data Protection Officer / procurement
    Data management plan Only if the funder requires it Data formats, storage, archiving over project lifecycle Principal investigator / research office

    Data sharing agreement vs data processing agreement

    A data sharing agreement and a data processing agreement address opposite relationships. A data sharing agreement applies between two or more controllers who each decide, jointly or independently, how personal data will be used. A data processing agreement applies when a controller instructs a processor — an organisation handling data solely on the controller’s instructions, such as a cloud storage provider — to process personal data on its behalf. Article 28 of UK GDPR makes the processing agreement mandatory in every controller-to-processor relationship, with terms prescribed by law; no equivalent blanket rule exists for controller-to-controller sharing.

    Common questions on data sharing agreements

    Is a data sharing agreement legally required?

    A data sharing agreement is legally mandatory only when two or more organisations act as joint controllers under UK GDPR Article 26. For independent controllers sharing data for their own separate purposes, the ICO’s data sharing code recommends but does not legally require a written agreement — though skipping one weakens your accountability defence if challenged.

    What is the difference between a data sharing agreement and a data processing agreement?

    A data sharing agreement governs data moving between two controllers who each decide how it is used. A data processing agreement is legally required under UK GDPR Article 28 whenever a controller instructs a processor to handle data on its behalf. Confusing the two risks drafting entirely the wrong contractual terms for the relationship.

    What are the 7 golden rules of data sharing?

    The “seven golden rules” originate from UK government safeguarding guidance for practitioners, not from UK GDPR itself. They emphasise that data protection law is not a barrier to justified sharing, that sharing should be necessary and proportionate, and that decisions must be recorded — sound principles, but not a substitute for a formal data sharing agreement.

    What is the data sharing law in the UK?

    There is no single “data sharing law” — sharing personal data is governed by UK GDPR, the Data Protection Act 2018, and, since Royal Assent on 19 June 2025, the Data (Use and Access) Act 2025, which amends both frameworks. Research collaborations must also observe common-law confidentiality duties alongside these statutes.

    What this means for research administrators

    For institutions running multi-site studies, the practical starting point is a controller-relationship analysis, not a template download. Research offices should determine whether partners are jointly designing the research question — pointing to joint controllership and a mandatory Article 26 arrangement — or each applying the data to its own distinct purpose, pointing to independent controllership and a recommended, non-mandatory agreement. This should run alongside, not instead of, the DMP required by funders such as UKRI or Horizon Europe. Bodies like ARMA (the Association of Research Managers and Administrators) increasingly treat this controller-status check as standard due diligence, sitting alongside ethics review rather than as a legal afterthought.

    Getting the agreement right

    A data sharing agreement and a data management plan answer different questions: one sets the legal terms under which personal data moves between institutions; the other describes how research data will be handled and preserved over a project’s lifecycle. Joint decision-making about personal data requires the former as a matter of UK GDPR law; funders increasingly require the latter as a matter of grant compliance. Treating the two as interchangeable is the most common compliance gap in multi-institution research — build the controller-status check into standard research administration workflow, before data starts moving.