Auftragsverarbeitungsvertrag (AVV)

gemäß Art. 28 DSGVO

Version: 1.0

---

Zwischen

dem registrierten Geschäftskunden, dessen Identität (Firmenname, Anschrift, Land) sich aus den bei Vertragsschluss im DialogHub-Konto hinterlegten Angaben sowie aus dem elektronischen Zustimmungsprotokoll (Zeitpunkt, akzeptierte Vertragsversion) ergibt

— nachfolgend „Verantwortlicher“ —

und

Denys Mierkulov (Einzelunternehmen), handelnd unter der Geschäftsbezeichnung „DialogHub“
Ahornallee 4
31195 Lamspringe
Deutschland
E-Mail: [email protected]

— nachfolgend „Auftragsverarbeiter“ —

— Verantwortlicher und Auftragsverarbeiter einzeln auch „Partei“, gemeinsam „Parteien“ —

---

Präambel

Der Auftragsverarbeiter erbringt für den Verantwortlichen Leistungen im Rahmen der Plattform DialogHub (KI-gestützter Assistent für Websites, Lead-Erfassung, Multikanal-Kommunikation und optionale Terminbuchung). Bei der Erbringung dieser Leistungen verarbeitet der Auftragsverarbeiter personenbezogene Daten im Auftrag und nach Weisung des Verantwortlichen. Dieser Vertrag konkretisiert die datenschutzrechtlichen Verpflichtungen der Parteien gemäß Art. 28 DSGVO. Er ist Bestandteil des zugrunde liegenden Hauptvertrages (Nutzungs-/Abonnementvertrag, nachfolgend „Hauptvertrag“).

---

§ 1 Gegenstand, Art und Zweck der Verarbeitung

1. Gegenstand, Art und Zweck der Verarbeitung, die Art der personenbezogenen Daten sowie die Kategorien betroffener Personen ergeben sich abschließend aus Anlage 1 (Verarbeitungsbeschreibung) zu diesem Vertrag.
2. Die Verarbeitung erfolgt ausschließlich zur Erfüllung des Hauptvertrages und im Rahmen der dokumentierten Weisungen des Verantwortlichen.
3. Eine Verarbeitung der Daten zu eigenen Zwecken des Auftragsverarbeiters findet nicht statt, soweit dieser Vertrag nichts anderes bestimmt.

§ 2 Dauer

Dieser Vertrag beginnt mit dem Vertragsschluss (siehe Abschnitt „Vertragsschluss durch elektronische Zustimmung“) und gilt für die Laufzeit des Hauptvertrages. Er endet automatisch mit dessen Beendigung. Die Pflichten zur Löschung bzw. Rückgabe der Daten (§ 11) sowie die fortwirkenden Geheimhaltungs- und Nachweispflichten bestehen über das Vertragsende hinaus fort.

§ 3 Weisungsrecht des Verantwortlichen

1. Der Auftragsverarbeiter verarbeitet die personenbezogenen Daten ausschließlich auf dokumentierte Weisung des Verantwortlichen, einschließlich in Bezug auf die Übermittlung in Drittländer, es sei denn, er ist hierzu nach Unionsrecht oder dem Recht eines Mitgliedstaats verpflichtet (Art. 28 Abs. 3 lit. a DSGVO).
2. Weisungen werden grundsätzlich durch die Konfiguration der Plattform und die Vereinbarungen des Hauptvertrages erteilt. Ergänzende oder abweichende Weisungen erfolgen in Textform an [email protected].
3. Der Auftragsverarbeiter informiert den Verantwortlichen unverzüglich, wenn er der Auffassung ist, dass eine Weisung gegen die DSGVO oder andere Datenschutzbestimmungen verstößt (Art. 28 Abs. 3 Satz 2 DSGVO).

§ 4 Pflichten des Auftragsverarbeiters

Der Auftragsverarbeiter verpflichtet sich insbesondere:

1. Vertraulichkeit (Art. 28 Abs. 3 lit. b, Art. 29, Art. 32 Abs. 4 DSGVO): sicherzustellen, dass sich die zur Verarbeitung befugten Personen zur Vertraulichkeit verpflichtet haben oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen.
2. Sicherheit der Verarbeitung (Art. 32 DSGVO): die in Anlage 2 (TOM) beschriebenen technischen und organisatorischen Maßnahmen zu treffen und während der Vertragslaufzeit aufrechtzuerhalten. Die beschriebenen Maßnahmen bilden das Mindestschutzniveau; sie können fortentwickelt werden, sofern dieses Niveau nicht unterschritten wird. Eine Fortentwicklung, die das Schutzniveau anhebt, bedarf keiner neuen Vertragsfassung — Art. 32 DSGVO verpflichtet den Auftragsverarbeiter, den Stand der Technik fortlaufend zu berücksichtigen. Der Auftragsverarbeiter schuldet mindestens das in Anlage 2 beschriebene Schutzniveau; die dortige Darstellung einzelner Maßnahmen ist dessen Beschreibung und nicht dessen abschließende Aufzählung. Nimmt der Auftragsverarbeiter später weitere Maßnahmen in Anlage 2 auf, so erweitert dies den geschuldeten Mindeststandard nur für die Zukunft und nur, soweit die Aufnahme sie ausdrücklich als getroffene Maßnahme ausweist. Angaben, die Anlage 2 als Bewertung eines Restrisikos oder als vorgesehene künftige Maßnahme kennzeichnet, sind nicht Teil des geschuldeten Mindeststandards.
3. Unterauftragsverarbeiter: die Bedingungen des § 7 für die Inanspruchnahme weiterer Auftragsverarbeiter einzuhalten.
4. Unterstützung des Verantwortlichen (Art. 28 Abs. 3 lit. e, f DSGVO): den Verantwortlichen mit geeigneten technischen und organisatorischen Maßnahmen nach Möglichkeit bei der Erfüllung seiner Pflichten zu unterstützen — namentlich bei der Beantwortung von Anträgen betroffener Personen (§ 8) sowie bei der Gewährleistung der Pflichten aus Art. 32 bis 36 DSGVO (§§ 9, 10).
5. Löschung/Rückgabe (Art. 28 Abs. 3 lit. g DSGVO): nach Abschluss der Verarbeitung gemäß § 11 zu verfahren.
6. Nachweise/Audits (Art. 28 Abs. 3 lit. h DSGVO): dem Verantwortlichen alle erforderlichen Informationen zum Nachweis der Einhaltung der Pflichten aus Art. 28 DSGVO zur Verfügung zu stellen und Überprüfungen gemäß § 12 zu ermöglichen.
7. Verzeichnis (Art. 30 Abs. 2 DSGVO): ein Verzeichnis aller im Auftrag des Verantwortlichen durchgeführten Kategorien von Verarbeitungstätigkeiten zu führen.
8. Datenschutzkontakt: dem Verantwortlichen die Kontaktdaten der für den Datenschutz zuständigen Stelle des Auftragsverarbeiters mitzuteilen: Denys Mierkulov, [email protected]. Ein Datenschutzbeauftragter ist nicht benannt; der Auftragsverarbeiter beschäftigt in der Regel weniger als 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten (§ 38 Abs. 1 Satz 1 BDSG).

