526 lines
16 KiB
Markdown
526 lines
16 KiB
Markdown
|
# 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*
|