Wann Auftragsverarbeiter-Management gilt und was Sie als naechstes tun sollten

Auftragsverarbeiter-Management gilt, wenn eine andere Organisation personenbezogene Daten fuer Ihr SaaS-Unternehmen verarbeitet oder wenn Ihr Unternehmen Kundendaten als Processor verarbeitet und dafuer weitere Dienstleister einsetzt. Die praktische Frage lautet nicht nur, ob es einen Vendor gibt. Entscheidend ist, ob personenbezogene Daten nach fremden Weisungen verarbeitet werden und ob diese Beziehung kontrollierbar nachgewiesen werden kann.

Bei SaaS-Teams ist die Antwort haeufig ja. Hosting, Support, CRM, Product Analytics, Billing, Identity, Monitoring, Customer Messaging, Security Tools, AI Services, Data Warehouses und ausgelagerte Support-Leistungen koennen Processor- oder Subprocessor-Beziehungen ausloesen.

Nach Artikel 28 DSGVO darf ein Controller nur Processor einsetzen, die ausreichende Garantien fuer geeignete technische und organisatorische Massnahmen bieten. Die Verarbeitung muss durch einen Vertrag oder einen anderen bindenden Rechtsakt geregelt sein. Dieser muss Gegenstand, Dauer, Zweck, Datentypen, Kategorien betroffener Personen sowie Rechte und Pflichten des Controllers beschreiben.

Operational bedeutet das: dokumentierte Weisungen, Vertraulichkeit, Security-Massnahmen, Subprocessor-Regeln, Unterstuetzung bei Betroffenenrechten, Loeschung oder Rueckgabe am Vertragsende sowie Informationen fuer Nachweise und Audits.

Wann es klar gilt

Das Thema gilt klar, wenn ein Dritter personenbezogene Daten fuer einen definierten Produkt- oder Geschaeftszweck nach Ihren Weisungen verarbeitet.

Typische SaaS-Beispiele sind Cloud-Infrastruktur, Helpdesk-Tools, Chat- und Call-Systeme, Transaktions-E-Mail, Product Analytics, Session Replay, Billing, Payment-Workflows, Identity-Plattformen, Logging, Backups, Incident Response, CRM, Marketing Automation, AI-Tools fuer Zusammenfassung oder Suche sowie externe Support- oder Operations-Dienstleister.

Ein Unternehmen kann mehrere Rollen haben. Ein SaaS-Anbieter kann Processor fuer Kundendaten im Workspace sein, Controller fuer Website Analytics und Mitarbeiterdaten, und zugleich Controller bei der Pruefung eigener Dienstleister. Deshalb zaehlt die tatsaechliche Zweckbestimmung mehr als das Etikett im Vertrag.

Wenn die Antwort unklar ist

Grenzfaelle entstehen bei begrenztem Zugriff, optionalen Features, internen Tools oder Anbietern, die behaupten, keine Kundendaten zu speichern. Ueberspringen Sie die Pruefung nicht, nur weil es "nur Metadaten" sind. Personenbezogene Daten koennen in Logs, Support-Anhaengen, IDs, Account Notes, Telemetrie, Prompts und Admin-Dashboards auftauchen.

Die EDPB-Leitlinien helfen, weil sie auf die Frage fokussieren, wer Zwecke und wesentliche Mittel bestimmt. Wenn ein Vendor Daten fuer eigene Produktverbesserung, Werbung, Benchmarking oder Modelltraining nutzt, ist die Beziehung moeglicherweise keine einfache Processor-Beziehung.

Was zuerst zu tun ist

Beginnen Sie mit einem schnellen Inventar aller Beziehungen, die personenbezogene Daten beruehren. Fuer jede Beziehung sollten Sie Vendor-Name, Produkt, Business Owner, Technical Owner, Workflow, Rollenbewertung, Datenkategorien, betroffene Personen, Systemzugriff, DPA-Status, Subprocessor, Security-Nachweise, Datenstandort, Transfermechanismus, Retention, Loeschung, Kundendisclosure und naechsten Review erfassen.

Dieser Datensatz muss am ersten Tag nicht perfekt sein. Er muss brauchbar genug sein, damit Legal, Security, Product, Procurement, Customer Success und Audit Owner aus denselben Fakten antworten koennen.

