A data sharing agreement is the contract two organizations sign before one hands a dataset to the other. It defines what data moves, how it must be protected, what the recipient is allowed to do with it, who pays if something goes wrong, and what happens to the data when the project ends. Businesses, researchers, and agencies use these agreements whenever both sides will make independent decisions about the data rather than one simply processing it under the other’s instructions.
When You Need One
Not every information exchange calls for this specific contract, and confusing it with related documents is a common early mistake. A non-disclosure agreement protects confidential business information but says nothing about how data gets processed, stored, or destroyed. A data processing agreement, required under regulations like the GDPR, governs situations where one party processes personal data on behalf of another. A data sharing agreement is broader: it covers any scenario where a defined dataset is transferred to another party that will use it for its own purposes or a jointly agreed objective.
The situations that typically require one include two organizations collaborating on research using pooled datasets, a vendor receiving customer information to provide analytics or marketing services, government agencies exchanging records for program administration, and a company sharing proprietary data with a business partner. The distinguishing feature is that both parties have some degree of independent use or decision-making over the data. If the recipient will make independent decisions about how to analyze or apply what they receive, this is the right instrument.
Identifying the Parties
Every workable agreement starts by naming the parties and their roles with enough specificity to assign liability: full legal names, addresses, and the key contacts responsible for managing the data on each side. This matters more than it sounds. When a breach happens two years into a five-year arrangement, you need to know exactly which entity is on the hook and who at that entity was responsible for oversight.
Scope and Permitted Use
Describe the exact data being shared, down to the field level when possible. Vague descriptions like “customer information” invite disputes. Effective agreements list the specific data elements — names, email addresses, transaction histories, geolocation logs, or whatever applies — either in the main body or an attached exhibit. Categorizing the data by sensitivity level (personally identifiable information, de-identified research data, proprietary financial records) helps both parties apply the right security controls.
Equally important is restricting what the recipient can do with the data. If you share customer records for a joint research project, the agreement should prevent the recipient from repurposing that data for marketing or selling it to third parties. The narrower the permitted use, the stronger your position if something goes wrong. Most disputes originate here, not from outright theft but from one party stretching the definition of “permitted use” beyond what the other intended.
Intellectual Property and Derived Data
One area that catches organizations off guard is who owns insights, models, or new datasets built from the shared data. If you give a partner access to customer behavior data and they train a predictive model on it, who owns the model? Without a clear clause, the answer depends on whatever a court decides later. Most well-drafted agreements specify that the original data remains the property of the provider, and that derivative works — analytics, aggregated reports, trained algorithms — belong to whichever party the agreement designates, often with a license back to the other party for the project’s purposes.
Pre-existing intellectual property should stay with its owner. The agreement should say this outright and clarify that neither party acquires rights to the other’s background IP just by participating. For projects where both parties contribute data and jointly develop something new, negotiate co-ownership terms or licensing arrangements before the work begins, not after someone has already built something valuable.
Security and Technical Terms
The technical section dictates how data moves between the parties and how it’s protected once it arrives. Encryption is the baseline. Most agreements require AES-256 encryption for data both at rest and in transit, which is the federal standard published by the National Institute of Standards and Technology for protecting sensitive information.1National Institute of Standards and Technology. Advanced Encryption Standard (AES) Secure file transfer protocols or specific API endpoints are the standard transmission methods, and the agreement should name the exact method rather than leaving it to the recipient’s discretion.
Beyond encryption, specify where the recipient will store the data: which cloud environments, which physical data centers, and whether the data can leave a particular jurisdiction. Access controls like multi-factor authentication and role-based permissions ensure that only authorized personnel can view sensitive datasets. These are often required by insurance underwriters as a condition of cyber liability coverage, and they become critical evidence if a breach occurs.
Retention and Destruction
Every dataset has a useful life, and the agreement should define it. Some data needs to be purged within 90 days of a project’s completion; other records must be kept for years to satisfy financial or healthcare recordkeeping requirements. State the retention period and spell out the destruction method — cryptographic erasure, physical disk shredding, or certified deletion — along with a requirement that the recipient provide written confirmation once the data is gone. Vague language like “data will be deleted when no longer needed” gives the recipient too much discretion and makes enforcement nearly impossible.
Audit Rights
A security clause without audit rights is largely decorative. The agreement should give the data provider the right to verify compliance through periodic audits, penetration testing, or by requiring the recipient to share current SOC 2 Type II reports. Industry practice varies, but annual security assessments and penetration tests are common, with some high-sensitivity agreements requiring quarterly vulnerability scans. Specify who pays for these audits and what happens if the recipient fails one, including the right to suspend data access until deficiencies are corrected.
Liability, Indemnification, and Insurance
This section determines who pays when things go wrong, and it deserves more attention than it typically receives. A strong indemnification clause requires the party that causes a breach to cover the full cost of the fallout: forensic investigations, notification of affected individuals, credit monitoring services, call center operations, regulatory fines, and legal fees. These costs add up fast. The average data breach runs into the millions, and the party holding the data when it leaked is usually the party holding the bill.
Most agreements also include a liability cap, a ceiling on total financial exposure that is often tied to the contract value or a negotiated dollar amount. Watch the interplay between the cap and the indemnification clause. If your liability cap is $500,000 but the indemnification obligation for a breach could easily exceed that, the cap effectively overrides the indemnification promise. Many organizations negotiate carve-outs that exclude data breaches, confidentiality violations, and indemnification obligations from the general liability cap, leaving those exposures uncapped or subject to a higher “super cap.”
Cyber liability insurance requirements belong in the agreement as well. The specific coverage limits depend on the volume and sensitivity of the data being shared, but aligning cyber coverage with the overall risk exposure of the arrangement is the standard approach. Requiring the recipient to name the data provider as an additional insured on their policy provides a direct path to recovery if the recipient’s negligence causes a breach.
Breach Notification
When a security incident occurs, speed matters, both for damage control and for regulatory compliance. The agreement should require the recipient to notify the provider within a defined timeframe after discovering a breach. Contractual notification windows typically range from 24 to 72 hours, though shorter is better from the provider’s perspective. The notification should include what data was compromised, how the breach occurred, what the recipient has done to contain it, and a point of contact for ongoing coordination.
This contractual obligation sits on top of legal requirements that vary by jurisdiction. HIPAA has its own breach notification rules for health information. The GDPR requires controllers to notify their supervisory authority within 72 hours of becoming aware of a breach, unless it is unlikely to pose a risk to individuals.2General Data Protection Regulation (GDPR). Art. 33 GDPR Notification of a Personal Data Breach to the Supervisory Authority All 50 states have their own breach notification laws, with required deadlines ranging from “as expeditiously as possible” to 30 calendar days. Draft the notice provision around the most aggressive deadline that could apply, so neither party is scrambling to figure out obligations while the clock is running.
Regulatory Overlays
Data sharing agreements don’t exist in a vacuum. Depending on the type of data involved, several federal and international frameworks impose specific requirements the agreement must reflect. Leaving these out can trigger penalties that dwarf the value of the underlying project.
HIPAA for Health Information
When the shared data includes protected health information, HIPAA requires a Business Associate Agreement between the covered entity and any organization that creates, receives, maintains, or transmits that information on its behalf.3U.S. Department of Health and Human Services. Business Associate Contracts The BAA must establish the permitted uses and disclosures of the data, require the business associate to implement appropriate safeguards, mandate reporting of unauthorized disclosures, ensure subcontractors agree to the same restrictions, and require return or destruction of the data when the relationship ends.4eCFR. 45 CFR 164.504 Penalties are tiered by culpability and adjusted for inflation annually, with the highest tier reaching over $2.1 million in annual caps. A business associate is directly liable under HIPAA for unauthorized uses or disclosures and for failing to safeguard electronic protected health information.5U.S. Department of Health and Human Services. Business Associates
GDPR for International Data
If the exchange involves personal information of individuals in the European Economic Area, the GDPR requires a data processing agreement meeting Article 28. The processor must act only on documented instructions from the controller, ensure staff confidentiality, implement appropriate security measures, assist with data subject rights requests, delete or return all personal data after the engagement ends, and submit to audits.6General Data Protection Regulation (GDPR). Art. 28 GDPR Processor The agreement must also specify the subject matter, duration, nature and purpose of processing, the types of personal data involved, and the categories of data subjects.
Transferring data outside the EEA adds another layer. Organizations typically rely on standard contractual clauses, pre-approved model contract terms issued by the European Commission, to authorize cross-border transfers when the destination country lacks an adequacy decision.7European Commission. Standard Contractual Clauses (SCC) Failing to use an approved transfer mechanism can trigger fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher.8General Data Protection Regulation (GDPR). Art. 83 GDPR General Conditions for Imposing Administrative Fines
FERPA for Student Records
Educational institutions that share student records with researchers, auditors, or vendors must comply with FERPA’s written agreement requirements. Under the studies exception, the agreement must specify the purpose, scope, and duration of the study; restrict use of personally identifiable information to that stated purpose; prohibit personal identification of students by anyone outside the research organization; and require destruction of all identifiable information once the study is complete, with a stated destruction timeline.9eCFR. 34 CFR 99.31 Under What Conditions Is Prior Consent Not Required Sharing student data without a conforming written agreement violates federal law and can jeopardize the institution’s federal funding.
COPPA for Children’s Data
Organizations that collect personal information from children under 13 face additional restrictions under the Children’s Online Privacy Protection Act. Sharing children’s data with third parties for purposes like targeted advertising requires separate verifiable parental consent beyond what was obtained for the initial collection. Operators must also maintain a written data retention policy, limit retention to the time reasonably necessary for the original purpose, and establish a written data security program. Civil penalties currently run up to $53,088 per violation.
FTC Enforcement and State Laws
Outside sector-specific regulations, the Federal Trade Commission can bring enforcement actions under Section 5 of the FTC Act against companies that violate their own data sharing promises or fail to maintain adequate security for consumer information.10Federal Trade Commission. Privacy and Security Enforcement If your privacy policy says you won’t share customer data with third parties and your data sharing agreement allows exactly that, the FTC considers it a deceptive practice. Your agreement and your public-facing privacy disclosures need to say the same thing.
The United States still has no comprehensive federal privacy law. More than 20 states have enacted their own consumer privacy statutes that impose obligations on businesses handling residents’ personal data. These laws commonly require contracts with service providers that restrict data use to a specific business purpose, prohibit selling or sharing beyond the agreed scope, and give consumers the right to request deletion of their information, typically with a 45-day response window. If your arrangement touches consumer data from multiple states, the agreement needs to accommodate the most restrictive requirements that apply.
Governing Law and Dispute Resolution
When the relationship breaks down, the dispute resolution clause determines whether you end up in a courtroom, an arbitration hearing, or a mediation session. Arbitration is common in these agreements because it is faster and more private than litigation, and neither party wants the details of a data dispute playing out in public filings. Specify the arbitration body, the rules that govern proceedings, the location, and how costs are split.
Governing law matters more than people realize. If the data provider operates under New York law and the recipient operates under English law, the choice-of-law clause determines which jurisdiction’s rules apply to contract interpretation, breach remedies, and limitation periods. For international arrangements, this choice intersects with GDPR requirements and can affect which courts or regulators have jurisdiction over enforcement. Pick the governing law deliberately, not as an afterthought at the end of negotiations.
Execution and Ongoing Management
Finalizing the agreement requires signatures from authorized officers at both organizations. Electronic signature platforms that generate a digital audit trail are standard practice, though some parties still insist on wet-ink signatures for high-value deals. Once executed, store the agreement in a central contract management system where compliance teams can track key dates: renewal deadlines, audit schedules, and retention period expirations.
A signed agreement that sits in a drawer accomplishes nothing. Active management means scheduling the audits and security reviews the agreement calls for, tracking the retention timeline so data gets destroyed on schedule, and monitoring regulatory changes that might require amendments. Build a termination notification window into the agreement, 30 or 60 days is standard, so neither party is caught off guard when the relationship ends and data needs to be returned or destroyed.
What Survives Termination
Termination or expiration of the agreement doesn’t end all obligations, and a survival clause makes that explicit. Confidentiality provisions, indemnification for past breaches, intellectual property ownership, and regulatory compliance obligations like GDPR data deletion requirements typically survive the agreement’s end. The clause should name each surviving provision and, where appropriate, assign a duration. Confidentiality and IP protections commonly survive indefinitely or for at least five years. Indemnification survival periods are more heavily negotiated, with 12 to 24 months being common for general representations but longer periods, or no expiration, for data breach liability. Any provision not expressly listed in the survival clause generally expires when the agreement does, so err on the side of naming too many rather than too few.