Zum Inhalt

DiveLogix360 – UC00-Datenkatalog

Stand: 12.08.2026 16:55 Branch: main Status: Zur Prüfung

Datum, Uhrzeit Version Änderung Autor
12.08.2026 16:55 2.5 Historische UC00-OpenAPI-Quellen an neuen Nachweisort angepasst Codex
09.08.2026 14:41 2.4 Implementierungsangaben auf das formal validierte Prisma-v4-Zielschema aktualisiert Codex
09.08.2026 13:04 2.3 Vorläufige RF-03-Frist, geplanten Schweizer Einzelunternehmensrahmen und Rechtsprüfbriefing präzisiert Codex
09.08.2026 12:55 2.2 Fünf zusätzliche Schutzbereiche und verbindliches TOM-Wirksamkeitsnachweismodell ergänzt Codex
09.08.2026 12:49 2.1 Zeitbegrenzte Support-, Notfall- und Providerzugriffe sowie V1-Ländergrenze nach ADR-023 ergänzt Codex
09.08.2026 12:34 2.0 Eigenbetriebenen ClamAV-Scanservice, Signaturgrenze und ausfallsicheren Quarantäneprozess nach ADR-022 ergänzt Codex
09.08.2026 12:17 1.9 Grafana Cloud Pro Frankfurt mit Datenminimierung, deaktivierten Zusatzmodulen und Kostenkontrolle nach ADR-021 ergänzt Codex
09.08.2026 11:52 1.8 Risikobasierte Wiederherstellungsziele, Falkenstein-Backup und dauerhafte Vertragsabschlussregel nach ADR-020 ergänzt Codex
09.08.2026 11:33 1.7 Hetzner Object Storage Nürnberg und AWS KMS Frankfurt mit getrennter Schlüsselverwaltung und Produktivsperre aufgenommen Codex
08.08.2026 14:48 1.6 Revisionsfähige Vertrags- und Datenschutzauditierung mit täglichem kryptografischem Sammelnachweis festgelegt Codex
08.08.2026 14:43 1.5 DSFA-Schwellenprüfung für UC00 verknüpft und zwingende Neubewertung bei Hochrisikomerkmalen festgelegt Codex
08.08.2026 13:40 1.4 Tenant-Offboarding, Exportfenster, Reaktivierung und operative Löschung nach ADR-017 festgelegt Codex
08.08.2026 13:28 1.3 Hostpoint als V1-E-Mail-Provider ausgewählt, Produktivsperre und sichere Transportwege für vertrauliche Inhalte präzisiert Codex
08.08.2026 11:57 1.2 Speicher- und Aufbewahrungsfristen für UC00 einschliesslich Logs, Token, Verträge, E-Mail-Nachweise und Backups fachlich festgelegt Codex
08.08.2026 11:44 1.1 Technische und organisatorische Schutzanforderungen mit Uploadgrenze, Wiederherstellungszielen, Prüfintervallen und zentraler TOM-Übersicht fachlich festgelegt Codex
07.08.2026 19:45 1.0 Empfänger und Übermittlungen fachlich geprüft; Hetzner als V1-Kandidat, Resend-Ausschluss und Providerregister festgelegt Codex
07.08.2026 19:34 0.9 Protokolldaten fachlich geprüft; fünf Protokollarten, Kontexttrennung, Minimierung, Ausfallschutz und Versandnachweis festgelegt Codex
07.08.2026 19:22 0.8 Onboarding- und Schulprofildaten fachlich geprüft; Vier-Schritt-Modell, getrenntes TenantProfile und Veröffentlichungsregeln festgelegt Codex
07.08.2026 19:15 0.7 Benutzer-, Einladungs- und Authentifizierungsdaten fachlich geprüft; Aktivierungsablauf, Argon2id, Geheimnisschutz und Tokenregeln festgelegt Codex
07.08.2026 18:57 0.6 Vertragsnachweisfelder fachlich geprüft; einheitliches PDF-Modell, Status, Tokenfrist, Parteiensnapshot und Prüfprozess festgelegt Codex
07.08.2026 18:42 0.5 Tenant- und Geschäftskontaktfelder fachlich geprüft; drei Kontaktrollen und Veröffentlichungsregeln verbindlich getrennt Codex
07.08.2026 18:38 0.4 Vollständige rechtliche Bezeichnung und Vertragsanschrift als AVV-Voraussetzung ergänzt; Schweizer Schreibweise bereinigt Codex
07.08.2026 18:26 0.3 Geltungsbereich, Rollenmodell und Verarbeitungstätigkeiten fachlich geprüft; E-Mail- und Auditverarbeitung nach Verantwortlichkeit getrennt Codex
07.08.2026 18:11 0.2 PDF als V1-Format und private Vertragsablage im Objektspeicher gemäss ADR-013 verbindlich übernommen Codex
07.08.2026 18:05 0.1 Datenkatalog für UC00 aus Prisma-Schema, Spezifikation, OpenAPI-Verträgen und Datenschutzentscheidungen erstellt Codex

Zweck: Feld- und verarbeitungsbezogene Übersicht der in UC00 verarbeiteten Personen- und Unternehmensdaten.
Speicherfristen: Die verbindlichen Fristen und Löschaktionen stehen in der zentralen Fristenmatrix. Feldzellen mit dem Verweis Gemäss zentraler Fristenmatrix richten sich nach der dort zugeordneten Datenkategorie.
Rechtsprüfung: Die Zuordnung der Rechtsgrundlagen ist eine fachliche V1-Arbeitsgrundlage und muss vor Produktivbetrieb juristisch geprüft werden.

1. Geltungsbereich

Der Katalog umfasst die vorbereitende Tenant-Anlage, den Abschluss des Auftragsverarbeitungsvertrags (AVV), die Einladung des Tenant-Admins, Authentifizierung und Zwei-Faktor-Authentifizierung (2FA), das initiale Schulprofil, den E-Mail-Versand sowie die Sicherheits- und Änderungsprotokollierung.

Er dokumentiert sowohl bereits im Prisma-Schema vorhandene Felder als auch fachlich beschlossene, technisch noch nicht modellierte Vertrags- und Onboarding-Daten. Unternehmensangaben werden einbezogen, weil sie bei Einzelunternehmen oder durch Angaben zu Kontaktpersonen einen Personenbezug besitzen können.

Nicht Bestandteil sind Kunden-, Equipment-, Service- und Abrechnungsdaten späterer Use Cases.

2. Verbindliche Rollenabgrenzung

Verarbeitungskontext Tauchschule DiveLogix360 Weitere Anbieter
SaaS-Vertrag, AVV-Verwaltung, erstes Tenant-Admin-Konto, Plattformbetrieb und eigene Sicherheitszwecke Vertragspartner, Datenquelle und teilweise betroffene Organisation Verantwortlicher für eigene Zwecke Auftragsverarbeiter von DiveLogix360
Benutzer-, Mitarbeiter- und Fachdaten innerhalb eines Tenants Verantwortlicher Auftragsverarbeiter beziehungsweise in der Schweiz Auftragsbearbeiter Unterauftragsverarbeiter
Plattform- und Sicherheitsnachrichten Vertragspartner und Empfänger Verantwortlicher E-Mail-Provider als Auftragsverarbeiter von DiveLogix360
Vom Tenant angeordnete Mitarbeitereinladungen Verantwortlicher Auftragsverarbeiter/Auftragsbearbeiter E-Mail-Provider als Unterauftragsverarbeiter
Plattformweite Authentifizierung, Missbrauchsabwehr und technische Sicherheit Mitwirkender Vertragspartner Verantwortlicher Hosting- und Sicherheitsanbieter als Auftragsverarbeiter
Vertrags-, Superadmin- und Plattform-Audit Vertragspartner und teilweise Datenquelle Verantwortlicher Hosting- und Datenbankanbieter als Auftragsverarbeiter
Fachliches Audit innerhalb eines Tenants Verantwortlicher Auftragsverarbeiter/Auftragsbearbeiter Hosting- und Datenbankanbieter als Unterauftragsverarbeiter

Für Auftragsverarbeitungen bestimmt die Tauchschule die konkrete Rechtsgrundlage gegenüber den betroffenen Personen. DiveLogix360 verarbeitet diese Daten nur im Rahmen des AVV und dokumentierter Weisungen. Eigene Zwecke von DiveLogix360 werden getrennt ausgewiesen.

3. Rechtsgrundlagenmodell

Kürzel Europäische Union, Deutschland und Österreich Schweiz
EU-V Art. 6 Abs. 1 lit. b Datenschutz-Grundverordnung (DSGVO): Vertrag oder vorvertragliche Massnahmen; nur soweit die betroffene Person Vertragspartei ist Art. 6 Datenschutzgesetz (DSG): Bearbeitungsgrundsätze; gegebenenfalls Rechtfertigung durch Vertrag nach Art. 31 DSG
EU-I Art. 6 Abs. 1 lit. f DSGVO: berechtigtes Interesse, insbesondere sichere Bereitstellung, Missbrauchsabwehr und Geschäftskontakt; Interessenabwägung erforderlich Art. 6 DSG; gegebenenfalls überwiegendes privates Interesse nach Art. 31 DSG
EU-P Art. 6 Abs. 1 lit. c DSGVO: rechtliche Verpflichtung, soweit eine konkrete Nachweis- oder Aufbewahrungspflicht besteht Gesetzliche Bearbeitung beziehungsweise Aufbewahrung; konkrete Norm je Pflicht zu ergänzen
AV Art. 28 und 29 DSGVO: Verarbeitung im Auftrag; Rechtsgrundlage wird durch den Tenant als Verantwortlichen bestimmt Art. 9 DSG: Auftragsbearbeitung; Rechtfertigung und Zweck werden durch den Tenant bestimmt

EU-P darf erst nach Benennung der konkreten gesetzlichen Verpflichtung als alleinige Grundlage verwendet werden. Wo eine natürliche Kontaktperson nicht selbst Vertragspartei ist, wird für deren Geschäftskontaktdaten grundsätzlich EU-I statt EU-V angesetzt.

4. Verarbeitungstätigkeiten

