Auftragsverarbeitungsvertrag SaaS: Wann dein Startup wirklich einen AVV braucht

Dieser Beitrag dient der allgemeinen Orientierung und ersetzt keine individuelle Rechtsberatung.

Ein potenzieller B2B-Kunde meldet sich kurz vor Vertragsabschluss zurück, aber nicht mit einer Unterschrift, sondern mit einem Datenschutzfragebogen. Er will einen Auftragsverarbeitungsvertrag SaaS, eine Übersicht der technischen und organisatorischen Maßnahmen, eine Liste eurer Subprozessoren, Löschfristen und, immer häufiger, konkrete Angaben zu KI-Modellen und Drittlandtransfers. Für viele Gründerteams ist das der Moment, in dem klar wird: Datenschutz ist kein Randthema, sondern ein Teil des Sales-Prozesses.

Das eigentliche Problem ist dabei selten, dass ein Startup gar kein Vertrags-PDF hat. Häufiger passen Vertrag, tatsächliche Produktrealität und das Setup der eigenen Vendoren einfach nicht zusammen. In diesem Beitrag lernst du, typische Rollen zu unterscheiden, deinen eigenen Fall vorzuprüfen, die Mindestanforderungen nach Artikel 28 DSGVO einzuordnen und ein Procurement-Paket aufzusetzen, das Sales-Prozesse beschleunigt statt sie zu blockieren. Wichtig vorweg: Nicht jede Software ist automatisch Auftragsverarbeiter, das hängt immer vom konkreten Fall ab.

Zuerst die Rolle klären, dann den Vertrag wählen

Bevor du dir überhaupt Gedanken über eine Vertragsvorlage machst, brauchst du Klarheit über eine ganz andere Frage: Wer entscheidet eigentlich, warum und wie personenbezogene Daten verarbeitet werden? Das ist wichtiger als der Titel des Dokuments, das dein Kunde dir schickt. Ob dort „DPA“, „AVV“ oder „Data Processing Agreement“ steht, sagt noch nichts über die tatsächliche Rollenverteilung aus.

Der Verantwortliche ist die Stelle, die entscheidet, warum personenbezogene Daten verarbeitet werden und welche wesentlichen Mittel dabei zum Einsatz kommen. Nutzt ein Kunde zum Beispiel ein CRM, um Leads und Kundenbeziehungen zu verwalten, bestimmt er diesen Geschäftszweck selbst.

Der Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag des Verantwortlichen und innerhalb dokumentierter Weisungen. Das CRM-Startup hostet in diesem Beispiel die Kontakt- und Nutzungsdaten und stellt die Funktionen bereit, mit denen der Kunde seine eigene Vertriebsarbeit organisiert.

Bei gemeinsamer Verantwortlichkeit bestimmen zwei Parteien gemeinsam Zwecke und wesentliche Mittel einer Verarbeitung. Das lässt sich nicht mit einem klassischen AVV lösen, sondern erfordert unter Umständen eine Vereinbarung nach Artikel 26 DSGVO.

Ein wichtiger Punkt, den viele Teams übersehen: Dasselbe Unternehmen kann je Verarbeitungsvorgang unterschiedliche Rollen haben. Ein SaaS-Anbieter ist für die gehosteten Kundendaten oft Auftragsverarbeiter, für eigene Rechnungsdaten, Missbrauchsprävention oder gesetzliche Aufbewahrungspflichten dagegen selbst Verantwortlicher. Die rechtliche Basis liefern Artikel 4 DSGVO für die Definitionen von Verantwortlichen und Auftragsverarbeitern sowie Artikel 26 für gemeinsame Verantwortlichkeit. Eine gute Vertiefung liefern die Leitlinien 07/2020 des Europäischen Datenschutzausschusses zu diesen Begriffen.

Die Schnellprüfung für typische Produktfälle

Damit du nicht bei jedem einzelnen Feature neu anfangen musst, hilft eine vierstufige Prüflogik:

