Compliance, Datenschutz & Audit-Bereitschaft
Kernaussage (BLUF). Medidentas ist auf DE→DACH-Compliance ausgelegt: DSGVO/revDSG (EU-/CH-Datenresidenz, PII-Minimierung by design, G-5/G-6), eIDAS/ZertES (E-Signatur je Rechtswirkung, OP-SIGN-1) und GoBD/§147 AO (append-only, hash-verketteter Audit-Trail; Retention/Löschkonzept noch offen, OP-AUDIT-1, G-4). Offene Härtungspunkte: Feld-Verschlüsselung/Retention der PII-Snapshots (MED-KB-6), Mitbestimmung der Zugriffs-Protokollierung (KB-3). Details je Rahmenwerk unten.
Lebende Doku (CLAUDE.md §Compliance): Belege/Checklisten für Datenschutz, Rechtssicherheit und Audits werden
laufend mitgepflegt — nicht erst zum Audit. Bei jedem relevanten Feature den Compliance-Bezug hier
nachziehen. Risiken parallel im docs/betrieb/Risikoregister.md.
Zielmärkte & relevante Rahmen
Primärmärkte DE · AT · CH (Reihenfolge DE→DACH). Relevante Rahmenwerke, die bei Features proaktiv zu berücksichtigen und ggf. zu flaggen sind:
| Thema | DE | AT | CH | Bezug |
|---|---|---|---|---|
| Datenschutz | DSGVO + BDSG | DSGVO + DSG | revDSG (CH-eigen, kein EU) | OP-DSGVO-1, G-5 |
| E-Signatur | eIDAS (SES/AES/QES) | eIDAS | ZertES (CH-eigen) | OP-SIGN-1, A-2 |
| Beratungsdoku-Pflicht | bestätigt: Versicherungsverm. §34d GewO/§61–62 VVG (IDD) · Finanzanlagenverm. §34f GewO/§18 FinVermV · Immobiliardarlehen §34i GewO | analog | analog | OP-DOMAIN-1 (✅), R6 |
| KI-/Transkriptions-Dienste | AVV + EU-Residenz; keine PII/Art.-9-Daten in US-Cloud ohne Garantien | analog | revDSG | OP-MEET-1, OP-AI-1, RISK-15 |
| Aufbewahrung | GoBD / §147 AO (6–10 J.) + branchenspez. | BAO | OR | OP-AUDIT-1 |
| Datenresidenz | EU | EU | CH/EU (CH = Nicht-EU) | OP-DSGVO-1 |
CH-Hinweis: Schweiz ist nicht EU (revDSG statt DSGVO, ZertES statt eIDAS). Residenz/Recht nicht hartkodieren. US-Transfer-Hinweis (MED-D-220, jetzt relevant): Der DocuSign-Adapter ist gebaut (dormant, noch nicht live) — vor dem ersten Live-Envelope ist der Datenexport in die USA abzusichern: AVV mit DocuSign + Transfermechanismus (EU-US Data Privacy Framework-Zertifizierung des Anbieters oder SCC) + soweit möglich die EU-Datenresidenz-Option von DocuSign aktivieren; alternativ PandaDoc-EU-Hosting. Ohne diese Absicherung bleibt der Provider auf
fake(dormant ohne Secret) (OP-SIGN-1). KI-/Transkriptions-Hinweis (RISK-15): Spracherkennung/Zusammenfassung/Grammatik/Beratungsdoku-Checks (Whisper, ChatGPT, Grammarly, Plaud, Krisp, Notion-AI, "Medidentas-GPT") verarbeiten Kunden- und ggf. Gesundheits-/Finanzdaten (Art. 9) — nur mit AVV + EU-Residenz und Zweckbindung; bei Gesprächen keine Vollaufnahme, Hinweis-/Einwilligungspflicht (OP-MEET-1, OP-AI-1).
Datenschutz-Kernpunkte (G-5)
- Datenminimierung: Kunde = Name + CRM-Link; Medidentas hält nur Prozess-Status + Referenzen, nicht die Kundenstammdaten-Kopie (S-1) und nicht die Dokument-Datei (S-2 → NextCloud).
- Auftragsverarbeitung: AV-Verträge mit allen Dritt-Diensten (NextCloud-Hosting, DocuSign/PandaDoc, CRM, E-Mail-Versand) — vor Produktivbetrieb.
- Betroffenenrechte / Löschkonzept: Auskunft, Berichtigung, Löschung — abgestimmt mit den Aufbewahrungsfristen (Beratungsunterlagen/Verträge dürfen nicht vor Fristende gelöscht werden → Audit-Log bleibt append-only, "Löschung" = Sperrung/Anonymisierung nach Frist).
Rechtssicherheit & Audit (G-4)
- Append-only Audit-Log über alle prozessrelevanten Ereignisse (Onboarding-Schritte, Dokument-Status,
Unterschriften, Beratungsprotokolle, Wiedervorlagen). Detail:
docs/architektur/Audit-Log.md. - Nachweisbarkeit der Unterschrift: Signatur-Zertifikat/Audit-Trail des Providers archivieren (zusammen mit dem unterschriebenen Dokument in NextCloud).
Compliance-Tracker (lebend)
Stand: 2026-07-24 (regelmäßige Prüfung; Runde nach Akten-Cockpit-Programm MED-D-188…210 + Welle 10, Doku-Welle 6/MED-D-212 — Substanz DSGVO/eIDAS/ZertES/Aufbewahrung unverändert stimmig; neu berücksichtigt: 1:n-Bankkonto-PII → RISK-28, Vor-Ort-eSignatur über Fake-Attrappe MED-KB-5 abgesichert; DocuSign-Adapter MED-D-220 → US-Transfer-Absicherung jetzt vor Live-Betrieb einzuholen, Zeile 3 aktualisiert). Status-Legende: ☐ offen · ◐ in Arbeit · ☑ erfüllt/bereit · ➖ n/a (noch nicht relevant).
| # | Rahmen / Anforderung | Status | Beleg / Artefakt | Nächster Schritt | Bezug |
|---|---|---|---|---|---|
| 1 | DSGVO/revDSG — Verarbeitungsverzeichnis | ☐ | — | nach Stack-/Datenmodell-Entscheidung anlegen | OP-DSGVO-1 |
| 2 | AV-Verträge (NextCloud, Signatur, CRM) | ☐ | — | Anbieter wählen → AVV abschließen | A-1, A-2, OP-CRM-1 |
| 3 | eIDAS-Niveau je Dokumenttyp | ◐ | architektur/Unterschriften.md, server/src/domain/signatur-niveau.ts, server/src/signatur/docusign.ts | Matrix gebaut (Slice 4): Vollmacht→QES, Vertrag→AES, Mandat→SES. DocuSign-Adapter gebaut (MED-D-220, 0.100.0): JWT-Grant + Envelope + Connect-Webhook, dormant ohne Secret. QES wird über den Dev-Account als AES mit sichtbarem Hinweis versendet (echte QES braucht CSP). Rest: Live-Verifikation + QES-CSP-Anbindung + US-Transfer-AVV (s. o.) | OP-SIGN-1, RISK-2, MED-D-220 |
| 4 | Aufbewahrungs-/Löschkonzept | ☐ | — | Fristen je Dokumenttyp festlegen | OP-AUDIT-1 |
| 5 | Beratungsdoku-Pflichtfelder | ◐ | Lastenheft.md R6 (§4.6) | Branche bestätigt → Pflichtfelder je Themenbereich aus §34d/f/i + VVG §61–62 + FinVermV §18 ableiten | OP-DOMAIN-1 (✅), R6 |
| 5a | Beratungsprotokoll-Rahmendaten | ◐ | Lastenheft.md R6-F11..F20, server/src/domain/model.ts | Gebaut (Slice 10): Pflichtangaben R6-F11..F20 (Modell/Migration v10/API/Client) — wann (F11), wo/Adresse bzw. Video (F12), Dauer (F13), Analyse-Programm (F14), Empfehlung gefolgt + ggf. Begründung (F15), Risikoaufklärung (F16), Unterlagen-Übermittlung (F17), Angaben/Gesundheitsbogen 1:1 (F18, §19 VVG), Verzicht (F19, Workflow gebaut Slice 11: R3-Ablage + R4-SES-Signatur), Schlusserklärung (F20, RISK-20) + Audit je Feldänderung. Rest: jur. Endabnahme der Texte (RISK-18/20) | OP-BERATDOK-1, R6, G-4 |
| 6 | Audit-Log (append-only) | ◐ | architektur/Audit-Log.md, server/src/domain/audit.ts, server/src/domain/zugriff.ts | Gebaut (Slice 6): append-only + Hash-Verkettung + Verify (zustandsändernde Events). Gebaut (0.48.0, D-50/RISK-27): Zugriffs-(Lese-)Protokollierung sensibler Entitäten aktion=eingesehen (Whitelist Mandant/Beratungsdoku/Datei-Inhalt), PII-arm in der Hash-Kette. Rest: (a) Dexman/PVS-Art.-9-Lese-Endpoints (ungebaut); (b) Retention der Zugriffs-Events ins Löschkonzept (#4); (c) Cold-Storage-Archiv/Restore | OP-AUDIT-1, G-4, D-50, RISK-27 |
| 7 | KI-/Transkriptions-Dienste: AVV + EU-Residenz | ☐ | architektur/Meeting-Doku-und-Aufgaben.md | Tool/Anbieter wählen → AVV + Residenz prüfen; Einwilligungs-/Hinweis-Flow | OP-MEET-1, OP-AI-1, RISK-15 |
| 8 | KI-Beratungsdoku: Haftungsgrenze dokumentiert | ☐ | Lastenheft.md R6-F08 | Check = Assistenz, Endkontrolle Berater; im UI/Prozess verankern | OP-AI-1, RISK-14 |
| 9 | GwG — Verpflichteten-Status + Identifizierung (§§ 2, 11 ff.) | ☐ | Decision-Log.md D-30 | OP-GWG-1: Produktklassen klären; falls verpflichtet Berater-Ident im Termin (Mandant+Audit) als Standard, VideoIdent Fallback, QES-Ident mitnutzen | OP-GWG-1, RISK-25, OP-SIGN-1 |
| 10 | Web-Push (Live-Timer-Benachrichtigung, MED-D-275/276) | ◐ | architektur/Zeiterfassung-Segmente-und-Push.md, server/src/api/push-service.ts | By-Design PII-arm gebaut: daten-loses Push (kein PII über die Dritt-Gateways Google/Mozilla/Apple/MS), Subscriptions PII-arm + Löschung bei 410/Abmeldung, opt-in Permission, VAPID-Keys als Secrets (dormant ohne Secret). Gehärtet (MED-D-276, G-6): kein user_agent gespeichert (Datensparsamkeit), Endpoint-Allowlist (nur HTTPS + FCM/Mozilla/Apple/WNS = Egress-Kontrolle), unsubscribe user-scoped. Rest vor Live: AVV/Transfer-Betrachtung der Push-Dienste + Retention der push_subscription-Zeilen + auth/p256dh-Schlüssel at-rest (bei daten-losem Push ungenutzt → dropen oder verschlüsseln, analog MED-KB-6) festlegen | MED-D-275/276, RISK-32, G-5, G-6 |
Review-Takt: zu Session-/PR-Beginn mitpflegen — bei jedem relevanten Feature die betroffene Zeile nachziehen. Belege git-nah (privates Repo), keine Secrets/PII im Klartext.