# 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 |