Controller-to-controller data sharing agreement: what it is and what to include

What a controller-to-controller data sharing agreement is

A controller is the party that determines the purposes and means of processing personal data. When two controllers share personal data and each one uses it for its own, separately defined purposes, the arrangement is controller to controller rather than controller to processor. A processor only acts on documented instructions from a controller, so a controller-to-processor relationship is governed by a data processing agreement (DPA), not a data sharing agreement.

The controller-to-controller label comes from the vocabulary of controllers and processors used in the GDPR, and it is widely adopted in the United States by privacy teams that operate across both regimes. Under US state privacy laws such as the California Consumer Privacy Act as amended by the CPRA, the equivalent situation is a business disclosing personal information to a third party, or to another business that will use it for its own purposes, which can qualify as a sale or a sharing and triggers specific contractual requirements. Whatever the label, the substance is the same: two accountable parties, one flow of personal data, and a need to write down the rules.

It is worth separating two related concepts. Independent controllers each decide their own purposes and are individually responsible for their own processing. Joint controllers decide the purposes and means together and share responsibility for a common processing activity. A controller-to-controller data sharing agreement usually covers independent controllers, while joint controllership calls for a joint controller arrangement that allocates respective responsibilities. Naming the model correctly at the outset drives most of the drafting that follows.

Key terms and clauses to include

A workable controller to controller data sharing agreement should address, at a minimum, the following:

• Parties and roles: confirm that each party is an independent controller (or, where relevant, that the parties are joint controllers), so that responsibility is not accidentally reassigned.
• Purpose and scope: state the specific, limited purposes for which the data may be used, and prohibit further use that is incompatible with those purposes.
• Categories of data and data subjects: describe exactly which personal data fields are shared and whose data they are, avoiding open-ended transfers.
• Lawful basis and transparency: record each party’s lawful basis for processing and confirm that the privacy notices given to individuals cover the sharing.
• Data quality and minimization: commit to sharing only what is necessary and to keeping shared data accurate and current.
• Security measures: set baseline technical and organizational safeguards, such as encryption in transit and at rest and access controls, and require prompt reporting of security incidents.
• Breach notification: fix a clear timeline and a single point of contact for notifying the other party of a personal data breach, so statutory clocks can be met.
• Individual rights: agree how access, deletion, correction, and opt-out or objection requests are routed and answered when both parties hold the same data.
• Retention and deletion: define how long each party keeps the data and what happens to it when the agreement ends.
• International transfers: address any cross-border transfer mechanism if data leaves its home jurisdiction, including standard contractual clauses where applicable.
• Onward disclosure: restrict whether and how each party may pass the data to its own vendors or other third parties.
• Liability, indemnity, and audit: allocate responsibility for regulatory penalties and third-party claims, and reserve a right to verify compliance.
• Term, termination, and governing law: state the duration, exit rights, the governing law, and the forum for disputes.

When you need one

You need a controller-to-controller data sharing agreement whenever your organization discloses personal data to another party that will decide, on its own, how to use it. Common triggers include co-marketing and lead-sharing arrangements between partner companies, referral programs where a customer’s details pass to a partner, shared loyalty or membership schemes, joint research or analytics projects, and disclosures to insurers, brokers, or financial institutions that then act as controllers. Corporate transactions can also require one, for example when two entities exchange customer records but neither is acting as the other’s processor.

A helpful test is to ask who decides the purpose. If the recipient simply carries out your instructions and cannot repurpose the data, you likely need a DPA instead. If the recipient sets its own purposes, keeps its own records, and answers to regulators in its own name, a controller-to-controller data sharing agreement is the right instrument. When US state privacy laws are in play, the same disclosure may also need to be characterized as a sale, a sharing, or a third-party transfer, each with its own contract terms and consumer-facing disclosures.

Common pitfalls

The most frequent mistake is using a DPA template for what is really a controller-to-controller relationship. A DPA assumes that one party instructs and the other obeys, which misstates responsibility when both parties are independent controllers and can leave the sharing without a valid contractual footing. A second pitfall is vague purpose language: broad phrases like business purposes invite scope creep and undermine the purpose limitation that regulators expect.

Other common gaps include failing to update customer-facing privacy notices to reflect the sharing, omitting a workable breach-notification timeline, and saying nothing about how individual rights requests are handled when both parties hold the data. Teams also leave retention and deletion undefined, so copies of personal data persist indefinitely, and they forget onward-transfer controls, which means the counterparty can pass the data to its own subprocessors or partners with no oversight. Finally, agreements are frequently signed and then lost: no central copy, no reminder before renewal, and no record of which version governs, so the operational commitments quietly lapse.

Disciplined contract management is what turns these clauses from paper into practice. Keeping every controller-to-controller data sharing agreement in a single contract repository, with an audit trail, renewal and deadline alerts, and standardized templates, means the purpose limits, security commitments, and deletion deadlines stay visible to the people who have to honor them. Pactolane centralizes those agreements and their obligations, while PactAI can run a compliance playbook across an agreement, flag conflicting or missing clauses, and surface an exposure analysis so your team can decide what to fix before signature. There is no .docx download here; the aim is a living, well-governed contract, not a one-off file that ages out of date.