§ 5 Ort der Verarbeitung

1. Die Verarbeitung der personenbezogenen Daten findet grundsätzlich innerhalb der Europäischen Union bzw. des Europäischen Wirtschaftsraums statt. Die Kerninfrastruktur (Anwendung, selbst gehosteter Automatisierungsdienst n8n, Datenbank, KI-Speicher) wird in Deutschland (Frankfurt am Main) betrieben (OVHcloud-VPS, Region os-de2; Datenbank Neon, AWS-Region eu-central-1/Frankfurt).
2. Soweit einzelne Unterauftragsverarbeiter ihren Sitz außerhalb der EU/des EWR haben (siehe Anlage 3), erfolgt die Übermittlung auf Grundlage geeigneter Garantien gemäß Kapitel V DSGVO (insbesondere EU-Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO und, soweit erforderlich, ergänzender Maßnahmen).

§ 6 Mitteilungspflichten

Der Auftragsverarbeiter informiert den Verantwortlichen unverzüglich, wenn er feststellt, dass

1. eine Verletzung des Schutzes personenbezogener Daten vorliegt (siehe § 9),
2. eine Kontrolle oder Maßnahme einer Aufsichtsbehörde gemäß Art. 58 DSGVO erfolgt, soweit sie sich auf die Auftragsverarbeitung bezieht, oder
3. die ihm erteilten Weisungen aus seiner Sicht datenschutzrechtlich unzulässig sind.

§ 7 Unterauftragsverarbeiter (Sub-Prozessoren)

1. Der Verantwortliche erteilt dem Auftragsverarbeiter die allgemeine Genehmigung zur Hinzuziehung weiterer Auftragsverarbeiter (Art. 28 Abs. 2 Satz 1 DSGVO). Die zum Zeitpunkt des Vertragsschlusses eingesetzten Unterauftragsverarbeiter sind in Anlage 3 (Sub-Prozessoren-Liste) aufgeführt und gelten als genehmigt.
2. Der Auftragsverarbeiter informiert den Verantwortlichen über jede beabsichtigte Änderung in Bezug auf die Hinzuziehung oder Ersetzung von Unterauftragsverarbeitern in Textform (§ 126b BGB); die Mitteilung an die im DialogHub-Konto hinterlegte E-Mail-Adresse des Verantwortlichen genügt. Der Verantwortliche kann der Änderung aus datenschutzrechtlichen Gründen innerhalb von 30 Tagen ab Zugang der Mitteilung widersprechen (Art. 28 Abs. 2 Satz 2 DSGVO). Der Widerspruch bedarf der Textform und ist an [email protected] zu richten; er soll den datenschutzrechtlichen Grund benennen. Widerspricht der Verantwortliche nicht innerhalb dieser Frist, gilt die Änderung als genehmigt; auf diese Wirkung weist der Auftragsverarbeiter in der Mitteilung ausdrücklich hin.
3. Der Auftragsverarbeiter setzt die Änderung nicht vor Ablauf der Frist nach Absatz 2 um, es sei denn, der Verantwortliche hat der Änderung zugestimmt. Abweichend hiervon darf er einen Unterauftragsverarbeiter bereits vor Ablauf dieser Frist hinzuziehen oder ersetzen, wenn dies erforderlich ist, um eine erhebliche Beeinträchtigung der Sicherheit oder der Verfügbarkeit der Leistung abzuwenden, oder weil der bisherige Unterauftragsverarbeiter die Leistung einstellt. In diesem Fall unterrichtet der Auftragsverarbeiter den Verantwortlichen unverzüglich, spätestens innerhalb von drei Werktagen nach der Umsetzung, in Textform (§ 126b BGB); das Widerspruchsrecht nach Absatz 2 und das Kündigungsrecht nach Absatz 4 bleiben unberührt, die Fristen laufen ab Zugang dieser Unterrichtung.
4. Widerspricht der Verantwortliche fristgerecht nach Absatz 2, so teilt ihm der Auftragsverarbeiter innerhalb von 14 Tagen ab Zugang des Widerspruchs in Textform (§ 126b BGB) mit, ob er an der Änderung festhält; unterbleibt diese Mitteilung, so gilt sie mit Ablauf dieser Frist als dahingehend erteilt, dass der Auftragsverarbeiter an der Änderung festhält. Nimmt der Auftragsverarbeiter von der Änderung Abstand, so besteht kein Kündigungsrecht nach diesem Absatz. Hält er an der Änderung fest, so kann der Verantwortliche die von der Änderung betroffene Leistung innerhalb von 14 Tagen ab Zugang dieser Mitteilung oder ab Ablauf der Frist nach Satz 1 in Textform (§ 126b BGB) kündigen. Die Kündigung wird zu dem Zeitpunkt wirksam, zu dem der Unterauftragsverarbeiter die Verarbeitung aufnimmt, frühestens jedoch mit Zugang der Kündigung; hat der Unterauftragsverarbeiter die Verarbeitung bereits aufgenommen, so wird die Kündigung mit ihrem Zugang wirksam. Den Zeitpunkt der Aufnahme teilt der Auftragsverarbeiter in der Mitteilung nach Satz 1 mit, soweit er zu diesem Zeitpunkt bereits feststeht; andernfalls unverzüglich nach seiner Festlegung, spätestens mit der Aufnahme der Verarbeitung. Das Kündigungsrecht ist auf die betroffene Leistung beschränkt; kann der Auftragsverarbeiter die Leistung ohne den betroffenen Unterauftragsverarbeiter insgesamt nicht erbringen, so erstreckt es sich auf das Abonnement insgesamt. Im Voraus gezahlte Entgelte für den nach Wirksamwerden der Kündigung nicht mehr genutzten Zeitraum erstattet der Auftragsverarbeiter zeitanteilig. Sonstige ordentliche und außerordentliche Kündigungsrechte bleiben unberührt.
5. Der Auftragsverarbeiter erlegt jedem Unterauftragsverarbeiter durch Vertrag dieselben Datenschutzpflichten auf, wie sie in diesem Vertrag festgelegt sind (Art. 28 Abs. 4 DSGVO). Kommt der Unterauftragsverarbeiter seinen Datenschutzpflichten nicht nach, haftet der Auftragsverarbeiter gegenüber dem Verantwortlichen für die Einhaltung der Pflichten.
6. Nicht als Unterauftragsverarbeitung im Sinne dieses Vertrages gelten Nebenleistungen, die der Auftragsverarbeiter als reine Hilfstätigkeit in Anspruch nimmt (z. B. Telekommunikations- oder Wartungsleistungen ohne konkreten Bezug zu den im Auftrag verarbeiteten Daten).

