# AUDIT-READINESS ASSESSMENT # AZA / MedWork – Februar 2026 **Assessor:** Internes Security-Team (automatisiert) **Datum:** 2026-02-22 **Scope:** AZA/MedWork Gesamtsystem **Datenklassifikation:** Besonders schützenswerte Personendaten (Gesundheitsdaten) **Rechtsrahmen:** DSG (Schweiz, rev. 2023), DSGVO (ergänzend), HIN-Referenzniveau **Referenzdokumente:** TOMs_AZA_MedWork.md, GAP-Analyse (STEP 3), Handovers STEP 4.1–6 --- ## 1. Technische Sicherheit --- ### 1.1 Transport Security #### Status: YELLOW #### Begründung: - TLS >= 1.2 für alle Backend-Services erzwungen (STEP 4.1, verifiziert in 4.1a) - Starke Cipher Suites mit PFS (ECDHE+AESGCM, CHACHA20) - HTTP wird komplett abgelehnt (kein Redirect, Connection Refused) - Fail-Start bei fehlenden Zertifikaten - **ABER:** Nur Self-Signed-Zertifikate für Entwicklung vorhanden - **ABER:** SMTP STARTTLS ist opportunistisch (nicht erzwungen) - **ABER:** Keine Ende-zu-Ende-Verschlüsselung für E-Mails #### Blocker für externes Audit: - Nein, kein harter Blocker. TLS ist implementiert und verifiziert. - Produktivzertifikate (Let's Encrypt / CA-signiert) müssen vor Go-Live beschafft werden. #### Empfohlene nächste Schritte: 1. Produktiv-Zertifikate beschaffen (Let's Encrypt / ACME) 2. SMTP-STARTTLS-Erzwingung implementieren (Fehler bei fehlgeschlagenem TLS) 3. S/MIME oder Gateway-Verschlüsselung für medizinische E-Mails evaluieren --- ### 1.2 Authentifizierung #### Status: YELLOW #### Begründung: - Passwort-Login mit bcrypt (cost=12, Salt eingebettet) – STEP 4.2 - Legacy-SHA-256-Migration transparent implementiert und verifiziert – STEP 4.2a - TOTP-2FA implementiert (RFC 6238, optional/erzwingbar via ENV) – STEP 6 - Backup-Codes (8 Einmal-Codes, SHA-256-gehasht) vorhanden - Rate-Limiting auf TOTP-Versuche (5/5min) - RBAC im Workforce Planner (3 Rollen) - **ABER:** 2FA nur im Desktop-Client, nicht im Workforce Planner (Web-API) - **ABER:** Kein SSO (SAML/OAuth/OIDC) - **ABER:** Keine Identitätsprüfung (Videoidentifikation o.ä.) - **ABER:** Minimale Passwortanforderung (4 Zeichen) ist zu schwach #### Blocker für externes Audit: - Ja, teilweise. Für medizinische Systeme wird 2FA in der Regel erwartet. Im Desktop-Client vorhanden, im Web-API fehlt sie. #### Empfohlene nächste Schritte: 1. Minimale Passwortlänge auf 8+ Zeichen erhöhen 2. 2FA im Workforce Planner (Web-API) implementieren 3. `AZA_2FA_REQUIRED=1` als Standard für Produktion setzen --- ### 1.3 Secrets Management #### Status: GREEN #### Begründung: - Hardcoded Secret Key entfernt – STEP 4.3 - Zentrale Validierung: Mindestlänge 32 Zeichen, keine trivialen Muster - Fail-Start bei fehlendem oder schwachem Key - DEV-Modus mit auto-generiertem Key (explizit AZA_ENV=dev) - Klartext-Credentials aus Config entfernt – STEP 4.4 - E-Mail-Passwörter nur via ENV-Variablen - Incident-Dokumentation für exponiertes Passwort erstellt – STEP 4.4a - TOTP-Secrets verschlüsselt gespeichert (nie Klartext auf Disk) #### Blocker für externes Audit: - Nein. Secret Management ist solide implementiert und dokumentiert. #### Empfohlene nächste Schritte: 1. Passwort beim Mail-Provider rotieren (INCIDENT offen) 2. OS-Keychain-Integration evaluieren (Windows Credential Manager) 3. Secret-Scanning in CI/CD-Pipeline einführen --- ### 1.4 2FA #### Status: YELLOW #### Begründung: - TOTP (RFC 6238) implementiert mit pyotp – STEP 6 - QR-Code-Provisioning, Erst-Validierung, Backup-Codes - Rate-Limiting (5 Versuche / 5 Minuten) - ENV-Steuerung (AZA_2FA_ENABLED, AZA_2FA_REQUIRED) - **ABER:** Nur im Desktop-Client (basis14.py), nicht im Workforce Planner - **ABER:** Aktuell optional (AZA_2FA_REQUIRED=0) - **ABER:** Kein Hardware-Token-Support (FIDO2/WebAuthn) #### Blocker für externes Audit: - Teilweise. 2FA ist implementiert, aber nicht standardmässig erzwungen. Für HIN-Niveau wäre 2FA-Pflicht erforderlich. #### Empfohlene nächste Schritte: 1. AZA_2FA_REQUIRED=1 als Produktiv-Standard 2. 2FA im Workforce Planner nachrüsten 3. FIDO2/WebAuthn als Upgrade-Option evaluieren --- ### 1.5 Logging & Monitoring #### Status: RED #### Begründung: - Audit-Log-Modell existiert (AuditLog-Tabelle in workforce_planner) - log_action()-Funktion definiert - **ABER:** log_action() wird in keinem API-Endpunkt aufgerufen - **ABER:** Kein Logging fehlgeschlagener Anmeldeversuche - **ABER:** Kein zentrales Logging-Framework - **ABER:** Kein Monitoring, kein Alerting - **ABER:** Debug-Prints statt strukturiertem Logging - **ABER:** Kein SIEM #### Blocker für externes Audit: - Ja. Fehlende Nachvollziehbarkeit von Datenzugriffen ist ein Kernproblem für medizinische Systeme (DSG Art. 8, DSGVO Art. 5 Abs. 2). #### Empfohlene nächste Schritte: 1. log_action() in alle schreibenden API-Endpunkte integrieren 2. Fehlgeschlagene Login-Versuche protokollieren 3. Strukturiertes Logging (Python logging-Modul) einführen --- ## 2. Datenschutz --- ### 2.1 TOMs-Dokumentation #### Status: GREEN #### Begründung: - Vollständiges TOMs-Dokument erstellt (12 Bereiche) – STEP 5 - Alle 12 DSG/DSGVO-Bereiche abgedeckt - Klare Trennung: implementiert vs. nicht implementiert - 35 Massnahmen implementiert, 62 offen - Referenzen auf technische Implementierungen vorhanden #### Blocker für externes Audit: - Nein. TOMs-Dokument ist vorhanden und audit-tauglich. Inhaltlich zeigt es aber viele offene Punkte auf. #### Empfohlene nächste Schritte: 1. TOMs nach jedem Security-Schritt aktualisieren 2. Versionierung/Changelog für TOMs einführen 3. Verantwortlichkeiten pro TOM zuweisen --- ### 2.2 Incident Management #### Status: YELLOW #### Begründung: - Ein Incident wurde formal dokumentiert (Credential Exposure) – STEP 4.4a - Checkliste mit Sofortmassnahmen und Folgeaktionen vorhanden - Security-Handovers für alle Schritte dokumentiert - **ABER:** Kein formaler Incident-Response-Plan - **ABER:** Keine Eskalationsstufen definiert - **ABER:** Keine Prozesse für DSG Art. 24 (Meldung an EDÖB innert 72h) - **ABER:** Passwort-Rotation (Incident-Empfehlung) noch offen #### Blocker für externes Audit: - Ja, teilweise. Das DSG verlangt eine Meldefähigkeit innert 72h. Ohne definierten Prozess ist diese nicht gewährleistet. #### Empfohlene nächste Schritte: 1. Incident-Response-Plan erstellen (Rollen, Eskalation, Fristen) 2. Meldeprozess an EDÖB definieren (72h-Frist) 3. Offene Incident-Massnahme abschliessen (Passwort-Rotation) --- ### 2.3 Datenminimierung #### Status: RED #### Begründung: - Keine formale Datenminimierungsstrategie - Patientendaten (KG) werden lokal ohne Löschfristen gespeichert - Keine Klassifikation der verarbeiteten Daten - Keine Prüfung, ob nur notwendige Daten erhoben werden - OpenAI API erhält potenziell Patientendaten (Transkription, KG-Generierung) ohne dokumentierte Notwendigkeitsprüfung - E-Mail-Inhalte werden vollständig lokal gecacht #### Blocker für externes Audit: - Ja. Datenminimierung ist ein Grundprinzip (DSG Art. 6 Abs. 2, DSGVO Art. 5 Abs. 1 lit. c). Ohne Nachweis ist ein Audit nicht bestehbar. #### Empfohlene nächste Schritte: 1. Datenverarbeitungsverzeichnis (Art. 12 DSG) erstellen 2. Prüfen welche Daten an OpenAI gesendet werden (Anonymisierung?) 3. Aufbewahrungsfristen für medizinische Daten definieren (kant. Recht: 10–20 Jahre) --- ### 2.4 Löschkonzepte #### Status: RED #### Begründung: - Kein Löschkonzept vorhanden - Keine automatische Datenlöschung - Keine Löschfunktion für Patientendaten - Keine Dokumentation der Aufbewahrungsfristen - Medizinische Daten: kantonale Aufbewahrungspflichten (typisch 10 Jahre) sind weder dokumentiert noch technisch unterstützt #### Blocker für externes Audit: - Ja. Recht auf Löschung (DSG Art. 32, DSGVO Art. 17) nicht umsetzbar. #### Empfohlene nächste Schritte: 1. Aufbewahrungsfristen pro Datentyp definieren 2. Löschfunktion für Patientendaten implementieren 3. Automatische Löschung nach Ablauf der Aufbewahrungsfrist --- ## 3. Organisation --- ### 3.1 Rollen & Verantwortlichkeiten #### Status: YELLOW #### Begründung: - RBAC im Workforce Planner (ADMIN, MANAGER, EMPLOYEE) - Rollen-basierte API-Zugriffskontrolle implementiert - Security-Projekt hat definierte Rollen (Security Engineer, Architekt, Inhaber) - **ABER:** Kein Datenschutzbeauftragter (DSB) benannt - **ABER:** Kein IT-Sicherheitsbeauftragter benannt - **ABER:** Keine Zugriffsmatrix für Patientendaten - **ABER:** Keine regelmässige Berechtigungsüberprüfung #### Blocker für externes Audit: - Teilweise. DSB-Benennung ist für medizinische Praxen in der Schweiz nicht zwingend (< 250 Mitarbeiter), aber empfohlen. #### Empfohlene nächste Schritte: 1. Datenschutz-Verantwortlichen benennen (auch wenn nicht DSB-pflichtig) 2. Zugriffsmatrix für Patientendaten erstellen 3. Regelmässige Berechtigungsüberprüfung einführen --- ### 3.2 Schulung #### Status: RED #### Begründung: - Keine Security-Awareness-Schulungen - Keine Dokumentation für Endbenutzer - Keine Schulung zum Umgang mit Patientendaten - Keine Phishing-Awareness - Keine Einweisungsprozedur #### Blocker für externes Audit: - Ja. Fehlende Mitarbeiterschulung ist ein Standard-Audit-Finding. DSG Art. 8 verlangt angemessene organisatorische Massnahmen. #### Empfohlene nächste Schritte: 1. Kurzschulung "Datenschutz für Praxismitarbeiter" erstellen (1 Seite) 2. Benutzerhandbuch für AZA/MedWork mit Security-Hinweisen 3. Jährliche Auffrischung dokumentieren --- ### 3.3 Prozesse #### Status: RED #### Begründung: - Kein Change-Management-Prozess - Kein Release-Management - Kein formaler Testprozess vor Produktiv-Updates - Kein Code-Review-Prozess - Kein Vulnerability-Disclosure-Prozess - Security-Projekt folgt strukturiertem Vorgehen (Steps), aber nicht formalisiert #### Blocker für externes Audit: - Teilweise. Fehlende Prozesse sind ein Risiko, aber für eine Einzelpraxis nicht zwingend auditrelevant. #### Empfohlene nächste Schritte: 1. Minimaler Change-Management-Prozess definieren 2. Checkliste vor Produktiv-Deployment 3. Regelmässige Dependency-Prüfung (pip-audit) --- ## 4. Betrieb --- ### 4.1 Backup & Recovery #### Status: RED #### Begründung: - Nur manuelle Dateisystem-Backups (Ordner-Kopien) - Kein automatisiertes Backup - Kein Off-Site-Backup - Keine dokumentierte Recovery-Prozedur - Keine RTO/RPO definiert - Keine Wiederherstellungstests #### Blocker für externes Audit: - Ja. Verfügbarkeitskontrolle ist eine Grundanforderung (DSG Art. 8). Ohne Backup-Konzept für medizinische Daten nicht auditierbar. #### Empfohlene nächste Schritte: 1. Automatisiertes tägliches Backup einrichten 2. RTO/RPO definieren (z.B. RPO=24h, RTO=4h) 3. Quartalsmässige Wiederherstellungstests durchführen --- ### 4.2 Patching #### Status: RED #### Begründung: - Kein dokumentiertes Patch-Management - Keine automatische Dependency-Prüfung - Keine Update-Zyklen definiert - Kein Changelog #### Blocker für externes Audit: - Teilweise. Ohne Nachweis aktueller Dependencies besteht Risiko durch bekannte Schwachstellen. #### Empfohlene nächste Schritte: 1. `pip-audit` einmalig ausführen und Ergebnis dokumentieren 2. Monatlichen Dependency-Check einführen 3. requirements.txt mit festen Versionen pflegen --- ### 4.3 Monitoring #### Status: RED #### Begründung: - Kein Health-Check-Monitoring - Kein Alerting bei Service-Ausfall - Kein Performance-Monitoring - Keine Anomalie-Erkennung #### Blocker für externes Audit: - Teilweise. Für eine Desktop-App weniger kritisch als für Cloud-Services. #### Empfohlene nächste Schritte: 1. Health-Check-Endpunkt für Backend-Services (bereits vorhanden: /health) 2. Einfaches Uptime-Monitoring (z.B. Skript mit Alerting) 3. Fehlgeschlagene Login-Versuche loggen und alarmieren --- ## 5. Recht --- ### 5.1 Informationspflichten #### Status: RED #### Begründung: - Keine Datenschutzerklärung für Patienten - Keine Information über Datenverarbeitung beim Einsatz von OpenAI - Keine Einwilligungserklärung für KI-gestützte Verarbeitung - DSG Art. 19–21 (Informationspflicht) nicht umgesetzt #### Blocker für externes Audit: - Ja. Informationspflicht ist zwingend für medizinische Daten. #### Empfohlene nächste Schritte: 1. Datenschutzerklärung für Patienten erstellen 2. Einwilligungserklärung für KI-Verarbeitung (OpenAI) erstellen 3. Information über Datenübermittlung ins Ausland (OpenAI-Server) --- ### 5.2 Auftragsverarbeitungsverträge (AV) #### Status: RED #### Begründung: - Kein AV/DPA mit OpenAI dokumentiert - Kein AV/DPA mit Supabase dokumentiert - Kein AV/DPA mit E-Mail-Provider - Keine Prüfung der Datenverarbeitungsstandorte #### Blocker für externes Audit: - Ja. AV-Verträge sind gesetzlich vorgeschrieben bei Auftragsverarbeitung (DSG Art. 9, DSGVO Art. 28). #### Empfohlene nächste Schritte: 1. OpenAI DPA prüfen/abschliessen (existiert als Standard-DPA bei OpenAI) 2. Supabase DPA prüfen/abschliessen 3. Datenverarbeitungsstandorte dokumentieren (Schweiz/EU/US) --- ### 5.3 Privacy Policy / Einwilligungen #### Status: RED #### Begründung: - Keine Privacy Policy vorhanden - Keine Einwilligungsmechanismen in der Anwendung - Keine Cookie-/Tracking-Hinweise (bei Web-Komponenten) - Keine Widerspruchsmöglichkeit - Keine Auskunftsfunktion (DSG Art. 25) #### Blocker für externes Audit: - Ja. Fundamentale rechtliche Anforderung nicht erfüllt. #### Empfohlene nächste Schritte: 1. Privacy Policy erstellen (Schweizer Recht, medizinischer Kontext) 2. Einwilligungsdialog für KI-Verarbeitung in die App integrieren 3. Auskunftsprozess definieren (Patientenrecht auf Einsicht) --- ## GESAMTBEWERTUNG ### Ampelübersicht | Bereich | Status | Audit-Blocker | |---------|:------:|:---:| | 1.1 Transport Security | YELLOW | Nein | | 1.2 Authentifizierung | YELLOW | Teilweise | | 1.3 Secrets Management | GREEN | Nein | | 1.4 2FA | YELLOW | Teilweise | | 1.5 Logging & Monitoring | RED | Ja | | 2.1 TOMs-Dokumentation | GREEN | Nein | | 2.2 Incident Management | YELLOW | Teilweise | | 2.3 Datenminimierung | RED | Ja | | 2.4 Löschkonzepte | RED | Ja | | 3.1 Rollen | YELLOW | Teilweise | | 3.2 Schulung | RED | Ja | | 3.3 Prozesse | RED | Teilweise | | 4.1 Backup & Recovery | RED | Ja | | 4.2 Patching | RED | Teilweise | | 4.3 Monitoring | RED | Teilweise | | 5.1 Informationspflichten | RED | Ja | | 5.2 AV-Verträge | RED | Ja | | 5.3 Privacy Policy | RED | Ja | ### Zählung | Status | Anzahl | |--------|:------:| | GREEN | 2 | | YELLOW | 5 | | RED | 11 | --- ### Gesamturteil #### DSG-konform: NEIN Hauptgründe: Fehlende Informationspflichten (Art. 19–21), fehlende AV-Verträge (Art. 9), fehlendes Löschkonzept (Art. 32), fehlende Nachvollziehbarkeit (Art. 8). #### DSGVO-konform: NEIN Hauptgründe: Fehlende Privacy Policy, fehlende Einwilligungen für KI-Verarbeitung, fehlende DPAs, fehlende Datenschutz-Folgenabschätzung (DSFA/DPIA) für Gesundheitsdatenverarbeitung. #### Medizinisch auditfähig: NEIN Hauptgründe: Kein Backup-Konzept, kein Logging, keine Schulung, keine Informationspflichten gegenüber Patienten. #### HIN-nah: TEILWEISE Technische Basis (TLS, Hashing, 2FA) ist vorhanden. Netzwerk-/PKI-/S/MIME-Ebene fehlt komplett. Organisatorische Massnahmen fehlen weitgehend. --- ### Priorisierte Top-10-Massnahmen für Audit-Readiness | Prio | Massnahme | Bereich | Aufwand | |:----:|-----------|---------|:-------:| | 1 | Datenschutzerklärung + Einwilligung KI | Recht | Niedrig | | 2 | OpenAI/Supabase DPA prüfen/abschliessen | Recht | Niedrig | | 3 | Incident-Passwort-Rotation abschliessen | Incident | Niedrig | | 4 | Automatisiertes Backup einrichten | Betrieb | Mittel | | 5 | Audit-Logging in API-Endpunkte integrieren | Technik | Mittel | | 6 | Datenverarbeitungsverzeichnis erstellen | Datenschutz | Mittel | | 7 | Löschkonzept + Aufbewahrungsfristen definieren | Datenschutz | Mittel | | 8 | Kurzschulung Datenschutz erstellen | Organisation | Niedrig | | 9 | Minimale Passwortlänge auf 8+ erhöhen | Technik | Niedrig | | 10 | AZA_2FA_REQUIRED=1 als Produktiv-Standard | Technik | Niedrig | --- *Erstellt: 2026-02-22* *Nächste Überprüfung: Nach Umsetzung der priorisierten Massnahmen* *Klassifikation: Intern – Nicht zur externen Weitergabe*