Checkliste Auftragsverarbeiter-Management fuer Gruender und Compliance-Leads

Auftragsverarbeiter-Management funktioniert am besten als Checkliste, nicht als einmalige juristische Einordnung. Ein SaaS-Team sollte erkennen koennen, wann ein Anbieter personenbezogene Daten im Auftrag verarbeitet, welche Rolle gilt, welche Vertrags- und Security-Nachweise vorliegen, welche Unterauftragsverarbeiter eingesetzt werden und wann eine erneute Pruefung ausgeloest wird.

Das praktische Ziel ist ein wiederholbarer Ablauf mit Ownern, dokumentierten Entscheidungen und Nachweisen. Wenn niemand sagen kann, wer die Beziehung verantwortet, welche Daten verarbeitet werden, welche Weisungen gelten und wo die Nachweise liegen, ist das Thema noch nicht operativ verankert.

1. Klaeren, ob die Pruefung greift

Die Pruefung greift, wenn ein Anbieter personenbezogene Daten in Ihrem Auftrag und nach Ihren Weisungen verarbeitet. Sie greift auch, wenn Ihr SaaS-Unternehmen als Auftragsverarbeiter fuer Kundendaten handelt und darunter weitere Dienstleister nutzt. Fragen Sie, ob der Anbieter Daten empfaengt, speichert, einsehen, uebertragen, analysieren oder erzeugen kann. Klaeren Sie ausserdem, ob der Anbieter eigene Zwecke verfolgt oder nur nach Weisung handelt.

Die EDPB-Leitlinien sind wichtig, weil die Rolle von der tatsaechlichen Verarbeitung abhaengt, nicht nur vom Vertragsetikett. Unklare Faelle sollten vor dem Datenfluss an Legal oder Privacy eskaliert werden.

2. Einen nutzbaren Datensatz anlegen

Jeder freigegebene Auftragsverarbeiter braucht einen praktischen Datensatz: Anbietername, Produkt, interner Owner, Zweck, Rollenbewertung, Datenkategorien, betroffene Personen, angebundene Systeme, Datenstandort, Transferroute, DPA-Status, Security-Review, Unterauftragsverarbeiter, Aufbewahrung, Loeschung, Kundendisclosure, letztes Review und naechster Trigger.

Dieser Datensatz verbindet Datenschutzplanung mit echten Lieferantenentscheidungen. Er verhindert, dass Sales, Security, Legal, Product und Procurement mit verschiedenen Listen arbeiten.

3. Artikel-28-Anforderungen pruefen

Der Vertrag oder bindende Rechtsakt sollte Gegenstand und Dauer, Art und Zweck, Datenarten, Kategorien betroffener Personen sowie Pflichten und Rechte des Verantwortlichen beschreiben. Er sollte Weisungen, Vertraulichkeit, Sicherheit, Unterstuetzung, Loeschung oder Rueckgabe, Nachweisinformationen, Audit-Unterstuetzung und Unterauftragsverarbeiter-Bedingungen abdecken.

Die Standardvertragsklauseln der Europaeischen Kommission fuer Verantwortliche und Auftragsverarbeiter koennen als strukturierter Vergleichspunkt dienen. Sie ersetzen aber nicht die Pruefung der konkreten Beziehung.

4. Garantien und Nachweise pruefen

Ausreichende Garantien bedeuten mehr als ein DPA. Pruefen Sie Zugriffskontrollen, Authentifizierung, Protokollierung, Verschluesselung, Mandantentrennung, Incident-Prozesse, Schwachstellenmanagement, Zertifizierungen, Aufbewahrung, Loeschung, Support-Zugriff und die Nutzung von Daten fuer KI-Training oder Produktverbesserung.

Die Tiefe der Pruefung sollte zum Risiko passen. Ein Dienst, der Kundendaten oder Produktivzugriff hat, braucht mehr Pruefung als ein internes Tool mit begrenzten Kontaktdaten.

5. Unterauftragsverarbeiter steuern

Unterauftragsverarbeiter sind Teil des Prozesses. Klaeren Sie, welche Dienstleister Zugriff haben, welche Leistung sie erbringen, wo Verarbeitung stattfindet, ob gleichwertige Pflichten gelten, welche Genehmigung das DPA verlangt, wie Kunden informiert werden und wann Engineering eine neue Abhaengigkeit aktivieren darf.

Die interne Liste muss zur oeffentlichen Unterauftragsverarbeiter-Seite oder DPA-Anlage passen. Abweichungen schaden dem Vertrauen schnell.

6. Transfers, Nachweise und Review-Trigger festlegen

Erfassen Sie, wo Daten gehostet werden, wo Zugriff moeglich ist und welcher Transfermechanismus gilt. Raten Sie nicht. Wenn die Transferroute unklar ist, sollte keine Verarbeitung beginnen, bis die Pruefung abgeschlossen ist.

Speichern Sie DPA, Rollenbewertung, Security-Review, Unterauftragsverarbeiter-Liste, Transfernachweis, Konfigurationsbedingungen, Freigabeticket, Restrisikoentscheidung und naechsten Review-Termin. Re-Reviews sollten durch neue Features, neue Unterauftragsverarbeiter, geaenderte Regionen, KI-Funktionen, Renewal, Kundenverpflichtungen oder stale Nachweise ausgeloest werden.

FAQ

Was ist der praktische Zweck?

Der Zweck ist Kontrolle ueber Drittverarbeitung: Welche Anbieter verarbeiten Daten, welche Weisungen gelten, welche Nachweise stuetzen die Entscheidung und wann wird neu geprueft?

Wann gilt das fuer SaaS-Teams?

Wenn ein Anbieter oder Unterauftragsverarbeiter personenbezogene Daten im Auftrag des Teams verarbeitet oder wenn das SaaS-Unternehmen eigene Unterauftragsverarbeiter fuer Kundendaten nutzt.

Was sollte zuerst dokumentiert werden?

Beginnen Sie mit dem Register fuer Anbieter, die Kunden- oder Produktivdaten beruehren: Owner, Zweck, Rolle, Daten, DPA, Security-Nachweise, Unterauftragsverarbeiter, Transferroute, Entscheidung und naechster Trigger.

Quellen

• 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.