wiki/e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md
Stephan Schellworth 9f5f8bfc11 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 <cursoragent@cursor.com>
2026-06-03 08:50:34 +02:00

3.8 KiB

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