Risikoregister (Medidentas)
Kernaussage (BLUF). 41 erfasste Risiken; 23 vorrangig (Score ≥6), davon zwei mit Höchst-Score 9: RISK-15 — PII in US-/Cloud-KI-Diensten (Whisper/ChatGPT/Grammarly) und RISK-39 — Fragenkatalog-Stammdaten und neue öffentliche Kundenstrecke. 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 Kunden-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 (Sub-Entitäts-Guards, erledigt s. u.): Defense-in-Depth; Stand MED-D-382 (2026-09-26): Praxis-Routen /api/praxen/:id* (Dentmarking, Dexman) sowie /api/gutachten/:id* und /api/befunde/:id/* jetzt ebenfalls im Kunden-Scope (Fremd→404, Test in rbac.test.ts); Stand MED-D-623: auch Dokumente, Bankkonten, Onboarding-Items, Signaturen, Dokumentgenerierung und Leistungszeit — damit sind alle By-ID-Routen mit Kundenbezug abgedeckt; kundenlose Verwaltungs-Routen (Benutzer, Einstellungen, Playbooks, Fremdformular-Vorlagen) über eigene Fähigkeiten geschützt; MED-D-629: Teams erweitern die Sicht bewusst auf Kolleg:innen im selben Team (Vertretung) — Team-Pflege nur Admin, auditiert (benutzer.rolle_gesetzt mit team) (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, #382, #623 | 2026-09-26 |
| 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. Stand MED-D-381: Dexman gebaut ohne Behandler-Vergleich/Scorecard; Umsatz je Behandler nur als Planungs-/Ist-Eingabe, Lesezugriff protokolliert | OP-DEX-4, R7, RISK-38 | 2026-09-26 |
| 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, Kunden-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 "Kunden-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 | 2 | 2 | 4 | in Minderung (Härtung gebaut; Access-Bypass-Gate offen) | Minderung by-design (S2 umgesetzt, S5 scharf + Härtung gebaut): (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. S5-Go-Live scharfgeschaltet (MED-D-310, 2026-09-23): PORTAL_AKTIV="true" (MED-KB-13 DSGVO/AVV erteilt) + echter Mailversand (OP-DM-8, Cloudflare Email Service ab MED-D-314 — löst MailChannels ab, ein Sub-Prozessor weniger). Login-Härtung gebaut (MED-D-311, MED-OP-PORTAL-3 ✅): Turnstile + fensterbasiertes Rate-Limiting am /oeffentlich/portal/anmelden (je IP 20 / je E-Mail 5 pro 10 Min → 429; Schlüssel gehasht, PII-arm; 429 kontounabhängig, kein Enumeration-Leak). VERBLEIBEND vor öffentlichem Cloudflare-Access-Bypass für /portal: (1) TURNSTILE_SITEKEY/TURNSTILE_SECRET setzen (ohne Secret ist nur der Rate-Limiter aktiv, kein CAPTCHA); (2) AVV mit dem Cloudflare Email Service + EU-Residenz im Deploy-Runbook bestätigen (Deploy.md §7e). Bis der Access-Bypass gesetzt ist, liegt das Portal weiter hinter Access — die Restrisiken sind erst mit dem Bypass scharf. Restrisiko damit auf 4 (2×2) gesenkt. | MED-D-279/310/311, Golden Rule (Zero Trust), G-5, G-6, MED-KB-13, OP-DM-8, MED-OP-PORTAL-3 | 2026-09-23 |
| 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 |
| RISK-35 | Öffentliche Firmen-Website ohne Impressum/Datenschutz (2026-09-25, MED-D-317; erweitert 2026-09-26, MED-D-332: gilt ebenso für die öffentlichen Kundenseiten Onboarding/Formular/Fragebogen/Lead/Portal — deren Fußzeile verlinkt Impressum/Datenschutz, sobald IMPRESSUM_URL/DATENSCHUTZ_URL gesetzt sind, Deploy.md §7f; Mitigation gebaut 2026-09-26, MED-D-384: eigene Seiten /impressum + /datenschutz, Landing + Kundenseiten verlinken — Anbieterdaten + anwaltliche Prüfung offen, #384): die WIP-Landing auf medidentas.com (Apex/www) ist eine öffentlich erreichbare, geschäftsmäßige Seite ohne Cloudflare Access (bewusste Golden-Rule-Ausnahme). Eine solche Seite löst in DE die Impressumspflicht (§5 DDG, vormals §5 TMG) und die Datenschutz-Informationspflicht (Art. 13 DSGVO) aus, in AT §5 ECG + DSGVO; Verstöße sind abmahn-/bußgeldfähig. | Compliance (DE/AT) | 2 | 2 | 4 | offen (vor Öffentlich-Gang zu schließen) | Gemindert by-design: (a) reine statische Halte-Seite ohne Datenerhebung/Login/Cookies/Tracking (kein D1, keine PII, kein Formular) → niedrigste Angriffs-/Pflichtenfläche; (b) noindex solange WIP; (c) KI-Training/TDM-Opt-out maschinenlesbar (robots.txt-Crawler-Block + ai.txt + /.well-known/tdmrep.json W3C TDMRep + Header X-Robots-Tag: noai/tdm-reservation:1; Rechtsvorbehalt Art. 4 Abs. 3 DSM-RL / §44b UrhG-DE / §42h öUrhG-AT). VERBLEIBEND vor/mit dem Öffentlich-Gang: Impressum (§5 DDG/ECG) + Datenschutzerklärung (Art. 13) ergänzen, sobald die Seite über den reinen Platzhalter hinausgeht — bei Bau-Halteseiten ist die Pflicht ein Grenzfall, daher konservativ ergänzen. Owner: HQ/Content. | MED-D-317, Golden Rule (Zero-Trust-Ausnahme), §5 DDG, §5 ECG, Art. 13 DSGVO, DSM-RL Art. 4/§44b UrhG, Deploy.md §10 | 2026-09-25 |
| RISK-36 | Mehrere Portal-Kontakt-Logins je Mandant (2026-09-25, MED-D-320): ein Mandant kann jetzt mehrere Kontaktpersonen mit je eigenem Portal-Login haben — jede sieht die Mandant-Daten (Onboarding-/Stammdaten-/Dokument-Status). Ohne saubere Autorisierung wäre das ein unbefugter Zugriff auf personenbezogene Praxis-/Mandantendaten (DSGVO). | Datenschutz/Zugriff | 1 | 2 | 2 | gemindert | By-Design gemindert: (a) Staff-gated — Kontakte legt ausschließlich ein Medidentas-Mitarbeiter hinter Cloudflare Access an (kein „Kontakt lädt Kontakt ein"); die Praxis benennt die Zugriffsberechtigten, die Autorisierung liegt damit beim Auftraggeber. (b) Scope-Guard — jeder Kontakt ist strikt auf einen Mandanten gescoped (kein Cross-Mandant; fremdes Konto → nicht_gefunden, kein Existenz-Leak). (c) Sperren beendet sofort auch laufende Sessions (ausscheidende Person → Zugang entziehen); reversibel (reaktivieren), Audit-Trail statt Hard-Delete (G-4). (d) Konten passwortlos/Magic-Link (kein Passwort-Hash), Audit PII-arm (nur kontoId+mandantId, keine E-Mail; G-6). Rest: in der AVV/Datenschutz-Info festhalten, dass die Praxis die Kontakt-Zugriffsberechtigten benennt/pflegt (MED-KB-13 (3) erledigt). | MED-D-320, MED-KB-13 (3), Golden Rule (Staff-gated), G-5, G-6, RISK-33 | 2026-09-25 |
| RISK-37 | Bank-Kontoinformationen in Dexman (2026-09-26, MED-D-372, DEX-14): die geplante Finanzsicht liest Geschäftskonten über PSD2. Eigenbetrieb eines Kontoinformationsdienstes wäre erlaubnis-/registrierungspflichtig (§ 34 ZAG, BaFin); Kontobewegungen enthalten Gegenpartei-/Verwendungszweck-PII Dritter. | Regulatorik/Datenschutz | 2 | 2 | 4 | offen | By-Design: nur über einen lizenzierten Kontoinformationsdienst (G-1, Issue #373) + AVV/EU-Residenz; Persistenz nur Datum/Betrag/Kategorie/generalisierte Gegenpartei (G-6); Privatkonten nur nach ausdrücklicher Freigabe. | DEX-14 · spezialtools/Dexman.md §11 · RISK-12 | 2026-09-26 |
| RISK-38 | Dexman speichert Beschäftigtendaten der Praxis (2026-09-26, MED-D-381): Planungsbausteine enthalten je Person Kürzel/Name, Rolle, Monatsbrutto, geplanten und gemeldeten Umsatz. Das sind personenbezogene Daten der Beschäftigten des Kunden (Art. 4/88 DSGVO, § 26 BDSG); Medidentas verarbeitet sie im Auftrag der Praxis. | Datenschutz | 2 | 2 | 4 | in Minderung | By-Design: Kürzel genügt (Hinweis im Formular), Stand MED-D-381: bewusst keine Steuerklasse/Kinder/KV/Konfession (pauschaler AG-Aufschlag statt Lohnrechnung, G-6); gebaut MED-D-709 Slice 3 (2026-10-16): je Anstellungs-Zeitraum nur Beschäftigungsart, KV-Status, Zusatzbeitrag und PKV-Zuschuss (für die AG-Kosten nötig), weiterhin keine Steuerklasse/Kinder/Konfession, Zugriff und Protokollierung unverändert, Art.-9-Einordnung und Aufbewahrungsfrist vor Produktivnutzung festlegen; Zugriff nur über die Kunde (RBAC je Kunde, fremde Berater → 404); Lesezugriff protokolliert (dexman_planung.eingesehen, D-50); Audit PII-arm (nur IDs/Enums); Beratungsmodus blendet Namen aus; kein Behandler-Vergleich gebaut (RISK-11). Entschieden (Issue #806, 2026-10-18, Vorschläge, vom Datenschutzbeauftragten zu bestätigen): (1) KV-Status, Zusatzbeitrag und PKV-Zuschuss sind Beschäftigtendaten nach § 26 BDSG, kein Gesundheitsdatum nach Art. 9 DSGVO (sie sagen nur, welche Versicherungsart gilt und was der Arbeitgeber zuschießt, nicht ob jemand krank ist); (2) Aufbewahrung von Planungsversionen, Ist-Beteiligungen und Portal-Meldungen: Mandatsdauer plus 3 Jahre (Regelverjährung § 195 BGB), dann Löschung, der Audit-Trail ohne Beträge bleibt; (3) AV-Vertrag je Dexman-Mandat, vor dem ersten Erfassen von Beschäftigtendaten. Offen: Bestätigung durch den Datenschutzbeauftragten, Umsetzung der Löschung nach Frist und die AV-Vertragsvorlage (Folge-Issues). | MED-D-381 · RISK-11 · spezialtools/Dexman-Systementwurf.md §10 | 2026-09-26 |
| RISK-39 | Fragenkatalog-Stammdaten und neue öffentliche Kundenstrecke (2026-10-14, MED-D-703): (a) Steuer-ID (§ 139b AO), Familienstand und Kinder (nur Vorname + Geburtsmonat; Daten Minderjähriger) werden als Stammdaten gespeichert — der frühere bewusste Ausschluss der Steuer-ID (MED-D-284) ist auf Nutzerwunsch aufgehoben; (b) der Kunden-Link /oeffentlich/katalog/:token ist eine fünfte öffentliche, token-basierte Strecke ohne Login: wer den Link besitzt, sieht die Angaben des Katalogs (inkl. Beraterteil) und kann sie ändern/bestätigen. | Datenschutz | 3 | 3 | 9 | offen | By-Design: Kinder nur Vorname + Geburtsmonat (G-6), Antworten nur für erlaubte Schlüssel je Rolle, Fremdschlüssel/abgeleitete Felder werden abgelehnt, Audit PII-arm und ohne Link-Token, /oeffentlich*-Access-Bypass bereits vorhanden (kein neuer Access-Schritt), Mandanten-Trennung der Berater-Routen (Fremd-Kunde → 404). Link-Gültigkeit umgesetzt (Nutzervorgabe 2026-10-14): 14 Tage absolut, Erneuern rotiert den Token (alter Link sofort tot), abgelaufen → 410 ohne Daten, Altbestand ohne Ablauf gilt als abgelaufen (fail-closed), nach Bestätigung/Signatur liefert der öffentliche Link nur noch den Status. Offen: Zweck/Rechtsgrundlage/Aufbewahrung für Steuer-ID, Familienstand, Kinder (#715) — vor Live; Verschlüsselung-at-rest/Retention bleibt MED-KB-6; Rate-Limiting/Turnstile und der Rest der öffentlichen Flächen (Ausfüll-Formular ohne Ablauf, Upload-Link mit optionalem Ablauf): #739. Nachtrag 2026-10-16 (Nutzerentscheidung): Kinder (Daten Minderjähriger) auf Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), Aufbewahrung wie Beratungsunterlagen (#715); alle öffentlichen Kundenlinks werden auf begrenzte Gültigkeit umgestellt (#739); apoBank-Stammnummer wird vom Kunden erfasst (G-6-Begründung bei #779). Nachtrag (MED-D-779): apoBank-Stammnummer als optionales, hash-versioniertes Stammdatum am Kunden — Zweck Zuordnung bei der apoBank, Rechtsgrundlage Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO), Aufbewahrung wie Beratungsunterlagen; Freitext ohne angenommenes Bankformat; Schreibweg nur Review-and-apply nach Berater-Prüfung (Audit PII-arm). Datenschutzhinweise vor Live prüfen. Nachtrag (#739, umgesetzt): alle öffentlichen Token-Links sind jetzt zeitlich begrenzt — Ausfüll-Formular 14 Tage (neu; Altbestand ohne Ablauf gilt als abgelaufen und wird vom Berater erneuert), Ablage-Upload höchstens 14 Tage (Ablaufdatum verpflichtend, Marker ohne Datum ungültig), Onboarding 14 Tage, Dentmarking-Fragebogen Standard 14 Tage (einstellbar bis 30). Erneuern = neuer Token, der alte ist sofort ungültig. Nach Abschluss/Ablauf liefert der Link nur noch den Status (keine Antworten, kein Name). Offen: Rate-Limiting/Turnstile der Token-Strecken, mittelfristig ein Zugang statt vieler Links (Portal). |
| RISK-40 | Vorläufig freigegebene Rechtstexte im Live-Betrieb (2026-10-18, MED-D-703): Die Texte der Fragenkataloge (Einwilligung Lastschrift, SEPA-Mandat, Widerrufsbelehrung) werden auf Nutzerentscheidung vorläufig freigegeben, die juristische Prüfung folgt. Jede Unterschrift bindet die Fassung (Version + Hash, G-4); eine spätere Korrektur ist eine neue Fassung, frühere Unterschriften bleiben an den ungeprüften Wortlaut gebunden. Eine fehlerhafte Widerrufsbelehrung (Stand 04/2021, Fernabsatz) kann die Widerrufsfrist verlängern. | Compliance | 3 | 4 | 12 | offen | Prüfung zeitnah nachholen, Herkunft „vorläufig“ vermerken, Unterschrift mit Rechtswirkung erst nach OP-SIGN-1 (DocuSign-Produktion + AVV). Details: docs/architektur/Onboarding-Texte-Freigabe.md. |
| RISK-41 | Öffentliche Token-Routen: Raten und Flut trotz Begrenzung (2026-10-25, #840): Katalog-, Ausfüll-, Fragebogen-, Onboarding- und Upload-Links liegen im Access-Bypass. Der Worker begrenzt sie je Token (120) und je IP (300) in einem festen Zehn-Minuten-Fenster; an der Fenstergrenze sind kurzzeitig bis zu doppelt so viele Anfragen möglich. Die Grenzwerte sind Annahmen; hinter einer gemeinsamen IP (Büro-NAT) können legitime Kunden gemeinsam die IP-Grenze erreichen. Eine Cloudflare-Regel am Rand ist nicht eingerichtet. | Sicherheit | 2 | 3 | 6 | beobachten | Nach dem ersten Betrieb Audit rate_limit.gesperrt auswerten und die Grenzwerte anpassen (TOKEN_RATE_IP, TOKEN_RATE_TOKEN); Edge-Regel erwägen. Details: docs/architektur/Deploy.md §7e-2. |
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 offenen Punkten (GitHub-Issues, Label
offener-punkt; Alt-IDs ausHANDOFF.md§4 / Lastenheft §11 verweisen per→ #ndarauf); dieses Register bündelt die Risiko-Sicht.