CCDL1 common mistakes
CCDL1 · Understand the traps and how to avoid them.
Treating data governance as a documentation exercise: producing policy documents and RACI charts without linking them to enforceable controls, owners, and measurable outcomes, then answering scenario questions by naming the framework instead of the mechanism.
Governance frameworks (DAMA-DMBOK, COBIT, ISO/IEC 38500) are easy to memorise as lists of domains and principles. Candidates study the vocabulary and assume the exam tests recall, when it actually tests whether they can pick the control that makes a policy operative.
What to do instead
For each governance concept, write one sentence pairing the artefact with its enforcement mechanism and owner (e.g., data stewardship assigned to a named business role, with policy exceptions requiring a documented approval workflow and periodic review). Practise scenario questions by asking 'what makes this policy actually happen?' before choosing an answer.
Choosing 'all data everywhere' as the safest answer for classification and inventory questions, or conversely skipping classification scope questions entirely because they seem administrative.
Candidates reason that classifying everything is the most conservative option and therefore must be correct. In practice, over-classification destroys inventory usefulness, inflates storage and access cost, and buries sensitive data in noise; exam scenarios reward proportionate, risk-based scoping.
What to do instead
Learn to distinguish full-population discovery (automated scanning to find unknown data) from targeted classification (applying tiers to data that matters). Answer by first identifying the business process and regulatory driver, then selecting the tier and scope that match, and be ready to justify why a narrower scope is defensible.
Confusing retention with deletion: assuming a retention schedule alone satisfies lifecycle obligations, and missing that defensible deletion, legal hold suspension, and verification of destruction are separate controls.
Retention periods are the most visible part of lifecycle management, so candidates anchor on them. Legal hold, disposal evidence, and the interaction between retention expiry and litigation obligations are less intuitive and get skipped in study.
What to do instead
Build a lifecycle checklist per data type: creation, classification, retention trigger event, retention period, legal hold override, disposal method, and evidence of disposal. In questions, check whether the scenario is asking about keeping data or about proving it was destroyed, and answer accordingly.
Treating encryption as a complete storage control: selecting 'encrypt the data' as the answer for questions about access control, data integrity, or data residency, without addressing key management, access logging, or location constraints.
Encryption is the most familiar technical control and feels like a universal safeguard. Candidates underweight that encryption at rest does not stop an authorised user from exfiltrating data, and that key custody is often the real risk in the scenario.
What to do instead
For each storage control, state what threat it addresses and what it does not. Practise pairing encryption with key management ownership, rotation, and separation of duties, and with access logging and residency controls. Reject 'encrypt it' when the scenario describes insider misuse or jurisdictional requirements.
Answering access questions with role-based access control by default, even when the scenario describes a need for attribute-based, purpose-based, or just-in-time access, or when the real issue is entitlement creep and periodic recertification.
RBAC is the model most candidates know best and appears in most introductory material, so it becomes a reflex. Candidates also conflate authentication strength (MFA) with authorisation design, and miss that access review cadence is often the intended control.
What to do instead
Map scenarios to access models explicitly: RBAC for stable job functions, ABAC for context-dependent rules, just-in-time and privileged access management for elevated rights, and periodic access recertification for entitlement drift. Before answering, identify whether the question is about proving identity, granting rights, or reviewing rights already granted.
Describing incident response as detection plus notification, skipping containment, evidence preservation, and the post-incident lessons-learned loop; or jumping straight to containment before scoping the incident.
Notification deadlines in privacy regulation are memorable and dramatic, so candidates over-index on them. The operational sequence of the response lifecycle is less frequently rehearsed, and containment feels like the obviously urgent first move.
What to do instead
Memorise the response lifecycle as an ordered sequence with decision points: detection, triage and severity assignment, scoping, containment, eradication, recovery, notification assessment, and post-incident review. For each scenario, ask what phase the described action belongs to and whether evidence preservation constrains it.
Applying a single jurisdiction's rules globally, or assuming a regulation's requirements are satisfied by a contractual clause alone (for example, treating a data processing agreement as sufficient for cross-border transfer).
Candidates often study one privacy regime in depth and generalise. Transfer mechanisms, lawful basis for processing, and data subject rights each have distinct conditions that a contract does not automatically satisfy.
What to do instead
For each privacy obligation, separate the legal basis, the operational control, and the evidence. Study transfer mechanisms as a category (adequacy decisions, contractual safeguards, derogations) and learn when each applies. In scenarios, identify the jurisdiction of the data subject, the location of processing, and the transfer direction before selecting an answer.
Treating data quality as a one-time cleansing project: choosing remediation as the answer when the scenario describes recurring defects, or ignoring data quality dimensions other than accuracy, such as completeness, timeliness, consistency, and uniqueness.
Cleansing is the visible, satisfying action, and 'accuracy' is the dimension candidates remember first. Root-cause controls, quality metrics, and stewardship accountability receive less attention in casual study, so they are under-selected.
What to do instead
For each quality dimension, name a measurable definition and a preventive control at the point of entry (validation rules, referential integrity constraints, mandatory fields, reconciliation). When a scenario shows repeated defects, prefer root-cause and prevention answers over remediation, and cite the specific dimension being measured.
Reading scenario questions as definitions and answering with the textbook term, rather than identifying the constraint in the scenario (regulatory deadline, cost, availability, existing control) that makes one option better than another.
Many CCDL-style items are written as short situations with a 'best' answer. Candidates trained on recall questions pick the most technically complete-sounding option, missing that the scenario deliberately rules out the strongest control for cost, feasibility, or proportionality reasons.
What to do instead
Before answering, underline the explicit constraints in the stem and eliminate any option that violates one. Practise articulating why the second-best option fails: too costly, too slow, wrong phase of the lifecycle, or addresses a different risk than the one described.
Mixing up the roles that own data versus the roles that operate on it: assigning accountability to IT or to a tool owner when the scenario calls for business data ownership, or confusing data owner, data steward, custodian, and controller/processor responsibilities.
Job titles vary across organisations and frameworks, and the same word (owner) can mean different things in governance and privacy contexts. Candidates answer by title rather than by the accountability the scenario describes.
What to do instead
Build a role table that separates accountability (who answers for the data), responsibility (who performs stewardship tasks), and custody (who runs the systems), and map controller and processor onto it. In questions, identify the decision being made and assign the role accountable for that decision, not the team that happens to operate the platform.