DiveLogix360 — Produkt-Roadmap & Versions-Backlog¶
Stand: 12.08.2026 16:55 Branch: main Status: Vertraulich | Internes Arbeitsdokument
| Datum, Uhrzeit | Version | Änderung | Autor |
|---|---|---|---|
| 12.08.2026 16:55 | 2.2 | Operative Aufgabenliste durch strategische Meilensteine und Prioritäten ersetzt | Codex |
| 09.08.2026 14:41 | 2.1 | Prisma-v4-Zielschema und ergänzende UC00-Modellgruppen in V1-Scope und nächste Schritte übernommen | Codex |
| 09.08.2026 13:43 | 2.0 | Schemaangaben als Produktscope statt Fertigmeldung präzisiert und nächste UC00-Schritte auf Zielmodellkonsolidierung ausgerichtet | Codex |
| 08.08.2026 14:43 | 1.9 | DSFA-Schwellenprüfung je Use Case ab V1 und vollständige Folgenabschätzung bei erreichtem Hochrisiko-Schwellenwert festgelegt | Codex |
| 06.08.2026 19:08 | 1.8 | ADR-015 übernommen: Auftragsverarbeitungsvertrag vor Tenant-Admin-Einladung; elektronischer Abschluss und Upload externer Vereinbarungen vorgesehen | Codex |
| 06.08.2026 18:42 | 1.7 | ADR-011 als V1-Einschränkung und user_tenant_memberships als V2-Zielmodell ergänzt |
Codex |
| 01.08.2026 14:55 | 1.6 | Kopfbereich vereinheitlicht | David Mittig |
| 01.08.2026 | 1.6 | UC00 Schritt 4 Backend-Business-Logik implementiert und in main gepusht; NestJS-Backend-Grundstruktur auf Erledigt gesetzt; UC00 Schritt 4–7 auf In Bearbeitung gesetzt; Stand und Version aktualisiert |
David Mittig |
| Mai 2026 | 1.5 | Kapitel 2.2 als echte Markdown-Tabelle korrigiert; Status- und Hinweis-Spalten ergänzt | David Mittig |
| Mai 2026 | 1.4 | UC18 Equipment-Verleih als V2-Erweiterung ergänzt; Verleih-Schemaobjekte vorbereitet; Bezug zu UC01 Equipment-Core dokumentiert | David Mittig |
| Mai 2026 | 1.3 | Füll-Abo & Füllkarten-Verwaltung als UC03 in Version 1 aufgenommen; nachfolgende UC in Version 1 und Version 2 neu nummeriert; UC06+ auf UC07+ angepasst | David Mittig |
| April 2026 | 1.2 | Fehlende Einleitungstexte in 1.2, 1.3, 2.1, 2.2, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0 ergänzt; Hinweis-Satz 7.3 vervollständigt (SEV 108+); Quellenangaben 8.1–8.3 mit vollständigen Hinweistexten ergänzt | David Mittig |
| April 2026 | 1.1 | Konvertierung zu Markdown; UC00 Status aktualisiert; Nächste Schritte aktualisiert; Kunden-Vorentscheide + Mitarbeiter-Einladungsmodell in 5.1 ergänzt; organizations in 3.2 ergänzt; V2-Vorbereitung customers.organization_id in 3.3 ergänzt; Designprinzip keine Gendersprache ergänzt |
David Mittig |
| April 2026 | 1.0 | Initiale Version (aus DiveLogix360_Roadmap.docx konvertiert) | David Mittig |
Märkte: DE | CH | AT
Inhaltsverzeichnis¶
- Projektübersicht
- Version 1 — MVP
- Version 2 — Erweiterungen
- Version 3 — Vision
- Offene Entscheide & Designprinzipien
- Meilensteine und Prioritäten
- Rechtsgrundlagen & Datenschutz-Compliance
- Quellenverzeichnis
1. Projektübersicht¶
DiveLogix360 ist eine mandantenfähige SaaS-Plattform für Tauchschulen im DACH-Raum. Sie digitalisiert die Verwaltung von TÜV-Inspektionen (Druckluftflaschen nach EN 1802/EN 1968), Inhouse-Services (Regler, Jacket) und bietet Endkunden ein Tracking-Portal für ihre eigene Ausrüstung.
1.1 Geschäftsmodell¶
Direkte SaaS-Kunden (Tenants) sind Tauchschulen. Endkunden (Taucher) erhalten über Modell B ein read-only Kundenportal als Mehrwertleistung der Tauchschule.
1.2 Akteurs-Modell (Modell B)¶
Das Akteurs-Modell definiert vier Rollen auf drei Ebenen. Die Tabellenbeschriftung folgt dem Schema Kapitel-Nr. + laufende Tabellennummer.
| Ebene | Rolle | Technisch | Beschreibung |
|---|---|---|---|
| Plattform | Betreiber | superadmin |
Plattform-Administration — verwaltet alle Tenants, System-Logs |
| Tenant | Schulinhaber | tenant_admin |
Verwaltet Mitarbeiter, Kunden, Berichte, DSGVO |
| Tenant | Mitarbeiter | mitarbeiter |
Erfasst Equipment, Workflows, Prüfergebnisse |
| Portal | Taucher | kunde |
Sieht eigene Flaschen/Regler, TÜV-Termine (read-only) |
1.3 Architektur-Prinzipien¶
DiveLogix360 ist nach folgenden Kernprinzipien gebaut, die alle technischen Entscheide leiten:
| Prinzip | Beschreibung |
|---|---|
| Offline-First | Alle Kernfunktionen funktionieren ohne Internetverbindung (Lageräume, Keller). Eine abstrakte SyncEngine synchronisiert Änderungen beim nächsten Online-Gang: Phase 1 via Timestamp-Strategie, Phase 2 via CRDT (Electric SQL, einhängbar ohne Schema-Änderung). |
| Mobile First / PWA | Die App ist als Progressive Web App (PWA) konzipiert — kein App-Store-Install nötig. Touch-optimiert, min. 44×44px Tap-Targets. Nutzung direkt am Equipment und in Lageräumen. |
| Multi-Tenancy via RLS | Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) in PostgreSQL soll sicherstellen, dass jeder Tenant ausschliesslich seine eigenen Daten sieht. Tenant-übergreifender Zugriff bleibt technisch dem Superadmin vorbehalten. |
| Modularität | Core (Tenant, Kunden, Equipment) + aktivierbare UseCase-Module. Jedes Modul ist einzeln lizenzierbar. Ein neues Modul verändert den Core nie. |
| URL-Sicherheit | Keine sequenziellen IDs in URLs. Alle Ressourcen werden über nicht erratbare UUIDs angesprochen (z.B. /equipment/a3f9b2c1 statt /equipment?id=17). |
| DSGVO by Design | Pseudonymisierung, Aufbewahrungsfristen und Auditierung werden im freigegebenen Zielmodell und in der Implementierung von Anfang an verankert. |
2. Version 1 — MVP¶
Version 1 liefert die Kernfunktionalität für den Tauchschul-Alltag. Das formal validierte Prisma-v4-Zielschema berücksichtigt erforderliche Erweiterbarkeit für V2 und V3; Migration und Implementierung sind noch nicht abgeschlossen. Das UI bleibt auf den V1-Umfang fokussiert.
2.1 Use Cases Version 1¶
Die folgende Tabelle zeigt alle Use Cases der ersten Version. Die Spalte Zielgruppe beschreibt wer den UC nutzt (Tauchschule, Taucher-Portal, Tauchschule + Taucher oder Plattform-Administration). Die Spalte Reifegrad V1 zeigt ob die Funktionalität vollständig implementiert wird oder in V1 vereinfacht bleibt und erst in V2 vollständig konfigurierbar ist.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad V1 | Status |
|---|---|---|---|---|---|
| UC00 | Tenant-Onboarding & Schulverwaltung | Superadmin, Tenant-Admin | Plattform-Administration | Vollständig | 🟡 In Bearbeitung |
| UC01 | Equipment erfassen | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC02 | TÜV-Inspektion einreichen (ext.) | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC03 | Füll-Abo & Füllkarten-Verwaltung | Tenant-Admin, Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC04 | Inhouse-Service erfassen | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC05 | Fristen-Dashboard | Tenant-Admin, Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC06 | Kunden einladen & Portal | Tenant-Admin, Taucher | Taucher-Portal | Vollständig | ⛹ Offen |
| UC07 | Benachrichtigungen (Fristen) | System, Taucher | Tauchschule + Taucher | Vereinfacht | ⛹ Offen |
| UC08 | Benutzerverwaltung | Tenant-Admin | Tauchschule | Vollständig | ⛹ Offen |
| UC09 | Berichte & Export | Tenant-Admin | Tauchschule | Vereinfacht | ⛹ Offen |
| UC-SA | Superadmin-Panel | Superadmin | Plattform-Administration | Vollständig | ⛹ Offen |
2.2 Schema-Tabellen Version 1¶
Die Tabelle beschreibt den vorgesehenen V1-Produktscope des Prisma-v4-Zielschemas. GREEN bezeichnet für V1 benötigte Fachobjekte und ist kein Implementierungs-, Migrations- oder Testnachweis. AMBER kennzeichnet Fachobjekte, deren Oberfläche erst in Version 2 vollständig konfigurierbar wird. Die vollständige technische Feldstruktur steht im Prisma-Schema; zusammengehörige UC00-Tabellen sind hier platzsparend gruppiert.
| Tabelle | Version | Status | Beschreibung | Hinweis |
|---|---|---|---|---|
tenants |
V1 | GREEN | Mandanten-Stammdaten, Plan-Typ, Land, Adresse | |
users |
V1 | GREEN | Benutzer (tenant_admin, mitarbeiter, kunde), 2FA | |
tenant_profiles |
V1 | GREEN | Operatives Schulprofil getrennt von rechtlichen Vertragsdaten | |
tenant_onboardings, onboarding_steps |
V1 | GREEN | Persistentes Vier-Schritt-Onboarding mit Draft-Wiederaufnahme | |
tenant_contracts, contract_acceptance_tokens, contract_documents |
V1 | GREEN | Vertragsversionen, Abschlusswege, Token und PDF-Metadaten | PDF-Inhalt liegt im privaten Objektspeicher |
tenant_offboardings, tenant_exports |
V1 | GREEN | Sperrung, Exportphase und operative Löschung | |
legal_holds, retention_runs |
V1 | GREEN | Begründete Aufbewahrungssperren und kontrollierte Löschläufe | |
two_factor_sessions, recovery_codes, refresh_tokens |
V1 | GREEN | Kurzlebige 2FA-Sitzungen, Wiederherstellung und Sitzungsrotation | Geheimnisse nur gehasht beziehungsweise verschlüsselt |
support_access_grants |
V1 | GREEN | Zeitbegrenzte Support- und Notfallzugriffe | Produktiver Einsatz erst nach Nachweisen |
audit_seals |
V1 | GREEN | Tägliche kryptografische Sammelnachweise | Objekt im privaten Objektspeicher |
customers |
V1 | GREEN | Kunden der Tauchschule, DSGVO-Felder | |
equipment |
V1 | GREEN | Alle Gerätetypen (Flasche, Regler, BCD, ...) | |
cylinder_details |
V1 | GREEN | TÜV-Details: EN 1802/EN 1968, DGUV, SVTI | |
regulator_details |
V1 | GREEN | Regler-Service-Details, Intervall | |
usecase_workflows |
V1 | GREEN | TÜV-Workflow, Inspektion, Inhouse-Service | |
workflow_history |
V1 | GREEN | Statusverlauf je Workflow (append-only) | |
invitation_tokens |
V1 | GREEN | Tenant-Admin-, Mitarbeiter- und Kundenportal-Einladungen | |
notification_rules |
V1 | AMBER | Mehrstufige Benachrichtigungsregeln | UI erst in V2 vollständig konfigurierbar |
notification_log |
V1 | GREEN | Verhindert doppelte Benachrichtigungen | |
sync_queue |
V1 | AMBER | Offline-Sync, Konfliktmanagement (Vector Clock) | UI erst in V2 vollständig konfigurierbar |
audit_log |
V1 | GREEN | Vollständiges Änderungsprotokoll (DSGVO) | |
access_log |
V1 | GREEN | Zugriffsprotokoll auf Entitäten | |
auth_log |
V1 | GREEN | Login / 2FA-Ereignisse | |
customer_activity_log |
V1 | GREEN | Kundenportal-Aktivitäten | |
deletion_log |
V1 | GREEN | DSGVO-Löschprotokoll | |
system_log |
V1 | GREEN | Systemereignisse, Fehler, Warnungen |
2.3 Bewusste V1-Einschränkungen (UI)¶
notification_rules: Schema ist mehrstufig — UI zeigt nur 1 Standardregel pro Tenant (30 Tage, E-Mail)- Taucher kann Kontaktdaten lesen, aber nicht selbst ändern (Änderungsantrag kommt in V2)
- Kein Multi-Schule-Support für Endkunden (1 Taucher = 1 Schule in V1)
- Kein Multi-Tenant-Support für Benutzerkonten: Eine globale Benutzeridentität gehört in V1 höchstens einem Tenant an (ADR-011)
- Berichte: einfacher PDF-Export, kein konfigurierbarer Reportgenerator
- Benachrichtigungen: nur E-Mail-Kanal, kein Push
- Logo/Branding: noch nicht in V1 — kommt in V2 (ev. als separates Preismodell)
- Eigene Equipment-Typen: in V1 fixer Katalog — Erweiterung in V2
- Sprache: in V1 nur DE — Mehrsprachigkeit in V2
- Tenant-Onboarding: in V1 manuell durch Superadmin — Self-Service in V2
3. Version 2 — Erweiterungen¶
Version 2 öffnet die im V1-Schema bereits vorbereiteten Flexibilitätspunkte für das UI und fügt neue Verkaufsargumente hinzu. Die V1-Einschränkungen werden schrittweise aufgehoben.
3.1 Use Cases Version 2¶
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC00+ | Self-Service-Registrierung (Tenant) | Tauchschule (neu) | Plattform-Administration | V2 |
| UC07+ | Konfigurierbares Benachrichtigungssystem | Tenant-Admin | Tauchschule | V2 |
| UC10 | Kontaktdaten-Änderungsantrag (Taucher) | Taucher, Tenant-Admin | Taucher-Portal | V2 |
| UC11 | Erweiterter Bericht & Exportkonfigurator | Tenant-Admin | Tauchschule | V2 |
| UC12 | Push-Benachrichtigungen | System, Taucher | Tauchschule + Taucher | V2 |
| UC13 | Dokument-Upload (Prüfzertifikate) | Mitarbeiter | Tauchschule | V2 |
| UC14 | Taucher bei mehreren Schulen | Taucher | Taucher-Portal | V2 |
| UC15 | Logo & Branding je Tenant | Tenant-Admin | Tauchschule | V2 |
| UC16 | Eigene Equipment-Typen verwalten | Tenant-Admin | Tauchschule | V2 |
| UC17 | Mehrsprachigkeit (FR, EN) | System | Tauchschule + Taucher | V2 |
| UC18 | Equipment-Verleih | Tenant-Admin, Mitarbeiter | Tauchschule | V2 |
UC18 – Equipment-Verleih¶
UC18 ist als optionales V2-Zusatzmodul vorgesehen und setzt fachlich auf UC01 Equipment erfassen auf. Nur erfasstes, aktives, vollständiges und nicht gesperrtes Equipment darf verliehen werden. Das Modul umfasst Ausgabe, Rückgabe, Verfügbarkeit, Zustand bei Ausgabe und Rückgabe, QR-Code-Nutzung, Historie, überfällige Rückgaben und spätere Berichte.
3.2 Neue Schema-Objekte V2¶
| Feature / Tabelle | Version | Beschreibung |
|---|---|---|
customer_tenant_map |
V2 | Erlaubt 1 Taucher bei mehreren Schulen (heute: tenant_id auf users) |
user_tenant_memberships |
V2 | Ordnet eine globale Benutzeridentität mehreren Tenants mit tenantbezogener Rolle und tenantbezogenem Status zu (ADR-011) |
documents |
V2 | Prüfzertifikate, Fotos je Equipment oder Workflow |
change_requests |
V2 | 4-Augen-Prinzip: Taucher beantragt Änderung, Tenant-Admin bestätigt |
push_tokens |
V2 | Push-Notification-Tokens je Gerät (iOS, Android) |
registration_requests |
V2 | Self-Service-Onboarding: neue Tauchschulen beantragen Zugang |
organizations |
V2 | Firmen/Vereine als optionale Gruppierung von Kunden (siehe uc-kunden-vorentscheide.md) |
rental_transactions |
V2 | Verleihvorgänge mit Kunde, Ausgabe, geplanter Rückgabe und Status |
rental_items |
V2 | Einzelne verliehene Equipment-Datensätze je Verleihvorgang |
rental_condition_logs |
V2 | Zustand, Foto und Notiz bei Ausgabe und Rückgabe |
3.3 Schema-Entscheide die V2 bereits vorbereiten¶
users.tenant_idbleibt in V1 —customer_tenant_mapkommt in V2 dazu (keine Migration nötig)users.emailbleibt in V1 global eindeutig; eine spätere Mehrfachzugehörigkeit wird überuser_tenant_membershipsstatt über doppelte Benutzerkonten modelliert (ADR-011)notification_rulesist bereits mehrstufig modelliert — V2 öffnet nur das UIequipment.custom_data(JSONB) erlaubt neue Equipment-Typen ohne Schema-Migrationtenants.logo_pathist im Schema vorhanden, wird in V1 nicht befülltcustomers.organization_idist in V1 bereits als nullable FK vorbereitet — V2 aktiviert die Logik (siehedocs/developer/uc-vorentscheide/uc-kunden-vorentscheide.md)- UC18 nutzt den Equipment-Core aus UC01 und ergänzt Verleih-, Zustands- und Historientabellen, ohne den Equipment-Core zu verändern
4. Version 3 — Vision¶
Version 3 realisiert das Modell C (aktiver Taucher) und öffnet die Plattform für tiefere Integrationen mit Prüfstellen und Zahlungsanbietern.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC-C1 | Taucher reicht Inspektion selbst ein | Taucher | Taucher-Portal | V3 |
| UC-C2 | Taucher lädt Dokumente hoch | Taucher | Taucher-Portal | V3 |
| UC-C3 | Direktzahlung / Rechnungsstellung | Taucher, Tenant-Admin | Tauchschule + Taucher | V3 |
| UC-C4 | API für Prüfstellen-Integration (SVTI) | Extern | Plattform-Administration | V3 |
| UC-C5 | White-Label / eigene Domain je Schule | Tenant-Admin | Tauchschule | V3 |
5. Offene Entscheide & Designprinzipien¶
5.1 Geklärt¶
- Tauchschule als externer Kunde: wird als normaler Kundendatensatz erfasst — kein Sonderfall im Schema
- Taucher-Registrierung V1: Einladung per E-Mail-Token durch die Schule (nicht Self-Registration)
- Kontaktdaten V1: read-only für Taucher — Schule pflegt Daten; Änderungsantrag kommt in V2
- Benachrichtigungszeitraum: flexibel und mehrstufig konfigurierbar pro Equipment-Typ
- Externe TÜV-Inspektion: Tauchschule reicht ein, externe Prüfstelle führt Prüfung durch
- Füll-Abo & Füllkarten-Verwaltung: V1-Use-Case für Abo pro Kunde, gasmix-abhängige Verbrauchserfassung und tenant-konfigurierbare Preise
- Inhouse-Service: Regler und Jacket werden von der Schule selbst gewartet und erfasst
- Prüfintervalle: Tenant-Admin kann eigene Intervalle je Equipment-Typ festlegen (V1)
- Standard-Währung: Tenant-Admin setzt CHF oder EUR pro Tenant (V1)
- Tenant-Onboarding V1: manuell durch Superadmin — Self-Service in V2
- Billing: komplett ausserhalb der App (Stripe oder manuelle Rechnung) — MwSt-Nr. im Schulprofil
- Mitarbeiter-Einladungsmodell: via Einladungslink (analog UC00 Modell C1) — Details in UC-Mitarbeiter
- Kunden V1: Kunde = Person (Szenario A) — Organisations-Zuordnung optional in V2 (Szenario C)
- Equipment-Verleih: wird als UC18 in V2 aufgenommen und als eigenes optionales Modul auf Basis von UC01 umgesetzt
5.2 Noch offen¶
- Preismodell: Starter / Professional / Enterprise — genaue Feature-Grenzen definieren
- Offline-Modus: welche Aktionen sind ohne Internet möglich? (
sync_queueist vorbereitet) - Sprachen: DE + CH-DE zum Start — wann kommt FR/EN?
- UC18: genauer V2-Umfang für Preislogik, Kaution, Unterschrift, Etikettendruck und Verleihberichte
5.3 Designprinzipien¶
- Schema-forward, UI-minimal: das DB-Design denkt 3 Versionen voraus, das UI liefert V1 fokussiert
- Keine Breaking Changes: neue Features erweitern das Schema (neue Tabellen/Spalten), nie umbauend
- DSGVO by Design: Pseudonymisierung, Löschfristen und Audit sind von Anfang an eingebaut
- Normenkonformität: EN 1802, EN 1968, DGUV, SVTI sind im Schema direkt referenzierbar
- Versionen als Verkaufsargument: Kunden kaufen V1, wissen dass V2 kommt — reduziert Churn
- Keine Gendersprache: klassische deutsche Rechtschreibung in der gesamten Applikation
6. Meilensteine und Prioritäten¶
Die Roadmap führt strategische Meilensteine und ihre Reihenfolge. Operative Aufgaben, Teilnachweise und tagesaktuelle Bearbeitungsstände stehen ausschliesslich im Projektstatus.
| Meilenstein | Ziel | Priorität | Einordnung |
|---|---|---|---|
| M1 – UC00-Grundlage vervollständigen | Tenant-Onboarding fachlich, technisch und sicherheitlich als tragfähige V1-Basis abschliessen | Hoch | In Bearbeitung |
| M2 – UC00 abnehmen | Frontend, Integrations- und Sicherheitstests, Infrastruktur sowie externe und formelle Freigaben nachweisen | Hoch | Offen |
| M3 – V1-Kernprozesse implementieren | Equipment, Prüfungen, Füll-Abos, Inhouse-Service und Fristen auf der freigegebenen Plattformbasis umsetzen | Hoch | Offen |
| M4 – V1-Portal und Administration implementieren | Kundenportal, Benachrichtigungen, Benutzerverwaltung, Berichte und Superadmin-Funktionen umsetzen | Hoch | Offen |
| M5 – V1 produktionsbereit machen | Gesamtintegration, Datenschutz, Betrieb, Monitoring, Wiederherstellung, Abnahme und Go-live-Vorbereitung abschliessen | Hoch | Offen |
| M6 – V2 vorbereiten | Erweiterungsfelder einschliesslich Equipment-Verleih nach V1-Prioritäten und Geschäftsmodell planen | Mittel | Backlog |
| M7 – Produkt- und Preismodell schärfen | Grenzen und Leistungen für Starter, Professional und Enterprise verbindlich definieren | Mittel | Backlog |
Ein Meilensteinstatus ist eine strategische Einordnung und ersetzt keinen technischen Fertigstellungs- oder Testnachweis. Die Detailkriterien werden im Projektstatus und in den Use-Case-Abschlusschecklisten geführt.
7. Rechtsgrundlagen & Datenschutz-Compliance¶
DiveLogix360 verarbeitet Personendaten von Tauchern und Mitarbeitenden der Tauchschulen. Damit unterliegt die Plattform einem komplexen Rechtsrahmen aus Schweizer und EU-Datenschutzrecht sowie branchenspezifischen Normen. Dieses Kapitel dokumentiert die relevanten Rechtsgrundlagen und leitet daraus konkrete Anforderungen für das Produkt ab.
7.1 Schweizer Datenschutzrecht (nDSG / DSV / VDSZ)¶
Das neue Schweizer Bundesgesetz über den Datenschutz (nDSG), die Datenschutzverordnung (DSV) sowie die Verordnung über Datenschutzzertifizierungen (VDSZ) sind am 1. September 2023 in Kraft getreten. Mit der Totalrevision wird das Datenschutzrecht den veränderten technologischen und gesellschaftlichen Verhältnissen angepasst. Es wurden keine gesetzlichen Übergangsfristen vorgesehen — alle Pflichten gelten sofort.
Das nDSG annähert die Schweizer Datenschutzgesetzgebung an die EU-Datenschutzgrundverordnung (EU-DSGVO 2016/679), ist aber kein 1:1-Abbild. Der pragmatischere Schweizer Ansatz bleibt erhalten: Datenbearbeitung ist grundsätzlich erlaubt, sofern die Grundprinzipien eingehalten werden (Art. 6 nDSG) — anders als in der EU, wo ein expliziter Erlaubnisgrund benötigt wird.
7.2 Kernpflichten für DiveLogix360¶
Als SaaS-Betreiber ist DiveLogix360 sowohl Verantwortlicher (für eigene Daten) als auch Auftragsbearbeiter (für Daten der Tauchschulen). Daraus ergeben sich folgende Pflichten:
| Pflicht | Rechtsgrundlage | Umsetzung in DiveLogix360 |
|---|---|---|
| Bearbeitungsverzeichnis führen | Art. 12 nDSG i.V.m. Art. 4–6 DSV | audit_log + deletion_log dokumentieren alle Datenbearbeitungen |
| Privacy by Design & Default | Art. 7 nDSG | DSGVO-Felder, Pseudonymisierung und Löschfristen sind von Anfang an im Schema eingebaut |
| Informationspflicht (Datenschutzerklärung) | Art. 19 nDSG, Art. 13 DSV | Datenschutzerklärung auf divelogix360.ch; je Tenant bei Kundenerfassung |
| Datensicherheit (TOM) | Art. 8 nDSG, Art. 1–3 DSV | RLS, 2FA, Audit-Log, verschlüsselte Übertragung (TLS), Supabase EU-Hosting |
| Meldepflicht bei Datenschutzverletzung | Art. 24 nDSG | system_log + Eskalationsprozess an EDÖB bei hohem Risiko |
| Betroffenenrechte (Auskunft, Löschung) | Art. 25–27 nDSG | deletion_log, customer.pseudonymized, gdpr_consent-Felder |
| Auftragsverarbeitungsvertrag beziehungsweise Auftragsbearbeitungsvereinbarung | Art. 9 nDSG / Art. 28 DSGVO | Abschluss mit jeder Tauchschule vor Tenant-Admin-Einladung; elektronisch oder als kontrolliert hochgeladenes, extern unterzeichnetes Dokument (ADR-015) |
| Bekanntgabe ins Ausland | Art. 16–17 nDSG | Supabase EU-Region (Frankfurt/Dublin) — keine Drittstaatenübermittlung |
7.3 Verhältnis nDSG – EU-DSGVO – BDSG¶
Da DiveLogix360 den DACH-Markt (DE, CH, AT) bedient, gilt ein dreifacher Rechtsrahmen je nach Standort des Tenants:
| Markt | Anwendbares Recht | Besonderheiten für DiveLogix360 |
|---|---|---|
| CH (Schweiz) | nDSG / DSV / VDSZ | Erlaubnis mit Verbotsvorbehalt; pragmatischer; AVV Pflicht; EDÖB als Aufsicht |
| DE (Deutschland) | EU-DSGVO + BDSG | Verbot mit Erlaubnisvorbehalt; strenger; Einwilligung oder Vertrag nötig; BfDI/LfDI |
| AT (Österreich) | EU-DSGVO + DSG AT | Wie DE; Datenschutzbehörde (Österreich) als Aufsicht |
Hinweis: Da die Schweiz von der EU als Drittstaat mit angemessenem Datenschutzniveau anerkannt ist (Angemessenheitsbeschluss), ist die grenzüberschreitende Datenübermittlung CH ↔ EU ohne zusätzliche Garantien zulässig. Diese Anerkennung basiert u.a. auf der Ratifizierung des modernisierten Datenschutzübereinkommens SEV 108+ des Europarats (2023).
7.4 Branchenspezifische Normen¶
Zusätzlich zum Datenschutzrecht unterliegt DiveLogix360 technischen Normen für die TÜV-Inspektion von Druckgeräten:
| Norm | Relevanz für DiveLogix360 |
|---|---|
| EN 1802:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Aluminium — Prüffristen und Dokumentationspflichten |
| EN 1968:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Stahl — Prüffristen und Dokumentationspflichten |
| DGUV (DE) | Deutsche Unfall-verhütungsvorschriften für Druckgeräte im Tauchbereich — gilt für DE-Tenants |
| SVTI (CH) | Schweizerischer Verein für technische Inspektionen — zugelassene Prüfstelle in der Schweiz |
7.5 Datenschutz-Roadmap¶
Folgende datenschutzrechtliche Massnahmen sind als Teil der Produktentwicklung umzusetzen:
| # | Massnahme | Version | Rechtsgrundlage |
|---|---|---|---|
| 1 | Datenschutzerklärung für divelogix360.ch erstellen | V1 | Art. 19 nDSG / Art. 13 DSGVO |
| 2 | Auftragsverarbeitungsvertrag je Tenant vor Tenant-Admin-Einladung; elektronischer oder externer Abschlussweg | V1 | Art. 9 nDSG / Art. 28 DSGVO; ADR-015 |
| 3 | Bearbeitungsverzeichnis aufsetzen (intern für DiveLogix360) | V1 | Art. 12 nDSG / Art. 30 DSGVO |
| 4 | RLS + 2FA + TLS — technische Schutzmassnahmen (TOM) | V1 | Art. 8 nDSG / Art. 25 DSGVO |
| 5 | GDPR-Consent-Flow für Kundenerfassung durch Tauchschule | V1 | Art. 19 nDSG |
| 6 | Schwellenprüfung für eine Datenschutz-Folgenabschätzung je Use Case; vollständige DSFA vor Hochrisiko-Bearbeitungen | V1 fortlaufend | Art. 22 DSG / Art. 35 DSGVO |
| 7 | ISO 27001-Zertifizierung anstreben (ab Enterprise-Tier) | V3 | VDSZ / Art. 7 nDSG |
8. Quellenverzeichnis¶
Die nachfolgenden Quellen bilden die Grundlage für die in diesem Dokument enthaltenen Aussagen zu Rechtsgrundlagen, technischen Normen und strategischen Entscheiden.
8.1 Schweizer Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [1] | nDSG — Bundesgesetz über den Datenschutz (revidiert) | fedlex.admin.ch/eli/cc/2022/491/de — in Kraft seit 1. September 2023 |
| [2] | DSV — Datenschutzverordnung | fedlex.admin.ch/eli/cc/2022/568/de — Ausführungsbestimmungen zum nDSG |
| [3] | VDSZ — Verordnung über Datenschutzzertifizierungen | fedlex.admin.ch — Zertifizierungsrahmen für Datenbearbeitungen |
| [4] | Neues Datenschutzgesetz DSG (Strategie Digitale Schweiz) | digital.swiss/de/aktionsplan/massnahme/neues-datenschutzgesetz-ndsg |
| [5] | KMU-Portal Bund: Neues Datenschutzgesetz (revDSG) | kmu.admin.ch — Bundesamt für Justiz, Bern |
| [6] | Übersicht zum neuen Datenschutzgesetz | economiesuisse.ch/de/artikel/datenschutz-eine-uebersicht-zum-neuen-gesetz |
8.2 EU-Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [7] | EU-DSGVO 2016/679 — Datenschutz-Grundverordnung | eur-lex.europa.eu — in Kraft seit 25. Mai 2018 |
| [8] | BDSG — Bundesdatenschutzgesetz (Deutschland) | gesetze-im-internet.de/bdsg_2018 — gilt für DE-Tenants |
| [9] | DSG AT — Datenschutzgesetz Österreich | ris.bka.gv.at — gilt für AT-Tenants |
8.3 Technische Normen (TÜV / Druckgeräte)¶
| Nr. | Titel | Quelle |
|---|---|---|
| [10] | EN 1802:2002 — Nahtlose Aluminiumflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Aluminium |
| [11] | EN 1968:2002 — Nahtlose Stahlflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Stahl |
| [12] | DGUV — Deutsche Gesetzliche Unfallversicherung | dguv.de — Vorschriften für Druckgeräte im Tauchbereich |
| [13] | SVTI — Schweizerischer Verein für technische Inspektionen | svti.ch — Zugelassene Prüfstelle CH für Druckbehälter |
8.4 Technische Grundlagen¶
| Nr. | Titel | Quelle |
|---|---|---|
| [14] | Supabase — PostgreSQL-Datenbankplattform | supabase.com |
| [15] | PostgreSQL Row Level Security (RLS) | postgresql.org/docs/current/ddl-rowsecurity.html |
| [16] | NestJS — Node.js Backend Framework | nestjs.com |
| [17] | Prisma — ORM für PostgreSQL / TypeScript | prisma.io |
| [18] | React — Frontend-Framework | react.dev |