Data Privacy

When to Use

• Use when: a feature collects or stores personal information
• Use when: building a user data export or deletion flow
• Use when: auditing an existing system for privacy compliance
• Use when: adding analytics or third-party tracking
• Do NOT use for: general security hardening — use red-team-check

PII Classification

Not all personal data is equal. Classify before designing.

Rule: If data can identify a natural person directly or in combination — it is PII. Treat it accordingly.

Data Minimization

Collect only what is necessary for the stated purpose. Delete when no longer needed.

Before collecting any field, ask:
  1. Why do we need this?
  2. What specific feature breaks without it?
  3. When do we delete it?

If no clear answer to all three → don't collect it.

Schema checklist:

• Phone number stored but never used for anything? → Remove the column
• Full birthdate collected but only age group needed? → Store age range, not DOB
• IP addresses logged forever? → Anonymize after 90 days

GDPR User Rights (Implementation)

Every system storing EU user data must implement:

Deletion pipeline design

User requests deletion:
1. Mark account deleted_at = now(), disable login
2. Queue async job: delete or anonymize all PII
3. Cascade: delete from: profile, orders (anonymize), logs (anonymize), analytics events
4. Third-party data: send deletion request to downstream processors (email provider, analytics)
5. Confirm to user within 30 days

Anonymize (not delete) where legal retention required:
  user_id → "anon-{hash}", email → null, name → "Deleted User"

Consent Management

Consent must be:
  ✓ Freely given (no consent wall blocking core service)
  ✓ Specific (separate consent per purpose)
  ✓ Informed (clear language, not legalese)
  ✓ Unambiguous (explicit opt-in — pre-ticked boxes invalid under GDPR)
  ✓ Withdrawable at any time (as easy to withdraw as to give)

Consent record (store with the data)

{
  "user_id": "usr-123",
  "purpose": "marketing_emails",
  "granted": true,
  "granted_at": "2025-01-15T10:00:00Z",
  "mechanism": "checkbox_signup_form_v2",
  "ip_address": "hashed or omitted",
  "version": "tos-2025-01"
}

Cookie consent

• Strictly necessary cookies: no consent needed
• Analytics, marketing: explicit opt-in required before setting
• Preference center must be accessible at any time (not just on first visit)

Data Retention Policy

Define and enforce retention periods per data type:

Implement as a scheduled job: run daily, delete records past retention window.

Privacy-by-Design Checklist

□ Data minimization: only collect fields with a documented, current purpose
□ PII classification: every table with personal data labeled (Direct/Indirect/Sensitive)
□ Encryption at rest: PII fields encrypted in DB (or full-disk encryption documented)
□ Encryption in transit: TLS 1.2+ on all data paths
□ Access control: PII accessible only to services/roles that need it
□ Deletion pipeline: right to erasure implemented and tested end-to-end
□ Consent records: stored alongside the data they authorize
□ Retention schedule: defined and enforced by automated job
□ Third-party processors: DPA (Data Processing Agreement) in place with each vendor
□ Logs: PII not present in application logs (audit 5 representative log lines)

Anti-Fake-Pass Rules

Before claiming a feature is privacy-compliant, you MUST show:

• PII fields identified and classified (direct/indirect/sensitive)
• Data minimization applied — every collected field has a documented purpose
• GDPR rights: access and erasure at minimum implemented and manually tested
• Consent stored with timestamp and mechanism — pre-ticked boxes absent
• Retention period defined and enforced (not just documented)

Reference: gates/anti-fake-pass-gate.md