Controller vs. Processor: Classification & Contract Governance under PDPL

A recap of the Pyxos masterclass with Muneeb Imran.

Most privacy teams treat the controller-or-processor question as a box to tick once a contract is drafted. Muneeb Imran spent this session arguing the opposite: the label is a risk decision, and getting it wrong does not announce itself until the architecture cracks years later, usually during a breach or an audit, when it is most expensive to repair.

His central move is to read the law for its spirit rather than its surface. The Saudi Personal Data Protection Law (PDPL) exists to protect the rights and interests of data subjects, and that purpose, not the wording of a signed agreement, is what a regulator measures a relationship against. Two competent privacy officers can reach complete consensus on who is the controller and who is the processor and still be wrong, because consensus is not the same as a correct determination. What governs is operational reality: who actually decides why and how personal data is processed, where the data flows, and who holds the decision-making power.

The distinction Imran kept returning to is choice. A controller has it. It decides the purpose, which is the lawful basis, and the essential means. A processor does not. It acts on documented instructions and looks after the technical layer of how, the encryption, the hosting, the tokenization, without setting the purpose. He offered a memorable image: the controller is the nerve center, the processor the muscular power. The test sharpens when a law compels one organization to hand data to another. If the sharing is mandated, it is not an act of choice, so it does not by itself make the sender a controller or the recipient a processor.

That is where the roles the law does not name earn their keep. The PDPL and its Implementing Regulations define only controller and processor, yet the transfer rules and standard contractual clauses recognize controller-to-controller arrangements. Treating joint controller and independent controller status as deliberate options, Imran argued, is a risk-mitigation instrument. Forcing a larger party, or one answering to a different regulator such as the Communications, Space and Technology Commission while you answer to SAMA, into a processor role tends to fail in practice: in a breach, that party will satisfy its own regulator before it honors your data processing agreement. He worked the point through familiar Saudi settings, from medical insurers whose data necessarily travels onward to hospitals and clinics across the Kingdom, to the credit information regime, where a controller-to-controller relationship is the honest description of how the data actually moves.

The economics carry the same logic. Every processor an organization accepts enlarges the compliance landscape it answers for, and accepting processor status oneself means inheriting a controller's obligations, its audit rights, and its remediation timelines. That trade only makes sense when the commercial benefit clearly outweighs the burden. Classification, then, is fact-based work that belongs to the privacy function, drawing on legal, compliance, IT, security and the business, and it does not end at signature. Relationships evolve, subprocessors appear, AI is introduced, and a vendor that starts making independent decisions on the means of processing has quietly become a controller.

The full classification method and the contract-governance toolkit, including the Article 17 requirements and the due-diligence and audit steps that sit around them, are best taken from the recording and the takeaways.

Imran's underlying claim is that privacy should come last in the analysis, not first. Examine the business, the money and the risk honestly, and the correct classification tends to reveal itself. Decide the label first and defend it afterward, and you are building on an assumption you never tested.