Auftrags­verarbeitungs­vertrag

1. Verantwortlicher und Auftragsverarbeiter

Die Liste der Verantwortlichen ist die Tabelle Firma. Sie ist damit selbst Teil dieses Verzeichnisses und muss nicht doppelt geführt werden.

2. Die Verarbeitungstätigkeiten im Einzelnen

2.1 Arbeitszeiterfassung (Kerntätigkeit)

Zweck: Erfassung, Auswertung und Dokumentation der Arbeitszeit der Beschäftigten des Kunden — die gesetzliche Aufzeichnungspflicht nach § 26 AZG.

Betroffene: Beschäftigte der Kundenbetriebe.

Datenkategorien (mit Fundstelle):

Besondere Kategorien nach Art. 9 DSGVO. Abwesenheit.typ = 'KRANKENSTAND' ist eine Angabe zur Gesundheit. Sie steht in der Anwendung ohne Diagnose und ohne Begründung — nur „krank von/bis" —, ist aber trotzdem ein Gesundheitsdatum. Damit gilt das grundsätzliche Verarbeitungsverbot des Art. 9 Abs. 1; die Verarbeitung stützt sich beim Verantwortlichen regelmäßig auf Art. 9 Abs. 2 lit. b (Arbeitsrecht) i. V. m. § 8 Abs. 1 DSG.

Für den Betreiber folgt daraus die Verschärfung, die das ganze Plattform-Dashboard prägt: Er sieht diese Zeilen nicht (siehe TOM, Punkt 3.4).

Zu `Berichtsplan`, weil hier Daten den Betrieb verlassen: Richtet ein Administrator einen Monatsbericht ein, gehen Arbeitszeitdaten seiner Beschäftigten als Excel-Datei an Adressen, die er selbst bestimmt — typischerweise an die Lohnverrechnung. Wer diese Empfänger auswählt, ist der Kunde; er ist Verantwortlicher und weist damit an. Der Betreiber prüft die Adressen nur auf Form und Zahl (höchstens fünf je Bericht), nicht auf Berechtigung — das kann er nicht. Technisch abgesichert ist stattdessen die Nachvollziehbarkeit: jeder Versand wird im `AuditLog` mit Zeitpunkt und vollständiger Empfängerliste festgehalten, und die Einrichtung bleibt Administratoren vorbehalten (kein Abteilungsleiter, siehe src/lib/leiterrechte.ts). In der Anwendung steht dieser Hinweis an der Stelle, an der er gebraucht wird — auf der Einrichtungsseite selbst.

Zu den Abteilungen: Sie sind eine Einteilung des Kunden, keine zusätzliche Datenerhebung über die Beschäftigten. Sie wirken in zwei Richtungen zugleich datensparsam: Ein Projekt einer Abteilung ist für alle anderen unsichtbar, und ein Abteilungsleiter sieht ausschließlich die Arbeitszeitdaten seiner eigenen Abteilung statt die des ganzen Betriebs (Rollenkonzept in src/lib/leitung.ts).

Rechtsgrundlage: Verarbeitung im Auftrag, Art. 28 DSGVO. Der Betreiber hat keine eigene Rechtsgrundlage und braucht keine — er handelt auf Weisung.

Speicherdauer: siehe loeschkonzept.md.

2.2 Zugang und Kontosicherheit

Zweck: Anmeldung, Zwei-Faktor-Authentifizierung, Passwortrücksetzung, Abwehr von Anmeldeangriffen.

Zu `Anmeldeversuch`, weil es die unangenehmste Zeile dieses Verzeichnisses ist: Hier entstehen Daten von Menschen, die nie Kunde werden — jeder Tippfehler in der Adresse erzeugt einen Eintrag mit E-Mail und IP. Die Tabelle ist plattformweit (sie muss es sein: Der Zähler läuft, bevor feststeht, zu welcher Firma eine Anmeldung gehört). Sie ist deshalb ausdrücklich befristet und wird vom nächtlichen Lauf geräumt (src/lib/aufbewahrung.ts).

Rechtsgrundlage: Für die Kontosicherheit Auftragsverarbeitung; für den Anmeldeschutz zusätzlich das berechtigte Interesse des Betreibers an der Sicherheit seines Dienstes (Art. 6 Abs. 1 lit. f), da er hier auch im eigenen Namen handelt.

2.3 Vertragsverhältnis mit dem Kunden

