Party Roles in Data Processing Agreements: When Controller-to-Controller Makes Sense

By Laith Sarhan

Every data processing agreement starts with a fundamental question: who is the controller and who is the processor?

Most agreements will default to the familiar pattern: the customer is the controller and vendors are processors. Some of the most important data flows in modern business, however, operate on a controller-to-controller basis, and mischaracterizing these relationships creates legal risk and operational confusion.

Understanding when controller-to-controller arrangements are appropriate is essential for companies navigating complex data ecosystems and trying to ensure that their chain of responsibilities is accordingly accounted for.

The Core Distinction

Controller: The organization that determines the purposes and means of processing personal information. The controller decides why data is collected and how it will be used. Under PIPEDA, this is the organization accountable to individuals for their data.

Processor: The organization that processes personal information on behalf of a controller, according to the controller's instructions. The processor only executes the controller's decisions.

Independent Controllers: Two organizations that each determine their own purposes for processing the same personal information. Neither acts on behalf of the other. Each is independently accountable.

The distinction matters because it determines who bears accountability, what agreements are needed, and what obligations flow to individuals.

When Controller-to-Controller Applies

Several common business relationships are properly characterized as controller-to-controller rather than controller-to-processor:

1. Employer of Record (EOR) Services

When you engage an EOR like Deel, Remote, or Oyster to employ workers in jurisdictions where you don't have an entity, the EOR isn't processing employee data on your behalf. The EOR is the employer. It determines how to process employee data for its own employment, payroll, benefits, and compliance purposes.

You provide the EOR with information about the individual (who they are, what role, what compensation). The EOR then processes that data—and collects additional data—for its own purposes as the legal employer.

This is two controllers:

• You: Controller of business relationship data, work assignments, performance information
• EOR: Controller of employment data, payroll processing, benefits administration, local compliance

The agreement between you and the EOR should reflect this. It's not a DPA with you as controller and EOR as processor. It's a services agreement between two controllers, with provisions addressing each party's independent obligations.

2. GTM and Sales Intelligence Tools

Platforms like Clay, Apollo, ZoomInfo, and similar GTM tools present an interesting case. When you use these tools, data flows in multiple directions:

• Data you provide: You may upload your prospect lists, CRM data, or target account information
• Data they provide: The platform provides enrichment data, contact information, intent signals from their own databases
• Data they generate: The platform creates derived insights by combining your data with their data and third-party sources

Is the GTM platform your processor? Not exactly. These platforms maintain their own databases, determine their own data collection practices, and use data from multiple customers to improve their products. They have independent purposes.

The appropriate framing is often:

• For data you upload: You're the controller, they process according to your instructions (processor relationship for this data)
• For data they provide: They're the controller of their database, licensing you access (controller-to-controller data sharing)
• For combined/derived data: This gets complex—the agreement needs to specify who controls what

Many GTM tools use hybrid agreements that address both the processor and controller-to-controller elements.

3. B2B Data Partnerships

When two companies share data to create joint value—combined analytics, shared insights, co-marketing—neither is typically acting as a processor for the other. Both have their own business purposes for the data.

Examples:

• A SaaS company sharing anonymized usage patterns with a research partner
• Two companies in a strategic partnership sharing customer overlap data
• A platform sharing seller data with a payment processor that uses it for fraud modeling

These are controller-to-controller relationships where each party must ensure it has a lawful basis for its own processing.

4. Professional Services Firms

Law firms, accounting firms, and consultants often function as independent controllers rather than processors. When you engage a law firm, you share information about your business, your employees, your counterparties. The law firm determines how to use that information to provide legal services—it applies its own professional judgment, maintains its own records, and has its own obligations.

The law firm isn't processing data "on your behalf" in the processor sense. It's providing professional services that require it to make independent determinations about data handling.

5. Payment Processors and Financial Services

Payment processors like Stripe, Adyen, or PayPal occupy an interesting position. When you integrate their services:

• They process transaction data to execute payments (arguably processor-like)
• They use transaction data for their own fraud prevention, risk modeling, and compliance (controller purposes)
• They're subject to their own regulatory obligations that require independent data handling decisions

Most payment processor agreements reflect this hybrid reality, with some data flows treated as processing on your behalf and others treated as independent controller activities.

Why the Distinction Matters

Accountability to Individuals

Under PIPEDA and GDPR, controllers are accountable to individuals for how their data is handled. If you're the controller, you're responsible for ensuring lawful processing, responding to access requests, and notifying about breaches—even for data processed by your processors.