§ 8 Unterstützung bei Betroffenenrechten

1. Wendet sich eine betroffene Person mit Ansprüchen auf Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit oder Widerspruch (Art. 15–21 DSGVO) unmittelbar an den Auftragsverarbeiter, leitet dieser das Ersuchen unverzüglich an den Verantwortlichen weiter und beantwortet es nicht selbst, sofern keine entsprechende Weisung vorliegt.
2. Der Auftragsverarbeiter unterstützt den Verantwortlichen im Rahmen seiner technischen Möglichkeiten bei der Erfüllung dieser Ansprüche — unter anderem durch Export- und Löschfunktionen der Plattform (siehe Anlage 2, Abschnitt „Betroffenenrechte / Löschung“).

§ 9 Verletzung des Schutzes personenbezogener Daten

1. Der Auftragsverarbeiter benachrichtigt den Verantwortlichen unverzüglich, nachdem ihm eine Verletzung des Schutzes personenbezogener Daten im Sinne des Art. 4 Nr. 12 DSGVO bekannt geworden ist, die im Rahmen der Auftragsverarbeitung eingetreten ist (Art. 33 Abs. 2 DSGVO).
2. Die Benachrichtigung enthält mindestens die nach Art. 33 Abs. 3 DSGVO erforderlichen Angaben, soweit diese dem Auftragsverarbeiter vorliegen (Art und Umfang der Verletzung, betroffene Datenkategorien, voraussichtliche Folgen, ergriffene/vorgeschlagene Maßnahmen).
3. Der Auftragsverarbeiter unterstützt den Verantwortlichen bei dessen Melde- und Benachrichtigungspflichten gemäß Art. 33, 34 DSGVO.

§ 10 Datenschutz-Folgenabschätzung

Soweit erforderlich, unterstützt der Auftragsverarbeiter den Verantwortlichen bei der Durchführung einer Datenschutz-Folgenabschätzung (Art. 35 DSGVO) und einer etwaigen vorherigen Konsultation der Aufsichtsbehörde (Art. 36 DSGVO), unter Berücksichtigung der ihm vorliegenden Informationen.

§ 11 Löschung und Rückgabe nach Vertragsende

1. Nach Beendigung der Verarbeitung löscht der Auftragsverarbeiter nach Wahl des Verantwortlichen alle personenbezogenen Daten oder gibt sie zurück und löscht vorhandene Kopien, sofern keine gesetzliche Aufbewahrungspflicht besteht (Art. 28 Abs. 3 lit. g DSGVO).
2. Der Verantwortliche kann die Löschung bzw. den Export während der Vertragslaufzeit und nach Vertragsende über die Selbstbedienungsfunktionen der Plattform sowie durch Textform-Anfrage an [email protected] veranlassen.
3. Daten, die gesetzlichen Aufbewahrungspflichten unterliegen (z. B. steuerliche Unterlagen), werden bis zum Ablauf der jeweiligen Frist eingeschränkt verarbeitet und anschließend gelöscht.

§ 12 Nachweise und Überprüfungen

1. Der Auftragsverarbeiter stellt dem Verantwortlichen auf Anfrage die zum Nachweis der Einhaltung dieses Vertrages erforderlichen Informationen zur Verfügung (Art. 28 Abs. 3 lit. h DSGVO), insbesondere die jeweils aktuelle Fassung der Anlage 2 (TOM) und der Anlage 3 (Sub-Prozessoren-Liste). Soweit eine Anlage Bestandteil des vom Verantwortlichen angenommenen Vertragstextes ist, tritt die Bereitstellung nach Satz 1 neben die angenommene Fassung und ersetzt sie nicht; die angenommene Fassung bleibt nach dem Abschnitt „Vertragsschluss durch elektronische Zustimmung“ abrufbar.
2. Überprüfungen erfolgen vorrangig durch Vorlage geeigneter Nachweise (z. B. Selbstauskünfte, Test-/Prüfberichte, Zertifikate, soweit vorhanden). Vor-Ort-Kontrollen sind nur nach angemessener Vorankündigung, während der üblichen Geschäftszeiten und ohne Störung des Betriebsablaufs zulässig.