1. Werden personenbezogene Daten verarbeitet, also etwa Namen, E-Mail-Adressen, Ticketinhalte, IP-Adressen oder Beschäftigtendaten?
2. Verarbeitet euer Startup diese Daten für den Kunden?
3. Bestimmt der Kunde den Zweck, während ihr innerhalb seiner Weisungen tätig werdet?
4. Nutzt ihr die Daten nicht zusätzlich für eigene, unabhängige Zwecke?

Wenn alle vier Fragen mit Ja beantwortet werden können, spricht viel für eine klassische Auftragsverarbeitung. Schauen wir uns typische Konstellationen an, ohne dass das eine pauschale Rechtsbewertung für jeden Einzelfall ist.

CRM- oder Helpdesk-SaaS: Meist Auftragsverarbeitung, wenn Kund:innen Kontakte, Tickets und Mitarbeitendendaten in der Software verwalten und ihr diese Daten im Rahmen der gebuchten Leistung verarbeitet. Internationale Einkaufsabteilungen nennen den AVV in diesem Kontext häufig DPA SaaS, also Data Processing Agreement.

Agentur mit Kundenzugängen: Häufig Auftragsverarbeitung, wenn die Agentur CRM-Einträge pflegt, Kampagnen technisch umsetzt oder Supportfälle ausschließlich nach Kundenweisungen bearbeitet. Entwickelt sie dagegen eigene Strategien und entscheidet eigenständig über Zwecke wesentlicher Verarbeitungen, muss dieser konkrete Vorgang gesondert bewertet werden.

Analytics-Tool: Hier gibt es keinen Automatismus. Reines Messen im Auftrag kann für Auftragsverarbeitung sprechen, eine eigene werbliche Nutzung, profilbasierte Produktanalyse oder Zusammenführung für eigene Zwecke kann dagegen sprechen.

KI-Assistent mit Kundendaten: Beim AV-Vertrag KI-Tools reicht der Blick auf den Modellnamen nicht aus. Entscheidend ist, ob Prompts, Dokumente und Outputs ausschließlich für die Kundenfunktion verarbeitet werden oder zusätzlich für Training, Modellverbesserung, Telemetrie oder eigene Analysen genutzt werden.

Internes Tooling: Nutzt euer Startup ein HR-, Support- oder Kollaborationstool für eure eigenen Beschäftigten und Kontakte, seid ihr regelmäßig selbst Verantwortlicher, der Toolanbieter kann euer Auftragsverarbeiter sein. Das beantwortet aber nicht automatisch die Frage nach eurer eigenen Rolle gegenüber euren Kunden.

Wann ein AVV gerade nicht die richtige Antwort ist

Eine der verbreitetsten Fehlannahmen im Gründeralltag lautet: „Jede Software braucht automatisch einen AVV.“ Das stimmt so nicht. Ein klassischer AVV ist nicht schon deshalb erforderlich, weil Daten zwischen zwei Unternehmen fließen.

Drei Konstellationen, in denen ein AVV nicht die passende Antwort ist:

• Eigenständige Verantwortliche: Beide Parteien verfolgen eigene, voneinander unabhängige Zwecke.
• Gemeinsame Verantwortlichkeit: Zwecke und wesentliche Mittel werden gemeinsam festgelegt, hier ist statt eines AVV eine Vereinbarung nach Artikel 26 DSGVO relevant.
• Tatsächlich anonymisierte Daten: Erwägungsgrund 26 DSGVO erfasst Informationen nicht, wenn Personen nicht oder nicht mehr identifizierbar sind. Wichtig dabei: Pseudonymisierung allein ist noch keine Anonymisierung.

Ein unpassender AVV kann Rollen verschleiern und macht Antworten in Kundenfragebögen im schlimmsten Fall widersprüchlich. Bei Grenzfällen, etwa bei sensiblen Daten, umfangreichem Tracking, KI-Training oder geteilten Produktentscheidungen, lohnt sich eine gesonderte Prüfung, statt reflexhaft ein Standardformular zu verschicken.