ID Tätigkeit und Zweck Betroffene Personen Rolle DiveLogix360 Rechtsgrundlage Empfänger Speicherfrist
V-01 Tenant und Geschäftskontakt zur Vertragsanbahnung vorbereiten Inhaber, Vertretungs- und Kontaktpersonen Verantwortlicher EU-V oder EU-I; CH Art. 6/31 DSG Hosting/Datenbank RF-01; bei Abschluss RF-03 bis RF-05
V-02 AVV nach Prüfung vollständiger Vertragsparteidaten abschliessen, versionieren und nachweisen Unterzeichner, Vertretungsperson, Superadmin Verantwortlicher EU-V, EU-I und gegebenenfalls EU-P; CH Art. 6/31 DSG Hosting, Datenbank, Objektspeicher RF-02 bis RF-04
V-03 Erstes Tenant-Admin-Plattformkonto anlegen und einladen Tenant-Admin, einladender Superadmin Verantwortlicher EU-V oder EU-I; CH Art. 6/31 DSG Hosting, Datenbank, E-Mail-Provider RF-06, RF-07 und RF-17
V-04 Login, Sitzung, 2FA und Kontowiederherstellung absichern Plattformbenutzer Verantwortlicher für Plattform- und Missbrauchssicherheit EU-I, gegebenenfalls EU-P; CH Art. 6/8/31 DSG Hosting, Datenbank RF-06 bis RF-11
V-05 Operatives Schulprofil und Onboarding-Fortschritt speichern Tenant-Admin, Kontaktpersonen Auftragsverarbeiter/Auftragsbearbeiter AV; konkrete Rechtsgrundlage bestimmt der Tenant Hosting, Datenbank, gegebenenfalls Objektspeicher RF-05 und RF-22
V-06A Plattform- und Sicherheitsnachrichten versenden Tenant-Admin, auslösender Superadmin Verantwortlicher EU-V oder EU-I; CH Art. 6/8/31 DSG E-Mail-Provider RF-17 und RF-18
V-06B Vom Tenant angeordnete Mitarbeitereinladungen versenden Eingeladene Mitarbeiter, auslösender Tenant-Admin Auftragsverarbeiter/Auftragsbearbeiter AV; konkrete Rechtsgrundlage bestimmt der Tenant E-Mail-Provider RF-07, RF-17 und RF-18
V-07 Plattformweite Authentifizierungs-, Missbrauchs- und Sicherheitsereignisse protokollieren Benutzer, einladende und administrative Personen Verantwortlicher EU-I, gegebenenfalls EU-P; CH Art. 6/8/31 DSG Hosting, Datenbank, streng berechtigter Sicherheitszugriff RF-11 und RF-15
V-08A Vertrags-, Superadmin- und Plattformänderungen sowie administrative Zugriffe nachvollziehen Benutzer, Superadmin, Tenant-Admin Verantwortlicher EU-I, gegebenenfalls EU-P; CH Art. 6/8/31 DSG Hosting, Datenbank, streng berechtigte Prüfer RF-12 bis RF-16
V-08B Fachliche Änderungen innerhalb eines Tenants nachvollziehen Tenant-Benutzer und betroffene Personen Auftragsverarbeiter/Auftragsbearbeiter AV; konkrete Rechtsgrundlage bestimmt der Tenant Hosting, Datenbank, berechtigte Tenant-Prüfer RF-12 bis RF-16; Weisung des Tenants bleibt zu beachten

5. Feldkatalog – Tenant und Geschäftskontakt

Modell/Feld Inhalt und Personenbezug Zweck Quelle Zugriff Rechtsgrundlage Schutz Implementierung Speicherfrist
Tenant.id Technische Tenant-ID; indirekter Personenbezug Eindeutige Zuordnung System System, Superadmin, zugeordneter Tenant-Admin V-01/V-05 Intern Vorhanden Gemäss zentraler Fristenmatrix
Tenant.slug Öffentliche beziehungsweise technische Tenant-Kennung Routing und Identifikation System System, Superadmin, Tenant-Admin V-01/V-05 Intern/öffentlich je Einsatz Vorhanden Gemäss zentraler Fristenmatrix
Tenant.name Vollständige rechtliche Bezeichnung; bei Einzelunternehmen personenbezogen Eindeutige Vertragspartei und Produktzuordnung Superadmin/Tenant-Admin System, Superadmin, Tenant-Admin V-01/V-02/V-05 Intern Feld vorhanden; Pflichtprüfung vor AVV offen Gemäss zentraler Fristenmatrix
Tenant.country Sitzland Recht, Lokalisierung und Konfiguration Superadmin System, Superadmin, Tenant-Admin V-01 Intern Vorhanden Gemäss zentraler Fristenmatrix
Tenant.address, postalCode, city Strasse und Hausnummer, Postleitzahl und Ort; bei Einzelunternehmen personenbezogen Eindeutige Vertragsanschrift Superadmin/Tenant-Admin System, Superadmin, Tenant-Admin V-01/V-02 Intern Felder vorhanden; Pflichtprüfung vor AVV im Backend offen Gemäss zentraler Fristenmatrix
TenantProfile.contactPerson Operative Kontaktperson des Schulprofils Betriebskommunikation; nicht automatisch Vertragskontakt Tenant-Admin System, Superadmin, Tenant-Admin V-05 Vertraulich Im Prisma-v4-Zielschema vom Vertragskontakt getrennt; Backend offen Gemäss zentraler Fristenmatrix
TenantProfile.contactEmail Operative Kontakt-E-Mail des Schulprofils Betrieb und Schulprofil; nicht automatisch Vertragskontakt Tenant-Admin System, Superadmin, Tenant-Admin, E-Mail-Provider bei Versand V-05/V-06A Vertraulich; öffentlich nur nach Freigabe Im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
TenantProfile.contactPhoneFixed, contactPhoneMobile Operative Telefonnummern; mindestens eine beim Profilabschluss erforderlich Erreichbarkeit und Schulprofil Tenant-Admin System, Superadmin, Tenant-Admin V-05 Vertraulich; öffentlich nur nach jeweiliger Freigabe Im Prisma-v4-Zielschema vorhanden; At-least-one-Prüfung im Backend offen Gemäss zentraler Fristenmatrix
TenantProfile.contactEmailPublic, contactPhoneFixedPublic, contactPhoneMobilePublic Getrennte Freigaben für Kontakt-E-Mail, Festnetz und Mobilnummer Kontrollierte Veröffentlichung Tenant-Admin System, Tenant-Admin; öffentlich nur bei aktivem Feld V-05 Standard false; einzeln widerrufbar Im Prisma-v4-Zielschema vorhanden; Backend und Audit offen Gemäss zentraler Fristenmatrix
Tenant.vatNumber Mehrwertsteuer-/Unternehmensnummer; bei Einzelunternehmen personenbezogen Vertrag und Abrechnungsvorbereitung Superadmin/Tenant-Admin System, Superadmin, Tenant-Admin V-01 Intern Vorhanden; in V1 optional Gemäss zentraler Fristenmatrix
Schul-Logo Logo-Objekt; regelmässig kein Personenbezug Schulprofil und Darstellung Tenant-Admin System, Superadmin, Tenant-Admin, öffentlicher Abruf nach Freigabe V-05 Öffentlich nach Freigabe Nicht im Prisma-v4-Zielschema; Produktumfang V2 Gemäss zentraler Fristenmatrix
Tenant.planType, Trial-Felder und status; TenantProfile.defaultCurrency Vertrags- und Konfigurationsdaten; indirekter Personenbezug Leistungsumfang und Lifecycle Superadmin/System System, Superadmin, Tenant-Admin lesend V-01/V-05 Intern Im Prisma-v4-Zielschema mit vollständigem Lifecycle vorhanden; Backend offen Gemäss zentraler Fristenmatrix
Erstellungs-, Änderungs- und Löschmetadaten Zeitpunkte und ausführende Benutzer-IDs Nachvollziehbarkeit System System, Superadmin, berechtigte Prüfer V-07/V-08A/V-08B Vertraulich Vorhanden Gemäss zentraler Fristenmatrix

6. Feldkatalog – Vertrag und Vertragsnachweis

Diese Felder sind fachlich verbindlich vorgesehen, im aktuellen Prisma-Schema aber noch nicht als eigenes Vertragsmodell implementiert.

Geplantes Feld Inhalt Zweck Quelle Zugriff Rechtsgrundlage Schutz Implementierung Speicherfrist
contract_id Eindeutige Vertragsinstanz Zuordnung, Versionierung und Audit System System, Superadmin, berechtigter Tenant-Admin V-02 Intern In TenantContract modelliert; Backend offen Gemäss zentraler Fristenmatrix
tenant_id Zuordnung zum Tenant Vertragszuordnung System System, Superadmin, Tenant-Admin lesend nach Berechtigung V-02 Vertraulich In TenantContract modelliert; Backend offen Gemäss zentraler Fristenmatrix
status pending_acceptance, pending_review, accepted, rejected, superseded oder terminated Vertrags-Lifecycle und Einladungssperre System/Superadmin System, Superadmin, Tenant-Admin lesend V-02 Vertraulich Im Prisma-v4-Zielschema modelliert; Statuslogik offen Gemäss zentraler Fristenmatrix
Vertragsparteien-Snapshot Rechtliche Bezeichnung, Strasse, Postleitzahl, Ort und Land zum Abschlusszeitpunkt Unveränderlicher Nachweis der Vertragspartei System aus geprüftem Tenant System, Superadmin, Tenant-Admin lesend V-02 Vertraulich; unveränderlich In TenantContract modelliert; Unveränderlichkeit in Migration und Backend offen Gemäss zentraler Fristenmatrix
contract_contact_name, contract_contact_email Name und geschäftliche E-Mail des Vertragskontakts Vertragskommunikation und Ansprechpartner Superadmin/Vertragskontakt System, Superadmin, berechtigter Tenant-Admin V-01/V-02/V-06A Vertraulich In TenantContract getrennt vom operativen Tenant-Kontakt modelliert Gemäss zentraler Fristenmatrix
contract_version Version des Vertragstexts Eindeutiger Nachweis des Inhalts System System, Superadmin, Tenant-Admin V-02 Vertraulich In TenantContract modelliert; Backend offen Gemäss zentraler Fristenmatrix
conclusion_type Elektronisch oder extern unterzeichnet Nachweis des Abschlusswegs System/Superadmin System, Superadmin, Tenant-Admin V-02 Vertraulich Im Prisma-v4-Zielschema modelliert; Backend offen Gemäss zentraler Fristenmatrix
concluded_at Abschlusszeitpunkt Vertrags- und Compliance-Nachweis System/Superadmin System, Superadmin, Tenant-Admin V-02 Vertraulich Im Prisma-v4-Zielschema modelliert; Backend offen Gemäss zentraler Fristenmatrix
signatory_name, signatory_email, signatory_function Name, geschäftliche E-Mail und Funktion der unterzeichnenden Person Identifikation und Vertretungsnachweis Unterzeichner/Superadmin System, Superadmin, Tenant-Admin V-02 Vertraulich In TenantContract modelliert; Backend offen Gemäss zentraler Fristenmatrix
authority_confirmed Bestätigung der Vertretungsberechtigung Wirksamkeits- und Nachweisprüfung Unterzeichner/Superadmin System, Superadmin V-02 Vertraulich In TenantContract modelliert; Backend offen Gemäss zentraler Fristenmatrix
storage_object_key Interner Objektschlüssel der unveränderlichen PDF-Kopie für beide Abschlusswege Inhalts- und Abschlussnachweis System beziehungsweise Upload durch Superadmin System, Superadmin, Tenant-Admin lesend nach Berechtigung V-02 Streng vertraulich; kein öffentlicher URL In ContractDocument modelliert; Objektspeicherintegration offen Gemäss zentraler Fristenmatrix
document_hash, hash_algorithm SHA-256-Integritätswert und Verfahrenskennung Manipulationsnachweis System System, Superadmin, Prüfer V-02 Intern In ContractDocument modelliert; Berechnung und Prüfung offen Mindestens so lange wie Nachweis; konkret offen
document_metadata Dateiname, MIME-Typ, Grösse, Upload-Zeitpunkt Sichere Dokumentverwaltung System/Superadmin System, Superadmin V-02 Vertraulich In ContractDocument modelliert; Uploaddienst offen Gemäss zentraler Fristenmatrix
uploaded_at, uploaded_by Upload-Zeitpunkt und ausführender Superadmin beim externen Weg Upload-Nachweis System System, Superadmin, Prüfer V-02/V-08A Vertraulich In ContractDocument modelliert; Backend offen Gemäss zentraler Fristenmatrix
review_status, reviewed_at, reviewed_by Kontrollstatus, Zeitpunkt und prüfender Superadmin beim externen Weg Getrennter Kontroll- und Freigabenachweis Superadmin/System System, Superadmin, Prüfer V-02/V-08A Vertraulich In ContractDocument modelliert; dieselbe Person darf in V1 hochladen und prüfen Gemäss zentraler Fristenmatrix
acceptance_token_hash Hash des elektronischen Vertragstokens Sichere einmalige Annahme System Ausschliesslich Vertragsabschlussdienst V-02 Geheim In ContractAcceptanceToken modelliert; Erzeugung und Prüfung offen Sieben Kalendertage plus 30 Tage nach Ablauf, Verwendung oder Widerruf (RF-07)
token_expires_at, token_used_at, token_revoked_at Ablauf, Verwendung und Widerruf des Vertragstokens Token-Lifecycle und Wiederverwendungsschutz System Vertragsabschluss- und Sicherheitsdienst V-02/V-07 Vertraulich In ContractAcceptanceToken modelliert; Lifecycle-Logik offen Tokenmetadaten 30 Tage; minimiertes Sicherheitsereignis 6 Monate (RF-07/RF-11)
supersedes_contract_id Verweis auf Vorgängerversion Lückenlose Versionierung System System, Superadmin, Tenant-Admin lesend V-02 Vertraulich Selbstrelation in TenantContract modelliert; transaktionale Ersetzung offen Gemäss zentraler Fristenmatrix

