Data Protection Roles and Principles: Controller, Processor and Lawful Basis

Data protection law appears on security exams as vocabulary and accountability rather than as legal detail. The terms are consistent across regimes even where the specifics differ, and knowing who is responsible for what is the part that affects how systems are built.

Controller and processor

The distinction everything else hangs on.

A controller determines the purposes and means of processing — why the data is collected and how it will be used. The controller is accountable for compliance and is who a regulator and a data subject deal with.

A processor processes data on the controller's behalf, following instructions. A cloud provider hosting a customer's database is typically a processor; the customer is the controller.

The exam point: accountability does not transfer to the processor. Engaging a processor does not move responsibility, which is the same reasoning as under the cloud shared responsibility model and under supply chain security. A controller must contract appropriately, assess the processor, and remains answerable when the processor fails.

Two further roles: the data subject is the person the data is about, and a data protection officer is the designated independent role required of some organizations.

The principles

Consistent across regimes and worth knowing by name, because they explain design requirements.

Lawfulness, fairness and transparency — there must be a lawful basis and people must be told what happens to their data. Purpose limitation — collected for a stated purpose and not repurposed without a basis. Data minimisation — collect only what is necessary, which is a design constraint rather than a policy statement. Accuracy. Storage limitation — retained no longer than needed, which means retention schedules and deletion that works. Integrity and confidentiality — the security principle. And accountability — being able to demonstrate compliance rather than merely assert it.

Minimisation and storage limitation are the two that most often conflict with how systems are actually built, because collecting everything and keeping it forever is the default behaviour of most architectures.

Lawful basis

Processing requires one, and consent is only one option among several — the common misconception being that consent is always needed.

The bases are consent, performance of a contract, a legal obligation, vital interests, a public task, and legitimate interests. Most ordinary business processing rests on contract or legitimate interests rather than consent, and consent carries the strongest conditions: it must be freely given, specific, informed and as easy to withdraw as to give.

Subject rights

People can request access to their data, correction of inaccuracies, erasure in defined circumstances — the right to be forgotten, which is qualified rather than absolute — restriction of processing, portability in a machine-readable format, and objection to certain processing including profiling.

The operational consequence is what matters for system design. Responding to these within the statutory timeframe requires knowing where personal data lives, being able to retrieve all of it for one individual, and being able to delete it — including from backups, logs and analytics systems, which is where it becomes genuinely difficult.

An organization that cannot enumerate where personal data resides cannot satisfy these rights, which is the inventory problem again.

Breach notification and DPIAs

A personal data breach generally requires notification to the regulator within a short fixed window — commonly 72 hours — measured from awareness rather than from conclusion of the investigation. Where risk to individuals is high, they must be told too.

That clock is the reason legal and communications belong in the incident process from the start rather than at the end, with the triggers written into the playbooks in hours.

A data protection impact assessment is required before high-risk processing — large-scale monitoring, sensitive categories, new technologies — and it is essentially a risk assessment scoped to individuals rather than to the organization, feeding the same risk register.

Cross-border transfer and other regimes

Transferring personal data outside its jurisdiction requires a lawful mechanism — an adequacy decision, standard contractual clauses, or binding corporate rules — which is why data residency appears as a cloud requirement and why region selection is a compliance decision rather than a performance one.

Regimes differ. Some are consent-based and comprehensive, some sectoral, and some create obligations that conflict across jurisdictions. For the exam, know that multiple regimes may apply simultaneously and that the strictest applicable requirement governs.

Exam angles

Distinguish controller (determines purposes and means, accountable) from processor (acts on instructions), and know that accountability does not transfer. Name the principles, especially data minimisation and storage limitation. Know that consent is one lawful basis among several. Know the subject rights and that satisfying them requires knowing where personal data resides. Recognize the breach notification clock starting at awareness, and DPIAs as required before high-risk processing.