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.
Why It Matters
In practice, choosing a lawful basis is the decision that determines which rights apply and how much operational burden the activity carries, so defaulting to consent -- the intuitive choice -- is usually the expensive mistake: consent must be withdrawable, and a service that breaks when a user withdraws was never really relying on consent. Where processing is genuinely necessary to deliver the contract the user asked for, contract is the honest basis; where the organisation benefits and the individual would not object, legitimate interests may fit but requires the balancing test to be written down rather than assumed. Bundling consent into terms of service, or making a service conditional on consent unrelated to it, is a recognised enforcement target. On certification exams such as CIPP/E and CGRC, expect questions about matching a scenario to the correct basis, the validity conditions for consent, the legitimate interests assessment, and the extra conditions attached to special-category data.
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.
Privacy by Design
The requirement to build data protection into a system's architecture and default settings rather than adding it afterwards, codified as data protection by design and by default in GDPR Article 25. In practical terms it means the most privacy-protective configuration is the one a user gets without acting, collection is limited at the point of design, retention is enforced by a mechanism rather than a policy document, and access is scoped by role from the start. It carries an accountability burden: the controller must be able to DEMONSTRATE the measures chosen, not merely assert them. Privacy by design is tested on CIPP/E, CDPSE and CSSLP.