Der AVV hinter dem Vertrag: Engineering-Controls, die einen Auftragsverarbeitungsvertrag wahr machen

Jedes B2B-SaaS-Unternehmen, das an europäische Kunden verkauft, unterschreibt früher oder später einen Auftragsverarbeitungsvertrag (AVV). Der AVV ist der Vertragsanhang, der Artikel 28 der DSGVO in konkrete Zusagen übersetzt: Du verarbeitest Daten nur auf dokumentierte Weisung, Du führst eine aktuelle Subprozessor-Liste, Du unterstützt bei Betroffenenanfragen, Du meldest Datenpannen ohne unangemessene Verzögerung, und Du löschst Daten bei Vertragsende oder gibst sie zurück.

Jahrelang wurden die meisten AVVs unterschrieben und abgelegt. Niemand hat nachgeprüft. Das hat sich geändert. Enterprise-Käufer führen heute Vendor-Security-Reviews durch, die Nachweise verlangen, nicht Unterschriften. Ein Procurement-Fragebogen fragt 2026 routinemäßig, wie Du Benachrichtigungen über Subprozessor-Änderungen durchsetzt, wie lang Deine Backup-Aufbewahrung tatsächlich ist und ob Dein Lösch-Workflow auch Replikate abdeckt. Wenn Deine technische Realität nicht zu Deinem AVV passt, kommt die Lücke im Sales-Zyklus ans Licht, zum denkbar schlechtesten Zeitpunkt.

Dieser Beitrag geht die Klauseln durch, die in fast jedem Auftragsverarbeitungsvertrag stehen, und verbindet jede mit den Engineering-Controls, die sie wahr machen. Das Ziel ist keine Rechtsberatung. Es ist eine technische Checkliste, damit der Vertrag, den Du längst unterschrieben hast, zu dem System passt, das Du tatsächlich betreibst.

Warum der Auftragsverarbeitungsvertrag zum Engineering-Dokument wurde

Drei Kräfte haben den AVV aus dem Rechtsordner ins Backlog geschoben.

Erstens haben sich die Security-Teams auf Käuferseite professionalisiert. Mittelgroße europäische Unternehmen fahren heute dieselben Vendor-Risk-Prozesse, die vor fünf Jahren nur Banken hatten. Sie verschicken Fragebögen, fordern Beispielnachweise an und vergleichen Deine Antworten mit Deiner öffentlichen Subprozessor-Seite.

Zweitens nehmen Aufsichtsbehörden Auftragsverarbeiter direkt ins Visier. Behörden haben Prozessoren, nicht nur Verantwortliche, für Sicherheitsversäumnisse und für Verarbeitung jenseits dokumentierter Weisungen mit Bußgeldern belegt. Die Ära, in der sich ein Auftragsverarbeiter hinter seinem Kunden verstecken konnte, ist vorbei.

Drittens haben Zertifizierungen die Messlatte angehoben. Wenn Dein Wettbewerber SOC 2 Type II und passende AVV-Nachweise hat und Du ein PDF, das niemand verifizieren kann, zeigt sich dieser Unterschied in der Deal-Geschwindigkeit. Die Zertifizierungsseite haben wir in unserer SOC-2-Readiness-Checkliste behandelt; dieser Beitrag behandelt die Vertragsseite.

Klausel für Klausel: vom Versprechen zum Nachweis

1. Verarbeitung nur auf dokumentierte Weisung

Die Klausel klingt abstrakt, hat aber eine konkrete technische Bedeutung: Kein Mitarbeiter, kein Skript und kein Analytics-Job darf personenbezogene Kundendaten für Zwecke außerhalb des Vertrags anfassen.

Controls, die sie wahr machen:

• Rollenbasierte Zugriffskontrolle, bei der Kundendaten auf die Services beschränkt sind, die sie brauchen, nicht auf jeden mit VPN-Login.
• Ein Audit-Log, das festhält, wer auf die Daten welches Tenants zugegriffen hat und warum. Append-only-Speicherung oder Hash-Chaining macht das Log glaubwürdig.
• Ein dokumentierter Prozess für Support-Zugriffe: zeitlich begrenzt, mit Ticket verknüpft und geloggt.

Nachweise, die ein Käufer prüfen kann: eine Zugriffsrichtlinie, ein Audit-Log-Auszug mit geschwärzten personenbezogenen Daten und Protokolle der vierteljährlichen Access-Reviews.

2. Die Subprozessor-Liste und die Änderungsbenachrichtigung

Die meisten AVVs verpflichten Dich, eine aktuelle Subprozessor-Liste zu führen und Kunden zu benachrichtigen, bevor ein neuer hinzukommt. Engineering-Teams verletzen diese Klausel ständig, ohne es zu merken, denn einen Subprozessor hinzuzufügen ist so einfach wie npm install plus ein API-Key.

Controls, die sie wahr machen:

• Ein maschinenlesbares Subprozessor-Inventar, das jeden externen Dienst erfasst, der personenbezogene Daten berührt: Hosting, E-Mail-Versand, Error-Tracking, Analytics, LLM-APIs, Support-Tooling.
• Ein CI-Check oder eine Review-Regel, die neue ausgehende Integrationen markiert. Wenn ein Pull Request ein neues SDK oder einen externen Endpoint einführt, fragt das Review-Template, ob personenbezogene Daten verarbeitet werden.
• Ein Benachrichtigungs-Workflow: Ändert sich das Inventar, bekommen die Kunden auf der Benachrichtigungsliste automatisch eine E-Mail mit Widerspruchsfrist.

Die Falle, die Du vermeiden solltest: Error-Tracker und LLM-Anbieter. Stack Traces enthalten öfter personenbezogene Daten, als Teams annehmen, und Prompts an eine Modell-API sind Verarbeitung im Sinne der DSGVO. Beides gehört auf die Liste.

3. Technische und organisatorische Maßnahmen (die Anhang-II-Versprechen)

Der TOM-Anhang ist die Stelle, an der AVVs Zusagen zu Verschlüsselung, Zugriffskontrolle, Resilienz und Tests auflisten. Es ist auch die Stelle, an der kopierte Vorlagen Dinge versprechen, die das Team nie gebaut hat, etwa jährliche Penetrationstests oder Verschlüsselung at rest in jedem Datenspeicher.

Controls, die sie wahr machen:

• Verschlüsselung at rest, verifiziert über alle Speicher hinweg, auch die vergessenen: Object-Storage-Buckets, Log-Archive, Queue-Persistenz und Datenbank-Snapshots.
• TLS auch intern erzwungen, nicht nur am Edge.
• Dependency- und Image-Scanning in der CI, mit einem Patching-SLA, das Du tatsächlich einhältst.
• Regelmäßige Backup-Restore-Tests, mit dokumentiertem Ergebnis.

Der ehrliche Weg ist, den Anhang so umzuschreiben, dass er der Realität entspricht, und die Realität dann Release für Release zu verbessern. Ein kürzerer, wahrer Anhang schlägt in jedem ernsthaften Review einen langen, falschen. Wenn Du nicht sicher bist, wo Deine Codebasis steht, liefert Dir ein externes Code-Quality-Audit die Lückenliste, bevor das Security-Team eines Kunden sie für Dich findet.

4. Unterstützung bei Betroffenenrechten

Dein Kunde ist der Verantwortliche, aber wenn dessen Nutzer Auskunft oder Löschung verlangt, verpflichtet Dich der AVV, innerhalb einer definierten Frist zu helfen. Wenn ein Export-Request einen Engineer zwei Tage Ad-hoc-SQL kostet, hast Du kein Control, sondern ein Haftungsrisiko.

Controls, die sie wahr machen:

• Ein Export-Endpoint pro Tenant oder eine Admin-Aktion, die eine strukturierte, vollständige Kopie der Datensätze einer betroffenen Person erzeugt.
• Ein Lösch-Workflow, der idempotent ist, Suchindizes und Caches abdeckt und ehrlich mit der Backup-Aufbewahrung umgeht. Über die schwierigen Teile haben wir in Engineering the Right to Erasure geschrieben.
• Request-Tracking mit Zeitstempeln, damit Du belegen kannst, dass Du innerhalb der vertraglichen Frist geantwortet hast.

5. Meldung von Datenpannen ohne unangemessene Verzögerung

AVVs verpflichten den Auftragsverarbeiter typischerweise, den Verantwortlichen innerhalb einer festen Frist zu benachrichtigen, oft 24 bis 48 Stunden, deutlich enger als die 72 Stunden, die Artikel 33 dem Verantwortlichen gibt. Diese Frist ist eine technische Anforderung im juristischen Gewand: Du kannst nicht melden, was Du nicht erkennst.

Controls, die sie wahr machen:

• Alerting auf die Signale, die einer Breach-Entdeckung vorausgehen: anomales Query-Volumen, Auffälligkeiten bei der Authentifizierung, Egress in Exfiltrationsgröße.
• Ein Incident-Runbook, das die Person benennt, die entscheidet, ob ein Ereignis meldepflichtig ist, mit Stellvertretung für Urlaubszeiten.
• Ein aktuelles, exportierbares Kundenkontakt-Register, damit die Benachrichtigung nicht mit einer Suche im CRM beginnt.

Führe eine Tabletop-Übung pro Jahr durch. Die erste findet immer dieselbe Lücke: Niemand weiß, wer die Benachrichtigungs-E-Mail versenden darf.

6. Löschung oder Rückgabe bei Vertragsende

Die leiseste Klausel ist am häufigsten falsch. Wenn ein Kunde kündigt, müssen seine Daten innerhalb der vertraglichen Frist gelöscht oder zurückgegeben werden, einschließlich Replikaten, Analytics-Kopien und Backups jenseits des angegebenen Aufbewahrungsfensters.

Controls, die sie wahr machen:

• Ein Offboarding-Workflow, der durch das Vertragsende ausgelöst wird, nicht dadurch, dass sich jemand erinnert.
• Tenant-bezogene Löschung, die jeden Speicher aufzählt, in dem Tenant-Daten liegen. Eine Data Map, und sei es eine simple YAML-Datei im Repo, ist die Voraussetzung.
• Backup-Ablaufrichtlinien, die zur Aufbewahrungszahl im AVV passen. Wenn der AVV 90 Tage sagt und Deine Snapshots ein Jahr leben, ist der Vertrag heute falsch.
• Ein Löschzertifikat, generiert aus dem Abschluss-Log des Workflows, denn Käufer fragen danach.

Eine Mapping-Tabelle zum Übernehmen

AVV-Klausel	Engineering-Control	Nachweis-Artefakt
Nur dokumentierte Weisungen	RBAC plus Tenant-bezogenes Audit-Log	Zugriffsrichtlinie, Log-Auszug, Review-Protokolle
Subprozessor-Management	Inventar plus CI-Flag bei neuen Integrationen	Öffentliche Liste, Benachrichtigungs-E-Mails
Technische Maßnahmen (TOMs)	Verschlüsselung, Scanning, Restore-Tests	Config-Screenshots, CI-Reports, Testprotokolle
Unterstützung bei Betroffenenrechten	Export- und Lösch-Workflows	Request-Log mit Zeitstempeln
Breach-Meldung	Detection-Alerts plus Runbook	Tabletop-Bericht, Alert-Konfigurationen
Löschung bei Vertragsende	Offboarding-Workflow plus Backup-Ablauf	Löschzertifikat, Retention-Konfigurationen

Die Lücke schließen, ohne die Roadmap zu stoppen

