Zum Inhalt

ADR-015: Auftragsverarbeitungsvertrag und Datenschutzrollen

Stand: 08.08.2026 14:35 Branch: main Status: Akzeptiert

Datum, Uhrzeit Version Änderung Autor
08.08.2026 14:35 1.5 Modulare AVV-Arbeitsvorlage und kontrollierten juristischen Freigabe- und Nachweisprozess verknüpft Codex
08.08.2026 13:28 1.4 Hostpoint-Providerentscheid und sichere Übermittlung einmaliger Vertragslinks gemäss ADR-016 verknüpft Codex
07.08.2026 18:57 1.3 Vertragsstatus, Sieben-Tage-Token, Nachweis-Snapshot und V1-Prüfprozess abschliessend festgelegt Codex
07.08.2026 18:42 1.2 Vertragskontakt, unterzeichnende Person und Tenant-Admin als getrennte, kombinierbare Rollen festgelegt Codex
07.08.2026 18:38 1.1 Vollständige Vertragsparteidaten als Sperrbedingung vor AVV-Abschluss ergänzt; Schweizer Schreibweise bereinigt Codex
06.08.2026 19:08 1.0 Datenschutzrollen und Abschlusszeitpunkt des Auftragsverarbeitungsvertrags für UC00 festgelegt Codex

Kontext

DiveLogix360 verarbeitet im Rahmen des Software-as-a-Service-Angebots personenbezogene Daten im Auftrag der angeschlossenen Tauchschulen. Für Deutschland und Österreich ist dafür ein Auftragsverarbeitungsvertrag nach Art. 28 Datenschutz-Grundverordnung erforderlich. In der Schweiz wird fachlich von Auftragsbearbeitung nach Art. 9 Datenschutzgesetz gesprochen.

Die bisherige UC00-Spezifikation erstellt den Tenant-Admin und versendet dessen Produkteinladung unmittelbar bei der Tenant-Anlage. Ein verbindlicher Vertragsabschluss und dessen Nachweis fehlen.

Datenschutzrollen

  • Die Tauchschule ist für die von ihr bestimmten Zwecke der Kunden- und Mitarbeiterdatenverarbeitung grundsätzlich Verantwortlicher.
  • DiveLogix360 ist für diese Verarbeitung Auftragsverarbeiter beziehungsweise in der Schweizer Terminologie Auftragsbearbeiter.
  • DiveLogix360 kann für eigene Zwecke, beispielsweise Vertragsverwaltung und Abrechnung, selbst Verantwortlicher sein. Diese eigenen Verarbeitungen sind vom Auftragsverarbeitungsvertrag abzugrenzen.
  • Unterauftragnehmer von DiveLogix360 sind im Vertrag beziehungsweise in dessen Anlagen transparent zu führen und nach den anwendbaren Regeln zu genehmigen.

Geprüfte Varianten

Variante A: Vertrag vor Tenant-Anlage

Ohne abgeschlossenen Vertrag wird kein Tenant-Datensatz angelegt. Dies bietet eine strikte Trennung, erschwert aber die kontrollierte Vertragsvorbereitung und Zuordnung.

Variante B: Vertrag nach vorbereitender Tenant-Anlage, aber vor Produkteinladung

Der Superadmin darf einen Tenant mit minimalen Vertragsdaten vorbereiten. Die Einladung des Tenant-Admins und die produktive Verarbeitung von Tenant-Daten bleiben bis zum Vertragsabschluss gesperrt.

Variante C: Annahme beim ersten Login

Der Tenant-Admin nimmt den Vertrag nach Erhalt der Produkteinladung an. Dabei entstehen Benutzer- und Einladungsdaten bereits vor Vertragsabschluss, und der eingeladene Administrator ist nicht zwingend vertretungsberechtigt.

Variante D: Vertrag erst vor produktiver Aktivierung

Das Onboarding kann vor dem Vertrag durchlaufen werden. Dabei würden bereits umfangreiche Schul-, Benutzer- und möglicherweise weitere personenbezogene Daten verarbeitet.

