What is an example of joint controllership in practice?

How joint controllership works in practice

joint controllership is most useful to understand as a shared decision-making arrangement, not as a purely contractual label. In practice, the joint controllers are both involved in deciding the purpose and essential means of the processing, even if they do not contribute equally or do the same tasks. That means the arrangement should map real responsibility, not just legal language.

For a shared service or campaign, the practical test is whether each organisation influences why the data is collected and how it is used. If one party sets the audience, retention, security baseline, and contact strategy, while the other supplies the platform or distribution channel, both may still be joint controllers for the processing that serves the shared objective.

A transparent arrangement usually separates operational tasks from accountability. One party may handle privacy notices, another may respond to data subject requests, and both may need to align on retention, lawful basis, and security controls. The point is to make the division of labour understandable to the data subject and workable in day-to-day operations, not to pretend only one party is responsible.

What makes a joint controller relationship different from a controller-processor setup?

The key difference is control over the purpose and essential means. A processor acts on instructions, while joint controllers make the high-level decisions together. If a partner can materially shape the campaign logic, customer journey, or data use, the relationship may move beyond processor status even if the operational work is outsourced.

That distinction matters because the obligations are different. In a joint controllership model, both parties must think about transparency, lawful basis, and how individuals can exercise rights. If the relationship is misclassified, one party may believe it has delegated responsibility when, in law and practice, it still shares accountability for the processing decisions.

For governance teams, the most useful question is not “Who hosts the system?” but “Who decides what happens to the personal data?” A vendor can be a processor for one activity and a joint controller for another, depending on whether it merely executes instructions or helps determine the processing purpose and means.

Which responsibilities should the arrangement make explicit?

A sound joint controller arrangement should make the shared duties concrete enough that teams can operate without ambiguity. The areas that usually need the clearest allocation are privacy notices, rights handling, recordkeeping, retention, and security responsibilities. If these are left vague, the arrangement becomes hard to defend and even harder to run.

Security duties are especially important because data protection failures often arise at handoff points. Even where one party runs the platform and another runs the campaign, both should understand who sets access rules, who reviews incidents, and who coordinates breach response. For a practical treatment of the security side of processing, see GDPR Compliance Guide for Security Teams.

If the arrangement spans multiple systems or service providers, the partners should also align on evidence. That includes who can show the lawful basis, who can demonstrate notice content, and who can prove that security and transfer safeguards were in place when the processing began.

Risk and Threat Considerations

Joint controllership creates shared accountability, but shared accountability can fail in practice if the parties assume the other side is covering notices, rights requests, or security controls. The most common exposure is not malicious abuse by itself, but operational gaps at the boundary between two organisations that both believe they have complied.

Failure mechanism: The arrangement is poorly defined, so notices, consent logic, rights handling, retention, or security controls are duplicated, omitted, or applied inconsistently across the shared processing activity.

Impact: Individuals may receive incomplete transparency, rights requests may be mishandled, and security or breach response duties may be delayed or missed. That can create compliance exposure for both parties and make it harder to defend the processing if challenged by a regulator or a data subject.

Practitioner Guidance

What to verify: Confirm that the written arrangement matches the actual decision-making model. If both organisations influence the purpose or essential means, do not rely on a processor-style contract to cover joint-controller behaviour.

Decision rule: If a duty affects the data subject directly, such as notice content or rights handling, name the responsible party and the coordination path. If a duty affects both organisations’ exposure, such as security or incident escalation, define the shared minimum standard and the escalation trigger.

What practitioners underestimate: The hardest part is usually not drafting the arrangement, but keeping it aligned as the service, campaign, or vendor stack changes. A relationship that starts as a simple collaboration can become jointly controlled through later product, audience, or analytics decisions.

Practitioner takeaway: Treat joint controllership as an operating model with shared accountability, not a paperwork exercise. If the organisations jointly decide why data is used and how it is processed, the arrangement should make those shared decisions and their consequences visible, testable, and revisable.

Related resources from NHI Mgmt Group

• What is an example of HUMINT in cyber practice?
• What is an example of third-party cookie deprecation in practice?
• What is an example of agentic AI risk in practice?
• What is an example of seccomp in practice?