GDPR / RULE REFERENCE

Art. 5 — Data minimisation

Article 5(1)(c) sits at the top of GDPR’s principles list because every other obligation flows from it — you cannot breach-protect, retention-manage, or fulfil a DSAR on data you never collected. Regulators read minimisation as an engineering requirement, not a privacy-policy sentence: enforcement consistently punishes collection that outlives its stated purpose — excessive form fields, retained location pings, "just in case" analytics payloads.

The rule

Personal data must be "adequate, relevant and limited to what is necessary" for the stated purpose. Collecting more than you need is non-compliant by itself, whatever your consent banner says.

What it means for how you build

Collect less. Strip identifiers at the boundary, before storage or logging — a field you never store can never leak, be breached, or need a DSAR.

Self-check

Can you name the declared purpose for every persisted field — and would deleting it break that purpose?
Do ingestion paths drop unknown keys before storage, or does your schema accept arbitrary payloads?
Are log and analytics payloads filtered at the boundary, not just trusted internally?
Is retention defined per field or data class somewhere other than someone’s memory?

Common pitfalls

Minimising at the UI while the API still accepts the same fields "for debugging" — the server boundary is what counts.
Treating analytics as exempt: event payloads are personal data too, and "we might need it later" is not a purpose.
Collecting full objects then redacting in the warehouse — the PII already lived in your logs.

How the engine checks it

POST /v1/sanitize — boundary redaction of SSN, email, phone, card and key fields before data reaches storage.

Sources

Related rules

Last reviewed 2026-11-01.