Privacy by design: data you never collected can never be breached

Data minimization is the principle of collecting, storing, and retaining only the specific data a feature actually requires to function — not whatever's convenient to grab "in case it's useful later." A signup form asking for a date of birth only to verify a user is over 13 needs to know whether they're over 13, not their exact birthdate — storing the full, precise birthdate anyway, because it was easy to add one more form field, creates a liability (a sensitive personal detail, now sitting in a database, fully exposed in the event of any future breach) with zero corresponding benefit to the feature it was collected for.

Collecting extra data "just in case a future feature needs it" feels efficient in the moment, but it means that data sits around, unused, as pure risk with no offsetting benefit until that hypothetical future feature actually materializes — and if it never does, the data was a liability the entire time for nothing. The right default is collecting what's needed for what's actually being built now, and adding a new field deliberately later if a genuine new need for it actually arises — the same "don't build for hypothetical future requirements" discipline this curriculum's own engineering practice generally favors, applied specifically to data collection.

Anonymization removes or irreversibly transforms identifying information so the original individual genuinely can't be re-derived from the remaining data — true anonymization is a strong guarantee, but harder to achieve than it looks (a supposedly "anonymized" dataset can sometimes still be re-identified by cross-referencing it against other available data). Pseudonymization replaces an identifier with a different, consistent token (a random ID instead of an email address) — useful for analytics that need to track the same user's behavior across events without storing their actual identity directly in that dataset, but reversible if the mapping between the token and the real identity is ever compromised, which is a meaningfully weaker guarantee than genuine anonymization and should never be described as equivalent to it.

A system that retains every record forever, by default, accumulates an ever-growing pool of sensitive data with no corresponding growth in legitimate need for most of it — old, inactive user accounts' personal details, years-old support tickets containing unredacted personal information, raw logs from long-resolved incidents. A deliberate retention policy (delete or anonymize data automatically after it's no longer needed for its original purpose, or after a defined period) bounds how much historical data is actually sitting around as risk at any given moment, rather than letting every past user's data accumulate as a permanently growing liability.

Regulations requiring that a user be able to request deletion of their personal data (GDPR's "right to erasure" being the most widely known) translate into a real, concrete engineering requirement: a system needs to actually be able to locate and delete a given individual's data across every table, every backup, every downstream analytics pipeline it was copied into — which is a genuinely hard requirement to satisfy after the fact in a system that was never designed with it in mind, and a comparatively easy one for a system that tracked data lineage and ownership deliberately from the start. Treating this as a day-one design constraint, not a feature bolted on once legally required, is the actual practical lesson here.