§ 13 Haftung

1. Die Haftung nach Art. 82 DSGVO richtet sich ausschließlich nach dieser Vorschrift. Regelungen des Hauptvertrages schränken sie weder der Höhe noch dem Grunde nach ein.
2. Für die Haftung im Übrigen gelten die Regelungen des Hauptvertrages (Allgemeine Geschäftsbedingungen des Auftragsverarbeiters) in ihrer bei Vertragsschluss geltenden Fassung. Unberührt bleiben in jedem Fall die Haftung für Vorsatz und grobe Fahrlässigkeit, die Haftung für die Verletzung des Lebens, des Körpers oder der Gesundheit sowie die Haftung nach dem Produkthaftungsgesetz.
3. Der Vorrang dieses Vertrages in datenschutzrechtlichen Fragen nach § 14 Abs. 1 bleibt unberührt.

§ 14 Schlussbestimmungen

1. Bei Widersprüchen zwischen diesem Vertrag und dem Hauptvertrag gehen in Bezug auf den Datenschutz die Regelungen dieses Vertrages vor.
2. Änderungen und Ergänzungen bedürfen der Textform. Dies gilt auch für die Abbedingung dieses Formerfordernisses.
3. Sollte eine Bestimmung dieses Vertrages unwirksam sein, bleibt die Wirksamkeit der übrigen Bestimmungen unberührt.
4. Es gilt das Recht der Bundesrepublik Deutschland.

---

Anlagen

• Anlage 1 — Verarbeitungsbeschreibung: Bestandteil dieses Vertrages, nachstehend abgedruckt.
• Anlage 2 — Technische und organisatorische Maßnahmen (TOM): Bestandteil dieses Vertrages, nachstehend abgedruckt. Maßgeblich für den Umfang der Pflichten des Auftragsverarbeiters ist § 4 Abs. 2 Nr. 2 dieses Vertrages; die jeweils aktuelle Fassung wird nach § 12 Abs. 1 zusätzlich zur Verfügung gestellt.
• Anlage 3 — Sub-Prozessoren-Liste: öffentlich abrufbar unter https://dialoghub.cloud/subprozessoren in der jeweils gültigen Fassung. Änderungen richten sich nach § 7 Abs. 2; die Liste wird deshalb bewusst nicht als feste Fassung in diesen Vertrag einbezogen — andernfalls liefe das dort geregelte Widerspruchsrecht leer.

---

Vertragsschluss durch elektronische Zustimmung

Dieser Auftragsverarbeitungsvertrag wird gemäß Art. 28 Abs. 9 DSGVO in elektronischem Format geschlossen. Er kommt durch die aktive elektronische Zustimmung des Verantwortlichen im Rahmen der Registrierung bzw. der Nutzung des DialogHub-Dienstes zustande (Bestätigung „Ich stimme dem Auftragsverarbeitungsvertrag zu“). Eine handschriftliche Unterschrift ist nach Art. 28 Abs. 9 DSGVO nicht erforderlich.

Zeitpunkt der Zustimmung, die zustimmende Vertragspartei und die akzeptierte Vertragsversion werden vom Auftragsverarbeiter in einem Zustimmungsprotokoll dauerhaft und nachweisbar dokumentiert (Art. 5 Abs. 2 DSGVO). Der Verantwortliche kann die jeweils aktuelle sowie die von ihm akzeptierte Fassung dieses Vertrages jederzeit im DialogHub-Konto einsehen und als PDF herunterladen.

---

Anlage 1 — Verarbeitungsbeschreibung

Anlage zum Auftragsverarbeitungsvertrag (AVV)

1. Gegenstand der Verarbeitung

Betrieb der DialogHub-Plattform für den Verantwortlichen: KI-gestützte Beantwortung von Besucheranfragen aus den Inhalten des Verantwortlichen, Lead-Erfassung und -Bewertung, Multikanal-Kommunikation (Website-Widget, Telegram, E-Mail, WhatsApp, Instagram — je nach gebuchtem Umfang; im Website-Widget zusätzlich die zubuchbare Spracheingabe) sowie optionale Terminbuchung über vom Verantwortlichen aktivierte Buchungsanbieter.

2. Art und Zweck der Verarbeitung

3. Art der personenbezogenen Daten

• Kontakt- und Identifikationsdaten von Website-Besuchern/Interessenten (z. B. Name, E-Mail-Adresse, Telefonnummer, soweit angegeben)
• Inhaltsdaten der Konversationen (Nachrichten, Anfragen)
• Termin-/Buchungsdaten (gewählte Leistung, Zeitfenster, Notizen)
• Technische Metadaten (IP-Adresse, Browser-/Geräteinformationen, Referrer-URL, Zeitstempel)
• Kanalbezogene Kennungen (z. B. Telegram-/Instagram-Benutzername, soweit der jeweilige Kanal aktiviert ist)

Hinweis: Die Plattform ist nicht auf die Verarbeitung besonderer Kategorien personenbezogener Daten (Art. 9 DSGVO) ausgelegt. Der Verantwortliche stellt sicher, dass solche Daten nicht ohne gesonderte Rechtsgrundlage und gesonderte Vereinbarung über die Plattform verarbeitet werden.

4. Kategorien betroffener Personen

• Website-Besucher und Interessenten des Verantwortlichen
• Kontaktpersonen/Leads des Verantwortlichen
• Nutzer der vom Verantwortlichen aktivierten Kommunikationskanäle

5. Kreis der betroffenen Personen — Umfang

Der konkrete Umfang ergibt sich aus der Nutzung der Plattform durch den Verantwortlichen und den von ihm aktivierten Funktionen und Kanälen.

---

Anlage 2 — Technische und organisatorische Maßnahmen (TOM)

