Joint PII controller

To meet the joint PII controller requirement, you must identify when your organization and another party jointly decide the purposes and means of processing personal information, then document a clear arrangement that assigns responsibilities. That arrangement must cover who handles data subject rights and how requests are coordinated and answered. ¹

Key takeaways:

• Treat “joint controller” as an operating model decision, then document it in writing with role clarity. ¹
• Your arrangement must explicitly allocate responsibility for PII principal rights handling, not just security or commercial terms. ¹
• Audits fail most often because the contract exists, but the actual workflow for rights requests and accountability is missing or untested. ¹

“Joint PII controller” issues show up in real programs whenever two organizations co-own a product, platform, dataset, or customer journey. Examples include co-branded offerings, shared loyalty programs, marketplace models, ad-tech measurement, and benefit administration where both parties determine why data is processed and how it is processed.

ISO/IEC 27701:2019 Clause 7.2.7 requires a documented arrangement that defines the respective responsibilities and roles of joint PII controllers, including responsibilities for exercising the rights of PII principals. ¹ For a CCO or GRC lead, the fastest way to operationalize this is to (1) decide whether the relationship is truly “joint controller,” (2) memorialize roles in an executed agreement, and (3) build an intake-and-routing workflow for rights requests that matches the agreement and can be evidenced during audit.

This page gives requirement-level guidance you can implement immediately: decision criteria, contract clauses to insist on, operating procedures to stand up, and the artifacts auditors ask for.

Regulatory text

Requirement (verbatim): “The organization shall determine the respective responsibilities and roles of joint PII controllers by a documented arrangement, including responsibilities for exercising the rights of PII principals.” ¹

Operator interpretation: If you and another controller jointly determine the purposes and means of PII processing, you must put in writing who does what. The arrangement has to cover day-to-day privacy operations (especially rights requests), not only high-level statements of cooperation. ¹

Plain-English meaning (what this forces you to decide)

• Are we joint controllers? Do both parties meaningfully decide why the PII is processed and how it will be processed (key systems, disclosures, retention logic, audiences, etc.)?
• If yes, who owns each obligation? The standard expects clarity on responsibilities and roles, with explicit allocation for PII principal rights handling. ¹

Who it applies to

Entity scope

• PII controllers that have relationships where processing decisions are shared with another controller. ¹

Operational contexts where joint controllership commonly appears

Use this as a triage list for your third-party and partner inventory:

• Co-branded products where both parties define customer eligibility, communications, and analytics.
• Platforms/marketplaces where the platform and seller decide what buyer data is collected and how it’s reused.
• Shared marketing initiatives where both parties define targeting/measurement parameters.
• Data sharing arrangements where both parties define secondary uses (for example, personalization and product improvement).

What you actually need to do (step-by-step)

Step 1: Identify candidate relationships (build a short list)

Pull a list from:

• Third-party contracts tagged “data sharing,” “partner,” “reseller,” “marketing,” “analytics,” “co-brand.”
• System integrations where PII flows both directions.
• Any arrangement where both parties publish privacy disclosures to the same end users.

Deliverable: “Joint controller candidates” register entry for each relationship (even if the decision is “not joint”).

Step 2: Make a defensible joint-controller determination

Document the reasoning using a consistent set of questions:

1. Who decides the purpose(s) of processing (business objective, allowed uses)?
2. Who decides the means (collection fields, core systems, sharing endpoints, retention triggers, access model)?
3. Can either party unilaterally change purposes/means without the other’s approval?
4. Who interfaces with the PII principal (notices, consent, account portal)?
5. Who can fulfill rights requests end-to-end without the other party?

Decision output:

• Joint controllers → proceed to Step 3.
• Independent controllers (separate purposes) → document separation and interface points.
• Controller/processor → route to your processor clause set and DPA workflow.

Exam focus: Auditors want to see the decision was intentional and repeatable, not an afterthought.

Step 3: Draft and execute the “documented arrangement”

This can be a standalone agreement or addendum, but it must be documented and assign responsibilities and roles with explicit rights handling. ¹

Minimum topics your arrangement should cover (make these headings in the document):

• Scope of joint processing: define in-scope products, systems, and PII categories at a practical level.
• Role allocation matrix (RACI-style): who owns notice, lawful basis/authorization decisions (if applicable to your regime), collection points, disclosures, retention, security responsibilities, sub-disclosures, breach coordination, and recordkeeping.
• PII principal rights operations: who is the “front door” for requests, how requests are routed, required response inputs, identity verification responsibilities, exceptions handling, and final response ownership. ¹
• Coordination mechanics: operational contacts, escalation paths, response time expectations (avoid hard numbers unless you align to your governing law and can meet them), and dispute resolution.
• Transparency alignment: how you ensure privacy notices and user-facing statements remain consistent across both parties.
• Change control: how product and processing changes get privacy review and trigger updates to the arrangement.

Practical tip: Put the rights workflow in an appendix with a swimlane diagram. Auditors accept a contract, but they trust a contract plus a tested workflow more.

Step 4: Operationalize rights requests (build the runbook)

Your arrangement must include responsibilities for exercising rights, so your internal process has to match it. ¹

Implement:

• Intake: central email/webform/ticket queue for rights requests.
• Classification: identify whether the request touches joint processing, which joint-controller partner is involved, and what data stores are implicated.
• Routing: assign tasks to each party per the arrangement (who pulls data, who deletes, who responds).
• Response assembly: define who sends the final response to the PII principal, and how the other party reviews for accuracy.
• Evidence logging: keep the request, steps taken, communications, and closure notes in a system of record.

Step 5: Train and test the joint-controller workflow

Run table-top exercises with the partner and your internal teams:

• A request that spans both parties’ systems.
• A request where identity verification is incomplete.
• A request that triggers exceptions (legal hold, fraud, security).

Evidence target: proof the workflow works, not just that it exists.

Required evidence and artifacts to retain

Auditors generally expect:

• Executed documented arrangement identifying respective responsibilities and roles. ¹
• Joint controller determination memo (why joint vs not joint).
• RACI / responsibility matrix tied to actual systems and processes.
• Rights request SOP and routing rules that map to the arrangement. ¹
• Operational contact list and escalation path shared with the partner.
• Change management records showing privacy review when processing changes.
• Sample rights request case files (redacted) showing coordination between controllers.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you decide a relationship is joint controllership.”
• “Where is the documented arrangement, and where does it assign responsibilities?”
• “Who owns data subject rights responses for joint processing, and how do you coordinate?” ¹
• “Does your operational process match the arrangement, or is the agreement aspirational?”
• “How do you keep notices and user communications consistent across both parties?”

Hangups that cause findings:

• The contract is silent on rights requests.
• The contract allocates responsibilities, but teams cannot execute (no routing, no contacts, no runbook).
• The relationship changed (new use case, new integration) and the arrangement was not updated.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating every data-sharing contract as controller/processor.
   Fix: run the joint-controller determination questions and document the outcome.

2. Mistake: vague “each party is responsible for complying with applicable law” clauses.
   Fix: convert to a role-by-role allocation, including rights request handling responsibilities. ¹

3. Mistake: assuming the customer-facing party owns all rights requests.
   Fix: specify which party verifies identity, searches which systems, applies deletions, and who sends the response.

4. Mistake: no evidence trail for coordination.
   Fix: require ticketing references in partner communications and keep them with the request record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement examples.

Operationally, joint controllership failures create predictable risk:

• Rights requests fall between two organizations, leading to delayed or incomplete responses.
• Inconsistent notices and disclosures occur when each party describes the shared processing differently.
• Incident response confusion happens if the arrangement does not spell out coordination and roles.

ISO/IEC 27701’s control intent here is auditability: a documented arrangement that reflects actual operations, with clear responsibility for PII principal rights. ¹

Practical execution plan (30/60/90)

Because no time-to-implement benchmarks were provided in the source catalog, treat the plan below as a sequencing guide and adjust to your governance cadence.

First 30 days (Immediate)

• Inventory candidate joint-controller relationships from contracts and integrations.
• Create a standard joint-controller determination template and decision log.
• Select one high-impact relationship and draft a documented arrangement outline with rights workflow headings. ¹

By 60 days (Near-term)

• Execute the documented arrangement (or negotiate to signature-ready status) for priority relationships.
• Stand up the rights request routing workflow in your ticketing system, mapped to the arrangement.
• Train privacy ops, support, legal, and the partner-facing team on intake and escalation.

By 90 days (Operationalized)

• Run a joint table-top for rights requests and capture evidence.
• Expand the arrangement pattern to other joint-controller relationships.
• Add a change-control trigger so new joint processing requires review and arrangement updates.

Tooling note (where Daydream fits)

If you track third-party relationships, privacy obligations, and rights request workflows across multiple systems, Daydream can act as the system of record for (a) joint-controller determinations, (b) executed arrangements and role matrices, and (c) evidence packs mapped to ISO/IEC 27701 Clause 7.2.7 for audit readiness. ¹

Frequently Asked Questions

How do I know if we are a “joint PII controller” versus separate controllers?

Treat it as a decision about who determines the purposes and means of processing. If both parties meaningfully decide why and how PII is processed for the shared activity, document it as joint controllership and assign roles in a written arrangement. ¹

Can the documented arrangement be an addendum to a broader commercial agreement?

Yes, as long as the responsibilities and roles are clearly determined in a documented arrangement, including responsibility for exercising PII principal rights. Put the operational details in an appendix if the main agreement is owned by procurement or partnerships. ¹

Do we need to name a single party to respond to rights requests?

ISO/IEC 27701 requires that the arrangement include responsibilities for exercising rights; it does not mandate one model. Choose a “front door” that matches the customer journey, then spell out how the other party supports searches, deletions, and exceptions. ¹

What’s the minimum evidence an auditor will accept?

An executed arrangement that assigns respective responsibilities and roles, plus proof your rights request workflow follows it. Keep a small set of completed request files showing coordination steps and accountability. ¹

What if the partner refuses to sign a joint controller arrangement?

Escalate as a launch blocker for the shared processing activity. Without a documented arrangement allocating roles, you cannot satisfy ISO/IEC 27701 Clause 7.2.7 for joint controllership, and your rights-handling process will be fragile in practice. ¹

How often should we revisit joint-controller arrangements?

Revisit whenever the shared processing changes in purpose, data categories, systems, disclosures, or user experience. Tie updates to product change control so the arrangement stays aligned with reality and remains auditable. ¹

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management