Auftragsverarbeitungsvertrag (AVV): DSGVO im Vertrag mit externen Entwicklern

Ein Auftragsverarbeitungsvertrag (AVV) ist schnell unterschrieben. Oft nehmen beide Seiten eine Vorlage aus dem Internet, tragen ein paar Firmennamen ein und haken das Dokument als erledigt ab. Das Problem: Vorlagen aus dem Internet sind so allgemein gehalten, dass sie im Streitfall wenig Substanz bieten. Wenn dein Entwicklungspartner Zugriff auf personenbezogene Daten hat - beim Testen, beim Hosting, beim Support nach dem Launch -, entscheidet nicht die Existenz eines AVV über deine Haftung, sondern der Inhalt seiner Klauseln. Dieser Artikel geht nicht noch einmal durch, wann du überhaupt einen AVV brauchst und was die DSGVO grundsätzlich verlangt - das steht in der DSGVO-Checkliste für Softwareprojekte. Hier geht es um den Vertrag selbst: welche Klauseln unbedingt reingehören, wo Entwicklungspartner in Verhandlungen gerne abwiegeln, was du unterschreiben solltest - und was nicht.

Gegenstand und Zweck der Verarbeitung präzise fassen

Art. 28 Abs. 3 DSGVO verlangt, dass ein AVV Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der personenbezogenen Daten und die Kategorien betroffener Personen konkret benennt. In der Praxis reicht vielen Anbietern "Verarbeitung von Kundendaten im Rahmen der Softwareentwicklung" - eine Formulierung, die im Ernstfall nichts aussagt. Bestehe stattdessen auf einer Anlage, die auflistet: welche Datenfelder verarbeitet werden (Name, E-Mail, Zahlungsdaten, Standortdaten und so weiter), zu welchem konkreten Zweck (Entwicklung, Testing, Produktivbetrieb, Support) und für welchen Zeitraum. Je präziser diese Anlage, desto klarer lässt sich später beurteilen, ob sich der Auftragnehmer im vereinbarten Rahmen bewegt hat oder nicht.

Weisungsgebundenheit vertraglich verankern, nicht nur behaupten

Die Pflicht zur Weisungsgebundenheit steht in praktisch jedem AVV-Muster. Meist als einzeiliger Satz wie "Der Auftragnehmer verarbeitet Daten nur auf dokumentierte Weisung des Auftraggebers". Das reicht rechtlich, klärt aber nicht, wie eine Weisung in der Praxis aussieht. Kläre deshalb konkret: Wer bei dir ist weisungsbefugt? Muss eine Weisung schriftlich (E-Mail reicht meist) oder in einem bestimmten Tool dokumentiert werden? Was passiert, wenn der Auftragnehmer eine Weisung für rechtswidrig hält? Hat er eine Hinweispflicht, bevor er sie ausführt oder ablehnt? Ohne diese Details wird die Weisungsgebundenheit zur Floskel, die im Streitfall schwer zu beweisen ist, weil niemand dokumentiert hat, welche Weisung wann gegeben wurde.

Subunternehmer nicht nur offenlegen, sondern genehmigungspflichtig machen

Ein AVV muss regeln, ob und wie der Auftragnehmer weitere Subprozessoren einsetzen darf (Art. 28 Abs. 2 und 4 DSGVO). Viele Vorlagen sehen dafür lediglich eine "allgemeine Genehmigung" vor: Der Auftragnehmer darf neue Subprozessoren einsetzen, solange er dich informiert und du nicht innerhalb einer Frist widersprichst. Das klingt fair, verschiebt die Kontrolle aber faktisch auf den Auftragnehmer, weil ein Widerspruch in der Praxis selten ausgeübt wird - und wenn doch, oft zu spät kommt, weil das Projekt schon auf dem neuen Dienst aufbaut. Verhandle stattdessen eine möglichst kurze, aber echte Prüf- und Widerspruchsfrist (zwei bis vier Wochen sind üblich) und verlange, dass jede neue Subprozessor-Meldung mindestens Name, Sitz und Verarbeitungszweck des neuen Dienstleisters enthält - nicht nur die Ankündigung "wir setzen jetzt einen neuen Anbieter ein".

Wichtiger Verhandlungspunkt, der oft übergangen wird: Der Auftragnehmer muss mit jedem Subprozessor selbst einen AVV mit mindestens gleichwertigen Pflichten abschließen (Art. 28 Abs. 4 DSGVO) und muss dir das auf Verlangen nachweisen können. Ein Anbieter, der diese Nachweispflicht in Verhandlungen streichen will, verschiebt damit ein Risiko auf dich, das eigentlich seines ist.

