Editor’s Note — DCC.
This brief adapts a case-driven analysis by 卢颖 (Lu Ying) and 张冰玢 (Zhang Bingbin), published June 29, 2026 on the 数据何规 account. The underlying dispute is the Shanghai appellate judgment (2024)沪01民终410号 — reported in Chinese court media as the Ou v. insurance company personal information protection dispute — in which a leaked online insurance policy forced the court to allocate responsibility across a broker, a platform operator, and an insurer under Article 20 of the Personal Information Protection Law. The facts and doctrinal argument below are the authors’; the framing for overseas readers is DCC’s.
The facts
A consumer (A) bought an insurance policy under the guidance of an insurance broker (B), by filling in her personal details on a website operated by a platform company (C). C transmitted the information to the insurer (D); D returned the issued policy to C, which delivered it to A.
Some time later, A searched her own phone number on a search engine — and got a direct link to a page on C’s website from which her policy, containing her detailed personal information, could be downloaded. A complained to the regulator; C changed the policy link and cut off the search result. A then sued B, C, and D together, seeking joint compensation.
How the analysis allocates the roles
C — the direct handler. C collected A’s information, the leaking link pointed to C’s own website, and C’s ability to kill the exposure by changing the link confirmed the information was under its control. C is a personal information handler (个人信息处理者) responsible for its processing activities and obliged to take necessary measures to keep the information secure.
B — a joint handler, jointly and severally liable. B and C had a business cooperation arrangement; B steered A to fill in her information on C’s website to complete the order. Nothing in the record showed B ever disclosed to A that the system was operated by C — to an ordinary consumer, the two companies presented the outward appearance of processing her information together. In B’s arrangement with D, B used C’s website as its own for internet-based sales; the two companies had an evident meeting of minds on collecting user information through C’s site and transmitting it to D, which amounts to jointly determining the means of processing. B is therefore a joint handler (共同处理者) and bears joint and several liability for the infringement of A’s rights.
D — not a joint handler. D merely authorized B to obtain applicants’ information. Its collection and receipt of A’s data served a relatively independent and reasonable purpose directly related to concluding the insurance contract; it had agreed personal-information-protection requirements with B, and it took no part in the downstream processing or the decisions about it. D falls outside the joint-handler perimeter.
The three identification factors
From the data flows, control points, and transmission arrangements in the case, the authors distill what to look at when identifying a joint handler:
- Common purpose and common conduct. The cooperation arrangement, the steering of the user into the partner’s system, and the use of the partner’s website as one’s own are the evidentiary building blocks.
- A pre-agreed division of roles can constitute “joint determination” of the downstream processing. B as business partner and C as system operator and transmission handler was a division of labor sufficient to conclude that the processing method was decided jointly. It does not matter how tasks are split across the stages — division of labor does not defeat joint-handler status.
- The appearance presented to the user counts. Tort liability is not normally assessed on outward appearance, but joint-handler analysis takes the objective cooperation relationship as an element — so what the ordinary user could perceive about who was processing her data is a legitimate factor.
The touchstone throughout is whether the parties jointly determined the purposes and means of processing. Conversely, multiple handlers working on the same shared dataset are not joint handlers if each pursues its own independent purpose.
Joint processing vs. sharing vs. entrusted processing
The article separates three neighboring concepts that multi-party data arrangements tend to blur:
- Sharing (共享). Provider and recipient are each independent handlers with no subordination; each may process for its own purposes. When infringement occurs, each party answers for its own fault — no automatic joint liability.
- Entrusted processing (委托处理). The entrusted processor has no processing purpose of its own; it acts entirely on the entrusting handler’s instructions and must return or delete the information when the engagement ends. Liability toward the individual sits with the entrusting handler, which may seek recourse against a defaulting entrustee.
- Joint processing (共同处理). Two or more handlers jointly determine purposes and means — and under PIPL Article 20(2), infringement liability is joint and several.
The doctrinal move: Article 20(2) as a claim basis
The authors’ closing argument goes beyond the case. Under the traditional joint-tort framework (now codified in the Civil Code), joint infringement requires plural tortfeasors, joint conduct — by common intent, common negligence, or objectively combined acts producing a single indivisible harm — and causation.
PIPL Article 20(2), they argue, is not merely a restatement of that framework for personal information. It is a special rule added onto it: because information flows through networks in ways that make it practically impossible for a victim to isolate which participant’s act caused the leak, the statute lets joint-handler status itself establish the joint character of the infringement. Being a joint handler is an objective, neutral description of a normal cooperation structure — not itself wrongdoing — but once infringement occurs within the jointly determined processing, Article 20(2) operates as an independent claim basis (请求权基础): the victim may sue all joint handlers for joint and several damages directly, without reconstructing the traditional joint-tort elements actor by actor.
What compliance teams should take from it
- Map every multi-party chain against the three factors. Broker/platform/ underwriter is the fact pattern here, but the same structure appears in co-branded apps, embedded storefronts, white-labeled booking systems, and agency sales. If your partner’s system collects data while presenting your brand, factor 3 is already against you.
- Disclose who operates the system. B’s decisive problem was that the consumer was never told the website belonged to C. A visible, documented disclosure of the actual system operator is cheap insurance against the appearance element.
- Contract design can keep you out of the perimeter — if it matches reality. D stayed outside joint-handler status by combining an independent contract-related purpose, agreed PI-protection requirements, and genuine non-participation in downstream processing decisions. That combination is replicable — but only if the operational facts match the paper.
- Joint and several means the deepest pocket pays first. Under the Article 20(2) claim-basis reading, a plaintiff can collect the whole judgment from whichever joint handler is easiest to reach and leave contribution to be sorted out afterward. Price that into partner due diligence.
— 卢颖、张冰玢 (Lu Ying, Zhang Bingbin), 如何厘清个人信息共同处理责任 (How to Untangle Joint Processing Responsibility for Personal Information), published via the 数据何规 WeChat Official Account, June 29, 2026. Original article (Chinese).
Not legal advice. Case details follow the authors’ anonymized account of judgment (2024)沪01民终410号; the judgment is authoritative.