数据最小化实践清单

Data Minimization Best Practices for Social Media Applications

1. Purpose limitation and lawful basis

• Define granular purposes per feature (e.g., account security, content delivery, fraud detection). Prohibit secondary use without a compatible purpose.
• Map each purpose to a lawful basis (GDPR Art. 6) and document necessity. Avoid relying on “legitimate interests” for high‑risk profiling without a robust LIA.
• Under CPRA/CCPA, collect, use, retain, and share only what is reasonably necessary and proportionate to the disclosed purposes (Cal. Civ. Code §1798.100(c); CPPA Regs §7002).

2. Collect the minimum data fields

• Make all non-essential fields optional. Use progressive profiling triggered only when a feature requires it.
• Avoid collecting precise geolocation, contact lists, messages’ content metadata, biometric templates, or device fingerprints unless strictly necessary and lawful.
• Prefer coarse location over precise; birth year/age band over full date of birth; hashed email for account recovery over phone number if feasible.

3. Sensitive data restrictions

• Treat special category data (GDPR Art. 9) and CPRA “sensitive personal information” (e.g., precise geolocation, racial/ethnic origin, union membership, health, biometrics) as out of scope unless the feature cannot function without it and you have an appropriate legal basis (e.g., explicit consent in the EU).
• Do not use sensitive data for advertising or recommendations without explicit consent where required; provide a separate opt-in and separate controls.

4. Default-deny OS and device permissions

• Request permissions (camera, microphone, photos, contacts, precise location, motion sensors, clipboard) only at the moment of need, and only while in use.
• Provide fully functional fallbacks if the user denies permission; degrade gracefully.

5. Identity and identifiers

• Avoid persistent, cross-context identifiers. Rotate identifiers per device/session and per purpose; silo advertising IDs from security IDs.
• Prohibit fingerprinting and probabilistic IDs unless strictly required for security/fraud, with documented necessity and controls.

6. On-device and edge processing

• Run safety classification, ranking, and content personalization on-device where feasible; transmit only minimal signals needed for the server-side function.
• Use privacy-preserving techniques (local differentially private telemetry, sketching, Bloom filters) for aggregates instead of raw event streams.

7. Analytics and measurement

• Collect only event fields needed for defined metrics. Strip or hash free-text and URLs; truncate IPs; drop exact timestamps if not needed.
• Apply aggregation and k-anonymity thresholds before reporting. Disable granular analytics for minors by default.

8. Advertising and recommendations

• Prefer contextual advertising and on-device interest inference. Treat cross-context behavioral advertising as opt-in in the EU and provide “Do Not Sell/Share” opt-out under CPRA.
• Honor the Global Privacy Control (GPC) signal for sale/share opt-outs (CPPA Regs §7025–7026). Do not sync user data with third-party ad networks without an appropriate legal basis and contract.

9. Third-party SDKs and data sharing

• Minimize or eliminate third-party SDKs for ads/analytics; prefer server-to-server with strict data scopes. Disable SDK features you do not use.
• Execute DPAs (processors) and assess processors’ data minimization. For the EU, implement SCCs for international transfers and complete a transfer risk assessment.
• Block outbound telemetry not documented in your ROPA. Use network controls and mobile OS privacy manifests to enforce data boundaries.

10. Retention and deletion

• Set purpose-based retention limits with documented schedules. Default to short retention for logs (e.g., 7–30 days), longer only where necessary (e.g., fraud).
• Implement automated deletion and aggregation jobs. Propagate deletions to backups via short backup TTLs and documented restore/deletion processes.

11. Access control and data scoping

• Enforce least privilege and purpose-based access controls. Segregate datasets by purpose (e.g., security, analytics, ads) and ban cross-purpose joins.
• Use pseudonymization with rotating salts; store key material separately. Log and review access to sensitive tables.

12. User controls and just-in-time notices

• Provide clear toggles per data category/purpose (e.g., personalized ads, precise location, contacts upload). Make “off” the default for non-essential purposes.
• Use just-in-time notices explaining the minimum data needed for the specific feature; avoid dark patterns.

