Was gehört in einen AVV? Auftragsverarbeitungsvertrag nach Art. 28 DSGVO

Auftragsverarbeitung ist Alltag: Cloud-Hosting, Newsletter-Versand, Support-Desk, Payment-Gateway, KI-Labeling, CRM-Betrieb. Spätestens wenn personenbezogene Daten im Auftrag verarbeitet werden, verlangt Art. 28 DSGVO einen belastbaren Auftragsverarbeitungsvertrag (AV-Vertrag, AVV). Der AVV ist kein Formularanhang, sondern die rechtsverbindliche Brücke zwischen Technik, Organisation und Haftung. Dieser Beitrag bündelt die Pflichtinhalte aus Art. 28 Abs. 3 DSGVO in einem strukturierten Fließtext, zeigt praxistaugliche Klauselmechaniken für Subprozessoren, Audits, TOMs und Datenportabilität und grenzt typische Fehlerbilder ab. Stilistisch knüpft der Text an die kompakten Wissensbeiträge auf itmedialaw.com an, vertieft aber die operative Ebene für SaaS-, Agentur-, Games- und KI-Setups.

 Ausgangspunkt und Anwendungsbereich

Auftragsverarbeitung meint die Verarbeitung personenbezogener Daten „im Auftrag“ eines Verantwortlichen. Maßgeblich ist nicht die Etikette „Dienstleister“, sondern die Weisungsgebundenheit und Zweckbindung: Der Verarbeiter agiert nicht für eigene Zwecke, sondern ausschließlich innerhalb der dokumentierten Weisungen des Verantwortlichen. Typische Konstellationen sind Hosting, E-Mail-Versand, Analytik, Lohnabrechnung, Ticketsysteme, Content-Moderation oder Datenanreicherung. Die Abgrenzung zu gemeinsamer Verantwortlichkeit (Art. 26 DSGVO) und zu eigenständiger Verantwortlichkeit ist zwingend: Wer Zwecke mitbestimmt, ist nicht mehr „bloß Verarbeiter“. Die rechtliche Trennschärfe schützt vor Rollenkonflikten und verhindert, dass Betroffenenrechte, Informationspflichten, Löschfristen oder Sicherheitsniveaus falsch verortet werden. Ein Blick in die kompakten itmedialaw-Einführungen zeigt die Praxisnähe des Themas im Vertrags- und Cloud-Kontext.

Ein AVV muss den Gegenstand und die Dauer der Verarbeitung benennen. Das meint nicht nur die Überschrift „Hosting“, sondern eine sprechende Beschreibung, welche Verarbeitungsvorgänge der Auftrag erfasst (Speichern, Abrufen, Übermitteln, Löschen, Sichern, Testen, Trainieren). Die Dauer folgt der Lebenszeit des Hauptvertrags, wird aber für Backups, Log-Retention und Nachlaufprozesse differenziert geregelt. Ohne diese Differenzierung bleiben Löschung und Herausgabe reine Theorie.

Erforderlich sind Art und Zweck der Verarbeitung. Wer ein CRM betreibt, verarbeitet beispielsweise Stamm-, Kontakt- und Interaktionsdaten zur Kundenverwaltung; ein DSP/AdTech-Partner verarbeitet pseudonyme IDs zur Kampagnenaussteuerung; ein Annotation-Dienst verarbeitet Bild-, Text- oder Audiosegmente zum KI-Training. Der Zweck ist strikt; eine „Zweckfortschreibung“ für interne Analytik des Verarbeiters ist ohne gesonderte Rechtsgrundlage unzulässig.

Zu nennen sind Art der personenbezogenen Daten und Kategorien betroffener Personen. Die Kategorien werden nicht generisch, sondern projektbezogen beschrieben (z. B. Kund*innen, Leads, Beschäftigte, Creator, Spieler-Accounts; Datenarten wie Identifikations-, Kommunikations-, Vertrags-, Nutzungs-, Support-, Zahlungs- oder Gesundheitsdaten). Je sensibler die Daten (Art. 9), desto präziser die TOM-Tiefe, desto enger die Subprozessor-Steuerung.