6.1 Abgrenzung Papier und Online-Formular

  • Beim elektronischen Abschluss werden Formulardaten, Vertragsversion und Abschlusszeitpunkt gespeichert sowie eine unveränderliche PDF-Kopie des akzeptierten Vertragstexts erzeugt.
  • Bei einem ausserhalb der Anwendung unterschriebenen Vertrag wird das digitalisierte oder bereits digital signierte Dokument hochgeladen und kontrolliert erfasst.
  • Ein physisches Papieroriginal wird nicht von DiveLogix360 verwahrt oder im System inventarisiert. Verarbeitet wird ausschliesslich die hochgeladene digitale Kopie.
  • Vertragsstatus, Versionierung, Integritätsnachweis und Zugriffsschutz gelten für beide Abschlusswege.
  • Vollständige Vertragsinhalte werden bei keinem Abschlussweg in SQL gespeichert.
  • PDF ist das verbindliche V1-Archiv- und Uploadformat. Die Datei liegt gemäss ADR-013 in einem privaten Objektspeicher; SQL enthält nur internen Objektschlüssel, Hash, Metadaten und Zuordnungen.
  • Die Dateigrenze von 10 MB, Malware-Prüfung und höchstens fünf Minuten gültige signierte Anwendungslinks sind fachlich entschieden. Hetzner Object Storage in Nürnberg und AWS KMS in Frankfurt sind gemäss ADR-019 gewählt; technische Umsetzung und Produktivnachweise bleiben offen.
  • IP-Adresse und User-Agent sind kein Bestandteil des V1-Vertragsnachweises; gegebenenfalls anfallende Sicherheitsdaten bleiben getrennten Sicherheitsprotokollen vorbehalten.

7. Feldkatalog – Benutzer, Einladung und Authentifizierung

Modell/Feld Inhalt Zweck Quelle Zugriff Rechtsgrundlage Schutz Implementierung Speicherfrist
User.id, tenantId Benutzer-ID und Tenant-Zuordnung Konto- und Berechtigungszuordnung System System, Superadmin, betroffener Tenant-Admin V-03/V-04 Vertraulich Vorhanden Gemäss zentraler Fristenmatrix
User.email Global eindeutige, durch Trimmen und Kleinschreibung normalisierte E-Mail Login und Kommunikation Superadmin/Benutzer System, Superadmin, betroffener Benutzer, E-Mail-Provider bei Versand V-03/V-04/V-06A Vertraulich Datenbank-Eindeutigkeit vorhanden; zentrale Normalisierung und globale Änderungsprüfung offen Gemäss zentraler Fristenmatrix
User.firstName, lastName Identitäts- und Anzeigenamen; für den ersten Tenant-Admin vor Aktivierung Pflicht Benutzerverwaltung und Kommunikation Superadmin/Benutzer System, Superadmin, berechtigter Tenant-Admin V-03 Vertraulich Vorhanden; Aktivierungsprüfung offen Gemäss zentraler Fristenmatrix
User.username Kein Feld im V1-Zielschema Kein Verarbeitungszweck in V1 Nicht zu befüllen Kein fachlicher Zugriff in V1 Keine Verarbeitung in V1 Nicht verwenden Aus dem Prisma-v4-Zielschema entfernt Nicht anwendbar in V1
User.role, status Rolle und Kontostatus invited, active, suspended oder deactivated Autorisierung und Lifecycle Superadmin/System System, Superadmin, betroffener Benutzer teilweise V-03/V-04 Vertraulich Vorhanden; Aktivierung erfolgt aktuell zu früh Gemäss zentraler Fristenmatrix
User.passwordHash Nicht rückrechenbarer Argon2id-Passworthash einschliesslich Verfahrensparametern Authentifizierung und sichere Verfahrensmigration Benutzer/System Ausschliesslich Authentifizierungsdienst V-04 Geheim; nie ausgeben oder protokollieren Derzeit bcrypt mit Kostenfaktor 12; Argon2id und Migration beim Login offen Gemäss zentraler Fristenmatrix
User.tfaSecretEncrypted, tfaKeyVersion Verschlüsseltes Geheimnis der zeitbasierten Zwei-Faktor-Authentifizierung (2FA) und Schlüsselversion Starke Authentifizierung und Rotation System/Benutzergerät Ausschliesslich Authentifizierungsdienst V-04 Geheim; Schlüssel ausserhalb der SQL-Datenbank Im Prisma-v4-Zielschema modelliert; Verschlüsselungsdienst und Migration offen Gemäss zentraler Fristenmatrix
User.tfaEnabled, tfaRequired, lastLoginAt Sicherheitsstatus und Zeitpunkt der letzten vollständig erfolgreichen Anmeldung Richtlinienprüfung und Kontosicherheit System System, Superadmin nur Status, betroffener Benutzer V-04/V-07 Vertraulich Vorhanden; Aktualisierung erst nach erforderlicher 2FA zu prüfen Gemäss zentraler Fristenmatrix
InvitationToken.tokenHash Hash des einmaligen Einladungsgeheimnisses Einladung sicher einlösen System Ausschliesslich Einladungsdienst V-03/V-04/V-06A/V-06B Geheim; Klarwert nur im Einladungslink, nie protokollieren Im Prisma-v4-Zielschema modelliert; Backend-Umstellung offen Ablauf 72 Stunden plus 30 Tage nach Ablauf, Verwendung oder Widerruf (RF-07)
Einladungs-E-Mail, Name und Rolle Empfänger und vorgesehene Berechtigung Einladung und Kontoanlage Superadmin/Tenant-Admin System, berechtigter Einladender, Empfänger, E-Mail-Provider V-03/V-06A/V-06B Vertraulich Vorhanden Gemäss zentraler Fristenmatrix
Einladungsstatus und Zeitpunkte Status, Ablauf, einmalige Nutzung, Widerruf und Erstellung Einladungs-Lifecycle und Missbrauchsschutz System System, Superadmin V-03/V-07 Vertraulich Vorhanden; Neuausstellung widerruft offene Vorgängertoken Gemäss zentraler Fristenmatrix
RefreshToken.tokenHash Hash des rotierenden Sitzungstokens Sitzung und Wiederverwendungserkennung System Ausschliesslich Authentifizierungsdienst V-04 Geheim; Klarwert nie dauerhaft speichern Hash, Rotation und Widerruf grundsätzlich vorhanden Bis Ablauf oder Widerruf plus 30 Tage (RF-08)
Refresh-Token-IP, User-Agent und Zeitpunkte Geräte- und Verbindungsmetadaten Sitzungssicherheit Endgerät/System Authentifizierungs- und Sicherheitsdienst V-04/V-07 Vertraulich Vorhanden Gemäss zentraler Fristenmatrix
RecoveryCode.codeHash Hash eines von acht Wiederherstellungscodes Kontowiederherstellung System Ausschliesslich Authentifizierungsdienst V-04 Geheim; Klarwert nur einmal anzeigen Im Prisma-v4-Zielschema modelliert; Backend-Umstellung offen Bis Nutzung, Ersetzung oder Reset plus 30 Tage (RF-09)
Recovery-Code-Nutzung und Erstellung Nutzungs- und Erstellungszeitpunkt Einmaligkeit und Sicherheitsnachweis System Authentifizierungs- und Sicherheitsdienst V-04/V-07 Vertraulich Vorhanden; Neuerzeugung muss alle Vorgänger ungültig machen Gemäss zentraler Fristenmatrix
TwoFactorSession Hash eines zweckgebundenen Übergangstokens, Ablauf und Fehlversuche Passwortprüfung sicher mit 2FA-Abschluss verbinden System Ausschliesslich Authentifizierungsdienst V-04/V-07 Geheim; einmalig, höchstens zehn Minuten Im Prisma-v4-Zielschema als zentrale kurzlebige Datenbanksitzung modelliert; Backend offen Höchstens zehn Minuten; verbrauchte Sperrinformation höchstens 24 Stunden (RF-10)

