GDPR & Privacy Rules

Collect the minimum personal data needed for a specific, stated purpose, have a lawful basis before you collect it (not after), and be able to actually export or delete a person's data on request — "we'll figure out compliance later" is not a deferred cost, it's a data model that has to be rebuilt.

Data minimization

• Collect only the fields a feature genuinely needs right now, not fields that "might be useful later" — every stored field is a field that must be secured, disclosed in the privacy policy, included in exports, and deleted on request.
• Prefer not collecting a category of data at all over collecting it and relying on access controls to protect it — data that was never collected cannot leak, cannot be subpoenaed, and cannot be misused by an insider.
• Re-evaluate stored fields periodically for ones no feature actually reads anymore, and delete them — dead personal-data columns are pure liability with zero product value.

Lawful basis before collection

• Identify the lawful basis (consent, contract necessity, legal obligation, legitimate interest, etc.) for each category of personal data before building the collection flow, not after — the basis determines what consent UI, retention period, and opt-out mechanism the flow needs, so it isn't a retrofit.
• Never collect data on the assumption that "we'll ask forgiveness" or add a basis after the fact — processing without an established lawful basis is itself the violation, independent of what happens to the data afterward.
• Document the basis per data category in a data inventory / record of processing — this is also what a subject access request or a regulator inquiry will ask you to produce.

Consent that's real

• Make consent granular (separate toggles per purpose — analytics, marketing email, third-party sharing — not one bundled "I agree") and require an affirmative opt-in action, never a pre-checked box or an "I agree" implied by continued use.
• Make withdrawing consent as easy as giving it — a settings toggle that's one click to turn on but requires emailing support to turn off is not a functioning revocation mechanism, and is very likely non-compliant on its own.
• Do not condition access to unrelated functionality on consenting to a purpose that isn't necessary for that functionality (no "consent to marketing email or you can't create an account") — bundled consent obtained under that kind of pressure is not freely given.
• Re-collect consent when the purpose changes materially — consent is scoped to the purpose it was given for, not a blanket permission for whatever comes next.

Retention limits and actual deletion

• Define a retention period per data category tied to the purpose it was collected for, and enforce it with an automated job — a documented retention policy that nothing actually executes is not a retention policy.
• When a user or record is deleted, verify deletion reaches every location the data was copied to: backups (or a documented backup-expiry policy), caches, logs, analytics pipelines, and third-party processors — a delete that only removes the primary DB row while the data lingers in a log line indefinitely does not satisfy the right to erasure.
• Distinguish deletion from anonymization: if you need to retain aggregate/statistical value from a record, irreversibly strip identifying fields rather than keeping the personal data "just in case."

Subject rights handling

• Implement (or clearly document a manual process for) export ("give me my data" in a portable format) and deletion ("erase my data") requests, with a bounded, disclosed response time — GDPR sets expectations here that a support-ticket-with-no-SLA does not meet.
• Make sure export and delete cover the same data inventory — a common gap is an export endpoint that only returns profile fields while forgetting user-generated content, activity logs, or data held by a connected third-party processor.
• Verify the requester's identity before fulfilling an access or deletion request for an account — the same request-handling flow that satisfies a subject right can become an account-takeover vector if identity isn't checked.

Privacy policy accuracy and breach basics

• Keep the privacy policy synchronized with what the code actually does — list every category of data collected, every third-party processor data is shared with, and the real retention period; a policy that's aspirational rather than accurate is itself a compliance gap when audited.
• Update the policy before shipping a feature that changes data collection or sharing, not after a user notices — the policy is documentation of current behavior, not a roadmap.
• Have a basic incident response plan before you need one: how a suspected breach gets detected, who's notified internally, and the applicable regulatory notification window (commonly 72 hours) — figuring this out for the first time during an actual incident guarantees you miss the deadline.