Häufige Fehler bei Auskunftsersuchen von Betroffenen, die SaaS-Teams immer noch machen

Die häufigsten DSAR-Fehler in SaaS-Unternehmen sind selten offene Compliance-Verweigerungen. Typischer sind operative Abkürzungen: ein Ersuchen wie ein Support-Ticket behandeln, nur das bequemste System durchsuchen, Controller- und Processor-Rollen vermischen, Identitätsprüfungen improvisieren und kaum Nachweise darüber behalten, was geprüft und warum entschieden wurde. Artikel 12 und 15 DSGVO verlangen mehr. Betroffene können eine Bestätigung der Verarbeitung, Zugang zu ihren personenbezogenen Daten und ergänzende Informationen verlangen. Die Antwort muss zudem klar, zugänglich und verteidigbar sein.

Genau deshalb decken Auskunftsersuchen Reifegradlücken so schnell auf. Ein Ersuchen kommt über Support, Sales, Privacy oder ein Trust-Postfach herein, und plötzlich muss das Unternehmen beweisen, wo Daten liegen, wer sie beschaffen kann, wann ein Auftragsverarbeiter helfen muss und wie Schwärzungen oder Einschränkungen begründet werden.

Wenn Sie zuerst das Fundament wollen, starten Sie mit Auskunftsersuchen von Betroffenen: Praktischer Leitfaden für SaaS-Teams, Wie man Auskunftsersuchen von Betroffenen operativ umsetzt, ohne die Produktentwicklung zu bremsen und Checkliste für Auskunftsersuchen von Betroffenen für Gründer und Compliance-Leads. Hilfreich ist außerdem warum Privacy-Impact-Reviews in der Produktplanung beginnen sollten.

Warum diese Fehler immer wieder auftauchen

Viele Teams verstehen das Auskunftsrecht theoretisch. Der wiederkehrende Fehler ist operativ, nicht definitorisch. Die ICO-Guidance stellt klar, dass Menschen keine bestimmte Formulierung, kein spezielles Formular und nicht einmal die Worte "subject access request" brauchen. Jedes Frontline-Team kann also den Startpunkt einer Frist auslösen. Artikel 15 verlangt außerdem mehr als einen Roh-Export: Bestätigung, Zugang und Informationen zu Zwecken, Kategorien, Empfängern, Aufbewahrung, Herkunft und gegebenenfalls automatisierten Entscheidungen.

Fehler 1: Das Ersuchen wie ein einmaliges Inbox-Ereignis behandeln

Ein häufiger Fehler ist die Annahme, ein DSAR beginne erst, wenn Legal es sieht, und ende mit einem Account-Export. In der Praxis berührt ein echtes DSAR Support, Privacy, Engineering, Security, Billing, CRM-Owner und manchmal externe Processor. Wenn das Unternehmen das Ersuchen nicht als funktionsübergreifenden Ablauf behandelt, passiert schnell Folgendes:

• Die Anfrage wird zu spät erkannt.
• Das falsche Team sucht im falschen System.
• Niemand kann erklären, wem der nächste Entscheidungsschritt gehört.

Deshalb ist Erkennung so wichtig. Wenn Support, Customer Success und Shared-Inbox-Owner ein Auskunftsersuchen nicht erkennen, verliert das Team Zeit, bevor die eigentliche Arbeit überhaupt beginnt.

Fehler 2: Controller- und Processor-Verantwortung verwechseln

In B2B-SaaS werden DSARs oft unübersichtlich, weil Unternehmen gemischte Rollen haben. Für Sales-, Marketing-, Mitarbeiter- oder Supportdaten sind sie häufig Controller. Für hochgeladene Kundendaten können sie Processor sein.

Typische Abkürzungen sind:

• "Wir sind nur Processor, also ist das nicht wirklich unser Thema."
• "Wir halten die Daten, also beantworten wir einfach alles direkt."

Beides ist riskant. Wichtiger ist die operative Frage, welche Rolle das Unternehmen für die konkreten Daten im Scope spielt und welcher nächste Schritt vertraglich oder prozessual vorgesehen ist. Ohne diese Regel wird aus DSAR-Bearbeitung schnell Raten unter Zeitdruck.

Fehler 3: Das bequemste statt des relevanten Systems durchsuchen

Viele Teams behandeln DSAR-Retrieval immer noch wie "User exportieren und fertig". Das reicht selten aus. Die ICO verlangt eine angemessene und verhältnismäßige Suche. Das heißt nicht, jede Backup-Kopie gleich tief zu durchforsten. Es heißt aber, die Systeme ernsthaft zu prüfen, die für das Ersuchen tatsächlich relevant sind, etwa:

• Produktdatenbank und Authentifizierungs-Tooling;
• Billing-, Rechnungs- und Subskriptionssysteme;
• Support-Tickets, Chat-Verläufe und Anhänge;
• CRM-Daten und Sales-Notizen;
• Analytics oder Telemetrie, soweit die Daten personenbezogen und relevant sind;
• Daten bei Auftragsverarbeitern, die über bestehende Abläufe abrufbar sind.