7.1 Verbindlicher Konto- und Aktivierungsablauf

  • Vor Einlösung besteht nur die Einladung; das Benutzerkonto ist noch nicht aktiv.
  • Nach Passwortvergabe bleibt der erste Tenant-Admin im Status invited, bis die verpflichtende 2FA erfolgreich eingerichtet und geprüft wurde.
  • Erst danach setzt das System den Benutzerstatus auf active und tfaEnabled auf true.
  • lastLoginAt wird nur nach vollständig erfolgreicher Anmeldung einschliesslich eines erforderlichen zweiten Faktors aktualisiert.
  • suspended und deactivated verhindern die Anmeldung und widerrufen alle bestehenden Refresh-Token.
  • Reaktivierung erfolgt am vorhandenen globalen Benutzer; E-Mail-Adressen deaktivierter oder vorläufig gelöschter Benutzer bleiben reserviert.

7.2 Verbindlicher Schutz der Authentifizierungsdaten

  • Anmeldung erfolgt ausschliesslich mit normalisierter E-Mail und Passwort; username ist in V1 ohne fachliche Funktion.
  • Argon2id ist das V1-Zielverfahren für Passwörter. Vorhandene bcrypt-Hashwerte mit Kostenfaktor 12 werden erkannt und beim nächsten erfolgreichen Login automatisch nach Argon2id migriert.
  • Das TOTP-Geheimnis wird verschlüsselt gespeichert. Der Verschlüsselungsschlüssel wird ausserhalb der SQL-Datenbank verwaltet; QR-Code und Klartext-Geheimnis sind nur während der Einrichtung sichtbar.
  • Acht zufällige Wiederherstellungscodes werden nur einmal im Klartext angezeigt, ausschliesslich als Hash gespeichert und jeweils nur einmal akzeptiert. Neuerzeugung oder 2FA-Reset invalidiert alle bisherigen Codes.
  • Einladungstoken sind kryptografisch zufällig, einmalig und 72 Stunden gültig. Nur der Hash wird gespeichert; eine Neuausstellung widerruft offene Vorgängertoken.
  • Refresh-Token werden ausschliesslich als Hash gespeichert und bei Verwendung rotiert. Abmeldung, Passwortänderung, Sperre, Deaktivierung und 2FA-Reset widerrufen die betroffenen Sitzungen.
  • Temporäre 2FA-Sitzungen sind zweckgebunden, einmalig, versuchsbegrenzt und höchstens zehn Minuten gültig. Für den Produktivbetrieb ist ein zentraler kurzlebiger Speicher erforderlich.
  • Passworthashes, TOTP-Geheimnisse, Wiederherstellungs-, Einladungs- und Refresh-Token sind auch für Superadmins nicht lesbar. Authentifizierungswerte dürfen niemals protokolliert werden.

8. Feldkatalog – Onboarding und Schulprofil

Rechtliche Tenant-Stammdaten und das operative Schulprofil sind getrennte fachliche Datengruppen. Änderungen des Schulprofils dürfen rechtliche Bezeichnung und Vertragsanschrift nicht überschreiben. Für V1 wird deshalb ein eigenes Eins-zu-eins-Modell TenantProfile vorgesehen.

Modell/Feldgruppe Inhalt Zweck Quelle Zugriff Rechtsgrundlage Schutz Implementierung Speicherfrist
TenantProfile.tenantId Eindeutige Zuordnung zum Tenant Operatives Profil vom Vertragsstamm trennen System System, Tenant-Admin, Superadmin supportbezogen V-05 Vertraulich Eins-zu-eins-Modell im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
displayName Angezeigter beziehungsweise öffentlicher Schulname Produktdarstellung ohne Änderung des rechtlichen Namens Tenant-Admin System, Tenant-Admin, Superadmin; öffentlich nach Profilfreigabe V-05 Intern bis Freigabe Im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
Operative Adresse Strasse, Postleitzahl, Ort und Land des Schulbetriebs Schulprofil, Erreichbarkeit und Lokalisierung Tenant-Admin System, Tenant-Admin, Superadmin; öffentlich nach Profilfreigabe V-05 Vertraulich bis Freigabe Separate Profilfelder im Prisma-v4-Zielschema vorhanden Gemäss zentraler Fristenmatrix
contactPerson Operative Kontaktperson Betriebskommunikation Tenant-Admin System, Tenant-Admin, Superadmin supportbezogen V-05 Vertraulich In TenantProfile modelliert; Backend offen Gemäss zentraler Fristenmatrix
contactEmail Operative Kontakt-E-Mail Betriebskommunikation und optional öffentliche Erreichbarkeit Tenant-Admin System, Tenant-Admin, Superadmin; E-Mail-Provider bei Versand; öffentlich nur nach Freigabe V-05/V-06B Vertraulich bis Freigabe In TenantProfile modelliert; Backend offen Gemäss zentraler Fristenmatrix
contactPhoneFixed, contactPhoneMobile Festnetz und Mobiltelefon; mindestens eines beim Abschluss erforderlich Erreichbarkeit Tenant-Admin System, Tenant-Admin, Superadmin; öffentlich nur nach jeweiliger Freigabe V-05 Vertraulich bis Freigabe In TenantProfile modelliert; At-least-one-Prüfung im Backend offen Gemäss zentraler Fristenmatrix
website Optionale HTTPS-Adresse der Schulwebsite Externe Information und Verlinkung Tenant-Admin System, Tenant-Admin, Superadmin; öffentlich nur nach Freigabe V-05 Intern bis Freigabe Im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
Veröffentlichungsfelder Getrennte boolesche Freigaben für Kontakt-E-Mail, Festnetz, Mobiltelefon und Website Kontrollierte Veröffentlichung Tenant-Admin System und Tenant-Admin; Superadmin nur lesend im Supportkontext V-05 Standard false; Änderungen auditieren Im Prisma-v4-Zielschema vorhanden; Backend und Audit offen Gemäss zentraler Fristenmatrix
defaultCurrency CHF oder EUR Tenant-weite Standardwährung Tenant-Admin bei Ersteinrichtung, danach Superadmin System, Tenant-Admin, Superadmin V-05 Intern In TenantProfile modelliert; Änderungssperre nach Erstspeicherung offen Gemäss zentraler Fristenmatrix
TenantOnboarding Gesamtstatus pending, in_progress oder completed; Start-, Abschlusszeit und ausführender Benutzer Wiederaufnahme, Abschlusskontrolle und Nachweis System System, Tenant-Admin, Superadmin supportbezogen V-05/V-08B Intern Im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
OnboardingStep Schlüssel, Status, Start-, Abschlusszeit und ausführender Benutzer Sequenz, Draft-Fortschritt und Wiederaufnahme System/Tenant-Admin System, Tenant-Admin, Superadmin supportbezogen V-05/V-08B Intern Vier persistente Schrittarten im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
Profilbestätigung profileConfirmed, profileConfirmedAt, profileConfirmedBy Bestätigung der Vollständigkeit und Richtigkeit Tenant-Admin/System System, Tenant-Admin, berechtigte Prüfer V-05/V-08B Vertraulich Im Prisma-v4-Zielschema vorhanden; Backend offen Gemäss zentraler Fristenmatrix
Erste Mitarbeitereinladung Normalisierte E-Mail, Vorname, Nachname und feste Rolle mitarbeiter Optionaler Einstieg in die Benutzerverwaltung Tenant-Admin System, Tenant-Admin, Empfänger, E-Mail-Provider V-05/V-06B Vertraulich OpenAPI und Backend widersprüchlich; Abschnitt-7-Regeln umzusetzen Gemäss zentraler Fristenmatrix

8.1 Verbindlicher V1-Ablauf

Reihenfolge Schritt Pflicht Abschlusskriterium
1 school_profile Ja Anzeigename, operative Adresse, Land und Standardwährung vollständig
2 contact_details Ja Kontaktperson, gültige Kontakt-E-Mail, mindestens eine Telefonnummer und alle Veröffentlichungsentscheidungen vorhanden
3 first_employee Nein Mitarbeitereinladung erfolgreich ausgelöst oder Schritt ausdrücklich übersprungen
4 confirmation Ja Profilübersicht bestätigt und serverseitige Gesamtprüfung erfolgreich
  • Die Reihenfolge wird serverseitig erzwungen. Ein Folgeschritt wird erst nach Abschluss des Vorgängers freigeschaltet.
  • Drafts werden direkt in den fachlichen Zielfeldern gespeichert. Das Fortschrittsmodell enthält keine zusätzliche freie JSON-Kopie der Profildaten.
  • Schrittstatus sind not_started, in_progress, completed und für optionale Schritte skipped.
  • Abgeschlossene Profilschritte können erneut bearbeitet werden; jede Änderung wird auditiert. Nach Abschluss bleibt das Profil über die reguläre Profilverwaltung änderbar.
  • first_employee erlaubt in V1 ausschliesslich die Rolle mitarbeiter. Der bereits angemeldete erste Tenant-Admin wird nicht erneut eingeladen.
  • Logo, Verbände, Zertifizierungen und Öffnungszeiten gehören nicht zum V1-Onboarding.
  • Die Bestätigung bezieht sich ausschliesslich auf Vollständigkeit und Richtigkeit des Profils. Ein unspezifisches termsAccepted wird nicht erhoben.

8.2 Abschluss- und Statusregeln

  • Der fachliche Tenant-Lifecycle lautet contract_pending → onboarding → active.
  • contract_pending gilt bis zum wirksamen AVV-Abschluss, onboarding danach bis zum vollständigen Schulprofil und active erst nach erfolgreicher Abschlussprüfung.
  • Beim Abschluss müssen Schulprofil, Kontaktdaten und Bestätigung vollständig sein; der optionale Mitarbeiterschritt muss completed oder skipped sein.
  • Der AVV-Nachweis muss weiterhin gültig sein. Der Abschluss ist idempotent und darf keine doppelten Einladungen oder Audit-Ereignisse erzeugen.
  • Die aktuelle Prisma-Statusauswahl pending, active, suspended, deactivated bildet den beschlossenen Lifecycle noch nicht vollständig ab.
  • defaultCurrency ist nach dem ersten erfolgreichen Speichern nur durch den Superadmin änderbar; jede Änderung wird auditiert.
  • Veröffentlichungsfreigaben sind je Feld standardmässig false, nur durch den Tenant-Admin änderbar und wirken bei Widerruf sofort.

9. Feldkatalog – Protokolle

