Standard Contractual Clauses (SCCs)
Pre-approved contractual terms adopted by the European Commission that provide a lawful mechanism for transferring personal data from the EEA to a country without an adequacy decision. Following the Schrems II ruling, using SCCs is not sufficient on its own: the exporter must also carry out a transfer impact assessment of the destination country's surveillance laws and apply supplementary measures -- such as strong encryption with keys held in the EEA -- where the clauses alone cannot be honoured. The modular 2021 clauses cover controller-to-controller, controller-to-processor and onward transfer scenarios. Cross-border transfer mechanisms are heavily examined on CIPP/E and CDPSE.
Why It Matters
In practice, SCCs are where privacy law meets cloud architecture, because the question of whether data leaves the EEA is answered by infrastructure decisions -- region selection, backup replication, support access from outside the region, and subprocessors -- rather than by contract language. The post-Schrems II position is what catches organisations out: signing the clauses and filing them is not compliance if the destination's legal regime would compel disclosure in a way the clauses cannot prevent, which is what the transfer impact assessment exists to surface. Enforcement has followed, including a multi-billion-euro fine over transfers that relied on mechanisms found inadequate. Vendor-driven transfers are easy to miss, since a processor's own subprocessor may move data further. On certification exams such as CIPP/E and CDPSE, expect questions about when SCCs are required, adequacy decisions and binding corporate rules as alternatives, and the supplementary-measures obligation.
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.