Behandle den AVV wie eine fehlschlagende Testsuite. Liste jede Zusage auf, markiere sie als wahr, teilweise wahr oder falsch, und triagiere.

Woche eins ist das Audit: Lies Deinen eigenen AVV neben Deinem Architekturdiagramm und erstelle die Lückenliste. Die meisten Teams finden zwei oder drei falsche Klauseln und eine Handvoll teilweise wahrer.

Der erste Monat deckt die günstigen Erfolge ab: das Subprozessor-Inventar, die Angleichung der Backup-Aufbewahrung und die Support-Zugriffsrichtlinie. Nichts davon erfordert neue Infrastruktur.

Das erste Quartal deckt die Workflows ab: Tenant-Offboarding, Betroffenen-Export und das Breach-Runbook mit einem Tabletop-Durchlauf. Das sind echte Engineering-Projekte, aber richtig geschnitten jeweils Tage, nicht Monate.

Was übrig bleibt, ist meist strukturell, etwa Tenant-bezogene Löschung in einem System, das nie dafür entworfen wurde. Das ist ein Architekturprojekt, und es zahlt sich beim ersten reibungslosen Security-Review eines Großkunden aus. Wenn Deinem Team die Kapazität fehlt, diese Workflows neben der Feature-Arbeit zu bauen, ist das genau die Art von begrenztem Projekt mit großem Hebel, die wir in Custom-Software-Development-Engagements übernehmen.

FAQ

Reicht ein unterschriebener AVV für die DSGVO-Compliance als Auftragsverarbeiter? Nein. Der AVV ist die vertragliche Ebene. Artikel 28 verlangt zusätzlich, dass die beschriebenen Maßnahmen tatsächlich existieren, und Artikel 32 verlangt eine dem Risiko angemessene Sicherheit. Ein unterschriebenes Dokument ohne Controls dahinter kann die Lage verschlimmern, weil es Versprechen dokumentiert, die Du wissentlich nicht hältst.

Zählen LLM-API-Anbieter als Subprozessoren? Wenn Prompts oder Completions personenbezogene Daten enthalten, ja. Nimm den Anbieter in Deine Subprozessor-Liste auf, unterschreibe dessen AVV und prüfe, wo die Daten verarbeitet werden. Mehrere Anbieter bieten genau deshalb EU-Region-Endpoints mit Zero-Retention-Optionen an.

Unser AVV verspricht Backup-Löschung nach 30 Tagen, aber unsere Backups halten Daten ein Jahr. Was jetzt? Repariere die Seite, die günstiger zu reparieren ist, und zwar schnell. Entweder verkürzt Du die Backup-Aufbewahrung, oder Du änderst den AVV auf die echte Zahl mit klarer Begründung. Eine dokumentierte, ehrliche Aufbewahrungsfrist ist verteidigbar. Eine falsche Vertragsaussage nicht.

Wie viel davon prüfen Enterprise-Käufer wirklich? Jedes Jahr mehr. Subprozessor-Listen und Breach-Meldefristen werden inzwischen fast überall geprüft. Löschnachweise und TOM-Verifizierung tauchen in größeren Deals und regulierten Branchen auf. Das Muster entspricht dem, was wir in der B2B-SaaS-Security-Checkliste, die Enterprise-Kunden wirklich auditieren beschrieben haben.

Mach den Vertrag wahr

Ein Auftragsverarbeitungsvertrag ist eine Liste technischer Anforderungen in juristischer Kleidung. Teams, die ihn so behandeln, verwandeln Vendor-Reviews von einem Sales-Blocker in ein Abschlussargument.

Wenn Du ein zweites Paar Augen auf die Lücke zwischen Deinem AVV und Deiner Architektur haben willst: Genau diese Art von Review machen wir. Schreib an hello@wolf-tech.io oder besuche wolf-tech.io und nimm Kontakt auf. Ein fokussiertes Audit jetzt ist günstiger als ein blockierter Enterprise-Deal später.