Modell/Feldgruppe Inhalt Zweck Zugriff Rechtsgrundlage Minimierung und Schutz Implementierung Speicherfrist
AuthLog Ereignis-ID und -typ, UTC-Zeitpunkt, optionale Tenant-/Benutzer-ID, pseudonymisierter Anmeldebezug, Ergebnis, Grundcode, IP-Adresse, begrenzter User-Agent, Korrelations-ID und Sicherheitsmassnahme Login-, Sitzungs-, 2FA-, Wiederherstellungs- und Einladungssicherheit Sicherheitsdienst; streng berechtigter Plattformzugriff V-07 Keine E-Mail im Klartext bei unbekanntem Konto; keine Passwörter, Codes, Geheimnisse oder Tokens Zielstruktur im Prisma-v4-Zielschema; Backend schreibt noch Teilereignisse und verwirft Fehler 6 Monate; vollständige IP-Adresse 30 Tage (RF-11)
AuditLog Kontext platform oder tenant, Akteur, Entität, Aktion, Ergebnis, Grundcode, freigegebene Feldänderungen, UTC-Zeitpunkt und Korrelations-ID Fachlicher Änderungs-, Vertrags- und Administrationsnachweis Plattformprüfer für Plattformkontext; berechtigte Tenant-Prüfer nur für Tenant-Kontext V-08A/V-08B Feld-Whitelist; bei Geheimfeldern nur changed: true; keine vollständigen Datensätze Zielstruktur im Prisma-v4-Zielschema; Backend und Feld-Whitelists offen 3 Jahre; vertragsrelevant 10 Jahre ab Ende des Kalenderjahres des Vertragsendes (RF-12/RF-13)
AccessLog Kontext, zugreifende Person, Tenant, Entität, Aktion, Zweck-/Grundcode, Ergebnis, UTC-Zeitpunkt, IP-Adresse und Korrelations-ID Nachweis besonders sensibler Lese-, Download-, Export- und Supportzugriffe Sicherheitsdienst und streng berechtigte Prüfer V-08A/V-08B Nur definierte sensible Zugriffe; Logzugriffe selbst protokollieren Zielstruktur im Prisma-v4-Zielschema; Backend offen 1 Jahr; vertragsrelevant 10 Jahre ab Ende des Kalenderjahres des Vertragsendes (RF-13/RF-14)
SystemLog beziehungsweise zentraler technischer Logspeicher Ereignistyp, Schweregrad, Dienst, standardisierter Fehlercode, UTC-Zeitpunkt, Korrelations-ID und bereinigte technische Metadaten Betrieb, Fehleranalyse, Verfügbarkeit und Alarmierung Betrieb und Sicherheitsdienst V-07 Strukturierte Whitelist; keine freien Request-/Response-Bodies, Providertexte, Personendaten oder Geheimnisse Zielstruktur im Prisma-v4-Zielschema; Backend nutzt noch überwiegend unstrukturierten Logger 30 Tage; sicherheitsrelevante Auszüge 6 Monate (RF-15/RF-11)
DeletionLog Kontext, pseudonymisierte Entitätsreferenz, Löschart, Akteur, Grundcode, UTC-Zeitpunkt, Ergebnis, Datenkategorien, Aufbewahrungssperre und Korrelations-ID Lösch-, Anonymisierungs- und Rechenschaftsnachweis Streng berechtigte Prüfer V-08A/V-08B Kein Daten-Snapshot und keine gelöschten Inhaltsdaten dataSnapshot im Prisma-v4-Zielschema entfernt; Backend offen 3 Jahre (RF-16)
NotificationLog für UC00 Geschützte Empfängerreferenz, Template-Schlüssel/-Version, Kanal, Provider-Nachrichten-ID, Status, Versand-/Zustell-/Fehlerzeitpunkt, Fehlercode und Korrelations-ID Minimierter Versand- und Fehlernachweis Versanddienst, Betrieb und berechtigte Prüfer V-06A/V-06B/V-07 Kein Nachrichteninhalt, Token, Code, Passwort oder freie Providerfehlermeldung Zielstruktur mit gehashter Empfängerreferenz im Prisma-v4-Zielschema; Backend offen 90 Tage; Providerinhalt höchstens 7 Tage (RF-17/RF-18)

9.1 Verbindliche Ereignisse und Kontexttrennung

  • Authentifizierungsprotokolle erfassen Erfolg und Misserfolg von Login, 2FA, Wiederherstellung, Logout, Tokenrotation, Token-Wiederverwendung, Passwort- und 2FA-Änderung, Sperre sowie Einladungseinlösung, -ablauf und -widerruf.
  • Audit-Protokolle erfassen Vertragsaktionen, Rollen- und Statusänderungen, Benutzerverwaltung, Onboarding-Abschluss, Veröffentlichungsänderungen, Sicherheitsresets, Exporte und Löschvorgänge.
  • Access-Protokolle erfassen das Öffnen oder Herunterladen von Vertragsdokumenten, den Zugriff auf Sicherheits-, Lösch- und Protokolldaten sowie begründete Supportzugriffe auf Tenant-Daten.
  • scope = platform kennzeichnet Tätigkeiten unter eigener Verantwortlichkeit von DiveLogix360; scope = tenant kennzeichnet Tätigkeiten im Auftrag des Tenants.
  • Bei scope = platform ist tenantId optional, bei scope = tenant verpflichtend. Rechtsgrundlage, Zugriff, Export, Aufbewahrung und Offboarding richten sich nach diesem Kontext.
  • Ereignistyp, Aktion, Ergebnis, Schweregrad und Grundcode stammen aus verbindlichen Katalogen und nicht aus frei eingegebenem Text.

9.2 Datenminimierung und Geheimnisausschluss

  • Passwörter, Passworthashes, TOTP-Werte und -Geheimnisse, Wiederherstellungs-, Access-, Refresh-, Einladungs- und Vertragstoken werden niemals protokolliert.
  • Unbekannte Login-E-Mail-Adressen werden höchstens mit einem zweckgebundenen HMAC pseudonymisiert; der verwendete Schlüssel liegt ausserhalb der Protokolldatenbank.
  • Alt- und Neuwerte werden nur für freigegebene Fachfelder gespeichert. Bei Sicherheitsfeldern wird ausschliesslich die Änderung ohne Wert dokumentiert.
  • Vollständige Request- oder Response-Bodies, Vertragsdokumente, Nachrichteninhalte, Datenbank-Verbindungsdaten und ungefilterte technische Fehlermeldungen sind ausgeschlossen.
  • DeletionLog enthält keinen vollständigen oder teilweisen Snapshot der gelöschten Personendaten.
  • IP-Adressen werden nur für begründete Sicherheits- und besonders sensible administrative Nachweise verarbeitet. Vollständige IP-Adressen werden nach 30 Tagen gekürzt oder gelöscht; der übrige minimierte Sicherheitsnachweis endet nach sechs Monaten.

9.3 Integrität, Zugriff und Verhalten bei Ausfall

  • Fachliche Protokolle sind append-only. Anwendungsrollen können sie weder ändern noch direkt löschen; Löschung erfolgt nur über den kontrollierten Aufbewahrungsprozess.
  • Zeitpunkte werden serverseitig in UTC erzeugt. Jede Anfrage beziehungsweise zusammengehörige Aktion erhält eine Korrelations-ID, die selbst kein Geheimnis enthält.
  • Protokollzugriffe und -exporte werden ebenfalls protokolliert. Rechte werden nach geringstmöglichem Zugriff getrennt und regelmässig geprüft.
  • Manipulation, unberechtigter Zugriff, ausgefallene Protokollierung und erschöpfter Speicher müssen erkannt und alarmiert werden.
  • Gewöhnliche Authentifizierungsversuche dürfen bei kurzfristigem Protokollausfall weiterlaufen, sofern ein unabhängiger Alarm und eine gesicherte Nachlieferung erfolgen.
  • Vertragsabschlüsse, Rollen- und Statusänderungen, Benutzerdeaktivierungen, 2FA-Resets sowie Löschungen werden transaktional mit ihrem Audit-Eintrag verarbeitet. Ohne Audit-Nachweis wird die kritische Änderung abgebrochen.
  • Vertrags- und Datenschutzereignisse folgen ADR-018. Je UTC-Tag und Verantwortlichkeitskontext wird ein SHA-256-Sammelnachweis erzeugt und getrennt unveränderlich im privaten Objektspeicher abgelegt.
  • E-Mail-Fehler verwenden interne Empfängerreferenzen und standardisierte Fehlercodes statt vollständiger Empfängeradresse und ungefiltertem Providertext.
  • Wiederherstellungscodes werden nicht per E-Mail versendet. Zulässig ist nur eine Nachricht, dass neue Codes erzeugt wurden, ohne die Codes selbst zu enthalten.

10. Empfänger und Übermittlungen

