Wann Privacy by Design gilt und was Sie als Naechstes tun sollten

Privacy by Design gilt immer dann, wenn ein SaaS-Team ein Produkt, einen Workflow, einen Anbieter, ein internes Tool, eine Datenpipeline oder einen Kundenprozess plant oder aendert, der personenbezogene Daten betrifft. Die richtige Reaktion ist nicht, Delivery zu stoppen. Das Team muss frueh klaeren, welche Daten notwendig sind, welche Defaults gelten, wer Zugriff hat, wie lange Daten aufbewahrt werden, welche Anbieter beteiligt sind und welche Nachweise die Entscheidung belegen.

Artikel 25 DSGVO verlangt geeignete technische und organisatorische Massnahmen sowie Datenschutz durch Voreinstellung. Standardmaessig sollen nur personenbezogene Daten verarbeitet werden, die fuer den jeweiligen Zweck notwendig sind. Die EDPB-Leitlinien behandeln dies als Pflicht ueber den Lebenszyklus der Verarbeitung.

Einfache Entscheidungsregel

Privacy by Design gilt, wenn eine Aenderung Erhebung, Nutzung, Weitergabe, Sichtbarkeit, Speicherung, Loeschung, Profiling, Analytics, Export oder Wiederverwendung personenbezogener Daten betrifft.

Dazu gehoeren neue Datenfelder, neue interne Sichtbarkeit, neue Subprozessoren, Exporte, KI-Verarbeitung, Retention-Aenderungen, Loeschlogik, Monitoring oder geaenderte Defaults. Der Ausloeser sollte in der Produktplanung sichtbar sein, nicht erst nach der Implementierung.

Typische Ausloeser

Neue Features loesen meist eine Pruefung aus, wenn sie Daten direkt erheben, bestehende Daten anders anzeigen oder neue interne Sichtbarkeit schaffen. Beispiele sind Onboarding-Felder, Dashboards, Reports, Berechtigungen, Exporte, Benachrichtigungen, Analytics und Admin-Kontrollen.

Auch interne Workflows zaehlen: CRM, Support, Data Warehouse, Admin-Konsole, Billing, Customer Success und Debugging koennen personenbezogene Daten verarbeiten. Die Bewertung muss dem Datenfluss folgen, nicht nur dem Kundenscreen.

Anbieter, KI und DPIA

Ein neuer Prozessor, ein AI-Anbieter, ein Support-Tool oder eine Analytics-Plattform kann Zweck, Zugriff, Transfer, Retention und Loeschung veraendern. Vor dem Go-live sollte das Team Datenkategorien, Subprozessoren, Vertragslage, Security-Evidence und Loeschsupport pruefen.

Nicht jede Pruefung braucht eine DPIA. Eskalieren Sie bei sensiblen Daten, Kindern, grossflaechigem Monitoring, Profiling, automatisierten Entscheidungen, KI-Verarbeitung, ungewoehnlicher Retention, breitem internen Zugriff, Transfers oder unerwarteter Wiederverwendung.

Was als Naechstes zu tun ist

Erstens: Bauen Sie den Trigger dort ein, wo Arbeit beginnt, etwa Product Brief, Ticket, Architekturreview, Vendor Intake, Data-Warehouse-Change oder Release-Checklist.

Zweitens: Weisen Sie Owner zu. Product verantwortet Zweck, Scope und Defaults. Engineering verantwortet technische Kontrollen, Berechtigungen, Loeschung und Implementierungsnachweise. Security prueft Zugriff. Legal oder Privacy entscheidet ueber Auslegung und Eskalation. Compliance oder Operations haelt Evidenz und Follow-ups zusammen.

Drittens: Dokumentieren Sie den Mindestrecord: Feature, Owner, Zweck, Datenkategorien, Betroffene, Zugriff, Anbieter, Defaults, Retention, Loeschpfad, Risiken, Entscheidung, Freigabe und Evidenzort. Verbinden Sie diese Entscheidung mit dem Release-Gate.

FAQ

Wann gilt Privacy by Design fuer SaaS-Teams?

Wenn ein Produkt, interner Workflow, Anbieter, Datenpipeline, Analytics-Setup, KI-Feature, Export, Berechtigungsmodell, Retention-Regel oder Default personenbezogene Daten betrifft.

Was sollte zuerst dokumentiert werden?

Starten Sie mit Trigger und Entscheidungsrecord. Danach beheben Sie die riskantesten Defaults, Zugriffspfade, Anbieterfluesse, Retention-Annahmen oder Loeschluecken.

Braucht jede Pruefung Legal Approval?

Nein. Niedrigrisiko-Aenderungen brauchen oft nur einen kurzen Record. Hoeheres Risiko sollte frueh zu Privacy, Legal, Security, Vendor Review, DPIA oder Executive Acceptance eskalieren.