Auftragsverarbeitung (AVV) für Wissensdatenbank-Anbieter: Was DACH-Buyer prüfen müssen

×

Der Auftragsverarbeitungsvertrag, kurz AVV, ist kein Bonusdokument, das ein Vendor netterweise mitliefert. Er ist seit 2018 nach Art. 28 DSGVO eine harte Voraussetzung. Wenn dein KB-Anbieter personenbezogene Daten in deinem Auftrag verarbeitet (und das tut jede gehostete Wissensdatenbank, sobald Mitarbeitende oder Kundenkontakte darin abgebildet sind), brauchst du einen unterschriebenen AVV vor der ersten Datenverarbeitung. Kein AVV, keine rechtmässige Nutzung. So einfach ist die Rechtslage.

Trotzdem scheitern Compliance-Audits regelmässig daran, dass ein AVV fehlt, lückenhaft ist, oder weil die Sub-Prozessoren-Liste nicht offengelegt wurde. Dieser Artikel sortiert, was nach Art. 28 DSGVO im AVV stehen muss, wie sich die Lage für US-Anbieter durch Schrems II und den EU-US Data Privacy Framework (Adequacy Decision vom 10. Juli 2023) verändert hat, welche KB-Anbieter heute einen AVV unterzeichnen, und welche fünf Fehler im Buying-Cycle wiederkehren.

Hinweis: Dieser Artikel gibt einen praxisorientierten Überblick. Für die konkrete Bewertung deines AVV solltest du deinen Datenschutzbeauftragten oder eine Fachanwältin für IT-Recht konsultieren.

Was AVV im DSGVO-Kontext bedeutet

Die DSGVO unterscheidet zwischen zwei Rollen: dem Verantwortlichen und dem Auftragsverarbeiter. Der Verantwortliche entscheidet über Zweck und Mittel der Datenverarbeitung. Das ist in den meisten KB-Szenarien dein Unternehmen, das sich entscheidet, Mitarbeiterzugriffe zu protokollieren und Kundenanfragen über das Help Center zu lenken. Der Auftragsverarbeiter handelt im Auftrag des Verantwortlichen. Das ist der KB-Vendor, der die Daten technisch hostet, sichert und verfügbar macht.

Art. 28 DSGVO regelt, dass diese beiden Rollen einen schriftlichen Vertrag brauchen, in elektronischer Form genügt (Art. 28 Abs. 9 DSGVO). Der Vertrag heisst in der deutschen Fachsprache Auftragsverarbeitungsvertrag (AVV oder seltener AV-Vertrag), im internationalen Kontext Data Processing Agreement (DPA). Beides ist dasselbe Dokument. Wer mit US-Anbietern arbeitet, bekommt typischerweise das englischsprachige DPA. Wer mit deutschen Anbietern arbeitet, bekommt typischerweise einen AVV auf Deutsch.

Der AVV ist kein Generalvertrag mit dem Vendor und auch kein Allgemeine Geschäftsbedingungen-Anhang. Er ist ein eigenständiges Vertragswerk, das parallel zum Hauptvertrag (z.B. dem SaaS-Subscription-Vertrag) existiert. In der Praxis liefert ein guter KB-Vendor den AVV als separates PDF, das beidseitig unterzeichnet wird. Ein schwacher Vendor versucht, den AVV in die AGB hineinzuziehen oder bietet nur eine Vorlage zum Selbst-Ausfüllen an. Das ist nicht per se unzulässig, aber ein Warnsignal.

Die 11 Mindestinhalte eines AVV nach Art. 28 DSGVO

Art. 28 Abs. 3 DSGVO listet die Pflichtinhalte. In der Praxis ergeben sich daraus elf Punkte, die jeder seriöse AVV abdecken muss. Wenn auch nur einer fehlt, ist der AVV formal angreifbar.