Empfängerkategorie Zweck Daten Rolle Region/Übermittlung Status
Anwendungs- und Infrastrukturhosting Anwendung und Betrieb Erforderliche UC00-Daten Auftragsverarbeiter von DiveLogix360 Deutschland oder Schweiz bevorzugt; Produkt, Backup und Support zu bestätigen Hetzner under_review
PostgreSQL-Datenbankdienst Persistente relationale Daten und fachliche Protokolle UC00-SQL-Daten Auftragsverarbeiter Produktiv Schweiz/EU/EWR; Supabase nur Entwicklung mit synthetischen Daten Produktiv offen; Supabase development_only
Hetzner Object Storage Verschlüsselte unveränderliche Vertrags-PDFs, Audit-Sammelnachweise, Offboarding-Exporte und technische Objektmetadaten Vertragsdokumente und Zuordnungen; Sammelnachweise ohne fachliche Inhaltsdaten; Exportinhalte Auftragsverarbeiter Nürnberg (nbg1); Replikations-, Support- und Fernzugriffsländer zu bestätigen; keine öffentliche CDN-Verteilung Gemäss ADR-019 gewählt, under_review bis zu vollständigen Produktivnachweisen
AWS Key Management Service (AWS KMS) Erzeugung und Entschlüsselung zufälliger Objektdatenschlüssel Zufällige Schlüssel und nicht personenbezogener Verschlüsselungskontext; keine Objektdokumente Auftragsverarbeiter Frankfurt (eu-central-1); Support-, Protokoll-, Fernzugriffs- und Unterauftragnehmerländer zu prüfen Gemäss ADR-019 gewählt, under_review bis zu vollständigen Produktivnachweisen
Hetzner Object Storage für Backup und Wiederherstellung Verschlüsselte PostgreSQL-PITR-Daten, Datenbank- und erforderliche Objektbackups Je Sicherungsumfang UC00-Daten Auftragsverarbeiter Falkenstein (fsn1); Replikations-, Protokoll-, Support- und Fernzugriffsländer bestätigen Gemäss ADR-020 gewählt, under_review bis zu vollständigen Produktiv- und Restore-Nachweisen
Authentifizierter SMTP-Dienst Einladungen, Passwortzurücksetzungs-, Vertrags- und Sicherheitsnachrichten Empfänger, minimierter Template-Inhalt, einmaliger Link und Versandmetadaten Auftragsbearbeiter von DiveLogix360 beziehungsweise Unterauftragsbearbeiter im Tenant-Kontext Hostpoint: Primär Schweiz; weitere Unterauftragnehmer- und Supportländer zu bestätigen Hostpoint gemäss ADR-016 gewählt, under_review bis Produktivnachweise; Resend und Hetzner-SMTP ausgeschlossen
Grafana Cloud Pro und Grafana Alloy Betrieb, Alarmierung, Fehleranalyse und externe Verfügbarkeitsprüfung Minimierte technische Metriken, Systemprotokolle, Alarmzustände und synthetische Prüfergebnisse; keine fachlichen Inhalte oder IDs Auftragsverarbeiter Deutschland, AWS Frankfurt (eu-central-1); Prüfstandorte Frankfurt/Zürich; Support- und Unterauftragnehmerländer prüfen Gemäss ADR-021 gewählt, under_review bis zu vollständigen Produktivnachweisen
DiveLogix360-Eigenbetrieb mit ClamAV Sicherheitsprüfung hochgeladener PDF-Dateien Temporäre Vertragsdatei und minimiertes Prüfergebnis Kein externer Empfänger Hetzner-Produktivinfrastruktur Gemäss ADR-022 gewählt; technische Härtung und Wirksamkeitsnachweise offen
Berechtigte interne Administratoren Tenant-, Vertrags-, Sicherheits- und Supportverwaltung Aufgabenbezogen erforderliche UC00-Daten Interner Zugriff von DiveLogix360 Schweiz/EU/EWR, solange keine Drittlandfreigabe vorliegt Berechtigungskonzept und Audit offen
Externe Supportkräfte Begründeter Support Minimal erforderliche Supportdaten Auftragsverarbeiter oder interner Zugriff je Vertragsmodell Schweiz/EU/EWR bevorzugt; vertraglich einzuordnen Nicht ausgewählt
Tenant-Admin und eingeladene Benutzer Eigener Tenant, eigenes Konto, eigene Einladung und freigegebene Vertragsnachweise Aufgabenbezogen erforderliche Daten Verantwortlicher Tenant beziehungsweise betroffene Person Tenant-Sitz CH/DE/AT Fachlich vorgesehen
Öffentliche Besucher Anzeige ausdrücklich freigegebener Profildaten Nur veröffentlichte Schulprofilfelder Öffentlichkeit als Empfängerkreis Weltweit abrufbar nach ausdrücklicher Feldfreigabe Fachlich entschieden; Umsetzung offen
Empfangender Mailanbieter Zustellung an die gewählte Empfängeradresse Inhalt der minimierten Nachricht und Transportmetadaten Empfängerumgebung der betroffenen Person Durch Empfängeradresse bestimmt Technisch unvermeidbarer Zustellweg
Behörden, Gerichte und Rechtsberatung Gesetzliche Pflicht oder Rechtsdurchsetzung im Einzelfall Nur erforderliche Einzelfalldaten Eigenständiger Empfänger Nach konkreter Rechtsgrundlage Kein pauschaler Zugriff

10.1 Produktive Infrastruktur und nicht produktive Umgebungen

  • Produktive Primärverarbeitung und Backups finden grundsätzlich in der Schweiz, EU oder im Europäischen Wirtschaftsraum statt. Deutschland oder Schweiz sind für V1 bevorzugt.
  • Hetzner bleibt bevorzugter Kandidat für den Anwendungsbetrieb. Hostpoint ist gemäss ADR-016 als V1-E-Mail-Provider gewählt, bleibt aber bis zur schriftlichen Nutzungsbestätigung, Auftragsbearbeitungsvereinbarung sowie Standort-, Unterauftragnehmer-, Lösch- und Technikprüfung under_review.
  • Ein eigener Mailserver wird in V1 nicht betrieben. Resend und Hetzner-SMTP sind keine V1-Kandidaten. Jeder Ersatz für Hostpoint benötigt eine neue Prüfung und dokumentierte Freigabe.
  • Supabase bleibt bis zu einer separaten Produktivprüfung auf Entwicklung mit synthetischen Daten beschränkt.
  • Entwicklungs-, Test- und Demo-Umgebungen enthalten keine produktiven Benutzer-, Vertrags-, Dokument- oder Protokolldaten und verwenden keine Produktivschlüssel oder Produktiv-Buckets.
  • Produktionskopien sind untersagt. Notwendige produktionsnahe Daten werden vor Übernahme irreversibel anonymisiert.
  • Test-E-Mails gehen ausschliesslich an kontrollierte interne Adressen oder einen lokalen Mail-Catcher.

10.2 Anbieter- und Übermittlungsprüfung

  • Das verbindliche Provider- und Unterauftragnehmerregister führt Anbieter und Dienste getrennt. Nur Status approved erlaubt produktive personenbezogene Daten.
  • Je Dienst werden juristische Vertragspartei, Zweck, Daten, betroffene Personen, Rolle, Primär-, Backup-, Support- und Fernzugriffsländer, Unterauftragnehmer, Vertrag, Schutzmassnahmen, Aufbewahrung, Löschung und Freigabestatus nachgewiesen.
  • Drittlandzugriffe durch Support, Wartung, Backups, Unterauftragnehmer, globale Protokollierung oder Konzerngesellschaften gelten ebenfalls als mögliche Auslandsübermittlung.
  • Vorrang haben Schweiz, EU/EWR und Staaten mit anerkannt angemessenem Datenschutzniveau. Fehlt Angemessenheit, sind vor Übermittlung Standardvertragsklauseln, Transferprüfung und erforderliche Zusatzmassnahmen zu dokumentieren.
  • Änderungen von Region, Zweck oder Unterauftragnehmern lösen eine erneute Prüfung, Versionierung und die im AVV geregelte Vorabinformation mit Widerspruchsprozess aus.
  • Beim Anbieterende werden Zugänge entzogen sowie Rückgabe und Löschung einschliesslich Backups nachgewiesen.

10.3 Dienstspezifische Schutzregeln

  • Vertrags-PDFs liegen in einem privaten Bucket ohne öffentliche oder globale CDN-Verteilung. Signierte URLs sind kurzlebig; Anbieter dürfen Inhalte nicht für eigene Zwecke verwenden.
  • E-Mail-Dienste erhalten keine Passwörter, Wiederherstellungscodes, Access-Token, Refresh-Token oder Vertragsdokumente. Zulässig sind minimierte Nachrichten mit einmaligen Einladungs-, Passwortzurücksetzungs- oder Vertragslinks. Linktoken sind befristet, einmalig, widerrufbar, serverseitig nur gehasht und aus Protokollen ausgeschlossen. Providerinhalte werden höchstens sieben Tage und eigene Versandnachweise 90 Tage gespeichert.
  • Externes Monitoring erhält keine Formulareingaben, vollständigen Request-Bodies oder Session-Replays.
  • Grafana Cloud Pro in Deutschland beziehungsweise Frankfurt ist gemäss ADR-021 gewählt. Personenbezogene und fachliche IDs sind als Metriklabels ausgeschlossen; Metriken werden nicht pro Tenant, Benutzer, Kunde, Equipmentteil, Vertrag oder Dokument erzeugt.
  • Normale Messwerte werden grundsätzlich einmal pro Minute und externe HTTPS-, DNS- und Zertifikatsprüfungen alle fünf Minuten aus Frankfurt und Zürich erhoben. Kürzere Intervalle benötigen eine dokumentierte Begründung.
  • Sentry, Application Observability, Database Observability, Frontend Observability, Real User Monitoring, Session Replay, Tracing und Profiling sind in V1 deaktiviert und benötigen vor Aktivierung einen neuen Entscheid.
  • Tarifkontingente werden spätestens bei 70 Prozent gewarnt und bei 85 Prozent kritisch alarmiert. Prognostizierte Mehrkosten, zusätzliche Benutzer und Zusatzmodule benötigen dokumentierte Freigabe; Sicherheitskontrollen dürfen nicht allein zur Kostensenkung entfallen.
  • Malware-Prüfung erfolgt gemäss ADR-022 durch einen eigenbetriebenen ClamAV-Dienst innerhalb der Hetzner-Produktivinfrastruktur. Vollständige Vertragsdateien werden nicht an externe Malware- oder Sandbox-Dienste übertragen.
  • Interne Infrastrukturrechte werden zweckgebunden für höchstens vier Stunden vergeben. Tenantbezogene Supportrechte sind standardmässig deaktiviert, benötigen eine ticketbezogene Tenant-Admin-Freigabe und gelten höchstens acht Stunden. Ein alarmierter Notfallzugriff ohne Vorabfreigabe ist nur zur Schadensabwehr oder Wiederherstellung und für höchstens eine Stunde zulässig.
  • Menschliche Produktivzugriffe sind in V1 auf Schweiz, EU und EWR begrenzt. Andere Länder benötigen vorab Transferprüfung, geeignete Garantien, erforderliche Zusatzmassnahmen und dokumentierte Freigabe. Provider ohne nachgewiesene Zugriffsländer bleiben under_review.
  • Supportkonten sind persönlich, minimal berechtigt und tenantbegrenzt. Freier Tenantwechsel, Identitätsübernahme, standardmässige Downloads und lokale Datenkopien sind ausgeschlossen. Zweck, Umfang, Beginn, Ende, Aktionen und Ergebnis werden protokolliert.
  • Tenant-Admins sehen weder Plattform-Sicherheitsprotokolle noch andere Tenants oder Authentifizierungsgeheimnisse. Öffentlich sichtbar sind ausschliesslich einzeln freigegebene Schulprofilfelder.

11. Technische und organisatorische Schutzanforderungen

Die folgenden V1-Regeln sind fachlich verbindlich. Ihr Umsetzungs- und Prüfstatus wird in der zentralen Übersicht der technischen und organisatorischen Massnahmen (TOM) geführt.

11.1 Zugriff, Identität und Sitzungen

  • Zugriff wird standardmässig verweigert und serverseitig nach Rolle, Tenant und Ressource freigegeben. Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) dient als zusätzliche Schutzschicht.
  • Superadmin-Zugriffe benötigen einen expliziten Kontext und Grund und werden auditiert. Administrative und Datenbankzugriffe verwenden persönliche Konten; gemeinsame Konten sind unzulässig.
  • Rechte werden bei Austritt oder Aufgabenwegfall sofort entzogen und mindestens quartalsweise geprüft. Ein besonders geschütztes Notfallkonto wird getrennt verwaltet und überwacht.
  • Zwei-Faktor-Authentifizierung (2FA) ist für Superadmin und Tenant-Admin Pflicht. Sensible Aktionen dürfen eine erneute Authentifizierung verlangen.
  • Allgemeine Ratenbegrenzung wird tatsächlich global aktiviert; Authentifizierungsendpunkte erhalten strengere Grenzwerte. Rollen- oder Statusänderungen widerrufen betroffene Sitzungen.
  • Sitzungscookies verwenden HttpOnly, Secure und SameSite=Strict. Cookie-basierte zustandsändernde Endpunkte prüfen Herkunft und Schutz gegen Cross-Site Request Forgery (CSRF). Access-Token werden nicht in localStorage oder sessionStorage gespeichert.