Anlage zum Auftragsverarbeitungsvertrag (AVV)

gemäß Art. 32 DSGVO

Der Auftragsverarbeiter trifft die nachfolgenden technischen und organisatorischen Maßnahmen zur Gewährleistung eines dem Risiko angemessenen Schutzniveaus. Die Kerninfrastruktur (Anwendung, Automatisierungsdienst n8n, Datenbank, KI-Speicher) wird in Deutschland (Frankfurt am Main) betrieben; die Verarbeitung erfolgt innerhalb der EU/des EWR mit Ausnahme der in Anlage 3 benannten Drittland-Sub-Prozessoren.

Wahrheitsgrundsatz dieser Anlage. Es wird ausschließlich der nachweisbare Ist-Stand beschrieben. Geplante, aber noch nicht produktive Maßnahmen werden bis zu ihrer Umsetzung nicht als bestehender Schutz dargestellt. Die Angaben dieser Anlage sind entweder am laufenden Produktivsystem gemessen, als Festlegung des Betreibers oder als Bewertung gekennzeichnet; wo eine Messung, eine Festlegung oder eine Bewertung einem Stichtag zugeordnet ist, wird dieser genannt. Eine Bewertung beurteilt Reichweite und Ende eines benannten Restrisikos; sie stützt sich auf den implementierten Ablauf und begründet für sich genommen keine Schutzwirkung.

---

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

1.1 Zutrittskontrolle (physischer Zugang)

Die physische Infrastruktur wird ausschließlich bei zertifizierten Rechenzentrums- und Cloud-Anbietern betrieben; der Auftragsverarbeiter unterhält keine eigenen Rechenzentren.

• Hosting der Anwendung, des selbst gehosteten Automatisierungsdienstes (n8n) und des KI-Speichers: OVHcloud, VPS im Rechenzentrum Frankfurt (DE) (OVH-Region os-de2). Physische Sicherheit (Zutrittskontrolle, Videoüberwachung, Zonierung) obliegt dem Rechenzentrumsbetreiber. Dessen jeweils gültige Zertifizierungen (u. a. ISO/IEC 27001) weist OVHcloud öffentlich aus: https://corporate.ovhcloud.com/de/sustainability/certifications/.
• Datenbank: Neon (Betrieb in AWS-Region eu-central-1, Frankfurt). Physische Sicherheit obliegt dem Cloud-Betreiber; dessen Zertifizierungen sind unter https://aws.amazon.com/de/compliance/programs/ und die des Datenbank-Anbieters unter https://neon.com/security abrufbar.
• Der Auftragsverarbeiter benennt hier bewusst die Fundstelle und nicht ein einzelnes Zertifikat mit Datum: Gültigkeitszeiträume der Provider-Zertifikate laufen unabhängig von diesem Dokument ab, und eine hier abgeschriebene Angabe wäre nach dem ersten Re-Audit unrichtig, ohne dass es jemandem auffällt. Die verlinkten Verzeichnisse tragen den jeweils aktuellen Stand.

1.2 Zugangskontrolle (Schutz vor unbefugter Systemnutzung)

• Authentifizierung der Plattform-Nutzer über E-Mail-Verifizierungscode und signierte Sitzungs-Tokens (serverseitig signierte Session-Cookies).
• Keine dauerhafte Speicherung von Klartext-Zugangsdaten Dritter, soweit in Abschnitt 1.4 nicht ausdrücklich anders angegeben; API-Schlüssel und Zugriffstoken verbundener Dienste werden gemäß Abschnitt 1.4 gesichert.
• Administrativer Zugang zu Produktionssystemen über Provider-Konten mit Mehr-Faktor-Authentifizierung (MFA). Für die zentralen Administrationskonten (Datenbank-Anbieter, Code-Repository, Automatisierungsdienst) ist MFA mit Stand 18. Juli 2026 aktiviert und durch Anmeldeprüfung bestätigt; für das Betriebsüberwachungs-Konto zusätzlich mit Stand 28. Juli 2026.
• Der Nachweisstand ist für die übrigen Provider-Konten (Hosting, CDN/WAF, Zahlungsdienstleister, Mailversand, Sprachmodell-Konsolen) ein anderer, und das wird hier ausdrücklich benannt statt eingeebnet: dort ist MFA nach Angabe des Betreibers aktiviert, eine Anmeldeprüfung durch den Auftragsverarbeiter steht noch aus. Bestätigt heißt in diesem Dokument: an der Anmeldemaske geprüft — nicht: angenommen. Der Bestand wird in docs/OPERATIONS/MFA_ACCOUNT_INVENTORY.md je Konto mit Prüfdatum geführt.
• Für zwei der geprüften Konten bestehen keine Wiederherstellungscodes; der Zugang hängt dort am Authenticator bzw. an einer Offline-Kopie des TOTP-Seeds. Auch das ist eine Tatsache über die Zugangskontrolle und gehört benannt.
• Schutz vor automatisierten Angriffen und Missbrauch durch Web-Application-Firewall und Bot-Abwehr (Cloudflare WAF / Turnstile) sowie serverseitiges Rate-Limiting.
• Abwehr von Trial-/Anmeldemissbrauch durch eine gepflegte Sperrliste für Wegwerf-E-Mail-Domains.

1.3 Zugriffskontrolle (Schutz vor unbefugtem Datenzugriff)

• Zugriff auf personenbezogene Daten ausschließlich über die Anwendungslogik; kein direkter Endnutzer-Zugriff auf die Datenbank.
• Datenzugriff erfolgt mandantenbezogen (Beschränkung auf den jeweiligen Tenant, siehe 1.5).
• Rechtebeschränkung interner Nebenprozesse auf Datenbankebene: Der Automatisierungsdienst (n8n) greift auf die Datenbank mit einer eigenen Datenbankrolle mit minimalen Rechten zu. Diese Rolle besitzt keinen Lesezugriff auf die Kontakt- und Inhaltsdaten von Lead-Datensätzen (Name, E-Mail-Adresse, Telefonnummer, Nachrichtentext); lesbar sind ausschließlich nicht-personenbezogene Auswertungsfelder (Bewertungswert, Zeitstempel). Produktiv und durch Ausführung unter der Rolle geprüft seit 18. Juli 2026 (Migration 102).
• Grundsatz der Datenminimierung und Beschränkung des Zugriffs auf das für den jeweiligen Zweck Erforderliche.

