CDPSE cheat sheet

Governance establishes accountability: assign a privacy owner (DPO or equivalent), document decision rights, and record approvals for privacy policy changes.

Core governance documents: privacy policy (external commitments), privacy standards (mandatory internal rules), and privacy procedures (operational steps). Each answers a different question.

Three lines of defense: operations owns privacy risk, an independent privacy/compliance function monitors it, and internal audit provides assurance.

GDPR Article 5 principles: lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability.

Accountability requires evidence, not intent: maintain records of processing, DPIA outcomes, training logs, and consent records as demonstrable proof.

Privacy roles differ: controller determines purposes and means; processor acts on documented instructions; joint controllers share purposes and must define responsibilities.

Board-level oversight indicators: privacy risk on the enterprise risk register, a reporting cadence to the board, and defined escalation thresholds for incidents.

Policy exception handling: every exception needs an owner, a documented justification, a compensating control, and a fixed expiry date.

Training governance: role-based curricula, completion tracked by population, and refresh triggered by material regulatory or process change.

Risk formula: risk = likelihood × impact, assessed against data subjects. Score both before (inherent) and after (residual) controls.

DPIA trigger test: systematic and extensive evaluation, large-scale special-category or criminal data, or large-scale systematic monitoring of a publicly accessible area.

DPIA content: description of processing and purposes, necessity and proportionality assessment, risks to rights and freedoms, mitigations, and sign-off by the privacy function.

Transfer mechanisms under GDPR Chapter V: adequacy decision, standard contractual clauses, binding corporate rules, or a specific derogation. Each has different durability.

Schrems II consequence: SCCs require a transfer impact assessment covering local surveillance law and any supplementary technical or organisational measures.

Breach notification clocks: GDPR requires supervisory authority notification within 72 hours of awareness; notify affected individuals without undue delay when risk is high.

Data subject request handling: verify identity, log the request, respond within the statutory deadline (one month under GDPR, extendable by two), and record refusals with reasons.

Compliance monitoring tools: records of processing activities, vendor risk questionnaires, audit findings tracking, and privacy control testing against a framework.

Vendor risk tiers: classify by data sensitivity and volume, then scale due diligence, contractual terms, and reassessment frequency to the tier.

Life cycle stages: collection, use, sharing/disclosure, retention, and disposal. Controls and legal basis must be defined at every stage, not only at collection.

Data minimisation test at collection: is each field necessary for the stated purpose, and is the collection method the least intrusive available?

Retention schedules derive from legal or business need, not convenience; each data category needs a defined retention period and a disposal trigger.

Legal hold suspends scheduled disposal for identified data; the hold must be documented and released formally when the matter closes.

Disposal must be verifiable: certificates of destruction for media, logs for logical deletion, and coverage checks that include backups and archives.

Secondary use requires a compatibility assessment against the original purpose; incompatible use needs a new legal basis or fresh consent.

Data classification drives handling: public, internal, confidential, restricted. Each level specifies storage, encryption, sharing, and disposal rules.

Data quality obligations include accuracy and correction; stale or duplicated records in analytics and CRM systems are a compliance exposure, not just a hygiene issue.

Third-party sharing requires a data flow map showing what leaves, to whom, under which agreement, and in which jurisdiction it is stored.

Privacy by design principles: proactive not reactive, privacy as the default, embedded into design, full functionality (positive-sum), end-to-end security, visibility and transparency, respect for user privacy.

Privacy by design is applied at design time; privacy by default means the highest privacy setting is the pre-selected state with no user action required.

PET selection: pseudonymisation reduces identifiability but is reversible with a key; anonymisation must be irreversible under realistic re-identification attacks.

De-identification techniques: masking, tokenisation, generalisation, k-anonymity, l-diversity, and differential privacy. Each trades utility against re-identification risk.

Encryption controls: at rest (AES-256 class), in transit (TLS 1.2+), and key management separated from data storage. Key custody determines the real protection level.

Access control models: RBAC assigns permissions by role; ABAC evaluates attributes such as purpose, location, and time, which supports purpose-based access.

Consent and preference engineering requires a record of the exact notice version shown, timestamp, scope granted, and a withdrawal path as easy as the grant.

Logging for privacy: record who accessed which personal data and why, protect logs as personal data themselves, and set retention for logs separately.

Privacy-enhancing architecture patterns: data localisation, purpose binding at the API layer, and separating identifiers from attributes in separate stores.