EXIN PDPP common mistakes
EXIN PDPP · Understand the traps and how to avoid them.
Treating 'personal data' as only obvious identifiers such as name, address or email, and therefore failing to classify IP addresses, location data, employee IDs, pseudonymised records or behavioural data as personal data in scenario questions.
Candidates carry over everyday intuitions from the GDPR headlines and forget that the test is whether data relates to an identified or identifiable natural person, directly or indirectly. Pseudonymisation is often confused with anonymisation because both sound like 'hiding the identity'.
What to do instead
Before answering, apply a two-step test to every data item in the scenario: can this be linked to a person, alone or combined with other available data, and by whom? Write 'identifiable by controller or third party' explicitly. Memorise that pseudonymised data remains personal data while anonymised data falls outside scope, and practise classifying borderline items such as IP addresses, CCTV footage, biometric templates and free-text case notes.
Lumping all processing principles together and answering with 'lawfulness' whenever anything feels wrong, instead of identifying the specific principle at issue (purpose limitation, data minimisation, storage limitation, accuracy, integrity and confidentiality, accountability).
The principles are learned as a list in one study session and never separated by their distinctive trigger facts. Under exam pressure, the most familiar word wins rather than the one matching the scenario detail.
What to do instead
Build a one-line trigger for each principle: new purpose equals purpose limitation; more fields than needed equals minimisation; kept too long equals storage limitation; wrong record equals accuracy; breach or insecure transfer equals integrity and confidentiality; cannot demonstrate compliance equals accountability. Rehearse by reading short scenarios and naming the principle before looking at the options, then check whether the option you chose describes the same trigger.
Answering legal-basis questions by choosing 'consent' by default, even where consent is invalid or inappropriate, for example in an employment relationship, for a public authority task, or where refusal has no genuine effect.
Consent is the most publicly discussed basis and feels safest. Candidates also overlook that consent must be freely given, specific, informed, unambiguous, and withdrawable, and that another basis may fit the facts better.
What to do instead
For every legal-basis question, run a short elimination: is there a contract with the data subject, a legal obligation, a vital interest, a public task, or a legitimate interest that survives balancing? Choose consent only when the data subject has a real choice and the request is granular. Flag employee and public-authority scenarios as high-risk for consent, and remember that consent can be withdrawn, which affects processing that relies on it.
Confusing the roles and obligations of controller, processor and joint controllers, for example assuming the processor bears the main accountability burden or that a processor may set its own purposes.
The terms sound interchangeable in ordinary language, and many vendor scenarios describe practical activity rather than legal role. Candidates answer from who physically touches the data rather than who determines why and how it is processed.
What to do instead
Ask who decides the purposes and essential means: that is the controller. A processor acts only on documented instructions and must not go beyond them. Joint controllers share determination of purposes and means and should arrange responsibilities transparently. In scenarios, identify the decision-maker first, then apply obligations: the controller handles accountability, data protection impact assessments and most data subject requests, while the processor supports them and notifies the controller of breaches without undue delay.
Missing that a transfer question turns on whether data leaves the relevant legal jurisdiction or goes to an international organisation, and then selecting a transfer mechanism for a purely domestic processing scenario, or missing the need for one in a genuine third-country case.
Transfer rules are learned as a separate chapter and not linked to the geography in the scenario. Candidates also assume that using a cloud provider always means a restricted transfer, or conversely that a well-known vendor needs no safeguard.
What to do instead
Map the data flow first: where is the controller established, where is the recipient, and is the recipient in a country covered by an adequacy decision? If not, look for appropriate safeguards such as standard contractual clauses or binding corporate rules, and remember derogations are exceptional. Practise sketching arrows between entities before reading the options, and check whether the question asks about the transfer itself or about the documentation of it.
Handling data subject rights questions with a single generic answer, ignoring the specific right, its conditions and its deadlines, such as confusing access with portability, or forgetting that erasure is not absolute.
Rights are memorised as a list of names without their scope and exceptions. The scenario usually contains a detail that triggers an exception, but candidates answer from the headline right rather than the facts.
What to do instead
For each right, memorise three things: what the data subject receives, the conditions, and the exceptions. Access gives a copy plus information about processing; portability applies to data provided by the data subject, processed by automated means on consent or contract, and is delivered in a structured machine-readable format; erasure yields to legal retention obligations and freedom of expression. Note the one-month response period and the possibility of extension, and check whether an identity verification issue or a manifestly unfounded request changes the answer.
Treating a personal data breach notification as a single decision, rather than separating the obligation to notify the supervisory authority from the obligation to inform affected data subjects, each with its own threshold and timing.
The two duties are studied together and collapse into 'notify within 72 hours'. Candidates then apply the authority deadline to data subjects or assume every incident must be reported.
What to do instead
Split the analysis into three questions: is it a personal data breach, is there a risk to rights and freedoms that requires authority notification without undue delay and where feasible within 72 hours, and is there a high risk that requires informing data subjects without undue delay? Record the reasoning, because a documented decision not to notify is itself part of accountability. Practise with incidents that are contained quickly, encrypted, or affect only internal contact details.
Confusing privacy by design and by default with a one-off documentation exercise, and therefore selecting 'write a policy' where the scenario demands technical and organisational measures embedded in the processing, or minimised defaults.
The phrase sounds like a planning document, and policy writing is the most familiar compliance activity. Candidates miss that the requirement attaches to the design of systems and to default settings such as data minimisation and limited accessibility.
What to do instead
Read the scenario for a design or configuration decision: new system, new form, default sharing setting, retention setting. Choose the answer that changes the system or the default, not merely the paperwork. Link the concept to the data protection impact assessment, which is the tool for high-risk processing, and to the principle of data minimisation, which supplies the default. Where options mix training, policy and technical measures, prefer the measure that operates at the point where data is collected or exposed.
Describing accountability as 'keep records' and failing to distinguish the various governance instruments: records of processing activities, the data protection impact assessment, the data protection officer, prior consultation, and the role of codes of conduct and certification.
These instruments are taught in one governance block and their purposes blur. Candidates match on the word 'documentation' rather than on the function each instrument performs.
What to do instead
Assign each instrument a function: records give an inventory of processing; the impact assessment evaluates high risk before processing and supports prior consultation where residual risk remains high; the data protection officer advises, monitors and is a contact point but is not personally liable for compliance; codes and certification demonstrate safeguards. In questions, ask what the organisation is trying to achieve, then pick the instrument whose function matches, and check whether the trigger for a mandatory impact assessment or a mandatory officer is actually present.
Assuming a data protection officer must always be appointed, or that the officer personally carries legal responsibility and may do any other job, instead of applying the designation criteria and the independence requirements.
The officer is a visible role and candidates generalise from organisations they know. The statutory criteria and the conflict-of-interest rule are easily reduced to 'appoint a DPO'.
What to do instead
Memorise the designation triggers: large-scale regular and systematic monitoring, or large-scale processing of special categories, plus the possibility of a legal requirement. Remember the officer must be involved properly, report to the highest management level, be free of instructions on exercising the role, and must not hold a position that creates a conflict of interest. In scenarios, test whether the scale and nature of processing genuinely meet a trigger, and reject options that make the officer the decision-maker or the personally liable party.