Was ein belastbarer Vertrag tatsächlich abdecken muss

Artikel 28 DSGVO bildet die rechtliche Grundlage für den Vertrag beziehungsweise Rechtsakt zwischen Verantwortlichem und Auftragsverarbeiter. Er muss die Verarbeitung konkret beschreiben und die Pflichten beider Seiten verbindlich regeln, nicht nur allgemein formulieren.

In Startup-Sprache übersetzt, braucht ein solcher AVV DSGVO folgende Bestandteile:

• Gegenstand und Dauer: Welche SaaS-Leistung wird erbracht und wie lange werden Daten verarbeitet?
• Art und Zweck: Beispielsweise Hosting, Ticketbearbeitung, Kommunikation, Analyse oder KI-gestützte Zusammenfassung für die Kundenorganisation.
• Datenkategorien und betroffene Personen: Kontakt-, Nutzungs-, Support-, Vertrags- und Beschäftigtendaten; Kund:innen, Interessent:innen, Nutzer:innen oder Mitarbeitende.
• Weisungen: Der Kunde muss rechtmäßige Weisungen geben können, ihr braucht einen dokumentierten Kanal dafür und müsst bei offenkundig rechtswidrigen Weisungen reagieren.
• Vertraulichkeit: Zugriffsberechtigte Mitarbeitende und externe Personen sind zur Vertraulichkeit verpflichtet.
• TOMs SaaS: Statt abstrakt „hohe Sicherheit“ zu behaupten, solltet ihr Maßnahmen wie Rollen- und Rechtekonzept, MFA, Verschlüsselung bei Übertragung und Speicherung, Protokollierung, Backups, Patch-Management und Incident-Prozesse konkret beschreiben.
• Unterauftragsverarbeiter: Vorabgenehmigung oder allgemeine Genehmigung mit Informations- und Widerspruchsmechanismus, die Pflichten müssen an Subunternehmer weitergegeben werden.
• Unterstützung: Angemessene Hilfe bei Betroffenenanfragen, Datenschutzverletzungen und Datenschutz-Folgenabschätzungen, soweit eure Leistung betroffen ist.
• Vertragsende: Rückgabe oder Löschung der Kundendaten, vorbehaltlich gesetzlicher Aufbewahrungspflichten.
• Nachweise und Audits: Ein praktikables Verfahren, etwa aktuelle Dokumente, Zertifikate oder Fragebögen zuerst, individuelle Audits risikobasiert, angekündigt und ohne unverhältnismäßige Sicherheitsrisiken.

Eine Mustervereinbarung ist dabei immer nur ein Ausgangspunkt, kein Ersatz für eine Leistungsbeschreibung und Anlagen, die tatsächlich zu eurem Produkt passen. Der offizielle DSGVO-Text und der EU-Durchführungsbeschluss 2021/915 mit Standardvertragsklauseln zwischen Verantwortlichen und Auftragsverarbeitern geben eine gute Orientierung, wie diese Punkte konkret ausformuliert werden können.

Quellen: DSGVO Volltext, Durchführungsbeschluss 2021/915

Das schlanke Procurement-Paket für schnellere Freigaben

Kunden prüfen selten nur einen einzelnen AVV DSGVO. Sie wollen nachvollziehen, wie ihr Daten tatsächlich schützt und welche Dienstleister dabei beteiligt sind. Genau dafür lohnt sich ein schlankes, wiederverwendbares Paket.

Eine Subprocessor-Liste sollte mindestens Dienstleistername, Funktion beziehungsweise Verarbeitungszweck, Verarbeitungsregion oder Standort, eingesetzte Datenkategorien soweit sinnvoll und den Prozess für Änderungen enthalten. Typische Einträge: Cloud-Hosting, E-Mail-Versand, Fehleranalyse, Supportplattform, Monitoring oder Modellanbieter.

