Category: Data Governance Frameworks

Data Sharing Agreement

Also known as: DSA, Data Sharing Arrangement

Simply put

A data sharing agreement is a written agreement between two or more parties that sets out what data will be shared, why it is being shared, and how it may be used. It clarifies each party's responsibilities and the standards they must follow at each stage of the data sharing, whether the exchange happens once or on an ongoing basis. It is a governance and accountability tool rather than a guarantee of legal compliance on its own.

Formal definition

A data sharing agreement (DSA) is a documented arrangement between two or more parties that governs a one-time or enduring exchange of, or access to, data. Per ICO guidance under the UK GDPR framework, it typically states the purpose of the sharing, describes what happens to the data at each stage, sets applicable standards, and allocates responsibilities among the parties. A DSA is primarily a governance and accountability instrument that helps parties demonstrate how sharing is managed and constrains permitted uses of the shared data; it does not by itself establish a lawful basis for processing, determine controller or processor status, or ensure compliance, all of which depend on the underlying facts, jurisdiction, and implementation. This entry does not address cross-border transfer mechanisms, retention rules, security controls, or the distinct question of whether shared data qualifies as personal, special category, or non-personal data; treatment of DSAs also differs across regimes such as the EU GDPR, CCPA and CPRA, and HIPAA, and generic model templates should not be assumed to satisfy any specific regulatory obligation.

Why it matters

A data sharing agreement gives the parties to a data exchange a documented, shared understanding of what is being shared, why, and how the data may be used. In governance terms, this matters because accountability frameworks generally require organizations to demonstrate how data handling is managed rather than simply assert that it is under control. A DSA that records the purpose of the sharing, describes what happens to the data at each stage, sets applicable standards, and allocates responsibilities among the parties provides evidence of that management and constrains permitted uses of the shared data.

Just as important is understanding what a DSA does not do. On its own it does not establish a lawful basis for processing, determine controller or processor status, or ensure compliance; those questions depend on the underlying facts, the applicable jurisdiction, and how the sharing is actually implemented. Treating a signed agreement as a compliance guarantee is a common and consequential mistake. Generic or model templates, such as those published for research or public-sector contexts, should not be assumed to satisfy any specific regulatory obligation without review against the relevant regime.

Treatment of data sharing agreements also differs across regulatory regimes. The ICO's data sharing guidance sits within the UK GDPR framework, while the EU GDPR, the CCPA and CPRA, and HIPAA each frame sharing arrangements differently. A DSA is best understood as a governance and accountability instrument that supports, but does not replace, the separate legal analysis each regime requires.

Who it's relevant to

Data protection officers and privacy leads

DPOs and privacy professionals use DSAs as evidence of how a sharing arrangement is governed and to constrain the permitted uses of shared data. They should recognize that the agreement itself does not fix controller or processor status, establish a lawful basis, or confirm whether shared data is personal, special category, or non-personal; those determinations require separate analysis of the underlying facts and applicable regime.

Data governance and stewardship teams

Governance and stewardship functions rely on DSAs to define ownership, purpose, applicable standards, and responsibilities across parties. The agreement supports demonstrable accountability by documenting what happens to data at each stage, complementing but not substituting for security controls, which sit within information security rather than governance.

Legal and contracts professionals

Legal teams draft, review, and negotiate DSAs to allocate obligations and constrain permitted uses. They should be cautious about applying generic model templates, which are not guaranteed to satisfy any specific regulatory obligation, and should account for differences in how the EU GDPR, UK GDPR, CCPA and CPRA, and HIPAA treat sharing arrangements.

Research and public-sector data managers

Researchers and public-sector data managers frequently use DSAs to facilitate one-time or enduring exchanges, including court-to-researcher and inter-agency sharing. These agreements clarify which data may be shared and how it may be used, but do not themselves resolve cross-border transfer mechanics, retention rules, or the lawfulness of the underlying processing, which fall outside the scope of this entry.

Inside DSA

Parties and Roles

Identifies the organizations involved and specifies each party's role in the processing, generally distinguishing whether a party acts as a controller, joint controller, or processor. The allocation of roles determines which obligations each party bears, so this should be stated explicitly rather than left to inference.

Purpose and Scope of Sharing

Defines the specific purposes for which data may be shared and used, and the categories of data covered. Limiting use to defined purposes supports purpose limitation principles found in regimes such as the EU GDPR and UK GDPR, though the precise obligations differ across jurisdictions.

Lawful Basis or Legal Authority

Records the basis relied upon for the sharing where applicable. Consent is only one possible basis among several and should not be treated as the default or as guaranteeing compliance; the appropriate basis depends on context and jurisdiction.

Categories of Data

Specifies whether the shared data includes personal data or special category/sensitive data, since the latter typically attracts heightened requirements. It should also note whether any pseudonymized data is involved, recognizing that pseudonymized data generally remains personal data.

Security and Confidentiality Obligations