Zweck: Abrechnung, Betreuung, Nachweis der Zustimmung. Hier ist der Betreiber Verantwortlicher, nicht Auftragsverarbeiter.

Rechtsgrundlage: Vertrag (Art. 6 Abs. 1 lit. b) und rechtliche Verpflichtung (Art. 6 Abs. 1 lit. c, Aufbewahrung von Rechnungen). Für die Erinnerungen an Administratorkonten zusätzlich berechtigtes Interesse (Art. 6 Abs. 1 lit. f).

2.4 Betrieb und Rechenschaft

Das Zugriffsprotokoll ist zugleich ein Verkaufsargument, und deshalb ist es so gebaut: Der Kunde sieht diese Einträge in seiner eigenen Anwendung. Nicht „wir schauen nicht hinein", sondern „jeder Blick steht in Ihrem Protokoll". Technisch: PlattformProtokoll ist mandantengebunden und für den Kunden lesbar, für ihn aber nicht schreibbar — ein Protokoll, das der Protokollierte führen könnte, wäre keines.

3. Empfänger

Vollständig in unterauftragsverarbeiter.md. Kurz: Hosting und Datenbank (Sliplane, Rechenzentren von Hetzner in Deutschland), E-Mail-Versand (Mailjet), E-Mail-Empfang (Apple, iCloud+ mit eigener Domain), Zahlungsabwicklung (Stripe, im Einsatz seit 09/2026).

Keine Übermittlung an Dritte darüber hinaus. Kein Analysedienst, kein Zählpixel, keine Werbenetzwerke — auch nicht in den Systemnachrichten (src/lib/mail/texte.ts).

Ausnahme auf Weisung des Kunden: Hat ein Kunde Monatsberichte eingerichtet (2.1, Berichtsplan), gehen die darin enthaltenen Arbeitszeitdaten über denselben Mailversand (Mailjet) an die von ihm benannten Adressen — regelmäßig seine Lohnverrechnung. Empfänger und Inhalt bestimmt der Kunde, der Betreiber führt nur aus.

4. Drittlandübermittlung

Anwendung und Datenbank laufen in Deutschland bei Sliplane (Berlin) in Rechenzentren von Hetzner — keine Drittlandübermittlung für den Betrieb selbst. Verschlüsselte Sicherungen liegen unter anderem bei Backblaze, Inc. (EU-Standort, US-Gesellschaft); Details in unterauftragsverarbeiter.md. Der E-Mail-Empfang läuft über iCloud+ mit eigener Domain; Vertragspartner ist die Apple Distribution International Ltd. (Irland), die Inhalte werden von Apple auch in den USA gespeichert, und für diesen Verbraucherdienst ist kein Auftragsverarbeitungsvertrag zu bekommen — die offene Position ist in unterauftragsverarbeiter.md ausführlich benannt. Zahlungsabwicklung über Stripe Payments Europe (Irland), im Einsatz seit 09/2026; dort ist ein Zugriff durch die US-Muttergesellschaft rechtlich möglich, Grundlage wären das EU-US Data Privacy Framework bzw. Standardvertragsklauseln. Details je Anbieter in unterauftragsverarbeiter.md.

5. Löschfristen

Siehe loeschkonzept.md — dort steht je Kategorie eine Frist, und zu jeder Frist die Stelle im Code, die sie durchsetzt.

6. Technische und organisatorische Maßnahmen

Siehe tom.md.

7. Was in diesem Verzeichnis bewusst NICHT steht

