Wann braucht ein SaaS-Tool einen AVV?
In der Praxis betrifft das auch Werkzeuge, die auf den ersten Blick keine Personendaten enthalten. Ein Whiteboard-Tool speichert Namen der Teilnehmenden und ihre Beiträge, ein Umfragetool Antworten und E-Mail-Adressen, ein Code-Repository Namen und Commit-Historien. Wer bei jedem Tool fragt, welche Personendaten anfallen, vermeidet Überraschungen.
Projektteams arbeiten mit einer Vielzahl von Werkzeugen: Projektmanagement, Zeiterfassung, Dokumentenablage, Videokonferenzen, Chat, Whiteboards, Umfragen, KI-Assistenten. Sobald in einem solchen Tool personenbezogene Daten verarbeitet werden — Namen, E-Mail-Adressen, Zeiten, Kommentare, Kundendaten —, verarbeitet der Anbieter diese Daten in aller Regel im Auftrag. Er ist dann Auftragsverarbeiter, und Art. 28 DSGVO verlangt einen Vertrag oder ein anderes Rechtsinstrument, der den Auftragsverarbeiter gegenüber dem Verantwortlichen bindet.[1]
Wichtig ist: Die Pflicht trifft den Verantwortlichen, also das Unternehmen, das das Tool einsetzt. Ein Projektteam, das ein Tool ohne Prüfung einführt, schafft damit ein Risiko für das ganze Unternehmen. Die allgemeinen Inhalte eines solchen Vertrags beschreibt Flenio im Leitfaden Auftragsverarbeitungsvertrag erklärt; dieses Kapitel konzentriert sich auf die Auswahl und Prüfung von SaaS-Werkzeugen im Projekt.
Was muss im AVV stehen?
Viele SaaS-Anbieter stellen einen standardisierten AVV bereit, oft als Teil der Nutzungsbedingungen oder zum Abschluss im Kundenkonto. Das ist zulässig, solange er die Mindestinhalte enthält. Individuelle Verhandlungen sind bei Standarddiensten selten möglich; umso wichtiger ist es, den Standardvertrag zu lesen und zu prüfen, ob er zu den eigenen Anforderungen passt — etwa in Bezug auf Speicherort, Unterauftragsverarbeiter und Löschfristen.
Art. 28 Abs. 3 DSGVO legt fest, was der Vertrag mindestens regeln muss. Dazu gehören Gegenstand und Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Kategorien betroffener Personen sowie die Pflichten und Rechte des Verantwortlichen. Der Auftragsverarbeiter muss insbesondere nur auf dokumentierte Weisung verarbeiten, die Vertraulichkeit sicherstellen, die erforderlichen Sicherheitsmaßnahmen nach Art. 32 treffen, Unterauftragsverarbeiter nur unter den vorgesehenen Bedingungen einsetzen, den Verantwortlichen bei Betroffenenrechten und Pflichten unterstützen, Daten nach Ende der Leistung löschen oder zurückgeben und Nachweise sowie Überprüfungen ermöglichen.[1]
| Inhalt | Worauf bei SaaS achten |
|---|---|
| Verarbeitung nur auf Weisung | Keine eigene Nutzung der Daten, etwa für das Training von KI-Modellen ohne Vereinbarung |
| Vertraulichkeit | Verpflichtung der Mitarbeitenden des Anbieters |
| Sicherheit nach Art. 32 | Beschreibung der technischen und organisatorischen Maßnahmen, Zertifizierungen |
| Unterauftragsverarbeiter | Liste, Informationspflicht bei Änderungen, Widerspruchsrecht |
| Unterstützung | Bei Auskunft, Löschung, Datenschutzverletzungen und DSFA |
| Löschung oder Rückgabe | Export in brauchbarem Format, Löschfristen nach Vertragsende |
| Nachweise und Kontrollen | Audit-Berichte, Zertifikate, Möglichkeit von Prüfungen |
Unterauftragsverarbeiter verstehen
Praktisch bewährt hat sich, die Benachrichtigungen über neue Unterauftragsverarbeiter an eine zentrale Adresse im Unternehmen zu leiten, etwa an den Datenschutz, und nicht an die Person, die das Tool zufällig bestellt hat. So gehen Änderungen nicht unter, und Widerspruchsfristen werden eingehalten.
SaaS-Anbieter betreiben ihre Dienste selten allein. Hosting, E-Mail-Versand, Support-Werkzeuge, Analyse oder KI-Funktionen werden häufig von weiteren Anbietern erbracht. Diese Unterauftragsverarbeiter darf der Auftragsverarbeiter nur einsetzen, wenn der Verantwortliche zugestimmt hat, gesondert oder allgemein; bei einer allgemeinen Genehmigung muss er über beabsichtigte Änderungen informieren, damit der Verantwortliche widersprechen kann.[1] Für die Prüfung eines Tools ist deshalb die Liste der Unterauftragsverarbeiter genauso wichtig wie der Hauptanbieter: Wo sitzen sie, welche Daten erhalten sie, für welchen Zweck?
Ein besonderes Augenmerk verdienen KI-Funktionen. Viele Werkzeuge haben in den letzten Jahren KI-Assistenten integriert, die Inhalte an externe Modellanbieter übermitteln. Ob das geschieht, wohin und ob die Daten für das Training verwendet werden, sollte vor der Aktivierung solcher Funktionen geklärt sein. Mehr dazu beschreibt Flenio im Leitfaden KI-Funktionen und Datenschutz.
Drittlandtransfer und Data Privacy Framework
Ein Projekt, das sensible Kundendaten verarbeitet, sollte im Zweifel Anbieter mit Datenhaltung in der EU bevorzugen; das reduziert die Abhängigkeit von der weiteren Rechtsentwicklung beim Drittlandtransfer.
Für Projektteams heißt das konkret: Bei einem US-Anbieter ist zu prüfen, ob er unter dem Data Privacy Framework zertifiziert ist, und ob die Zertifizierung die betroffenen Daten abdeckt. Ist er nicht zertifiziert, braucht es eine andere Grundlage, in der Regel Standardvertragsklauseln mit einer Bewertung der Rechtslage im Empfängerland.
Werden personenbezogene Daten in ein Land außerhalb der EU und des EWR übermittelt, ist das nur unter den Bedingungen der Art. 44 ff. DSGVO zulässig, etwa auf Grundlage eines Angemessenheitsbeschlusses der Kommission oder geeigneter Garantien wie Standardvertragsklauseln.[1] Die aktuellen Standardvertragsklauseln hat die Kommission mit dem Durchführungsbeschluss (EU) 2021/914 erlassen.[3]
Für Übermittlungen in die USA stützt sich der Datenverkehr seit Juli 2023 auf den Angemessenheitsbeschluss zum EU-US Data Privacy Framework. Übermittlungen an US-Unternehmen, die auf der vom US-Handelsministerium geführten Liste stehen, sind damit ohne zusätzliche Garantien möglich.[4] Das Gericht der Europäischen Union hat eine Nichtigkeitsklage gegen den Beschluss am 3. September 2025 abgewiesen (T-553/23).[2] Der Kläger hat am 31. Oktober 2025 Rechtsmittel beim Gerichtshof eingelegt; bis zu einer etwaigen Aufhebung bleibt der Beschluss wirksam.[5][4]
Eine Prüfliste für Projektteams
Bei Tools, die bereits im Einsatz sind, empfiehlt sich eine einmalige Bestandsaufnahme: Welche Werkzeuge nutzt das Team, welche Daten liegen darin, und gibt es für jedes einen AVV? Die Ergebnisse fließen in das Verzeichnis der Verarbeitungstätigkeiten ein.
Der Aufwand für diese Prüfung ist überschaubar, wenn sie einmal standardisiert ist. Ein kurzes Formular mit den Fragen der Liste, ausgefüllt vom Projektteam und freigegeben vom Datenschutz, genügt in den meisten Fällen.
Damit Tools nicht im Wildwuchs eingeführt werden, braucht es einen einfachen, verbindlichen Prüfprozess. Er muss nicht aufwendig sein, sollte aber vor jeder Einführung eines neuen Tools mit Personendaten durchlaufen werden:
- 1Klären, welche personenbezogenen Daten im Tool verarbeitet werden und von wem.
- 2Prüfen, ob der Anbieter einen Auftragsverarbeitungsvertrag nach Art. 28 anbietet und ihn abschließen.
- 3Liste der Unterauftragsverarbeiter mit Sitz und Zweck prüfen.
- 4Speicherort der Daten und mögliche Drittlandtransfers klären, einschließlich der Grundlage.
- 5Sicherheitsmaßnahmen und Nachweise prüfen, etwa Zertifizierungen oder Audit-Berichte.
- 6KI-Funktionen und deren Datenflüsse klären, bei Bedarf deaktivieren.
- 7Export und Löschung bei Vertragsende prüfen.
- 8Tool im Verzeichnis der Verarbeitungstätigkeiten erfassen.
- 9Datenschutzbeauftragten einbinden und Freigabe dokumentieren.
Für die strukturierte Bewertung mehrerer Anbieter eignet sich die Checkliste Lieferantenauswahl; Hinweise zur Auswahl aus Datenschutzsicht gibt der Leitfaden Tool-Auswahl und Datenschutz.
Schatten-IT im Projekt vermeiden
Schulungen für Projektteams helfen zusätzlich, das Bewusstsein für diese Risiken zu schärfen.
Hilfreich ist eine öffentlich im Unternehmen einsehbare Liste der freigegebenen Werkzeuge mit ihrem Einsatzzweck und den Daten, die darin verarbeitet werden dürfen. Sie beantwortet die häufigste Frage im Projekt — darf ich das verwenden? — ohne Rückfrage und reduziert den Anreiz, ungeprüfte Tools zu nutzen.
Ein häufiges Problem in Projekten ist Schatten-IT: Teammitglieder nutzen spontan ein kostenloses Tool, weil es schnell hilft, und laden Kundendaten oder Projektunterlagen hoch. Ohne AVV und ohne Prüfung ist das ein Datenschutzverstoß des Unternehmens. Verbote allein helfen selten. Wirksamer ist ein freigegebener Werkzeugkasten, der die typischen Bedürfnisse abdeckt, und ein schneller Prüfprozess für neue Tools, damit Teams nicht ausweichen müssen.
An das Vertragsende denken
Für den Fall eines Anbieterwechsels sollte zudem geklärt sein, wie lange der bisherige Anbieter die Daten nach Vertragsende noch vorhält und wie die Löschung bestätigt wird. Eine schriftliche Löschbestätigung ist ein einfacher Nachweis für die Rechenschaftspflicht.
Bei der Auswahl wird oft vergessen, was nach dem Projekt oder bei einem Anbieterwechsel geschieht. Art. 28 verlangt, dass der Auftragsverarbeiter nach Abschluss der Leistungen alle personenbezogenen Daten nach Wahl des Verantwortlichen löscht oder zurückgibt.[1] Für Projektteams ist zusätzlich wichtig, dass Projektunterlagen in einem brauchbaren Format exportiert werden können — auch wegen der Aufbewahrungspflichten nach Abgabenordnung und GoBD, die das Kapitel GoBD beschreibt. Wie ein Anbieterwechsel gelingt, zeigt der Leitfaden Datenexport beim Anbieterwechsel.
Den Überblick über die Datenschutzpflichten im Projekt bietet das Kapitel DSGVO im Projektmanagement; weitere Rechtsthemen ordnet der Recht-Leitfaden Deutschland.