1.4 Verschlüsselung / Pseudonymisierung

• Verschlüsselung bei der Übertragung: ausschließlich über TLS (HTTPS) für alle externen Verbindungen.
• Verschlüsselung im Ruhezustand: Die Zugangsdaten kundenseitig aktivierter Integrationen werden differenziert gesichert:
  • Buchungs-Credentials (Cal.com-API-Key; eTermin publickey + HMAC-Secret) sowie IMAP-/SMTP-Zugangsdaten des E-Mail-Kanals werden mit authentifizierter Verschlüsselung (AES-256-GCM) und mandantengebundenen zusätzlichen authentifizierten Daten (AAD = Tenant-ID) gespeichert — Manipulationserkennung und Anti-Swap.
  • OAuth-Zugangstoken des LinkedIn-Zusatzmoduls werden mit demselben Verfahren gespeichert (AES-256-GCM, AAD = Tenant-ID). Das Konto wird vom Verantwortlichen selbst unterhalten und per OAuth verbunden.
  • OAuth-Zugangstoken der Meta-Kanäle (WhatsApp, Instagram) werden mit demselben Verfahren gespeichert (AES-256-GCM, AAD = Tenant-ID). Die Kanäle sind derzeit nicht freigeschaltet; die Maßnahme ist im Code umgesetzt und greift ab der ersten Verbindung eines Kundenkontos.
  • Telegram-Bot-Token — verschlüsselt at-rest (umgesetzt, produktiv seit 25.07.2026): Der Token wird als mandantengebundenes n8n-Credential (telegramApi) im selbst gehosteten Automatisierungsdienst (n8n, EU/Frankfurt, eigene Datenbank auf dem OVHcloud-VPS) gespeichert und dort durch die n8n-eigene Credential-Verschlüsselung (N8N_ENCRYPTION_KEY) at-rest verschlüsselt. Er ist nicht mehr als Workflow-Parameter hinterlegt. Aus der Anwendungsdatenbank (Neon, Frankfurt) wird er nach erfolgreicher Einrichtung entfernt; scheitert die Einrichtung, verbliebe er dort bis zur nächsten erfolgreichen Einrichtung im Klartext. Geprüft am 25.07.2026: Für die Telegram-Kanäle von Mandanten liegt kein Klartext-Token vor — weder in der Workflow-Definition noch in der Workflow-Versionshistorie oder der Ausführungshistorie des Automatisierungsdienstes noch in der Anwendungsdatenbank.
  • Restrisiko-Bewertung zum vorgenannten Klartextverbleib (Bewertung auf Grundlage des implementierten Ablaufs, Stand 5. August 2026): Der Verbleib tritt ausschließlich dann ein, wenn die Einrichtung des Telegram-Kanals nicht vollständig gelingt — namentlich, wenn die Bot-Identität vorab nicht bestimmt werden konnte, die Einrichtung des zugehörigen Workflows einen Fehler meldet oder kein Einrichtungsergebnis vorliegt. Die Aufbewahrung ist in diesem Fall beabsichtigt: sie ist das Material des erneuten Einrichtungsversuchs; ohne sie müsste der Verantwortliche den Token erneut eingeben. Betroffen ist genau ein Wert dieses Datenbestands — der Zugangstoken des vom Verantwortlichen selbst benannten Bots — im Datensatz des betreffenden Mandanten in der Anwendungsdatenbank (Neon, Frankfurt); personenbezogene Daten von Endnutzern sind davon nicht erfasst. Der Zugriff unterliegt denselben Beschränkungen wie die übrige Anwendungsdatenbank. Die Exposition endet mit jedem der drei folgenden Vorgänge: erfolgreicher Wiederholung der Einrichtung, Deaktivierung des Telegram-Kanals oder Löschung des Mandanten. Eine Dauer wird hier bewusst nicht zugesagt, da der Eintritt des jeweiligen Vorgangs vom Handeln des Verantwortlichen abhängt. Im Missbrauchsfall erlaubte der Token das Handeln unter dem betreffenden Bot, nicht jedoch einen Zugriff auf die Anwendungsdatenbank oder auf Daten anderer Mandanten. Ergänzend gilt: Über keine der Schnittstellen, die den Einrichtungszustand mitteilen, wird der Token ausgegeben — wo dieser Zustand mitgeteilt wird, tritt an seine Stelle ein bloßes Kennzeichen seines Vorliegens; ebendieses Kennzeichen macht den Klartextverbleib anwendungsseitig feststellbar. Vorgesehen ist die technische Schließung dieses Restrisikos, indem der aufbewahrte Wert mit dem in der Anwendung bereits bestehenden Verfahren für Kanal-Geheimnisse (AES-256-GCM, AAD = Mandanten-Kennung) verschlüsselt wird; über den Vollzug wird gesondert berichtet. Über die vorstehenden Maßnahmen des Auftragsverarbeiters hinaus steht es dem Verantwortlichen frei, den Token jederzeit über den Telegram-eigenen Verwaltungsbot (BotFather) zu invalidieren; dies ist keine Maßnahme des Auftragsverarbeiters, wird hier nur der Vollständigkeit halber genannt und ist vom Auftragsverarbeiter weder geschuldet noch überwachbar.
  • Datenminimierung der Ausführungshistorie (umgesetzt): Für die token- und personenbezogenen Telegram-Workflows ist die Speicherung von Ausführungsdaten im n8n-Dienst deaktiviert (saveDataSuccessExecution = none, saveDataErrorExecution = none). Dadurch werden weder der Token noch Endnutzer-Nachrichten (Namen, Kontaktdaten, Nachrichteninhalte) in der n8n-Ausführungshistorie persistiert — Datenminimierung durch Technikgestaltung (Art. 25 DSGVO). Am 25.07.2026 im laufenden Betrieb geprüft: Für den aktiven Telegram-Kanal eines Mandanten wurden trotz verarbeiteter Nachrichten keine Ausführungsdaten im n8n-Dienst gespeichert.
