GDPR Data Controller vs. Processor

Under GDPR Article 4, a Data Controller is the entity that determines the purposes and means of processing personal data; a Data Processor is an entity that processes personal data on behalf of a controller. This distinction is not determined by contract language — it reflects factual reality about who has decision-making power over the why and how of processing. A cloud provider that processes customer data strictly according to customer instructions is a processor; a SaaS analytics vendor that uses customer data for its own product improvement is also acting as a controller for that secondary processing. Joint Controllers arise when two or more entities jointly determine purposes and means, requiring a documented arrangement under Article 26. Misidentifying one's role as controller, processor, or joint controller has direct consequences: processors have significantly narrower obligations than controllers but cannot rely on controller justifications for their own processing decisions.

Engineering systems for GDPR compliance requires architecting around the controller/processor boundary at the data flow level. Processing agreements (DPAs) under Article 28 must be in place for every controller-to-processor relationship, and they must specify the subject matter, duration, nature and purpose of processing, type of personal data, categories of data subjects, and controller obligations and rights. Processors may only engage sub-processors with prior written authorization (specific or general), must impose the same DPA terms on sub-processors (Article 28(4)), and are directly liable to data subjects for damages caused by sub-processor failures where they bear responsibility. This sub-processor chain must be technically traceable: a complete data lineage map showing personal data flows from controller through processor to sub-processor is essential for DPA compliance, supervisory authority inquiries, and incident response.

A frequently misunderstood nuance is that processors who act outside controller instructions become controllers for that processing — and incur full controller liability. This matters practically for AI and analytics vendors who use client data to train models or benchmark performance, even with pseudonymization applied. The EDPB's guidance on controller and processor concepts (Guidelines 07/2020) clarifies that processors must not use personal data for their own purposes, must implement only controller-instructed retention and deletion, and must not transfer data to additional recipients without controller authorization. Architects designing multi-tenant SaaS platforms must therefore implement strict data segregation controls that prevent customer data from informing platform-wide decisions — model training pipelines, aggregate benchmarks, and product telemetry must be carefully scoped to avoid inadvertent controller status for tenant data.

We conduct controller/processor role assessments across your entire vendor and partner ecosystem, producing a classification matrix that identifies misaligned DPAs, undisclosed sub-processor relationships, and processing activities where vendors have assumed controller status without authorization. Our data architecture reviews enforce controller/processor boundaries in system design — tenant data isolation controls, model training data governance policies, and telemetry scoping — before deployment rather than as post-hoc remediation. DPA obligation tracking is embedded in vendor management workflows with automated alerts when sub-processor changes require controller notification.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.