The GDPR Mental Model

Data minimization: not collecting is cheaper than protecting#

Data minimization — collecting only what a specific, stated purpose actually requires — is GDPR's second core principle, and also just good engineering economics independent of any regulation: a field never collected needs no classification, no access control scoping, no encryption consideration, no place in a deletion request. The cheapest, most reliable control over a sensitive field is not having it in the first place.

Purpose limitation: data has a reason, not just a schema#

Data collected for one stated purpose being silently repurposed for another — a support email collected to resolve a ticket, later mined for marketing — is exactly what Data Contracts' semantic guarantees exist to make explicit and reviewable. A contract that states not just a field's type but why it was collected turns "can we use this for X" into a question with a documented answer, rather than something discovered by whoever happens to notice the field exists and looks useful.

Storage limitation: retention has to end somewhere#

Data minimization has a time dimension too — retaining data indefinitely "in case it's useful later" is the same anti-pattern as collecting it without a stated purpose, just deferred. A defined retention period, with an actual automated deletion process behind it, keeps the total surface area of sensitive data from only ever growing.

The right to erasure requires lineage, not just a delete statement#

The right to erasure sounds mechanically simple — delete this person's data — and is only actually achievable if Data Lineage and Cataloging was already in place before the request arrived:

Delete request for customer 42's data:
  Without lineage: delete from the obvious source table,                    hope nothing downstream still has a copy
  With lineage:     delete from the source table AND every                     derived table lineage shows actually                     inherited that customer's data

Why these principles hold regardless of jurisdiction#

Minimizing what is collected, limiting how it is used, bounding how long it is kept, and being able to find and remove it on request are not burdens specific to one regulation — they are the same discipline that reduces classification burden, shrinks the attack surface Encryption at Rest and in Transit has to cover, and makes every other article in this module's job smaller. Treating GDPR's principles as good system design, applicable everywhere, tends to produce a better-governed system than treating them as a checklist to satisfy only where legally required.

Common mistakes#

Treating this as a one-time compliance project#

Minimization, purpose limitation, and retention are ongoing engineering disciplines, not a single audit completed once and filed away — new fields get added, new purposes get invented, and each one needs the same scrutiny the original data collection got.

Collecting data "just in case it's useful later"#

The direct opposite of data minimization, and a real, recurring source of governance burden: every speculatively-collected field is something that now needs classification, access control, and inclusion in every future deletion request, for a benefit that may never materialize.

Discovering lineage was never tracked only when a deletion request arrives#

By the time an erasure request needs an answer, it is too late to start building the lineage tracking that answer depends on. Data Lineage and Cataloging has to already be in place before it is needed.

Further reading#

• General Data Protection Regulation — full legal text — the actual regulation, for anyone needing the precise legal requirements rather than the engineering principles summarized here.
• Article 17: Right to erasure — the specific provision behind this article's lineage discussion.
• Data minimization and Right to be forgotten — background on the two principles covered in most depth above.

See also#