Technische und organisatorische Maßnahmen (TOMs) als verbindliche Anlage

Die TOM-Anlage ist der Teil eines AVV, der in der Praxis am leichtesten zur reinen Formsache verkommt. Viele Entwicklungspartner legen ein generisches TOM-Dokument bei, das seit Jahren nicht aktualisiert wurde und pauschale Aussagen wie "Zugriffskontrolle nach dem Stand der Technik" enthält, ohne zu sagen, was das konkret bedeutet. Verlange stattdessen konkrete Angaben zu:

Verschlüsselung von Daten bei Übertragung und Speicherung (welches Verfahren, nicht nur "verschlüsselt")
Zugriffskontrolle: Wer hat Zugriff auf welche Umgebung, und wie wird das protokolliert?
Trennung von Entwicklungs-, Test- und Produktivumgebungen, insbesondere ob echte Kundendaten in Testumgebungen landen
Backup- und Wiederherstellungskonzept, inklusive Aufbewahrungsdauer von Backups
Verfahren zur regelmäßigen Überprüfung der Maßnahmen (Art. 32 Abs. 1 lit. d DSGVO verlangt genau das)

Ein weiterer Punkt, der in Verhandlungen gerne untergeht: Vereinbare, dass die TOM-Anlage bei wesentlichen Änderungen der Infrastruktur (zum Beispiel Wechsel des Hosting-Anbieters) automatisch aktualisiert werden muss, statt erst bei der nächsten Vertragsverlängerung.

Löschung und Rückgabe nach Vertragsende konkret regeln

Art. 28 Abs. 3 lit. g DSGVO verlangt, dass Daten nach Ende der Vertragslaufzeit gelöscht oder zurückgegeben werden - je nach deiner Wahl. In der Praxis ist genau das der Punkt, an dem viele AVV vage bleiben: "Der Auftragnehmer löscht alle Daten nach Vertragsende" klingt eindeutig, sagt aber nichts über Backups, Log-Dateien, Staging-Kopien oder lokale Entwicklerrechner. Verhandle deshalb:

Eine konkrete Frist für die Löschung (zum Beispiel 30 Tage nach Vertragsende)
Eine schriftliche Bestätigung der vollständigen Löschung, nicht nur eine Behauptung
Eine explizite Aussage dazu, wie mit Backups umgegangen wird - diese laufen oft nach einem eigenen Zyklus aus und werden in Standardverträgen schlicht vergessen
Ein Recht auf Datenrückgabe in einem strukturierten Format, falls du die Daten weiterverwenden willst, statt sie nur löschen zu lassen

Kontroll- und Auditrechte, die im Ernstfall auch nutzbar sind

Ein AVV muss dir Kontrollrechte einräumen (Art. 28 Abs. 3 lit. h DSGVO) - aber viele Vorlagen formulieren das so, dass ein tatsächliches Audit faktisch unmöglich ist, etwa durch überlange Ankündigungsfristen oder eine Klausel, die Vor-Ort-Prüfungen komplett ausschließt und nur "Selbstauskünfte" des Auftragnehmers zulässt. Für ein KMU-Projekt reicht es, wenn der Vertrag alternativ zum Vor-Ort-Audit ein aktuelles Zertifikat (z.B. ISO 27001) oder einen unabhängigen Prüfbericht als Nachweis akzeptiert - verlange aber, dass diese Nachweise regelmäßig aktualisiert und auf Anfrage unaufgefordert vorgelegt werden, nicht erst nach mehrfacher Nachfrage.

Haftung und Meldefristen nicht dem Standardtext überlassen

Die DSGVO regelt die grundsätzliche Haftungsverteilung zwischen Verantwortlichem und Auftragsverarbeiter (Art. 82 DSGVO), aber ein AVV kann und sollte die praktischen Abläufe im Schadensfall konkretisieren. Zwei Punkte sind besonders verhandlungsrelevant:

