CIPP/C common mistakes
CIPP/C · Understand the traps and how to avoid them.
Treating PIPEDA as the general rule for all private-sector organisations in Canada, instead of first checking whether the organisation is provincially regulated or covered by substantially similar provincial legislation (Quebec, Alberta, British Columbia) or by sector statutes (Ontario health, New Brunswick, Newfoundland and Labrador).
PIPEDA is the default federal statute and appears in most study material, so candidates apply it reflexively and miss that constitutional division of powers places most intraprovincial activity under provincial law.
What to do instead
Before answering any jurisdiction question, run a two-step test: (1) is the activity federal (banking, telecom, air, interprovincial transport, crown corporations) or intraprovincial? (2) if intraprovincial, does a substantially similar provincial law apply? Memorise the substantially similar list and the sectoral statutes.
Conflating the Privacy Commissioner's powers with those of a court: asserting that the OPC can order an organisation to stop processing, impose administrative monetary penalties, or award damages under PIPEDA.
Candidates transfer the GDPR enforcement model onto Canada, where the OPC is an ombudsman-style regulator that issues findings and recommendations and must apply to the Federal Court for enforceable orders.
What to do instead
Build a power table per statute: OPC under PIPEDA (investigate, report, apply to Federal Court for order, no AMPs, no damages), OPC under the Digital Charter Implementation Act proposals (would add AMPs), Quebec CAI (orders, AMPs, penal offences), Alberta PIPA (orders, AMPs), BC PIPA (orders, AMPs). Drill the distinction between recommend and order.
Applying GDPR lawful-basis categories to PIPEDA and omitting the knowledge-and-consent requirement, including the validity of implied consent where appropriate.
Most secondary study material is GDPR-centric, and candidates assume consent is only one of several equal bases rather than the central PIPEDA principle, with defined exceptions in section 7.
What to do instead
Memorise PIPEDA Principle 4.3 (knowledge and consent), the section 7 exceptions (legal, medical, security, disclosure for investigation, etc.), and the OPC's guidance on implied consent and appropriate sensitivity. Practise classifying scenarios as express, implied, or exception-based.
Misclassifying a privacy incident as a reportable breach under the PIPEDA mandatory breach reporting provisions, either reporting every incident or failing to report a real one because no harm was proven.
The threshold is a real risk of significant harm, which is a probability judgment about a defined set of harms (bodily, humiliation, damage to reputation, financial loss, identity theft), not a requirement that harm actually occurred.
What to do instead
Apply the two-part test explicitly: (1) is there a breach of security safeguards involving personal information? (2) is there a real risk of significant harm, considering sensitivity and probability? Then apply the record-keeping duty for all breaches and the notification duty to affected individuals and the OPC. Work through sensitivity factors (health, financial, SIN, credentials).
Answering Quebec questions using PIPEDA concepts and ignoring Law 25 amendments, such as the privacy officer designation, the confidentiality-by-default rule for commercial websites, and the new portability and automated decision provisions.
Quebec has the most detailed private-sector regime in Canada and recent amendments changed several rules, so candidates relying on older or federal-only material give answers that are close but wrong.
What to do instead
Create a Quebec-specific one-pager: CAI role and order-making power, incident reporting with a real risk of serious injury threshold, confidentiality by default, privacy officer requirement, biometrics notice, data portability, automated decision transparency, and the phased coming-into-force dates.
Writing an accountability answer that only names a designated privacy officer, without covering the full accountability principle: policies, training, complaint handling, third-party processing contracts, and the ability to demonstrate compliance on request.
Accountability is long and cross-cutting, so candidates reduce it to the single most memorable element and lose marks on scenario and program-design questions.
What to do instead
Memorise the accountability checklist as a system: designate responsibility, document policies and procedures, train staff, manage access requests and complaints, use contracts for service providers, monitor, and be able to demonstrate compliance. Use this checklist as the skeleton for program-design answers.
Drafting a privacy program that lacks a defensible governance structure: no executive sponsor, no reporting line, no defined roles for business units, and no linkage between privacy risk and the organisation's risk register.
Candidates treat program development as a policy-writing exercise and underestimate the governance, risk-assessment, and resourcing elements that exam scenarios test.
What to do instead
Structure answers around a recognised program model: governance and accountability, risk assessment, policies and procedures, training and awareness, incident management, monitoring and audit, and third-party management. For each, state the owner, the artefact, and the evidence of operation.
Handling access requests incorrectly: applying the wrong statutory clock, ignoring the extension rules, or failing to identify the correct exempt information (third-party personal information, solicitor-client privilege, confidential commercial information) and the duty to sever.
Access and correction rules differ by statute and include procedural details (fee estimates, time limits, extensions, deemed refusal) that are easy to blur across PIPEDA, provincial statutes, and the Privacy Act.
What to do instead
Build a comparison table of access timelines, extension conditions, fee rules, and exemptions per statute. Practise the severance principle: redact exempt portions and release the rest, rather than refusing the whole request.
Treating cross-border transfers and service-provider arrangements as automatically requiring consent, or as automatically permissible, instead of applying the transfer-for-processing rule with accountability retained by the transferring organisation.
The OPC's position that transfers to a third party for processing are not disclosures requiring consent under PIPEDA conflicts with intuitions from GDPR transfer rules, and candidates swing to one extreme.
What to do instead
Learn the distinction between transfer for processing (accountability retained, contractual safeguards, notification through the privacy policy) and disclosure to a third party for its own purposes (requires knowledge and consent). Address the USA PATRIOT Act-style foreign-law access question as a risk to be disclosed, not a bar to transfer.
Answering privacy impact assessment questions with a generic description of a PIA rather than the operational steps: threshold screening, description of the information flow, identification of legal authority and privacy risks, mitigation, sign-off, and ongoing review tied to the project lifecycle.
PIAs are tested in program-operations scenarios where the examiner wants process, triggers, and documentation, not a definition.
What to do instead
Memorise the PIA lifecycle and the triggers that require one (new program, system, data sharing, outsourcing, technology change). Practise writing the mitigation table and the approval and review steps, and link the PIA to the organisation's project gateways.