Entscheidung

Variante B wird für V1 akzeptiert: Der Auftragsverarbeitungsvertrag muss nach der vorbereitenden Tenant-Anlage, aber vor der Einladung des Tenant-Admins abgeschlossen sein.

Es gelten folgende Regeln:

  • Der Superadmin darf einen Tenant zunächst nur mit minimal erforderlichen Vertragsdaten im fachlichen Status contract_pending vorbereiten.
  • Vor Einleitung oder kontrollierter Erfassung des Vertragsabschlusses müssen die vollständige rechtliche Bezeichnung sowie Strasse, Postleitzahl, Ort und Land des Tenants vorliegen.
  • Vertragskontakt, unterzeichnende Person und Tenant-Admin sind getrennte fachliche und historisch nachweisbare Rollen. Dieselbe natürliche Person darf mehrere oder alle Rollen übernehmen.
  • Name und geschäftliche E-Mail des Vertragskontakts sind vor Vertragsabschluss Pflicht; eine Telefonnummer ist für den Vertragsabschluss nicht erforderlich.
  • Bei unvollständigen Vertragsparteidaten bleibt der Tenant im Status contract_pending; der Vertragsabschluss wird serverseitig mit 409 contract_party_incomplete abgewiesen.
  • Vor Vertragsabschluss werden kein Tenant-Admin-Benutzer, kein Produkteinladungstoken und keine Produkteinladung erzeugt.
  • Die Annahme erfolgt durch eine als vertretungsberechtigt bestätigte Person der Tauchschule.
  • Nach erfolgreichem Abschluss wechselt der Tenant in den fachlichen Status onboarding.
  • Erst danach darf der Tenant-Admin angelegt und eingeladen werden.
  • Die produktive Nutzung und der Import realer Tenant-Daten bleiben bis zum Vertragsabschluss gesperrt.
  • Die elektronische Annahme und ein ausserhalb der Anwendung unterzeichnetes Dokument sind gleichwertig unterstützte Abschlusswege.
  • Eine ausserhalb der Anwendung unterzeichnete Vereinbarung wird vom Superadmin als Dokument hochgeladen und kontrolliert mit Abschlussdaten erfasst.
  • Die endgültige Vertragsvorlage und der Nachweisprozess müssen vor Produktivbetrieb juristisch geprüft werden.

Elektronischer Abschluss

Der elektronische Nachweis muss mindestens enthalten:

  • Tenant-ID
  • Vertragsversion und unveränderlicher Dokument-Hash beziehungsweise Snapshot
  • Abschlusszeitpunkt in koordinierter Weltzeit (UTC)
  • Name, geschäftliche E-Mail und Funktion der unterzeichnenden Person
  • ausdrückliche Bestätigung der Vertretungsberechtigung
  • Abschlussart electronic_acceptance
  • referenzierte Anlagen, insbesondere technische und organisatorische Massnahmen sowie Unterauftragnehmerliste
  • unveränderliche Kopie im Portable Document Format (PDF) beziehungsweise in einem anderen vereinbarten Dokumentformat für beide Parteien

IP-Adresse und User-Agent werden nur gespeichert, wenn eine dokumentierte rechtliche und datenschutzrechtliche Prüfung ihre Erforderlichkeit bestätigt.

Der Vertragstext beziehungsweise die Vertrags-PDF wird nicht per E-Mail versendet. Die unterzeichnende Person erhält über Hostpoint ausschliesslich einen minimierten einmaligen Link zum HTTPS-geschützten Vertragsportal. Für Token, Providerfreigabe und Nachrichtenminimierung gilt ADR-016.

Für V1 werden IP-Adresse und User-Agent nicht als Bestandteil des Vertragsnachweises gespeichert. Der Vertragstoken ist sieben Kalendertage gültig, einmalig verwendbar und wird ausschliesslich als Hash gespeichert. Eine Neuanforderung widerruft den vorherigen Token. Sicherheitsrelevante Verbindungsdaten bleiben getrennten Authentifizierungs- und Sicherheitsprotokollen vorbehalten.