Eine TOM-Summary als lesbare Ergänzung, maximal ein bis zwei Seiten, deckt Zugriffsschutz, Verschlüsselung, Berechtigungsmanagement, Logging, Backup und Wiederherstellung, Sicherheitsvorfälle und Verantwortlichkeiten ab. Sie ersetzt keine detaillierte Sicherheitsdokumentation, erleichtert aber Procurement-Prüfungen erheblich.

Ein klares Löschkonzept sollte Auslöser wie Vertragsende oder Kundenanweisung, produktive Löschfristen, den Umgang mit Backups, Exportmöglichkeiten vor Löschung und Sonderfälle gesetzlicher Aufbewahrung benennen.

Bei den Transferinfos gehören Datenresidenz, beteiligte Anbieter, Zugriffsländer und der verwendete Transfermechanismus dazu. Wichtige Klarstellung: SCC, also Standardvertragsklauseln, sind nicht dasselbe wie ein AVV. Sie können bei bestimmten Drittlandübermittlungen zusätzlich erforderlich sein, ersetzen aber weder die Rollenprüfung noch den Vertrag nach Artikel 28.

Der praktische Sales-Hinweis: Führt alles versioniert in einem klar verantworteten Vendor-Ordner. Das verhindert, dass Sales und Support widersprüchliche Einzelauskünfte geben, wenn ein Kunde nachfragt.

Quelle: Durchführungsbeschluss 2021/914 zu SCC

Vier Zusatzfragen bei KI, Logs und internationalen Anbietern

Gerade bei KI-Funktionen lohnt sich eine zusätzliche, sehr konkrete Checkliste:

1. Werden Prompts, hochgeladene Dateien, Outputs oder Logs gespeichert, und wie lange?
2. Ist Training, Modellverbesserung oder sonstige Sekundärnutzung ausgeschlossen, optional oder standardmäßig aktiviert?
3. Wer kann für Support, Debugging oder Sicherheitsanalysen auf Inhalte zugreifen?
4. In welchen Ländern verarbeiten Modellanbieter, Hosting-Anbieter und Unterauftragsverarbeiter die Daten oder ermöglichen Fernzugriffe?

„KI-Tool“ ist keine Datenschutzrolle. Eigene Zwecke des Anbieters, etwa Modellverbesserung, können gegen eine ausschließlich weisungsgebundene Verarbeitung sprechen. Bei Drittlandtransfers gilt: Besteht ein Angemessenheitsbeschluss, sind grundsätzlich keine zusätzlichen Transfergarantien nötig. Fehlt er, kommen je nach Datenfluss unter anderem SCC in Betracht. Pauschale Aussagen zu einzelnen Ländern oder konkreten KI-Anbietern helfen hier wenig, da sich Produktbedingungen und Datenflüsse regelmäßig ändern. Prüft daher immer den konkreten Fall.

Quelle: EU-Kommission zu Datentransfers außerhalb der EU

Der 14-Tage-Plan für ein sauberes Setup

Der Anspruch dieses Plans ist kein perfektes Legal-Projekt, sondern ein konsistenter erster Standard für Auftragsverarbeitung Startups, der sich später verfeinern lässt.

Tage 1 bis 2: Datenlandkarte erstellen. Erfasst Datenarten, Kundenrollen, Produktmodule, KI-Funktionen, Supportzugriffe, Speicherorte und externe Anbieter.

Tage 3 bis 4: Rollen pro Vorgang festhalten. Für jeden wesentlichen Datenfluss dokumentieren: Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter oder gemeinsame Verantwortlichkeit; offene Punkte markieren.

Tage 5 bis 6: Vendor-Check. Bei jedem kritischen Anbieter DPA/AVV, Subprozessoren, TOMs, Löschfristen, Speicherregion, Transfers sowie Trainings- und Log-Regeln prüfen.

Tage 7 bis 8: Vertragsunterlagen anpassen. Leistungsbeschreibung, Datenkategorien, Weisungsweg, Auditprozess und Löschregeln auf euer tatsächliches Produkt zuschneiden.

