From 9f5f8bfc112209f5a563e5cabc16e89a1ad40ac8 Mon Sep 17 00:00:00 2001 From: Stephan Schellworth Date: Wed, 3 Jun 2026 08:50:34 +0200 Subject: [PATCH] Add e-compliance processes and PowerOn AG documentation. Includes CACC/FINMA legal processes, updated AGB with PowerOn AG stammdaten, and internal legal and best-practice analysis report. Co-authored-by: Cursor --- e-compliance/Prozesse/20260528_bcm_runbook.md | 204 +++++ .../Prozesse/20260528_datenbank-handling.md | 183 ++++ .../20260528_drittanbieter-inventar.md | 313 +++++++ .../20260528_feature_release_bugfix.md | 589 ++++++++++++ .../Prozesse/20260603_PowerON_AGB_v1.0_1.md | 857 ++++++++++++++++++ .../legal/00_README_Prozessuebersicht.md | 56 ++ .../01_Informationssicherheitsrichtlinie.md | 66 ++ .../legal/02_Zugriffsmanagement_IAM_PAM.md | 77 ++ .../03_Mitarbeitersicherheit_und_Screening.md | 55 ++ ...rschluesselung_und_Schluesselmanagement.md | 74 ++ .../legal/05_Backup_und_Wiederherstellung.md | 74 ++ ...siness_Continuity_und_Disaster_Recovery.md | 80 ++ .../07_Incident_Response_und_Meldewesen.md | 84 ++ .../Prozesse/legal/08_Change_Management.md | 62 ++ .../Prozesse/legal/09_Patch_Management.md | 52 ++ .../legal/10_Schwachstellenmanagement.md | 53 ++ .../legal/11_Logging_und_Monitoring.md | 66 ++ ...12_Netzwerk_und_Infrastruktursicherheit.md | 68 ++ ...3_Datenaufbewahrung_Loeschung_LegalHold.md | 67 ++ .../Prozesse/legal/14_Exit_und_Transition.md | 73 ++ .../15_Sichere_Softwareentwicklung_SDLC.md | 57 ++ .../legal/16_Kapazitaetsmanagement.md | 54 ++ .../legal/17_Subunternehmer_Management.md | 66 ++ .../18_Analyse_Recht_und_BestPractice.md | 220 +++++ 24 files changed, 3550 insertions(+) create mode 100644 e-compliance/Prozesse/20260528_bcm_runbook.md create mode 100644 e-compliance/Prozesse/20260528_datenbank-handling.md create mode 100644 e-compliance/Prozesse/20260528_drittanbieter-inventar.md create mode 100644 e-compliance/Prozesse/20260528_feature_release_bugfix.md create mode 100644 e-compliance/Prozesse/20260603_PowerON_AGB_v1.0_1.md create mode 100644 e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md create mode 100644 e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md create mode 100644 e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md create mode 100644 e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md create mode 100644 e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md create mode 100644 e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md create mode 100644 e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md create mode 100644 e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md create mode 100644 e-compliance/Prozesse/legal/08_Change_Management.md create mode 100644 e-compliance/Prozesse/legal/09_Patch_Management.md create mode 100644 e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md create mode 100644 e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md create mode 100644 e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md create mode 100644 e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md create mode 100644 e-compliance/Prozesse/legal/14_Exit_und_Transition.md create mode 100644 e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md create mode 100644 e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md create mode 100644 e-compliance/Prozesse/legal/17_Subunternehmer_Management.md create mode 100644 e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md diff --git a/e-compliance/Prozesse/20260528_bcm_runbook.md b/e-compliance/Prozesse/20260528_bcm_runbook.md new file mode 100644 index 0000000..1c02a57 --- /dev/null +++ b/e-compliance/Prozesse/20260528_bcm_runbook.md @@ -0,0 +1,204 @@ +# Runbook: Plattform-Core (PowerOn Gateway) + +Dieses Dokument beschreibt die drei häufigsten Betriebsszenarien für die PowerOn-Plattform. Es richtet sich an alle, die im Notfall handeln müssen — auch ohne tiefes technisches Vorwissen. Die konkreten Befehle sind für die Person gedacht, die den Server-Zugang hat (typisch: Entwickler oder DevOps). + +**Kurze Systemübersicht:** Die Plattform läuft auf einem Server bei Infomaniak (`api.poweron.swiss`). Alle Kundendaten liegen in einer separaten PostgreSQL-Datenbank (`db.poweron.swiss`). Codeänderungen werden über das interne Git-System (Forgejo) automatisch deployed. + +| Umgebung | Server | URL | +|---|---|---| +| Produktion | `ubuntu@api.poweron.swiss` | `https://api.poweron.swiss` | +| Integration (Test) | `ubuntu@api-int.poweron.swiss` | `https://api-int.poweron.swiss` | + +--- + +## 1. Produktivumgebung neu starten + +**Wann nötig?** Die API antwortet nicht mehr, Requests laufen in Timeouts, oder nach einem Konfigurationswechsel soll alles frisch gestartet werden. + +**Was passiert dabei?** Der laufende Prozess wird gestoppt und neu gestartet. Die Datenbank und alle gespeicherten Daten bleiben dabei vollständig erhalten. Nutzer merken einen kurzen Unterbruch von typisch wenigen Sekunden. + +### Normalfall: Service neu starten + +Auf dem Produktionsserver einloggen und den Service neu starten: + +```bash +ssh ubuntu@api.poweron.swiss +sudo systemctl restart gateway +``` + +Danach prüfen, ob alles wieder läuft: + +```bash +sudo systemctl status gateway +``` + +Den Health-Check aufrufen — wenn er `200 OK` zurückgibt, ist alles gut: + +```bash +curl https://api.poweron.swiss/api/admin/health +``` + +### Kompletter Neustart (inkl. Abhängigkeiten neu laden) + +Wenn sich seit dem letzten Deploy neue Bibliotheken geändert haben oder nach einem manuellen Eingriff am Server: + +```bash +ssh ubuntu@api.poweron.swiss +cd /srv/gateway/current +source .venv/bin/activate +pip install -r requirements.txt --no-cache-dir +sudo systemctl restart gateway +``` + +### Wenn der Service nicht startet + +Wenn der Neustart nicht hilft oder der Service sofort wieder abbricht, hilft ein Blick in die Logs: + +```bash +# Systemlogs der letzten 100 Zeilen +sudo journalctl -u gateway -n 100 --no-pager + +# Anwendungslogs des heutigen Tages +tail -100 /srv/gateway/shared/logs/log_app_$(date +%Y%m%d).log +``` + +Wenn der Fehler unklar ist, kann die App auch direkt im Vordergrund gestartet werden — dann erscheint die Fehlermeldung sofort im Terminal: + +```bash +cd /srv/gateway/current +source .venv/bin/activate +gunicorn app:app --bind 0.0.0.0:8000 --timeout 600 \ + --worker-class uvicorn.workers.UvicornWorker --workers 1 +``` + +--- + +## 2. Backup einspielen (Datenbankwiederherstellung) + +**Wann nötig?** Nach einem Datenverlust, einer fehlerhaften Migration oder wenn ein früherer Datenbankstand wiederhergestellt werden muss. + +**Was passiert dabei?** Die Anwendung wird kurz gestoppt, damit während dem Restore niemand inkonsistente Daten sieht. Die bestehenden Daten werden durch den Backup-Stand ersetzt. Danach wird die Anwendung wieder gestartet. Je nach Datenmenge dauert der Restore wenige Minuten bis zu einer Stunde. + +**Wichtig vor dem Start:** Immer zuerst einen aktuellen Snapshot erstellen, bevor man ein älteres Backup einspielt — so kann man auch den Zustand kurz vor dem Restore noch wiederherstellen, falls etwas schiefläuft. + +### Schritt 1: Aktuellen Stand sichern (Sicherheitskopie) + +```bash +ssh ubuntu@api.poweron.swiss +# DB-Passwort aus der Konfiguration lesen: +grep DB_ /srv/gateway/current/.env + +# Alle Datenbanken sichern (Dateien landen in /tmp/) +for DB in poweron_app poweron_management poweron_billing poweron_chat \ + poweron_chatbot poweron_trustee poweron_realestate \ + poweron_knowledge poweron_workspace; do + pg_dump -h db.poweron.swiss -U poweron_dev -p 5432 \ + -Fc $DB > /tmp/backup_${DB}_$(date +%Y%m%d_%H%M%S).dump +done +``` + +### Schritt 2: Anwendung stoppen und Backup einspielen + +```bash +sudo systemctl stop gateway + +# Einzelne Datenbank wiederherstellen (Beispiel: poweron_app) +pg_restore -h db.poweron.swiss -U poweron_dev -p 5432 \ + -d poweron_app --clean --if-exists \ + /pfad/zum/backup_poweron_app_DATUM.dump + +sudo systemctl start gateway +``` + +### Backup einspielen über das Migrations-Tool (alle Datenbanken) + +Wenn ein vollständiges JSON-Export aus dem projekteigenen Migrationstool vorliegt: + +```bash +ssh ubuntu@api.poweron.swiss +cd /srv/gateway/current +source .venv/bin/activate +sudo systemctl stop gateway + +# Hilfe zum Import-Script anzeigen: +python scripts/script_db_export_migration.py --help + +sudo systemctl start gateway +``` + +### Schritt 3: Verifizieren + +```bash +sudo systemctl status gateway +curl https://api.poweron.swiss/api/admin/health +``` + +--- + +## 3. Rollback auf die vorherige Version + +**Wann nötig?** Ein frisch deploytes Update verursacht Fehler oder unerwünschtes Verhalten, das vorher nicht da war. Statt stundenlang zu debuggen, fährt man die Plattform einfach auf den letzten stabilen Stand zurück. + +**Was passiert dabei?** Der Code auf dem Server wird auf einen früheren Git-Commit zurückgesetzt. Die Datenbank bleibt unverändert — nur der Anwendungscode wird ausgetauscht. Das dauert typisch unter 2 Minuten. + +**Hinweis zu Datenbank-Migrationen:** Wenn das neue Update auch Datenbankänderungen enthielt, kann ein reiner Code-Rollback zu Inkompatibilitäten führen. In diesem Fall zusätzlich einen Datenbank-Restore (Szenario 2) in Betracht ziehen und vorher mit dem Entwicklungsteam absprechen. + +### Rollback über Git (empfohlen, schnellster Weg) + +```bash +ssh ubuntu@api.poweron.swiss +cd /srv/gateway/current + +# Die letzten 10 Deployments anzeigen — den gewünschten HASH notieren +git log --oneline -10 + +# Auf den gewählten Stand zurücksetzen (HASH ersetzen, z.B. "b04211be") +git reset --hard + +# Konfigurationsdatei neu setzen +test -f env-prod.env && cp env-prod.env .env && rm -f env-*.env + +# Abhängigkeiten prüfen +source .venv/bin/activate +pip install -r requirements.txt --no-cache-dir + +# Service neu starten und prüfen +sudo systemctl restart gateway +sudo systemctl status gateway +curl https://api.poweron.swiss/api/admin/health +``` + +### Rollback über Forgejo (sauberer, hinterlässt Protokoll) + +Diese Variante ist etwas langsamer (Tests laufen durch), aber der Rollback wird im Git-Verlauf sichtbar und ist für alle nachvollziehbar. + +```bash +# Lokal: einen Revert-Commit erstellen und pushen +git revert HEAD # oder den spezifischen Commit angeben +git push origin main +# → Forgejo startet automatisch Tests und deployed danach +``` + +### Rollback auf der INT-Umgebung + +Gleiche Schritte wie oben, aber mit diesen Werten: +- Server: `ubuntu@api-int.poweron.swiss` +- Branch: `int` statt `main` +- Env-Datei: `env-int.env` +- Health-Check: `https://api-int.poweron.swiss/api/admin/health` + +--- + +## Referenz + +| Was | Wo | +|---|---| +| Prod-Server | `ubuntu@api.poweron.swiss` | +| Int-Server | `ubuntu@api-int.poweron.swiss` | +| App-Pfad auf Server | `/srv/gateway/current` | +| App-Logs | `/srv/gateway/shared/logs/log_app_YYYYMMDD.log` | +| System-Logs | `journalctl -u gateway` | +| Datenbank-Host | `db.poweron.swiss:5432` | +| Datenbank-User | `poweron_dev` | +| Health-Check Endpoint | `GET /api/admin/health` | +| CI/CD Pipeline | `.forgejo/workflows/main_porta-main-platform-core.yml` | diff --git a/e-compliance/Prozesse/20260528_datenbank-handling.md b/e-compliance/Prozesse/20260528_datenbank-handling.md new file mode 100644 index 0000000..1db8ad3 --- /dev/null +++ b/e-compliance/Prozesse/20260528_datenbank-handling.md @@ -0,0 +1,183 @@ +# Datenbank-Handling: Exports, Imports, Backups & Datensicherung + +Dieses Dokument beschreibt, wie die PowerOn-Plattform ihre Datenbanken verwaltet — von der strukturierten Datensicherung über flexible Export- und Import-Werkzeuge bis hin zur sicheren Wiederherstellung. + +--- + +## 1. Datenbankübersicht + +Die Plattform betreibt **13 separate Datenbanken** auf dem Datenbankserver `db.poweron.swiss`. Jede Datenbank gehört einem fachlichen Bereich: + +| Datenbank | Inhalt | +|---|---| +| `poweron_app` | Benutzer, Mandate, Berechtigungen, Features — Kern der Plattform | +| `poweron_management` | Workflows, Prompts, Verbindungen (Connections) | +| `poweron_billing` | Abonnements, Rechnungen, Stripe-Daten | +| `poweron_chat` | Chat-Konversationen und Nachrichten | +| `poweron_chatbot` | Chatbot-Feature: Konversationen, Logs | +| `poweron_knowledge` | RAG-Wissensdatenbank, Dokumentenindizes | +| `poweron_workspace` | Workspace-Daten | +| `poweron_trustee` | Treuhand-spezifische Daten | +| `poweron_realestate` | Immobilien-Daten | +| `poweron_commcoach` | CommCoach-Feature | +| `poweron_neutralization` | Content-Neutralisierung | +| `poweron_teamsbot` | Microsoft Teams Bot | +| `poweron_test` | Testdaten (wird bei Exports ausgeschlossen) | + +--- + +## 2. Export + +Ein Export erstellt eine vollständige Kopie aller Daten in einem lesbaren JSON-Format. Er dient als Grundlage für Backups, Migrationen zwischen Umgebungen (z. B. Prod → Int) und als Sicherungspunkt vor grösseren Änderungen. + +### 2.1 Export via Admin-UI (empfohlen) + +Im SysAdmin-Bereich der Plattform gibt es einen integrierten Export-Button. Er erzeugt eine JSON-Datei, die direkt heruntergeladen wird. + +- **Zugriff:** Nur für SysAdmins (höchste Berechtigungsstufe) +- **Umfang:** Alle Datenbanken oder einzelne auswählbar +- **Dateiname:** `migration_backup_YYYY-MM-DD_HH-MM.json` +- **Rate-Limit:** Max. 2 Exports pro Minute (Schutzmassnahme gegen versehentliche Mehrfachausführung) + +Auch sehr grosse Datenbanken werden sicher übertragen, ohne dass der Server dabei überlastet wird. + +### 2.2 Export via Script (für Entwickler / Server-Zugriff) + +Direkt auf dem Server kann das Export-Script ausgeführt werden: + +```bash +ssh ubuntu@api.poweron.swiss +cd /srv/gateway/current +source .venv/bin/activate + +# Alle Datenbanken exportieren +python scripts/script_db_export_migration.py --pretty + +# Nur bestimmte Datenbanken +python scripts/script_db_export_migration.py --db poweron_app,poweron_management + +# Ohne Metadaten (kleiner, für Archivierung) +python scripts/script_db_export_migration.py --exclude Token,AuthEvent + +# Mit Zusammenfassung (zeigt Tabellen- und Zeilenanzahl) +python scripts/script_db_export_migration.py --summary +``` + +Das Script erstellt automatisch zwei Dateien: +- `migration_export_TIMESTAMP.json` — vollständige Daten +- `migration_export_TIMESTAMP_structure.json` — nur Tabellenstruktur, keine Daten + +### 2.3 Was wird beim Export ausgeschlossen? + +Aus Sicherheits- und Datenschutzgründen werden folgende Tabellen **nie** exportiert: +- `Token` (aktive Login-Sessions) +- `AuthEvent` (Login-Protokoll) +- `poweron_test` (Testdatenbank) + +--- + +## 3. Import + +Ein Import spielt einen zuvor erstellten Export wieder ein. Typische Anwendungsfälle: +- Wiederherstellung eines früheren Datenstands +- Migration zwischen Umgebungen (z. B. Produktionsdaten auf die Testumgebung übertragen) +- Initialisierung einer neuen Instanz + +### 3.1 Zwei Import-Modi + +**Replace (Ersetzen):** +Löscht alle bestehenden Daten (ausser geschützte System-Objekte, siehe unten) und schreibt den Backup-Stand vollständig neu. Verwenden bei vollständiger Wiederherstellung. + +**Merge (Zusammenführen):** +Fügt nur Datensätze ein, die noch nicht existieren (anhand ID). Bestehende Daten bleiben unverändert. Verwenden wenn nur fehlende Daten ergänzt werden sollen. + +### 3.2 Import via Admin-UI + +1. JSON-Datei hochladen +2. Validation läuft automatisch (prüft Format-Version, Struktur, System-Objekte) +3. Import-Modus wählen: `replace` oder `merge` +4. Import starten — Ergebnis zeigt Anzahl eingespielter Datensätze pro Tabelle + +Auch sehr grosse Backup-Dateien können problemlos importiert werden, ohne den Server zu überlasten. + +### 3.3 Geschützte System-Objekte + +Beim Import werden drei kritische Objekte **nie gelöscht oder überschrieben**, unabhängig vom Import-Modus: +- Root-Mandat +- Admin-Benutzer +- Event-Benutzer + +Falls diese Objekte im Backup andere interne Kennungen hatten als in der Zielumgebung, passt das System alle betroffenen Verknüpfungen **automatisch** an. Das verhindert inkonsistente Daten nach dem Import. + +### 3.4 Import via Script + +```bash +ssh ubuntu@api.poweron.swiss +cd /srv/gateway/current +source .venv/bin/activate +sudo systemctl stop gateway + +# Import-Script (Pendant zum Export-Script) +# Datei übergeben, Modus wählen +python scripts/script_db_export_migration.py --help # zeigt alle Optionen + +sudo systemctl start gateway +``` + +--- + +## 4. Backups & Datensicherung + +### 4.1 Backup-Strategie + +Die Plattform verfügt über ein durchdachtes, mehrschichtiges Sicherungskonzept: + +**Infrastruktur-Ebene:** Der Datenbankserver läuft auf der Infomaniak Public Cloud, die Snapshot-Funktionalitäten für Managed Databases bereitstellt. + +**Anwendungs-Ebene:** Über die integrierte Admin-UI kann jederzeit ein vollständiger Export aller Datenbanken erstellt werden — on-demand, gezielt pro Datenbank oder als Gesamtexport. Die Backup-Dateien sind vollständig portabel und können auf jedem Speicher archiviert werden. + +### 4.2 Empfohlene Backup-Praxis + +| Zeitpunkt | Aktion | +|---|---| +| Vor jedem Deployment | Export via Admin-UI, Datei lokal speichern | +| Vor Datenbank-Migrationen | Export erstellen und beschriftet archivieren | +| Wöchentlich | Export als Archiv-Backup ablegen | + +--- + +## 5. Datenbankmigrationen (Struktur-Änderungen) + +Wenn sich das Datenmodell weiterentwickelt — z. B. durch neue Felder oder Tabellen — stellt die Plattform dedizierte Hilfsprogramme bereit, die Datenbankstruktur kontrolliert und sicher anzupassen: + +| Programm | Zweck | +|---|---| +| `script_db_adapt_to_models.py` | Passt die Datenbankstruktur automatisch an den aktuellen Code an (mit Vorschau-Modus ohne Änderungen) | +| `script_db_audit_legacy_state.py` | Analysiert den Datenbankzustand vor einem Bereinigungsschritt | +| `script_db_migrate_*.py` | Datenmigrations-Programme für spezifische Features | +| `script_db_init_automation2.py` | Erstellt die Datenbankstruktur für das Automation-Feature | +| `script_db_init_chatbot.py` | Erstellt die Datenbankstruktur für das Chatbot-Feature | + +Beim Start der Anwendung prüft die Plattform ausserdem automatisch, ob alle benötigten Tabellen vorhanden sind, und legt fehlende selbstständig an. + +--- + +## 6. Datenschutz-Hinweise + +- Export-Dateien enthalten **alle Kundendaten** (Mandate, Benutzer, Chats, Dokumente, etc.) und sind entsprechend zu behandeln +- Dateien dürfen **nicht auf unsicheren Speichern** (persönliche Dropbox, E-Mail, etc.) abgelegt werden +- Export-Dateien sollten nach Nutzung gelöscht werden wenn sie nicht mehr benötigt werden +- Der Zugriff auf Export/Import ist auf SysAdmins beschränkt und wird serverseitig geloggt + +--- + +## Zusammenfassung: Datenbankoperationen im Überblick + +| Aufgabe | Wie | +|---|---| +| Fehlende Tabellen beim Start anlegen | Automatisch beim Plattform-Start | +| Datenbank-Export / Backup | Admin-UI (ein Klick) oder Entwickler-Script | +| Datenbank-Import / Wiederherstellung | Admin-UI mit geführtem Prozess oder Entwickler-Script | +| Infrastruktur-Snapshots | Infomaniak Cloud (Serverebene) | +| Struktur-Anpassungen bei Updates | Kontrolliert durch Entwickler-Hilfsprogramme | +| Datenbankpflege & Bereinigung | Admin-UI | diff --git a/e-compliance/Prozesse/20260528_drittanbieter-inventar.md b/e-compliance/Prozesse/20260528_drittanbieter-inventar.md new file mode 100644 index 0000000..01d710a --- /dev/null +++ b/e-compliance/Prozesse/20260528_drittanbieter-inventar.md @@ -0,0 +1,313 @@ +# Drittanbieter-Inventar: Plattform-Core + +Dieses Dokument listet alle externen Dienste und Plattformen auf, mit denen die PowerOn-Plattform direkt integriert ist. Es basiert auf einer Auswertung des Quellcodes (Stand: Mai 2026). + +**Verantwortlicher für alle Drittdienste:** Patrick Motsch — p.motsch@poweron.swiss + +--- + +## 1. KI-Provider (LLM) + +Diese Dienste liefern die KI-Intelligenz der Plattform. Fällt einer aus, sind die entsprechenden AI-Features nicht mehr verfügbar, je nach Konfiguration kann auf einen anderen Provider ausgewichen werden. + +### OpenAI + +| Feld | Wert | +|---|---| +| **Kategorie** | LLM-Provider | +| **Verwendung** | Chat-Completions, Embeddings für RAG/Suche, Bildgenerierung (DALL·E). Primärer AI-Provider. | +| **Kritikalität** | Ja — Ausfall betrifft Chat, Agent, Automation-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.openai.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +### Anthropic (Claude) + +| Feld | Wert | +|---|---| +| **Kategorie** | LLM-Provider | +| **Verwendung** | Chat-Completions, Agent-Workflows als Alternative zu OpenAI | +| **Kritikalität** | Nein — nur wenn als aktiver Provider konfiguriert | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.anthropic.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +### Mistral AI + +| Feld | Wert | +|---|---| +| **Kategorie** | LLM-Provider | +| **Verwendung** | Chat-Completions und Embeddings als Alternative zu OpenAI | +| **Kritikalität** | Nein — nur wenn als aktiver Provider konfiguriert | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://mistral.ai/status | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +### Perplexity AI + +| Feld | Wert | +|---|---| +| **Kategorie** | LLM-Provider (mit Web-Zugriff) | +| **Verwendung** | Chat-Completions mit integrierter Websuche | +| **Kritikalität** | Nein — optionaler Provider | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.perplexity.ai | +| **Vertragslaufzeit / Kündigung** | unbefristet | + + +### Tavily + +| Feld | Wert | +|---|---| +| **Kategorie** | AI-Websuche | +| **Verwendung** | Echtzeit-Websuche für AI-Agenten und LangChain-Workflows | +| **Kritikalität** | Nein — betrifft nur Research-/Agent-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.tavily.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +--- + +## 2. Infrastruktur & Hosting + +### Infomaniak (Server & Datenbank) + +| Feld | Wert | +|---|---| +| **Kategorie** | Cloud Hosting / Managed Database | +| **Verwendung** | VM-Hosting für Prod- und Int-Server (`api.poweron.swiss`, `api-int.poweron.swiss`), PostgreSQL-Datenbank (`db.poweron.swiss`) | +| **Kritikalität** | **Ja** — Totalausfall der Plattform bei Ausfall | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.infomaniak.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +--- + +## 3. Authentifizierung & Login + +### Microsoft Azure AD (OAuth) + +| Feld | Wert | +|---|---| +| **Kategorie** | Auth / Identity Provider | +| **Verwendung** | Login via Microsoft-Konto (OAuth 2.0). Auch Basis für Microsoft 365 Datenzugriff. | +| **Kritikalität** | Ja — Login für Microsoft-Nutzer nicht möglich bei Ausfall | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.azure.com | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +### Google OAuth + +| Feld | Wert | +|---|---| +| **Kategorie** | Auth / Identity Provider | +| **Verwendung** | Login via Google-Konto. Auch Basis für Google Workspace Datenzugriff. | +| **Kritikalität** | Ja — Login für Google-Nutzer nicht möglich bei Ausfall | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.google.com/appsstatus | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +--- + +## 4. Daten-Konnektoren (Dateiablage, Kalender, Kontakte) + +Diese Dienste sind optionale Verbindungen, die Endkunden in ihrer Mandanten-Konfiguration aktivieren können. Ein Ausfall betrifft die Kunden, die diesen Konnektor aktiv nutzen. + +### Microsoft 365 (SharePoint / OneDrive / Outlook / Calendar) + +| Feld | Wert | +|---|---| +| **Kategorie** | Datei- & Kommunikationsplattform (Konnektor) | +| **Verwendung** | Dateizugriff auf SharePoint/OneDrive, E-Mail-Lesen und -Senden via Outlook, Kalender-Integration via Microsoft Graph API | +| **Kritikalität** | Nein (nur für Kunden mit aktivem MS365-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.office365.com | +| **Vertragslaufzeit / Kündigung** | Kundenseitig (eigenes Microsoft-Konto des Kunden) | + +### Google Workspace (Drive / Gmail / Calendar / Contacts) + +| Feld | Wert | +|---|---| +| **Kategorie** | Datei- & Kommunikationsplattform (Konnektor) | +| **Verwendung** | Dateizugriff auf Google Drive, Gmail lesen/senden, Google Calendar, Google Contacts via Google APIs | +| **Kritikalität** | Nein (nur für Kunden mit aktivem Google-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.google.com/appsstatus | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +### Infomaniak (kDrive / Kalender / Kontakte) + +| Feld | Wert | +|---|---| +| **Kategorie** | Datei- & Kommunikationsplattform (Konnektor) | +| **Verwendung** | Dateizugriff auf kDrive, Infomaniak Calendar, Infomaniak Contacts via Personal Access Token | +| **Kritikalität** | Nein (nur für Kunden mit aktivem Infomaniak-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.infomaniak.com | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +### FTP + +| Feld | Wert | +|---|---| +| **Kategorie** | Dateikonnektor | +| **Verwendung** | Generischer FTP/SFTP-Zugriff für Kunden mit FTP-Verbindung | +| **Kritikalität** | Nein (nur für Kunden mit aktivem FTP-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | Kundenseitig | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +--- + +## 5. Ticket-Systeme (Konnektoren) + +### ClickUp + +| Feld | Wert | +|---|---| +| **Kategorie** | Projektmanagement / Ticketing (Konnektor) | +| **Verwendung** | Aufgaben und Tickets lesen/erstellen/aktualisieren via ClickUp API v2 und OAuth | +| **Kritikalität** | Nein (nur für Kunden mit aktivem ClickUp-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://clickupstatus.com | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +### Jira + +| Feld | Wert | +|---|---| +| **Kategorie** | Projektmanagement / Ticketing (Konnektor) | +| **Verwendung** | Tickets lesen/erstellen via Jira REST API | +| **Kritikalität** | Nein (nur für Kunden mit aktivem Jira-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://jira-software.status.atlassian.com | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +### Redmine + +| Feld | Wert | +|---|---| +| **Kategorie** | Projektmanagement / Ticketing (Konnektor) | +| **Verwendung** | Tickets lesen/erstellen via Redmine REST API | +| **Kritikalität** | Nein (nur für Kunden mit aktivem Redmine-Konnektor) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | Kundenseitig | +| **Vertragslaufzeit / Kündigung** | Kundenseitig | + +--- + +## 6. Payment + +### Stripe + +| Feld | Wert | +|---|---| +| **Kategorie** | Payment Provider | +| **Verwendung** | Abonnement-Management, Zahlungsabwicklung, automatische Steuerberechnung (CH MwSt). API-Version `2026-01-28`. | +| **Kritikalität** | **Ja** — Neue Abonnements und Zahlungen schlagen fehl bei Ausfall | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.stripe.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +--- + +## 7. Messaging & Kommunikation + +### Azure Communication Services (E-Mail) + +| Feld | Wert | +|---|---| +| **Kategorie** | Transaktions-E-Mail | +| **Verwendung** | Systemmails (Einladungen, Passwort-Reset, Rechnungen) via `DoNotReply@poweron.swiss`. Endpunkt: `mailing-poweron-prod.switzerland.communication.azure.com` | +| **Kritikalität** | **Ja** — Einladungs- und Benachrichtigungs-E-Mails werden nicht zugestellt | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.azure.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +### Twilio (SMS) + +| Feld | Wert | +|---|---| +| **Kategorie** | SMS-Gateway | +| **Verwendung** | SMS-Versand (z. B. 2FA, Benachrichtigungen) | +| **Kritikalität** | Nein — nur wenn SMS-Feature aktiv genutzt wird | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.twilio.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +--- + +## 8. Google Cloud Services + +### Google Cloud Speech-to-Text / Text-to-Speech + +| Feld | Wert | +|---|---| +| **Kategorie** | Sprach-KI (STT/TTS) | +| **Verwendung** | Sprache-zu-Text-Transkription und Text-zu-Sprache-Synthese für Voice-Features | +| **Kritikalität** | Nein — betrifft nur Voice-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.cloud.google.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +### Google Cloud Translate + +| Feld | Wert | +|---|---| +| **Kategorie** | Übersetzungsdienst | +| **Verwendung** | Automatische Übersetzung von Inhalten | +| **Kritikalität** | Nein — betrifft nur Übersetzungsfeatures | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://status.cloud.google.com | +| **Vertragslaufzeit / Kündigung** | unbefristet | + +--- + +## 9. Schweizer Geodienste (öffentliche APIs) + +Diese Dienste sind öffentlich zugängliche Schnittstellen des Bundes und der Kantone. Kein Login, kein Vertrag erforderlich — aber ein Ausfall beeinträchtigt Geo-Features. + +### swisstopo MapServer & Geocoding + +| Feld | Wert | +|---|---| +| **Kategorie** | Geodaten / Kartendienst | +| **Verwendung** | Adress-Geocoding, Karteninformationen, Parzellen-Identifikation via `api3.geo.admin.ch` | +| **Kritikalität** | Nein — betrifft nur Immobilien-/Geo-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.geo.admin.ch | +| **Vertragslaufzeit / Kündigung** | Kostenloser öffentlicher Dienst | + +### STAC API (swisstopo) + +| Feld | Wert | +|---|---| +| **Kategorie** | Geodaten (Satellitenbilder / Rasterdaten) | +| **Verwendung** | Zugriff auf georäumliche Katalogdaten via `data.geo.admin.ch` | +| **Kritikalität** | Nein — betrifft nur Geo-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.geo.admin.ch | +| **Vertragslaufzeit / Kündigung** | Kostenloser öffentlicher Dienst | + +### ÖREB-Kataster WFS (Kanton Zürich) + +| Feld | Wert | +|---|---| +| **Kategorie** | Geodaten / Rechtliche Grundlagen Grundstücke | +| **Verwendung** | Abruf öffentlich-rechtlicher Eigentumsbeschränkungen (ÖREB) für Parzellen via `maps.zh.ch` | +| **Kritikalität** | Nein — betrifft nur Immobilien-Features (ZH) | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.zh.ch/de/direktion-der-justiz-und-des-innern/geoinformation.html | +| **Vertragslaufzeit / Kündigung** | Kostenloser öffentlicher Dienst | + +### Geodienste.ch (Amtliche Vermessung ZH) + +| Feld | Wert | +|---|---| +| **Kategorie** | Geodaten / Amtliche Vermessung | +| **Verwendung** | WFS-Abfragen für Parzellensuche via `www.geodienste.ch` | +| **Kritikalität** | Nein — betrifft nur Immobilien-Features | +| **Ansprechpartner** | Patrick Motsch — p.motsch@poweron.swiss | +| **Statusseite** | https://www.geodienste.ch | +| **Vertragslaufzeit / Kündigung** | Kostenloser öffentlicher Dienst | + diff --git a/e-compliance/Prozesse/20260528_feature_release_bugfix.md b/e-compliance/Prozesse/20260528_feature_release_bugfix.md new file mode 100644 index 0000000..7895429 --- /dev/null +++ b/e-compliance/Prozesse/20260528_feature_release_bugfix.md @@ -0,0 +1,589 @@ +# Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management + +**Dokumenttyp:** Prozessbeschreibung / SOP +**Geltungsbereich:** Softwareentwicklung, Release Management, Bugfixing +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Entwicklung / Produktverantwortung +**Letzte Aktualisierung:** 28.05.2026 + +--- + +## 1. Zweck des Dokuments + +Dieses Dokument beschreibt einen auditkonformen Prozess für: + +- die strukturierte Aufnahme, Bewertung und Umsetzung von Feature-Requests, +- die Durchführung technischer Workshops vor Implementierungsbeginn, +- die kontrollierte Entwicklung über Branches, Reviews und Staging-Verifikation, +- die versionierte Erstellung von Release Notes, +- die Erfassung, Priorisierung, Bearbeitung und Dokumentation von Bugs, +- die Nachvollziehbarkeit von Entscheidungen, Änderungen, Verantwortlichkeiten und Freigaben. + +Ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren Entwicklungs- und Release-Prozess sicherzustellen. + +--- + +## 2. Prozessübersicht + +Der Gesamtprozess besteht aus zwei Hauptsträngen: + +1. **Feature-Entwicklung & Releases** +2. **Bug-Management & Bugfixing** + +Beide Stränge folgen gemeinsamen Prinzipien: + +- zentrale Erfassung aller Anforderungen und Fehler, +- dokumentierte Bewertung und Priorisierung, +- nachvollziehbare technische Entscheidungen, +- Vier-Augen-Prinzip vor produktivem Release, +- dokumentierte Release Notes, +- klare Verantwortlichkeiten, +- prüfbare Nachweise in Tickets, Branches, Pull Requests und Changelogs. + +--- + +## 3. Prozessbild + +```mermaid +flowchart TD + + A[Feature Request oder Bug Report geht ein] --> B{Art des Eingangs} + + B -->|Feature Request| F1[Zentrale Erfassung
z. B. GitHub Issues, Linear, Notion] + F1 --> F2[Priorisierung nach Kundenwert,
strategischer Relevanz und Aufwand] + F2 --> F3[Feature mit hoher Priorität
für Tech Workshop vormerken] + F3 --> F4[Tech Workshop mit beiden Entwicklern] + F4 --> F5[Architektur-, API-, Datenmodell-
und Schnittstellenanalyse] + F5 --> F6[Aufwandsschätzung,
Aufgabenverteilung und Akzeptanzkriterien] + F6 --> F7[Dokumentation im Issue
oder internen Ticket] + F7 --> F8[Entwicklung auf Feature Branch
feature/kurzbeschreibung] + F8 --> F9[Commits mit aussagekräftigen Messages
z. B. feat:, fix:, chore:] + F9 --> F10[Code Review durch zweiten Entwickler] + F10 --> F11{Review bestanden?} + F11 -->|Nein| F12[Überarbeitung durch Entwickler] + F12 --> F10 + F11 -->|Ja| F13[Merge in Main/Development Branch] + F13 --> F14[Deployment in Staging] + F14 --> F15[Finale Verifikation gegen Akzeptanzkriterien] + F15 --> F16{Verifikation bestanden?} + F16 -->|Nein| F12 + F16 -->|Ja| F17[Release / Push in Produktion] + F17 --> F18[Release Notes erstellen und versionieren] + F18 --> F19[CHANGELOG.md und /changelog aktualisieren] + + B -->|Bug Report| G1[Zentrale Erfassung
z. B. ClickUp Formular] + G1 --> G2[Initiale Antwort gemäß Schweregrad] + G2 --> G3[Triage durch Mitarbeiter 1] + G3 --> G4[Prüfung auf Vollständigkeit
und Reproduzierbarkeit] + G4 --> G5[Klassifizierung:
Kritisch / Hoch / Mittel / Niedrig] + G5 --> G6[Zuweisung an zuständigen Entwickler] + G6 --> G7[Fix auf Bugfix Branch
fix/kurzbeschreibung] + G7 --> G8[Code Review durch Mitarbeiter 1] + G8 --> G9{Review bestanden?} + G9 -->|Nein| G10[Nachbesserung durch Entwickler] + G10 --> G8 + G9 -->|Ja| G11[Merge analog Feature-Prozess] + G11 --> G12[Staging-Verifikation] + G12 --> G13{Fix verifiziert?} + G13 -->|Nein| G10 + G13 -->|Ja| G14[Release in Produktion] + G14 --> G15[Dokumentation in Release Notes / CHANGELOG] + G15 --> G16[Melder informieren und Ticket schließen] +``` + +--- + +## 4. Rollen und Verantwortlichkeiten + +| Rolle | Verantwortung | +|---|---| +| Entwickler 1 | Teilnahme am Tech Workshop, Entwicklung, Review, ggf. Triage | +| Entwickler 2 | Teilnahme am Tech Workshop, Entwicklung, Review, Release-Durchführung | +| Mitarbeiter 1 / Triage-Rolle | Prüfung eingehender Bug Reports, Klassifizierung, Reproduzierbarkeit, Zuweisung, Review von Bugfixes | +| Mitarbeiter 2 / Entwicklungsrolle | Umsetzung von Bugfixes auf separatem Branch, Dokumentation technischer Änderungen | +| Release-Verantwortlicher | Durchführung des Releases, Pflege der Release Notes, Aktualisierung von CHANGELOG.md und /changelog | +| Produkt-/Business-Verantwortlicher | Bewertung von Kundenwert und strategischer Relevanz bei Feature Requests | + +--- + +# 5. Feature-Entwicklung & Releases + +## 5.1 Feature-Request-Prozess + +Eingehende Feature-Requests werden zentral gesammelt. Mögliche Systeme sind: + +- GitHub Issues, +- Linear, +- Notion, +- ein internes Produkt-Backlog. + +Jeder Feature Request muss mindestens folgende Informationen enthalten: + +| Pflichtfeld | Beschreibung | +|---|---| +| Titel | Kurze, eindeutige Beschreibung des gewünschten Features | +| Beschreibung | Fachliche Beschreibung des Bedarfs | +| Nutzen | Erwarteter Mehrwert für Kunden, Nutzer oder internes Team | +| Quelle | Kunde, interner Stakeholder, Entwickler, Support oder Management | +| Prioritätsbewertung | Bewertung nach definierten Kriterien | +| Status | Neu, in Bewertung, geplant, in Umsetzung, umgesetzt, abgelehnt | + +## 5.2 Priorisierung + +Die Priorisierung erfolgt anhand folgender Kriterien: + +| Kriterium | Beschreibung | Bewertung | +|---|---|---| +| Kundenwert | Relevanz für Nutzer oder Kunden | 1 = gering, 2 = mittel, 3 = hoch | +| Strategische Relevanz | Beitrag zur Produktstrategie | 1 = gering, 2 = mittel, 3 = hoch | +| Implementierungsaufwand | Technischer und organisatorischer Aufwand | 1 = gering, 2 = mittel, 3 = hoch | + +Alternativ kann eine MoSCoW-Kategorisierung verwendet werden: + +| Kategorie | Bedeutung | +|---|---| +| Must have | zwingend erforderlich | +| Should have | wichtig, aber nicht kritisch | +| Could have | optional, wenn Kapazität vorhanden | +| Won't have | bewusst zurückgestellt | + +Features mit höchster Priorität werden für den nächsten Tech Workshop vorgemerkt. + +--- + +## 5.3 Tech Workshop vor Implementierungsbeginn + +Vor der Implementierung priorisierter Features findet ein Tech Workshop statt. + +**Teilnehmer:** + +- beide Entwickler, +- optional Produkt-/Business-Verantwortlicher bei fachlicher Klärung. + +**Inhalte des Tech Workshops:** + +- Analyse architektonischer Auswirkungen, +- Prüfung betroffener Systeme, Schnittstellen und Datenmodelle, +- Definition möglicher API-Änderungen, +- Definition neuer Endpunkte, +- Prüfung von Abhängigkeiten zu Drittdiensten, +- Aufwandsschätzung, +- Aufgabenverteilung, +- Definition von Akzeptanzkriterien, +- Festlegung von technischen Risiken, +- Dokumentation der Entscheidung. + +**Auditnachweis:** + +Das Ergebnis des Tech Workshops wird dokumentiert, z. B. als: + +- Issue-Kommentar, +- internes Ticket, +- kurzer Workshop-Vermerk, +- technische Entscheidungsnotiz. + +--- + +## 5.4 Entwicklungsprozess + +Jedes Feature wird auf einem separaten Feature Branch entwickelt. + +**Branch-Konvention:** + +```text +feature/kurzbeschreibung +``` + +**Beispiele:** + +```text +feature/user-export +feature/payment-dashboard +feature/api-rate-limit +``` + +**Commit-Konvention:** + +Commits sollen aussagekräftige Messages enthalten, vorzugsweise nach dem Muster der Conventional Commits. + +**Beispiele:** + +```text +feat: add user export endpoint +fix: correct validation for release note dates +chore: update dependency configuration +``` + +--- + +## 5.5 Code Review + +Vor jedem Merge ist ein Code Review durch den jeweils anderen Entwickler erforderlich. + +**Review-Fokus:** + +- Codequalität, +- Sicherheit, +- Konsistenz, +- Architektur, +- Einhaltung der Akzeptanzkriterien, +- potenzielle Seiteneffekte, +- Lesbarkeit und Wartbarkeit, +- Auswirkungen auf Schnittstellen oder Datenmodelle. + +**Auditkontrolle:** + +Ein Merge darf nur erfolgen, wenn das Review dokumentiert und freigegeben wurde. + +--- + +## 5.6 Staging-Verifikation und Release + +Nach bestandenem Review erfolgt: + +1. Merge in den Main- oder Development-Branch, +2. Deployment in die Staging-Umgebung, +3. finale Verifikation gegen die Akzeptanzkriterien, +4. Release bzw. Push in Produktion, +5. Dokumentation im Release-Prozess. + +Die produktive Veröffentlichung darf erst erfolgen, wenn die Staging-Verifikation erfolgreich abgeschlossen wurde. + +--- + +# 6. Release Notes + +## 6.1 Grundsatz + +Release Notes werden mit jedem Merge bzw. Release erstellt und versioniert. + +Es wird semantische Versionierung verwendet: + +```text +MAJOR.MINOR.PATCH +``` + +**Beispiel:** + +```text +1.4.2 +``` + +## 6.2 Inhalt einer Release Note + +Jede Release Note enthält mindestens: + +| Abschnitt | Inhalt | +|---|---| +| Versionsnummer | z. B. 1.4.2 | +| Datum | Datum des Releases | +| Neue Features | kurze Beschreibung, ggf. Nutzen für User | +| Behobene Bugs | Liste der korrigierten Fehler | +| Breaking Changes | prominent hervorgehobene inkompatible Änderungen | +| Technische Änderungen | interne Infrastruktur-, API- oder Architekturänderungen | + +## 6.3 Ablageorte + +| Ablageort | Zielgruppe | Inhalt | +|---|---|---| +| `CHANGELOG.md` im Wiki-Repository | technische Zielgruppe | vollständige Release-Historie | +| `/changelog` | intern / technisch | ausführliche Details je Release | +| Produktbereich | Endnutzer | kurze, nicht-technische Zusammenfassung, derzeit optional | + +## 6.4 Verantwortlichkeit + +Verantwortlich für die Release Notes ist der Entwickler, der den Release durchführt. + +--- + +# 7. Bug-Management & Bugfixing + +## 7.1 Eingang und Erstreaktion + +Bug Reports werden zentral erfasst, z. B. über ein ClickUp Formular. + +Jeder Bug Report soll mindestens enthalten: + +| Pflichtfeld | Beschreibung | +|---|---| +| Titel | Kurze Fehlerbeschreibung | +| Beschreibung | Was ist passiert? | +| Erwartetes Verhalten | Was hätte passieren sollen? | +| Tatsächliches Verhalten | Was ist tatsächlich passiert? | +| Reproduktionsschritte | Schritte zur Nachstellung des Fehlers | +| Schweregrad | Kritisch, Hoch, Mittel, Niedrig | +| Screenshots / Logs | falls vorhanden | +| Melder | Person oder Quelle des Reports | + +## 7.2 Initiale Antwortzeiten + +| Schweregrad | Beschreibung | Initiale Antwort | +|---|---|---| +| Kritisch | Produktionsausfall, Datenverlust | innerhalb von 2 Stunden | +| Hoch | wesentliche Funktion defekt | innerhalb von 1 Werktag | +| Mittel | eingeschränkte Funktion, Workaround möglich | innerhalb von 2 Werktagen | +| Niedrig | kosmetisch oder selten auftretend | innerhalb von 5 Werktagen | + +--- + +## 7.3 Triage und Priorisierung + +Die Triage wird durch Mitarbeiter 1 durchgeführt. + +**Aufgaben der Triage-Rolle:** + +- Prüfung auf Vollständigkeit, +- Prüfung auf Reproduzierbarkeit, +- Rückfrage bei unvollständigen Reports, +- Klassifizierung nach Schweregrad, +- Zuweisung an zuständigen Entwickler, +- Dokumentation der Entscheidung im Ticket. + +**Schweregrade:** + +| Schweregrad | Definition | +|---|---| +| Kritisch | Produktionsausfall, Datenverlust, sicherheitsrelevanter Vorfall oder vollständige Nichtnutzbarkeit | +| Hoch | zentrale Funktion defekt, erhebliche Nutzerbeeinträchtigung | +| Mittel | eingeschränkte Funktion, Workaround vorhanden | +| Niedrig | kosmetischer Fehler, seltenes Randverhalten, geringe Auswirkungen | + +--- + +## 7.4 Ziellösungszeiten / SLOs + +| Priorität | Initiale Antwort | Angestrebte Lösung | +|---|---:|---:| +| Kritisch | 2 Stunden | 24 Stunden | +| Hoch | 1 Werktag | 3 Werktage | +| Mittel | 2 Werktage | 2 Wochen | +| Niedrig | 5 Werktage | nächster Release | + +Die SLOs sind Zielwerte. Abweichungen müssen im Ticket nachvollziehbar begründet werden. + +--- + +## 7.5 Fixing und Release + +Die Umsetzung erfolgt durch Mitarbeiter 2 bzw. den zuständigen Entwickler. + +**Branch-Konvention:** + +```text +fix/kurzbeschreibung +``` + +**Beispiele:** + +```text +fix/login-timeout +fix/export-validation +fix/payment-status-mapping +``` + +**Ablauf:** + +1. Bugfix Branch erstellen, +2. Fehler reproduzieren, +3. Ursache analysieren, +4. Fix implementieren, +5. Tests bzw. Verifikation durchführen, +6. Code Review durch Mitarbeiter 1, +7. Merge analog Feature-Prozess, +8. Deployment in Staging, +9. finale Verifikation, +10. Release in Produktion, +11. Dokumentation in Release Notes / CHANGELOG, +12. Information an Melder, +13. Ticket schließen. + +--- + +# 8. Kontrollpunkte und Auditnachweise + +| Kontrollpunkt | Beschreibung | Nachweis | +|---|---|---| +| Zentrale Erfassung | Alle Requests und Bugs werden in definierten Systemen erfasst | Issue, Ticket, Formular | +| Priorisierung | Bewertung anhand definierter Kriterien | Prioritätsfeld, Score, Kommentar | +| Tech Workshop | technische Analyse vor Implementierung | Workshop-Kommentar, Ticketnotiz | +| Akzeptanzkriterien | fachliche und technische Erfolgskriterien | Ticketbeschreibung | +| Branching | getrennte Branches je Feature oder Bugfix | Git Branch | +| Commit-Konvention | nachvollziehbare Änderungshistorie | Git Commit History | +| Code Review | Vier-Augen-Prinzip vor Merge | Pull Request Review | +| Staging-Verifikation | Prüfung vor Produktion | Testkommentar, Checkliste | +| Release Notes | versionierte Dokumentation jeder Änderung | CHANGELOG.md, /changelog | +| Bug-Triage | Klassifizierung und Zuweisung | Bug Ticket | +| SLO-Überwachung | Prüfung von Antwort- und Lösungszeiten | Ticket-Zeitstempel | +| Ticketabschluss | Abschluss mit nachvollziehbarem Ergebnis | Status, Kommentar, Melderinfo | + +--- + +# 9. Definition of Done + +Ein Feature oder Bugfix gilt erst als abgeschlossen, wenn folgende Kriterien erfüllt sind: + +- Umsetzung auf separatem Branch erfolgt, +- aussagekräftige Commits vorhanden, +- Code Review durch zweite Person durchgeführt, +- Review-Kommentare wurden bearbeitet, +- Merge in Main/Development erfolgt, +- Staging-Verifikation erfolgreich abgeschlossen, +- Akzeptanzkriterien erfüllt, +- Release Notes aktualisiert, +- CHANGELOG.md bzw. /changelog aktualisiert, +- bei Bugs: Melder informiert, +- Ticket geschlossen oder auf erledigt gesetzt. + +--- + +# 10. Risiken und Kontrollen + +| Risiko | Auswirkung | Kontrolle | +|---|---|---| +| Unklare Anforderungen | Fehlentwicklung, Rework | Akzeptanzkriterien und Tech Workshop | +| Fehlende Priorisierung | falsche Ressourcenallokation | Scoring oder MoSCoW | +| Direkter Merge ohne Review | Qualitäts- und Sicherheitsrisiken | verpflichtendes Vier-Augen-Prinzip | +| Unvollständige Release Notes | fehlende Nachvollziehbarkeit | Release-Checkliste | +| Bugs ohne Triage | falsche Dringlichkeit | definierte Triage-Rolle | +| SLO-Verletzungen ohne Begründung | fehlende Steuerbarkeit | Ticketkommentar bei Abweichung | +| Produktivfehler nach Release | Nutzerbeeinträchtigung | Staging-Verifikation vor Produktion | + +--- + +# 11. Empfohlene Ticket-Templates + +## 11.1 Feature Request Template + +```markdown +## Feature Request + +### Titel +Kurzbeschreibung des Features + +### Beschreibung +Was soll umgesetzt werden? + +### Nutzen +Welchen Mehrwert liefert das Feature? + +### Quelle +Kunde / intern / Support / Management + +### Priorisierung +- Kundenwert: 1 / 2 / 3 +- Strategische Relevanz: 1 / 2 / 3 +- Implementierungsaufwand: 1 / 2 / 3 + +### Akzeptanzkriterien +- [ ] Kriterium 1 +- [ ] Kriterium 2 +- [ ] Kriterium 3 + +### Technische Hinweise +Betroffene Systeme, APIs, Datenmodelle oder Schnittstellen + +### Entscheidung Tech Workshop +Kurzprotokoll / Ergebnis +``` + +--- + +## 11.2 Bug Report Template + +```markdown +## Bug Report + +### Titel +Kurzbeschreibung des Fehlers + +### Beschreibung +Was ist passiert? + +### Erwartetes Verhalten +Was hätte passieren sollen? + +### Tatsächliches Verhalten +Was ist tatsächlich passiert? + +### Reproduktionsschritte +1. Schritt 1 +2. Schritt 2 +3. Schritt 3 + +### Schweregrad +Kritisch / Hoch / Mittel / Niedrig + +### Auswirkungen +Welche Nutzer, Systeme oder Daten sind betroffen? + +### Workaround +Ja / Nein / Beschreibung + +### Anhänge +Screenshots, Logs, Videos + +### Triage-Ergebnis +- Vollständig: Ja / Nein +- Reproduzierbar: Ja / Nein +- Zugewiesen an: +- Zieltermin: +``` + +--- + +## 11.3 Release Note Template + +```markdown +# Release Notes + +## Version +x.y.z + +## Datum +TT.MM.JJJJ + +## Neue Features +- Beschreibung des Features und Nutzen + +## Behobene Bugs +- Beschreibung des behobenen Fehlers + +## Breaking Changes +- Keine / Beschreibung der Änderung + +## Technische Änderungen +- API, Infrastruktur, Datenmodell oder Abhängigkeiten + +## Verantwortlich +Name des Release-Verantwortlichen + +## Referenzen +- Issue / Ticket / Pull Request +``` + +--- + +# 12. Freigabe und Review des Prozesses + +Dieser Prozess sollte regelmäßig überprüft werden, mindestens jedoch: + +- bei wesentlichen Änderungen am Entwicklungsprozess, +- bei Einführung neuer Tools, +- nach größeren Incidents, +- vor externen Audits, +- mindestens einmal jährlich. + +| Freigabefeld | Eintrag | +|---|---| +| Prozessverantwortlicher | | +| Fachliche Freigabe | | +| Technische Freigabe | | +| Datum der Freigabe | | +| Nächste Überprüfung | | + +--- + +# 13. Kurzfazit + +Der beschriebene Prozess stellt sicher, dass Feature-Entwicklung, Bugfixing und Releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. Durch zentrale Erfassung, klare Rollen, dokumentierte Priorisierung, Tech Workshops, Branching-Konventionen, Code Reviews, Staging-Verifikation und versionierte Release Notes entsteht ein robuster Entwicklungsprozess mit belastbaren Nachweisen für interne und externe Prüfungen. diff --git a/e-compliance/Prozesse/20260603_PowerON_AGB_v1.0_1.md b/e-compliance/Prozesse/20260603_PowerON_AGB_v1.0_1.md new file mode 100644 index 0000000..c7bdc84 --- /dev/null +++ b/e-compliance/Prozesse/20260603_PowerON_AGB_v1.0_1.md @@ -0,0 +1,857 @@ +# Allgemeine Geschäftsbedingungen (AGB) +## PowerOn AG — PORTA Enterprise KI-Plattform + +**Version 1.0 | Stand: 01.02.2026** +**Gilt ab: 01.02.2026** + +--- + +> **Hinweis zur Anwendung:** Diese AGB gelten für alle Unternehmenskunden (B2B) der PowerOn AG. Für regulierte Finanzinstitute (FINMA-beaufsichtigte Institute) und Einrichtungen des Gesundheitswesens (BAG-reguliert) sind ergänzend ein individueller Dienstleistungsvertrag und ein Auftragsverarbeitungsvertrag (AVV) abzuschliessen, welche diesen AGB vorgehen, soweit sie von ihnen abweichen. + +--- + +## Inhalt + +1. [Vertragsparteien und Geltungsbereich](#1-vertragsparteien-und-geltungsbereich) +2. [Leistungsbeschreibung](#2-leistungsbeschreibung) +3. [Vertragsschluss und Laufzeit](#3-vertragsschluss-und-laufzeit) +4. [Vergütung und Zahlungsbedingungen](#4-vergütung-und-zahlungsbedingungen) +5. [Nutzungsrechte und geistiges Eigentum](#5-nutzungsrechte-und-geistiges-eigentum) +6. [Datenschutz und Auftragsverarbeitung](#6-datenschutz-und-auftragsverarbeitung) +7. [Datenspeicherung und -lokalisierung](#7-datenspeicherung-und--lokalisierung) +8. [Informationssicherheit](#8-informationssicherheit) +9. [Verschlüsselung und Schlüsselmanagement](#9-verschlüsselung-und-schlüsselmanagement) +10. [Verfügbarkeit und Service Level Agreement](#10-verfügbarkeit-und-service-level-agreement) +11. [Business Continuity und Notfallplanung](#11-business-continuity-und-notfallplanung) +12. [Subunternehmer und LLM-Anbieter](#12-subunternehmer-und-llm-anbieter) +13. [Vertraulichkeit und Berufsgeheimnis](#13-vertraulichkeit-und-berufsgeheimnis) +14. [Meldepflichten](#14-meldepflichten) +15. [Legal Hold und Datenaufbewahrung](#15-legal-hold-und-datenaufbewahrung) +16. [Datenrückgabe, -export und -löschung (Exit)](#16-datenrückgabe--export-und--löschung-exit) +17. [Audit- und Prüfungsrechte](#17-audit--und-prüfungsrechte) +18. [Zugriffsrechte, Weisungsrecht und Datenzugang](#18-zugriffsrechte-weisungsrecht-und-datenzugang) +19. [Haftung und Haftungsbeschränkung](#19-haftung-und-haftungsbeschränkung) +20. [Aussetzung des Dienstes](#20-aussetzung-des-dienstes) +21. [Vertragsänderungen](#21-vertragsänderungen) +22. [Übertragung des Vertrags](#22-übertragung-des-vertrags) +23. [Anwendbares Recht und Gerichtsstand](#23-anwendbares-recht-und-gerichtsstand) +24. [Schlussbestimmungen](#24-schlussbestimmungen) + +**Anhänge:** +- [Anhang A: Subunternehmer- und LLM-Anbieter-Liste](#anhang-a-subunternehmer--und-llm-anbieter-liste) +- [Anhang B: Service Level Agreement (SLA)](#anhang-b-service-level-agreement-sla) +- [Anhang C: Technisch-organisatorische Massnahmen (TOMs)](#anhang-c-technisch-organisatorische-massnahmen-toms) + +--- + +## § 1 Vertragsparteien und Geltungsbereich + +### 1.1 Anbieter + +Diese Allgemeinen Geschäftsbedingungen gelten für Dienstleistungen der + +**PowerOn AG** +Birmensdorferstrasse 94 +8003 Zürich, Schweiz +CHE-491.960.195 +E-Mail: p.motsch@poweron.swiss + +(nachfolgend **«PowerOn»** oder **«Anbieter»**) + +### 1.2 Kunde + +Kunde im Sinne dieser AGB ist jedes Unternehmen, jede juristische Person des öffentlichen oder privaten Rechts sowie jede sonstige rechtsfähige Organisation, die einen Vertrag über die Nutzung der PORTA-Plattform mit PowerOn abschliesst (nachfolgend **«Kunde»** oder **«Institution»**). + +Diese AGB richten sich ausschliesslich an Unternehmen (B2B). Verbraucher im Sinne des Konsumentenschutzes sind nicht Zielgruppe dieser Leistungen. + +### 1.3 Geltungsbereich + +Diese AGB gelten für alle von PowerOn erbrachten Leistungen im Zusammenhang mit der PORTA Enterprise KI-Plattform, soweit nicht im individuellen Dienstleistungsvertrag (nachfolgend **«Vertrag»**) oder in gesondert vereinbarten Service Level Agreements (SLA) abweichende Regelungen getroffen wurden. + +Abweichende AGB des Kunden gelten nicht, es sei denn, PowerOn stimmt ihrer Geltung ausdrücklich schriftlich zu. + +### 1.4 Vorrang + +Im Fall von Widersprüchen gilt folgende Rangfolge: +1. Individueller Dienstleistungsvertrag (inkl. Einzelvereinbarungen) +2. Auftragsverarbeitungsvertrag (AVV) +3. Service Level Agreement (SLA) +4. Diese Allgemeinen Geschäftsbedingungen +5. Anhänge A, B, C + +--- + +## § 2 Leistungsbeschreibung + +### 2.1 PORTA Enterprise KI-Plattform + +PowerOn stellt dem Kunden die **PORTA Enterprise KI-Plattform** als Software-as-a-Service (SaaS) zur Verfügung. PORTA ist eine KI-Orchestrierungsplattform, die: + +- **KI-Agents** bereitstellt und verwaltet, welche repetitive, datengetriebene Aufgaben automatisieren; +- **Multi-LLM-Integration** ermöglicht (Anbindung verschiedener Sprachmodelle gemäss Anhang A); +- **Workflow-Automatisierung** für unternehmensinterne Prozesse umsetzt; +- **Datenschnittstellen** zu bestehenden Kundensystemen (APIs, Datenquellen) bereitstellt; +- **Sicherheits- und Compliance-Funktionen** für regulierte Branchen (Finanz, Gesundheit, Industrie) integriert. + +### 2.2 Leistungsumfang + +Der konkrete Leistungsumfang (verfügbare Module, Nutzeranzahl, Datenvolumen, zugelassene LLM-Anbieter) wird im individuellen Dienstleistungsvertrag definiert. Änderungen des Leistungsumfangs bedürfen der schriftlichen Vereinbarung. + +### 2.3 Mitwirkungspflichten des Kunden + +Der Kunde stellt sicher, dass: + +- technisch notwendige Systemvoraussetzungen (Netzwerk, Browser, APIs) auf seiner Seite erfüllt sind; +- benannte Ansprechpersonen (technisch und fachlich) erreichbar sind; +- Zugangsdaten vertraulich behandelt und nicht an unbefugte Dritte weitergegeben werden; +- Nutzungsverbote (§ 5.3) eingehalten werden. + +### 2.4 Änderungen an der Plattform + +PowerOn ist berechtigt, die Plattform laufend weiterzuentwickeln, sofern dies die vereinbarten Kernfunktionen nicht wesentlich beeinträchtigt. Die Ausserbetriebnahme wesentlicher Funktionen oder eine wesentliche Reduktion der Service Levels wird dem Kunden mindestens **12 Monate** im Voraus angekündigt, soweit dies nicht durch zwingende gesetzliche oder regulatorische Anforderungen anders geboten ist. + +--- + +## § 3 Vertragsschluss und Laufzeit + +### 3.1 Vertragsschluss + +Der Vertrag kommt durch schriftliche Unterzeichnung des Dienstleistungsvertrags oder schriftliche Auftragsbestätigung durch beide Parteien zustande. Eine Nutzung der Plattform vor formalem Vertragsschluss erfolgt ausschliesslich auf der Grundlage einer separaten Pilotvereinbarung. + +### 3.2 Laufzeit + +Die Mindestlaufzeit beträgt **12 Monate**, soweit im Dienstleistungsvertrag nichts anderes vereinbart ist. Nach Ablauf der Mindestlaufzeit verlängert sich der Vertrag automatisch um jeweils weitere **12 Monate**, sofern er nicht rechtzeitig gekündigt wird. + +### 3.3 Ordentliche Kündigung + +Beide Parteien können den Vertrag mit einer Frist von **3 Monaten** zum Ende eines Vertragsmonats schriftlich kündigen, frühestens jedoch zum Ende der vereinbarten Mindestlaufzeit. + +### 3.4 Ausserordentliche Kündigung + +Beide Parteien können den Vertrag aus wichtigem Grund fristlos kündigen. Ein wichtiger Grund liegt insbesondere vor, wenn: + +- die andere Partei wesentliche Vertragspflichten trotz schriftlicher Abmahnung nicht binnen 30 Tagen erfüllt; +- über das Vermögen einer Partei ein Konkurs- oder Nachlassverfahren eröffnet wird; +- eine Rechtsentwicklung eine Vertragserfüllung dauerhaft unmöglich oder unzumutbar macht. + +Im Fall einer ausserordentlichen Kündigung durch den Kunden aufgrund einer Rechtsentwicklung, auf die PowerOn keinen Einfluss hat, verhandeln die Parteien nach Treu und Glauben über eine Vertragsanpassung. Gelingt dies nicht binnen 60 Tagen, kann der Kunde ohne Haftung kündigen. + +### 3.5 Aktivierung zusätzlicher Dienste + +Die Aktivierung einzelner Zusatzdienste oder Optionen löst keine neue Mindestlaufzeit aus, sofern dies nicht ausdrücklich schriftlich vereinbart ist. PowerOn informiert den Kunden vor Aktivierung eines Zusatzdienstes klar darüber, ob und unter welchen Bedingungen eine neue oder verlängerte Laufzeit entsteht. + +--- + +## § 4 Vergütung und Zahlungsbedingungen + +### 4.1 Preisgestaltung + +Die vereinbarten Entgelte ergeben sich aus dem individuellen Dienstleistungsvertrag. Grundlage bilden in der Regel: + +- ein monatliches oder jährliches Abonnemententgelt (Subscription); +- nutzungsabhängige Komponenten (API-Calls, Datenvolumen, LLM-Token-Nutzung). + +### 4.2 Rechnungsstellung und Fälligkeit + +Rechnungen sind innert **30 Tagen** ab Rechnungsdatum zahlbar. Bei Verzug ist PowerOn berechtigt, den gesetzlichen Verzugszins zu berechnen. Bei Zahlungsverzug von mehr als 60 Tagen kann PowerOn nach schriftlicher Vorankündigung mit angemessener Frist (mindestens 14 Tage) den Zugang zur Plattform beschränken. **Die Kundendaten werden dabei zu keinem Zeitpunkt zurückbehalten** (vgl. § 18.4). + +### 4.3 Preisanpassungen + +Preisanpassungen werden dem Kunden mindestens **3 Monate** vor Inkrafttreten schriftlich angekündigt. Stimmt der Kunde einer wesentlichen Preiserhöhung (mehr als 10% p.a.) nicht zu, ist er berechtigt, den Vertrag mit einmonatiger Frist auf den Zeitpunkt des Inkrafttretens der Preisanpassung ausserordentlich zu kündigen. + +### 4.4 Steuern + +Alle Preise verstehen sich zuzüglich der gesetzlichen Mehrwertsteuer (MWST) zum jeweils gültigen Satz. + +--- + +## § 5 Nutzungsrechte und geistiges Eigentum + +### 5.1 Nutzungsrecht + +PowerOn räumt dem Kunden für die Dauer des Vertrags ein nicht-exklusives, nicht übertragbares, auf die Nutzung im eigenen Unternehmen beschränktes Recht zur Nutzung der PORTA-Plattform ein. + +### 5.2 Eigentum an Kundendaten + +**Alle vom Kunden in die Plattform eingespeisten Daten («Inhaltsdaten») verbleiben im Eigentum des Kunden.** PowerOn erwirbt durch die Verarbeitung der Kundendaten keinerlei Eigentums- oder sonstige Rechte daran. + +### 5.3 Nutzungsbeschränkungen + +Dem Kunden ist es untersagt: + +- die Plattform für rechtswidrige Zwecke oder in einer Weise zu nutzen, die Rechte Dritter verletzt; +- die Plattform weiterzuverkaufen, zu vermieten oder Dritten ausserhalb des eigenen Unternehmens zur Nutzung zu überlassen, ohne vorherige schriftliche Zustimmung von PowerOn; +- Reverse Engineering, Dekompilierung oder Disassemblierung der Plattform vorzunehmen, soweit dies nicht durch zwingendes Recht erlaubt ist; +- Sicherheits- oder Zugriffsbeschränkungen zu umgehen. + +### 5.4 Plattform-IP + +Die Plattform PORTA sowie alle zugehörigen Entwicklungen, Algorithmen, Modelle, Interfaces und Dokumentationen sind geistiges Eigentum von PowerOn und/oder ihrer Lizenzgeber. Diese AGB räumen dem Kunden keinerlei Eigentumsrechte daran ein. + +### 5.5 Feedback und Verbesserungen + +Wenn der Kunde PowerOn Rückmeldungen, Anregungen oder Verbesserungsvorschläge zur Plattform übermittelt, darf PowerOn diese zur Weiterentwicklung der Plattform nutzen, sofern dabei keine Kundendaten oder vertraulichen Informationen des Kunden offenbart werden. + +### 5.6 Keine Nutzung für eigene Zwecke + +PowerOn nutzt Inhaltsdaten des Kunden **nicht** für eigene Zwecke (insbesondere nicht für das Training von KI-Modellen, für Werbezwecke oder für die Verbesserung allgemeiner Plattformfunktionen), es sei denn, dies ist im Einzelfall ausdrücklich schriftlich vereinbart. Soweit PowerOn aggregierte, vollständig anonymisierte Nutzungsstatistiken zur Plattformoptimierung heranzieht, gelten für diese dieselben Sicherheits- und Vertraulichkeitsmassnahmen wie für Inhaltsdaten. + +--- + +## § 6 Datenschutz und Auftragsverarbeitung + +### 6.1 Anwendbares Datenschutzrecht + +PowerOn verarbeitet personenbezogene Daten im Auftrag des Kunden in Übereinstimmung mit: + +- dem Schweizerischen Bundesgesetz über den Datenschutz (DSG, SR 235.1) in seiner jeweils geltenden Fassung; +- der Datenschutz-Grundverordnung (DSGVO, EU 2016/679), soweit auf die betreffenden Daten anwendbar; +- sektorspezifischem Recht (insbesondere FINMA-Rundschreiben 2018/3 und 2023/1 für regulierte Finanzinstitute). + +### 6.2 Auftragsverarbeitungsvertrag (AVV) + +PowerOn schliesst mit jedem Kunden, der personenbezogene Daten in die Plattform einbringt, einen Auftragsverarbeitungsvertrag (AVV) gemäss Art. 28 DSGVO bzw. Art. 9 DSG ab. Der AVV ist Bestandteil des Vertragsverhältnisses und kann auf Anfrage als separates Dokument bereitgestellt werden. + +Der AVV regelt mindestens: + +- Gegenstand, Art, Zweck und Dauer der Datenverarbeitung; +- Kategorien betroffener Personen und Datenkategorien; +- Pflichten und Rechte des Kunden als Verantwortlichem; +- technisch-organisatorische Massnahmen (TOMs, Anhang C); +- Regelungen zu Unterauftragsverarbeitern (§ 12); +- Informationspflichten und Unterstützung bei der Erfüllung von Betroffenenrechten. + +### 6.3 Geltungsbereich des AVV + +Die AVV-Bestimmungen gelten nicht nur für personenbezogene Daten natürlicher Personen, sondern sinngemäss für **alle Inhaltsdaten des Kunden**, insbesondere für Daten, die dem Bankkundengeheimnis oder einem sonstigen Berufsgeheimnis unterliegen. + +### 6.4 Schweizer DSG-Konformität + +Soweit der AVV oder ergänzende Datenschutzbestimmungen auf die DSGVO verweisen, gelten diese Verweise sinngemäss auch für das Schweizer DSG. Die strikteren Anforderungen des jeweils anwendbaren Rechts gehen vor. + +### 6.5 Datenschutz-Folgenabschätzung + +PowerOn unterstützt den Kunden auf Anfrage bei der Durchführung einer Datenschutz-Folgenabschätzung (DSFA) gemäss Art. 35 DSGVO / Art. 22 DSG, soweit die Verarbeitung durch die Plattform betroffen ist. + +--- + +## § 7 Datenspeicherung und -lokalisierung + +### 7.1 Speicherstandort Schweiz + +**Inhaltsdaten des Kunden werden ausschliesslich auf Infrastruktur gespeichert, die in der Schweiz betrieben wird.** Der Speicherstandort kann nicht einseitig von PowerOn geändert werden, ohne den Kunden mindestens 3 Monate im Voraus schriftlich zu informieren und ihm ein ausserordentliches Kündigungsrecht einzuräumen. + +### 7.2 LLM-Verarbeitung — Transparenzhinweis + +**Wichtiger Hinweis:** Wenn Inhaltsdaten zur Verarbeitung durch externe LLM-Anbieter (Anhang A) an deren APIs übermittelt werden, verlassen diese Daten temporär die Schweiz und werden auf der Infrastruktur des jeweiligen LLM-Anbieters verarbeitet. Dies betrifft insbesondere Prompts, Anfragen und die darin enthaltenen Nutzerdaten. + +PowerOn stellt sicher, dass: + +- für jeden eingesetzten LLM-Anbieter ausserhalb der Schweiz und des EWR die erforderlichen Standardvertragsklauseln (SCC) gemäss EU-Kommission oder anerkannte Binding Corporate Rules (BCR) vorliegen; +- die eingesetzten LLM-Anbieter unternehmensbezogene API-Abkommen («Zero Data Retention»-Policies oder vergleichbare Vereinbarungen) mit PowerOn unterhalten, wonach übermittelte Daten nicht für das Training eigener Modelle verwendet werden; +- Transfer Impact Assessments (TIA) für relevante Drittlandtransfers dokumentiert und dem Kunden auf Anfrage zugänglich gemacht werden; +- der Kunde die Liste der zugelassenen LLM-Anbieter (Anhang A) einsehen und für seinen Tenant bestimmte Anbieter ausschliessen kann. + +### 7.3 Kundenwahl des LLM-Anbieters + +Im Dienstleistungsvertrag wird festgehalten, welche LLM-Anbieter für den jeweiligen Kunden-Tenant zugelassen sind. Kunden mit regulatorischen Anforderungen (z.B. FINMA-beaufsichtigte Institute), die eine ausschliessliche Verarbeitung innerhalb der Schweiz oder des EWR verlangen, wählen ausschliesslich Anbieter aus der Liste der zugelassenen Schweizer/EU-LLMs. + +### 7.4 Zulässige Ausnahmen + +Eine Datenverarbeitung ausserhalb des vereinbarten Standorts ist nur zulässig in folgenden klar definierten Ausnahmefällen: + +- auf ausdrückliche, schriftliche Genehmigung des Kunden im Einzelfall (z.B. für Support-Zwecke); +- aufgrund einer rechtskräftigen und vollstreckbaren behördlichen Anordnung nach Schweizer Recht; +- bei technischen Notfallmassnahmen zum Schutz der Datenverfügbarkeit, sofern der Kunde unverzüglich informiert wird. + +--- + +## § 8 Informationssicherheit + +### 8.1 Sicherheitsstandard + +PowerOn betreibt ein **Informationssicherheits-Management-System (ISMS)** materiell in Anlehnung an ISO/IEC 27001 und strebt eine Zertifizierung nach diesem Standard an. Die eingesetzten Sicherheitsmassnahmen entsprechen dem Stand der Technik und den Anforderungen schweizerischer Finanzinstitute für gleichartige Dienstleistungen. + +### 8.2 Technisch-organisatorische Massnahmen (TOMs) + +Die technisch-organisatorischen Massnahmen sind in **Anhang C** detailliert beschrieben. Sie umfassen mindestens: + +- **Zugangskontrolle:** Multi-Faktor-Authentifizierung (MFA), rollenbasiertes Zugriffsmodell (RBAC), Least-Privilege-Prinzip; +- **Zugriffskontrolle:** Need-to-Know-Prinzip, Identity and Access Management (IAM), Privileged Access Management (PAM); +- **Weitergabekontrolle:** Verschlüsselung bei Übertragung (TLS 1.3 oder höher); +- **Eingabekontrolle:** Vollständige Audit-Trails aller Datenzugriffe; +- **Verfügbarkeitskontrolle:** Redundante Systeme, regelmässige Backups, getestetes DR-Konzept; +- **Trennungskontrolle:** Logische und physische Mandantentrennung. + +### 8.3 Mitarbeiter und Screening + +PowerOn stellt sicher, dass: + +- alle Mitarbeitenden und eingesetzten Hilfspersonen, die Zugang zu Inhaltsdaten im Klartext haben können, sorgfältig ausgewählt, überprüft (inkl. Hintergrundüberprüfung, soweit gesetzlich zulässig) und geschult werden; +- der Zugriff auf personenbezogene Daten und Berufsgeheimnisdaten protokolliert und stichprobenweise überwacht wird; +- Mitarbeitende schriftlich zur Vertraulichkeit verpflichtet sind (zeitlich unbefristet, auch nach Beendigung des Arbeitsverhältnisses). + +### 8.4 Schwachstellenmanagement + +PowerOn führt ein systematisches Schwachstellenmanagement durch, das regelmässiges Vulnerability Scanning, mindestens jährliche Penetrationstests durch unabhängige Dritte sowie dokumentierte Massnahmenpläne umfasst. Die vollständigen Prüfberichte (nicht nur Zusammenfassungen) werden dem Kunden auf Anfrage zugänglich gemacht. + +### 8.5 Patch-Management + +Kritische Sicherheitsupdates werden innert **48 Stunden**, sonstige sicherheitsrelevante Patches innert **30 Tagen** nach Veröffentlichung eingespielt, sofern keine abweichenden Maintenance-Windows vereinbart sind. + +### 8.6 Anpassung bei neuen Bedrohungen + +PowerOn aktualisiert die Sicherheitsmassnahmen fortlaufend auf Basis neuer oder geänderter Bedrohungslagen und informiert den Kunden über wesentliche Anpassungen. + +--- + +## § 9 Verschlüsselung und Schlüsselmanagement + +### 9.1 Verschlüsselung im Ruhezustand («at rest») + +Alle Inhaltsdaten werden im Ruhezustand mit **AES-256** oder einem gleichwertigen anerkannten Standard verschlüsselt. + +### 9.2 Verschlüsselung bei der Übertragung («in transit») + +Alle Datenübertragungen zwischen Client und Plattform sowie zwischen Systemkomponenten erfolgen verschlüsselt über **TLS 1.3** oder höher. Ältere TLS-Versionen werden nicht akzeptiert. + +### 9.3 Schlüsselmanagement-Optionen + +PowerOn bietet dem Kunden folgende Schlüsselverwaltungsoptionen an, die im Dienstleistungsvertrag festzulegen sind: + +**Option A — Anbieter-verwaltete Schlüssel (Standard):** +PowerOn verwaltet die Verschlüsselungsschlüssel in einem sicheren Key Store nach anerkannten Standards (NIST SP 800-57). Schlüssel werden kundenspezifisch erzeugt, aufbewahrt und rotiert. + +**Option B — Kundenkontrollierte Schlüsselverwaltung (BYOK):** +Der Entschlüsselungsschlüssel verbleibt im Key Store von PowerOn, die Schlüsselverwaltung (Generieren, Ersetzen, Widerrufen) übernimmt der Kunde remote. PowerOn erhält über einen Break-Glass-Account Notfallzugang nur im vertraglich definierten Ausnahmefall. + +**Option C — Extern gehosteter Key Store:** +Der Kunde betreibt den Key Store in seiner eigenen Infrastruktur oder einem selbst gewählten Key-Management-System (z.B. Azure Key Vault, AWS KMS, Thales). PowerOn bindet diesen technisch an. + +### 9.4 Schlüssellebenszyklus + +PowerOn hat Anforderungen für die sichere Erzeugung, Speicherung, Archivierung, Abfrage, Verteilung, Sperrung und Löschung von Schlüsseln festgelegt und dokumentiert (Key Management Policy, auf Anfrage einsehbar). + +### 9.5 Keine gemeinsamen Schlüssel + +Der Einsatz von Generalschlüsseln für mehrere Kunden gleichzeitig ist nicht zulässig. Jeder Kunde erhält isolierte Schlüsselbereiche. + +--- + +## § 10 Verfügbarkeit und Service Level Agreement + +### 10.1 Zielverfügbarkeit + +PowerOn stellt die PORTA-Plattform mit einer Zielverfügbarkeit von **99,5% pro Kalendermonat** (ausserhalb vereinbarter Wartungsfenster) zur Verfügung. Die genauen Messverfahren und Konsequenzen bei Unterschreitung sind in **Anhang B** geregelt. + +### 10.2 Wartungsfenster + +Regelmässige Wartungsarbeiten werden dem Kunden mindestens **5 Werktage** im Voraus angekündigt. Notfall-Wartungen werden so schnell wie möglich kommuniziert. + +### 10.3 Frozen Zones + +Auf Anfrage des Kunden richtet PowerOn «Frozen Zones» ein — definierte Zeiträume, in denen keine Updates oder Änderungen an der Plattform vorgenommen werden (z.B. Jahresabschluss, Prüfungsperioden). Die Modalitäten werden im Dienstleistungsvertrag geregelt. + +### 10.4 RTO und RPO + +Im Falle eines schwerwiegenden Ausfalls gelten folgende Zielwerte: + +- **Recovery Time Objective (RTO):** Maximal **4 Stunden** bis zur Wiederherstellung des Betriebs; +- **Recovery Point Objective (RPO):** Maximal **1 Stunde** Datenverlust. + +Abweichende RTO/RPO-Anforderungen des Kunden werden im Dienstleistungsvertrag festgehalten. + +### 10.5 Monitoring und Statusseite + +PowerOn betreibt ein kontinuierliches Monitoring aller systemkritischen Komponenten. Der aktuelle Systemstatus wird über eine öffentliche oder kundenspezifische Statusseite kommuniziert. + +--- + +## § 11 Business Continuity und Notfallplanung + +### 11.1 Business Continuity Plan (BCP) und Disaster Recovery Plan (DRP) + +PowerOn unterhält einen schriftlichen **Business Continuity Plan (BCP)** und einen **Disaster Recovery Plan (DRP)**, die eine kontinuierliche Leistungserbringung und -wiederherstellung im Katastrophenfall angemessen gewährleisten. Beide Pläne werden mindestens einmal jährlich überprüft und getestet. Testprotokolle werden aufbewahrt und dem Kunden auf Anfrage zugänglich gemacht. + +### 11.2 Backup-Rechenzentrum + +PowerOn betreibt ein geografisch vom primären Rechenzentrum getrenntes Backup-Rechenzentrum innerhalb der Schweiz, das im Notfall die Weiterführung des Betriebs sicherstellt. + +### 11.3 Weiterführungspflicht bei gescheitertem Exit + +Sollte eine Rückführung der an PowerOn ausgelagerten Funktionen aus irgendeinem Grund scheitern, verpflichtet sich PowerOn, seine Leistungen für einen Zeitraum von mindestens **6 Monaten** zu den bisherigen Bedingungen weiterzuerbringen, um dem Kunden einen zweiten Rückführungsversuch zu ermöglichen. Diese Verpflichtung gilt unabhängig vom Kündigungsgrund. + +### 11.4 Kapazitätsplanung + +PowerOn betreibt ein etabliertes Verfahren zur Planung, Überwachung und Steuerung von Personal- und IT-Ressourcenkapazitäten, um eine kontinuierliche Leistungserbringung sicherzustellen. + +--- + +## § 12 Subunternehmer und LLM-Anbieter + +### 12.1 Subunternehmer-Liste + +Die aktuell eingesetzten Subunternehmer und LLM-Anbieter sind in **Anhang A** aufgeführt. Die Liste enthält für jeden Subunternehmer: Name und Firmensitz, Funktion/Rolle, eingesetzte Leistungen, Land der Tätigkeit. + +### 12.2 Widerspruchsrecht des Kunden + +PowerOn informiert den Kunden schriftlich über die beabsichtigte Hinzunahme oder den Ersatz eines wesentlichen Subunternehmers mindestens **30 Tage** im Voraus. Der Kunde hat das Recht, innerhalb von **14 Tagen** nach Bekanntgabe aus sachlichem Grund schriftlich Widerspruch einzulegen. Im Falle eines begründeten Widerspruchs, den PowerOn nicht ausräumen kann, ist der Kunde berechtigt, den Vertrag mit einer Frist von 3 Monaten ausserordentlich zu kündigen. + +### 12.3 Weitergabe von Pflichten + +PowerOn verpflichtet alle Subunternehmer vertraglich zu denselben Sicherheits-, Datenschutz-, Vertraulichkeits- und Compliance-Pflichten, die PowerOn gegenüber dem Kunden eingegangen ist. PowerOn haftet dem Kunden gegenüber für die ordnungsgemässe Leistungserfüllung durch Subunternehmer wie für eigenes Handeln. + +### 12.4 LLM-Anbieter als Unterauftragsverarbeiter + +LLM-Anbieter, an die Inhaltsdaten zur Modellverarbeitung übermittelt werden, sind als Unterauftragsverarbeiter im AVV aufgeführt. PowerOn schliesst mit diesen geeignete Datenschutzvereinbarungen (inkl. Standardvertragsklauseln, wo erforderlich) ab. + +### 12.5 Sanktionscheck + +PowerOn überprüft alle Subunternehmer vor deren Einsatz auf Sanktionslisten und wiederholt diese Prüfung regelmässig. + +--- + +## § 13 Vertraulichkeit und Berufsgeheimnis + +### 13.1 Allgemeine Vertraulichkeitspflicht + +Beide Parteien behandeln alle im Rahmen des Vertragsverhältnisses erhaltenen Informationen der anderen Partei vertraulich und geben diese nicht an Dritte weiter, es sei denn, dies ist für die Vertragserfüllung erforderlich, von der anderen Partei schriftlich genehmigt oder durch eine rechtskräftige Anordnung zwingend geboten. + +### 13.2 Berufsgeheimnis + +Soweit der Kunde einem gesetzlichen Berufsgeheimnis unterliegt (insbesondere Bankgeheimnis nach Art. 47 BankG, medizinisches Berufsgeheimnis nach Art. 321 StGB), verpflichtet sich PowerOn: + +- alle derart geschützten Inhaltsdaten («Berufsgeheimnisdaten») mit dem gleichen oder einem höheren Schutzniveau zu behandeln wie personenbezogene Daten; +- die Geheimhaltungspflicht auf alle Mitarbeitenden und eingesetzten Hilfspersonen zu übertragen, die Zugang zu Berufsgeheimnisdaten haben können; +- sicherzustellen, dass die Geheimhaltungsverpflichtung zeitlich unbefristet gilt; +- die Geheimhaltungspflicht auch nach Beendigung des Vertragsverhältnisses vollumfänglich aufrechtzuerhalten. + +### 13.3 Ausländische Behördenanfragen + +Wird PowerOn mit Auskunfts- oder Zugriffsanordnungen ausländischer Behörden in Bezug auf Berufsgeheimnisdaten konfrontiert, verpflichtet sich PowerOn: + +- alle verfügbaren Rechtsmittel auszuschöpfen, um solche Anordnungen anzufechten, sofern sie dem Schweizer Recht widersprechen oder das Berufsgeheimnis verletzen; +- den Kunden unverzüglich und — soweit gesetzlich zulässig — vor jeder Offenlegung zu informieren und dessen Weisungen einzuholen; +- über die Anzahl solcher Anfragen in einem jährlichen Transparenzbericht zu berichten, soweit dies nicht gesetzlich untersagt ist. + +--- + +## § 14 Meldepflichten + +### 14.1 Meldepflicht bei Cyberangriffen (24-Stunden-Frist) + +PowerOn ist verpflichtet, dem Kunden unverzüglich — und in jedem Fall **innerhalb von 24 Stunden** nach erstmaliger Feststellung — folgende Ereignisse zu melden: + +- erfolgreiche oder teilweise erfolgreiche Cyberangriffe, die kritische Daten oder kritische Prozesse des Kunden betreffen können; +- wesentliche Verletzungen der Vertraulichkeit, Integrität oder Verfügbarkeit kritischer Daten. + +Die 24-Stunden-Frist dient insbesondere dazu, dem Kunden die Einhaltung seiner eigenen Meldepflicht gegenüber der FINMA zu ermöglichen. + +### 14.2 Meldepflicht bei sonstigen Vorfällen + +PowerOn meldet dem Kunden unverzüglich: + +- sonstige Vorkommnisse, die sich auf kritische Daten oder Prozesse des Kunden auswirken können; +- wesentliche nachteilige Entwicklungen, die die Dienstleistungserbringung erheblich beeinträchtigen können; +- Verstösse gegen das Berufsgeheimnis, auch wenn keine personenbezogenen Daten betroffen sind. + +### 14.3 Datenpannenmeldung + +Bei einer Verletzung des Schutzes personenbezogener Daten informiert PowerOn den Kunden unverzüglich, spätestens aber **innerhalb von 24 Stunden** nach Bekanntwerden, um diesem die fristgerechte Erfüllung seiner Meldepflichten gegenüber Aufsichtsbehörden zu ermöglichen. + +### 14.4 Meldeinhalt und Unterstützung + +Jede Meldung enthält soweit bekannt: Beschreibung der Art des Vorfalls, betroffene Datenkategorien und -mengen, wahrscheinliche Folgen sowie ergriffene und geplante Massnahmen. PowerOn unterstützt den Kunden aktiv bei der Behebung und bei der Verhinderung einer Wiederholung. + +--- + +## § 15 Legal Hold und Datenaufbewahrung + +### 15.1 Legal Hold + +PowerOn stellt dem Kunden die Möglichkeit zur Verfügung, bestimmte Daten für rechtliche Zwecke (interne Ermittlungen, staatliche Ermittlungen, Rechtsstreitigkeiten) zu sperren («Legal Hold»), sodass diese nicht automatisch gelöscht oder verändert werden. Gesperrte Daten können mit entsprechenden Berechtigungskontrollen forensisch sicher in einem branchenüblichen Format extrahiert werden. + +### 15.2 Konfigurierbare Aufbewahrungsfristen + +Der Kunde kann für verschiedene Datenkategorien individuelle Aufbewahrungsfristen konfigurieren. Nach Ablauf der definierten Frist werden die Daten automatisch gelöscht oder auf Kundenwunsch anonymisiert, sofern kein Legal Hold aktiv ist. + +### 15.3 Dauerhafte Aufbewahrung + +Der Kunde kann Ausnahmen von automatischen Löschroutinen definieren (z.B. bestimmte Dokumentenklassen, die dauerhaft aufbewahrt werden müssen). + +--- + +## § 16 Datenrückgabe, -export und -löschung (Exit) + +### 16.1 Datenexport jederzeit + +PowerOn stellt sicher, dass der Kunde **jederzeit** und ohne zusätzliche Kosten alle Inhaltsdaten (inkl. Zugriffs-, Protokoll- und Nutzungsdaten) in einem gängigen, maschinenlesbaren Standardformat (z.B. JSON, CSV, XML) exportieren kann. Dieser Exportanspruch besteht unabhängig von allfälligen Zahlungsstreitigkeiten. + +### 16.2 Datenrückgabe bei Vertragsende + +Nach Beendigung des Vertrags stellt PowerOn dem Kunden für einen Zeitraum von **90 Tagen** nach Vertragsende eine schreibgeschützte Umgebung zum vollständigen Datenexport zur Verfügung. Der Kunde wird rechtzeitig vor Ablauf dieser Frist erinnert. + +### 16.3 Löschung nach Vertragsende + +Nach erfolgreichem Export und Ablauf der 90-tägigen Exportfrist löscht PowerOn alle Inhaltsdaten des Kunden unwiderruflich und sicher, soweit gesetzliche Aufbewahrungspflichten nicht entgegenstehen. PowerOn stellt auf Verlangen eine schriftliche Löschbestätigung aus. Die Löschpflicht erstreckt sich auf alle Systeme, Backups und Subunternehmer. + +### 16.4 Aktive Unterstützung bei Repatriierung + +PowerOn unterstützt den Kunden aktiv bei der Rückführung (Repatriierung) von Funktionen und Daten zu einem anderen Anbieter oder zum Kunden selbst. Bei einer Repatriierung soll kein Datenverlust entstehen, der den weiteren Betrieb des Kunden beeinträchtigt. + +--- + +## § 17 Audit- und Prüfungsrechte + +### 17.1 Allgemeines Prüfungsrecht + +PowerOn räumt dem Kunden sowie von ihm beauftragten, unabhängigen Dritten (externe Prüfungsgesellschaft, Revisoren) das Recht ein, die für die Leistungserbringung relevanten Systeme, Prozesse und Dokumentationen jederzeit und uneingeschränkt zu prüfen — auch vor Ort. Die Prüfung erstreckt sich auf den gesamten ausgelagerten Bereich und ist nicht auf reine Sicherheitsprüfungen beschränkt. + +### 17.2 FINMA und Aufsichtsbehörden + +Für FINMA-regulierte Kunden gilt ergänzend: Die externe Revisionsstelle des Kunden sowie die FINMA können ihre Prüfungs- und Informationsrechte **unmittelbar und direkt** gegenüber PowerOn geltend machen, ohne Umweg über den Kunden (Drittbegünstigungsrecht). PowerOn stellt sicher, dass keine lokalen gesetzlichen Bestimmungen die Ausübung dieser Rechte verhindern. Sollte dies ausnahmsweise nicht vollständig gewährleistet werden können, informiert PowerOn den Kunden unverzüglich. + +### 17.3 Vollständige Audit-Berichte + +PowerOn stellt dem Kunden jährlich und ohne gesonderte Kosten die vollständigen Audit-Berichte zu — insbesondere SOC-2-Berichte, Pentest-Berichte und ISO-27001-Auditberichte (nicht nur Zertifizierungen oder Zusammenfassungen). + +### 17.4 Durchführung + +Audits werden mindestens 5 Werktage im Voraus angekündigt (ausser bei begründetem Notfallaudit). Die Kosten trägt der Kunde, ausser bei festgestellten wesentlichen Verstössen durch PowerOn. + +--- + +## § 18 Zugriffsrechte, Weisungsrecht und Datenzugang + +### 18.1 Weisungsrecht des Kunden + +Der Kunde hat gegenüber PowerOn im Rahmen der Auftragsverarbeitung ein Weisungsrecht. Weisungen können aus dem Vertragsinhalt, der Kundenkonfiguration oder Konsoleneinstellungen resultieren. Weisungen, die nicht durch den Vertragsinhalt gedeckt sind, bedürfen der schriftlichen Bestätigung durch PowerOn. + +### 18.2 Benutzerverwaltung + +Der Kunde kann Benutzeridentitäten für seinen Cloud-Tenant selbständig verwalten (erstellen, ändern, sperren, löschen) sowie bei Bedarf Identity Federation (SAML 2.0, OIDC) mit seinem bestehenden Verzeichnisdienst einrichten. + +### 18.3 Mitarbeiterzugang zu Kundendaten + +Mitarbeitende von PowerOn greifen auf Inhaltsdaten des Kunden im Klartext **ausschliesslich** zu, wenn: + +- der Kunde dies für einen konkreten Fall (z.B. Support-Anfrage) ausdrücklich genehmigt hat; +- dies zur Erfüllung einer rechtskräftigen behördlichen Anordnung zwingend erforderlich ist; +- ein schwerwiegender technischer Ausfall dies temporär notwendig macht (mit unverzüglicher nachträglicher Information des Kunden). + +Alle Datenzugriffe durch PowerOn-Mitarbeitende werden lückenlos protokolliert. + +### 18.4 Datenzugang trotz Zahlungsstreitigkeiten + +**Das Zurückhalten von Kundendaten zur Durchsetzung von Zahlungsansprüchen ist ausdrücklich unzulässig.** Bei Zahlungsverzug ist PowerOn allenfalls berechtigt, neue Verarbeitungsvorgänge einzuschränken, nicht aber den Zugang zu bestehenden Daten zu sperren. + +### 18.5 Insolvenz des Anbieters + +Im Falle einer Insolvenz von PowerOn soll sichergestellt sein, dass der Kunde weiterhin Zugang zu seinen Inhaltsdaten hat. PowerOn regelt dies durch entsprechende vertragliche Vorsorge (z.B. Software-Escrow, vertraglich gesicherte Direktzugriffsrechte). Inhaltsdaten sind klar als Eigentum des Kunden gekennzeichnet und gesondert von PowerOn-eigenen Daten gehalten. + +--- + +## § 19 Haftung und Haftungsbeschränkung + +### 19.1 Grundsatz + +PowerOn haftet dem Kunden für Schäden, die durch eine Verletzung vertraglicher oder gesetzlicher Pflichten entstehen, nach den nachfolgenden Massgaben. + +### 19.2 Haftungsobergrenze + +Die Gesamthaftung von PowerOn innerhalb eines Vertragsjahres ist auf die **Höhe der vom Kunden im betreffenden Vertragsjahr tatsächlich bezahlten Entgelte (Jahreshonorar)** begrenzt. + +### 19.3 Erhöhte Haftung bei Vertraulichkeits- und Sicherheitsverletzungen + +Abweichend von § 19.2 haftet PowerOn bei Verletzungen von Vertraulichkeitspflichten (§ 13), bei Verletzungen des Berufsgeheimnisses oder bei Datenschutzverletzungen bis zur Höhe des **Zweifachen des Jahreshonorars**. + +### 19.4 Keine Haftungsbeschränkung bei grobem Verschulden + +Die Haftungsbeschränkungen gemäss §§ 19.2 und 19.3 gelten **nicht** für Schäden, die auf grobem Verschulden oder Vorsatz von PowerOn oder ihrer Hilfspersonen beruhen. In diesen Fällen haftet PowerOn unbeschränkt. + +### 19.5 Freistellung + +PowerOn stellt den Kunden von Ansprüchen Dritter frei, die aufgrund einer Verletzung von Rechten Dritter durch PowerOn entstehen, insbesondere bei IP-Verletzungen oder Datenschutzverstössen durch PowerOn. + +### 19.6 Haftungsausschluss für KI-Outputs + +PowerOn haftet nicht für die inhaltliche Richtigkeit, Vollständigkeit oder Eignung von KI-generierten Outputs (Ergebnissen der Sprachmodelle). Die Verantwortung für die Überprüfung und Verwendung von KI-Outputs liegt beim Kunden. PowerOn haftet jedoch für die vertragsgemässe Bereitstellung der Plattforminfrastruktur. + +--- + +## § 20 Aussetzung des Dienstes + +### 20.1 Eingeschränktes Aussetzungsrecht + +Das Recht von PowerOn, den Dienst auszusetzen oder den Datenzugang einzuschränken, ist auf aussergewöhnliche Situationen beschränkt, die ausschliesslich auf das Verhalten des Kunden zurückzuführen sind — insbesondere wenn Aktivitäten des Kunden eine unmittelbare ernsthafte Gefährdung der Datensicherheit oder der Dienste für andere Kunden verursachen oder die Plattform für gesetzeswidrige Zwecke genutzt wird. + +### 20.2 Vorwarnung bei Zahlungsverzug + +Eine Aussetzung wegen Zahlungsverzugs setzt voraus, dass PowerOn den Kunden mindestens **14 Tage** schriftlich vorab gewarnt hat. **Inhaltsdaten des Kunden werden in keinem Fall zurückbehalten** (vgl. § 18.4). + +### 20.3 Verhältnismässigkeit + +Jede Aussetzungsmassnahme muss verhältnismässig sein und auf das notwendige Minimum beschränkt werden. + +--- + +## § 21 Vertragsänderungen + +### 21.1 Keine einseitigen Verschlechterungen + +PowerOn ist nicht berechtigt, wesentliche Vertragsbestandteile (insbesondere Leistungsbeschreibung, Sicherheitsmassnahmen, Datenschutzmassnahmen oder Preise) einseitig zum Nachteil des Kunden zu ändern, es sei denn, dies ist gesetzlich zwingend vorgeschrieben. + +### 21.2 Ankündigungsfristen + +Änderungen werden dem Kunden mindestens **30 Tage** (bei wesentlichen Änderungen mindestens **3 Monate**, bei Abkündigung wesentlicher Funktionen mindestens **12 Monate**) im Voraus schriftlich mitgeteilt. + +### 21.3 Ausserordentliches Kündigungsrecht + +Bei wesentlichen nachteiligen Änderungen, die nicht zwingend rechtlich vorgeschrieben sind, hat der Kunde das Recht, den Vertrag mit einer Frist von **3 Monaten** zum Zeitpunkt des Inkrafttretens der Änderung ausserordentlich zu kündigen. + +--- + +## § 22 Übertragung des Vertrags + +### 22.1 Zustimmungspflicht + +Die Übertragung dieses Vertrags oder einzelner Rechte und Pflichten daraus auf Dritte bedarf der vorherigen schriftlichen Zustimmung der anderen Partei, die nicht ohne sachlichen Grund verweigert werden darf. + +### 22.2 Ausnahme: Regulatorische Anordnung + +Auf Anordnung einer zuständigen Aufsichtsbehörde (z.B. FINMA) oder im Insolvenzfall des Kunden ist PowerOn verpflichtet, den Vertrag auf einen vom Kunden oder von der Aufsichtsbehörde benannten Dritten zu übertragen, sofern dieser die Vertragsbedingungen übernimmt. + +### 22.3 Konzerninterne Übertragung + +Eine konzerninterne Übertragung (auf ein Tochter- oder Schwesterunternehmen) bedarf lediglich der schriftlichen Information der anderen Partei, sofern die Gesamtverantwortlichkeit erhalten bleibt. + +--- + +## § 23 Anwendbares Recht und Gerichtsstand + +### 23.1 Anwendbares Recht + +Dieser Vertrag unterliegt **ausschliesslich Schweizer Recht** unter Ausschluss der Kollisionsnormen und des UN-Kaufrechts (CISG). + +### 23.2 Gerichtsstand + +Ausschliesslicher Gerichtsstand für alle Streitigkeiten ist **Zürich, Schweiz**. PowerOn anerkennt, dass der Kunde einstweiligen Rechtsschutz auch an seinem Sitz beantragen kann. + +### 23.3 Regulatorische Anforderungen + +PowerOn verpflichtet sich zur Einhaltung aller auf die von ihm erbrachten Dienstleistungen anwendbaren Schweizer Gesetze und Regulierungen, einschliesslich der FINMA-Anforderungen, soweit diese im Einzelfall anwendbar sind. + +--- + +## § 24 Schlussbestimmungen + +### 24.1 Schriftformerfordernis + +Änderungen und Ergänzungen dieser AGB sowie aller darauf basierenden Verträge bedürfen zu ihrer Wirksamkeit der Textform. Mündliche Nebenabreden haben keine Gültigkeit. + +### 24.2 Salvatorische Klausel + +Sollten einzelne Bestimmungen dieser AGB unwirksam sein oder werden, berührt dies die Wirksamkeit der übrigen Bestimmungen nicht. Die Parteien verpflichten sich, eine unwirksame Bestimmung durch eine wirksame zu ersetzen, die dem wirtschaftlichen Zweck am nächsten kommt. + +### 24.3 Vollständigkeit + +Dieser Vertrag und seine Anhänge stellen die vollständige Vereinbarung der Parteien dar und ersetzen alle früheren Vereinbarungen. + +### 24.4 Sprache + +Massgebliche Vertragssprache ist **Deutsch**. Bei Widersprüchen zwischen Übersetzungen gilt die deutsche Fassung. + +--- + +--- + +# Anhang A: Subunternehmer- und LLM-Anbieter-Liste + +**Stand: 01.02.2026 | Version 1.0** + +> Diese Liste wird bei wesentlichen Änderungen aktualisiert und dem Kunden mindestens 30 Tage vor Einsatz eines neuen Anbieters kommuniziert. + +## A.1 Infrastruktur (Rechenzentrumsbetrieb) + +| Anbieter | Sitz | Funktion | Datenverarbeitung | Rechtsgrundlage | +|---|---|---|---|---| +| [RZ-Anbieter primär] | Schweiz | Primäres Rechenzentrum / Hosting | Schweiz | Schweizer DSG | +| [RZ-Anbieter DR] | Schweiz | Backup-Rechenzentrum (Disaster Recovery) | Schweiz | Schweizer DSG | + +## A.2 LLM-Anbieter (Unterauftragsverarbeiter) + +> **Hinweis für regulierte Kunden (FINMA, BAG):** Es wird empfohlen, ausschliesslich Optionen D oder E zu wählen, um eine vollständige Datenverarbeitung innerhalb der Schweiz sicherzustellen. + +| Option | Anbieter | Sitz | Datenverarbeitung | Datenschutzmechanismus | Zero-Data-Retention | +|---|---|---|---|---|---| +| A | Anthropic, Inc. | USA | USA | EU-SCC + TIA | Ja (Enterprise API) | +| B | OpenAI, LLC | USA | USA / EU (Azure) | EU-SCC + TIA | Ja (Enterprise API) | +| C | Google LLC (Vertex AI) | USA | USA / EU | EU-SCC + TIA | Ja (Enterprise) | +| D | [Schweizer LLM-Anbieter] | Schweiz | Schweiz | Schweizer DSG | Ja | +| E | Open-Source Modell (self-hosted auf PowerOn-Infra) | Schweiz | Schweiz | Schweizer DSG | N/A (lokal) | + +**Legende:** +- **EU-SCC:** EU-Standardvertragsklauseln (Durchführungsbeschluss 2021/914) +- **TIA:** Transfer Impact Assessment vorhanden und auf Anfrage einsehbar +- **Zero-Data-Retention:** Vertragliche Zusicherung des LLM-Anbieters, dass Daten nicht für Modelltraining genutzt werden + +## A.3 Weitere Subdienstleister + +| Anbieter | Sitz | Funktion | Land | Datenschutzgrundlage | +|---|---|---|---|---| +| [E-Mail-Dienstleister] | [Land] | Transaktionsmails, Benachrichtigungen | [Land] | [DSG / SCC] | +| [Monitoring-Anbieter] | [Land] | System-Monitoring, Alerting | [Land] | [DSG / SCC] | +| [Support-Tool] | [Land] | Kundensupport-Plattform | [Land] | [DSG / SCC] | + +--- + +# Anhang B: Service Level Agreement (SLA) + +**Stand: 01.02.2026** + +## B.1 Verfügbarkeits-SLA + +| Metrik | Zielwert | Messzeitraum | +|---|---|---| +| Plattform-Verfügbarkeit | ≥ 99,5% | Kalendermonat | +| API-Verfügbarkeit | ≥ 99,5% | Kalendermonat | +| Max. ungeplante Ausfallzeit | ≤ 3,6 Stunden | Kalendermonat | + +Geplante Wartungsfenster werden ausgeschlossen, sofern sie mindestens 5 Werktage im Voraus angekündigt wurden. + +## B.2 Reaktions- und Behebungszeiten + +| Priorität | Definition | Erstreaktion | Statusupdate | Behebungsziel | +|---|---|---|---|---| +| **P1 – Kritisch** | Vollständiger Plattformausfall oder Datenverlust | 30 Minuten | Stündlich | 4 Stunden | +| **P2 – Hoch** | Wesentliche Funktion nicht verfügbar | 2 Stunden | Alle 4 Stunden | 8 Stunden | +| **P3 – Mittel** | Einzelne Funktion beeinträchtigt | 4 Stunden | Täglich | 3 Werktage | +| **P4 – Niedrig** | Kosmetische Fehler, Verbesserungswünsche | 1 Werktag | Wöchentlich | Nach Absprache | + +## B.3 Recovery-Ziele + +| Parameter | Zielwert | +|---|---| +| Recovery Time Objective (RTO) | ≤ 4 Stunden | +| Recovery Point Objective (RPO) | ≤ 1 Stunde | +| Backup-Frequenz | Täglich inkrementell / wöchentlich vollständig | +| Backup-Aufbewahrung | 90 Tage | + +## B.4 SLA-Gutschriften bei Unterschreitung + +| Monatsverfügbarkeit | Gutschrift (% Monatsentgelt) | +|---|---| +| 99,0% – < 99,5% | 10% | +| 98,0% – < 99,0% | 20% | +| 95,0% – < 98,0% | 30% | +| < 95,0% | 50% | + +Gutschriften werden mit der nächsten Rechnung verrechnet. Ansprüche verfallen, wenn sie nicht innerhalb von 30 Tagen nach Ende des betreffenden Kalendermonats geltend gemacht werden. + +--- + +# Anhang C: Technisch-organisatorische Massnahmen (TOMs) + +**Stand: 01.02.2026** + +## C.1 Zugangskontrolle + +| Massnahme | Implementierung | +|---|---| +| Multi-Faktor-Authentifizierung (MFA) | Für alle Benutzerkonten verpflichtend (TOTP-App oder Hardware-Token; SMS-TAN wird vermieden) | +| Passwortrichtlinie | Mindestlänge 12 Zeichen, Komplexitätsvorgaben, kein Passwort-Sharing | +| Session Management | Automatische Session-Timeouts, sichere Token-Verwaltung | +| IP-Whitelisting | Einschränkung des Plattformzugangs auf definierte IP-Adressen möglich | + +## C.2 Zugriffskontrolle (Berechtigungsmanagement) + +| Massnahme | Implementierung | +|---|---| +| Rollenbasiertes Zugriffsmodell (RBAC) | Definierte Rollen mit granularen Berechtigungen | +| Need-to-Know / Least Privilege | Mitarbeitende erhalten nur minimal notwendige Berechtigungen | +| Privileged Access Management (PAM) | Separates PAM-System für privilegierte Zugriffe mit lückenloser Protokollierung | +| Rezertifizierung | Vierteljährliche Überprüfung aller Zugriffsberechtigungen | +| Offboarding | Sofortige Sperrung bei Ausscheiden von Mitarbeitenden | + +## C.3 Verschlüsselung + +| Massnahme | Standard | +|---|---| +| Daten im Ruhezustand (at rest) | AES-256 | +| Daten bei Übertragung (in transit) | TLS 1.3 (ältere Versionen deaktiviert) | +| Schlüsselmanagement | Dedizierter Key Store, kundenspezifische Schlüssel, NIST SP 800-57 | + +## C.4 Protokollierung und Monitoring + +| Massnahme | Implementierung | +|---|---| +| Audit-Logging | Lückenlose, manipulationsgeschützte Protokollierung aller Datenzugriffe (inkl. PowerOn-Mitarbeiterzugriffe) | +| Log-Aufbewahrung | Mindestens 3 Jahre | +| Log-Schutz | Write-once / Append-only, restriktiver Zugriffsschutz | +| 24/7-Monitoring | Kontinuierliche automatische Überwachung aller systemkritischen Komponenten | +| SIEM | Automatisierte Anomalie-Erkennung und Alerting | +| Kundenzugang zu Logs | Logs sind dem Kunden jederzeit zugänglich, inkl. Echtzeit-API-Zugang | +| SOC-Integration | Log-Streaming-Schnittstellen für Kunden-SOC verfügbar (Syslog, CEF, API) | + +## C.5 Netzwerksicherheit + +| Massnahme | Implementierung | +|---|---| +| Firewall & WAF | Netzwerk- und Applikations-Firewall (Web Application Firewall) | +| IDS/IPS | Intrusion Detection und Prevention System | +| DDoS-Schutz | Automatische Erkennung und Abwehr volumetrischer Angriffe | +| Netzwerksegmentierung | Logische und physische Trennung der Kundenmandanten | +| Konfigurationshärtung | CIS Benchmarks; regelmässige Compliance-Validierung | + +## C.6 Rechenzentrum und physische Sicherheit + +| Massnahme | Implementierung | +|---|---| +| Standort | Ausschliesslich Schweiz | +| Physische Zutrittskontrolle | Biometrie und/oder Chipkarte, Videoüberwachung, Besucherprotokoll | +| Energieversorgung | USV (unterbrechungsfreie Stromversorgung), Notstromaggregat | +| Brandschutz | Gaslöschanlage, Raucherkennung | +| Zertifizierung | [ISO 27001 / Tier III oder höher — Zertifikat auf Anfrage verfügbar] | + +## C.7 Backup und Wiederherstellung + +| Massnahme | Implementierung | +|---|---| +| Backup-Frequenz | Täglich inkrementell, wöchentlich vollständig | +| Backup-Verschlüsselung | AES-256, separate Schlüssel | +| Backup-Monitoring | Automatische Überwachung und Alerting bei Fehlern | +| Restore-Tests | Mindestens vierteljährlich mit schriftlichem Protokoll | +| Geografische Trennung | Backups in separatem Schweizer Rechenzentrum | + +## C.8 Schwachstellen- und Patch-Management + +| Massnahme | Implementierung | +|---|---| +| Vulnerability Scanning | Wöchentlich automatisiert | +| Penetrationstests | Mindestens jährlich durch akkreditierten unabhängigen Drittanbieter | +| Patch-Fristen | Kritische Patches: 48h; sonstige Sicherheitspatches: 30 Tage | +| Schwachstellen-Tracking | Dokumentiertes Massnahmen-Tracking bis zur vollständigen Behebung | + +## C.9 Mitarbeitersicherheit + +| Massnahme | Implementierung | +|---|---| +| Hintergrundüberprüfung | Vor Beschäftigung, soweit gesetzlich zulässig | +| Sicherheitsschulung | Bei Onboarding und jährlich wiederkehrend | +| Vertraulichkeitsverpflichtung | Schriftlich, zeitlich unbefristet | +| Awareness-Training | Phishing-Simulationen, Social-Engineering-Training | + +## C.10 Incident Response + +| Massnahme | Implementierung | +|---|---| +| Incident Response Plan | Schriftlich dokumentiert, mindestens jährlich getestet | +| 24h-Meldepflicht | Implementierter Prozess für FINMA-konforme Meldung (vgl. § 14) | +| Forensische Sicherung | Beweissicherung vor Bereinigung von Systemen | +| Post-Incident-Review | Root-Cause-Analyse und Massnahmenplan innert 72h nach Vorfall | + +--- + +*Dieses Dokument ist rechtlich unverbindlich ohne Unterzeichnung des individuellen Dienstleistungsvertrags. PowerOn empfiehlt die Prüfung durch einen auf IT- und Datenschutzrecht spezialisierten Anwalt, insbesondere für FINMA-regulierte Kunden.* + +*Version: 1.0 | Stand: 01.02.2026 | Nächste planmässige Überprüfung: 01.02.2027* diff --git a/e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md b/e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md new file mode 100644 index 0000000..56e9304 --- /dev/null +++ b/e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md @@ -0,0 +1,56 @@ +# E-Compliance Prozessübersicht — PowerOn / PORTA + +**Zweck:** Dieses Verzeichnis enthält die dokumentierten Prozesse und Konzepte der PowerOn AG zum Nachweis der Anforderungen aus dem **GLKB Cloud Assessment Criteria Catalogue (CACC)** sowie den FINMA-Rundschreiben 2018/3 und 2023/1. + +**Stand:** 02.06.2026 +**Geltungsbereich:** PORTA Enterprise KI-Plattform (`api.poweron.swiss`) +**Hinweis:** `[ZU PRÜFEN]` markiert Stellen, an denen ein Fakt vor Einreichung verifiziert oder ergänzt werden muss. + +--- + +## Rahmenbedingungen (gelten für alle Dokumente) + +- **Hosting & Datenspeicherung:** Infomaniak Public Cloud, Schweiz (`api.poweron.swiss`, `db.poweron.swiss`). +- **Datenverarbeitung KI:** Inhaltsdaten werden zur KI-Verarbeitung an externe LLM-Provider übermittelt. **Primärprovider ist OpenAI (USA).** Diese Übermittlung verlässt die Schweiz und ist über AVV/DPA + EU-SCC abgesichert (siehe Drittanbieter-Inventar und Verschlüsselungskonzept). +- **Team:** Sehr kleines Team (2–5 Personen). Wo Katalogpunkte eine grössere Organisation voraussetzen (24/7-SOC, vollständige Funktionstrennung), werden **kompensierende Massnahmen** beschrieben. + +--- + +## Dokumentenkarte → CACC-Punkte + +| Dokument | Abgedeckte CACC-Punkte | +|---|---| +| `01_Informationssicherheitsrichtlinie.md` | 49, 52, 56 | +| `02_Zugriffsmanagement_IAM_PAM.md` | 25, 36, 37, 66, 67, 68, 69 | +| `03_Mitarbeitersicherheit_und_Screening.md` | 23, 35, 37 | +| `04_Verschluesselung_und_Schluesselmanagement.md` | 43, 44, 45, 46, 70, 71, 72 | +| `05_Backup_und_Wiederherstellung.md` | 75, 87 | +| `06_Business_Continuity_und_Disaster_Recovery.md` | 3, 79, 87 | +| `07_Incident_Response_und_Meldewesen.md` | 19, 20, 27, 86 | +| `08_Change_Management.md` | 81, 82, 83 | +| `09_Patch_Management.md` | 78 | +| `10_Schwachstellenmanagement.md` | 54, 59, 63, 84 | +| `11_Logging_und_Monitoring.md` | 88, 89, 90, 91, 92, 93, 94 | +| `12_Netzwerk_und_Infrastruktursicherheit.md` | 95, 96, 97, 98, 99 | +| `13_Datenaufbewahrung_Loeschung_LegalHold.md` | 1, 2, 38, 72 | +| `14_Exit_und_Transition.md` | 4, 5, 6, 22 | +| `15_Sichere_Softwareentwicklung_SDLC.md` | 100, 101, 102 | +| `16_Kapazitaetsmanagement.md` | 80 | +| `17_Subunternehmer_Management.md` | 16, 31, 48, 53 | +| `18_Analyse_Recht_und_BestPractice.md` | Befundbericht (rechtlich / Best Practice, intern) | +| **Bestehend:** `drittanbieter-inventar.md` | 48, 53, 61 | +| **Bestehend:** `datenbank-handling.md` | 2, 38, 75 (teilw.) | +| **Bestehend:** `bcm_runbook.md` | 3, 87 (technisch) | +| **Bestehend:** `feature_release_bugfix.md` | 81, 100, 101 (teilw.) | + +--- + +## Offene Punkte vor Einreichung (Sammelliste) + +- [ ] Verschlüsselung at-rest der Infomaniak-DB bestätigen (Konzept #04) +- [ ] MFA-Status auf Admin-/Server-Zugängen bestätigen (#02) +- [ ] Hintergrundprüfungen bei Einstellung klären (#03) +- [ ] Log-Aufbewahrungsdauer und Manipulationsschutz festlegen (#11) +- [ ] Restore-Test-Protokoll erstmalig durchführen und ablegen (#05) +- [ ] AVV/Zero-Retention-Verträge mit OpenAI & weiteren LLM-Providern ablegen (#17) +- [ ] Entscheidung zu produktiven Daten in Testumgebung (#15) diff --git a/e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md b/e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md new file mode 100644 index 0000000..8bce818 --- /dev/null +++ b/e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md @@ -0,0 +1,66 @@ +# Informationssicherheitsrichtlinie (ISMS-Dachdokument) + +**Dokumenttyp:** Richtlinie +**Geltungsbereich:** PORTA Enterprise KI-Plattform, gesamte PowerOn AG +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Geschäftsführung PowerOn AG +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 49, 52, 56 + +--- + +## 1. Zweck und Geltungsbereich + +Diese Richtlinie definiert die grundlegenden Vorgaben, Prinzipien und Verantwortlichkeiten für die Informationssicherheit bei PowerOn. Sie ist das Dachdokument des Informationssicherheits-Managementsystems (ISMS) und verweist auf die detaillierten Einzelprozesse. + +Der Geltungsbereich umfasst alle Systeme, Daten, Mitarbeitenden und Dienstleister, die an der Bereitstellung der PORTA-Plattform beteiligt sind — insbesondere die Infrastruktur bei Infomaniak (`api.poweron.swiss`, `db.poweron.swiss`), das Forgejo-basierte Entwicklungs- und Deployment-System sowie alle im Drittanbieter-Inventar gelisteten externen Dienste. + +## 2. Sicherheitsziele + +PowerOn verfolgt die klassischen Schutzziele der Informationssicherheit: + +- **Vertraulichkeit:** Kundendaten (Inhaltsdaten, insbesondere Berufsgeheimnisdaten) sind nur autorisierten Personen und Prozessen zugänglich. +- **Integrität:** Daten und Systeme sind vor unbefugter oder unbeabsichtigter Veränderung geschützt. +- **Verfügbarkeit:** Die Plattform und die Kundendaten stehen im Rahmen der vereinbarten Service Levels zur Verfügung. +- **Nachvollziehbarkeit:** Zugriffe und Änderungen an kritischen Systemen sind protokolliert und auditierbar. + +## 3. Organisation und Verantwortlichkeiten + +Aufgrund der kleinen Teamgrösse (2–5 Personen) werden Rollen gebündelt. Eine vollständige Funktionstrennung ist nicht in allen Bereichen möglich; wo sie fehlt, greifen kompensierende Massnahmen (Vier-Augen-Prinzip bei Releases, Protokollierung privilegierter Zugriffe). + +| Rolle | Verantwortung | Träger | +|---|---|---| +| Informationssicherheits-Verantwortlicher (ISO/CISO-Funktion) | Pflege des ISMS, Risikobeurteilung, Richtlinienfreigabe | Patrick Motsch (p.motsch@poweron.swiss) | +| Datenschutzverantwortlicher | Einhaltung DSG/DSGVO, AVV-Management | Patrick Motsch (p.motsch@poweron.swiss) | +| Drittdienst-Verantwortlicher | Verwaltung externer Dienste, Subunternehmer | Patrick Motsch (p.motsch@poweron.swiss) | +| Betrieb / DevOps | Server, Deployment, Backups, Incident-Handling | Patrick Motsch (p.motsch@poweron.swiss) | +| Geschäftsführung | Gesamtverantwortung, Freigabe Richtlinien | Patrick Motsch (p.motsch@poweron.swiss) | + +## 4. Grundsätze + +1. **Need-to-Know & Least Privilege:** Zugriff nur im erforderlichen Umfang (Details: `02_Zugriffsmanagement_IAM_PAM.md`). +2. **Sichere Standardkonfiguration:** Systeme werden nach anerkannten Standards gehärtet (Details: `12_Netzwerk_und_Infrastruktursicherheit.md`). +3. **Verschlüsselung:** Daten werden bei Übertragung und Speicherung verschlüsselt (Details: `04_Verschluesselung_und_Schluesselmanagement.md`). +4. **Nachvollziehbare Änderungen:** Alle Produktivänderungen durchlaufen den Change-Prozess (Details: `08_Change_Management.md`). +5. **Vorfallreaktion:** Sicherheitsvorfälle werden klassifiziert, behoben und gemeldet (Details: `07_Incident_Response_und_Meldewesen.md`). + +## 5. Risikomanagement + +PowerOn führt mindestens jährlich sowie anlassbezogen (z. B. bei wesentlichen Architekturänderungen) eine Risikobeurteilung der für Kunden relevanten Systeme durch. Identifizierte Risiken werden bewertet (Eintrittswahrscheinlichkeit × Auswirkung), behandelt (vermeiden / vermindern / übertragen / akzeptieren) und dokumentiert. Ergebnisse werden auf Anfrage berechtigten Kunden und Prüfern offengelegt. + +## 6. Verbindlichkeit und Schulung + +Diese Richtlinie ist für alle Mitarbeitenden und Hilfspersonen verbindlich. Neue Mitarbeitende werden im Onboarding auf die Richtlinie verpflichtet; eine Auffrischung erfolgt jährlich (siehe `03_Mitarbeitersicherheit_und_Screening.md`). + +## 7. Überprüfung + +Die Richtlinie wird mindestens jährlich sowie bei wesentlichen Änderungen überprüft und durch die Geschäftsführung freigegeben. + +## 8. Stand der Umsetzung / Lücken + +| Thema | Status | Geplante Massnahme | +|---|---|---| +| ISMS nach ISO/IEC 27001 zertifiziert | Nicht vorhanden | [ZU PRÜFEN: Zertifizierung geplant? Zeithorizont?] | +| Dokumentierte Rollenzuteilung | In Arbeit (dieses Dokument) | Namentliche Zuordnung ergänzen | +| Jährliche Risikobeurteilung | [ZU PRÜFEN] | Erstdurchführung terminieren | diff --git a/e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md b/e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md new file mode 100644 index 0000000..5b44de0 --- /dev/null +++ b/e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md @@ -0,0 +1,77 @@ +# Zugriffsmanagement (IAM / PAM) + +**Dokumenttyp:** Richtlinie & Prozess +**Geltungsbereich:** Alle Zugänge zu PORTA-Systemen (Server, Datenbank, Admin-UI, Drittdienste) +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 25, 36, 37, 66, 67, 68, 69 + +--- + +## 1. Grundprinzipien + +PowerOn gewährt Zugriffe ausschliesslich nach **Need-to-Know** und **Least Privilege**. Kein Mitarbeiter erhält mehr Rechte, als für seine Aufgabe erforderlich sind. + +## 2. Zugriffsebenen der Plattform + +| Ebene | Beschreibung | Berechtigte | +|---|---|---| +| **SysAdmin (Admin-UI)** | Höchste Stufe in der PORTA-Admin-UI: DB-Export/Import, Mandatsverwaltung, Feature-Steuerung | Patrick Motsch | +| **Server-Zugang (SSH)** | `ubuntu@api.poweron.swiss` / `api-int` — Vollzugriff auf Anwendung und Konfiguration | Patrick Motsch | +| **Datenbank** | DB-User `poweron_dev` auf `db.poweron.swiss:5432` | Patrick Motsch | +| **Mandats-Administrator (kundenseitig)** | Verwaltet Nutzer innerhalb des eigenen Tenants | Kunde selbst | +| **Endnutzer** | Nutzung der gebuchten Features | Kunde | + +> **Offener Punkt (kompensierende Massnahme nötig):** Der SSH-Zugang erfolgt aktuell über den geteilten Benutzer `ubuntu`. Für Nachvollziehbarkeit auf Personenebene ist entweder (a) Umstellung auf personalisierte SSH-Accounts oder (b) lückenlose Protokollierung jeder SSH-Sitzung mit eindeutiger Personenzuordnung erforderlich. → siehe `11_Logging_und_Monitoring.md`. **[ZU PRÜFEN / UMZUSETZEN]** + +## 3. Zugang zu Kundendaten im Klartext (#25, #66) + +Mitarbeitende von PowerOn greifen auf Inhaltsdaten eines Kunden im Klartext **nur** zu, wenn: + +1. der Kunde dies für einen konkreten Fall (z. B. Support-Ticket) freigegeben hat, **oder** +2. eine rechtskräftige behördliche Anordnung dies zwingend verlangt, **oder** +3. ein schwerer technischer Störfall den Zugriff temporär erfordert — mit unverzüglicher nachträglicher Information des Kunden. + +Jeder solche Zugriff wird protokolliert (Datenbank-Export/Import wird serverseitig geloggt, siehe `datenbank-handling.md` Abschnitt 6). + +## 4. Authentifizierung (#68) + +| System | Authentifizierungsmethode | MFA | +|---|---|---| +| PORTA Endnutzer | Microsoft Azure AD OAuth / Google OAuth / lokales Login | [ZU PRÜFEN: MFA erzwungen?] | +| Admin-UI (SysAdmin) | [ZU PRÜFEN] | [ZU PRÜFEN: MFA?] | +| SSH-Server | SSH-Key | [ZU PRÜFEN: Key + Passphrase? Bastion?] | +| Drittdienste (OpenAI etc.) | API-Keys in `.env` | n/a | + +**Vorgabe:** Für privilegierte Zugänge (SysAdmin, SSH, DB) ist Zwei-Faktor-Authentifizierung zu konfigurieren. SMS-/mobile TAN ist möglichst zu vermeiden; bevorzugt App- oder Hardware-Token. **[ZU PRÜFEN: aktueller Stand]** + +## 5. Berechtigungsvergabe, -änderung und -entzug (#67) + +| Ereignis | Massnahme | Frist | +|---|---|---| +| Onboarding | Zugänge gemäss Rolle einrichten, Minimalprinzip | Bei Eintritt | +| Rollenwechsel | Berechtigungen anpassen, nicht mehr benötigte entziehen | Innert 5 Werktagen | +| Offboarding | **Alle** Zugänge sofort sperren: SSH-Key entfernen, Admin-UI deaktivieren, API-Keys rotieren, DB-Zugang entziehen | Am letzten Arbeitstag | +| Rezertifizierung | Vollständige Überprüfung aller Zugänge und Berechtigungen | Mindestens halbjährlich | + +## 6. Privilegierte Zugriffe (PAM) (#36, #37) + +Privilegierter Zugriff (SSH, DB-Admin, SysAdmin) wird nur sorgfältig ausgewählten, geschulten Personen gewährt. Aufgrund der Teamgrösse ist die Anzahl privilegierter Personen sehr klein, was das Risiko begrenzt. Kompensierend zu fehlender vollständiger Funktionstrennung gilt: + +- Protokollierung privilegierter Aktionen (Export/Import, Deployments, DB-Zugriffe). +- Vier-Augen-Prinzip bei produktiven Releases (siehe `feature_release_bugfix.md` / `08_Change_Management.md`). +- Regelmässige Stichprobenprüfung der Protokolle. + +## 7. Zugangsbeschränkung auf IP/Domain (#69) + +[ZU PRÜFEN: Ist der Admin-/Server-Zugang auf bestimmte IP-Adressen beschränkt? Falls ja, dokumentieren. Falls nein, als geplante Massnahme aufnehmen.] + +## 8. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Personalisierte SSH-Accounts | Offen | Umstellung oder vollständige Sitzungsprotokollierung | +| MFA auf privilegierten Zugängen | [ZU PRÜFEN] | Erzwingen | +| Halbjährliche Rezertifizierung | Neu | Erstdurchführung terminieren | diff --git a/e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md b/e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md new file mode 100644 index 0000000..36ffa55 --- /dev/null +++ b/e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md @@ -0,0 +1,55 @@ +# Mitarbeitersicherheit und Screening + +**Dokumenttyp:** Richtlinie & Prozess +**Geltungsbereich:** Alle Mitarbeitenden und Hilfspersonen mit Zugang zu Kundendaten +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Geschäftsführung +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 23, 35, 37 + +--- + +## 1. Vertraulichkeitsverpflichtung (#23) + +Alle Mitarbeitenden und Hilfspersonen werden bei Eintritt schriftlich zur Geheimhaltung sämtlicher Inhaltsdaten der Kunden verpflichtet — insbesondere zur Wahrung des Bankkunden- und sonstigen Berufsgeheimnisses. Die Verpflichtung gilt **zeitlich unbefristet** und besteht auch nach Beendigung des Arbeitsverhältnisses fort. + +**Nachweis:** Unterschriebene Geheimhaltungsvereinbarung (NDA) im Personaldossier. **[ZU PRÜFEN: liegen NDAs für alle aktuellen Mitarbeitenden vor?]** + +## 2. Sorgfältige Auswahl und Hintergrundprüfung (#35) + +Vor Gewährung von Zugang zu Berufsgeheimnisdaten im Klartext werden Mitarbeitende sorgfältig ausgewählt und überprüft. + +| Prüfschritt | Durchführung | +|---|---| +| Identitätsprüfung | Bei Einstellung | +| Strafregisterauszug | [ZU PRÜFEN: wird verlangt?] | +| Referenzprüfung früherer Arbeitgeber | [ZU PRÜFEN] | +| Prüfung auf einschlägige Sanktionslisten | [ZU PRÜFEN] | + +> **Hinweis:** Punkt #35 verlangt eine Überprüfung „entsprechend den Standards des Instituts für eigene Mitarbeiter". Für FINMA-Kunden ist mindestens ein aktueller Strafregisterauszug üblich. Falls dies aktuell nicht erfolgt, als Massnahme aufnehmen. + +## 3. Schulung und Awareness + +| Massnahme | Häufigkeit | +|---|---| +| Sicherheits- und Datenschutz-Onboarding | Bei Eintritt | +| Auffrischungsschulung (inkl. Phishing-/Social-Engineering-Awareness) | Jährlich | +| Schulung zu dieser Richtlinie und zur IS-Richtlinie | Bei Eintritt + bei Änderungen | + +**[ZU PRÜFEN: Findet eine strukturierte Schulung statt? Falls informell, formalisieren und dokumentieren.]** + +## 4. Überwachung privilegierter Mitarbeitender (#37) + +Mitarbeitende mit privilegiertem Zugriff auf kritische Klartextdaten werden: +- sorgfältig ausgewählt und geschult, +- durch Audit-Trails überwacht, die regelmässig (mindestens stichprobenweise) ausgewertet werden (siehe `11_Logging_und_Monitoring.md`), +- bei Offboarding sofort entzogen (siehe `02_Zugriffsmanagement_IAM_PAM.md` Abschnitt 5). + +## 5. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| NDAs für alle Mitarbeitenden | [ZU PRÜFEN] | Vollständigkeit sicherstellen | +| Strafregisterauszug bei Einstellung | [ZU PRÜFEN] | Einführen falls nicht vorhanden | +| Dokumentierte jährliche Schulung | [ZU PRÜFEN] | Formalisieren | diff --git a/e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md b/e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md new file mode 100644 index 0000000..b09f508 --- /dev/null +++ b/e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md @@ -0,0 +1,74 @@ +# Verschlüsselung und Schlüsselmanagement + +**Dokumenttyp:** Konzept +**Geltungsbereich:** Speicherung und Übertragung aller Kundendaten der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 43, 44, 45, 46, 70, 71, 72 + +--- + +## 1. Verschlüsselung bei der Übertragung (in transit) (#70) + +| Verbindung | Schutz | +|---|---| +| Endnutzer → `api.poweron.swiss` | HTTPS / TLS [ZU PRÜFEN: TLS 1.2 / 1.3? Ältere Versionen deaktiviert?] | +| Anwendung → Datenbank `db.poweron.swiss` | [ZU PRÜFEN: TLS/SSL auf PostgreSQL-Verbindung aktiv?] | +| Anwendung → LLM-Provider (OpenAI etc.) | HTTPS / TLS (durch Provider-APIs) | +| System-E-Mail (Azure Communication Services) | TLS | + +**Vorgabe:** Alle externen Verbindungen über TLS 1.2 oder höher; ältere Protokolle deaktiviert. + +## 2. Verschlüsselung im Ruhezustand (at rest) (#70) + +| Datenort | Verschlüsselung | +|---|---| +| PostgreSQL-Datenbank (Infomaniak Managed DB) | [ZU PRÜFEN: At-Rest-Verschlüsselung durch Infomaniak aktiviert? Standard bei Managed Databases bestätigen] | +| VM-Speicher (Infomaniak) | [ZU PRÜFEN: Volume-Verschlüsselung] | +| Backup-/Export-Dateien (JSON) | **Aktuell unverschlüsselt** — siehe Hinweis unten | + +> **Wichtiger offener Punkt:** Die JSON-Exporte aus `datenbank-handling.md` enthalten *alle* Kundendaten im Klartext und sind aktuell nicht verschlüsselt. **Massnahme:** Export-Dateien verschlüsselt ablegen (z. B. AES-256 / GPG) und Aufbewahrungsort absichern. → siehe `13_Datenaufbewahrung_Loeschung_LegalHold.md`. + +## 3. Verarbeitung bei LLM-Providern (in use) + +Zur KI-Verarbeitung werden Inhaltsdaten an externe LLM-Provider übermittelt (Primär: OpenAI, USA). Während der Verarbeitung liegen die Daten beim Provider. Schutzmechanismen: + +- Übertragung ausschliesslich über TLS. +- Vertragliche Absicherung über AVV/DPA und (für US-Provider) EU-Standardvertragsklauseln. **[ZU PRÜFEN: Verträge abgeschlossen — siehe `17_Subunternehmer_Management.md`]** +- Zero-Data-Retention-Vereinbarung (Daten werden nicht für Provider-Training genutzt). **[ZU PRÜFEN: Enterprise-Tier / Opt-out aktiviert?]** + +## 4. Schlüsselmanagement-Modelle (#43–46, #71) + +Der Katalog beschreibt vier Modelle. Aktueller Stand und Angebot von PowerOn: + +| Modell | Beschreibung | PowerOn-Angebot | +|---|---|---| +| **A — Kundenkontrolliert** | Schlüssel nur für vom Kunden zugelassene Nutzer/Prozesse | [ZU PRÜFEN: technisch möglich?] | +| **B — Anbieter verwaltet (Standard)** | Schlüssel im Speicher von PowerOn/Infomaniak, PowerOn verwaltet | Aktueller Stand: Infomaniak Managed Keys | +| **C — Anbieter-Speicher, Kunde verwaltet remote** | Schlüssel bei PowerOn, Verwaltung durch Kunde | [ZU PRÜFEN] | +| **D — Kunden-Schlüsselspeicher (BYOK)** | Schlüssel in kundenseitigem Key Store | [ZU PRÜFEN: BYOK angeboten?] | + +**Realistische Aussage für das Assessment:** Aktuell wird Modell B (anbieterverwaltet über Infomaniak) genutzt. BYOK/kundenkontrollierte Schlüssel sind [ZU PRÜFEN: nicht / in Planung]. + +## 5. Schlüssellebenszyklus (#72) + +Anforderungen für sichere Erzeugung, Speicherung, Archivierung, Abfrage, Verteilung, Sperrung und Löschung von Schlüsseln: + +| Phase | Vorgabe | Status | +|---|---|---| +| Erzeugung | Durch Infomaniak Managed DB / etablierte Bibliotheken | [ZU PRÜFEN] | +| Speicherung | Getrennt von verschlüsselten Daten | [ZU PRÜFEN] | +| API-Keys (OpenAI etc.) | In `.env` auf dem Server, nicht im Git | Umgesetzt (Konfiguration getrennt) | +| Rotation | API-Keys bei Offboarding/Verdacht rotieren | [ZU PRÜFEN: Rotationsintervall definieren] | +| Sperrung/Löschung | Bei Vertragsende Schlüssel vernichten (Krypto-Löschung) | siehe Dok 13 | + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| At-Rest-Verschlüsselung DB bestätigen | [ZU PRÜFEN] | Bei Infomaniak verifizieren, dokumentieren | +| Export-Dateien verschlüsseln | Offen | AES-256/GPG einführen | +| BYOK-Angebot | [ZU PRÜFEN] | Entscheidung für regulierte Kunden | +| Schlüssel-Rotationsintervall | Offen | Festlegen | diff --git a/e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md b/e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md new file mode 100644 index 0000000..d284240 --- /dev/null +++ b/e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md @@ -0,0 +1,74 @@ +# Backup und Wiederherstellung + +**Dokumenttyp:** Konzept & Prozess +**Geltungsbereich:** Alle Kundendaten auf `db.poweron.swiss` +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 75, 87 +**Verweist auf:** `datenbank-handling.md`, `bcm_runbook.md` + +--- + +## 1. Backup-Strategie (mehrschichtig) + +PowerOn sichert Daten auf zwei Ebenen (vgl. `datenbank-handling.md` Abschnitt 4): + +| Ebene | Mechanismus | Verantwortung | +|---|---|---| +| **Infrastruktur** | Snapshots der Infomaniak Managed PostgreSQL | Infomaniak / Betrieb | +| **Anwendung** | Vollständiger JSON-Export aller 13 Datenbanken via Admin-UI oder Script | Betrieb (SysAdmin) | + +Token- und AuthEvent-Tabellen sowie die Testdatenbank werden vom Export ausgeschlossen. + +## 2. Anforderung #75 — die drei Pflichtelemente + +Punkt #75 verlangt explizit drei Dinge. Stand und Massnahmen: + +### 2.1 Angemessener Schutz der gesicherten Daten +- Backup-Dateien enthalten alle Kundendaten und sind als vertraulich klassifiziert. +- **Offen:** Export-Dateien aktuell unverschlüsselt → Verschlüsselung einführen (siehe Dok 04). +- Ablage nur auf gesicherten Speichern, nicht auf persönlichen Geräten/Cloud (vgl. `datenbank-handling.md` Abschnitt 6). + +### 2.2 Überwachung der Datensicherung +- **Offen / [ZU PRÜFEN]:** Werden Infomaniak-Snapshots automatisch überwacht (Erfolg/Fehler-Alerting)? +- **Massnahme:** Automatisiertes Alerting bei fehlgeschlagenem Backup einrichten; Backup-Status mindestens wöchentlich kontrollieren. + +### 2.3 Test der Wiederherstellungsverfahren +- Das technische Restore-Verfahren ist in `bcm_runbook.md` Abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + Migrations-Tool). +- **Offen:** Es fehlt ein dokumentierter, regelmässiger Restore-Test. +- **Massnahme:** Mindestens **vierteljährlich** einen Restore-Test auf der INT-Umgebung durchführen und protokollieren (Datum, getestete DB, Dauer, Ergebnis, Tester). + +## 3. Backup-Frequenz und Aufbewahrung + +| Anlass | Aktion | Aufbewahrung | +|---|---|---| +| Vor jedem Deployment | Export via Admin-UI | bis zum nächsten erfolgreichen Deployment | +| Vor DB-Migrationen | Export + beschriftet archivieren | mind. 90 Tage | +| Wöchentlich | Archiv-Export | [ZU PRÜFEN: Aufbewahrungsdauer festlegen, z. B. 90 Tage] | +| Infrastruktur-Snapshot | automatisch (Infomaniak) | [ZU PRÜFEN: Intervall & Retention bei Infomaniak] | + +## 4. Wiederherstellungsziele (RTO/RPO) + +| Parameter | Zielwert | Bemerkung | +|---|---|---| +| RTO (Recovery Time Objective) | [ZU PRÜFEN, Vorschlag: ≤ 4 h] | Restore dauert lt. Runbook „wenige Minuten bis 1 Stunde" | +| RPO (Recovery Point Objective) | [ZU PRÜFEN, Vorschlag: ≤ 24 h] | Abhängig von Snapshot-/Export-Frequenz | + +> Hinweis: RTO/RPO müssen zu den im SLA gegenüber Kunden zugesagten Werten passen (AGB Anhang B). Aktuell im AGB-Entwurf RTO ≤ 4 h / RPO ≤ 1 h — das erfordert häufigere Sicherungen als die aktuelle wöchentliche Praxis. **Abgleich nötig.** + +## 5. Restore-Test-Protokoll (Vorlage) + +| Datum | Getestete DB | Quelle (Backup) | Dauer | Ergebnis | Tester | +|---|---|---|---|---|---| +| | | | | | | + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Backup-Verschlüsselung | Offen | siehe Dok 04 | +| Backup-Monitoring/Alerting | [ZU PRÜFEN] | Einrichten | +| Regelmässiger Restore-Test | Offen | Vierteljährlich + Protokoll | +| RTO/RPO mit SLA abgleichen | Offen | Werte festlegen & Frequenz anpassen | diff --git a/e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md b/e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md new file mode 100644 index 0000000..8463853 --- /dev/null +++ b/e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md @@ -0,0 +1,80 @@ +# Business Continuity (BCP) und Disaster Recovery (DRP) + +**Dokumenttyp:** Konzept & Plan +**Geltungsbereich:** PORTA-Plattform und zugehörige Infrastruktur +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Geschäftsführung / Betrieb +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 3, 79, 87 +**Verweist auf:** `bcm_runbook.md`, `05_Backup_und_Wiederherstellung.md`, `drittanbieter-inventar.md` + +--- + +## 1. Zweck + +Dieser Plan stellt die kontinuierliche Leistungserbringung und die Wiederherstellung der PORTA-Plattform im Katastrophen- und Störfall sicher. Die operativen Schritte sind im `bcm_runbook.md` dokumentiert; dieses Dokument liefert den organisatorischen Rahmen (Szenarien, Rollen, Ziele, Tests). + +## 2. Kritische Komponenten und Abhängigkeiten + +Aus dem Drittanbieter-Inventar ergeben sich die geschäftskritischen Abhängigkeiten: + +| Komponente | Anbieter | Auswirkung bei Ausfall | +|---|---|---| +| VM-Hosting & DB | Infomaniak (CH) | **Totalausfall** der Plattform | +| Primärer LLM-Provider | OpenAI (USA) | KI-Features (Chat, Agent, Automation) nicht verfügbar — Ausweichen auf Anthropic/Mistral möglich | +| Auth | Microsoft Azure AD / Google OAuth | Login für betroffene Nutzer nicht möglich | +| Zahlungen | Stripe | Neue Abos/Zahlungen schlagen fehl | +| System-E-Mail | Azure Communication Services (CH) | Einladungen/Benachrichtigungen werden nicht zugestellt | + +## 3. Szenarien und Reaktion + +| # | Szenario | Reaktion | Referenz | +|---|---|---|---| +| 1 | API antwortet nicht / Timeouts | Service-Neustart | `bcm_runbook.md` §1 | +| 2 | Datenverlust / fehlerhafte Migration | Backup-Restore | `bcm_runbook.md` §2 | +| 3 | Fehlerhaftes Release | Rollback (Git/Forgejo) | `bcm_runbook.md` §3 | +| 4 | Ausfall LLM-Primärprovider | Umschalten auf alternativen Provider (Anthropic/Mistral) | [ZU PRÜFEN: Failover-Konfiguration dokumentieren] | +| 5 | Totalausfall Infomaniak-Region | Wiederaufbau aus Export-Backup | siehe unten | + +## 4. Verfügbarkeitsüberwachung (#79) + +- Health-Check-Endpunkt: `GET /api/admin/health` (liefert 200 OK bei intaktem Betrieb). +- [ZU PRÜFEN: Existiert ein automatisiertes Uptime-Monitoring, das den Health-Check periodisch prüft und bei Ausfall alarmiert? Falls nicht: einrichten (z. B. externer Monitor + Alert an Betrieb).] + +## 5. Wiederherstellungsziele + +| Parameter | Zielwert | Quelle | +|---|---|---| +| RTO | [ZU PRÜFEN, Vorschlag ≤ 4 h] | mit SLA abgleichen | +| RPO | [ZU PRÜFEN, Vorschlag ≤ 24 h] | abhängig von Backup-Frequenz | + +## 6. Geografische Trennung / Backup-Standort + +> **Offener Punkt:** Punkt #3 / FINMA verlangt angemessene Redundanz. Aktuell liegen Prod und Backup in der Infomaniak-Umgebung. **[ZU PRÜFEN: Liegen Snapshots/Backups in einer getrennten Infomaniak-Region oder einem getrennten Rechenzentrum? Falls nicht, geografisch getrennte Backup-Ablage als Massnahme aufnehmen.]** + +## 7. Tests und Überprüfung + +| Test | Häufigkeit | Status | +|---|---|---| +| Restore-Test (DB) | Vierteljährlich | siehe Dok 05 — neu einzuführen | +| Rollback-Übung | Halbjährlich | [ZU PRÜFEN] | +| LLM-Failover-Test | Halbjährlich | [ZU PRÜFEN] | +| BCP-Review (Aktualität) | Jährlich | neu | + +## 8. Kommunikation im Notfall + +| Rolle | Kontakt | +|---|---| +| Betrieb / DevOps (Server-Zugang) | Patrick Motsch — p.motsch@poweron.swiss | +| Drittdienste / Eskalation | Patrick Motsch — p.motsch@poweron.swiss | +| Kundeninformation (bei Vorfall) | siehe `07_Incident_Response_und_Meldewesen.md` | + +## 9. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Automatisiertes Uptime-Monitoring | [ZU PRÜFEN] | Einrichten + Alerting | +| Geografisch getrenntes Backup | [ZU PRÜFEN] | Klären / umsetzen | +| Dokumentierte Tests | Offen | Testplan etablieren | +| LLM-Failover dokumentieren | Offen | Konfiguration festhalten | diff --git a/e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md b/e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md new file mode 100644 index 0000000..e3e02ad --- /dev/null +++ b/e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md @@ -0,0 +1,84 @@ +# Incident Response und Meldewesen + +**Dokumenttyp:** Prozess +**Geltungsbereich:** Alle Sicherheits- und IT-Vorfälle der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / Geschäftsführung +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 19, 20, 27, 86 + +--- + +## 1. Zweck + +Dieser Prozess stellt eine schnelle, effektive und angemessene Reaktion auf Sicherheits- und IT-Vorfälle sicher und regelt die **Meldepflichten gegenüber Kunden** — insbesondere die für FINMA-Kunden kritische **24-Stunden-Meldung**. + +## 2. Vorfallklassifizierung (#86) + +| Stufe | Definition | Beispiel | +|---|---|---| +| **P1 — Kritisch** | Bestätigte Verletzung von Vertraulichkeit/Integrität/Verfügbarkeit kritischer Daten; erfolgreicher Cyberangriff | Datenabfluss, Ransomware, DB-Kompromittierung | +| **P2 — Hoch** | Teilweise erfolgreicher Angriff; wesentliche Störung ohne bestätigten Datenverlust | Eingedrungener, aber isolierter Angreifer; längerer Totalausfall | +| **P3 — Mittel** | Sicherheitsrelevantes Ereignis ohne unmittelbare Kundenauswirkung | Verdächtige Login-Versuche, einzelne Schwachstelle | +| **P4 — Niedrig** | Geringfügig, kein Kundenbezug | Fehlkonfiguration ohne Exposure | + +## 3. Reaktionsablauf + +```mermaid +flowchart TD + A[Vorfall erkannt] --> B[Erfassen & Klassifizieren P1-P4] + B --> C{Kundendaten betroffen?} + C -->|Ja| D[Sofortmassnahmen: Eindämmen, Beweise sichern] + C -->|Nein| E[Beheben & dokumentieren] + D --> F[Kunde benachrichtigen - Frist 24h bei P1/P2] + F --> G[Behebung & Root-Cause-Analyse] + E --> G + G --> H[Abschlussbericht & Lessons Learned] + H --> I[Ticket schliessen, Massnahmen tracken] +``` + +## 4. Meldepflichten gegenüber dem Kunden (#19, #20, #27) + +| Auslöser | Meldefrist | Empfänger | +|---|---|---| +| Erfolgreicher/teilw. erfolgreicher Cyberangriff auf kritische Daten/Prozesse (#19) | **≤ 24 h** nach Feststellung | Kunde (Sicherheitskontakt) | +| Wesentliche Verletzung Vertraulichkeit/Integrität/Verfügbarkeit (#19) | **≤ 24 h** | Kunde | +| Sonstige wesentliche nachteilige Entwicklungen (#20) | unverzüglich | Kunde | +| Verletzung des Berufsgeheimnisses (#27) | unverzüglich | Kunde | + +**Begründung der Frist:** Der Kunde (FINMA-Institut) muss seinerseits die FINMA fristgerecht informieren (Art. 29 FINMAG). Die 24-h-Meldung von PowerOn ermöglicht das. + +## 5. Meldeinhalt + +Jede Meldung an den Kunden enthält, soweit bekannt: Art des Vorfalls, betroffene Datenkategorien/-mengen, betroffene Tenants/Personen, wahrscheinliche Folgen, bereits ergriffene und geplante Massnahmen, Ansprechpartner. Folgeberichte nach Vereinbarung; Abschlussbericht mit Root-Cause-Analyse innert **72 h**. + +## 6. Meldewege und Kontakte + +| Funktion | Kontakt | +|---|---| +| Interner Incident-Koordinator | Patrick Motsch — p.motsch@poweron.swiss | +| Kundenmeldung (Kanal) | Telefon + verschlüsselte E-Mail an den im Vertrag definierten Sicherheitskontakt | +| Eskalation Drittdienste | Patrick Motsch — p.motsch@poweron.swiss | + +## 7. Beweissicherung (Forensik) + +Bei P1/P2 werden vor der Bereinigung betroffener Systeme Beweise gesichert: relevante Logs exportieren (siehe `11_Logging_und_Monitoring.md`), Zeitstempel und handelnde Personen festhalten, Snapshots/Abbilder erstellen wo möglich. + +## 8. Kleines Team — kompensierende Massnahmen + +Eine 7×24-Besetzung ist nicht vorhanden. Kompensierend: +- definierte Rufbereitschaft der Betriebsverantwortlichen, +- automatisiertes Alerting (siehe Dok 11), das Vorfälle auch ausserhalb der Arbeitszeit meldet, +- klare Eskalationskette. + +**[ZU PRÜFEN: Rufbereitschaft und Erreichbarkeit konkret festlegen.]** + +## 9. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Dokumentierter Incident-Prozess | Neu (dieses Dokument) | Intern freigeben & üben | +| Kundenmelde-Kontakte je Vertrag | Offen | Im Vertrag/AVV festhalten | +| Alerting für Out-of-hours | [ZU PRÜFEN] | siehe Dok 11 | +| Incident-Log / Register | Neu | Anlegen | diff --git a/e-compliance/Prozesse/legal/08_Change_Management.md b/e-compliance/Prozesse/legal/08_Change_Management.md new file mode 100644 index 0000000..53426e7 --- /dev/null +++ b/e-compliance/Prozesse/legal/08_Change_Management.md @@ -0,0 +1,62 @@ +# Change Management + +**Dokumenttyp:** Prozess +**Geltungsbereich:** Alle Änderungen an Produktivsystemen der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Entwicklung / Release-Verantwortlicher +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 81, 82, 83 +**Verweist auf:** `feature_release_bugfix.md` + +--- + +## 1. Bestehender Prozess (Basis) + +Der Kern des Change-Managements ist bereits in `feature_release_bugfix.md` dokumentiert und auditkonform aufgebaut: zentrale Erfassung, Priorisierung, Tech-Workshop, Feature-/Bugfix-Branches, Code-Review (Vier-Augen-Prinzip), Staging-Verifikation gegen Akzeptanzkriterien, Release in Produktion, versionierte Release Notes und CHANGELOG. Deployment erfolgt automatisiert über Forgejo-CI/CD. + +Dieses Dokument ergänzt die für das CACC fehlenden Aspekte (#82 Frozen Zones, #83 Konfigurationskonformität) und fasst die Risikobewertung/Genehmigung formal zusammen (#81). + +## 2. Change-Kategorien und Genehmigung (#81) + +| Kategorie | Beispiel | Risikobewertung | Genehmigung | +|---|---|---|---| +| **Standard** | Routine-Bugfix, kleinere Anpassung | gering | Code-Review (2. Entwickler) | +| **Normal** | Neues Feature, API-Änderung | mittel | Tech-Workshop + Review + Staging-Verifikation | +| **Major** | Neue Version, DB-Migration, Architekturänderung | hoch | Tech-Workshop + Review + Staging + Backup vor Deployment + explizite Release-Freigabe | +| **Emergency** | Kritischer Hotfix / Sicherheitspatch | situativ | Verkürzt: Fix + Review + sofortiges Deployment, Nachdokumentation innert 24 h | + +Jede Major-Änderung erfordert vor dem Deployment einen Export-Backup (siehe `datenbank-handling.md` / Dok 05). + +## 3. Frozen Zones und Maintenance Windows (#82) + +PowerOn ermöglicht kundenseitig definierte **Frozen Zones** (Zeiträume ohne Änderungen, z. B. Jahresabschluss einer Bank) und **Maintenance Windows**. + +| Element | Regelung | +|---|---| +| Frozen Zone | Auf Kundenwunsch im Vertrag/SLA definiert; in diesen Zeiträumen keine nicht-kritischen Deployments | +| Maintenance Window | Geplante Wartung wird mind. 5 Werktage im Voraus angekündigt | +| Notfalländerung in Frozen Zone | Nur bei kritischen Sicherheitsvorfällen, mit Kundeninformation | + +**[ZU PRÜFEN: Werden Frozen Zones aktuell technisch/organisatorisch berücksichtigt? Falls neu, als Prozessvorgabe etablieren.]** + +## 4. Standardisierte und sichere Konfiguration (#83) + +| Element | Regelung | Status | +|---|---|---| +| Konfigurationsdateien | `.env` pro Umgebung (`env-prod.env`, `env-int.env`), getrennt, nicht im Git | Umgesetzt | +| Infrastruktur als Code | [ZU PRÜFEN: Werden Server-Konfigurationen versioniert/reproduzierbar gehalten?] | [ZU PRÜFEN] | +| Konformitätskontrolle | Regelmässige Prüfung, dass Produktivkonfiguration dem Soll entspricht | [ZU PRÜFEN: etablieren] | +| Härtung | siehe `12_Netzwerk_und_Infrastruktursicherheit.md` | | + +## 5. Nachvollziehbarkeit (Auditnachweis) + +Jede Änderung ist nachvollziehbar über: Issue/Ticket, Feature-/Bugfix-Branch, Pull Request mit Review, CI/CD-Pipeline-Lauf in Forgejo, Commit-Historie, CHANGELOG-Eintrag. Rollbacks sind über Git/Forgejo dokumentiert (`bcm_runbook.md` §3). + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Change-Kategorisierung formalisiert | Neu | Übernehmen | +| Frozen Zones | [ZU PRÜFEN] | Prozess verankern | +| Konfigurations-Konformitätsprüfung | [ZU PRÜFEN] | Etablieren | diff --git a/e-compliance/Prozesse/legal/09_Patch_Management.md b/e-compliance/Prozesse/legal/09_Patch_Management.md new file mode 100644 index 0000000..8884846 --- /dev/null +++ b/e-compliance/Prozesse/legal/09_Patch_Management.md @@ -0,0 +1,52 @@ +# Patch Management + +**Dokumenttyp:** Prozess +**Geltungsbereich:** Betriebssystem, Laufzeitumgebung, Abhängigkeiten der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 78 + +--- + +## 1. Geltungsbereich + +| Ebene | Beispiel | Patch-Verantwortung | +|---|---|---| +| Managed Infrastruktur | VM-Host, PostgreSQL (Infomaniak) | Infomaniak (Managed) + Betrieb | +| Betriebssystem (Ubuntu) | Sicherheitsupdates | Betrieb | +| Laufzeit / Python | `requirements.txt`-Abhängigkeiten | Entwicklung/Betrieb | +| Anwendungsabhängigkeiten | Bibliotheken (z. B. LangChain, SDKs) | Entwicklung | + +## 2. Maximale Fristen (#78) + +Punkt #78 verlangt definierte Höchstdauern bis zum Einspielen von Patches: + +| Kritikalität | Beschreibung | Maximale Frist | +|---|---|---| +| Kritisch | Aktiv ausgenutzte / kritische Schwachstelle (CVSS ≥ 9) | **48 Stunden** | +| Hoch | CVSS 7,0–8,9 | 7 Tage | +| Mittel | CVSS 4,0–6,9 | 30 Tage | +| Niedrig | CVSS < 4,0 | nächstes Wartungsfenster | + +## 3. Ablauf + +1. **Erkennung:** Sicherheitsmeldungen verfolgen (Ubuntu Security, GitHub Dependabot/Advisories, Provider-Statusseiten). **[ZU PRÜFEN: Wird Dependabot o. ä. in Forgejo/Repo genutzt?]** +2. **Bewertung:** Kritikalität einstufen, betroffene Systeme bestimmen. +3. **Test:** Patch auf INT-Umgebung (`api-int.poweron.swiss`) einspielen und verifizieren. +4. **Freigabe & Deployment:** Über regulären Change-Prozess (Dok 08); bei kritischen Patches als Emergency-Change. +5. **Dokumentation:** Patch, Datum, Version im CHANGELOG/Ticket festhalten. + +## 4. OS- und Abhängigkeits-Updates (technisch) + +Abhängigkeiten werden beim Deployment via `pip install -r requirements.txt` aktualisiert (siehe `bcm_runbook.md`). OS-Patches: `apt`-Updates auf den VMs. **[ZU PRÜFEN: Automatische Sicherheitsupdates (unattended-upgrades) aktiv?]** + +## 5. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Definierte Patch-Fristen | Neu (dieses Dokument) | Übernehmen | +| Automatisches Vuln-Tracking (Dependabot) | [ZU PRÜFEN] | Aktivieren | +| Unattended-Upgrades OS | [ZU PRÜFEN] | Prüfen/aktivieren | +| Patch-Protokollierung | [ZU PRÜFEN] | Im CHANGELOG mitführen | diff --git a/e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md b/e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md new file mode 100644 index 0000000..ce7ec12 --- /dev/null +++ b/e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md @@ -0,0 +1,53 @@ +# Schwachstellenmanagement + +**Dokumenttyp:** Richtlinie & Prozess +**Geltungsbereich:** Alle für Kunden relevanten Systeme der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / Entwicklung +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 54, 59, 63, 84 + +--- + +## 1. Zweck + +Kontinuierliche Identifizierung, Bewertung, Behandlung und Nachverfolgung von Schwachstellen in den für Kunden relevanten Systemen. + +## 2. Identifizierungsmethoden (#63) + +| Methode | Häufigkeit | Status | +|---|---|---| +| Automatisiertes Dependency-Scanning (Bibliotheken) | kontinuierlich | [ZU PRÜFEN: Dependabot/Scanner aktiv?] | +| Schwachstellen-Scan der Server/Endpunkte | [ZU PRÜFEN, Vorschlag: quartalsweise] | [ZU PRÜFEN] | +| Penetrationstest durch unabhängige Dritte | jährlich | **[ZU PRÜFEN: bisher durchgeführt? Sonst erstmalig planen]** | +| Interne Code-Reviews | pro Change | Umgesetzt (siehe Dok 08) | + +## 3. Bewertung und Behandlung (#84) + +1. **Dokumentation:** Jede Schwachstelle wird mit Quelle, betroffenem System und CVSS-Score erfasst. +2. **Bewertung:** Einstufung nach Kritikalität. +3. **Massnahme:** Behebung über Patch- (Dok 09) bzw. Change-Prozess (Dok 08), nach den dort definierten Fristen. +4. **Nachverfolgung:** Offene Schwachstellen werden bis zur Behebung in einem Register getrackt. +5. **Reporting:** Status mindestens quartalsweise intern; auf Anfrage für berechtigte Kunden/Prüfer einsehbar. + +## 4. Unabhängige Audits (#54, #59) + +Punkt #54/#59 verlangen regelmässige unabhängige Audits und die Bereitstellung **vollständiger Auditberichte** (nicht nur Zertifikate). + +- **Aktuell:** [ZU PRÜFEN: Es liegen bisher keine externen Audit-/Pentest-Berichte vor.] +- **Massnahme:** Jährlichen externen Penetrationstest beauftragen; Bericht ablegen und berechtigten Kunden zugänglich machen. Behobene Schwachstellen dokumentieren. + +## 5. Schwachstellen-Register (Vorlage) + +| ID | Datum | System | Beschreibung | CVSS | Status | Behoben am | +|---|---|---|---|---|---|---| +| | | | | | | | + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Externer Pentest | [ZU PRÜFEN / fehlt] | Jährlich beauftragen | +| Dependency-Scanning | [ZU PRÜFEN] | Aktivieren | +| Schwachstellen-Register | Neu | Anlegen | diff --git a/e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md b/e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md new file mode 100644 index 0000000..bc7ee53 --- /dev/null +++ b/e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md @@ -0,0 +1,66 @@ +# Logging und Monitoring (Sicherheitsprotokollierung) + +**Dokumenttyp:** Konzept +**Geltungsbereich:** Protokollierung und Überwachung der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 88, 89, 90, 91, 92, 93, 94 + +--- + +## 1. Vorhandene Protokolle + +| Protokoll | Inhalt | Ort | +|---|---|---| +| Anwendungslog | App-Ereignisse | `/srv/gateway/shared/logs/log_app_YYYYMMDD.log` | +| Systemlog | Service `gateway` | `journalctl -u gateway` | +| AuthEvent (DB) | Login-Protokoll | DB-Tabelle (vom Export ausgeschlossen) | +| Export/Import-Log | DB-Operationen durch SysAdmins | serverseitig (siehe `datenbank-handling.md` §6) | +| CI/CD | Deployments | Forgejo | + +## 2. Protokollierung des Zugriffs auf Kundendaten (#88, #94) + +- Zugriffe auf Kundendaten im Klartext (z. B. DB-Export/Import) werden serverseitig geloggt. +- **Anforderung #94:** Eindeutige Identifizierung von Benutzerzugriffen auf Tenant-Ebene für forensische Analyse. +- **Offener Punkt:** Da der SSH-Zugang über den geteilten `ubuntu`-User läuft, ist die Personenzuordnung auf Server-Ebene aktuell eingeschränkt. → personalisierte Zugänge oder Sitzungsprotokollierung erforderlich (siehe Dok 02). **[ZU PRÜFEN/UMZUSETZEN]** + +## 3. Kundenzugang zu Protokollen (#88) + +Punkt #88 verlangt, dass Protokolle dem Kunden jederzeit (ggf. in Echtzeit) zur Verfügung stehen. + +**[ZU PRÜFEN: Können Kunden ihre Tenant-bezogenen Logs einsehen/exportieren? Falls nicht vorhanden, als Massnahme aufnehmen — z. B. Log-Export pro Mandant oder API.]** + +## 4. Automatische Analyse und Ereigniserkennung (#89, #90) + +| Element | Status | +|---|---| +| Etablierter Logging-/Monitoring-Prozess | [ZU PRÜFEN] | +| Automatische, proaktive Loganalyse (SIEM/Alerting) | **Offen** — kleines Team, kein SIEM | +| Anomalie-/Schwellwert-Alerting | [ZU PRÜFEN] | + +**Kompensierende Massnahme (kleines Team):** Statt eines vollwertigen SIEM ein leichtgewichtiges, automatisiertes Alerting (z. B. Log-Monitor, der bei definierten Mustern — fehlgeschlagene Logins, Fehlerraten, Health-Check-Ausfall — eine Benachrichtigung an die Rufbereitschaft sendet). **[ZU PRÜFEN/EINFÜHREN]** + +## 5. Schutz der Protokolldaten (#91) + +| Anforderung | Status / Massnahme | +|---|---| +| Schutz vor unbefugtem Zugriff | Logs auf Server, nur über privilegierten Zugang erreichbar | +| Schutz vor Veränderung/Löschung (Integrität) | **Offen** — Logs aktuell auf demselben Server, kein Write-Once. **Massnahme:** Logs an einen getrennten, append-only/write-once Speicher weiterleiten | +| Aufbewahrungsdauer | [ZU PRÜFEN, Vorschlag: mind. 12 Monate, sicherheitsrelevante Zugriffslogs 3 Jahre] | + +## 6. 7×24-Analyse (#92) und SOC-Schnittstellen (#93) + +- **#92 (7×24-Analyse):** Mit 2–5 Personen nicht als Vollbetrieb leistbar. Kompensierend: automatisiertes Alerting + Rufbereitschaft (siehe Dok 07). +- **#93 (Schnittstellen zum Kunden-SOC):** [ZU PRÜFEN: Kann Log-Streaming/Export an ein Kunden-SOC bereitgestellt werden (Syslog, API)? Falls nicht, als optionales Angebot dokumentieren.] + +## 7. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Personenbezogene Nachvollziehbarkeit (Tenant-Ebene) | Teilweise | personalisierte Zugänge / Sitzungslog | +| Log-Integritätsschutz | Offen | append-only/getrennter Speicher | +| Automatisches Alerting | Offen | einführen | +| Aufbewahrungsdauer definiert | Offen | festlegen | +| Kundenzugang zu Logs | [ZU PRÜFEN] | klären | diff --git a/e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md b/e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md new file mode 100644 index 0000000..56957a3 --- /dev/null +++ b/e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md @@ -0,0 +1,68 @@ +# Netzwerk- und Infrastruktursicherheit + +**Dokumenttyp:** Konzept +**Geltungsbereich:** Netzwerk, Server und Rechenzentrumsanbindung der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Betrieb / DevOps +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 95, 96, 97, 98, 99 + +--- + +## 1. Härtung und Basiskonfiguration (#95) + +| Element | Vorgabe | Status | +|---|---|---| +| Server-Härtung (Ubuntu) | nach anerkanntem Standard (z. B. CIS Benchmark) | [ZU PRÜFEN: angewendet?] | +| Nicht benötigte Dienste/Ports deaktiviert | ja | [ZU PRÜFEN] | +| Regelmässige Validierung der Basiskonfiguration | mind. jährlich | [ZU PRÜFEN: etablieren] | + +## 2. Netzwerksegmentierung und Mandantentrennung (#96) + +| Element | Beschreibung | Status | +|---|---|---| +| Trennung App / DB | Anwendung (`api.poweron.swiss`) und Datenbank (`db.poweron.swiss`) auf getrennten Hosts | Umgesetzt | +| Trennung Prod / Int | Produktiv- und Integrationsumgebung getrennt | Umgesetzt | +| Mandantentrennung (Multi-Tenancy) | Logische Trennung der Kundendaten innerhalb der Anwendung über Mandate/Berechtigungen | Umgesetzt (logisch) | +| Netzwerksegmentierung (Firewall-Zonen) | [ZU PRÜFEN: wie ist der Netzverkehr segmentiert?] | [ZU PRÜFEN] | + +> **Hinweis für regulierte Kunden:** Die Mandantentrennung erfolgt logisch (gemeinsame DB-Instanz, getrennte Mandate/Berechtigungen), nicht physisch pro Kunde. Das ist für SaaS üblich, sollte aber im Assessment transparent gemacht werden. + +## 3. Netzwerkschutzmassnahmen (#97) + +| Massnahme | Status | +|---|---| +| Firewall | [ZU PRÜFEN: Infomaniak-Firewall / OS-Firewall (ufw/iptables) konfiguriert?] | +| Web Application Firewall (WAF) | [ZU PRÜFEN: vorhanden?] | +| IDS/IPS (Intrusion Detection/Prevention) | [ZU PRÜFEN: vorhanden?] | +| TLS-Terminierung / Reverse Proxy | [ZU PRÜFEN: nginx o. ä.?] | + +## 4. Schutz vor netzwerkbasierten Angriffen / DDoS (#98) + +| Massnahme | Status | +|---|---| +| DDoS-Schutz | [ZU PRÜFEN: durch Infomaniak bereitgestellt?] | +| Anomalie-Erkennung im Datenverkehr | [ZU PRÜFEN] | +| Rate-Limiting | Teilweise (z. B. Export max. 2/Min — siehe `datenbank-handling.md`) | + +## 5. Physische Sicherheit und Versorgung (#99) + +Die physische Sicherheit wird durch den Rechenzentrumsbetreiber **Infomaniak** (Schweiz) gewährleistet: + +| Element | Zuständigkeit | Nachweis | +|---|---|---| +| Physische Zutrittskontrolle | Infomaniak | [ZU PRÜFEN: Infomaniak-Zertifikate/RZ-Doku beilegen, z. B. ISO 27001] | +| Stromversorgung / USV / Notstrom | Infomaniak | Infomaniak-Rechenzentren (CH) | +| Kühlung / Brandschutz | Infomaniak | Infomaniak-Dokumentation | + +**Massnahme:** Aktuelle Sicherheits-/Zertifizierungsnachweise von Infomaniak einholen und als Evidenz dem Assessment beilegen. + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Server-Härtung nach CIS | [ZU PRÜFEN] | Anwenden & dokumentieren | +| WAF / IDS / IPS | [ZU PRÜFEN] | Bedarf klären, ggf. einführen | +| Infomaniak-Zertifikate als Evidenz | Offen | Einholen | +| Firewall-Konfiguration dokumentieren | [ZU PRÜFEN] | Festhalten | diff --git a/e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md b/e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md new file mode 100644 index 0000000..5997482 --- /dev/null +++ b/e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md @@ -0,0 +1,67 @@ +# Datenaufbewahrung, Löschung und Legal Hold + +**Dokumenttyp:** Konzept +**Geltungsbereich:** Alle Kundendaten (Inhaltsdaten, Metadaten) der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Datenschutzverantwortlicher / Betrieb +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 1, 2, 38, 72 +**Verweist auf:** `datenbank-handling.md` + +--- + +## 1. Legal Hold (#1) + +Punkt #1 verlangt, dass der Kunde Inhalte (inkl. Metadaten) für rechtliche Zwecke aufbewahren und exportieren kann. + +| Funktion | Status | +|---|---| +| Daten eines Mandats vollständig exportieren (JSON) | Umgesetzt (Admin-UI / Script, siehe `datenbank-handling.md`) | +| Gezieltes „Einfrieren" einzelner Datensätze gegen Löschung (Legal Hold) | **[ZU PRÜFEN: technisch vorhanden? Sonst als Massnahme / manuelle Prozedur dokumentieren]** | +| Forensischer Export in lesbarem Format | Umgesetzt (JSON) | + +**Manuelle Legal-Hold-Prozedur (Übergang, falls keine Funktion vorhanden):** Auf Kundenanfrage wird ein vollständiger Export des betroffenen Mandats erstellt und gesichert abgelegt; betroffene Daten werden von automatischen Löschroutinen ausgenommen. + +## 2. Aufbewahrung und Löschung pro Datenkategorie (#2) + +Punkt #2 verlangt konfigurierbare Aufbewahrungsfristen pro Datenkategorie mit sicherer Löschung/Anonymisierung und Ausnahmemöglichkeit. + +| Datenkategorie (DB) | Aufbewahrung | Löschung | +|---|---|---| +| Chat-Konversationen (`poweron_chat`) | [ZU PRÜFEN / festlegen] | [ZU PRÜFEN: automatisch?] | +| Chatbot-Logs (`poweron_chatbot`) | [ZU PRÜFEN] | [ZU PRÜFEN] | +| RAG-Wissensdaten (`poweron_knowledge`) | bis Kunde löscht | manuell | +| Abrechnungsdaten (`poweron_billing`) | gesetzliche Frist (CH: 10 Jahre Geschäftsbücher) | nach Frist | +| Auth-/Login-Protokoll (`AuthEvent`) | [ZU PRÜFEN, Vorschlag: 12 Monate] | [ZU PRÜFEN] | + +> **Offener Punkt:** Aktuell besteht **keine automatische, kategorienbasierte Löschroutine**. Daten bleiben, bis ein Mandat/Datensatz manuell gelöscht wird. **Massnahme:** Aufbewahrungsfristen je Kategorie definieren und — soweit möglich — automatisierte Löschung/Anonymisierung implementieren, mit Ausnahmemechanismus (Legal Hold). + +## 3. Löschung bei Vertragsende (#38) + +Nach Vertragsende und erfolgter Datenmigration darf PowerOn keine lesbare Kopie der Berufsgeheimnisdaten mehr besitzen. + +| Schritt | Vorgehen | Status | +|---|---|---| +| Datenexport an Kunden | vollständiger JSON-Export | Umgesetzt | +| Löschung aus Produktiv-DB | Mandat und zugehörige Daten löschen | [ZU PRÜFEN: vollständige Löschroutine pro Mandat?] | +| Löschung aus Backups/Exports | Krypto-Löschung (Schlüssel vernichten) bzw. Löschung der Export-Dateien | [ZU PRÜFEN] | +| Löschung bei Subprozessoren | LLM-Provider: keine Speicherung (Zero-Retention) | [ZU PRÜFEN: vertraglich] | +| Löschbestätigung | schriftliche Bestätigung an Kunden | Neu — Vorlage erstellen | + +## 4. Schlüssellöschung (#72) + +Sichere Löschung von Verschlüsselungsschlüsseln am Ende des Lebenszyklus — siehe `04_Verschluesselung_und_Schluesselmanagement.md`. + +## 5. Datenschutz-Hinweise (aus bestehender Doku) + +Aus `datenbank-handling.md` übernommen und verbindlich: Export-Dateien enthalten alle Kundendaten, dürfen nicht auf unsicheren Speichern abgelegt werden und sind nach Gebrauch zu löschen. Zugriff auf Export/Import nur für SysAdmins, serverseitig geloggt. + +## 6. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Kategorienbasierte Aufbewahrungsfristen | Offen | Definieren | +| Automatische Löschung/Anonymisierung | Offen | Implementieren | +| Legal-Hold-Funktion | [ZU PRÜFEN] | Funktion oder manuelle Prozedur | +| Löschbestätigung bei Vertragsende | Neu | Vorlage erstellen | diff --git a/e-compliance/Prozesse/legal/14_Exit_und_Transition.md b/e-compliance/Prozesse/legal/14_Exit_und_Transition.md new file mode 100644 index 0000000..164d3f7 --- /dev/null +++ b/e-compliance/Prozesse/legal/14_Exit_und_Transition.md @@ -0,0 +1,73 @@ +# Exit- und Transitionsmanagement (Repatriierung) + +**Dokumenttyp:** Konzept & Plan +**Geltungsbereich:** Beendigung der Dienstleistung und Rückführung von Daten/Funktionen +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Geschäftsführung / Betrieb +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 4, 5, 6, 22 + +--- + +## 1. Zweck + +Dieser Plan stellt sicher, dass ein Kunde die ausgelagerten Funktionen geordnet zu sich oder einem Drittanbieter zurückführen (repatriieren) kann, ohne dass kritische Daten verloren gehen oder der Betrieb des Kunden gefährdet wird. + +## 2. Kündigungs- und Vorlauffristen (#4, #22) + +| Element | Regelung (gemäss AGB-Entwurf) | +|---|---| +| Ordentliche Kündigung | 3 Monate zum Vertragsmonatsende | +| Ankündigung neuer Subunternehmer | 30 Tage im Voraus, Widerspruchsrecht | +| Vorlauf für geordneten Rücktransport bei Kündigung durch PowerOn | ausreichend für Migration (siehe Weiterführungspflicht) | + +> Hinweis: Punkt #4 nennt als Richtwert ~6 Monate Vorlauf. Prüfen, ob 3 Monate Kündigungsfrist + Exportfenster + Weiterführungspflicht in Summe ausreichend sind, oder ob die Frist für regulierte Kunden vertraglich verlängert wird. + +## 3. Datenexport (#5) + +Der Kunde kann **jederzeit** alle relevanten Daten exportieren: + +| Datenart | Export | +|---|---| +| Inhaltsdaten (Mandate, Chats, Dokumente, Wissensdaten) | vollständiger JSON-Export (Admin-UI/Script) | +| Zugriffs-/Protokolldaten | [ZU PRÜFEN: AuthEvent/Logs separat exportierbar?] | +| Format | JSON (offen, maschinenlesbar, kein proprietäres Lock-in) | + +Der Export ist unabhängig von Zahlungsstreitigkeiten verfügbar (vgl. AGB §18.4). + +## 4. Weiterführungspflicht bei gescheiterter Repatriierung (#6) + +Sollte die Rückführung scheitern, führt PowerOn die Leistung für einen definierten Zeitraum weiter, damit der Kunde einen zweiten Versuch unternehmen kann. + +| Element | Regelung | +|---|---| +| Weiterführungsdauer | mind. 6 Monate (gemäss AGB §11.3) | +| Bedingungen | zu bisherigen Vertragsbedingungen | + +## 5. Transition-Ablauf (Runbook) + +```mermaid +flowchart TD + A[Kündigung / Exit-Entscheid] --> B[Exit-Plan aktivieren, Ansprechpartner benennen] + B --> C[Vollständiger Datenexport JSON] + C --> D[Übergabe an Kunde/Drittanbieter, Formatklärung] + D --> E[Verifikation: Daten vollständig & lesbar beim Kunden] + E --> F{Repatriierung erfolgreich?} + F -->|Nein| G[Weiterführung bis zu 6 Monate, 2. Versuch] + F -->|Ja| H[Löschung bei PowerOn inkl. Backups] + H --> I[Schriftliche Löschbestätigung an Kunden] +``` + +## 6. Löschung nach Exit + +Siehe `13_Datenaufbewahrung_Loeschung_LegalHold.md` Abschnitt 3. Nach erfolgreicher Migration: vollständige Löschung inkl. Backups und Bestätigung an den Kunden. + +## 7. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Exportfunktion | Umgesetzt | — | +| Export von Logs/Zugriffsdaten | [ZU PRÜFEN] | sicherstellen | +| Exit-Plan je regulierten Kunden | Neu | im Vertrag konkretisieren | +| Löschbestätigungs-Vorlage | Neu | erstellen | diff --git a/e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md b/e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md new file mode 100644 index 0000000..c152e8d --- /dev/null +++ b/e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md @@ -0,0 +1,57 @@ +# Sichere Softwareentwicklung (Secure SDLC) + +**Dokumenttyp:** Richtlinie +**Geltungsbereich:** Entwicklung der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Entwicklung +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 100, 101, 102 +**Verweist auf:** `feature_release_bugfix.md` + +--- + +## 1. Basis + +Der grundlegende Entwicklungs- und Release-Prozess (Anforderungen, Tech-Workshop mit Architektur-/Schnittstellenanalyse, Branches, Code-Review, Staging-Verifikation, Release Notes) ist in `feature_release_bugfix.md` dokumentiert. Dieses Dokument ergänzt die **sicherheitsspezifischen** Aspekte gemäss #100–#102. + +## 2. Sicherheit über den Entwicklungszyklus (#100) + +| Phase | Sicherheitsmassnahme | Status | +|---|---|---| +| Anforderungen | Sicherheits-/Datenschutzanforderungen je Feature im Tech-Workshop berücksichtigen | [ZU PRÜFEN: explizit Teil des Workshops?] | +| Design | Bedrohungsbetrachtung bei Architekturänderungen (betroffene Daten, Schnittstellen, Drittdienste) | Teilweise (Tech-Workshop prüft Abhängigkeiten zu Drittdiensten) | +| Implementierung | Sichere Coding-Praktiken, Secrets nicht im Code (`.env`-Trennung) | Umgesetzt | +| Tests & Review | Code-Review (Vier-Augen), Staging-Verifikation | Umgesetzt | +| Security-Tests | SAST/DAST/Dependency-Scan in der CI/CD-Pipeline | **[ZU PRÜFEN: in Forgejo-Pipeline integriert?]** | + +## 3. Standards und Frameworks (#101) + +| Standard | Anwendung | Status | +|---|---|---| +| OWASP Top 10 | Berücksichtigung gängiger Web-Schwachstellen in Reviews | [ZU PRÜFEN: als Review-Checkliste verankert?] | +| NIST / anerkannte Frameworks | Orientierung | [ZU PRÜFEN] | + +**Massnahme:** OWASP-Top-10-Checkliste als fester Bestandteil des Code-Reviews aufnehmen; ggf. automatisiertes SAST-Tool (z. B. Bandit für Python) in die Pipeline integrieren. + +## 4. Keine Produktivdaten in Entwicklung/Test (#102) — WICHTIG + +> **Direkter Konflikt mit aktueller Praxis:** `datenbank-handling.md` (Abschnitt 3) beschreibt das Übertragen von **Produktionsdaten auf die Testumgebung** als regulären Use-Case. Punkt #102 verlangt jedoch ausdrücklich, dass **produktive, dem Berufsgeheimnis unterliegende Daten NICHT für Entwicklung und Test** verwendet werden. + +**Erforderliche Massnahme (Entscheidung nötig):** + +| Option | Beschreibung | +|---|---| +| A — Verbot + Anonymisierung | Prod→Int-Migration nur mit vollständiger Anonymisierung/Pseudonymisierung der Inhaltsdaten. Klartext-Berufsgeheimnisdaten nie auf Int. | +| B — Synthetische Testdaten | Entwicklung/Test ausschliesslich mit synthetischen Testdaten (`poweron_test` ist bereits vom Export ausgeschlossen). | +| C — Streng kontrollierte Ausnahme | Prod-Daten auf Int nur in eng begrenzten, protokollierten Ausnahmefällen mit Kundengenehmigung. | + +**Empfehlung für FINMA-Kontext:** Option A oder B. Die aktuelle Beschreibung in `datenbank-handling.md` ist entsprechend anzupassen. + +## 5. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| SAST/DAST in Pipeline | [ZU PRÜFEN] | Integrieren | +| OWASP-Review-Checkliste | [ZU PRÜFEN] | Verankern | +| Prod-Daten in Test (#102) | **Konflikt** | Praxis ändern (Anonymisierung/synthetische Daten) + Doku anpassen | diff --git a/e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md b/e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md new file mode 100644 index 0000000..19a630e --- /dev/null +++ b/e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md @@ -0,0 +1,54 @@ +# Kapazitätsmanagement + +**Dokumenttyp:** Prozess +**Geltungsbereich:** Personal- und IT-Ressourcen der PORTA-Plattform +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Geschäftsführung / Betrieb +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 80 + +--- + +## 1. Zweck + +Sicherstellung ausreichender Personal- und IT-Kapazitäten für eine kontinuierliche, vereinbarungsgemässe Leistungserbringung. + +## 2. IT-Ressourcen-Kapazität + +| Ressource | Überwachung | Status | +|---|---|---| +| Server-Auslastung (CPU/RAM/Disk) | [ZU PRÜFEN: Monitoring vorhanden?] | [ZU PRÜFEN] | +| Datenbank (Grösse, Verbindungen) | Infomaniak Managed DB Metriken | [ZU PRÜFEN] | +| LLM-Provider-Kontingente (Rate Limits, Token-Budget) | Provider-Dashboards | [ZU PRÜFEN] | +| Speicher (Backups/Exports) | manuell | [ZU PRÜFEN] | + +**Massnahme:** Schwellwerte definieren (z. B. Disk > 80 %, DB-Verbindungen > 80 %) und Alerting einrichten (gemeinsam mit Dok 11). + +## 3. Personal-Kapazität (kleines Team) + +Bei 2–5 Personen ist die Personalkapazität ein erhöhtes Risiko (Schlüsselpersonen-Abhängigkeit). + +| Risiko | Kompensierende Massnahme | +|---|---| +| Ausfall einer Schlüsselperson | Dokumentation aller kritischen Prozesse (dieses Wiki), Zugangs-Notfallregelung | +| Wissenskonzentration | Vier-Augen-Prinzip, gemeinsame Reviews, dokumentierte Runbooks | +| Bei Wachstum | Kapazitätsplanung bei Neukunden-Onboarding | + +**[ZU PRÜFEN: Gibt es eine Vertretungs-/Notfallregelung für den alleinigen Server-Zugang?]** + +## 4. Kapazitäts-Review + +| Aktivität | Häufigkeit | +|---|---| +| Review IT-Auslastung | mind. quartalsweise | +| Review Personal-/Projektlast | laufend / bei Neukunden | +| Skalierungsentscheid Infrastruktur | bei Bedarf (Infomaniak skalierbar) | + +## 5. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| Ressourcen-Monitoring mit Schwellwerten | [ZU PRÜFEN] | Einrichten | +| Schlüsselpersonen-Vertretung | [ZU PRÜFEN] | Notfallregelung dokumentieren | +| Quartals-Review | Neu | etablieren | diff --git a/e-compliance/Prozesse/legal/17_Subunternehmer_Management.md b/e-compliance/Prozesse/legal/17_Subunternehmer_Management.md new file mode 100644 index 0000000..29b0f34 --- /dev/null +++ b/e-compliance/Prozesse/legal/17_Subunternehmer_Management.md @@ -0,0 +1,66 @@ +# Subunternehmer- und Unterauftragsverarbeiter-Management + +**Dokumenttyp:** Prozess +**Geltungsbereich:** Alle externen Dienste und Unterauftragsverarbeiter +**Version:** 1.0 +**Status:** Entwurf zur internen Freigabe +**Owner:** Patrick Motsch (Drittdienst-Verantwortlicher) +**Letzte Aktualisierung:** 02.06.2026 +**Deckt ab (CACC):** 16, 31, 48, 53 +**Verweist auf:** `drittanbieter-inventar.md` + +--- + +## 1. Basis + +Das vollständige Inventar aller Drittdienste ist in `drittanbieter-inventar.md` dokumentiert (Verantwortlicher: Patrick Motsch). Dieses Dokument ergänzt die **Compliance-Sicht**: Datenschutz-Status, Datenstandort, Widerspruchsrecht und Sanktionsprüfung. + +## 2. Compliance-Ergänzung zum Inventar (#48, #31) + +Für jeden Unterauftragsverarbeiter, der Inhaltsdaten verarbeitet, sind folgende Angaben zu führen (Ergänzung zum bestehenden Inventar): + +| Anbieter | Rolle | Datenstandort | AVV/DPA | EU-SCC (falls Drittland) | Zero-Retention | +|---|---|---|---|---|---| +| OpenAI (USA) | LLM (primär) | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | [ZU PRÜFEN: Enterprise/Opt-out] | +| Anthropic (USA) | LLM (alternativ) | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | [ZU PRÜFEN] | +| Mistral (EU/FR) | LLM (alternativ) | EU | [ZU PRÜFEN] | n/a (EU) | [ZU PRÜFEN] | +| Perplexity (USA) | LLM + Websuche | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | [ZU PRÜFEN] | +| Tavily (USA) | AI-Websuche | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | n/a | +| Infomaniak (CH) | Hosting/DB | Schweiz | [ZU PRÜFEN] | n/a (CH) | n/a | +| Google Cloud (USA) | STT/TTS/Translate | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | [ZU PRÜFEN] | +| Microsoft Azure (CH/EU) | Auth + E-Mail (CH-Region) | CH/EU | [ZU PRÜFEN] | [ZU PRÜFEN] | n/a | +| Stripe (USA/IE) | Payment | USA/EU | [ZU PRÜFEN] | [ZU PRÜFEN] | n/a | +| Twilio (USA) | SMS | USA | [ZU PRÜFEN] | [ZU PRÜFEN] | n/a | + +> **Wichtig für FINMA-Kunden:** Inhaltsdaten gehen an den primären LLM-Provider OpenAI (USA). Für regulierte Kunden ist zu klären, ob (a) ausreichende vertragliche Absicherung (AVV + SCC + Zero-Retention) vorliegt und/oder (b) ein auf EU/CH-LLM beschränkter Betrieb angeboten wird (z. B. Mistral EU oder CH-gehostetes Modell). + +## 3. Widerspruchsrecht des Kunden (#16) + +| Element | Regelung | +|---|---| +| Information über neuen wesentlichen Subunternehmer | 30 Tage im Voraus (gemäss AGB §12.2) | +| Widerspruchsfrist Kunde | 14 Tage, aus sachlichem Grund | +| Folge bei berechtigtem Widerspruch | ausserordentliches Kündigungsrecht des Kunden | + +## 4. Weitergabe der Pflichten (#53) + +Alle Subunternehmer werden vertraglich auf gleichwertige Sicherheits-, Datenschutz- und Vertraulichkeitspflichten verpflichtet. Kunden können diese bei Bedarf (mittelbar) auditieren. + +**[ZU PRÜFEN: Liegen die DPAs/AVVs der grossen Provider (OpenAI, Microsoft, Google, Stripe) abgelegt vor? Diese sind als Evidenz für das Assessment zentral.]** + +## 5. Sanktionsprüfung + +Subunternehmer werden vor Einsatz und periodisch gegen einschlägige Sanktionslisten geprüft. **[ZU PRÜFEN: erfolgt das? Sonst einführen.]** + +## 6. Pflege + +Das Inventar wird bei jeder Änderung (neuer/entfallender Dienst) aktualisiert; Verantwortlich: Patrick Motsch. Review mindestens jährlich. + +## 7. Stand der Umsetzung / Lücken + +| Thema | Status | Massnahme | +|---|---|---| +| AVV/SCC/Zero-Retention je Provider | [ZU PRÜFEN] | Verträge prüfen & ablegen | +| Compliance-Spalten im Inventar | Neu | ergänzen | +| Sanktionsprüfung | [ZU PRÜFEN] | einführen | +| EU/CH-only-LLM-Option für FINMA-Kunden | Offen | Entscheidung | diff --git a/e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md b/e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md new file mode 100644 index 0000000..f59cdba --- /dev/null +++ b/e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md @@ -0,0 +1,220 @@ +# Analyse: Rechtliche Aspekte und Best Practices + +**Dokumenttyp:** Befund- und Risikobericht (intern) +**Geltungsbereich:** Gesamtes e-compliance-Wiki (PORTA-Plattform) +**Version:** 1.0 +**Stand:** 01.02.2026 +**Erstellt für:** PowerOn AG, Birmensdorferstrasse 94, 8003 Zürich (CHE-491.960.195) +**Ansprechpartner:** Patrick Motsch — p.motsch@poweron.swiss + +> **Hinweis:** Dieser Bericht ersetzt keine anwaltliche Beratung. Er dokumentiert den Stand der Wiki-Dokumentation nach der Firmendaten-Anpassung und benennt Lücken sowie Widersprüche zwischen vertraglichen Zusicherungen (AGB) und beschriebenem Umsetzungsstand. + +--- + +## 1. Durchgeführte Anpassungen (01.02.2026) + +| Massnahme | Umfang | +|---|---| +| Rechtsträger | `PowerON GmbH` → **PowerOn AG** (CHE-491.960.195) | +| Markenschreibweise | `PowerON` → **PowerOn** in AGB und allen `legal/`-Dokumenten | +| Stammdaten AGB §1.1 | Birmensdorferstrasse 94, 8003 Zürich, p.motsch@poweron.swiss | +| Gerichtsstand AGB §23.2 | Zürich, Schweiz | +| Datumsfelder AGB | Stand / Gilt ab / Anhänge: **01.02.2026**; nächste Überprüfung: **01.02.2027** | +| Ansprechpartner/Rollen | Patrick Motsch in offenen Namens-/Kontaktfeldern (Dok. 01, 02, 06, 07) | + +**Nicht geändert (bewusst):** Inhaltliche AGB-Zusicherungen; technische `[ZU PRÜFEN]`-Fakten (MFA, At-Rest, Pentest-Nachweis etc.). + +--- + +## 2. Rechtlicher Rahmen + +### 2.1 Anwendbares Recht + +| Rechtsgebiet | Relevanz in der Dokumentation | +|---|---| +| **Schweizer DSG** (revDSG) | Primärrecht für Daten in der Schweiz; AGB §6.4, security-overview Kap. 9.2 | +| **DSGVO** | Anwendbar bei EU-Betroffenen / grenzüberschreitender Verarbeitung; Betroffenenrechte in security-overview | +| **FINMA-Rundschreiben 2018/3, 2023/1** | Auslagerung an Cloud/IT-Dienstleister; CACC-Mapping in `00_README_Prozessuebersicht.md` | +| **Bankgeheimnis (Art. 47 BankG)** | AGB §13.2; erhöhter Schutz für Berufsgeheimnisdaten | +| **Berufsgeheimnis StGB (Art. 321)** | Medizinische/sonstige Berufsgeheimnisse; gleiche Behandlung wie Bankdaten in AGB | +| **Schweizer Obligationenrecht / ZGB** | B2B-Verträge, AGB-Geltung, Gerichtsstand Zürich | + +### 2.2 Vertragshierarchie (AGB §1.4) + +1. Individueller Dienstleistungsvertrag +2. AVV (Auftragsverarbeitungsvertrag) +3. SLA +4. AGB +5. Anhänge A, B, C + +**Empfehlung:** Für FINMA-regulierte Kunden immer individuellen Vertrag + AVV abschliessen; AGB allein genügt regulatorisch nicht. + +### 2.3 Auftragsverarbeitung und Drittlandtransfers + +- **Speicherung Inhaltsdaten:** Schweiz (Infomaniak) — konsistent dokumentiert. +- **LLM-Verarbeitung:** Primär OpenAI (USA) — temporärer Datenabfluss; erfordert AVV/DPA, EU-SCC, TIA, Zero-Data-Retention (`17_Subunternehmer_Management.md`, AGB §7.2). +- **Neutralisierung:** Technisches Modul reduziert PII vor externem LLM-Call (`neutralisierung-detail.md`); nicht standardmässig für alle Tenants aktiv (`security-overview.md` Kap. 7.6). + +### 2.4 Melde- und Auditpflichten + +| Pflicht | AGB / CACC | Umsetzungsdokument | +|---|---|---| +| 24h-Meldung Cyberangriffe | AGB §14, CACC #19 | `07_Incident_Response_und_Meldewesen.md` | +| FINMA-Drittbegünstigung | AGB §17.2 | Prozess neu dokumentiert | +| Audit-Rechte (vollständige Berichte) | AGB §17.3 | `10_Schwachstellenmanagement.md` — Pentest fehlt | + +--- + +## 3. Best-Practice-Einordnung + +### 3.1 Stärken (implementiert / dokumentiert) + +| Bereich | Status | Nachweis | +|---|---|---| +| DSGVO-Betroffenenrechte (Self-Service) | Implementiert | `security-overview.md` Kap. 2 | +| Mandantentrennung (logisch) | Implementiert | `security-overview.md` Kap. 3 | +| RBAC | Implementiert | `security-overview.md` Kap. 4 | +| Parametrisierte DB-Queries, CSRF, Rate Limiting | Implementiert | `security-overview.md` Kap. 6 | +| Change Management / Vier-Augen | Dokumentiert | `feature_release_bugfix.md`, `08_Change_Management.md` | +| Fail-safe Neutralisierung | Konzept + Code-Karte | `neutralisierung-detail.md` | +| Drittanbieter-Inventar | Vollständig | `drittanbieter-inventar.md` | +| BCM-Runbook (operativ) | Vorhanden | `bcm_runbook.md` | +| JSON-Export / Exit | Vorhanden | `datenbank-handling.md`, `14_Exit_und_Transition.md` | + +### 3.2 Lücken (transparent benannt) + +| Thema | Risiko | Quelle | +|---|---|---| +| Keine ISO 27001-Zertifizierung | Mittel — AGB spricht von «Streben» | AGB §8.1, `01_Informationssicherheitsrichtlinie.md` | +| Kein granulares Consent-Management | Mittel (Art. 7 DSGVO) | `security-overview.md` Kap. 2.6 | +| PII-Filter nicht Standard | Hoch bei sensiblen Daten | `security-overview.md` Kap. 7.6 | +| Kein SIEM / 7×24-SOC | Hoch für FINMA-Kunden | `11_Logging_und_Monitoring.md` | +| Geteilter SSH-User `ubuntu` | Hoch — fehlende Personen-Nachvollziehbarkeit | `02_Zugriffsmanagement_IAM_PAM.md` | +| Log-Integrität (kein write-once) | Hoch | `11_Logging_und_Monitoring.md` | +| Kein externer Pentest-Nachweis | Hoch — widerspricht AGB | `10_Schwachstellenmanagement.md` | +| AVV/SCC bei LLM-Providern ungeklärt | Hoch | `17_Subunternehmer_Management.md` | + +### 3.3 OWASP / ISO 27001 + +Die Plattform adressiert OWASP Top 10 präventiv (`security-overview.md` Kap. 9.3), ohne formale Zertifizierung. Die `legal/`-Prozesse bilden eine **Grundlage für ISMS** nach ISO 27001, sind aber grösstenteils im Status «Entwurf» mit vielen `[ZU PRÜFEN]`-Markierungen. + +--- + +## 4. Widersprüche: AGB-Zusicherung vs. dokumentierter Umsetzungsstand + +> Die AGB wurden inhaltlich **nicht** abgeschwächt. Die folgenden Punkte sind **Compliance-Risiken**, solange der Umsetzungsstand nicht angeglichen wird. + +### 4.1 Verschlüsselung at-rest (AGB §9.1, Anhang C) + +| | AGB | Dokumentierter Stand | +|---|---|---| +| Zusage | Alle Inhaltsdaten AES-256 at rest | `[ZU PRÜFEN]` Infomaniak DB; JSON-Exporte **unverschlüsselt** | +| Referenz | `20260603_PowerON_AGB_v1.0_1.md` §9.1 | `04_Verschluesselung_und_Schluesselmanagement.md` §2; `security-overview.md` §5.1 (nur Secrets) | + +**Empfehlung:** At-Rest bei Infomaniak verifizieren und dokumentieren; Export-Verschlüsselung (AES-256/GPG) einführen; ggf. AGB-Formulierung präzisieren («Inhaltsdaten in der Produktiv-DB» vs. «Backup-Exporte»). + +### 4.2 Penetrationstests (AGB §8.4) + +| | AGB | Dokumentierter Stand | +|---|---|---| +| Zusage | Jährlich, unabhängig, volle Berichte auf Anfrage | «Bisher keine externen Pentest-Berichte» | +| Referenz | AGB §8.4 | `10_Schwachstellenmanagement.md` §4 | + +**Empfehlung:** Jährlichen Pentest beauftragen; Bericht archivieren; oder AGB-Frist erst nach erstem Test aktivieren. + +### 4.3 RTO / RPO (AGB Anhang B) + +| | AGB | Dokumentierter Stand | +|---|---|---| +| Zusage | RTO ≤ 4 h, RPO ≤ 1 h | Wöchentliche Export-Praxis; RPO eher ≤ 24 h | +| Referenz | Anhang B | `05_Backup_und_Wiederherstellung.md` §4 | + +**Empfehlung:** Backup-Frequenz erhöhen (täglich inkrementell) oder SLA/AGB-Werte an reale Kapazität anpassen. + +### 4.4 Geografisch getrenntes Backup-RZ (AGB §11.2) + +| | AGB | Dokumentierter Stand | +|---|---|---| +| Zusage | Backup-RZ in der Schweiz, geografisch getrennt | `[ZU PRÜFEN]` — nur Infomaniak-Umgebung | +| Referenz | AGB §11.2 | `06_Business_Continuity_und_Disaster_Recovery.md` §6 | + +**Empfehlung:** Infomaniak-Region/Snapshot-Standort klären; Evidenz beilegen. + +### 4.5 MFA und Logging (AGB Anhang C) + +| | AGB | Dokumentierter Stand | +|---|---|---| +| Zusage | MFA verpflichtend; Logs 3 Jahre, write-once, Kundenzugang | MFA `[ZU PRÜFEN]`; kein write-once; SIEM offen | +| Referenz | Anhang C | `02_Zugriffsmanagement_IAM_PAM.md`, `11_Logging_und_Monitoring.md` | + +**Empfehlung:** MFA auf SysAdmin/SSH erzwingen; Log-Shipping auf append-only Storage; leichtgewichtiges Alerting. + +### 4.6 Produktivdaten in Testumgebung (CACC #102) + +| | Anforderung | Dokumentierter Stand | +|---|---|---| +| Verbot | Keine Berufsgeheimnisdaten in Dev/Test | Prod→Int-Migration als Regelfall beschrieben | +| Referenz | `15_Sichere_Softwareentwicklung_SDLC.md` §4 | `datenbank-handling.md` §3 | + +**Empfehlung:** Option A (Anonymisierung) oder B (synthetische Daten); `datenbank-handling.md` anpassen — **kritisch für FINMA-Assessment**. + +### 4.7 Anhang A: Rechenzentrumsbetreiber + +| | AGB Anhang A | Übrige Dokumente | +|---|---|---| +| Stand | `[RZ-Anbieter primär]` Platzhalter | **Infomaniak** (Schweiz) klar benannt | +| Referenz | AGB Anhang A §A.1 | `00_README`, `drittanbieter-inventar.md` | + +**Empfehlung:** Anhang A mit Infomaniak (primär + DR-Standort) füllen — keine inhaltliche AGB-Änderung der Zusagen, nur Vervollständigung. + +--- + +## 5. Priorisierte Massnahmenliste + +| Prio | Massnahme | Aufwand | Rechtliches Risiko | +|:---:|---|---|---| +| P1 | AVV/DPA + SCC + Zero-Retention mit OpenAI (und weiteren LLM-Providern) abschliessen und ablegen | Mittel | Hoch | +| P1 | Prod-Daten in Test: Prozess ändern (Anonymisierung/synthetisch) | Mittel | Hoch (FINMA) | +| P1 | Backup-Exporte verschlüsseln | Gering | Hoch | +| P2 | Externen Pentest beauftragen (jährlich) | Mittel | Hoch (AGB §8.4) | +| P2 | MFA auf privilegierten Zugängen | Gering | Mittel | +| P2 | RTO/RPO mit Backup-Frequenz abgleichen | Mittel | Mittel (Vertrag) | +| P2 | Anhang A: Infomaniak eintragen | Gering | Gering | +| P3 | Personalisierte SSH-Accounts oder Sitzungsprotokollierung | Mittel | Mittel | +| P3 | Log-Integrität (append-only / separates Log-Storage) | Mittel | Mittel | +| P3 | Automatisches Uptime-Monitoring + Alerting | Gering | Mittel | +| P3 | Strafregisterauszug / NDAs für alle Mitarbeitenden verifizieren | Gering | Mittel | +| P3 | ISO-27001-Zertifizierung planen oder AGB-Formulierung «strebt an» beibehalten | Hoch | Niedrig (wenn ehrlich kommuniziert) | + +--- + +## 6. Offene Punkte zur Klärung (Rückfragen an PowerOn AG) + +Die folgenden Punkte konnten aus den Dokumenten **nicht** verifiziert werden und sollten intern geklärt werden: + +1. **Telefonnummer** für Incident-Rufbereitschaft (aktuell nur E-Mail Patrick Motsch). +2. **Trennung Rollen:** Patrick Motsch trägt alle Rollen (CISO, DPO, GF, DevOps) — für Audits ggf. formale Zuordnung oder externe DPO-Unterstützung erwägen. +3. **Infomaniak:** At-Rest-Verschlüsselung, DR-Region, ISO-Zertifikate als PDF beilegen. +4. **OpenAI:** Enterprise-Tier mit Training-Opt-out — Vertragsversion und Speicherort dokumentieren. +5. **Schweizer/EU-only LLM** für FINMA-Kunden: Ist Mistral EU oder self-hosted Modell produktiv anbietbar? +6. **Legal Hold:** Technische Funktion vorhanden oder nur manuelle Prozedur? +7. **Kundenzugang zu Logs:** API/Export pro Mandant geplant? +8. **BYOK:** Angebot gewünscht für regulierte Kunden? +9. **Rechtliche Prüfung AGB** durch Fachanwalt vor Veröffentlichung gegenüber Bankkunden. +10. **Weitere Ansprechpartner** bei Team-Wachstum (Vertretung Schlüsselperson). + +--- + +## 7. Dokumentenübersicht (Stand nach Anpassung) + +| Datei | Rolle | +|---|---| +| `20260603_PowerON_AGB_v1.0_1.md` | Vertragsgrundlage B2B (Stammdaten aktualisiert) | +| `security-overview.md` | Kundeninformation Sicherheit/Datenschutz | +| `neutralisierung-detail.md` | Technisches Datenschutz-Modul | +| `legal/00`–`17` | CACC/FINMA-Prozessdokumentation | +| **`legal/18_Analyse_Recht_und_BestPractice.md`** | Dieser Befundbericht | + +--- + +*Nächste planmässige Überprüfung dieses Berichts: 01.02.2027 oder nach wesentlicher Änderung an AGB, Infrastruktur oder regulatorischen Anforderungen.*