1. Gegenstand und Dauer der Verarbeitung. Was wird verarbeitet, wie lange, und für welchen Zweck. Beim Help Center typischerweise: Hosting von Hilfeartikeln, Zugriffsprotokolle, ggf. Nutzeranalysen. Dauer entspricht meist der Vertragslaufzeit plus Übergangsfristen.
2. Art und Zweck der Verarbeitung. Bereitstellung, Speicherung, Backup, Analyse, ggf. Anreicherung durch KI-Modelle. Wenn der Vendor KI-Funktionen anbietet, muss das hier explizit stehen.
3. Art der personenbezogenen Daten. Konkret welche Daten betroffen sind. Typischerweise IP-Adressen der Leser, Sitzungs-IDs, Mitarbeiter-Logins, ggf. E-Mail-Adressen bei Kommentaren.
4. Kategorien betroffener Personen. Mitarbeitende des Verantwortlichen, Endkunden des Verantwortlichen, ggf. Subunternehmer.
5. Rechte und Pflichten des Verantwortlichen. Weisungsrecht, Kontrollrechte, Pflicht zur Bereitstellung von Weisungen.
6. Weisungsbindung. Der Auftragsverarbeiter darf die Daten ausschliesslich nach dokumentierten Weisungen des Verantwortlichen verarbeiten. Eine Klausel, die dem Vendor erlaubt, Daten für eigene Zwecke wie Produktverbesserung oder KI-Training zu nutzen, ist hier oft versteckt. Genau hinschauen.
7. Vertraulichkeitsverpflichtung der Mitarbeitenden. Alle beim Vendor beschäftigten Personen, die Zugriff haben, müssen schriftlich zur Vertraulichkeit verpflichtet sein.
8. Technische und organisatorische Massnahmen (TOM). Beschreibung der Sicherheitsmassnahmen nach Art. 32 DSGVO. Verschlüsselung, Zugangskontrolle, Pseudonymisierung, Backup, Wiederherstellung. Oft als Anlage zum AVV.
9. Regelung zu Sub-Auftragsverarbeitern. Wer wird vom Vendor als Sub-Prozessor eingesetzt (Hosting bei AWS, Logging bei Datadog, etc.) und wie wird der Verantwortliche über Änderungen informiert. Mehr dazu im nächsten Abschnitt.
10. Unterstützungspflichten. Der Vendor unterstützt den Verantwortlichen bei Anfragen Betroffener (Auskunft, Löschung, Übertragbarkeit), bei Datenschutz-Folgenabschätzungen, und bei Meldungen von Datenpannen.
11. Beendigungsregelung. Was passiert mit den Daten am Ende des Vertrags. Rückgabe, Löschung, Bestätigung der Löschung. Üblich: Daten werden binnen 30 bis 90 Tagen gelöscht, der Vendor stellt eine schriftliche Löschbestätigung aus.

Wenn dein Vendor einen AVV anbietet, der kürzer als zwei Seiten ist, fehlt etwas. Wenn er zehn Seiten lang ist und Punkte aus dieser Liste auslässt, ist das ein Gespräch wert.

Sub-Prozessoren: das oft übersehene Detail

Sub-Auftragsverarbeiter sind Drittunternehmen, die der Vendor selbst beauftragt, um seinen Service zu betreiben. Bei einem typischen KB-Anbieter sind das vier bis zehn Sub-Prozessoren. Eine Auswahl, die regelmässig auftaucht:

• Hosting-Infrastruktur. AWS, Google Cloud, Microsoft Azure, Hetzner, OVHcloud. Verarbeitet alle Inhaltsdaten und Logs.
• CDN und DDoS-Schutz. Cloudflare, Fastly, Akamai. Verarbeitet IP-Adressen der Leser.
• E-Mail-Versand. SendGrid, Postmark, Mailgun. Verarbeitet E-Mail-Adressen für Notifications.
• Logging und Monitoring. Datadog, New Relic, Sentry. Verarbeitet ggf. Nutzerverhalten und Fehlerprotokolle.
• Analytics. Mixpanel, Amplitude, Heap. Verarbeitet Nutzerverhalten.
• Support- und CRM-Tools. Intercom, Zendesk, Salesforce. Verarbeitet Kundenkontakte für den Vendor-Support.
• KI-Modelle. OpenAI, Anthropic, Google Vertex AI, eigene Modelle. Verarbeitet Inhaltsdaten, wenn KI-Suche oder KI-Antworten aktiv sind.

