Data Controller and Data Processor
The two principal GDPR roles, distinguished by who decides. A controller determines the purposes and means of processing and carries the primary accountability, including lawful basis, transparency and responding to data subject rights. A processor acts only on the controller's documented instructions, and must not engage a subprocessor without authorisation. The roles are determined by actual decision-making, not by what a contract calls the parties, so a vendor that decides how to use data for its own purposes becomes a controller regardless of the label. Article 28 requires a written processing agreement between them, and a processor that exceeds instructions takes on controller liability. This allocation is central to CIPP/E, CDPSE and CGRC.
Why It Matters
In practice, getting the role allocation wrong misassigns accountability for years, and the error is usually optimistic: a service provider that analyses customer data to improve its own product is making purpose decisions and is a controller for that activity, whatever the signed agreement says. Joint controllership arises more often than organisations expect -- typically where two parties genuinely co-decide purposes -- and requires an arrangement setting out who answers data subject requests. For third-party risk work the practical consequence is that a controller remains accountable for its processors, so a processor's subprocessor is the controller's exposure too, which is why authorisation and flow-down obligations belong in the Article 28 agreement rather than being assumed. On certification exams such as CIPP/E, CDPSE and CGRC, expect questions about classifying parties in a scenario, mandatory Article 28 contract terms, joint controller arrangements, and where liability lands when a processor acts outside instructions.
Related Privacy terms
Data Protection Impact Assessment (DPIA)
A documented assessment of how a proposed processing activity affects the rights and freedoms of individuals, required under GDPR Article 35 whenever processing is likely to result in high risk -- large-scale profiling, systematic monitoring of a public area, or processing of special-category data. A DPIA records the nature and purpose of the processing, its necessity and proportionality, the risks to data subjects, and the measures chosen to reduce them. It must be completed BEFORE processing begins, because its purpose is to change the design while change is still cheap. The supervisory authority must be consulted where residual high risk remains. DPIAs appear on CIPP/E, CDPSE and CGRC in the privacy governance and risk domains.
Data Subject Access Request (DSAR)
A request by an individual to exercise their rights over personal data an organisation holds about them -- most often access to a copy, but also rectification, erasure, portability, restriction, or objection to processing. Under GDPR the response deadline is one month from receipt, extendable by two further months for complex or numerous requests, and the response is normally free. The organisation must verify the requester's identity before disclosing anything, since a DSAR is itself an attractive route for a social engineer. Fulfilment requires knowing every system that holds the data, which is why DSAR readiness is a data-inventory problem rather than a legal one. DSARs are examined on CIPP/E and CDPSE.
Data Minimization
The principle that personal data collected and retained must be adequate, relevant and limited to what is necessary for the stated purpose, expressed in GDPR Article 5(1)(c). It constrains collection at the point of design -- not asking for a date of birth when an age band suffices -- and constrains retention afterwards, since data kept past its purpose is no longer necessary by definition. Minimisation is the cheapest security control available, because data never collected cannot be breached, misused, or requested in a DSAR. It sits alongside purpose limitation and storage limitation as one of the core processing principles tested on CIPP/E, CDPSE and CISSP.
Pseudonymization
Processing personal data so that it can no longer be attributed to a specific individual without additional information -- typically by replacing direct identifiers with tokens -- while that additional information is kept separately under technical and organisational safeguards. Crucially, pseudonymised data REMAINS personal data under GDPR and stays fully in scope, because the link can be restored by whoever holds the key. GDPR Article 32 names it as a recommended security measure and it can reduce risk, but it is not an exemption from the regulation. It is regularly confused with anonymisation on CIPP/E and CDPSE, which is exactly why examiners ask about it.
Anonymization
Irreversibly processing data so that no individual can be identified from it, by any party, using any reasonably available means. Genuinely anonymous data falls outside GDPR entirely, which is why the bar is high and why most claims of anonymisation do not meet it. The standard is contextual rather than technical: a dataset stripped of names may still be re-identifiable by combining quasi-identifiers such as postcode, birth date and sex, or by linking against an external dataset the publisher never considered. Techniques include aggregation, generalisation, suppression and formal models such as k-anonymity and differential privacy. Anonymisation is tested on CIPP/E, CDPSE and AIGP.
Lawful Basis for Processing
The legal ground an organisation must identify before processing personal data, chosen from the six in GDPR Article 6: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The basis must be determined and documented BEFORE processing starts and cannot be swapped afterwards to rescue an activity that has been challenged. Consent is only one option and often the weakest, since it must be freely given, specific, informed and unambiguous, and it can be withdrawn at any time. Legitimate interests requires a documented balancing test against the individual's rights. Special-category data needs an additional Article 9 condition. Lawful basis is core CIPP/E and CGRC material.