13. Children and teens

• For under-13 users (COPPA) and minors where applicable, disable targeted advertising, limit data collection to what is necessary for the service, and provide age-appropriate defaults.
• Use low-intrusion age estimation methods; do not retain biometric data solely for age checks.

14. Logging and diagnostics

• Collect only essential diagnostic fields; avoid storing full request bodies, tokens, message contents, or attachments in logs.
• Redact PII at the source; sample logs where feasible; use short retention and strict access.

15. Security controls that support minimization

• Encrypt data in transit and at rest; use end-to-end encryption for private messaging so servers cannot access content.
• Prefer ephemeral tokens and short-lived credentials. Separate encryption domains for different purposes.

16. Data governance and accountability

• Maintain an up-to-date data map and Records of Processing (GDPR Art. 30) with purpose, lawful basis, data fields, recipients, and retention.
• Require Privacy by Design reviews (GDPR Art. 25) for new features; run DPIAs for high-risk processing (e.g., large-scale profiling, sensitive data).
• Establish a data field intake process with necessity tests, and track minimization KPIs (e.g., average fields per user, retention days, third-party SDK count).

17. Testing and experimentation

• Limit A/B test dimensions and duration; avoid user-level persistent IDs where not required.
• Use aggregated or on-device experimentation frameworks when feasible; delete raw experiment data at conclusion.

18. Backups and replicas

• Avoid copying full datasets to non-production. Use synthetic or minimized data in test environments; if production data is required, apply strict masking and access controls.

19. Internationalization and regionalization

• Localize processing where required by law or risk assessments; segregate EU user data to limit cross-border transfers.
• Ensure purposes and data fields remain consistent across regions; do not expand collection in less regulated markets.

20. Verification and audit

• Perform periodic audits for unused fields, SDKs, and tables; remove or stop collecting anything not tied to an active, documented purpose.
• Validate that opt-outs and GPC signals suppress collection/sharing across systems. Test deletion propagation end-to-end.

Regulatory anchors to keep in scope

• GDPR Art. 5(1)(c) (data minimization), Art. 6 (lawful bases), Art. 9 (special categories), Art. 25 (privacy by design), Art. 30 (ROPA), Art. 35 (DPIA).
• CPRA/CCPA: purpose limitation and data minimization (Cal. Civ. Code §1798.100(c)), sale/share opt-outs (§1798.120), honoring opt-out preference signals; CPPA Regulations §§7002 (purpose limitation), 7025–7026 (GPC).
• ePrivacy/cookie rules for tracking technologies; COPPA for under-13 users in the U.S.

Implementation tip

• Start with a data inventory and purpose-to-field matrix; block any collection or sharing not mapped to a purpose and lawful basis, and enforce via code-level schemas, privacy manifests, and DLP controls.

Best Practices zur Datenminimierung in Unternehmens‑Analytics‑Plattformen

Grundlagen und Rechtsrahmen

• Zweckbindung und Datenminimierung: Prozesse an den Grundsätzen des Art. 5 Abs. 1 lit. b und c DSGVO ausrichten; CPRA/CCPA fordert Sammlung, Nutzung und Aufbewahrung nur soweit „vernünftigerweise notwendig und verhältnismäßig“ für den angegebenen Zweck.
• Speicherbegrenzung: Art. 5 Abs. 1 lit. e DSGVO; klare, dokumentierte Aufbewahrungsfristen je Datenkategorie (CPRA verlangt die Offenlegung und Begründung der Fristen).
• Datenschutz durch Technikgestaltung und Voreinstellungen: Art. 25 DSGVO; standardmäßige Plattformkonfigurationen auf minimale Datenerhebung/‑sichtbarkeit ausrichten.
• DPIA/PbD: Datenschutz‑Folgenabschätzung für hochriskante Analysen (Art. 35 DSGVO); Privacy‑by‑Design Prinzipien über den gesamten Datenlebenszyklus.