Sets out the technical and organizational measures each party must apply to protect confidentiality, integrity, and availability. These are information security obligations that complement, but do not replace, governance and accountability commitments.

Retention and Deletion Terms

States how long shared data may be held and what happens on termination or completion of purpose. This entry does not itself resolve statutory retention rules, which are determined by applicable law.

Data Subject Rights and Responsibilities

Allocates responsibility for handling individuals' rights requests and related communications between the parties, so that obligations do not fall into a gap between controller and processor duties.

Governance and Accountability Provisions

Covers oversight, points of contact, audit rights, incident notification, and record-keeping. Accountability under governance frameworks generally requires demonstrable evidence of compliance, not merely stated intent.

Common questions

Answers to the questions practitioners most commonly ask about DSA.

Does a data sharing agreement by itself make the sharing lawful?

No. A data sharing agreement documents responsibilities, purposes, and safeguards between parties, but it does not supply a lawful basis for processing. Under regimes such as the EU GDPR and UK GDPR, each disclosing and receiving party generally still needs its own valid lawful basis for the processing it carries out, and other obligations such as transparency to data subjects continue to apply. The agreement supports accountability but does not substitute for these underlying requirements.

Is a data sharing agreement the same thing as a controller-to-processor contract?

Not necessarily. The term data sharing agreement is often used for arrangements between separate or joint controllers who each determine purposes and means, whereas a controller-to-processor arrangement governs a processor acting on a controller's instructions and, under the EU and UK GDPR, must contain specific mandated terms. The obligations and the allocation of accountability differ depending on the relationship, so identifying whether the parties are joint controllers, independent controllers, or a controller and processor should precede drafting.

What core elements should a data sharing agreement typically address?

Agreements commonly specify the parties and their roles, the categories of data and any special category data involved, the purposes and lawful bases relied upon, the safeguards and security expectations, retention and deletion expectations, arrangements for handling data subject requests, and breach notification responsibilities between the parties. The exact required content depends on the applicable regime and the nature of the relationship, so this list is illustrative rather than exhaustive, and it does not address cross-border transfer mechanics.

How should responsibility for responding to data subject requests be allocated in the agreement?

The agreement should generally set out which party receives requests, how requests are routed between the parties, and expected timeframes for cooperation, so that individuals can exercise their rights without gaps. Where parties are independent or joint controllers, each typically retains its own accountability toward data subjects, and the agreement clarifies the operational handoff rather than transferring statutory obligations. This entry does not detail the specific response timelines or content requirements set by any particular regime.

Should a data protection impact assessment be completed before entering a data sharing agreement?

It depends on the processing. A data protection impact assessment is not always mandatory; under regimes such as the EU and UK GDPR it is generally triggered where processing is likely to result in high risk to individuals. Sharing involving special category data, large-scale processing, or novel uses may indicate the need for one. The assessment is a separate exercise from the agreement, and its outputs may inform the safeguards recorded in the agreement, but the agreement does not replace it.

How can parties demonstrate accountability for a data sharing arrangement over its lifecycle?

Accountability under governance and data protection frameworks generally requires demonstrable evidence rather than stated intent. Parties typically maintain the signed agreement alongside supporting records, review it when purposes or data categories change, and retain evidence that safeguards and breach-handling and deletion expectations are being followed. Periodic review and version control help show the arrangement remains current. This entry does not cover enforcement penalties or the specific record-keeping obligations imposed by any particular regime.

Common misconceptions

A data sharing agreement by itself makes the sharing lawful and compliant.

The agreement documents and allocates obligations, but compliance depends on a valid legal basis, adherence to applicable principles, and correct implementation. No single document guarantees compliance across jurisdictions or contexts.

If shared data is pseudonymized, tokenized, or encrypted, the agreement no longer concerns personal data.

Pseudonymization, tokenization, and encryption are protective measures but generally do not render data non-personal, since re-identification typically remains possible. Such data usually stays in scope and the agreement's obligations continue to apply.

A data sharing agreement is the same as a controller-to-processor contract, so one template fits all.

The appropriate terms depend on the roles of the parties. Controller-to-controller, joint controller, and controller-to-processor arrangements carry different obligations, and treating them interchangeably can misallocate accountability.

Best practices

Determine and state each party's role explicitly (controller, joint controller, or processor) before drafting, since this drives which obligations each party bears.

Define the purposes and categories of data narrowly, and flag where special category or sensitive data is involved so that any heightened requirements are addressed.

Do not rely on the existence of the agreement alone; confirm and record an appropriate lawful basis or legal authority rather than defaulting to consent.

Allocate responsibility for data subject rights, incident notification, and security measures clearly so obligations do not fall into gaps between the parties.

Build in audit rights, record-keeping, and evidence requirements to support demonstrable accountability rather than stated intent.

Address retention, deletion on termination, and any applicable jurisdictional variations explicitly, and confirm whether cross-border transfer mechanics are handled separately, as they are out of scope of the agreement's core terms.