Risikoregister (Medidentas)
Kernaussage (BLUF). 34 erfasste Risiken; 21 vorrangig (Score ≥6), davon zwei mit Höchst-Score 9: RISK-15 — PII in US-/Cloud-KI-Diensten (Whisper/ChatGPT/Grammarly) und RISK-33 — Kunden-Self-Service-Portal (neue extern-authentifizierte Fläche). Schwerpunkte der ≥6-Risiken: Datenschutz/PII (DSGVO/revDSG), E-Signatur-Rechtswirkung (eIDAS/ZertES) und regulatorische DACH-Themen. Vorrangige (≥6) zuerst lesen.
Gesamtsichtung 2026-07-24 (v0.99.8, MED-D-212, Doku-Welle 6): Register gegen das Akten-Cockpit-Programm (MED-D-188…210) + Welle 10 gegengeprüft. Kein neues eigenständiges Kritik-Risiko; die einzige substanzielle Neuerung — der 1:n-Bankkonto-PII-Ausbau (MED-D-195) — ist in RISK-28 aufgenommen (identifizierende Finanz-PII, hängt am selben MED-KB-6). Der gebaute Vor-Ort-/Demo-eSignatur-Abschluss (MED-D-198) ist rechtswirkungs-relevant, aber über die Fake-Provider-Attrappe (MED-KB-5, nie fälschbare echte Vorgänge) abgesichert → kein neues Risiko.
Nachtrag 2026-07-24 (MED-D-220, DocuSign-Adapter, 0.100.0): Der erste echte E-Signatur-Adapter
ist gebaut (dormant ohne Secret, noch nicht live). Das aktiviert zwei bestehende Risiken konkret ohne neues
Risiko: RISK-4 (AVV/US-Transfer — vor dem ersten Live-Envelope zwingend, s. Compliance.md) und RISK-2
(die QES→AES-mit-Hinweis-Herabstufung über den Dev-Account ist eine bewusste, sichtbar gekennzeichnete
Zwischenlösung — echte QES braucht CSP-Anbindung, bis dahin QES-Dokumente nicht produktiv einsetzen). Beide
Zeilen unten aktualisiert.
Lebendes Register relevanter Risiken (Technik · Sicherheit · Datenschutz · Regulatorik) für die Zielmärkte DE · AT · CH und generell. Pflicht (CLAUDE.md §Compliance): zu Session-/PR-Beginn die relevanten Risiken sichten, neue eintragen, Status/Maßnahme pflegen; bei kritischen/regulatorisch relevanten Themen aktiv hinweisen + Optionen zeigen.
Skala: W = Wahrscheinlichkeit (1 niedrig · 2 mittel · 3 hoch) · A = Auswirkung (1 · 2 · 3) · Score = W×A (1–9; ≥6 = vorrangig). Status: offen · in Arbeit · gemindert · akzeptiert.
| ID | Risiko | Bereich | W | A | Score | Status | Maßnahme / Owner | Bezug | Letzte Prüfung |
|---|---|---|---|---|---|---|---|---|---|
| RISK-1 | Klartext-PII in Logs/State/URLs (DSGVO/revDSG DE/AT/CH) | Datenschutz | 2 | 3 | 6 | offen | PII-Scrubbing im Logger-Wrapper; EU-/CH-Residenz; Datenminimierung (Kunde = Name + CRM-Link, S-1) | OP-DSGVO-1, OP-OBS-1, G-5 | 2026-07-14 |
| RISK-2 | E-Signatur rechtlich unzureichend (falsches eIDAS-Niveau für Dokumenttyp → Vertrag anfechtbar) | Regulatorik | 2 | 3 | 6 | in Arbeit | Niveau-Matrix gebaut (Slice 4): Vollmacht→QES, Vertrag→AES, Mandat→SES (domain/signatur-niveau.ts). DocuSign-Adapter gebaut (MED-D-220): versendet QES-Dokumente über den Dev-Account als AES mit sichtbarem Hinweis (bewusste Zwischenlösung, nicht produktiv für echte QES) — echte QES erst mit CSP-Anbindung. Rest: QES-CSP je Niveau + Live-Verifikation (OP-SIGN-1) | OP-SIGN-1, A-2, R4, MED-D-220 | 2026-07-24 |
| RISK-3 | Beratungsdokumentations-Pflicht nicht erfüllt (Versicherungs-/Finanzanlagen-/Immobiliardarlehensvermittlung) | Regulatorik | 2 | 3 | 6 | offen | Branche bestätigt (OP-DOMAIN-1 ✅); Pflichtfelder je Themenbereich aus §34d GewO/§61–62 VVG (IDD), §34f GewO/§18 FinVermV, §34i GewO ableiten; Audit-Log danach ausrichten | OP-DOMAIN-1, R6, G-4 | 2026-07-14 |
| RISK-4 | Auftragsverarbeitung Dritter ohne AVV (NextCloud-Hosting, DocuSign/PandaDoc) | Datenschutz/Vertrag | 2 | 3 | 6 | offen | AV-Verträge schließen; Datenresidenz prüfen (US-Transfer bei DocuSign → SCC/DPF/Adequacy). Jetzt konkret (MED-D-220): DocuSign-Adapter gebaut (dormant) → vor dem ersten Live-Envelope AVV + Transfermechanismus + EU-Residenz-Option zwingend (s. Compliance.md); ohne Absicherung bleibt der Provider auf fake | OP-DSGVO-1, A-1, A-2, MED-D-220 | 2026-07-24 |
| RISK-5 | Audit-Log lückenhaft / manipulierbar → Rechtssicherheit verloren | Daten/Audit | 1 | 3 | 3 | gemindert | Append-only D1-Store + SHA-256-Hash-Verkettung + verify (Slice 6) erkennt Änderung/Löschung; quer verdrahtet (PII-arm). Rest: Cold-Storage-Archiv + Concurrency-Härtung der globalen Kette (OP-AUDIT-1) | OP-AUDIT-1, G-4, R8 | 2026-07-14 |
| RISK-6 | Externer Dienst nicht erreichbar (NextCloud/Signatur) → Status driftet, Vorgang hängt | Verfügbarkeit | 2 | 2 | 4 | gemindert | Idempotente Reconciliation (Dokument-/Signatur-Abgleich, Slices 2/4) + Cron-idempotente Erinnerungen (Slice 3); Webhook-Push gebaut (0.49.0/MED-D-55): NextCloud-Webhook angefordert→erhalten (Webhook Listeners App, NC≥30), Pull-abgleich bleibt Fallback (robust bei verpasstem Event). Rest: Retry/Queue bei Push-Zustellfehlern | R9, A-5, R5 | 2026-07-14 |
| RISK-7 | Aufbewahrungsfristen verletzt (zu früh gelöscht / zu lange gehalten) | Regulatorik | 2 | 2 | 4 | offen | Retention-/Löschkonzept je Dokumenttyp (GoBD/§147 AO + branchenspezifisch) | OP-DSGVO-1, OP-AUDIT-1 | 2026-07-14 |
| RISK-8 | Secret-Leak (NextCloud-App-Passwort · Signatur-API-Key · CRM-Token) | Secrets/CI | 1 | 3 | 3 | gemindert | Keine Secrets im Repo (GitHub-/Env-Secrets), least-privilege, Rotation/Ablauf; Cloudflare Access vor dem Worker (Slice 7) schützt die API; Audit-Actor = echte Identität (nicht mehr system-Platzhalter) | OP-AUTH-1, R7 | 2026-07-14 |
| RISK-9 | Supply-Chain / verwundbare Dependencies | Sicherheit | 2 | 2 | 4 | offen (App-Phase) | SBOM + Dependency-Audit + Dependabot + gepinnte Actions — sobald Anwendungscode existiert | — | 2026-07-14 |
| RISK-10 | Cross-Mandanten-Zugriff (falls Mehr-Mandanten-Betrieb); auch Cross-Tool-Zugriff (Spezial-Tools) | Multi-Tenancy | 2 | 3 | 6 | in Arbeit | Authn + Rollen-RBAC gebaut (Slice 7); RBAC je Mandant gebaut (0.46.0/D-48): Access-Identität je Request; Rechte-Matrix (domain/rechte.ts) + Mandant-Scope über verantwortlich an zwei Chokepoints (Aggregate + /api/mandanten/:id*-Middleware, Fremd→404 statt 403 = kein Existenz-Leak); Feature-Flag rbac_mandant_scope_aktiv (Default aus, kontrollierter Rollout, Rückdrehen ohne Deploy). Restrisiko: feingranulare Sub-Entitäts-Guards (Routen mit eigener Objekt-ID, z. B. /api/dokumente/:id) noch offen — Defense-in-Depth (alle Nutzer sind Mitarbeiter hinter Access, kein öffentlicher Rand); SCIM/Gruppen-Sync; Tenant-/Tool-Isolation (R10); vor Mehr-Mandanten-Betrieb Pentest | OP-AUTH-1, OP-EXT-1 | 2026-07-14 |
| RISK-11 | Behandler-Leistungskontrolle (Dexman: Umsatz/Leistung je Behandler) ohne Mitbestimmung/Rechtsgrundlage → BetrVG-/Beschäftigtendatenschutz-Verstoß | Regulatorik/Personal | 2 | 3 | 6 | offen | Behandler-Vergleiche rollen-gegated; § 87 Abs. 1 Nr. 6 BetrVG (Betriebsrat) + § 26 BDSG beachten; Zweckbindung, Transparenz, Normalisierung | OP-DEX-4, R7 | 2026-07-14 |
| RISK-12 | Gesundheits-/Sozialdaten (DSGVO Art. 9) im Dexman-Datenfluss aus PVS → besondere Kategorien, Schweigepflicht | Datenschutz | 2 | 3 | 6 | offen | Datenminimierung/Aggregation, AV-Verträge mit PVS/Bank/Buchhaltung, EU-/CH-Residenz, Pseudonymisierung wo möglich | OP-DSGVO-1, OP-DEX-1 | 2026-07-14 |
| RISK-13 | Falsche Controlling-Stammdaten (Sätze/Benchmarks/Kostenzuordnung) → irreführende Margen/Prognosen | Daten/Steuerung | 2 | 2 | 4 | offen | Sprechende, editierbare Stammdaten; Plausibilisierung; Daten-Lineage (Kennzahl→Quelle) | DEX-1, DEX-2 | 2026-07-14 |
| RISK-14 | KI-generierte Beratungsdoku fehlerhaft/unvollständig → Falschberatung/Haftung; KI-"Rechtssicherheits-Check" wird als Freigabe missverstanden | Regulatorik/Haftung | 2 | 3 | 6 | in Arbeit | Umgesetzt (Slice 5): pruefstatus trennt ki_geprüft (Assistenz) von freigegeben (Mensch); Prüf-Hinweis nennt Haftungsgrenze explizit; Inhaltsänderung setzt Prüfstand zurück. Rest: echtes Medidentas-GPT-Briefing versionieren (OP-AI-1) | OP-AI-1, R6 | 2026-07-14 |
| RISK-15 | PII in US-/Cloud-KI-Diensten (Whisper/ChatGPT/Grammarly/Plaud/Krisp/Notion-AI) ohne AVV/EU-Residenz → DSGVO-Verstoß; Gesundheits-/Finanzdaten (Art. 9) | Datenschutz | 3 | 3 | 9 | offen | Nur Dienste mit AVV + EU-Residenz; keine Vollaufnahme (nur Zusammenfassung); Einwilligungs-/Hinweis-Flow; Datenminimierung, Roh-Audio nicht persistieren | OP-MEET-1, OP-AI-1, OP-DSGVO-1, G-5 | 2026-07-14 |
| RISK-16 | NextCloud-Auth via App-Passwort (Basic Auth) → keine Rotation/Ablauf, breiter Scope; Secret-Leak = voller Datei-Zugriff | Sicherheit | 2 | 2 | 4 | akzeptiert (begründet) | OAuth2 verworfen (MED-D-55): NextCloud-OAuth2 kann kein client_credentials/kein Scoping → für Maschinen-Zugriff untauglich; App-Passwort auf technischem Service-User ist der korrekte Weg. Minderung: Secret nur via GitHub-/Worker-Secret (nie im Repo, RISK-8), least-privilege-Konto, Rotation (App-Passwort widerrufbar ohne Hauptpasswort), ggf. Group-Folder-Scope (OP-DOC-1-Rest) | OP-DOC-1, A-1, R9 | 2026-07-14 |
| RISK-18 | Einwilligung rechtlich unzureichend dokumentiert (Self-Service-SES) → Einwilligung anfechtbar/nicht nachweisbar | Regulatorik/Datenschutz | 2 | 3 | 6 | in Arbeit | SES gebaut (Slice 9): Ankreuzen + Name + Absenden, append-only auditiert (G-4, Inhalts-Hash) + Einwilligungs-Fassung als Dokument (R3). Rest: Einwilligungstext juristisch prüfen, Widerrufs-/Auskunftsprozess (Art. 7/15 DSGVO), Versionierung der Textfassung. | OP-ONBOARD-1, OP-DSGVO-1, R2/R4 | 2026-07-14 |
| RISK-19 | Öffentlicher Onboarding-Endpunkt (außerhalb Cloudflare Access) → Bot-/Spam-/Enumeration-Fläche, PII-Einreichung durch Unbefugte | Sicherheit | 2 | 2 | 4 | in Arbeit | Token-gebunden + Ablauf + Einmal-Einreichung (Slice 9); Turnstile vorgesehen (optional, TURNSTILE_*). Rest: Access-Bypass nur für /onboarding*+/fragebogen*+/oeffentlich* (nicht weiter; /fragebogen* = Dentmarking T5, gleiche Token-Mechanik), Turnstile produktiv aktivieren, Rate-Limiting. | OP-ONBOARD-1, OP-AUTH-1 | 2026-07-14 |
| RISK-17 | Datenresidenz außerhalb der EU beim Deploy (D1-Region · Cloudflare-Metadaten/Logs · NextCloud-Hosting · Signatur-Provider) → DSGVO/revDSG-Verstoß. EU-Residenz ist Pflicht (Nutzer-Vorgabe 28.06.). | Datenschutz | 2 | 3 | 6 | offen | D1 mit --location weur (EU), NextCloud EU-gehostet (A-1), Cloudflare Data Localization Suite (Regional Services + EU Metadata Boundary), Signatur-Provider mit EU-Residenz/AVV (OP-SIGN-1); keine US-Sub-Prozessoren ohne SCC (RISK-4/15). Vor Go-live verbindlich prüfen. | OP-DEPLOY-1, OP-DSGVO-1, G-5 | 2026-07-14 |
| RISK-20 | Vorformulierte Kunden-Pauschalbestätigung (R6-F20: "alles verstanden / über alles aufgeklärt / Hinweise selbst gegeben / exakt empfohlenes Produkt / zufrieden") → begrenzter Beweiswert (BGH), Gefahr unwirksamer/überraschender Klauseln und faktischer Umkehr der Dokumentationslast; ersetzt die konkrete Beratungsdoku nicht | Regulatorik/Haftung | 2 | 3 | 6 | in Arbeit | Feld gebaut (Slice 10) als eigenes Ankreuzfeld neben F06/F11–F18 (nicht statt) — die konkrete, individuelle Beratungsdoku bleibt führend. Rest: Formulierung/UX juristisch prüfen, append-only Audit je Feldänderung (G-4). | OP-BERATDOK-1, RISK-14, R6 | 2026-07-14 |
| RISK-21 | Gesetzliche Arbeitszeiterfassung (ArbZG) vermengt mit abrechenbarer Leistungszeit → falls Beginn/Ende/Pausen der Mitarbeiter erfasst werden: Mitarbeiter-PII, BetrVG-Mitbestimmung (§87), Aufbewahrung — bei Vermischung mit R13 (Kunden-/Leistungsdaten) Zweckbindungs-/DSGVO-Verstoß | Datenschutz/Arbeitsrecht | 2 | 3 | 6 | offen | R13 Leistungszeit erfasst nur abrechenbare Kundenleistung (OP-TIME-1), nicht die gesetzliche Arbeitszeit. Diese ist als eigener OP-TIME-2 getrennt zu führen (eigenes Datenmodell, Betriebsrat-Beteiligung, ggf. separates Tool). Vor Umsetzung von OP-TIME-2: BetrVG + AVV klären. | OP-TIME-2, OP-DSGVO-1 | 2026-07-14 |
| RISK-22 | Kunden-Excels mit Klartext-PII als Analyse-/Import-Input (Dexman-Altbestand: IBANs, Kredit-/Policen-Nummern, Namen, Orts-/Objektangaben in Freitexten, Klarnamen sogar in Dateinamen/-pfaden; Passwortschutz der Mappen ist kein wirksamer Schutz) → DSGVO-Verstoß bei Ablage im Repo/unkontrollierter Weitergabe | Datenschutz | 2 | 3 | 6 | in Arbeit | Original-Dateien nie ins Repo (nur Analyse in Session/NextCloud R3, EU); ins Repo nur anonymisierte Ableitungen nach festen Regeln (Dexman-Fachmodell.md §9: Pseudonyme, IBAN/Nummern entfernt, Institute als Gattung, Freitexte generalisiert, Beträge gerundet, Daten monatsgenau — für Beispieldaten angewendet). Arbeitskopien/Zwischenexporte (Session-Arbeitsbereiche, lokale Entschlüsselungen, NextCloud-Staging) nach Abschluss der Analyse löschen — Verantwortung: jeweilige/r Bearbeiter/in je Session. Beim künftigen Upload-Import (DEX-13): PII-Scrubbing als Pflichtschritt, AVV/Residenz je Ablageort. | DEX-13, OP-DEX-8, OP-DSGVO-1, G-5 | 2026-07-14 |
| RISK-23 | Alt-Werkzeug Dentmarking (Excel) mit Echtdaten im Datei-Umlauf: Fragebogen-PII (Kontakt + Wirtschaftsdaten) in Excel-Kopien auf Fileshares, Kundennamen in gespeicherten Dateipfaden, Blattschutz nur mit Klartext-Kennwort im VBA; Betroffenenrechte (Auskunft/Löschung) im Datei-Prozess faktisch nicht erfüllbar; DSGVO-Einwilligungstext ungeprüft | Datenschutz | 2 | 3 | 6 | offen | Neuimplementierung als Spezial-Tool (Dentmarking DM-1..DM-8, D-26): Speicherung in D1/EU, R7-Rollen statt Excel-Schutz, Audit (G-4), Einwilligung auditiert. Alt-Bestand: Excel-/Export-Kopien inventarisieren, bereinigen oder verschlüsselt archivieren (OP-DM-4); Einwilligungstext juristisch prüfen (analog RISK-18); keine PII aus Alt-Dateien ins Repo (G-5). | OP-DENTMARK-1, OP-DM-4, OP-DSGVO-1 | 2026-07-14 |
| RISK-24 | Self-hosted CI-Runner als Single Point of Failure + Angriffsfläche (D-29): Runner-Host führt Repo-Code aus und hält die Cloudflare-Secrets im Job-Kontext; ist der Host offline/kompromittiert, stehen CI + Auto-Deploys still bzw. sind Secrets/Deploys gefährdet | Betrieb/Sicherheit | 2 | 2 | 4 | offen | Runner nur für dieses private Repo registrieren (nie öffentliche Repos), Host gepatcht + zugriffsbeschränkt halten; Fallback dokumentiert: Repo-Variable CI_RUNNER=ubuntu-latest schaltet ohne Commit auf GitHub-Runner zurück (sobald Billing/Limit geklärt); Cloudflare-Token minimal berechtigt (nur Workers/D1/Pages Edit) | D-29, Deploy.md §7b | 2026-07-14 |
| RISK-25 | GwG-Verpflichteten-Status ungeklärt (D-30): Bei Vermittlung von Lebensversicherungen/Anlageprodukten (§ 34d/§ 34f GewO) greift voraussichtlich § 2 Abs. 1 Nr. 8 GwG → Identifizierungspflicht (§§ 11 ff. GwG) inkl. Aufzeichnung/Aufbewahrung; ohne geklärten Prozess drohen Bußgeld + Beweisprobleme | Compliance | 2 | 3 | 6 | offen | OP-GWG-1 klären (welche Produktklassen tatsächlich vermittelt werden); wenn verpflichtet: Vor-Ort-Identifizierung durch Berater im Termin als Standard (Ausweis, dokumentiert beim Mandanten + Audit-Event, G-4), VideoIdent/PostIdent nur als Fallback für terminlose Strecken; bei QES (OP-SIGN-1) Identifizierung des CSP mitnutzen; Aufzeichnungs-/Aufbewahrungspflicht ins Löschkonzept (Compliance-Tracker #4) | D-30, OP-GWG-1, OP-SIGN-1 | 2026-07-14 |
| RISK-26 | Mitarbeiter-Skill-/Lernziel-Daten als Beschäftigten-PII + Leistungsbewertungsnähe (OP-SKILL-1): Skill-Matrix + Lernziele je Mitarbeiter können als Leistungs-/Verhaltenskontrolle ausgelegt werden → in DE BetrVG-Mitbestimmung (§ 87 Abs. 1 Nr. 6), DSGVO-Zweckbindung; bei verdeckter Nutzung Konflikt-/Bußgeldrisiko | Datenschutz/Arbeitsrecht | 2 | 2 | 4 | offen | Skill-Daten zweckgebunden (Aufgabenverteilung + Kompetenzentwicklung, nicht verdeckte Leistungskontrolle); Betriebsrat früh beteiligen (analog RISK-21/OP-TIME-2), Transparenz für Mitarbeiter, Datenminimierung (nur benötigte Skills/Niveaus); Aufbewahrung/Löschung ins DSGVO-Konzept | OP-SKILL-1, OP-DSGVO-1 | 2026-07-14 |
| RISK-27 | Lesezugriff auf sensible/Art.-9-Daten nicht protokolliert (D-48): Das Audit-Log (Slice 6) erfasst nur zustandsändernde Ereignisse, nicht reine Lesezugriffe. Wer eine Beratungsdoku, den Gesundheitsbogen (R6-F18, Art. 9) oder einen ganzen Mandanten einsieht, hinterlässt keine Spur → unbefugter Zugriff nicht erkennbar, im Breach-Fall (Art. 33) nicht aufklärbar, Betroffenenauskunft (Art. 15) unvollständig. Für besondere Kategorien ist Zugriffsprotokollierung aufsichtsseitig State of the Art (Art. 5(2)/24/32 DSGVO, revDSG, ISO 27001 A.12.4). | Datenschutz/Audit | 2 | 3 | 6 | in Arbeit | Gebaut (0.48.0, D-50): append-only, PII-armes Event aktion=eingesehen auf einer Whitelist (domain/zugriff.ts: mandant = ganzer Mandant · beratungsdoku inkl. Gesundheitsbogen R6-F18 · dokument = Datei-Inhalt signierter Dokumente R4) in der bestehenden R8-Hash-Kette; verdrahtet an GET /api/mandanten/:id · …/beratungsdoku · …/dokumente/:id/datei; Listen/Cockpit/Navigation nicht einzeln (G-6, per Test abgesichert). Rest: Dexman/PVS-Art.-9-Lese-Endpoints (noch nicht gebaut), Retention der Zugriffs-Events ins Löschkonzept (Compliance #4). Kopplung RISK-11/21/26: Zugriffslog nicht zur Mitarbeiter-Leistungskontrolle zweckentfremden (§87 BetrVG → KB-3, organisatorisch offen). | D-50, G-6, R8, OP-AUDIT-1, KB-3 | 2026-07-14 |
| RISK-28 | Neue sensible Stammdaten-PII ohne Feld-Verschlüsselung-at-rest + ohne Retention/Löschkonzept (MED-D-84): Formular-Rückübernahme persistiert jetzt Geburtsdatum · Anschrift · Telefon (zusätzlich zur privaten IBAN, MED-D-71) im Klartext in D1. Ausgeweitet (MED-D-195, Akten-Cockpit S3a): die neue 1:n-Bankkonto-Entität persistiert je Mandant zusätzlich Kontoinhaber-Namen · mehrere IBANs · Zeichnungsberechtigung · Praxis-/Privat-Kontext — deutlich mehr identifizierende Finanz-PII (append-only, kein Löschen → Archivieren via Prüfstatus, was die Retention-Frage verschärft). Geburtsdatum/Adresse sind identifizierende Personendaten; ohne definierte Aufbewahrungsfrist + Löschprozess drohen DSGVO-Verstöße (Art. 5(1)(e) Speicherbegrenzung, Art. 17 Löschung, Art. 32 Verschlüsselung as-appropriate). | Datenschutz | 2 | 3 | 6 | offen | G-6 begründet + minimiert (nur Felder mit Zweck: Kontakt/Identität/Vertrag; nullable; Übernahme nur per Review-and-apply, nicht automatisch). EU-Residenz (D1 EU). Offen (MED-KB-6, Kundenentscheidung): Feld-Verschlüsselung-at-rest (Application-Layer oder D1-seitig) und Retention/Löschkonzept für Geburtsdatum/Adresse/IBAN — bis dahin bewusst im Klartext (wie IBAN MED-D-71). Audit der Übernahme bleibt PII-arm (nur Feldschlüssel/Zähler). | MED-D-84, MED-D-195, MED-KB-6, G-5/G-6, RISK-22/23 | 2026-07-24 |
| RISK-29 | Self-hosted CI-Runner-Pool (hot) kann Runs verklemmen (2026-07-22, Doku-Welle 5a): ein pull_request-Run blieb 30+ min in queued ohne Runner-Zuweisung (0 Jobs), war weder per API-cancel (2×202, wirkungslos) noch per PR-close/reopen tötbar und hielt die Concurrency-Gruppe → keine PR mergebar. Blockiert den Merge-/Deploy-Fluss. | Technik/CI | 2 | 2 | 4 | gemindert | Mitigation (MED-D-185): Repo-Variable CI_RUNNER=ubuntu-latest → CI läuft auf GitHub-hosted Runnern (kein self-hosted Queue-Deadlock; Workflow nutzt für Forks ohnehin ubuntu-latest). Bewusst hosted belassen (Nutzerentscheidung 2026-07-22). Rückweg zu hot nur bei Kosten-/Policy-Grund. Force-cancel eines verklemmten Runs braucht den Admin-force-cancel-Endpoint (regulärer cancel reicht nicht). | MED-D-185, .github/workflows/ci.yml | 2026-07-22 |
| RISK-30 | Steuernummer & Steuer-ID als neue Stammdaten-PII (2026-07-25, MED-D-241): der Design-Prototyp "Akten-Cockpit 1a" zeigt im Stammdaten-Grid Steuernummer und Steuer-ID — beide sind heute nicht im Datenmodell. Die deutsche Steuer-Identifikationsnummer ist besonders reguliert (§139b AO): Erhebung/Verwendung nur für gesetzlich zugelassene Zwecke, kein allgemeines Ordnungs-/Suchmerkmal; unnötige Speicherung verstößt gegen Zweckbindung/Datenminimierung (DSGVO Art. 5, G-5/G-6). | Compliance/DSGVO (DE) | 2 | 3 | 6 | offen | Bewusst NICHT eingebaut — die zwei Felder aus dem Prototyp-Grid wurden bei der Design-Übernahme (MED-D-241) ausgelassen (Kommentar im Code + Rail-Grid). Vor einer etwaigen Aufnahme: Zweck + Rechtsgrundlage je Feld klären (wofür braucht Medidentas die Steuer-ID überhaupt?), Aufbewahrung/Löschkonzept, Aufnahme ins Weltmodell/Data-Dictionary (G-8) — erst dann Persistenz. Default = nicht speichern. Kundenklärung: MED-KB-10. Update MED-D-284 (2026-08-27): die Steuernummer ist jetzt — datensparsam — aufgenommen (Wertobjekt Steuer, ins Data-Dictionary katalogisiert, Zweck/Rechtsgrundlage in RISK-34); dieser Teil ist erledigt. Das Risiko scoped damit nur noch auf die weiterhin ausgeschlossene Steuer-ID (§139b AO) — Default bleibt: nicht speichern. | MED-D-241, MED-D-284, MED-KB-10, docs/architektur/Weltmodell-Data-Dictionary.md | 2026-07-25 |
| RISK-31 | Selbst-Rollenwahl in der UI = Privilege-Escalation (2026-07-26, MED-D-260): der interim Selbst-Rollen-Wähler (POST /api/ich/rolle, Verwaltung „Meine Rolle") erlaubt jedem eingeloggten Nutzer, sich selbst zum Admin zu machen — bewusst OHNE benutzer_verwalten-Guard, um den Bootstrap-Deadlock zu lösen (leere benutzer-Tabelle + kein/falsch gesetztes AUTH_BOOTSTRAP_ADMIN → sonst ist NIEMAND Admin, die gesamte Admin-Verwaltung unerreichbar). Widerspricht RBAC/least-privilege (R7) und der Golden-Rule-Zero-Trust-Haltung. | Sicherheit/RBAC | 2 | 3 | 6 | akzeptiert (interim) | Gemindert durch Cloudflare Access: die Route ist nur für bereits authentifizierte, autorisierte Mitarbeiter erreichbar (Zero Trust vor Public), nicht öffentlich; jede Änderung ist append-only auditiert (benutzer.eigene_rolle_gesetzt, echter Actor, G-4). Bewusste Nutzer-Entscheidung „freie Selbst-Wahl" (2026-07-26). Rückbau vorgesehen: sobald die Rollen sauber vergeben sind, den Endpoint auf benutzer_verwalten gaten bzw. auf „nur solange kein Admin existiert" verriegeln oder entfernen und AUTH_BOOTSTRAP_ADMIN korrekt setzen. | MED-D-260, R7, G-5, Golden Rule (Zero Trust) | 2026-07-26 |
| RISK-32 | Web-Push-Datenschutz (2026-08-23, MED-D-275): die Live-Timer-Benachrichtigung nutzt Web-Push über Dritt-Gateways (Google/Mozilla/Apple/Microsoft); Push-Subscriptions (Endpoint + Client-Keys je Gerät) sind personenbeziehbar (DSGVO/revDSG), und ein PII-behafteter Notification-Inhalt würde über Dritte laufen. | Datenschutz | 2 | 2 | 4 | gemindert | By-Design gemindert: (a) daten-loses Push — der Server sendet nur ein VAPID-signiertes Wecksignal, keinerlei PII über die Gateways; der Service Worker holt den Stand erst danach hinter Cloudflare Access; (b) Subscriptions PII-arm gespeichert (user_agent auf 80 Zeichen gekürzt, G-6), Löschung bei 410/Abmeldung; (c) Notification-Inhalt PII-frei (nur Laufzustand + Minuten, kein Klarname); (d) opt-in (Notification-Permission); (e) VAPID-Keys als Secrets (kein Repo-PII, G-5), Feature dormant ohne Secret. Rest: AVV/Transfer-Betrachtung der Push-Dienste im Compliance-Dok vermerken; Retention der push_subscription-Zeilen (Ablauf/Rotation) festlegen. | MED-D-275, G-5, G-6, OP-DM-8 | 2026-08-23 |
| RISK-33 | Kunden-Self-Service-Portal = neue extern-authentifizierte Fläche (2026-08-27, MED-D-279): das geplante persistente Kunden-Login ist eine öffentlich erreichbare, authentifizierte Oberfläche — im Gegensatz zur Golden Rule „Zero Trust vor Public" (Default = abgeschottet). Angriffsflächen: Konto-Enumeration, Magic-Link-Abfang/Replay, Session-Hijacking, Brute-Force, Bot-Anmeldungen; DSGVO-Relevanz durch persistente Kundenkonten. | Sicherheit/Datenschutz | 3 | 3 | 9 | offen (Design; Gate vor Go-Live) | Minderung by-design (S2 umgesetzt, S5 offen): (a) passwortlos/Magic-Link → kein Passwort-Hash at rest (G-5/G-6); (b) keine Konto-Enumeration (immer „falls Konto existiert, Mail gesendet"); (c) Magic-Link Einmalgebrauch + kurze TTL; (d) Turnstile am Login (auth/turnstile.ts vorhanden) + Rate-Limiting je IP+Konto; (e) Session-Cookie HttpOnly/Secure/SameSite, absolute+Idle-Expiry, Logout=Widerruf; (f) strikte Prinzipal-Trennung vom Staff-Akteur + Scope-Guard „nur eigener Mandant"; (g) vorschlagend, nicht ausführend (Kunde schreibt nie den tatsächlichen Datenstand); (h) dormant/flag-gated bis DSGVO/AVV-Sign-off (MED-KB-13) + realer Mail-Seam (OP-DM-8). Bewusste, begründete Zero-Trust-Ausnahme — analog den vier öffentlichen Kundenstrecken, explizit dokumentiert. S2 gebaut (MED-D-283): flag-gated (PORTAL_AKTIV dormant-Default), No-Enumeration, Einmal-Token (atomarer Login), gehashte Session-Cookies, istEmail-Validierung, Sperr-Check auf laufende Sessions. Verbleibend vor Go-Live: Rate-Limiting/Turnstile am anmelden-Endpunkt + DSGVO/AVV + realer Mailversand (OP-DM-8) (S5). | MED-D-279, Golden Rule (Zero Trust), G-5, G-6, MED-KB-13, OP-DM-8 | 2026-08-27 |
| RISK-34 | Neue Persistenz personenbezogener Grunddaten (2026-08-27, MED-D-284): der Onboarding-Grunddaten-Katalog speichert zusätzliche PII am Mandanten — Handynummer, Steuernummer und (Fundament) der Steuerberater-Bezug (Name/Kanzlei/E-Mail/Telefon, PII einer dritten Person). Jede neue PII-Persistenz ist rechtfertigungspflichtig (G-6); Drittpersonendaten lösen zusätzlich die Art.-14-DSGVO-Informationspflicht aus. | Datenschutz | 2 | 2 | 4 | gemindert | Datensparsam by-design (G-6, Nutzer-Entscheidung): (a) bewusst KEINE Steuer-ID (§139b AO) und KEINE Ausweisnummer (§20 PAuswG); der Personalausweis bleibt Upload-Nachweis; (b) Zweck: Onboarding-Vollständigkeit + Kontakt-/steuerliche Korrespondenz; Rechtsgrundlage Art. 6 Abs. 1 b DSGVO; (c) alle Felder optional; (d) Art.-14-Gate geschlossen (Slice A): die Steuerberater-Felder werden auf der öffentlichen Onboarding-Strecke NICHT erhoben (nicht in STAMMDATEN_FELDER) — nur die eigenen Daten des Mandanten (Handynummer/Steuernummer, von der bestehenden Einwilligung Art. 6 I b gedeckt) sind öffentlich. Die Steuerberater-Spalten + Übernahme-Regeln bleiben als Fundament; die öffentliche/interne Erhebung der Drittpersonendaten kommt erst mit dem Art.-14-Informationspfad in Slice B (verbindlicher Gate vor Aktivierung). Aufbewahrung/Verschlüsselung-at-rest = MED-KB-6. NICHT im PII-armen Audit-Log (nur Feldschlüssel + Zähler). | MED-D-284, G-5, G-6, Art. 14 DSGVO, MED-KB-6 | 2026-08-27 |
Review-Rhythmus
- Je Session/PR: betroffene Risiken sichten; neue Risiken aus dem Change eintragen; Score/Status aktualisieren.
- Vorrangig behandeln: Score ≥ 6. Bei neuen kritischen/regulatorischen Themen für DE/AT/CH sofort flaggen + Optionen aufzeigen (CLAUDE.md §Compliance) und hier eintragen.
- Verknüpfung: Maßnahmen hängen an den OPs in
HANDOFF.md§4 / Lastenheft §11; dieses Register bündelt die Risiko-Sicht.