• Von DialogHub ausgestellte API-Schlüssel (Public API) werden ausschließlich als SHA-256-Hash gespeichert (nach der Erstellung nie im Klartext).
• Integritäts-/Authentizitätssicherung über HMAC-Signaturen (u. a. Widget-Origin-Bindung, Signaturprüfung eingehender Webhooks).
• Keine Speicherung von Zahlungskartendaten beim Auftragsverarbeiter; die Zahlungsabwicklung erfolgt über den spezialisierten Dienstleister Stripe.

1.5 Trennungskontrolle (Mandantentrennung)

• Logische Trennung der Daten je Mandant (Tenant) anhand einer Mandanten-Kennung auf Anwendungsebene; jede datenbezogene Abfrage ist mandantenbezogen.
• Zusätzliche Schutzmechanismen für eingebettete Widgets (Origin-Bindung, Sitzungs-/Konversationsgeheimnisse).
• Datenbankseitige Mandantentrennung (Row-Level-Security) ist in Produktion aktiv. Stand der Messung 27. Juli 2026: aktiviert auf 47 von 64 Tabellen des Anwendungsschemas, abgesichert durch 137 Richtlinien. Die Anwendung verbindet sich mit einer Datenbank-Rolle ohne das Recht, diese Richtlinien zu umgehen (kein BYPASSRLS) — ohne diese Eigenschaft wäre die Aktivierung wirkungslos, weshalb sie hier mitgenannt wird.
• Die Angabe ist bewusst eine Zahl und keine Pauschale: die verbleibenden Tabellen sind nicht mandantenbezogen oder dem Trennungsmechanismus vorgelagert. Eine Pauschalaussage wäre unrichtig, „in Einführung“ inzwischen untertrieben.
• Trennung von Test-/Entwicklungs- und Produktionsdaten.

---

2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

2.1 Weitergabekontrolle

• Übermittlung personenbezogener Daten an Dritte ausschließlich an die in Anlage 3 benannten Sub-Prozessoren bzw. an die vom Verantwortlichen aktivierten Integrationen, jeweils über verschlüsselte Verbindungen (TLS).
• Festgelegte, konstante Ziel-Endpunkte für externe Dienste (kein eingabegesteuertes Umleiten von Anfragen — Schutz vor serverseitigem Request-Forgery).

2.2 Eingabekontrolle

• Protokollierung sicherheits- und betriebsrelevanter Ereignisse zur Nachvollziehbarkeit (forensische Ereignis-Logs). Die Eingabekontrolle wird auf Anwendungsebene geführt: die Protokolle entstehen dort, wo die Eingabe oder Änderung ausgelöst wird, und nicht auf einer vorgelagerten Netzwerkebene.
• Umfang. Als Protokolle der Eingabekontrolle im Sinne dieser Ziffer werden geführt: das Löschprotokoll (jeder Löschvorgang eines Mandanten, Zeitpunkt, Umfang und auslösende Stelle), das Zugriffsprotokoll der Mandantenübernahme (Übernahme eines Mandantenkontos durch eine Agentur — handelndes Konto, betroffener Mandant, aufgerufene Funktion) sowie das Protokoll der Zugriffsentziehung (Entzug und Wiederherstellung von Agenturzugängen). Aufgezeichnet werden ausschließlich Kennungen, Zeitstempel, Aktions- und Ergebnisbezeichner, gegebenenfalls eine Begründung des Auftragsverarbeiters sowie Fehlermeldungen und Zählwerte des Löschlaufs. Gesprächs- oder Nachrichteninhalte werden in diese Protokolle nicht kopiert.
• Aufbewahrungsdauer. Diese drei Protokolle werden unbefristet aufbewahrt, und zwar bewusst: das Löschprotokoll ist der Nachweis der Löschung nach Art. 17 Abs. 3 lit. e DSGVO, die beiden übrigen sind Bestandteil des Verarbeitungsnachweises nach Art. 28 DSGVO. Ein Nachweis, der sich nach Ablauf einer Frist selbst entfernt, könnte beides nicht leisten; sie überdauern deshalb auch die Löschung des betroffenen Mandanten und enthalten aus eben diesem Grund keine Inhaltsdaten. Der älteste protokollierte Vorgang datiert zum Stichtag der Messung am 4. August 2026 vom 28. April 2026.
• Abgrenzung. Auf dem vom Auftragsverarbeiter selbst betriebenen Reverse-Proxy (Caddy) findet keine Protokollierung des Anwendungsverkehrs statt; dort wird ausschließlich die eigene Verfügbarkeitsprobe des Auftragsverarbeiters aufgezeichnet. Es besteht insoweit kein Zugriffsprotokoll, das personenbezogene Verbindungsdaten der Betroffenen vorhielte — was zugleich dem Grundsatz der Datenminimierung entspricht. Eine Protokollierung auf der Ebene des vorgeschalteten CDN- und WAF-Dienstes (Ziff. 3.1) ist davon nicht erfasst; sie richtet sich nach dem Verhältnis zu dem in Anlage 3 benannten Sub-Prozessor. Die plan­bezogene Aufbewahrung der Mandantendaten und der Gesprächsverläufe ist ein anderer Gegenstand und richtet sich nicht nach dieser Ziffer.

---

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c DSGVO)

3.1 Verfügbarkeitskontrolle