Der AVV verankert Rechte und Pflichten des Verantwortlichen, insbesondere das Weisungsrecht. Weisungen werden schriftlich oder in einem System dokumentiert; der Verarbeiter prüft offenkundig rechtswidrige Weisungen und meldet Bedenken. Das Weisungsregime schließt Notfall-Weisungen ein, wenn Sicherheitsvorfälle ein sofortiges Handeln erfordern.

Kern der Verarbeiterpflichten sind Vertraulichkeit, TOMs und Sicherheitsniveau. Jede Person mit Datenzugriff wird auf Vertraulichkeit verpflichtet; die TOMs orientieren sich an Art. 32 DSGVO und werden als dynamische Anlage geführt. Dazu gehört, dass Stand der Technik, Implementierungskosten, Art, Umfang, Umstände und Zwecke berücksichtigt werden. Der AVV verweist nicht nur auf „ISO-Zertifikate“, sondern beschreibt Zugriffskontrollen, Verschlüsselung, Schlüsselmanagement, Netzwerksegmentierung, Härtung, Logging/Monitoring, Backup/Restore, Schwachstellen-Management, MFA-Pflichten, Rollen- und Rechtekonzepte, Pseudonymisierung/Minimierung, Test- und Staging-Isolation und regelmäßige Wirksamkeitsprüfungen.

Der Verarbeiter unterstützt den Verantwortlichen bei Betroffenenrechten (Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch), bei Sicherheitsvorfällen (Art. 33/34), bei DSFA (Art. 35) und bei Aufsichtsbehörden-Kommunikation – jeweils mit klaren Reaktionszeiten und Prozessbeschreibungen. Ohne SLA-Takte werden Fristen zur bloßen Hoffnung.

Nach Auftragsende erfolgt Löschung oder Rückgabe der personenbezogenen Daten, einschließlich Archiv-, Backup- und Log-Bestände, sofern keine gesetzliche Aufbewahrung entgegensteht. Der AVV regelt Exportformate und Prüfmechanismen, etwa stichprobenhafte Delete-Nachweise oder Hash-basierte Abgleichsverfahren, um „Löschfiktionen“ zu vermeiden.

Schließlich sind Nachweis- und Auditpflichten zu verankern. Der Verarbeiter stellt alle Informationen bereit, die zur Nachweisführung der Compliance erforderlich sind, und ermöglicht Prüfungen – durch den Verantwortlichen oder unabhängige Prüfer – unter angemessenen Schutzvorkehrungen. Der AVV balanciert dabei Vertraulichkeit, Frequenz und Kosten und erlaubt Remote-Audits, kombinierte Audit-Wochen, Report-Anerkennung (z. B. ISO/SOC) sowie Nachprüfungen nach Major-Incidents.

