Data Controller vs. Data Processor Requirements Under GDPR

GDPR: Controller vs. Processor Responsibilities

The controller/processor distinction sounds like a clean binary, but Article 28 has a specific trap worth understanding before anything else: a processor that decides, on its own, to use personal data for a purpose the controller didn't instruct — even informally, even with good intentions — becomes a controller for that specific processing activity, and loses the more limited liability that comes with being "just" a processor. The distinction isn't about job title or contract language; it's about who actually determines the purpose and means of processing, activity by activity.

The Core Distinction, Precisely

A controller determines the purposes and means of processing — why the data is being processed and how, at a meaningful decision-making level. A processor acts strictly on the controller's documented instructions, with no independent decision-making authority over why or how the data is used. The distinction is functional, not contractual: calling yourself a processor in an agreement doesn't make you one if you're actually making independent decisions about data use.

Joint Controllers: A Third Category Your Binary Framing Misses

GDPR's Article 26 recognizes a third arrangement: joint controllers, where two or more parties jointly determine the purposes and means of processing — common in platform-and-partner setups, ad tech, and shared data ventures. Joint controllers have to transparently and explicitly agree on their respective responsibilities, particularly for handling data subject rights requests and providing required information to individuals, documented in an arrangement available to data subjects. Treating every multi-party relationship as a simple controller-processor pair when it's actually joint controllership is a common structural mistake — and one that can leave data subject rights obligations unclear between the parties when it matters most.

What Controllers Must Actually Do

Beyond the general obligations, Article 24 makes controllers responsible for demonstrating compliance — not just achieving it, but proving it on request. In practice, this means:

• Lawful basis documentation — a defensible legal ground for every processing activity, not asserted after the fact but determined and recorded before processing begins

• Data subject rights fulfillment — access, erasure, rectification, and other rights requests handled within GDPR's required timelines

• DPIAs where required — Article 35 mandates a Data Protection Impact Assessment specifically for processing likely to result in high risk to individuals, not for every processing activity

• Processor due diligence — Article 28(1) places an affirmative duty on the controller to vet processors before engaging them, including reviewing the processor's security policies, audit reports, and certifications (ISO 27001 and SOC 2 reports are commonly used as part of this evidence), not just accepting a processor's word that it's compliant

What Processors Must Actually Do, Per Article 28(3)

The regulation specifies eight things a controller-processor contract must require of the processor, not as a flexible suggestion but as the legally mandated minimum content of a Data Processing Agreement:

1. Process personal data only on the controller's documented instructions — including for international transfers, with an obligation to flag if an instruction appears to violate GDPR

2. Ensure personnel handling the data are bound by confidentiality

3. Implement appropriate security measures consistent with Article 32

4. Respect the conditions for engaging sub-processors — specifically, obtaining the controller's prior specific or general written authorization before bringing in any sub-processor, not just informing them after the fact

5. Assist the controller in responding to data subject rights requests

6. Assist the controller with security obligations, breach notification, DPIAs, and prior consultation with supervisory authorities

7. Delete or return all personal data at the end of the service, per the controller's choice

8. Make available all information necessary to demonstrate compliance, and allow for audits

The Sub-Processor Chain

If a processor engages a sub-processor, the same data protection obligations have to flow down through a contract or legal act — and critically, the original processor remains fully liable to the controller for the sub-processor's performance, even though the sub-processor has its own direct obligations. This creates a chain of accountability that doesn't break just because work was delegated further down.

Records and Audits Aren't Optional Formalities

Article 30 requires both controllers and processors to maintain a Record of Processing Activities — and Article 28(3)(h) specifically requires processors to allow for and contribute to audits the controller (or an auditor the controller designates) conducts to verify compliance. A controller that never exercises this audit right, or a processor that resists reasonable audit requests, is creating exactly the kind of unverified compliance gap that surfaces badly if a regulator investigates later.

Why This Distinction Matters Operationally

Getting controller/processor classification wrong has real consequences: a vendor mistakenly treated as a processor when it's actually exercising controller-level decisions about data use may be operating without the lawful basis a true controller needs to establish. Conversely, a controller that assumes a vendor relationship absolves it of responsibility because "the processor handles security" misunderstands Article 24 — the controller's accountability for GDPR compliance doesn't transfer away just because processing is outsourced.

Building This Into a Multi-Framework Program

A well-drafted Data Processing Agreement, covering all eight Article 28(3) elements, tends to overlap substantially with the vendor security and due diligence documentation ISO 27001 and SOC 2 already require — both frameworks expect similar vendor risk assessment and contractual flow-down for third parties handling sensitive data. Organizations managing all three can often build one due diligence and contracting process that satisfies GDPR's Article 28 requirements alongside the other two frameworks' vendor management expectations, rather than maintaining separate parallel vendor review processes.