11.2 Verschlüsselung, Geheimnisse und Infrastruktur

  • Alle Transportwege verwenden Transport Layer Security (TLS) 1.2 oder höher, bevorzugt TLS 1.3; HTTP Strict Transport Security (HSTS) ist aktiv. Dies gilt auch für Datenbank, E-Mail, Backups und Objektspeicher.
  • Datenbank, private Objekte und Backups sind im Ruhezustand verschlüsselt. TOTP-Geheimnisse werden feldverschlüsselt; Schlüssel liegen ausserhalb der SQL-Datenbank.
  • Produktive Geheimnisse und Schlüssel werden zentral, umgebungsgetrennt und nach Minimalprinzip verwaltet, rotiert und widerrufen. JWT-Schlüsselwechsel unterstützt eine kontrollierte Übergangsphase mit Schlüssel-ID.
  • Datenbank und interne Dienste sind nicht öffentlich erreichbar. Private Netze, Firewalls, minimale Ports, persönliche SSH-Schlüssel, zeitnahe Sicherheitsupdates, Umgebungsisolation und nicht privilegierte Prozesse sind Pflicht.
  • Administrative Oberflächen werden, soweit betrieblich möglich, zusätzlich über VPN oder eine IP-Freigabeliste eingeschränkt. Systemzeiten und Nachweise verwenden UTC.

11.3 Anwendungssicherheit

  • Endpunkte verwenden konkrete Datenübertragungsobjekte statt any, Feld- und Längenprüfungen, parametrisierte Datenbankzugriffe und bereinigte Fehlerausgaben.
  • CORS verwendet eine exakte Freigabeliste. Sicherheitsheader, eine Content-Security-Policy im Frontend und no-store für sensible Antworten sind aktiv.
  • Weiterleitungen und externe Links folgen einer Freigabeliste. Debug- und API-Dokumentationsflächen sind produktiv deaktiviert oder geschützt.
  • Passwörter, Token, Wiederherstellungscodes, TOTP-Geheimnisse, freie Request- oder Response-Bodies und vollständige Vertragsdokumente gelangen in kein Protokoll. Auditwerte werden über Feld-Freigabelisten minimiert.

11.4 Vertragsuploads und Objektspeicher

  • Zulässig sind ausschliesslich PDF-Dateien mit höchstens 10 MB. Dateiendung, MIME-Typ und Magic Bytes müssen übereinstimmen.
  • Verschlüsselte oder passwortgeschützte PDFs werden abgewiesen. JavaScript, automatische Startaktionen und eingebettete Dateien werden abgewiesen. Signierte Vertrags-PDFs werden nicht bereinigt oder neu geschrieben.
  • Neue Dateien verbleiben verschlüsselt bis zum erfolgreichen ClamAV-Scan in Quarantäne. Nur ein eindeutiges sauberes Ergebnis mit höchstens zwei Stunden alten Signaturen erlaubt die unveränderte Übernahme. Scanner-, Signatur-, Zeit- oder Prüffehler sperren die Freigabe; fehlgeschlagene Dateien werden spätestens nach 24 Stunden gelöscht.
  • Der private Objektschlüssel ist zufällig; der bereinigte Originalname wird nur als Metadatum gespeichert. Nach sicherer Prüfung wird ein SHA-256-Hash gebildet.
  • Der Bucket ist nicht öffentlich. Autorisierte signierte Anwendungslinks gelten höchstens fünf Minuten, werden weder persistent gespeichert noch protokolliert. Das Backend prüft die Berechtigung, übergibt den SSE-C-Schlüssel ausschliesslich serverseitig und streamt Downloads mit Content-Disposition: attachment sowie X-Content-Type-Options: nosniff.

11.5 Backup, Wiederherstellung und Monitoring

  • Verschlüsselte automatische Backups und PostgreSQL Point-in-Time Recovery (PITR, Wiederherstellung auf einen bestimmten Zeitpunkt) müssen ein Recovery Point Objective (RPO, maximal tolerierter Datenverlust) von höchstens einer Stunde und ein Recovery Time Objective (RTO, maximale Wiederherstellungszeit) von höchstens acht Stunden erreichen. Dies sind risikobasierte interne V1-Obergrenzen und keine gesetzlich festgelegten Zahlen.
  • Bestätigte Vertragsabschlüsse dulden keinen bewusst akzeptierten Verlust: Die Anwendung meldet Erfolg erst nach konsistenter dauerhafter Speicherung von Vertragsdatensatz, PDF-Objekt und Auditnachweis.
  • PostgreSQL verwendet fortlaufende WAL-Archivierung für PITR, tägliche Sicherungen und mindestens wöchentliche Vollsicherungen. Die verschlüsselten Sicherungen liegen getrennt vom Nürnberger Produktivspeicher in Hetzner Object Storage am Standort Falkenstein.
  • Vertragsobjekte sind geschützt und versioniert. Backupkopien verwenden getrennte Berechtigungen; mindestens eine Kopie liegt in einer separaten Ausfalldomäne in der Schweiz, Europäischen Union oder im Europäischen Wirtschaftsraum.
  • Backups werden täglich auf Erfolg überwacht, monatlich technisch geprüft, quartalsweise dokumentiert wiederhergestellt und jährlich in einer vollständigen Notfallwiederherstellung erprobt. Gemessene RPO- und RTO-Werte werden festgehalten.
  • Monitoring umfasst mindestens Verfügbarkeit, Datenbank, Fehler, Speicher, Backup und Restore, Zertifikate, E-Mail, Malware-Scan, Authentifizierungsmissbrauch, Protokollausfall, administrative Zugriffe, Schlüsselrotation, Objektzugriffe und abgewiesene Uploads. Jeder Alarm besitzt einen verantwortlichen Empfänger.
  • Monitoring selbst wird überwacht. Metrikkardinalität, Datenpunkte, Logvolumen, synthetische Prüfungen, aktive Benutzer, Kosten und nicht freigegebene Zusatzmodule werden mindestens monatlich geprüft.

11.6 Schwachstellen, Vorfälle und Organisation

  • Abhängigkeiten, Anwendungscode und Geheimnisse werden automatisiert geprüft. Software Bill of Materials (SBOM, Software-Stückliste), Lockfiles und reproduzierbare Builds sind Pflicht; kritische Schwachstellen blockieren die Produktion.
  • OWASP ASVS Level 2 ist Prüfbasis. Ein unabhängiger Penetrationstest erfolgt vor Produktivstart, nach wesentlichen Sicherheitsänderungen und anschliessend jährlich.
  • Ein Incident-Response-Prozess regelt Kontakte, Eindämmung, Beweissicherung, betroffene Daten und Tenants, Geheimnisrotation, Information, rechtliche Meldeprüfung, Vorfallregister und Ursachenanalyse. Der Ablauf wird jährlich geübt.
  • Mitarbeitende sind zur Vertraulichkeit verpflichtet und werden jährlich zu Sicherheit und Datenschutz geschult. Eintritt, Rollenwechsel, Austritt, Provider, Supportzugriff, Endgeräteschutz, Notfallwiederherstellung und lokale Vertragskopien sind organisatorisch geregelt.
  • Physischer Rechenzentrumsschutz wird über Providerbelege geprüft. Überlastungs- und DDoS-Schutz, Datenschutz durch Technikgestaltung, kontrollierte Betroffenenprozesse sowie sichere Ausserbetriebnahme von Datenträgern, Instanzen und Providerressourcen sind zusätzliche verbindliche V1-Schutzbereiche.
  • Jede produktionsrelevante Massnahme besitzt einen Nachweis mit Geltungsbereich, verantwortlicher Funktion, Referenz, Prüfdatum, prüfender Person, Methode, Ergebnis, Abweichung, Behebungsverantwortlichem, Zieltermin und nächster Prüfung. Sicherheitskritische Detailbelege und Geheimnisse werden nicht öffentlich im Repository abgelegt.
  • Ein obligatorisches Vier-Augen-Prinzip gilt in V1 nicht für jede Änderung. Kritische Änderungen werden nach Möglichkeit gegengeprüft; bei Einzelbesetzung werden Grund, Tests und nachträgliche Kontrolle dokumentiert.
  • Die TOM-Übersicht und ihre Nachweise werden mindestens jährlich sowie nach wesentlichen Architektur-, Provider-, Rechts- oder Sicherheitsänderungen geprüft.

11.7 Speicherbegrenzung und kontrollierte Löschung

  • Die zentrale Fristenmatrix ist für UC00 verbindlich. Sie unterscheidet operative Daten, Verträge, Geheimnisse, sechs Protokollarten, E-Mail-Nachweise, Uploadquarantäne und Backups.
  • RF-03 ist vorläufig eine zehnjährige konservative DACH-Vertragsnachweisfrist und keine Behauptung einer identischen gesetzlichen Mindestfrist. Der geplante Betrieb als Schweizer Einzelunternehmen und die endgültige Firma, Adresse, Register- und Steuerangaben werden vor Produktivbetrieb gemäss juristischem Prüfbriefing bestätigt.
  • Authentifizierungsprotokolle werden sechs Monate, allgemeine Auditdaten drei Jahre, Access-Protokolle ein Jahr, Systemprotokolle 30 Tage, Löschprotokolle drei Jahre und Versandnachweise 90 Tage aufbewahrt. Vertragsrelevante Audit- und Zugriffsnachweise folgen der zehnjährigen Vertragsfrist.
  • Ein täglicher idempotenter Retention-Job löscht fällige SQL-Daten und Objekte gemeinsam. Fehler lösen Alarm und Wiederholung aus; Löschläufe werden monatlich stichprobenartig geprüft.
  • Ein dokumentierter legal_hold darf die Löschung nur für einen konkreten Rechtsstreit, eine behördliche Anordnung oder eine nachgewiesene Pflicht aussetzen. Grund, Umfang und Fortbestand werden mindestens jährlich geprüft.
  • Gelöschte Primärdaten laufen innerhalb von höchstens 35 Tagen aus rollierenden Backups aus. Eine Wiederherstellung darf planmässig gelöschte Daten nicht unkontrolliert reaktivieren.

