EXIN PIPL Foundation common mistakes
EXIN PIPL Foundation · Understand the traps and how to avoid them.
Treating the PIPL as applying only to companies registered in mainland China, so candidates answer that a foreign e-commerce site selling into China is out of scope.
Candidates carry over a territorial instinct from GDPR-style or domestic-law thinking and overlook Article 3's extraterritorial limb, which reaches processing outside China that serves the purpose of providing products or services to individuals in China or analysing/evaluating behaviour of individuals in China.
What to do instead
Memorise the two-pronged scope test in Article 3: processing inside China, plus processing outside China that has a purpose of providing products/services to people in China or analysing/evaluating their behaviour. Practise classifying short scenarios (overseas app with Chinese users, overseas firm processing data of its Chinese staff) as in or out of scope.
Conflating 'personal information' with 'sensitive personal information' and labelling items like a name, phone number or ordinary purchase history as sensitive.
The exam uses short fact patterns and candidates default to a vague 'privacy-sensitive' gut feeling rather than the statutory list, which includes biometric characteristics, religious belief, specific identity, medical health, financial accounts, whereabouts/trajectory, and minors under 14.
What to do instead
Build a two-column recall sheet: ordinary PI versus sensitive PI, using the Article 28 categories plus the under-14 rule. For each practice item, ask 'is this on the statutory list or is it merely identifying?' and note that sensitive PI triggers separate consent and a personal information protection impact assessment.
Answering that consent is required for every processing activity, or conversely that consent is always the default legal basis.
Candidates over-learn 'consent' from privacy notices and miss that Article 13 lists multiple independent bases, including contract necessity, statutory duty, public health/emergency, and other lawful grounds, and that consent is not a hierarchy-topping basis.
What to do instead
Memorise the Article 13 list and practise matching scenario to basis. Remember the separate-consent triggers (sensitive PI, providing PI to another processor, public disclosure, overseas transfer, processing for automated decision-making with targeted push) and that withdrawal must be as easy as giving consent.
Accepting 'bundled' or 'implied' consent as valid, or saying consent can be presumed when the individual does not opt out.
Real-world interfaces normalise pre-ticked boxes and combined terms, so candidates transfer that familiarity into answers, ignoring the requirement that consent be voluntary, explicit, informed, and given on a clear basis, with separate consent where the law demands it.
What to do instead
Learn the consent validity checklist: informed, voluntary, explicit where required, purpose-specific, and separately obtained for each separate-consent trigger. In practice questions, reject any option containing 'deemed', 'implied', 'by continuing to use', or consent buried in general terms.
Telling an individual that they cannot access, copy, or correct their data because it is 'internal business information' or because the request is inconvenient.
Candidates confuse the processor's internal operational interest with the individual's statutory rights and do not recall that Article 45 gives a right to access and copy, and Articles 46-47 give correction and deletion rights with defined response duties.
What to do instead
Memorise the rights bundle (know/decide, access and copy, correct, delete, withdraw consent, portability, explanation of automated decisions, complaint) and the processor's duty to respond promptly. For each right, note the lawful refusal grounds and that refusal must be justified and a complaint channel given.
Rejecting a deletion request outright because a retention obligation under another law exists, without distinguishing which data must be kept and for how long.
Candidates treat 'we must keep records' as a blanket defence and miss that Article 47 requires deletion once the purpose is achieved or consent withdrawn, except where retention is required by law or regulation, and that retention should be limited to the required scope.
What to do instead
Practise the deletion decision tree: has the purpose been achieved, consent withdrawn, processing unlawful, or a contract ended? If yes, delete; if a statutory retention duty applies, keep only the required data for the required period and stop other processing. Note that deletion should also cover third parties who received the data.
Assuming a processor can use personal information for its own new purposes (e.g. its own marketing or model training) once it has received it from a client.
Candidates blur the controller/processor distinction and forget that a processor must process only as instructed, and that re-purposing requires a fresh legal basis, typically new consent from the individual.
What to do instead
Learn the Article 21 entrustment rules: agreed purpose, period, method, and data type; processor acts on instruction; no sub-entrustment without consent; and the processor must assist the controller. In scenarios, flag any processor-side use beyond the instruction as a violation requiring separate consent.
Answering that a data protection officer or impact assessment is needed only for large companies, or skipping the personal information protection impact assessment when sensitive PI or overseas transfer is involved.
Candidates generalise a 'size threshold' intuition and miss the trigger-based rules: a PIPIA is required for sensitive PI, automated decision-making, entrustment, provision to third parties, public disclosure, and cross-border transfer, and a dedicated officer/agency is required above the statutory volume threshold.
What to do instead
Memorise the PIPIA trigger list and the requirement to keep the report and processing records for at least three years. Separately memorise the threshold for appointing a person in charge of personal information protection (processing volume above the level set by the national cyberspace authority) and the duty to file with the authority for overseas transfers.
Treating a cross-border transfer as automatically allowed once the individual consents, without checking the Article 38 mechanism (security assessment, certification, standard contract, or other statutory route).
Candidates reduce cross-border transfer to a consent question and overlook that consent is an additional requirement layered on top of a transfer mechanism, and that critical infrastructure operators and volume thresholds change the route.
What to do instead
Build a transfer decision flow: identify whether the entity is a CIIO or over the volume threshold, then select the required mechanism (security assessment, certification, or standard contract filed with the authority), and add separate consent plus notification of overseas recipient details. Practise distinguishing 'consent alone' from 'consent plus mechanism'.
Answering that a breach requires notifying every individual regardless of risk, or that no notification is needed if the data was encrypted.
Candidates apply a single rigid rule instead of the risk-based test and forget the duty to notify the authority and to inform affected individuals when harm is likely, plus the duty to report the breach and any remedial action taken.
What to do instead
Memorise the breach response sequence: take immediate remedial action, notify the authority and the affected individuals where harm is possible, and where notification to individuals is not required, still notify the authority. Learn the required content of a notification and the record-keeping duty, and apply the 'likely to cause harm' test to scenario items.