Governance und Inventarisierung

• Dateninventar und Katalog: Vollständige, gepflegte Übersicht aller Datensätze, mit Klassifizierung (personenbezogen, besonders sensibel, pseudonymisiert, anonymisiert) und Zweckzuordnung.
• Datenfluss- und Lineage-Tracking: Nachvollziehbarkeit, wo personenbezogene Daten entstehen, transformiert oder weitergegeben werden; automatisierte lineage in ETL/ELT.
• Zweckkompatibilitätsprüfung: Vor jeder neuen Analyse prüfen (Art. 6 Abs. 4 DSGVO), ob der neue Zweck mit dem ursprünglichen vereinbar ist; andernfalls neue Rechtsgrundlage/Einwilligung.
• Minimierungs‑KPIs: Metriken wie Anzahl sensibler Spalten pro Dataset, Anteil aggregierter statt Rohdaten, Löschquote fristgerecht, Abdeckung pseudonymisierter Pipelines.

Erhebung und Ingestion

• „Need‑to‑collect“-Assessment: Vor Aufnahme neuer Quellen fachliche Notwendigkeit, Rechtsgrundlage, Zweck und Minimierungsalternativen dokumentieren.
• Standardisierte Aufnahmeschemata: PII‑Spalten sind opt‑in und explizit begründet; Default‑Blocklisten für hohes Risiko (z. B. freie Textfelder, genaue Geodaten).
• Edge‑/Quellseitige Aggregation: Ableitungen/Feature‑Engineering möglichst am Rand durchführen; nur aggregierte oder pseudonymisierte Features einspeisen.
• Deduplication und Normalisierung: Dubletten entfernen, unnötige Attribute streichen; nur eindeutige, für den Zweck erforderliche Attribute halten.

Datenmodellierung und Transformation

• Minimalistische Schemas: Trennen von Identifikatoren und Analysemerkmalen; separate, streng abgesicherte Identitätsschichten.
• Pseudonymisierung (Art. 4 Nr. 5 DSGVO): Stabiler, zweckgebundener Token/Schlüssel; Schlüsselverwaltung getrennt und stark kontrolliert.
• Anonymisierung: Risiko‑basierte Verfahren (k‑Anonymität, l‑Diversität, t‑Closeness) mit Re‑Identifikationsprüfung; dokumentierte Methodik und Tests gegen externe Hilfsdaten.
• Differential Privacy: Rauschzugabe mit verwaltetem Epsilon‑Budget für häufige Abfragen/Statistiken; Durchsetzung von Privacy‑Budgets auf Query‑Ebene.
• Small‑Cell‑Suppression: Unterdrückung/Pooling von Ergebniszellen mit kleiner Fallzahl zur Vermeidung von Rückschlüssen.
• Feature‑Selektion: Entfernen korrelierter oder hochsensibler Merkmale ohne sichtbaren Nutzwert; regelmäßige Utility‑Privacy‑Abwägung.

Speicherung und Zugriff

• Least Privilege: Rollen‑/Attributbasierte Zugriffskontrolle (RBAC/ABAC) bis auf Zeilen‑/Spaltenebene; Standardrollen ohne Zugriff auf Roh‑PII.
• Dynamische Maskierung: Laufzeitmaskierung für sensible Spalten (z. B. Teilmaskierung, Reduktion von Präzision); differenzierte Masken je Rolle/Zweck.
• Verschlüsselung: Starke Verschlüsselung in Ruhe und Übertragung; getrennter, gehärteter Key‑Store; regelmäßige Rotation.
• Daten‑Abschichtung: Mehr‑Zonen‑Architektur (Raw/Curated/Analytics) mit abnehmendem PII‑Gehalt; Übergang nur nach Minimierungs‑Checks.
• Nicht‑Produktionsumgebungen: Keine Roh‑PII in Test/Dev; synthetische oder stark anonymisierte Daten; strikte Freigabeprozesse.

Nutzung, Auswertung und Outputs