• Standortdaten. Die Anwendung erfasst keine. Die Berechtigung ist im Browser ausdrücklich abgeschaltet (Permissions-Policy: geolocation=()).
• Biometrische Daten. Keine.
• Profilbildung oder automatisierte Entscheidungen nach Art. 22. Keine. Die Mitteilungen (z. B. „Grenzwert überschritten") sind Hinweise an Menschen, keine Entscheidungen — sie lösen nichts aus und haben keine Rechtswirkung.
• Auswertungen des Betreibers über Kundendaten. Ausgeschlossen und technisch durchgesetzt, siehe TOM 3.4.

1. Vertraulichkeit

1.1 Zutrittskontrolle (physisch)

Keine eigene Hardware. Anwendung und Datenbank laufen bei Sliplane in Rechenzentren der Hetzner Online GmbH in Deutschland (Unterauftragsverarbeiter); deren Zutrittskontrolle ist Teil der Zertifizierung des Rechenzentrumsbetreibers (Hetzner: ISO 27001). Der Betreiber hat keinen physischen Zugang zu Servern.

1.2 Zugangskontrolle (wer kommt hinein)

1.3 Zugriffskontrolle (wer sieht was)

Die Mandantentrennung läuft auf zwei unabhängigen Ebenen. Das ist die wichtigste Einzelaussage dieses Dokuments:

1. Anwendungsebene: mitFirma() setzt die Firmenzugehörigkeit in jede Abfrage und entfernt sie aus jedem Schreibvorgang — eine Zeile kann den Mandanten nicht wechseln. (src/lib/firma.ts)
2. Datenbankebene: PostgreSQL Row Level Security mit FORCE ROW LEVEL SECURITY auf jeder Mandantentabelle. Die Anwendung verbindet sich als Rolle app_mandant ohne BYPASSRLS; die Zugehörigkeit steht in einer transaktionslokalen Sitzungsvariablen. (Migration _rls, scripts/rollen-anlegen.sql)

Ebene 1 allein wäre eine vergessene Zeile von einem Datenleck entfernt. Ebene 2 allein wäre kaum lesbar. Dass beide unabhängig voneinander tragen, wird gemessen, nicht behauptet: src/test/mandanten.integration.test.ts prüft Ebene 1 gegen eine Verbindung ohne RLS — also ohne Ebene 2 — und umgekehrt. src/test/lastparallel.integration.test.ts prüft dasselbe unter gleichzeitiger Last mehrerer Firmen.

Weiter:

1.4 Trennungskontrolle

Siehe 1.3. Zusätzlich: Die Sicherung eines Kunden enthält ausschließlich dessen Daten (src/lib/sicherung.ts), und eine Rückspielung wirkt nur auf den eigenen Betrieb — mit ausdrücklicher Prüfung, ob die hochgeladene Datei aus einem fremden Betrieb stammt.

2. Integrität

Ein Restrisiko, ausdrücklich benannt: style-src erlaubt 'unsafe-inline'. Grund: src/app/global-error.tsx trägt seine Gestaltung als Inline-Stilattribute, weil diese Seite genau dann erscheint, wenn das Stylesheet ausgefallen ist; für Attribute hilft ein Nonce nicht. Eingeschleustes CSS ist ohne Freigabe in script-src ein Darstellungs-, kein Ausführungsproblem.

3. Verfügbarkeit und Belastbarkeit

Die geprobte Rückspielung ist der Punkt, an dem sich dieses Dokument von den meisten unterscheidet. „Regelmäßige Sicherungen" steht in jedem TOM-Papier. Ob sie sich zurückspielen lassen, weiß man erst, wenn man es getan hat — und die meisten haben es nicht. Hier läuft die Probe bei jedem Push, und sie vergleicht den Bestand danach Zeile für Zeile mit dem davor.

4. Verfahren zur regelmäßigen Überprüfung

4.1 Was der Betreiber vom Kunden NICHT sieht

Diese Maßnahme hat keine Entsprechung in den üblichen TOM-Listen, ist hier aber die wirksamste — und für einen Betriebsrat die entscheidende Frage:

• Das Plattform-Dashboard lädt keine Zeile aus Stempelung, Abwesenheit, Monatsabschluss, Auszahlung, Urlaubsanspruch oder AuditLog und aus Mitarbeiter weder Namen noch E-Mail. Es rechnet ausschließlich mit count, groupBy und aggregate.
• Das ist durch automatische Tests erzwungen, nicht vereinbart: plattformAggregatWache.test.ts durchsucht den gesamten Betreiberbereich nach Zeilenzugriffen und nach include/select auf die betroffenen Beziehungen. Ein „include" zu viel lässt die automatischen Tests fehlschlagen.
• Jeder Support-Zugriff braucht Grund und Befristung und steht anschließend im Protokoll — das der Kunde in seiner eigenen Anwendung sieht.
• Schon das Öffnen einer Firmendetailseite erzeugt einen Protokolleintrag, gedrosselt auf einen je Stunde.

5. Offen — und deshalb hier und nicht verschwiegen

1. Eingesetzte Dienste

2. Anmerkungen, die in die Bewertung gehören

Sliplane ist ein deutscher Anbieter mit Sitz in Berlin; Anwendung und Datenbank laufen in Rechenzentren der Hetzner Online GmbH in Deutschland. Für den Betrieb selbst findet keine Übermittlung in ein Drittland statt. Das ist der Punkt, an dem ein Betriebsrat nachfragen wird. Bis 2026-09-14 standen an dieser Stelle Vercel und Neon (US-Gesellschaften mit EU-Region); gewechselt wurde vor dem ersten Kundendatensatz. Beide sind aus der Kette vollständig heraus. IONOS Cloud war kurz vorgesehen und wurde wegen der Kosten verworfen.

Sliplane setzt seinerseits Unterauftragsverarbeiter ein. Die folgende Liste ist Abschnitt 6 des am 19.09.2026 angenommenen AVV (Fassung 2.1) entnommen. Für die Region Deutschland, die qlok nutzt, betrifft das:

Die im selben Abschnitt genannten DataCamp Limited (Seattle) und Latitude.sh (Ashburn, Singapur) betreffen ausschließlich die Server-Regionen USA und Singapur. qlok nutzt sie nicht; nach Abschnitt 2 des AVV verlegt Sliplane keine Daten in eine Region, die der Verantwortliche nicht gewählt hat.

Ehrlich benannt: Backblaze. Die Sicherungen liegen in der EU und sind verschlüsselt, aber Backblaze ist eine US-Gesellschaft. Ein Zugriff nach US-Recht auf die verschlüsselten Dateien ist damit rechtlich nicht ausgeschlossen. Ob der Schlüssel bei Sliplane oder beim Speicheranbieter liegt — davon hängt ab, was ein solcher Zugriff hergäbe.

Zum Namen im Sliplane-Vertrag. Die ausgefertigte Kopie vom 19.09.2026 nennt als Verantwortlichen den Kontonamen „mariushcloud's team" unter der Anschrift Alpenstraße 106, Neu-Anif, AT — also der Anschrift der Konzept Schmiede GmbH, die Vertragspartner ist. Der Betreiber hat am 21.09.2026 entschieden, es dabei zu belassen: Anschrift und handelnde Person stimmen, der Kontoname ist eine Bezeichnung und keine Partei, und der Vertrag ist wirksam geschlossen. Wer ihn prüft, wird die Zeile lesen — deshalb steht sie hier erklärt und nicht unerwähnt.

Ehrlich benannt: Sliplane ist ein kleiner Anbieter (laut AVV betrieben von einer natürlichen Person). Das ist datenschutzrechtlich kein Mangel, betrifft aber die Verfügbarkeit und die Frage, was bei einer Einstellung des Dienstes geschieht. Die Anwendung ist deshalb bewusst nicht an Sliplane gebunden (Abschnitt 3).

Die Datenbank hängt nicht in einem privaten Netz, sondern ist über das Internet erreichbar — nur von ausdrücklich freigegebenen IP-Adressen und nur über TLS mit Zertifikatsprüfung. Freigegeben sind der Anwendungsserver und, für Wartung, der Arbeitsplatz des Betreibers.

Let's Encrypt (Internet Security Research Group, USA) stellt die TLS-Zertifikate aus. Übermittelt wird dabei der Domainname, keine Kundendaten — kein Unterauftragsverarbeiter.

Ehrlich benannt: das Postfach liegt bei Apple, und dafür gibt es keinen AVV. Seit 09/2026 laufen support@qlok.eu und marius.huttary@qlok.eu über iCloud+ mit eigener Domain und landen im iCloud-Postfach des Betreibers; der frühere Empfang über Infomaniak (Schweiz) ist entfallen. iCloud+ ist ein Verbraucherdienst: Apple schließt dafür keinen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ab, und die iCloud-Inhalte werden nach Apples eigenen Angaben auch in Rechenzentren in den USA gespeichert.

Solange das Postfach nur Post enthält, die Kunden von sich aus schreiben, ist das vertretbar — der Absender entscheidet selbst, was er hineinschreibt, und die Verarbeitung beruht auf seiner eigenen Kontaktaufnahme, nicht auf dem Auftrag. Unhaltbar wird es, sobald dort planmäßig Beschäftigtendaten des Kunden bearbeitet werden, etwa Stundenlisten, die zur Klärung geschickt werden.

Zwei Dinge sind deshalb zu tun. Erstens: dem Juristen die Frage vorlegen, ob der Empfang von Supportpost über einen Verbraucherdienst ohne AVV tragbar ist — und ob der Dienst stattdessen in diese Liste gehört oder gar nicht hineindarf. Zweitens gilt bis dahin eine Hausregel: Beschäftigtendaten gehören nicht ins Postfach. Wer Zahlen klären will, tut das in der Anwendung — dafür gibt es den angemeldeten, befristeten Support-Zugriff (AVV § 6.4). Anhänge mit Personaldaten werden nicht angefordert und nach der Klärung gelöscht.

Der Punkt ließe sich auch technisch aus der Welt schaffen: Ein Postfach bei einem Geschäftsdienst mit AVV (Infomaniak, mailbox.org, Microsoft 365) kostet wenige Euro im Monat und macht aus der offenen Position eine Zeile in der Tabelle oben.

Die Domain liegt vollständig bei INWX (Registrar und Nameserver, seit 2026-09-14). qlok.eu zeigt per A/AAAA-Eintrag direkt auf den Server bei Sliplane, www.qlok.eu per CNAME; die Anwendung leitet www auf qlok.eu weiter (next.config.mjs). Die MX-Einträge zeigen auf Apple (iCloud+ mit eigener Domain), dazu die von Apple vorgegebenen SPF-, DKIM- und DMARC-Einträge. Cloudflare ist an der Domain nicht mehr beteiligt — weder als Registrar noch als Nameserver noch als Proxy — und damit kein Dienst dieser Kette mehr.

Mailjet berührt keine Zeitdaten, sondern nur Adressen und die Texte der Systemnachrichten. Die Nachrichten zum Testzeitraum und Abonnement gehen an die Ansprechpersonen und an die aktiven Administratorkonten eines Betriebs (src/lib/abrechnung/lauf.ts, empfaenger). Nachrichten, die der Betreiber selbst auslöst — die vorgefertigten Knöpfe im Firmendetail und die Rundschreiben aus dem Reiter „Mails" — gehen ausschließlich an die hinterlegten Ansprechpersonen, also an die Vertragspartner des Betreibers und nicht an Beschäftigte (src/lib/plattformNachrichtLaden.ts). Die Texte enthalten bewusst keine Beschäftigtendaten über den Empfänger hinaus — kein Saldo, keine Krankenstände, keine Namen Dritter. Nachlesbar in src/lib/mail/texte.ts und src/lib/betreibernachrichten.ts.

Der Vertrag mit Mailjet ist geschlossen. Am 21.09.2026 wurde das Sinch Data Processing Agreement, Fassung vJan 2025 (Sinch ist die Muttergesellschaft von Mailjet) von beiden Seiten unterzeichnet. Damit ist die Kette der Auftragsverarbeitungsverträge vollständig: Sliplane, Sinch und Stripe liegen vor, und für INWX wird keiner gebraucht. Offen bleibt allein das Postfach bei Apple — dazu die Anmerkung weiter unten.

Was darin steht, soweit es diese Anlage betrifft:

- Der Vertrag ist Bestandteil des Sinch-Rahmenvertrags („Principal Agreement"); die Vertragsparteien sind dieselben. - Drittlandübermittlung: Standardvertragsklauseln nach Durchführungsbeschluss (EU) 2021/914, Modul 2 (Verantwortlicher an Auftragsverarbeiter) bzw. Modul 3, wo Sinch Unterauftragsverarbeiter ist. Dazu das UK-Addendum. Für Sinch Email zusätzlich das EU-US Data Privacy Framework. - Anwendbares Recht der Klauseln: Schweden. Zuständige Aufsichtsbehörde nach Klausel 13 ist die schwedische Datenschutzbehörde IMY (Integritetsskyddsmyndigheten). Das ist erwähnenswert, weil man Mailjet für französisch hält: Vertragspartner und Aufsicht sind schwedisch. - Unterauftragsverarbeiter von Sinch: allgemeine Genehmigung mit Ankündigung 30 Tage im Voraus und einem Widerspruchsrecht binnen 10 Werktagen. Die Liste steht unter sinch.com/data-protection-agreement/sub-processors. - Technische und organisatorische Maßnahmen: Anlage 2 des Sinch-DPA.

Ein Punkt bleibt, und er ist leicht zu übersehen: Die 30-Tage-Ankündigung neuer Unterauftragsverarbeiter kommt nur, wenn man sie abonniert hat — über die Benachrichtigungsfunktion auf derselben Seite. Ohne dieses Abonnement gibt es kein Widerspruchsrecht, das man ausüben könnte, weil man nichts erfährt.

Stripe berührt keine Zeit- und Abwesenheitsdaten. Übertragen wird die Zahl der Sitzplätze, nicht wer sie belegt (src/lib/abrechnung/sitzplaetze.ts rechnet mit count, nicht mit Zeilen).

Eine Beschäftigtenangabe erreicht Stripe genau in einem Fall, und der gehört hierher: Ist für einen Betrieb keine Ansprechperson mit E-Mail hinterlegt, geht beim ersten Abschluss die Adresse des Admin-Kontos, das bucht, als Rechnungsadresse an Stripe (src/lib/abrechnung/checkoutLaden.ts, rechnungsadresse). Ohne sie käme keine Rechnung an. Wer das vermeiden will, hinterlegt vor dem Abschluss eine Ansprechperson.

Ein Überwachungsdienst ist NICHT eingesetzt. Die Naht steht (src/lib/ueberwachung.ts); Vorfälle gehen derzeit ins Dienstprotokoll bei Sliplane, also an keinen zusätzlichen Empfänger. Ein externer Dienst (etwa Sentry mit EU-Region) wird Unterauftragsverarbeiter und muss vorher in diese Tabelle und in den AVV.

Kein Analysedienst, keine Zählpixel, keine Werbenetzwerke — weder auf der Landing Page noch in der Anwendung noch in den E-Mails.

3. Wechsel eines Dienstes

Der AVV muss regeln, wie ein Wechsel abläuft (Art. 28 Abs. 2: Information und Widerspruchsrecht). Technisch ist der Wechsel bei zwei der Dienste bewusst vorbereitet:

• Mailversand: src/lib/mail/ ist eine Schnittstelle mit austauschbarer Umsetzung. Der Grund steht dort und ist genau dieser: Der Anbieter wird Unterauftragsverarbeiter, ein Wechsel ist ein Vorgang mit Vorlauf und kein technischer Zufall.
• Abrechnung: src/lib/abrechnung/anbieter.ts, gleiche Bauart.

Für Hosting und Datenbank gilt das nicht — ein Wechsel ist dort ein Projekt, kein Eintrag. Er ist aber kleiner geworden: Die Mandantentrennung setzt seit 2026-09-14 kein Sonderrecht des Datenbankanbieters mehr voraus (Richtlinie statt BYPASSRLS, Migration _plattform_richtlinie) und läuft auf jedem PostgreSQL.

4. Wie ein AVV mit diesen Diensten zustande kommt

Was damit gemeint ist. Ein Auftragsverarbeitungsvertrag ist hier kein Schriftstück, das Sie selbst aufsetzen und dem Dienst schicken. Jeder dieser Anbieter hält einen fertigen Vertragstext bereit („Data Processing Agreement", DPA) und bietet ihn im eigenen Konto zur Annahme an. Sie sind dort der Kunde: Der Anbieter verpflichtet sich Ihnen gegenüber zu demselben, wozu Sie sich Ihren eigenen Kunden gegenüber verpflichten — Weisungsbindung, Vertraulichkeit, technische Maßnahmen, Meldung von Datenpannen, Löschung am Ende. Das dauert je Dienst ein paar Minuten und besteht überall aus denselben drei Schritten:

1. Annehmen. Im Konto des Dienstes die Stelle suchen, an der das DPA liegt, es lesen und zustimmen. Meist ein Kontrollkästchen mit Namenszeile.
2. Die Fassung ablegen. PDF herunterladen, mit Datum in die eigene Ablage. Das ist der eigentliche Punkt. Fragt ein Kunde oder die Datenschutzbehörde nach, gilt nicht, dass Sie irgendwann zugestimmt haben, sondern nur das, was Sie vorlegen können.
3. Hier eintragen. Fassung und Datum in die Tabelle in Abschnitt 1. Nur dann stimmt die Anlage, die Ihre Kunden mit dem AVV bekommen.

Je Dienst, konkret:

Und dann:

1. Diese Liste in den AVV aufnehmen (als Anlage, auf die der Vertragstext verweist).
2. Vor jedem neuen Dienst: erst hier eintragen, dann einsetzen.
3. Bei Sliplane erfragen: Speicherort des Objektspeichers für die Region Deutschland, Schlüsselverwaltung der Sicherungen, Aufbewahrungsdauer der Dienstprotokolle.
4. Bei Sinch die Benachrichtigung über neue Unterauftragsverarbeiter abonnieren — sonst läuft das vereinbarte Widerspruchsrecht ins Leere.