ICCP DGSP common mistakes
ICCP DGSP · Understand the traps and how to avoid them.
Treating data stewardship and data ownership as synonyms, so on scenario questions the candidate assigns accountability for data quality, access approval, and policy enforcement all to one role instead of distinguishing the business owner (accountable for the data domain) from the steward (responsible for day-to-day quality, definitions, and issue resolution).
Colloquial usage in many workplaces blurs the two titles, and study material read quickly reinforces the overlap; the exam tests the RACI distinction explicitly in role-clarification scenarios.
What to do instead
Build a one-page RACI table for a single data domain (e.g., customer master) listing owner, steward, custodian/IT, and data governance council, and for each decision (definition change, access grant, quality remediation, policy exception) write who is Accountable vs Responsible. Rehearse explaining the table aloud in under two minutes.
Answering policy questions by choosing the most rigorous control (full approval workflow, quarterly recertification of everything, blocking access until classification completes) rather than the control proportionate to the data's classification and use.
Candidates equate 'governance' with 'more control' and default to maximal restriction, which is intuitive under exam pressure but conflicts with risk-based governance principles.
What to do instead
Practice tiering: take five data sets, assign a classification, and justify a control set for each (public, internal, confidential, restricted). Learn to spot answer options that apply the highest tier universally and eliminate them as disproportionate.
Confusing data governance with data management execution, so the candidate selects answers where the governance body builds pipelines, cleans records, or administers the warehouse instead of setting decision rights, standards, and escalation paths.
In small organizations the same people do both, so the candidate's lived experience contradicts the exam's separation of 'decide and oversee' from 'do'.
What to do instead
Memorize the test: governance answers 'who decides, by what rule, and who is accountable'; management answers 'who executes and with what tooling'. Tag every practice option as D (decision/oversight) or E (execution) before choosing.
Skipping the operating-model design questions-choosing centralized or federated without stating the criteria (business unit autonomy, regulatory uniformity, maturity, funding model) that make one fit the scenario.
Candidates memorize 'federated is agile, centralized is controlled' as slogans and then pick by gut feel rather than by matching model to stated constraints in the stem.
What to do instead
Create a decision matrix with rows for centralization, federation, and hybrid, and columns for decision latency, consistency needs, cost, and skills required. For each practice scenario, extract the constraints first, then let the matrix pick the model.
Treating a data catalog as a documentation deliverable, so the candidate picks answers where the catalog is populated once at project close rather than maintained as an operational asset with ownership, review cadence, and linkage to policy and lineage.
Catalog work is often framed internally as a documentation task, and candidates carry that framing into questions about sustaining metadata.
What to do instead
Reframe the catalog as a governed register: for each entry, know who owns it, how often it is reviewed, what triggers an update (schema change, new source, policy change), and how it connects to classification and access decisions. Practice questions that ask what happens after go-live.
Ignoring the human and change-management side of stewardship rollouts-answering purely with tooling, charters, and org charts when the scenario describes low adoption, stewards who will not perform duties, or business units bypassing the council.
Technical candidates gravitate to artifacts they can design, and adoption problems feel softer and less examinable, so they under-prepare for them.
What to do instead
For every governance artifact you study, add a companion note on adoption: incentives, executive sponsorship, steward workload protection, and visible wins. When a stem mentions resistance or bypass, scan options first for those that address incentives, sponsorship, and escalation before tooling.
Misreading data quality dimensions-using accuracy, completeness, consistency, timeliness, validity, and uniqueness interchangeably, and choosing a dimension that does not match the described defect (e.g., calling a field with an out-of-range code an accuracy problem rather than a validity problem).
The dimensions overlap in everyday speech and definitions vary between frameworks, so candidates rely on intuition instead of a fixed definition set.
What to do instead
Write a one-line definition and a concrete defect example for each dimension, then drill 20 short defect descriptions and name the dimension. Where frameworks differ, note the exam's likely convention and answer by the defect's mechanism, not the label.
Choosing a remediation answer that fixes the symptom (correct the bad records, add a validation rule at the report layer) instead of the root cause (fix the source system, add a control at point of entry, assign stewardship of the field).
Symptom fixes are faster and more familiar operationally, and candidates answer as they would act in production rather than as a governance question about durable controls.
What to do instead
Apply a two-step test to every remediation option: does it prevent recurrence, and does it place the control as close to the source as possible? Eliminate options that only cleanse downstream or patch a report.
Treating metadata and lineage as optional technical detail, so the candidate fails questions about impact analysis, regulatory traceability, or change management where lineage is the enabling capability.
Lineage is often absent in candidates' own environments, so they underestimate how central it is to governance decisions and answer as if classification and policy alone suffice.
What to do instead
Study lineage as a decision input: for a proposed schema change or a regulator's question, trace which reports, models, and controls are affected. Practice sketching end-to-end lineage for one metric from source to dashboard and naming where controls attach.
Answering maturity and roadmap questions with the end state (target operating model, full automation) rather than the next appropriate step given the stated current maturity, funding, and culture.
Candidates want to demonstrate knowledge of the ideal model and overlook that the question asks what to do next from where the organization is.
What to do instead
For each maturity level (initial, developing, defined, managed, optimizing), write the realistic next move and the trap answer that jumps two levels. Before answering, underline the stem's current-state descriptors and reject any option that skips a level without a stated enabler.