Tage 9 bis 10: Procurement-Paket bündeln. AVV, TOM-Summary, Subprocessor-Liste, Löschkonzept, Transferinformationen und Sicherheitskontakt versioniert bereitstellen.

Tage 11 bis 12: Sales und Support befähigen. Kurze Standardantworten für Kundenfragebögen erstellen; Sonderfälle an eine klar benannte verantwortliche Person eskalieren.

Tage 13 bis 14: Review-Auslöser verbindlich festlegen. Überprüfung bei neuen Tools, neuen KI-Features, Hosting-Regionen, Supportprozessen oder neuen Unterauftragsverarbeitern.

Fazit: Gute Vorbereitung verhindert den nächsten Sales-Blocker

Ein belastbarer Auftragsverarbeitungsvertrag SaaS entsteht nicht durch Copy-Paste einer Vorlage, sondern aus sauber dokumentierten Rollen und Datenflüssen, die zu eurem echten Produkt passen. Wendet die Schnellprüfung aus diesem Beitrag auf euer eigenes Produkt und eure wichtigsten Vendoren an und baut anschließend euer Procurement-Paket entlang des 14-Tage-Plans auf.

Pro-Tipp: Bei komplexen Rollenfragen, besonderen Kategorien personenbezogener Daten, umfangreicher KI-Nutzung oder internationalen Datenflüssen lohnt sich der Griff zu spezialisierter Datenschutzberatung. Dieser Beitrag liefert die Struktur dafür, ersetzt aber keine individuelle Rechtsberatung.

FAQ: Häufige Fragen zum Auftragsverarbeitungsvertrag SaaS

Was kostet ein Auftragsverarbeitungsvertrag für SaaS-Startups?

Die Kosten hängen stark davon ab, ob ihr eine angepasste Mustervorlage nutzt oder eine individuelle Ausarbeitung durch eine Kanzlei beauftragt. Entscheidender als der reine Vertragspreis ist oft der interne Aufwand, um Rollen, TOMs und Subprozessoren korrekt zu dokumentieren.

Braucht jedes SaaS-Startup automatisch einen AVV?

Nein. Ein AVV ist nur erforderlich, wenn ihr personenbezogene Daten tatsächlich im Auftrag und nach Weisung eures Kunden verarbeitet. Bei eigenständigen Verantwortlichen, gemeinsamer Verantwortlichkeit oder echt anonymisierten Daten ist ein klassischer AVV nicht die passende Lösung.

Was ist der Unterschied zwischen AVV und SCC?

Der AVV regelt die Auftragsverarbeitung nach Artikel 28 DSGVO. Die Standardvertragsklauseln, kurz SCC, sind ein separater Mechanismus für bestimmte Datenübermittlungen in Drittländer. Beide können parallel relevant sein, ersetzen sich aber nicht gegenseitig.

Wie gehe ich mit einem AV-Vertrag für KI-Tools um?

Prüft konkret, ob Prompts, Dokumente und Outputs ausschließlich für die Kundenfunktion verarbeitet werden oder zusätzlich für Training, Modellverbesserung oder eigene Analysen genutzt werden. Nur wenn Letzteres ausgeschlossen oder klar geregelt ist, ist ein klassischer AVV belastbar.

Wie oft sollte ich meinen AVV und mein Procurement-Paket überprüfen?

Ein sinnvoller Standard sind feste Review-Auslöser: neue Tools, neue KI-Features, neue Hosting-Regionen, veränderte Supportprozesse oder neue Unterauftragsverarbeiter sollten jeweils eine Überprüfung anstoßen, statt nur einmal jährlich pauschal zu prüfen.

Transparenzhinweis: Dieser Beitrag wurde unter Zuhilfenahme künstlicher Intelligenz erstellt und vor der Veröffentlichung redaktionell geprüft. Alle Zahlen und Angaben wurden gegen die im Text verlinkten Primärquellen abgeglichen. Die Bilder wurden mit Hilfe von künstlicher Intelligenz erstellt.