Controller, Processor or Joint Controller?

The role dictates the document. Controller to processor requires a binding written contract containing the Article 28(3) mandatory clauses: process only on documented instructions, confidentiality, security measures, sub-processor authorisation, assistance with rights and breaches, and return or deletion at the end.

Controller to controller, including joint controllership, does not use Article 28 terms. Instead you need a written arrangement allocating responsibilities: who tells the individual what, who answers subject access requests, who notifies breaches, how queries get routed. For joint controllers this transparency arrangement is a legal requirement, not good practice.

A frequent real-world error is a firm sending its standard processor terms for every instruction, including ones where the investigator plainly exercises controller discretion. The mismatch does not change the legal reality; it just guarantees the paperwork contradicts it.

Before sending an instruction, run it through five quick questions. The pattern of answers tells you the role, and the Code Member on the other side should reach the same conclusion independently.

• Purpose. Did we define exactly why this data will be processed, or does the agent shape the objective?
• Scope. Have we specified whose data and which data types, or will the agent decide who falls within the enquiry?
• Sources and methods. Are the sources fixed by us in detail, or chosen through the agent's professional judgement?
• New information. If something unexpected surfaces, must the agent revert to us, or may they pursue it?
• Retention. Do our instructions govern how long material is kept, or does the agent apply its own policy?

All answers on the left: processor, paper it with Article 28 terms. Answers drifting right: controller or joint controller, paper it with a responsibilities arrangement. Mixed answers are normal, one engagement can involve both roles for different activities.

Roles attach to processing activities, not to companies. The same investigator can be your processor for one activity and a controller for another, sometimes over the very same data, and the Code expects members to keep the two clearly separated.

Its example: an agent traces a debtor with wide discretion, acting as controller. The debt is sold, and the purchaser sends tightly specified trace instructions, naming systems and data points. For the new work the agent is likely a processor. Same subject, same agent, different role, because the facts changed.

Retention for audit shows the same split. An investigator holding closed-case data for its own quality or accreditation audits is controller of that retained copy, even if it was a processor when gathering it. Precision here is not pedantry; it determines which contract clause and which liability rules bite on which activity.

The classic failure is assuming our agent equals our processor. A subject access request arrives at the investigator, who assumes the law firm will deal with it; the firm assumes the reverse. The statutory deadline passes while everyone waits, and a routine request becomes a complaint.

Breaches expose the same gap under worse pressure. A processor must notify its controller without undue delay; a controller must assess and, where required, notify the ICO within 72 hours. If nobody established who is who, that clock runs out during the argument.

Liability follows the reality. Individuals can claim against a controller for its processing, and against a processor that breached its own duties or exceeded instructions. An investigator who quietly exceeded processor instructions has become a controller for that excursion, with full controller exposure, and the ICO can enforce against either party. Labels on paper rescue no one.

Everything above compresses into a few habits at the point of instruction. State the purpose in a sentence. Decide how much discretion you are granting, and say so. Expect the investigator's engagement letter to declare its role, the Code requires members to do exactly that before accepting work, and check it matches your own analysis.

Then attach the right paper: Article 28 terms for processor work, a responsibilities arrangement for controller or joint controller work, or both where an engagement mixes activities. Confirm the practical routings while you are there: where SARs go, who calls whom on a breach, what happens to the file at the end.

Done once, this becomes a template you reuse on every instruction. At Tremark the role conversation is built into onboarding, because a client who knows exactly where responsibility sits is a client whose evidence, and whose file, survives scrutiny.