12. Offene Entscheidungen und Folgeverweise

ID Offener Punkt Folgekriterium
DK-01 Speicher- und Löschfrist je Verarbeitung und Feldgruppe technisch über Retention-Klassen umsetzen UC00-08-52
DK-02 Hostpoint-Produktivnachweise, Auftragsbearbeitungsvereinbarung, Regionen, Unterauftragnehmer und Vertragsgrundlage abschliessen UC00-07-12, ADR-016
DK-03 Tenant-Offboarding und Behandlung reservierter E-Mail-Adressen festlegen Erledigt; ADR-017
DK-04 Vertragsmodell, Statuswerte, Versionierung und Dokumentenspeicher technisch festlegen UC00-04-02
DK-05 PDF-Format und privater Objektspeicher sind mit ADR-013 entschieden; 10-MB-Grenze, fünfminütige signierte Anwendungslinks, backendvermittelte Downloads und Malware-Prüfung technisch umsetzen UC00-04-02, UC00-08-46, ADR-019
DK-11 Server- und Oberflächenvalidierung für vollständige rechtliche Bezeichnung und Vertragsanschrift vor AVV-Abschluss umsetzen UC00-05-05, UC00-08-08
DK-12 Vertragskontakt, Unterzeichner und Tenant-Admin getrennt modellieren; Mehrfachrollen derselben Person zulassen UC00-04-02, UC00-08-09
DK-13 Sichtbarkeitsfelder für öffentliche Kontakt-E-Mail, Festnetz und Mobilnummer standardmässig deaktiviert ergänzen UC00-04-02, UC00-08-10
DK-14 Einheitliches Vertragsmodell mit sechs Statuswerten, Parteiensnapshot, PDF-Objektschlüssel und SHA-256-Nachweis implementieren UC00-04-02, UC00-08-11
DK-15 Gehashten, einmaligen Vertragstoken mit sieben Kalendertagen Laufzeit und Widerruf bei Neuanforderung implementieren UC00-05-07, UC00-08-12
DK-16 Externen Upload und separate Prüfung auditieren; dieselbe Superadmin-Person in V1 zulassen UC00-05-08, UC00-08-13
DK-17 E-Mail-Normalisierung an allen Grenzen und globale Konfliktprüfung bei Änderungen umsetzen UC00-08-01
DK-18 Konto erst nach erfolgreicher 2FA aktivieren und lastLoginAt erst nach vollständiger Anmeldung setzen UC00-08-14
DK-19 Passwort-Hashing auf Argon2id umstellen und bcrypt-Hashwerte beim Login migrieren UC00-08-15
DK-20 TOTP-Geheimnis verschlüsseln und Schlüssel ausserhalb der SQL-Datenbank verwalten UC00-08-16
DK-21 Wiederherstellungscodes nur als Hash speichern, Feld eindeutig benennen und Vorgänger bei Reset invalidieren UC00-08-17
DK-22 Einladungstoken nur als Hash speichern und Klarwerte aus Persistenz und Protokollen ausschliessen UC00-08-18
DK-23 Sicherheitsbedingten vollständigen Sitzungswiderruf vereinheitlichen UC00-08-19
DK-24 Temporäre 2FA-Sitzungen zentral, kurzlebig, einmalig und versuchsbegrenzt speichern UC00-08-20
DK-25 Rechtliche Tenant-Daten von operativen Daten in einem Eins-zu-eins-Modell TenantProfile trennen UC00-04-02, UC00-08-22
DK-26 Persistentes Vier-Schritt-Onboarding mit Status und Zeitpunkten implementieren UC00-08-23
DK-27 OpenAPI und Backend auf school_profile, contact_details, first_employee, confirmation vereinheitlichen UC00-08-24
DK-28 Pflichtfelder, Schrittfolge, Draft-Wiederaufnahme und idempotenten Abschluss serverseitig umsetzen UC00-08-25
DK-29 Veröffentlichungsfreigaben für E-Mail, Festnetz, Mobiltelefon und Website getrennt und standardmässig deaktiviert umsetzen UC00-08-26
DK-30 Tenant-Lifecycle contract_pending, onboarding, active im Datenmodell und Backend abbilden UC00-08-27
DK-31 Falsche Fertigmeldungen zum Onboarding-Modell korrigieren und Schemaabgleich wiederholen UC00-10-02
DK-32 Protokollmodelle um Kontext, feste Ereigniskataloge, Ergebnis, Grundcode und Korrelations-ID vereinheitlichen UC00-08-29
DK-33 Vollständige Authentifizierungsereignisse mit pseudonymisiertem unbekanntem Anmeldebezug und überwachtem Ausfall umsetzen UC00-08-30
DK-34 Plattform- und Tenant-Audit mit Feld-Whitelist sowie transaktionaler Pflicht für kritische Änderungen umsetzen UC00-08-31
DK-35 Administrative Lese-, Download-, Export-, Support- und Logzugriffe in AccessLog nachweisen UC00-08-32
DK-36 Strukturierte Systemprotokollierung mit Geheimnisfilter, standardisierten Fehlercodes und Alarmierung umsetzen UC00-08-33
DK-37 DeletionLog.dataSnapshot entfernen und minimierten Lösch- und Anonymisierungsnachweis implementieren UC00-08-34
DK-38 Minimierten UC00-E-Mail-Versandnachweis ohne Nachrichteninhalt und Token umsetzen UC00-08-35
DK-39 Append-only Rechte, kontrollierte Retention, Manipulationserkennung und Protokollzugriffsaudit umsetzen UC00-08-36, ADR-018
DK-40 Versand von Wiederherstellungscodes per E-Mail aus dem Backend entfernen UC00-08-28
DK-41 Provider- und Unterauftragnehmerregister vollständig prüfen und je produktivem Dienst freigeben UC00-07-09
DK-42 Hostpoint-Produkt für automatisierten Transaktionsversand, Volumen, Standorte, Unterauftragnehmer, Löschung und Sicherheit produktiv freigeben UC00-07-12, UC00-08-54, ADR-016
DK-43 Supabase technisch und organisatorisch auf synthetische Entwicklungsdaten begrenzen UC00-08-37
DK-44 Hetzner Object Storage Nürnberg und Falkenstein, AWS KMS sowie Grafana Cloud Pro Frankfurt produktiv freigeben UC00-07-09, UC00-08-38, ADR-019, ADR-020, ADR-021
DK-45 Produktivdaten in Test- und Demo-Umgebungen verhindern und Anonymisierungsprozess absichern UC00-08-39
DK-46 Vierstündige Infrastruktur-, achtstündige tenantfreigegebene Support- und einstündige Notfallzugriffe mit eingeschränkten Rollen, Audit, Länderprüfung, Tenant-Information und Einsatzende gemäss ADR-023 umsetzen UC00-08-40, ADR-023
DK-47 Serverseitige Standardverweigerung, persönliche Admin-Konten, RLS und quartalsweise Rechteprüfung umsetzen UC00-08-41
DK-48 Globale und verschärfte Auth-Ratenbegrenzung, sichere Cookies, CSRF-Schutz und Sitzungswiderruf umsetzen UC00-08-42
DK-49 AWS-KMS-Envelope-Encryption, minimale technische Identität, geschützten Berechtigungs-Bootstrap, Rotation und Schlüsselnotfallprozess gemäss ADR-019 umsetzen UC00-08-43, ADR-019
DK-50 TLS, Verschlüsselung im Ruhezustand, private Netze und Serverhärtung nachweisen UC00-08-44
DK-51 Konkrete DTOs, Eingabegrenzen, Sicherheitsheader und bereinigte Fehler vollständig umsetzen UC00-08-45
DK-52 PDF-Prüfung, verschlüsselte Quarantäne, eigenbetriebenen ClamAV-Scan mit stündlichen Updates und Zwei-Stunden-Freigabeschwelle, private SSE-C-Ablage sowie höchstens fünfminütige backendvermittelte Anwendungslinks umsetzen UC00-08-46, ADR-019, ADR-022
DK-53 WAL-basierte PITR, tägliche und wöchentliche Sicherungen, getrennten Falkenstein-Bucket, RPO von einer Stunde, RTO von acht Stunden und Prüfintervalle gemäss ADR-020 umsetzen UC00-08-47, ADR-020
DK-54 Grafana Alloy und Grafana Cloud Pro mit Label-Positivlisten, Logfiltern, Mindestabdeckung, Alarmempfängern, Kostenwarnungen und monatlicher Nutzungskontrolle gemäss ADR-021 umsetzen UC00-08-48, ADR-021
DK-55 Schwachstellenmanagement, SBOM, ASVS-Prüfung und Penetrationstests etablieren UC00-08-49
DK-56 Incident-Response-Prozess, Register und jährliche Übung einführen UC00-08-50
DK-57 Alle 33 technischen und organisatorischen Massnahmen mit dem verbindlichen Nachweismodell zentral pflegen, umsetzen und regelmässig auf Wirksamkeit prüfen UC00-07-10, UC00-08-51
DK-58 Retention-Klassen, Fristbeginn, retainUntil, begründete Aufbewahrungssperre und tägliche Löschläufe implementieren UC00-08-52
DK-59 SQL-Daten, Objektspeicher, Provider und Backups fristgerecht und gemeinsam löschen sowie Fehler alarmieren UC00-08-53
DK-60 Juristische Länderprüfung der Vertrags- und gesetzlichen Aufbewahrungsfristen vor Produktivbetrieb abschliessen UC00-07-11
DK-06 Rollenwechsel zwischen eigener Verantwortlichkeit und Auftragsverarbeitung juristisch prüfen UC00-07-05
DK-07 Regeln für Test- und Demo-Tenants festlegen UC00-07-06
DK-08 Schwellenprüfung für eine Datenschutz-Folgenabschätzung durchführen Erledigt; DSFA-Schwellenprüfung
DK-09 Protokollfelder und Payload-Filter gegen tatsächlichen Backend-Code prüfen UC00-08-04
DK-10 Datenschutzerklärung und Verzeichnis der Verarbeitungstätigkeiten aus diesem Katalog ableiten Projektstatus Compliance

13. Quellen

14. Abnahme

Prüfung Status
Abgleich mit UC00-Spezifikation Durchgeführt
Abgleich mit aktuellem Prisma-Schema Durchgeführt
Abgleich mit OpenAPI-Verträgen Durchgeführt
Fachliche Prüfung durch Product Owner Offen
Juristische Prüfung vor Produktivbetrieb Offen
Speicherfristen über UC00-07-02 Fachlich durchgeführt; technische Umsetzung und juristische Länderprüfung offen

Bis zur fachlichen Prüfung bleibt UC00-07-01 im Status Zur Prüfung.