Art. 28 Abs. 2 DSGVO verlangt, dass der Verantwortliche jedem Sub-Prozessor vorher schriftlich zustimmt. In der Praxis erfolgt das meist über eine generelle Vorab-Zustimmung im AVV, kombiniert mit einer Informations- und Widerspruchspflicht des Vendors bei neuen Sub-Prozessoren. Üblich sind 30 Tage Widerspruchsfrist.

Drei Fragen, die du der Sub-Prozessoren-Liste stellen solltest:

• Ist die Liste öffentlich einsehbar? Seriöse Vendoren publizieren sie auf einer permanenten Seite (z.B. vendor.com/subprocessors) mit Datum der letzten Aktualisierung. Wer keine öffentliche Liste hat, muss sie auf Anfrage liefern. Wer mauert, ist nicht audit-fähig.
• Stehen Drittland-Anbieter mit drauf? AWS, Google, Microsoft, Cloudflare sind US-Konzerne, auch wenn sie EU-Regionen anbieten. Das ist nicht per se ein Problem (siehe nächster Abschnitt), aber es muss benannt sein.
• Werden KI-Anbieter offengelegt? Wenn der Vendor KI-Suche oder KI-Antworten anbietet, muss der zugrundeliegende Modellanbieter (OpenAI, Anthropic, etc.) in der Sub-Prozessoren-Liste stehen. Ein KB-Vendor, der "KI" verkauft, aber keinen KI-Sub-Prozessor benennt, betreibt entweder Eigenentwicklung (selten und erklärungsbedürftig) oder verschweigt etwas.

Schrems II und der EU-US Data Privacy Framework

Im Juli 2020 hat der Europäische Gerichtshof im Urteil "Schrems II" (Rechtssache C-311/18) das EU-US Privacy Shield für ungültig erklärt. Begründung: Die US-Überwachungsgesetze (FISA 702, Executive Order 12333) erlaubten US-Behörden einen Zugriff auf Daten europäischer Bürger, der nicht mit der DSGVO vereinbar war. Drei Jahre lang stand der transatlantische Datentransfer rechtlich auf wackligem Boden. Unternehmen mussten Standardvertragsklauseln (Standard Contractual Clauses, SCCs) plus zusätzliche Schutzmassnahmen abschliessen, was in der Praxis einen erheblichen Compliance-Aufwand bedeutete.

Am 10. Juli 2023 hat die EU-Kommission den EU-US Data Privacy Framework (DPF) als neue Adequacy Decision verabschiedet. Das DPF ersetzt das alte Privacy Shield und stellt fest, dass US-Unternehmen, die sich beim US-Handelsministerium für das DPF zertifizieren, ein angemessenes Schutzniveau im Sinne der DSGVO bieten. Für Datentransfers in die USA an DPF-zertifizierte Unternehmen reichen seit Juli 2023 keine zusätzlichen Schutzmassnahmen mehr aus, sofern das DPF eingehalten wird.

Praktisch heisst das:

• DPF-zertifizierter US-Anbieter: Datentransfer in die USA rechtlich tragfähig. Du brauchst einen AVV, der den DPF referenziert. SCCs sind nicht zwingend, aber viele Anbieter unterzeichnen sie zusätzlich als Backup, falls das DPF kippen sollte.
• Nicht-DPF-zertifizierter US-Anbieter: Du brauchst SCCs plus eine dokumentierte Transfer Impact Assessment (TIA). Aufwand höher, Restrisiko bleibt.
• EU-Anbieter mit EU-Hosting: Kein Drittlandtransfer, keine SCCs nötig. Einfachster Compliance-Pfad.