Wichtig für die Gestaltung: Elektronische Form genügt (Art. 28 Abs. 9 DSGVO). Der AVV ist also signatur- oder portal-fähig; gelebte Änderungsprotokolle und Versionsstände sichern die Beweisführung im Audit. (

Subprozessoren: Erlaubnis, Kette, Kontrolle

Ohne Subprozessoren funktioniert kein modernes Setup. Gleichwohl verlangt Art. 28 Abs. 2/4 DSGVO eine vorgängige Genehmigung und die Durchreichung sämtlicher Pflichten an die Unterverarbeiter. Zwei Modelle sind üblich: spezifische Einzelfallgenehmigung oder allgemeine Genehmigung mit Subprozessor-Register und Widerspruchsrecht. Praxisfest ist die allgemeine Genehmigung mit klaren Ankündigungsfristen bei Wechseln und Neuzugängen, differenziert nach „kritisch“ (Storage, Core-Compute, Identity) und „nicht kritisch“ (z. B. E-Mail-Zustellung). Ein Register nennt Firma, Funktion, Land, Datenkategorien und die maßgeblichen TOM-Anker. Flow-Down heißt: dieselben Datenschutzpflichten gelten in der Kette, einschließlich Audit-Kooperation und Incident-Meldewegen. Bei Drittlandbezug werden zusätzliche Garantien vereinbart (Standardvertragsklauseln, ggf. Transfer Impact Assessment). Ein schlanker, aber belastbarer Prozess verhindert „Schatten-Subprozessoren“ und adressiert Wechsel-Szenarien, ohne den Betrieb zu blockieren.

Auditrechte ohne Stillstand: Nachweise, Remote-Prüfung, Anerkennungslogik

Audits sind kein Freibrief zur Betriebsunterbrechung. Der AVV definiert, wie geprüft wird: bevorzugt Remote-Audits, Einsicht in Policies, TOM-Anlagen, Risiko- und Maßnahmenregister, Stichproben von Tickets/Vorfällen, Einsicht in Pen-Test-Zusammenfassungen und Zertifizierungs-Reports. On-Site-Audits bleiben für sicherheitskritische Fälle und angekündigte Slots vorbehalten. Ein Anerkennungsmechanismus stellt klar, welche externen Nachweise die Auditpflicht teilweise erfüllen (z. B. ISO 27001, SOC 2 Type II), ohne die gesetzlichen Kontrollrechte auszuhebeln. Fristen, Prüftage-Kontingente und Vertraulichkeits-Schleusen (Clean Rooms, View-Only-Zugriffe) verhindern Datenabflüsse und minimieren Geschäftsgeheimnis-Risiken.

TOMs richtig aufsetzen: Art. 32-Niveau, aber operativ

TOM-Anhänge geraten oft zu Schlagwortlisten. Wirksam wird der TOM-Anhang, wenn technische und organisatorische Maßnahmen kategorisiert, messbar und prüfbar sind. Dazu zählen Identitäts- und Rechteverwaltung (RBAC/ABAC, least privilege, JIT-Admin), MFA für interne und externe Zugriffe, Schlüsselmanagement (KMS/HSM, Rotation, Separation of Duties), Verschlüsselung at rest und in transit, Netzwerksegmentierung und Zero-Trust-Prinzipien, Sicherheits-Logging mit fälschungssicheren Speichern, Backup/Restore inklusive regelmäßiger Recovery-Tests, Schwachstellen- und Patch-Prozesse, Secure-SDLC (Code-Reviews, SAST/DAST, Secrets-Scanning, Build-Integrity), Data-Lifecycle-Management (Minimierung, Pseudonymisierung, Retention), Lieferketten-Kontrollen (SBOM, Abhängigkeits-Monitoring), Home-Office/BYOD-Regeln und Awareness-Programme. Die Wirksamkeitsprüfung erfolgt zyklisch und nach Major-Changes; Ergebnisse fließen in das Risikoregister. Die Aufsichtsbehörden erinnern daran, dass TOMs nicht zwingend im AVV selbst vollständig ausbuchstabiert sein müssen, sondern nachweisbar bewertet und dokumentiert werden; operativ sinnvoll ist die Versionierung in einer Anlage mit Änderungsprotokoll.

Datenportabilität, Exit-Strategie und Löschnachweise

Der sauberste AVV verliert an Wert, wenn der Exit ungeklärt bleibt. Eine Portabilitäts-Klausel definiert deshalb Exportpfade: Formate (CSV, JSON, Parquet), Schemata, API-Zugänge, Zeitleisten, Revisionsschleifen und Kostenlogiken. Für komplexe Mandanten-Daten (z. B. in SaaS-Systemen) wird eine „Read-Only-Phase“ nach Vertragsende vereinbart, während der Zugriff noch möglich ist, aber keine neue Verarbeitung stattfindet. Löschung bedeutet nicht nur das Entfernen aus Produktivsystemen; der AVV bezieht Backups, Snapshots, Cold-Storage, Crash-Dumps und Protokolldaten ein. Stichprobenhafte Lösch-Atteste oder Hash-Vergleiche sichern die Nachweisführung, ohne Betriebsgeheimnisse zu entblößen. In Kettenverhältnissen verpflichtet der Verarbeiter Subprozessoren zur synchronen Löschung und dokumentiert deren Nachweise im Register.

Praxisbeispiele aus SaaS, KI und Games

SaaS-Betrieb eines CRM: Verantwortlicher nutzt ein gehostetes CRM. Der AVV beschreibt Verarbeitungsvorgänge (Erfassen, Speichern, Segmentieren, Senden, Löschen), Datenarten (Stamm-, Kommunikations-, Nutzungsdaten), Betroffenengruppen (Leads, Kund*innen), TOM-Niveau (u. a. Verschlüsselung, RBAC, MFA), Subprozessoren (IaaS-Provider, E-Mail-Relay), Audit-Mechanik (Remote, SOC-Reports, jährliche Slot-Prüfung), Exit (Voll-Export, Datenlöschung, Log-Retention). Der Verantwortliche erhält Betroffenenkopien über den SaaS-Export; der Verarbeiter unterstützt, wenn Systemfelder nicht 1:1 auslesbar sind. Auf diese Weise wird das in der itmedialaw-Wissensdatenbank oft skizzierte Datenschutz-Fundament in die Produktpraxis übersetzt.

KI-Annotation und Fine-Tuning: Ein Labeling-Dienst verarbeitet Bild- und Textdaten. Der AVV fixiert strenge Zweckbindung, Geheimhaltung, isolierte VDI-Umgebungen, Wasserzeichen für synthetic data, Umgang mit halluzinierten Inhalten, und einen spezifischen Prozess zur Betroffenenrechte-Unterstützung bei Trainings-Datasets. Bei Drittlandbezug werden SCC implementiert; Subprozessor-Wechsel werden 30 Tage zuvor angezeigt. DSFA-Unterstützung erhält eigene Reaktionsfenster. Messbare TOM-Kriterien (Keine BYOD-Speicher, Copy/Paste-Blocker, Clipboardschutz) steigen in den Audit-Scope auf.

Games-Live-Ops mit externer Cloud: Telemetrie-Daten fließen in eine Analytics-Pipeline. Der IaaS-Provider ist Subprozessor; ein Event-Processing-Dienst und ein A/B-Testing-Tool ebenso. Der AVV verlangt Datenminimierung (nur erforderliche Events), getrennte Pseudonyme, Lösch-Propagation Richtung Subprozessoren und eine klare A/B-Datenaufbewahrung. Da Live-Ops schnell ist, regelt der AVV ein Express-Weisungsfenster für Hotfix-Änderungen an Event-Schemas, damit die Zweckbindung nicht „überholt“ wird.

Typische Fehler – und wie sie vermieden werden

Unbestimmter Scope: „Verarbeiter darf Daten zur Vertragserfüllung verarbeiten“ beschreibt weder Vorgänge noch Zwecke. Folge sind Erweiterungen durch die Hintertür. Abhilfe: sprechender Scope inkl. Vorgangskatalog und Beispiel-Matrix, die den Rahmen zieht, ohne starre Technik zu verrechtlichen.

Leere TOM-Schlagworte: „Verschlüsselung, Logging, Backup“ ohne Verfahren und Prüfpfade genügt nicht. Ein TOM-Anhang benennt Verfahren (z. B. TLS-Versionen, KMS-Betrieb, Rotationszyklen), Kontrollen (Rollenzuordnung, Rezertifizierung) und Prüfungen (Recovery-Tests, Pen-Tests-Rhythmus).

Schatten-Subprozessoren: Agenturen binden „kleine Helfer“ ein, ohne Register-Update. Lösung: allgemeine Genehmigung mit Register, Schwellenwerte für „kritisch“, Benachrichtigungsfenster, Widerspruchs-Option und Exit-Varianten bei zwingenden Wechseln.

Unrealistische Auditrechte: „Jederzeit, unangekündigt, vollständiger Systemzugriff“ ist in skalierenden Multi-Tenant-Umgebungen nicht praktikabel. Ein kluger AVV koppelt Remote-Prüfungen, Report-Anerkennung und Slot-Audits mit Eskalationsstufen für Incidents.

Exit ohne Portabilität: „Löschung nach Ende“ ohne Exportformate führt zu Lock-In. Ein Portabilitäts-abschnitt definiert Formate, Fristen, Schnittstellen und Kostenlogik, damit Daten tatsächlich übergeben werden können.

Art. 26-/28-Verwechslung: Joint-Controller-Modelle werden fälschlich als AVV etikettiert. Ergebnis: Falsche Informationspflichten, unklare Verantwortlichkeit bei Betroffenenrechten, Haftungsverschiebungen. Abgrenzung erfolgt über Zweckbestimmung: Wer Zwecke mitbestimmt, ist am Steuer, nicht auf dem Beifahrersitz.

„Datenschutz später“ in agilen Roll-outs: Feature-Teams gehen live, AVV folgt. Das ist riskant. Verträge und TOM-Prozesse sind frühe Enable-Voraussetzungen – nicht nachrangige Formalitäten.

Kopierte Muster ohne Datenwirklichkeit: Copy-&-Paste fremder Klauseln ignoriert reale Datenflüsse, Subprozessor-Ketten und Löschlogik. Das rächt sich im Audit oder nach einem Incident. Praxisleitfäden erinnern deshalb daran, die Pflichtinhalte konkret zu verankern.

Mini-Musterlogik in Worten – ohne Formularästhetik

Ein Scope-Abschnitt benennt Verarbeitungsvorgänge, Zwecke, Datenarten, Betroffenenkategorien und die operativen Systeme. Er enthält einen dynamischen Anhang „Verarbeitungstätigkeiten“ mit Versionierung. Ein Weisungs-Abschnitt beschreibt Kanäle (Ticket, Portal, E-Mail-Signatur), Prioritäten, Reaktionsfenster und die Pflicht zur Beanstandung offenkundig rechtswidriger Weisungen. Der TOM-Abschnitt verweist auf einen fortschreibbaren TOM-Anhang mit technischen und organisatorischen Maßnahmen, Prüf- und Review-Zyklen; Änderungen werden dokumentiert und angekündigt, ohne jedes Mal neu zu verhandeln. Der Subprozessor-Abschnitt wählt die allgemeine Genehmigung, stellt ein Register bereit, regelt Ankündigungsfristen, Widerspruch und flow-down inkl. Audit-Kooperation. Der Audit-Abschnitt erlaubt Remote-Prüfungen, anerkennt ISO/SOC-Berichte, wahrt Mandanten- und Geheimnisschutz und macht On-Site zur Ausnahme mit Vorlauf. Der Support-Abschnitt für Betroffenenrechte, DSFA und Incidents enthält SLA-Fenster (z. B. 48 h für Erstreaktion bei Datenschutzvorfällen; 5 Werktage für betroffenenrechtliche Zuarbeit). Der Datenübermittlungs-Abschnitt ordnet Drittlandsübermittlungen und SCC sauber ein und koppelt Transfer Impact Assessments an Subprozessor-Wechsel. Portabilität und Exit definieren Exportformate, Prüfschritte, Lösch-Propagation und Nachweise. Haftung/Vertragsstrafe bleiben maßvoll und kausalitätsnah; sie sind kein Ersatz für gute TOMs, sondern flankieren Sorgfaltspflichten.

Verzahnung mit dem Hauptvertrag

Der AVV lebt nicht isoliert, sondern bezieht sich auf den Hauptvertrag. Servicebeschreibungen und SLA müssen die Datenschutz-Pflichten spiegeln: Wenn 24/7-Support vereinbart ist, brauchen Incident-Prozesse 24/7-Erreichbarkeit; wenn Near-/Offshore-Teams arbeiten, muss das Subprozessor-Register und die Transfer-Absicherung dieses Setup abbilden. Preisblöcke berücksichtigen Datenschutz-Aufwände (z. B. Export-Aufwände oder zusätzliche Audittage) transparent, statt sie zu „verstecken“. Change-Prozesse sehen eine Datenschutz-Prüfung vor (Privacy by Design/Default), damit neue Features nicht an Art. 28 scheitern. So entsteht eine konsistente Linie, die man auf itmedialaw.com im Cloud- und Vertragsumfeld wiedererkennt: Datenschutz wird als integraler Teil der Produktleistung verstanden, nicht als störende Beilage.

Operative Durchführung: Governance schlägt Formular

Ein unterschriebener AVV ist nur der Anfang. Verantwortliche prüfen vor Beginn eines Dienstleister-Einsatzes, ob hinreichende Garantien bestehen – nicht erst im Incident. Dazu gehört die Bewertung der TOMs, die Einsicht in Zertifikate/Reports, ein Risiko-Scoring und die Dokumentation im Vendor-Register. Während der Laufzeit wird dieser Status turnusmäßig aktualisiert, bei Major-Changes und Incidents ad hoc. Der Verarbeiter führt Awareness-Programme durch, erneuert Vertraulichkeitsbindungen, kontrolliert Zugriffsrechte und pflegt die Subprozessor-Liste. Der gemeinsame Blick gilt der Nachweisführung: Wer in drei Klicks zeigen kann, welche TOM-Version galt, wann ein Subprozessor neu aufgenommen wurde und wann der letzte Restore-Test erfolgreich war, besteht jede Prüfung – vertraglich und faktisch. Diese Governance-Linie ergibt sich aus den Grundpflichten von Art. 28 Abs. 1, 3 DSGVO und der dort angelegten Nachweislogik.

12. Kurzantwort für die Suchintention „AV-Vertrag / Auftragsverarbeitungsvertrag Muster“

Was gehört in einen AVV? Ein klarer Verarbeitungsscope mit Dauer, Zwecken, Datenarten und Betroffenen; ein dokumentiertes Weisungsregime; belastbare TOMs nach Art. 32; transparente Subprozessor-Ketten mit Genehmigung, Ankündigungsfristen und flow-down; Audit- und Nachweismechanik; SLA-fähige Unterstützung bei Betroffenenrechten, DSFA und Incidents; Exit- und Portabilitäts-Regelungen; Löschung mit Nachweis; Drittland-Absicherung; und eine konsistente Verzahnung mit dem Hauptvertrag. Wer diese Elemente auf der Ebene von Verfahren, Fristen und Nachweisen verankert, hat nicht nur „einen AVV“, sondern eine überprüfbare Datenschutz-Architektur. Praxis-Checklisten zeigen denselben Kern – entscheidend ist die Übersetzung in den eigenen Tech-Stack. (

Fazit

Ein guter AV-Vertrag ist präzise, prüfbar und betrieblich umsetzbar. Pflichtinhalte aus Art. 28 DSGVO bilden das Fundament; Subprozessor-Steuerung, Audit-Mechanik, TOM-Versionierung und Portabilität machen den Vertrag alltagstauglich. Muster helfen – entscheidend bleibt die Anpassung an reale Datenflüsse, Systeme und Verantwortlichkeiten. Für Cloud-, SaaS-, Games- und KI-Vorhaben gilt: Der AVV ist Produkt- und Prozessrecht zugleich. Wer ihn so versteht, reduziert Risiken, beschleunigt Audits und schafft Vertrauen bei Kundschaft, Partnern und Aufsicht.

Empfehlung: Vor Abschluss und bei größeren Änderungen die konkrete Datenwirklichkeit prüfen – und beraten lassen.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.