DSCI DCPP common mistakes
DSCI DCPP · Understand the traps and how to avoid them.
Treating 'personal data' as limited to identifiers like name, email and phone number, then failing items where the correct answer turns on linked or linkable information such as device IDs, IP addresses, location trails, or combinations of indirect attributes.
Candidates carry over a colloquial or older 'PII' mental model and never internalize the breadth of the statutory definition, so they misclassify pseudonymized or inferred data as outside scope.
What to do instead
Before answering any classification item, restate the statutory test in your head: data relating to an identifiable or identified individual, directly or indirectly. Drill worked examples where only the combination of two innocuous fields re-identifies a person, and where pseudonymized data remains personal data because re-linking is possible.
Conflating the roles of Data Fiduciary, Data Processor and Data Principal, and applying the wrong party's obligations to a scenario (for example holding the processor liable for notice and consent, or assuming the fiduciary must obtain consent for every processing purpose).
The roles are described with familiar-sounding terms that map imperfectly onto GDPR controller/processor language, and candidates rely on GDPR intuition instead of the specific Indian statutory allocation of duties.
What to do instead
Build a one-page role matrix: who determines purpose and means, who owes notice, who must obtain and honor consent, who handles grievance redressal, who notifies breaches, and what the processor's duties are toward the fiduciary. For each practice question, first assign roles explicitly in writing before evaluating the answer choices.
Answering consent questions as if consent were the only lawful basis, and missing that certain legitimate uses (such as specified categories of state functions, medical emergencies, employment purposes, or other notified legitimate uses) may proceed without consent but remain subject to conditions.
Training material and news coverage emphasize consent, so candidates over-apply it and overlook the enumerated non-consent grounds and the conditions attached to them.
What to do instead
Memorize the structure of the statute rather than isolated facts: consent as the default, the listed exceptions, and the conditions each exception carries. Practice scenario items where the correct answer is 'permitted without consent but only if X', and be alert to options that are too absolute in either direction.
Applying GDPR concepts mechanically to other jurisdictions, for example assuming a GDPR-style data protection officer obligation, GDPR lawful-basis list, or GDPR transfer mechanism exists identically in India, Singapore, Brazil or China.
GDPR is the most studied framework, so candidates pattern-match on it and skip the jurisdiction-specific threshold tests, registration duties and transfer rules that the question is actually testing.
What to do instead
For each major law, memorize a compact comparison table covering scope and territorial reach, lawful bases, individual rights set, regulator and registration duties, breach timelines, and cross-border transfer mechanism. When a question names a jurisdiction, answer from that column of the table, not from GDPR memory.
Treating cross-border transfer as a single global question ('is transfer allowed?') instead of separating the transfer mechanism, the destination-country restriction, and the accountability or contractual safeguards, which are three distinct layers.
Candidates learn one transfer tool (for example standard contractual clauses or an adequacy list) and then select it as the answer even when the question concerns a country restriction or a local storage requirement.
What to do instead
For every transfer scenario, answer three separate questions in order: is there a permitted basis or mechanism, is the destination restricted or subject to conditions, and what safeguards or accountability measures attach? Only then evaluate the options. Note which laws use allow-lists, which use adequacy decisions, and which impose localization for specified categories.
Confusing accountability and governance artifacts with operational controls, for example choosing a privacy notice as the answer to a question about demonstrating compliance to a regulator, or choosing a policy document where the correct answer is a record of processing, DPIA, or audit evidence.
Notices and policies are the most visible privacy outputs, so candidates default to them, missing the distinction between transparency to individuals and demonstrable accountability to a supervisory authority.
What to do instead
Categorize program artifacts by function: transparency to individuals, internal operating control, evidence of accountability, and risk decision record. For each governance question, identify which function the scenario demands, then select the artifact that serves that function.
Designing or evaluating a privacy program without assigning ownership, escalation paths and review cadence, producing answers that describe activities but not a governable structure.
Candidates focus on what must be done (training, DPIAs, notices) and neglect who owns it, how it is monitored, and how it is refreshed, which is exactly what program-management items test.
What to do instead
For any program-design question, check the option for four elements: named accountable role, defined process, monitoring or metrics, and periodic review with escalation. Prefer options containing all four and reject those that list activities with no owner or feedback loop.
Choosing 'encrypt everything' or 'delete the data' as the default engineering answer to every privacy-by-design item, ignoring purpose limitation, minimization at collection, and the trade-offs that make a control appropriate to a specific risk.
Encryption and deletion are memorable controls, so candidates over-generalize them and fail items that test minimization, access control, retention scheduling, or privacy-preserving analytics.
What to do instead
Map controls to risks explicitly: minimization and purpose limitation at design, access control and segregation at operation, encryption in transit and at rest for confidentiality, retention schedules and deletion for storage limitation, and aggregation or differential privacy for analytics. Select the control that addresses the named risk rather than the strongest-sounding control.
Mishandling breach scenarios by not distinguishing containment from notification, or by applying a single fixed notification clock and recipient set across jurisdictions and incident types.
Candidates memorize one timeline and one recipient, then apply it to every scenario, missing that thresholds, deadlines and recipients differ by law and by whether the incident is a confidentiality, integrity or availability event.
What to do instead
Practice a breach triage template: classify the incident, assess harm and threshold, contain and document, then determine who must be notified, in what order, and by when, per applicable jurisdiction. Rehearse scenarios with different timelines and different recipients so the distinctions become automatic.
Answering data subject or Data Principal rights requests as if the only question is whether the right exists, without addressing verification of identity, timelines, exemptions, and the format of the response.
Candidates learn the catalogue of rights but not the operational procedure, so they pick the substantively correct right while ignoring the procedural conditions the scenario is testing.
What to do instead
For every rights-request item, run a four-step check: is the requester verified, which right and which law applies, does an exemption or third-party rights limitation apply, and what is the deadline and required response format. Answer only after all four steps are resolved.