Business guide to data sharing agreements with a document and data governance illustration
    Table of contents

    By-Research Team

    August 18, 2026 | 12 min read | Governance


    What Is a Data Sharing Agreement? A Complete Guide

    Data rarely stays where it is collected. Businesses share customer information with partners, vendors, analytics providers, research organisations, financial institutions, and other external parties every day. The problem begins when the data moves faster than the rules governing it.

    A Data Sharing Agreement (DSA) creates those rules. It establishes what data can be shared, why it can be used, who is responsible for protecting it, how long it can be retained, and what happens when the relationship changes or ends.

    But there is an important distinction: a DSA is not simply another compliance document to sign and file away. It is a governance blueprint for a data-sharing relationship.

    So, what exactly should a DSA do? When should an organisation use one? And what should happen after it is signed?

    This guide breaks down the Data Sharing Agreement lifecycle—from deciding whether you need one to reviewing, managing, updating, and eventually closing it.

    What Is a Data Sharing Agreement?

    A Data Sharing Agreement is a formal arrangement between organisations that defines the rules for sharing and using data. It typically identifies the parties, purpose, data involved, permitted uses, security expectations, retention requirements, responsibilities, and procedures for handling changes, incidents, and termination.

    Data sharing agreement defines how a data provider and recipient use, protect, and manage shared data.

    A DSA can therefore turn a loosely understood data exchange into a documented governance framework.

    When Is a Data Sharing Agreement Necessary?

    A Data Sharing Agreement is particularly useful when a data-sharing relationship is ongoing or involves meaningful risk. It is especially relevant when multiple parties, sensitive information, recurring transfers, or external service relationships make informal arrangements difficult to manage consistently.

    Common situations include:

    • Recurring data sharing: Customer, employee, transaction, or operational data is exchanged regularly.
    • Business partnerships: Two organisations need defined rules for using shared information.
    • Research and analytics: Multiple parties collaborate using a defined dataset.
    • Confidential datasets: Commercial or proprietary information needs controlled disclosure.
    • Multi-party arrangements: Several organisations receive, use, or contribute data.
    • External service relationships: An organisation needs contractual clarity over how another party handles shared data.

    Why Is a Data Sharing Agreement Important?

    A Data Sharing Agreement is important because it converts an informal data exchange into a documented framework of responsibilities, permitted uses, safeguards, and accountability. It gives each party a clear reference point for how shared data should be handled throughout the relationship.

    1. Clarifying Roles and Responsibilities

    A DSA clearly defines who is responsible for what when data is shared.

    It can specify who:

    • Provides and receives the data
    • Controls access and permitted use
    • Maintains security safeguards
    • Handles incidents, corrections, and deletion
    • Manages Data Principal requests
    • Monitors compliance with the agreement

    2. Controlling How Shared Data Is Used

    A DSA sets clear boundaries for how shared data can be used.

    It can define:

    • The approved purpose
    • Permitted and prohibited uses
    • Rules for onward sharing
    • Restrictions on unrelated reuse

    Having access to data does not mean having unlimited rights to use it.

    3. Reducing Privacy, Security and Contractual Risk

    A DSA documents the safeguards and responsibilities agreed between the parties.

    It can address:

    • Security and confidentiality
    • Access controls
    • Retention and deletion
    • Data breach responsibilities
    • Liability and termination

    4. Creating Accountability Between Parties

    A DSA creates a documented record of what was agreed and what each party must do.

    It can record:

    • Data covered by the agreement
    • Approved purposes
    • Agreed safeguards
    • Review requirements
    • Actions required when circumstances change

    Signing the agreement is the beginning of accountability—not the end of it.

    What Should a Data Sharing Agreement Include?

    A Data Sharing Agreement should clearly define what data is being shared, why it is being shared, how it can be used, and what each party is responsible for. The agreement should also establish rules for security, retention, third-party access, incidents, termination, and future changes.

    1. Parties and Their Roles

    Identify all organisations involved and clearly define who does what.

    Specify whether each party provides, receives, processes, or independently uses the shared data.

    2. Purpose and Scope

    Clearly state why the data is being shared and what the agreement covers.

    Avoid vague terms such as “business purposes.” Define the specific purpose, activities, and boundaries.

    3. Data Categories

    Specify what information will be shared.

    This may include customer, employee, transaction, research, operational, or confidential business data. Clearly define what is included—and excluded—from the agreement.

    4. Permitted and Prohibited Uses

    Define what the recipient can and cannot do with the data.

    Include restrictions on unrelated use, commercialisation, profiling, onward sharing, or use after the agreed purpose ends.

    5. Access and Security

    Set expectations for how shared data must be protected.

    This can include access controls, authentication, encryption, secure transfers, logging, security testing, and incident management.

    6. Retention and Deletion

    Define how long the data can be retained and what happens when that period ends.

    Specify when data must be returned, deleted, or securely destroyed, including after termination.

    7. Onward Sharing and Third Parties

    Clearly state whether the recipient can share the data with other parties.

    Define permitted third parties, approval requirements, and whether equivalent contractual safeguards must apply to them.

    8. Data Breach and Incident Responsibilities

    Define what happens if the shared data is lost, compromised, or accessed without authorisation.

    Specify notification procedures, escalation, cooperation, investigation, and remediation responsibilities.

    9. Data Quality and Correction

    Assign responsibility for keeping shared data accurate, complete, and up to date.

    Also establish how errors will be identified, corrected, and communicated between the parties.

    10. Confidentiality, Ownership and Intellectual Property

    Clarify who owns the data and what rights the recipient receives.

    Address confidentiality, intellectual property, analytical outputs, derivative datasets, commercialisation, and permitted use after the agreement ends.

    11. Audit and Assurance

    Define how parties can verify compliance with the agreement.

    Depending on the risk, this may include audits, certifications, security assessments, questionnaires, or periodic reviews.

    12. Liability and Dispute Resolution

    Establish what happens if a party fails to meet its obligations.

    Address liability, indemnification, dispute resolution, applicable law, and escalation procedures as appropriate.

    13. Term and Termination

    Define the start date, duration, renewal, and termination conditions.

    Also specify what happens to the data, access rights, and outstanding obligations when the agreement ends.

    14. Amendments and Change Management

    Explain how changes to the agreement will be approved and documented.

    This should cover changes to the data, purpose, parties, security requirements, legal obligations, or business relationship.

    A good DSA should describe the relationship as it actually operates—not as it existed when the contract was first drafted.

    How to Manage a Data Sharing Agreement After Signing

    A Data Sharing Agreement should be treated as a living governance record rather than a document that disappears into a contract repository after signature. Organisations should track active arrangements, monitor changes, maintain evidence, and connect agreements with relevant privacy and data-governance processes.

    1. Maintain a Central DSA Register

    Keep a central register of all Data Sharing Agreements so the organisation knows which agreements are active and what each one covers.

    The register should include the parties involved, purpose, data categories, agreement owner, effective and expiry dates, review dates, business owner, and current status.

    2. Track the Data, Parties and Purposes Covered

    A DSA register should record more than just the existence of an agreement.

    Track what data is being shared, who receives it, and why it is being shared. If a new recipient is added, the purpose changes, or a new dataset is introduced, check whether the existing agreement still covers the arrangement.

    3. Monitor Compliance With Agreed Terms

    A signed DSA is only useful if the parties follow its terms in practice.

    Regularly check whether the agreed rules around data use, access, security, retention, and onward sharing are being followed. If actual practices differ from the agreement, the arrangement should be reviewed.

    4. Track Amendments and Changes

    Keep a record of all important changes made to the data-sharing arrangement.

    This can include contract amendments, approvals, new recipients, changes to datasets, updated security requirements, review outcomes, and termination decisions. Maintaining this history helps teams work from the current version and provides a clear audit trail.

    5. Manage Renewals and Expiry

    Do not wait until a DSA expires to review whether it is still appropriate.

    Track renewal and review dates and set reminders well in advance. Before renewal, confirm that the parties, purpose, data, security requirements, and other terms still reflect the current arrangement.

    Data sharing agreement lifecycle from defining terms and sharing data to review, renewal, and closure.

    When Should a Data Sharing Agreement Be Reviewed or Updated?

    A Data Sharing Agreement should be reviewed regularly and whenever there is a material change to the data-sharing arrangement, its purpose, participating parties, security environment, or legal context. Significant complaints and security breaches should also trigger review because they may indicate that the existing controls no longer reflect the actual risk.

    1. When the Purpose of Data Sharing Changes

    If the purpose of sharing data changes, review the DSA to ensure it still covers the new use.

    For example, data originally shared for fraud detection may require a new assessment if it is later used for marketing analytics.

    2. When New Data Is Added

    Review the agreement when new datasets or data categories are introduced.

    New data may have different sensitivity, access, retention, or security requirements.

    3. When a New Recipient Is Added

    Adding a new organisation changes the data-sharing arrangement.

    Check who the new party is, what data it receives, why it needs the data, and what safeguards apply.

    4. When Onward Sharing Changes

    If the recipient starts sharing data with new vendors, affiliates, processors, or other third parties, review the DSA.

    New data destinations create new governance requirements.

    5. After a Data Breach or Security Incident

    A breach can reveal weaknesses in the existing agreement or how it is being followed.

    Review the DSA to determine whether responsibilities, security requirements, notification procedures, or other controls need to be strengthened.

    6. When Laws or Requirements Change

    Changes in privacy laws, regulations, industry requirements, or regulatory guidance may require the DSA to be updated.

    Review the agreement to ensure its obligations still reflect the applicable requirements.

    7. When the Business Relationship Changes

    Changes such as mergers, acquisitions, restructuring, new services, or new vendors can change how data is shared.

    Update the DSA if the existing terms no longer reflect the actual relationship.

    8. Before Renewal or Expiry

    Use renewal as an opportunity to check whether the agreement is still fit for purpose.

    Ask:

    • Is the data sharing still necessary?
    • Is the same data still required?
    • Are the same parties involved?
    • Is the original purpose still valid?
    • Do the existing controls still match the current risk?

    What Happens When a Data Sharing Agreement Ends?

    When a Data Sharing Agreement ends, the parties should follow the agreed post-termination process for stopping data sharing, revoking access, returning or deleting information, addressing retained copies, and documenting completion. Ending the contract does not automatically answer what happens to every copy of the data already created or stored.

    1. Stop Further Data Sharing

    Stop any transfers that are no longer authorised when the DSA ends.

    Disable relevant systems, APIs, file transfers, workflows, or manual processes connected to the arrangement.

    2. Revoke Access

    Remove access provided for the data-sharing relationship.

    This may include user accounts, API credentials, shared folders, dashboards, and system permissions.

    3. Return or Delete the Data

    Follow the agreement's requirements for returning, deleting, or securely destroying the shared data.

    Also consider copies stored in backups or other systems.

    4. Address Copies and Backups

    Check whether the data exists in backups, reports, analytics systems, derived datasets, or downstream systems.

    Define how these copies should be handled according to the agreement.

    5. Confirm Completion

    Obtain evidence that post-termination actions have been completed where appropriate.

    This could include deletion confirmations, access-revocation records, return confirmations, or destruction records.

    6. Document the Closure

    Update the DSA register and record the termination date, reason, data disposition, access removal, and any outstanding obligations.

    The relationship is not fully closed until the data lifecycle is closed too.

    Conclusion

    A Data Sharing Agreement provides the architecture for a controlled data-sharing relationship. It tells organisations what can be shared, why it can be shared, how it can be used, who is responsible, and what happens when circumstances change.

    The strongest DSAs do not exist merely to satisfy a compliance checklist. They translate business arrangements into clear operational rules.

    Build the agreement around the actual data flow. Review it against the actual business relationship. And update it when reality changes.

    Key Takeaways

    • A Data Sharing Agreement defines clear rules for how data is shared, used, protected, and managed.
    • Use a DSA when data sharing is ongoing or involves meaningful risk, multiple parties, sensitive data, or complex arrangements.
    • A DSA should clearly define the parties, purpose, data, permitted uses, security, retention, and responsibilities.
    • Review the DSA when the data-sharing arrangement changes, such as when new data, recipients, purposes, or third parties are introduced.
    • Manage DSAs throughout their lifecycle by maintaining a central register, tracking changes, monitoring compliance, and managing renewals.
    • A DSA should be reviewed after significant events, including security incidents, legal changes, or major business changes.
    • When a DSA ends, stop sharing, revoke access, and return or delete the data as required by the agreement.
    • Proper closure includes documenting the termination and confirming that the data lifecycle has also been closed.

    Related Blog

    Assessment

    Liked the post? Share on: