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