Wichtig: Das DPF kann politisch kippen. Schon das alte Privacy Shield wurde nach vier Jahren vom EuGH gekippt, das vorhergehende Safe Harbor nach 15 Jahren. Es gibt seit 2023 mehrere Klagen gegen das DPF beim EuGH (u.a. von Max Schrems' Organisation noyb). Wer heute auf das DPF baut, sollte einen Plan B in der Schublade haben, der typischerweise EU-Hosting oder einen Vendor-Wechsel umfasst.

KB-Anbieter und ihre AVV-Praxis (Stand 2026-05-23)

Die folgende Übersicht zeigt elf KB-Anbieter, die im DACH-Markt häufig in der Buying-Shortlist auftauchen. Die Angaben basieren auf öffentlich verfügbaren DPA- und Sub-Prozessoren-Seiten, verifiziert am 23. Mai 2026. Da Vendoren ihre Compliance-Programme regelmässig anpassen, prüfe vor dem Vertragsabschluss die aktuelle Vendor-Dokumentation.

Lies das Spaltenbild nicht binär. Ein "Ja" bei AVV-Verfügbarkeit heisst nicht, dass der AVV automatisch sauber ist. Es heisst, dass der Vendor einen anbietet. Die inhaltliche Prüfung gehört trotzdem auf den Tisch deines Datenschutzbeauftragten.

Praxis-Checkliste für den DACH-Buyer

Wenn du gerade einen KB-Vendor evaluierst, arbeite diese zehn Punkte ab, bevor du unterschreibst. Die Liste deckt 90 Prozent der Audit-Risiken ab, die in der Praxis hochkommen.

1. AVV anfordern, bevor der POC startet. Nicht erst beim Procurement. Wer im POC schon echte Daten testet, braucht den AVV ab Tag 1.
2. 11-Punkte-Check durchführen. Liste oben durchgehen, jeden Punkt im AVV finden. Was fehlt, ist verhandelbar oder ein Deal-Breaker.
3. Sub-Prozessoren-Liste prüfen. Öffentlich? Mit Datum? Drittland-Anbieter benannt? KI-Anbieter benannt, wenn KI-Features im Tarif sind?
4. Hosting-Region klären. Wo liegen die Daten physikalisch? Ist das im AVV oder einem Anhang fixiert oder ändert sich das je nach Vendor-Laune?
5. Drittlandtransfer dokumentieren. Wenn Daten ausserhalb der EU verarbeitet werden, welche Rechtsgrundlage gilt? DPF, SCCs, Adequacy Decision für UK oder Schweiz?
6. Weisungsbindung explizit prüfen. Steht im AVV, dass der Vendor Daten nicht für eigene Zwecke nutzen darf? Achtung bei "Service Improvement", "Product Analytics", "AI Training". Diese Klauseln sind oft als legitimes Interesse getarnte Mitnutzung.
7. Löschpflicht am Vertragsende festlegen. Frist (typisch 30 bis 90 Tage), Löschbestätigung (typisch schriftlich), Backup-Behandlung (Backups dürfen länger leben, aber müssen mit Löschvermerk versehen sein).
8. Audit-Recht abklären. Hast du als Verantwortlicher das Recht, beim Vendor zu auditieren oder Audit-Reports einzusehen (z.B. SOC 2, ISO 27001)? Direkter Audit-Zugang ist bei großen Vendoren selten, Audit-Reports einsehen ist Standard.
9. Datenschutz-Folgenabschätzung (DSFA) bewerten. Wenn dein Use Case eine DSFA nach Art. 35 DSGVO erfordert (z.B. Mitarbeitermonitoring, automatisierte Entscheidungen), unterstützt der Vendor dich dabei? Steht das im AVV?
10. Datenschutzbeauftragten einbinden. Vor Unterschrift. Nicht danach. Ein interner oder externer Datenschutzbeauftragter erkennt Klauselrisiken, die dem Procurement-Team entgehen.

Häufige Fehler beim AVV-Review

Aus über 100 ausgewerteten Buying-Cycles im DACH-SaaS-Markt wiederholen sich fünf Fehler, die später teuer werden.

Fehler 1: AVV erst beim Vertragsschluss anfordern. Sobald im POC echte Daten getestet werden, ist Datenverarbeitung im Gang. Ohne AVV ist diese Datenverarbeitung formal rechtswidrig. Manche Vendoren liefern AVV erst beim bezahlten Vertrag. Das ist ein Prozessfehler, den du als Buyer durchsetzen musst: AVV vor POC oder kein POC.

Fehler 2: AVV-Template des Vendors blind unterschreiben. Vendor-AVVs sind oft so geschrieben, dass sie dem Vendor maximale Flexibilität geben. Klauseln wie "der Auftragsverarbeiter darf aggregierte Daten zur Service-Verbesserung nutzen" sind Verhandlungsmasse, kein Naturgesetz. Bei kleineren Vendoren ist Anpassung oft möglich, bei großen US-Anbietern selten. Aber gefragt werden sollte immer.

Fehler 3: Sub-Prozessoren ignorieren. Der AVV ist sauber, aber die Sub-Prozessoren-Liste enthält fünf Unternehmen, von denen du noch nie gehört hast und die in Indien sitzen. Wenn du das im Audit nicht erklären kannst, wirst du es im Bussgeldverfahren auch nicht erklären können. Sub-Prozessoren sind keine Fussnote, sie sind die echte Datenverarbeitungs-Realität.

Fehler 4: DPF als Garantie ansehen. Das DPF ist seit Juli 2023 in Kraft, aber rechtlich angefochten. Wer heute ausschliesslich auf das DPF setzt und keine Backup-Strategie hat, riskiert beim nächsten EuGH-Urteil einen Compliance-Notstand. Plan B: EU-Hosting-Option beim Vendor schon vertraglich verankern, oder einen Migrations-Pfad in der Schublade haben.

Fehler 5: KI-Funktionen vergessen. Ein KB-Vendor schaltet 2025 oder 2026 KI-Suche oder KI-Antworten dazu, oft als kostenloses Upgrade. Die Inhaltsdaten gehen plötzlich durch OpenAI, Anthropic oder ein anderes Modell. Ist das im AVV abgedeckt? Steht der KI-Anbieter in der Sub-Prozessoren-Liste? Wurdest du als Verantwortlicher vorher informiert? Wenn nein, hast du ein Compliance-Problem, das nicht du verursacht hast, aber jetzt lösen musst.

HappySupport im Kontext

HappySupport ist als deutsches Unternehmen mit Sitz in Frankfurt aufgebaut und betreibt seine Cloud-Infrastruktur in der EU. Konkret heisst das: Der AVV ist auf Deutsch verfügbar und referenziert Art. 28 DSGVO direkt. Die Inhaltsdaten unserer Kunden liegen physikalisch in Frankfurt. Keine US-Datenübertragung im Standardbetrieb, also auch keine Abhängigkeit vom EU-US Data Privacy Framework, die später kippen könnte.

Die Sub-Prozessoren-Liste ist öffentlich, mit Datum, und enthält alle relevanten Drittunternehmen, die im Service-Betrieb verarbeiten. Wenn wir Sub-Prozessoren ändern, informieren wir betroffene Kunden mit 30 Tagen Vorlauf und bieten ein Widerspruchsrecht an. Wir nutzen Kundendaten nicht für KI-Modell-Training, weder eigene noch fremde Modelle.

Das ist keine Audit-Garantie für deinen konkreten Fall. Jeder DSGVO-Audit hängt von deinen eigenen Verarbeitungstätigkeiten und deinem Branchenkontext ab. Aber es ist eine Ausgangslage, die deinem Datenschutzbeauftragten kein Kopfzerbrechen bereitet, weil die Standardfragen (AVV, Hosting, Sub-Prozessoren, Drittlandtransfer) ohne Klimmzüge beantwortbar sind.

Wenn du tiefer eintauchen willst: DSGVO-Wissensdatenbank: Die fünf Pflichten behandelt das Gesamtbild jenseits des AVV, Wissensdatenbank für Unternehmen ordnet die Compliance-Anforderungen in den breiteren Tool-Auswahl-Kontext ein, und KI-Wissensdatenbank-Software erklärt, was sich aus DSGVO-Sicht ändert, sobald KI-Features im Spiel sind.