How to Review a Data-Sharing Agreement (2026 Checklist)

A data-sharing agreement sets the terms when two or more organisations share personal data and each decides its own purposes for using it. That makes it different from a data processing agreement, where a processor only acts on a controller's instructions. Here both sides are controllers (or joint controllers), so the agreement has to pin down why the data is shared, on what lawful basis, how it is protected, and who answers to the individuals and the regulator. Reviewing one well starts with getting the roles right, because everything else follows from that. This is general guidance, not legal advice. ## The fast answer: what to check first Settle four points before the detailed read. What are the roles (separate controllers, joint controllers, or controller and processor). What is the specific purpose, and is sharing limited to it. What is the lawful basis for sharing, and how are individuals told. How is the data secured, and what happens if it leaks. If the agreement is vague on roles or purpose, fix that before anything else. ## Clause-by-clause review checklist ### Roles of the parties State clearly whether each party is an independent controller, whether they are joint controllers, or whether one is actually a processor (in which case you need a DPA instead). For joint controllers, there must be an arrangement that sets out who does what, especially who handles individual rights and transparency. Getting this wrong misallocates legal responsibility. ### Purpose and purpose limitation The agreement should name the specific purpose of the sharing and say the data will not be used for anything incompatible. Watch for broad purposes ("for business purposes") that would let either side repurpose the data. The tighter the purpose, the safer the sharing. ### Lawful basis and fairness Each party should identify its lawful basis for its part of the processing (for example consent, contract, legal obligation, or legitimate interests, with special-category data needing an extra condition). Check who is responsible for telling individuals their data is shared, in a privacy notice, and that the sharing is actually fair and expected. ### Data minimisation and quality Share only the data fields needed for the purpose, not whole records by default. Look for a description of exactly which data is shared and a duty to keep it accurate and up to date, with a way to correct errors on both sides. ### Security Both parties should commit to appropriate technical and organisational measures: encryption in transit and at rest, access control, logging, and secure transfer methods. For sensitive data the bar is higher. Avoid agreements that describe the sharing in detail but say almost nothing about how the data is protected in transit and at each end. ### International transfers If data crosses borders to a country without an adequacy decision, check for a valid transfer mechanism such as the standard contractual clauses or the relevant local equivalent, with a transfer risk assessment where needed. Confirm the clauses are current and completed. ### Individual rights Decide who handles requests from individuals: access, correction, deletion, objection. The agreement should set a process and time limits so a request to one party is handled properly even though the data sits with both. ### Breach notification and cooperation There should be a clear duty to tell the other party quickly if shared data is breached, with enough information and cooperation for each to meet its own regulatory notification duties. Check the trigger and the timing. ### Retention, return and deletion Set how long each party may keep the shared data, tied to the purpose, and what happens at the end: deletion or return, with confirmation. Open-ended retention is a common weakness. ### Audit, review and governance Look for a right to seek assurance that the other party is complying, a named contact on each side, and a review date so the agreement does not go stale as the sharing evolves. ### Liability and indemnity Because both parties are controllers, each is responsible to individuals and regulators for its own compliance. Check how liability is shared between the parties for a breach caused by one of them, and whether there is an indemnity for losses caused by the other party's failure. ## Red flags to push back on Roles left undefined, or a "data-sharing agreement" that is really a processor relationship dressed up. Broad purposes that allow repurposing. No lawful basis stated. Thin or missing security terms. No process for individual rights. Open-ended retention. Cross-border sharing with no transfer mechanism named. ## How the law changes by jurisdiction Contract law is national, so the same words do not behave the same everywhere. In common-law systems (India, the UK, Singapore, Australia, the US) courts lean on the written terms and read ambiguity against the drafter. Governing-law and jurisdiction clauses decide which country's rules apply and where disputes are heard; check they match where the parties and the assets actually are. In India, stamp duty and, for many instruments, registration are live concerns, and the Indian Contract Act 1872 governs formation. In the US, state law varies and the Uniform Commercial Code may apply where goods are involved. Across the EU and UK, data and consumer rules add mandatory terms you cannot contract out of. When in doubt, take local advice; this page is general information, not legal advice. ## A simple review workflow Fix the roles and the purpose first, then the lawful basis and transparency, then security and transfers, then rights, breach and retention, then liability. Compare the agreement with both parties' privacy notices so the sharing is actually disclosed. Keep an issues list with clause reference, risk and proposed change, and involve your data-protection lead, since this is one of the agreements regulators look at closely. ## One workspace for drafting, review and tracking Everything above is work you can do by hand: read the draft, mark the risky positions, line up your redlines, remember the dates. The friction is rarely the reading. It is that the draft, the comments, the versions, the signed copy and the renewal date usually live in five different places. The simple idea behind an AI contract workspace is to keep that work together: draft from your own catalogue, see each clause flagged favourable, neutral or unfavourable to you, edit clauses in plain English and get a clean diff, keep a live activity timeline so every version is traceable, and track key dates and obligations so renewals and notices do not slip. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts. It is India-first today; deeper support for other jurisdictions and a single legal health pane (the Company Command Centre) are on the roadmap. None of that replaces legal advice on a specific deal. It just means the review you ran once does not have to be rebuilt from scratch next quarter.