Extern unterzeichnetes Dokument

Der Superadmin muss einen bereits ausserhalb der Anwendung abgeschlossenen Vertrag erfassen können. Dafür gelten mindestens folgende Anforderungen:

  • signiertes Dokument hochladen
  • Vertragsversion auswählen oder erfassen
  • Abschlussdatum und unterzeichnende Person erfassen
  • Funktion und bestätigte Vertretungsberechtigung dokumentieren
  • Abschlussart signed_document
  • Prüfer und Prüfzeitpunkt protokollieren
  • Originaldatei unverändert und zugriffsgeschützt speichern
  • erst nach erfolgreicher Erfassung die Produkteinladung freigeben

Upload und Prüfung sind getrennte und auditierte Aktionen. In V1 darf dieselbe Superadmin-Person beide Aktionen durchführen; ein verpflichtendes Vier-Augen-Prinzip besteht nicht.

Versionierung und Unterauftragnehmer

  • Abgeschlossene Vertragsversionen bleiben unveränderlich erhalten.
  • Wesentliche Vertragsänderungen erzeugen eine neue Version und können eine erneute Annahme erfordern.
  • Redaktionelle Änderungen dürfen keine bestehende Vertragsversion überschreiben.
  • Vertragsstatus sind pending_acceptance, pending_review, accepted, rejected, superseded und terminated.
  • Nur accepted gilt als aktueller gültiger Nachweis und erlaubt die Tenant-Admin-Einladung.
  • superseded bedeutet, dass eine Version durch eine neuere akzeptierte Vertragsversion ersetzt wurde. Sie bleibt unveränderlich als historischer Nachweis erhalten.
  • Eine bisherige akzeptierte Version wird erst dann superseded, wenn die neue Version erfolgreich akzeptiert wurde.
  • Eine allgemeine Genehmigung von Unterauftragnehmern kann vorgesehen werden.
  • Änderungen der Unterauftragnehmerliste werden vor Einsatz angekündigt; Widerspruchsfrist und Folgen eines Widerspruchs sind vertraglich festzulegen.

Konsequenzen

  • Der bisherige kombinierte Vorgang „Tenant anlegen und Einladung senden“ muss fachlich und technisch getrennt werden.
  • Das Tenant-Statusmodell benötigt eine eindeutige Abbildung von contract_pending und onboarding; die konkrete Prisma-Modellierung wird im Datenmodellentscheid festgelegt.
  • Vertragsversionen, Nachweise und Dokumente benötigen ein revisionssicheres Datenmodell und eine kontrollierte Ablage.
  • Backend, OpenAPI-Spezifikation, Superadmin-Frontend, Auditierung und Tests müssen ergänzt werden.
  • Ohne akzeptierten beziehungsweise kontrolliert erfassten Vertrag muss jeder Versuch einer Tenant-Admin-Einladung serverseitig abgewiesen werden.

Umsetzungsstand

Teil Status
Fachentscheid und Datenschutzrollen Umgesetzt
Modulare Vertragsvorlage als Arbeitsentwurf Umgesetzt
Juristische Prüfung und Produktivfreigabe Offen
Prisma-Datenmodell und Migration Offen
Backend und serverseitige Sperren Offen
OpenAPI-Spezifikation Offen
Elektronischer Abschluss Offen
Upload und Kontrolle extern unterzeichneter Dokumente Offen
Superadmin-Frontend Offen
Automatisierte Tests Offen

Rechtsgrundlagen und Referenzen

Verwandte ADRs

  • ADR-011: Globale Benutzeridentität und E-Mail-Eindeutigkeit
  • ADR-012: Row-Level-Security-Implementierung für Supabase und generisches PostgreSQL (vorgeschlagen)
  • ADR-016: Hostpoint als E-Mail-Provider