• Standard‑Aggregationen: Dashboards/Reports liefern aggregierte Kennzahlen; Rohdatenexporte sind deaktiviert oder streng reglementiert.
• Ergebnis‑Kontrollen: Schwellenwerte, Rauschen, Sampling oder Generalisierung vor Freigabe von Analyseergebnissen; automatische Prüfroutinen gegen identifizierbare Outputs.
• Join‑Sicherheit: Privacy‑preserving Linkage (z. B. gehashte, gesalzene Schlüssel) statt Klartext‑Joins; Minimierung von Cross‑Domain‑Verknüpfungen.
• API/Query‑Governance: Whitelists für zulässige Abfragen; Limitierung von Abfragefrequenz und Ausgabefeldern; Audit‑Logs mit Zweckangabe.

Aufbewahrung und Löschung

• Retention‑Policies: Zweck‑ und risikobasierte Fristen; automatische Löschung/Archivierung; CPRA‑konforme Offenlegung der Fristen gegenüber Betroffenen.
• Löschbarkeit: Technische Verfahren für vollständige Löschung in Primär‑ und Sekundärspeichern (inkl. Backups durch zeitversetzte, automatische Purge‑Prozesse).
• Aktualität/Genauigkeit: Regelmäßige Bereinigung veralteter oder unnötiger Daten; Minimierung durch Entfernung nicht mehr zweckdienlicher Attribute.

Einwilligungen und Präferenzen

• Consent‑Tagging: Speicherung und Durchsetzung von Einwilligungsstatus je Datensatz/Feld; Datenfluss blockiert bei fehlender Rechtsgrundlage.
• Opt‑Out/Do‑Not‑Sell/Share (CCPA/CPRA): Präferenzsignale technisch durchsetzen; Segmentierung, die keine PII erfordert, bevorzugen.

Externe Weitergabe und Anbieter

• Datenfreigabe nur in minimierter Form: Aggregierte, anonymisierte oder pseudonymisierte Datasets; Data‑Sharing‑Agreements mit Minimierungs‑ und Re‑Identifikationsverboten.
• Due‑Diligence: Technische und organisatorische Prüfungen von Drittanbietern; Bindung an Minimierungs‑Standards, Aufbewahrungsfristen und Löschpflichten.

Überwachung und Kontrolle

• Kontinuierliches Monitoring: Erkennung von PII‑Leakage, übermäßiger Attributnutzung und Zweckabweichungen; automatische Alarme.
• Audits: Regelmäßige Reviews von Pipelines, Datenmodellen und Zugriffsrechten; Nachweise für DSGVO/CPRA‑Konformität.
• Schulung: Rollenbezogene Trainings für Daten‑Teams zu Minimierungsprinzipien, Tools und rechtlichen Anforderungen.

Spezielle Muster für KI/ML‑Analytics

• Federated Learning/On‑Device‑Training: Vermeidung zentraler Rohdatenhaltung; Aggregation von Modellupdates mit DP.
• Training auf minimalen Datensätzen: Strenge Feature‑Auswahl; Evaluierung, ob synthetische Daten oder Transfer‑Learning ausreichend sind.
• Model Cards und Data Sheets: Dokumentation der verwendeten Datenkategorien, Minimierungsentscheidungen und Risiken.

Implementierungshinweise

• „Shift‑Left“-Privatsphäre: Minimierungsprüfungen früh in ETL/ELT; CI/CD‑Gates für Datenschutz‑Checks.
• Standard‑Patterns: Bibliotheken/Pipelines für Pseudonymisierung, Aggregation, Differential Privacy als wiederverwendbare Bausteine.
• Risiko‑Management: Formale Re‑Identifikationsrisikoanalyse vor Freigaben; Entscheidung und Verantwortlichkeiten dokumentieren.

Diese Best Practices richten sich auf die konsequente Reduktion personenbezogener Daten über den gesamten Analytics‑Lebenszyklus, die rechtliche Absicherung nach DSGVO und CPRA/CCPA sowie die technische Durchsetzung durch Plattform‑Kontrollen.