Der Fehler liegt nicht nur im zu kleinen Suchumfang. Manche Teams suchen auch zu breit, aber ohne nachvollziehbare Regel. Das schafft Kosten, Verzögerung und unnötigen Review-Lärm.

Fehler 4: Identität, Klarstellungen und Fristen improvisieren

Ein weiteres Problem ist das Übersteuern am Anfang des Ablaufs. Ein Team antwortet zu locker, ohne ausreichend sicher zu sein, dass die anfragende Person die richtige ist. Ein anderes verlangt unnötig viele Nachweise, obwohl die Person bereits authentifiziert ist.

Beides schafft Risiko. Das Unternehmen braucht eine verhältnismäßige Regel, wann bestehende Authentifizierung genügt, wann zusätzliche Verifikation gerechtfertigt ist, wann Klarstellung wegen unklarer Reichweite nötig wird und wie diese Entscheidungen dokumentiert werden. Fehlt diese Regel, gehen die ersten Tage oft in interner Abstimmung verloren.

Fehler 5: Die Review-Schicht überspringen

Eine DSAR-Antwort ist nicht nur Retrieval, sondern auch Review. Gesammelte Datensätze können Informationen anderer Personen, interne Kommentare, Fraud-Hinweise oder Material enthalten, das geschwärzt oder besonders geprüft werden muss. Hinzu kommt, dass die Schwelle für "manifestly unfounded or excessive" hoch ist. Die ICO betont ausdrücklich, dass dafür starke Begründungen und klare Nachweise nötig sind.

Hier brechen unreife Abläufe oft auseinander. Daten werden zusammengetragen, aber niemand verantwortet sauber:

• ob Drittdaten geschwärzt werden müssen;
• ob eine Einschränkung oder Ablehnung tragfähig ist;
• ob das Antwortpaket verständlich und nicht nur vollständig ist;
• ob sich die Begründung später verteidigen lässt.

Fehler 6: Kaum Nachweise über den Ablauf behalten

Viele Teams glauben, das einzige relevante Artefakt sei die versendete Antwort. Für operative Belastbarkeit reicht das nicht. Wenn später Audit, Kunde oder Regulator nachfragt, sollte das Team mehr zeigen können als einen Export und eine versendete E-Mail. Nützlich sind meist:

• wann und wo das Ersuchen erkannt wurde;
• wer die Identität auf welcher Grundlage bestätigt hat;
• welche Systeme durchsucht wurden und warum;
• welche Processor einbezogen wurden;
• welche Review- oder Schwärzungsentscheidungen getroffen wurden;
• wann die Antwort von wem versendet wurde.

So sehen diese Fehler in der Praxis aus

Support-geführtes Ersuchen ohne Suchkarte

Support erhält eine E-Mail mit der Bitte um "alle Daten über mich". Engineering exportiert die Kontodaten aus der App und stoppt dort. Erst später stellt Privacy die Frage, ob Support-Chats, Billing-Kontakte, CRM-Notizen oder Daten bei Processorn ebenfalls geprüft wurden.

Enterprise-Anfrage in einem Controller-Processor-Setup

Ein Mitarbeiter des Kunden stellt sein Ersuchen direkt an den SaaS-Vendor. Support weiß nicht, ob geantwortet, weitergeleitet oder abgelehnt werden soll. Der Vertrag sieht Unterstützung bei Betroffenenrechten vor, aber der konkrete Ablauf dafür wurde nie definiert.

Breites Ersuchen ohne Review-Disziplin

Das Unternehmen sammelt E-Mails, Tickets und Notizen über die anfragende Person und sendet alles gesammelt heraus. Erst danach fällt auf, dass Drittdaten und interne Kommentare ohne ausreichende Prüfung enthalten waren.

Ein praktikabler Reset für SaaS-Teams

Die schnellste Verbesserung ist meist keine größere Policy, sondern ein einfacherer Betriebsablauf. Legen Sie einen Intake-Pfad, einen Case-Owner und eine Eskalationsregel fest. Erstellen Sie dann eine kurze Suchkarte für Produkt, Authentifizierung, Billing, Support, CRM, Analytics und die wichtigsten Processor. Dokumentieren Sie anschließend minimale Review-Punkte für Identität, Scope, Schwärzung und Freigabe. Halten Sie schließlich einen schlanken Nachweis fest, der den nächsten Fall leichter macht.

FAQ

Was sollten Teams über Auskunftsersuchen von Betroffenen verstehen?

Teams sollten verstehen, wann Auskunftsersuchen greifen, welche operativen Änderungen sie verlangen und welcher Nachweis zeigt, dass der Ablauf wirklich funktioniert.

Warum ist das Thema in der Praxis wichtig?

Weil es beeinflusst, wie Teams Risiken eingrenzen, Ownership festlegen, Entscheidungen dokumentieren und Kunden-, Regulator- oder Auditfragen belastbarer beantworten.

Was ist der größte Fehler?

Der größte Fehler ist, Auskunftsersuchen als einmalige Rechtsfrage statt als wiederholbaren Workflow mit Ownern, Triggern, Nachweisen und Eskalationspfaden zu behandeln.