Privacy Engineering Language Exercises

Personally Identifiable Information (PII) is any data that can directly or indirectly identify an individual — including names, email addresses, IP addresses, device IDs, and biometric data. Engineers classify PII by sensitivity tier: direct identifiers (name, national ID), quasi-identifiers (postcode, date of birth), and sensitive special-category data (health, religion, political opinions under GDPR Article 9). Classification drives access controls, encryption requirements, and retention policies. In design reviews, engineers ask "does this field constitute PII?" and "which tier does it fall into?"

Privacy by design (PbD), codified in GDPR Article 25, means embedding privacy protections into system architecture from the outset rather than bolting them on after build. In practice this means data minimisation (collecting only what is necessary), purpose limitation (using data only for its stated purpose), default privacy settings, end-to-end encryption, and pseudonymisation where possible. Engineers use phrases like "the system should collect the minimum data needed for the stated purpose" and "privacy controls should be the default, not an opt-in."

GDPR technical vocabulary includes: data controller (determines purpose and means of processing), data processor (processes on behalf of the controller), data subject (the individual), lawful basis (consent, legitimate interest, contractual necessity), data processing agreement (DPA), records of processing activities (ROPA), data protection impact assessment (DPIA), and supervisory authority. Engineers also reference Article 17 (right to erasure), Article 20 (data portability), and Article 32 (security of processing) in technical discussions.

Data minimisation means collecting, storing, and processing only the data strictly necessary for the defined purpose. Engineers enforce this through schema reviews ("do we need to store the full date of birth or just the year?"), API design (returning only required fields), and retention policies (auto-deleting data after its useful lifetime). In code reviews, a common challenge is "this endpoint exposes the full user object — can we scope it to only the fields the client needs?"

A consent management platform (CMP) collects, stores, and enforces user consent for data processing activities, typically via a cookie banner or preference centre. Engineers integrate CMPs by tagging data collection points with consent purposes (analytics, marketing, personalisation), checking consent signals before initialising tracking scripts, and forwarding consent records to downstream systems. Key vocabulary includes consent string, IAB TCF (Transparency and Consent Framework), consent receipt, and granular consent.

Pseudonymisation replaces direct identifiers with a pseudonym (e.g. replacing user_email with a hashed user_id), such that re-identification is possible only with access to the mapping key. Anonymisation irreversibly removes the ability to re-identify individuals. GDPR still applies to pseudonymised data but relaxes certain obligations; it does not apply to truly anonymised data. Engineers discuss "storing the mapping table in a separate, access-controlled database" as a pseudonymisation safeguard.

Differential privacy is a mathematical framework that provides provable privacy guarantees by adding calibrated statistical noise to query results, ensuring that any individual's data has negligible influence on the output. Engineers describe it as "the output of a query looks statistically similar whether or not any single individual's record is included." It is used in aggregate analytics, machine learning training data, and reporting. Key terms include epsilon (privacy budget), sensitivity, and the Laplace and Gaussian noise mechanisms.

Data retention vocabulary includes retention period (how long data is kept), legal hold (suspension of deletion for litigation), purpose limitation (data may not be kept beyond its stated purpose), data lifecycle, and automated purge. Engineers discuss "a scheduled job that hard-deletes records older than the retention period" and "a soft-delete pattern that sets a deleted_at timestamp and a separate purge job handles physical deletion." Retention schedules are documented per data category and aligned with legal requirements.

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and mitigating privacy risks before launching a new system or processing activity. GDPR Article 35 requires a DPIA when processing is "likely to result in a high risk" — for example, large-scale profiling, systematic monitoring of public spaces, or processing special-category data. Engineers participate by documenting data flows, identifying risks (data breach, function creep, re-identification), proposing mitigations, and confirming residual risk is acceptable.

Implementing erasure requires identifying every store where a user's PII lives: primary databases, analytics warehouses, backups, caches, search indexes, third-party integrations, and logs. Engineers design a "delete cascade" workflow triggered by a deletion request that soft-deletes the record, enqueues downstream deletion tasks, and confirms completion. Key challenges include immutable append-only logs, shared audit trails, and backups. Common patterns include storing PII in a separate table and replacing it with a null or tombstone record on deletion.