Meldefrist bei Datenpannen: Du hast als Verantwortlicher nur 72 Stunden ab Kenntnis, um eine Datenpanne bei der Aufsichtsbehörde zu melden (Art. 33 DSGVO). Mit "Kenntnis" ist dabei nicht deine eigene Kenntnis gemeint: Nach der Auslegung der Art.-29-Datenschutzgruppe (WP250, von der EDPB übernommen) giltst du bereits als "in Kenntnis", sobald dein Auftragsverarbeiter die Datenpanne bemerkt - unabhängig davon, wann er dich tatsächlich informiert. Deine Frist läuft also schon, während du noch nichts davon weißt. Bei einer Kette aus mehreren Subprozessoren ist rechtlich nicht abschließend geklärt, ob das bis zum entferntesten Glied der Kette zurückwirkt, aber jede Verzögerung auf dem Weg zu dir geht faktisch von deiner Frist ab. Vereinbare deshalb eine deutlich kürzere Meldefrist des Auftragnehmers an dich - 24 Stunden ab Kenntnis ist ein realistischer Wert, den viele Anbieter zunächst auf 72 Stunden oder länger setzen wollen, weil sie ihre eigene interne Prüfung zuerst abschließen möchten. Diese 24 Stunden verschaffen dir keine zusätzliche Zeit, sondern begrenzen nur, wie viel von deiner ohnehin laufenden Frist durch die Meldekette verloren geht.
Haftungsbegrenzung: Manche Standard-AVV enthalten pauschale Haftungsobergrenzen, die auch DSGVO-Bußgelder erfassen sollen. Das ist rechtlich umstritten, sorgt aber im Streitfall für Verzögerung. Kläre diesen Punkt explizit im Hauptvertrag oder AVV, statt dich auf eine Auslegung im Ernstfall zu verlassen.

Fazit

Ein AVV ist kein Formular, das man abhakt, sondern ein Vertrag, der im Ernstfall trägt oder nicht. AVV-Vorlagen ähneln sich in der Grundstruktur. Aber die entscheidenden Punkte liegen in den Details: wie konkret die Verarbeitungszwecke beschrieben sind, ob Subprozessoren wirklich genehmigungspflichtig sind, ob die TOM-Anlage mehr als Textbausteine enthält, und ob Löschfristen und Meldefristen tatsächlich durchsetzbar formuliert sind. Nimm dir für die AVV-Verhandlung genauso viel Zeit wie für den Hauptvertrag - im Zweifel ist es das Dokument, das über deine Haftung entscheidet, nicht der Werkvertrag.

Häufig gestellte Fragen

Reicht ein Standard-AVV-Muster aus dem Internet aus?

Ein Muster kann als Ausgangspunkt dienen, deckt aber selten die konkreten Details ab, auf die es im Ernstfall ankommt - etwa präzise Verarbeitungszwecke, echte Genehmigungspflichten für Subprozessoren oder konkrete TOM-Angaben statt allgemeiner Floskeln. Prüfe jedes Muster gegen dein konkretes Projekt, statt es unverändert zu übernehmen.

Was passiert, wenn mein Entwicklungspartner die Löschfrist nach Vertragsende nicht einhält?

Das hängt davon ab, wie konkret die Löschpflicht im AVV formuliert ist. Ohne feste Frist und Nachweispflicht ist ein Verstoß schwer zu belegen. Vereinbare deshalb eine konkrete Frist (z.B. 30 Tage) und eine schriftliche Löschbestätigung als vertragliche Pflicht, nicht nur als allgemeine Absicht.

Muss der AVV Vor-Ort-Audits bei meinem Entwicklungspartner ermöglichen?

Nicht zwingend. Alternative Nachweise wie aktuelle Zertifizierungen oder unabhängige Prüfberichte reichen aus, solange diese regelmäßig aktualisiert und auf Anfrage vorgelegt werden. Wichtig ist, dass irgendeine wirksame Kontrollmöglichkeit vertraglich verankert ist.

Wie kurz sollte die Meldefrist meines Entwicklungspartners bei einer Datenpanne sein?

Deutlich kürzer als deine eigene 72-Stunden-Frist gegenüber der Aufsichtsbehörde. Diese Frist läuft bereits ab der Kenntnis deines Auftragsverarbeiters, nicht erst ab deiner eigenen Information. 24 Stunden ab Kenntnis des Vorfalls ist ein realistischer Verhandlungswert, der den Zeitverlust auf dem Weg zu dir begrenzt.

Muss jeder Subprozessor meines Entwicklungspartners einen eigenen AVV haben?

Ja. Der Auftragnehmer muss mit jedem Subprozessor einen AVV mit mindestens gleichwertigen Pflichten abschließen und dir das auf Verlangen nachweisen können. Verhandle diese Nachweispflicht explizit, falls sie im Vertragsentwurf fehlt oder gestrichen werden soll.