Haeufige Privacy-by-Design-Fehler, die SaaS-Teams immer noch machen

Privacy by Design scheitert, wenn SaaS-Teams es als spaeten Legal-Check behandeln. Die praktische Aufgabe ist, Datenschutz in Produktplanung, Defaults, Zugriff, Aufbewahrung, Anbieterentscheidungen, Release-Gates und Nachweise einzubauen, bevor eine Funktion schwer zu aendern ist.

Artikel 25 DSGVO verlangt geeignete technische und organisatorische Massnahmen und Datenschutz durch Voreinstellung. Standardmaessig sollen nur personenbezogene Daten verarbeitet werden, die fuer den konkreten Zweck notwendig sind. Die EDPB-Leitlinien machen deutlich, dass dies ueber den gesamten Lebenszyklus der Verarbeitung gilt.

Zu spaet starten

Der haeufigste Fehler ist ein Review erst kurz vor Release, waehrend eines Audits oder bei einer Kundenpruefung. Dann sind Datenmodell, Berechtigungen, Analytics-Events, Anbieter und Retention oft schon gebaut. Privacy by Design sollte beginnen, wenn das Team noch ueber Zweck, Datenfelder und Defaults entscheidet.

Ein Product Brief sollte fragen, ob eine Aenderung personenbezogene Daten erhebt, zeigt, teilt, speichert, loescht, profiliert, exportiert oder fuer neue Zwecke nutzt. Bei Ja braucht die Aenderung einen sichtbaren Ausloeser und eine risikogerechte Pruefung.

Privacy by Design mit DPIA verwechseln

Eine DPIA ist wichtig fuer hoeheres Risiko, aber nicht das ganze Programm. Auch ohne DPIA muessen Teams Datenminimierung, Zweckbindung, Zugriff, Defaults, Aufbewahrung, Loeschung und Nachweise beruecksichtigen.

Ein Customer-Success-Dashboard kann engere Rollenrechte brauchen. Ein Signup-Flow kann mit weniger Pflichtfeldern auskommen. Ein Supportprozess braucht eventuell einen Loeschpfad fuer Anhaenge. Die DPIA ist ein Eskalationsweg, nicht der einzige Weg.

Nur die sichtbare Oberflaeche pruefen

SaaS-Daten bewegen sich durch Logs, Admin-Panels, CRM, Support-Tools, Analytics, Data Warehouses, KI-Funktionen, Backups, Exporte und Subprozessoren. Ein Review, das nur den Kundenscreen betrachtet, uebersieht oft die eigentlichen Risiken.

Teams sollten dem Datenfluss folgen: Wo werden Daten erhoben, transformiert, gespeichert, angezeigt, exportiert, geloggt und geloescht? Auch abgeleitete Daten, Embeddings, Reports und Tickets gehoeren in die Betrachtung.

Zu breite Defaults waehlen

Privacy by Default scheitert oft an Bequemlichkeit. Alle Admins erhalten Exportrechte, Integrationen sind automatisch aktiv, Logs bleiben unbegrenzt, Profile sind zu breit sichtbar oder Onboarding-Felder sind Pflicht, obwohl sie nicht notwendig sind.

Gute Defaults beginnen mit dem Minimum: minimale Daten, minimale Sichtbarkeit, minimale Aufbewahrung und minimaler Zugriff fuer den Zweck. Erweiterungen koennen bewusst aktiviert werden, wenn sie gerechtfertigt sind.

Ownership und Nachweise fehlen

Privacy by Design wird langsam, wenn niemand weiss, wer den naechsten Schritt besitzt. Produkt verantwortet Zweck, Scope und Defaults. Engineering verantwortet technische Kontrollen, Zugriff, Loeschung und Implementierungsnachweise. Security prueft Zugriff und Monitoring. Legal oder Privacy interpretiert Anforderungen und Eskalation. Compliance oder Operations sichert Workflow, Ablage und Follow-ups.

Ebenso wichtig ist der Nachweis. Ein brauchbarer Record nennt Feature, Owner, Zweck, Datenkategorien, Betroffene, Zugriff, Anbieter, Defaults, Retention, Loeschpfad, Risikoentscheidung, Freigabe und Fundort der Evidenz. Ohne diesen Record muss das Team spaeter aus Tickets und Chats rekonstruieren, warum eine Entscheidung getroffen wurde.

Drift nach dem Launch ignorieren

Nach dem Launch aendern sich Produkte weiter. Sales will mehr Sichtbarkeit, Support fuegt Freitextfelder hinzu, Analytics expandiert, Anbieter wechseln oder Logs werden laenger gespeichert. Jede Aenderung kann vertretbar sein, aber die urspruenglichen Annahmen koennen falsch werden.

Deshalb gehoert Privacy by Design in Change Management. Wenn sich Datenfelder, Berechtigungen, Anbieter, Exporte, Retention, KI-Funktionen oder Defaults aendern, sollte das Team pruefen, ob der alte Review noch traegt.

FAQ

Was sollten Teams ueber Privacy by Design verstehen?

Privacy by Design ist ein Betriebsworkflow. Er sollte Produktplanung, Defaults, Zugriff, Retention, Anbieter, Release-Checks und Evidenz praegen.

Warum ist Privacy by Design praktisch wichtig?

Viele Risiken entstehen durch normale Produktentscheidungen. Ein wiederholbarer Workflow hilft, frueher zu entscheiden und spaeter Kunden-, Audit- oder Regulatorfragen sicherer zu beantworten.

Was ist der groesste Fehler?

Der groesste Fehler ist, Privacy by Design als einmalige Rechtsauslegung zu behandeln, statt Owner, Ausloeser, Review-Schritte, Evidenz und Change Management festzulegen.