A joint controller is an organisation that shares responsibility for deciding why and how personal data is processed. Each party remains accountable for GDPR obligations within the shared activity, including transparency, lawful basis, security, and data subject rights, even if operational tasks are distributed across different entities.
Expanded Definition
A joint controller is not simply a vendor relationship or a delegated processing arrangement. It exists where two or more organisations jointly determine the purposes and essential means of personal data processing, which means the allocation of tasks does not remove shared accountability under GDPR. The concept is distinct from a controller and processor model because each joint controller influences the core decisions that shape the processing activity, even when one party operates the platform, consent flow, or customer-facing interface. Guidance varies across regulators on how granular the division of responsibility must be, so organisations should rely on documented arrangements rather than assumptions about who “owns” the data flow. The practical test is whether each party can influence why the data is collected and how it is used, not whether both entities touch the same system.
For security and governance teams, the most important point is that joint control creates overlapping obligations for transparency, security safeguards, and response handling. That makes the arrangement more complex than a standard outsourced processing model and requires clear accountability mapping, especially where identity data, behavioural data, or analytics are involved. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it reinforces that governance and control ownership must be explicit, measurable, and continuously maintained. The most common misapplication is treating a commercial partner as a processor when both parties actually shape the purpose and essential means of processing, which occurs when contract language is used to override operational reality.
Examples and Use Cases
Implementing joint controller arrangements rigorously often introduces coordination overhead, requiring organisations to weigh regulatory clarity against slower decision-making and more complex incident handling.
- A retailer and a payment analytics provider jointly decide what transaction data is collected, how it is segmented, and how long it is retained for fraud analysis.
- A parent company and a regional subsidiary both determine the purposes of a shared customer identity platform, even if one entity runs the infrastructure and support processes.
- A publisher and an advertising partner co-determine tracking and profiling rules for audience measurement, which creates shared obligations for notice and lawful basis.
- A healthcare network and a platform operator jointly define how patient portal data is used for authentication, access analytics, and service improvement.
- A SaaS provider and a customer success partner both influence the design of in-app telemetry that supports product analytics and targeted outreach.
In each case, the question is not who performs the technical task, but who decides the processing purpose and the essential design choices. Organisations should document the division of responsibilities, especially for security notices, rights requests, retention, and breach coordination, and align that documentation with authoritative privacy and security guidance such as the NIST Cybersecurity Framework 2.0.
Why It Matters for Security Teams
Joint controller status matters because it prevents accountability gaps that can emerge when multiple teams assume another party is handling privacy obligations. If a security incident exposes personal data, both parties may need to support impact assessment, notification decisions, evidence preservation, and remediation. That has direct implications for IAM, logging, access governance, and third-party oversight, particularly where identity attributes are shared across ecosystems. For NHI-heavy environments, joint control can also appear in API-driven data exchanges and federated identity journeys, where multiple organisations influence how identity-linked data is used even without direct employee access. The security question is not only whether access was protected, but whether each controller had appropriate governance over the shared processing purpose. GDPR obligations, internal control maps, and contractual clauses all need to point to the same operational reality. The clearest way to understand the risk is through incident response: when a breach or rights request arrives, vague responsibility splits become immediately visible and expensive to unwind. Organisati ons typically encounter the cost of joint controller ambiguity only after a complaint, audit, or breach notice, at which point the arrangement becomes operationally unavoidable to resolve.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, while EU AI Act and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Defines governance and risk ownership expectations relevant to shared controller accountability. |
| NIST SP 800-63 | Identity assurance guidance is relevant where joint controllers share identity-linked data flows. | |
| NIST AI RMF | AI RMF is relevant when joint controllers govern profiling or automated decision workflows. | |
| EU AI Act | Regulatory governance concepts help when joint control includes automated profiling or AI features. | |
| DORA | Operational resilience obligations matter when shared processing affects regulated financial services. |
Ensure incident coordination and resilience roles are defined across all jointly controlling parties.