In den Betriebsworkflow einbauen

Auftragsverarbeiter-Management scheitert, wenn die Pruefung erst beginnt, nachdem das Tool live ist. Der Trigger gehoert in Procurement, Product Launch, Security Review und Vendor Onboarding.

Eine gute Intake fragt: Welche personenbezogenen Daten erhaelt oder sieht der Vendor? Welche Kunden, Nutzer, Mitarbeiter oder Prospects sind betroffen? Gibt es Subprocessor? Wo werden Daten gehostet oder abgerufen? Nutzt der Vendor Daten fuer eigene Zwecke? Welche DPA-, Security-, Transfer- und Loeschnachweise existieren?

Security prueft technische und organisatorische Massnahmen. Privacy oder Legal prueft Rolle, DPA, Weisungen, Subprocessor und Transfers. Procurement verwaltet Vertrag und Renewal. Product oder Engineering besitzt Implementierungsgrenzen. Compliance stellt sicher, dass Nachweise spaeter fuer Audit und Customer Due Diligence auffindbar sind.

Subprocessor vor Kundenfragen steuern

Subprocessor sind besonders sichtbar. Ihre Processor koennen eigene Subprocessor einsetzen, und Ihre Kunden erwarten oft eine klare Subprocessor-Liste, Change Notifications und einen Einwendungsprozess im Einklang mit dem DPA.

Artikel 28 verlangt eine vorherige spezifische oder allgemeine schriftliche Genehmigung des Controllers. Praktisch brauchen Sie eine stabile Subprocessor-Seite oder Schedule, einen Freigabeprozess und einen Nachweis, was vor der Aufnahme geprueft wurde.

Belastbare Nachweise

Nuetzliche Nachweise sind DPA oder Online Terms, Rollenbewertung, Security-Fragebogen, Security-Dokumentation, Subprocessor-Liste, Transfermechanismus, Approval Ticket, Residual-Risk-Entscheidung, Retention Settings, Loeschverfahren und Kundendisclosure.

Diese Nachweise unterstuetzen GDPR-Planung, Data Protection by Design and Default, Data Minimisation und die Erkenntnis, dass GDPR nicht nur Cookie Banner sind.

Beispiel

Ein SaaS-Unternehmen moechte ein AI-Tool einfuehren, das Support-Tickets zusammenfasst. Das Tool kann Namen, E-Mail-Adressen, Account IDs, Ticketinhalte, Anhaenge und Metadaten erhalten. Das Team prueft zuerst, ob der Vendor Processor fuer diese Zusammenfassung ist oder Inhalte fuer eigene Zwecke nutzt. Danach folgen DPA, Weisungen, Security Evidence, Subprocessor, Hosting, Transfers, Retention, Training Controls, Loeschoptionen und Kundenzusagen.

Wenn der Vendor genehmigt wird, dokumentiert das Register Workflow, Datenkategorien, Owner, Terms, Transfermechanismus, Konfiguration, Subprocessor-Status, Evidence Location und Review Date.

FAQ

Was sollten Teams ueber Auftragsverarbeiter-Management verstehen?

Es gilt, wenn Dritte personenbezogene Daten im Auftrag des Unternehmens oder unterhalb der eigenen Processor-Rolle verarbeiten. Es sollte Owner, Trigger, Vertragsnachweise, Security-Nachweise, Subprocessor-Kontrollen und auditfaehige Records erzeugen.

Warum ist es praktisch wichtig?

SaaS-Teams verlassen sich auf Dritte fuer Produkt und Betrieb. Ohne Kontrolle koennen DPAs, Datenschutzhinweise, Security Questionnaires und Audit-Antworten schnell von der Realitaet abweichen.

Was sollte zuerst dokumentiert werden?

Starten Sie mit Beziehungen, die Kundendaten, Security Reviews, Transfers, Subprocessor, AI-Nutzung oder Kundendisclosures betreffen. Weisen Sie Owner zu, bestaetigen Sie die Rolle und sammeln Sie DPA- und Security-Nachweise.

Sources

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR.
• Information Commissioner's Office, Contracts and liabilities between controllers and processors.
• European Commission, Standard contractual clauses for controllers and processors in the EU/EEA.