• Betrieb auf etablierter Cloud-/RZ-Infrastruktur mit den providerseitigen Verfügbarkeits- und Schutzmechanismen.
• Vorgelagerter Schutz gegen Überlastung/Angriffe (Cloudflare).
• Datensicherung der Datenbank über die Mechanismen des Datenbank-Anbieters (Neon). Maßgeblich ist kein Sicherungsintervall im klassischen Sinn, sondern ein durchgehendes Point-in-Time-Recovery-Fenster: der Zustand der Produktionsdatenbank lässt sich auf jeden beliebigen Zeitpunkt innerhalb der letzten 6 Stunden zurückführen (History-Retention des Produktionsprojekts, gemessen am 4. August 2026).
• Die Unterscheidung ist keine Wortklauberei: „stündliche Sicherung“ und „6-Stunden-Fenster“ klingen ähnlich und bedeuten Verschiedenes — im ersten Fall gibt es Zeitpunkte, auf die man nicht zurückkann, im zweiten nicht. Außerhalb dieses Fensters existiert keine Rückführbarkeit; das begrenzt zugleich den RPO-Wert in Abschnitt 3.2 und ist dort genannt.

3.2 Rasche Wiederherstellbarkeit

• Wiederherstellung aus Datenbank-Sicherungen über die Funktionen des Datenbank-Anbieters.
• Zielzeiten (Festlegung des Betreibers, 4. August 2026): RTO ≤ 24 Stunden — Zielzeit bis zur Wiederherstellung des Dienstes. RPO ≤ 6 Stunden — maximal tolerierter Datenverlust.
• 🔴 Der RPO-Wert ist keine freie Zusage, sondern durch das Point-in-Time-Fenster aus Abschnitt 3.1 nach oben begrenzt — und er gilt nur, soweit der Vorfall innerhalb dieses Fensters erkannt wird. Wird ein Datenverlust erst nach Ablauf des Fensters bemerkt, ist eine Rückführung auf den Zeitpunkt davor technisch nicht mehr möglich; der tatsächliche Verlust ist dann größer als der Zielwert. Diese Grenze wird hier genannt und nicht in der Zielzahl versteckt: ein RPO, der die Erkennungsgrenze verschweigt, verspricht etwas, das im ungünstigen Fall niemand halten kann.

---

4. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d, Art. 25 DSGVO)

4.1 Datenschutz-Management

• Berücksichtigung der Grundsätze „Datenschutz durch Technikgestaltung“ und „durch datenschutzfreundliche Voreinstellungen“ (Art. 25 DSGVO): u. a. keine Werbe-Tracker/Tracking-Cookies Dritter, nur technisch notwendige Cookies, ausschließlich aggregierte Reichweitenmessung.
• Pflege dieser TOM sowie der Sub-Prozessoren-Liste (Anlage 3) bei Änderungen des Stacks.
• Überprüfungsrhythmus (Festlegung des Betreibers, 4. August 2026): mindestens jährlich, zusätzlich anlassbezogen bei (a) Aufnahme, Wechsel oder Wegfall eines Unterauftragsverarbeiters und (b) nach einem meldepflichtigen Vorfall nach Abschnitt 4.2.
• Nachweis: jede Überprüfung wird im Änderungsjournal dieses Dokuments festgehalten (Datum, Prüfumfang, Ergebnis). Ein Rhythmus, der nur im Text steht, ist unbelegt — nachweisbar wird er erst durch den Eintrag, und das Fehlen eines Eintrags ist damit selbst eine Feststellung.

4.2 Vorfallreaktion (Incident Response)

• Verfahren zur Erkennung, Bewertung und Meldung von Verletzungen des Schutzes personenbezogener Daten gemäß § 9 AVV (Art. 33 DSGVO).

• **Interne Eskalations- und Reaktionszeiten (Festlegung des Betreibers,

  4. August 2026), jeweils gerechnet ab Kenntniserlangung:**

  Frist	Schritt
  ≤ 24 Stunden	Ersteinschätzung: Sachverhalt, betroffene Datenkategorien, Eindämmung
  ≤ 48 Stunden	Entscheidung über die Meldepflicht und Unterrichtung des Verantwortlichen
  ≤ 72 Stunden	Äußere Grenze nach Art. 33 Abs. 1 DSGVO

• 🔴 Die Fristen laufen kumulativ ab Kenntniserlangung, nicht nacheinander. Die 72 Stunden sind die gesetzliche Außengrenze, an der sich die beiden internen Werte ausrichten; sie addieren sich nicht zu ihr. Die 48 Stunden sind bewusst kürzer gewählt als die gesetzliche Grenze, damit dem Verantwortlichen eine eigene Reaktionszeit bleibt — er ist nach Art. 33 selbst meldepflichtig, und eine Unterrichtung erst zur 72-Stunden-Marke hin würde ihm keine lassen.

4.3 Auftragskontrolle (Steuerung der Unterauftragsverarbeiter)

• Einsatz von Unterauftragsverarbeitern ausschließlich gemäß § 7 AVV mit vertraglicher Verpflichtung auf gleichwertige Datenschutzpflichten.
• Drittland-Übermittlungen sind durch geeignete Garantien (EU-Standardvertragsklauseln, ggf. ergänzende Maßnahmen) abgesichert (siehe Anlage 3).

4.4 Betroffenenrechte / Löschung

• Funktionen zur Auskunft/Export und zur Löschung personenbezogener Daten, einschließlich der Möglichkeit der Konto-/Datenlöschung auf Veranlassung des Verantwortlichen (Unterstützung der Betroffenenrechte nach §§ 8, 11 AVV).
• Beachtung gesetzlicher Aufbewahrungspflichten (z. B. steuerliche Unterlagen) vor endgültiger Löschung.

---

Hinweis zur Pflege

Diese TOM sind mit der öffentlichen Datenschutzerklärung und der Sub-Prozessoren-Liste (Anlage 3) konsistent zu halten. Maßgeblich für tatsächliche Aussagen ist stets der nachweisbare Stand der Implementierung.