In a controller-to-controller relationship, each controller is independently accountable for its own processing. You're not responsible for the other controller's compliance failures (though you may face reputational consequences from association).

Consent and Legal Basis

If you're a controller sharing data with a processor, your existing consent or legal basis covers the processor's handling (because they're acting on your behalf).

If you're a controller sharing data with another controller, the receiving controller needs its own legal basis. Your consent doesn't automatically extend to their purposes. This is why controller-to-controller agreements include provisions about each party's compliance responsibilities.

Instructions and Autonomy

Processors act on controller instructions. Controllers make independent decisions.

If you engage a vendor expecting them to follow your instructions precisely, and they're actually operating as an independent controller making their own determinations, you have a mismatch that creates risk. The vendor might use data in ways you didn't anticipate, and you won't have contractual recourse if those uses were within their legitimate controller purposes.

Agreement Structure

Processor agreements (DPAs) are inherently asymmetric—the controller directs, the processor obeys. Controller-to-controller agreements are between peers—each party has its own rights and obligations, and the agreement governs the interface between them.

Structuring Controller-to-Controller Agreements

When you've determined that a controller-to-controller relationship is appropriate, the agreement should address:

1. Data Flows

Specify exactly what data moves in which direction:

• What personal information does each party provide to the other?
• What derived data is created, and who controls it?
• What enrichment or combination occurs?

2. Purposes

Each party's permitted purposes should be explicit:

• What can Party A do with data received from Party B?
• What can Party B do with data received from Party A?
• Are there prohibited uses?

3. Legal Basis

Each party should represent that it has a lawful basis for:

• Disclosing data to the other party
• Processing data received from the other party

This doesn't mean each party guarantees the other's compliance—it means each party takes responsibility for its own.

4. Data Subject Rights

How do the parties coordinate on individual requests?

• If an individual asks Party A for access, and some of that data came from Party B, how is that handled?
• If an individual asks Party A for deletion, does Party A notify Party B?

5. Security Obligations

Even though neither party is directing the other's processing, both should commit to reasonable security measures. A breach at either party affects the shared data.

6. Breach Notification

How do parties notify each other of incidents affecting shared data? What are the timelines and procedures?

7. Liability

How is liability allocated for:

• Breaches of the agreement
• Third-party claims arising from each party's processing
• Regulatory actions

Controller-to-controller agreements often include mutual indemnification provisions rather than the one-way indemnities typical of DPAs.

The Hybrid Reality

Many vendor relationships don't fit neatly into controller or processor categories. The same vendor may be:

• A processor for some data (customer data you upload for them to process according to your instructions)
• A controller for other data (their own product improvement, aggregated analytics, fraud prevention)

Sophisticated agreements acknowledge this reality with provisions that address each data flow according to its proper characterization. The agreement might include:

• A DPA attachment for data processed on your behalf
• Controller-to-controller terms for data the vendor processes for its own purposes
• Clear delineation of which data falls into which category

Practical Guidance

When evaluating a new vendor or partner:

1. Map the data flows. What data goes where, and for what purposes? 2. Ask: Is this vendor acting on our instructions, or making independent determinations? 3. If the vendor has its own purposes for the data, it's at least partially a controller 4. Review their standard agreements—do they acknowledge their controller role, or do they try to disclaim all accountability? 5. Ensure the agreement structure matches the actual relationship

Red flags:

• A vendor that clearly operates as a controller but insists on a pure processor agreement (avoiding accountability)
• An agreement that doesn't address the vendor's own uses of data
• Lack of clarity about who handles data subject requests
• Processor agreements with vendors that obviously make independent decisions about data

For your own vendor agreements:

If you're a SaaS company and your processing involves independent purposes (product improvement, aggregated analytics, ML training), be transparent about it. Controller-to-controller framing for those uses is more accurate—and more defensible—than trying to squeeze everything into a processor box.

The Strategic Perspective

The controller-processor framework made sense when data processing was simpler: you hired a vendor to do a specific task with your data, and they did exactly that. Modern data ecosystems are more complex. Data flows through multiple parties, gets enriched and combined, and serves multiple purposes.

Companies that understand this complexity—and structure their agreements accordingly—reduce legal risk and build more sustainable data relationships. The goal isn't to avoid accountability by claiming everything is controller-to-controller. It's to accurately characterize each relationship so that accountability is properly allocated and everyone understands their obligations.

When controller-to-controller is the right framing, use it. When processor is right, use that. And when the relationship is genuinely hybrid, build an agreement that reflects reality.