# Anlage 5 zum AVV: Incident-Response-Plan

**Vorfallreaktionsplan für Datenschutz- und Sicherheitsvorfälle**

**Auftragnehmer:** fmhconsulting · Qognio — Finn Malte Hinrichsen
**Stand:** April 2026
**Version:** 1.0

---

## 1. Zweck und Geltungsbereich

**(1)** Dieser Incident-Response-Plan (IRP) definiert das Verfahren zur Erkennung, Bewertung, Eindämmung, Behebung und Nachbereitung von Sicherheits- und Datenschutzvorfällen im Zusammenhang mit dem Qognio Bot-Service.

**(2)** Er dient der Erfüllung der Meldepflichten gemäß Art. 33 und 34 DSGVO sowie der vertraglichen Pflichten gemäß § 8 des AVV.

**(3)** Der Plan gilt für alle Vorfälle, die die Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten des Auftraggebers betreffen oder betreffen könnten.

---

## 2. Definitionen

**Sicherheitsvorfall:** Jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationssystemen oder Daten gefährdet oder beeinträchtigt.

**Datenschutzverletzung (Data Breach):** Eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von bzw. zum unbefugten Zugang zu personenbezogenen Daten führt (Art. 4 Nr. 12 DSGVO).

**Beinahe-Vorfall (Near Miss):** Ein Ereignis, das unter anderen Umständen zu einem Sicherheitsvorfall hätte führen können, aber durch bestehende Schutzmaßnahmen verhindert wurde.

---

## 3. Rollen und Verantwortlichkeiten

### 3.1 Incident-Response-Team

| Rolle | Verantwortlicher | Kontakt | Aufgaben |
|-------|-----------------|---------|----------|
| **Incident Manager** | Finn Malte Hinrichsen | info@qognio.com, +49 176 88499977 | Gesamtkoordination, Entscheidung über Klassifizierung und Eskalation, Kommunikation mit Auftraggeber |
| **Technischer Leiter** | Finn Malte Hinrichsen | info@qognio.com | Technische Analyse, Eindämmung, Behebung, forensische Sicherung |
| **Datenschutzkoordinator** | Finn Malte Hinrichsen | datenschutz@qognio.com | Bewertung datenschutzrechtlicher Implikationen, Unterstützung bei Meldungen an Aufsichtsbehörde |

### 3.2 Externe Ansprechpartner

| Rolle | Organisation | Kontakt |
|-------|-------------|---------|
| Auftraggeber (Verantwortlicher) | _[Kundenname]_ | _[Kontaktdaten lt. § 5 Abs. 4 AVV]_ |
| Zuständige Aufsichtsbehörde | Hamburgischer Beauftragter für Datenschutz und Informationsfreiheit | mailbox@datenschutz.hamburg.de |

---

## 4. Klassifizierung von Vorfällen

### 4.1 Severity-Stufen

| Severity | Bezeichnung | Beschreibung | Beispiele |
|----------|------------|-------------|----------|
| **Severity 1 — Kritisch** | Akute Datenschutzverletzung mit hohem Risiko | Bestätigte Offenlegung, Verlust oder Vernichtung personenbezogener Daten mit hohem Risiko für die Rechte und Freiheiten betroffener Personen | Ransomware-Angriff mit Datenexfiltration; unbefugter Zugriff auf HR-Daten durch Externe; Verlust unverschlüsselter Backups |
| **Severity 2 — Hoch** | Datenschutzverletzung mit Risiko | Bestätigte Verletzung des Schutzes personenbezogener Daten mit Risiko für betroffene Personen | Mandantenübergreifender Datenzugriff durch Softwarefehler; unbeabsichtigte Offenlegung von Daten an falsche Mandanten; Kompromittierung eines Admin-Accounts |
| **Severity 3 — Mittel** | Sicherheitsvorfall ohne bestätigte Datenschutzverletzung | Sicherheitsrelevantes Ereignis, bei dem eine Datenschutzverletzung nicht ausgeschlossen werden kann | Ungewöhnliche Zugriffsversuche; erkannter aber abgewehrter Angriff; fehlerhafte Zugriffskonfiguration (ohne bestätigten Zugriff) |
| **Severity 4 — Niedrig** | Beinahe-Vorfall oder geringfügiger Sicherheitsvorfall | Ereignis mit geringem oder keinem Risiko für personenbezogene Daten | Fehlgeschlagene Brute-Force-Versuche (von fail2ban blockiert); Phishing-E-Mail erkannt; geplante Wartungsunterbrechung |

### 4.2 Erstbewertungskriterien

Die Klassifizierung erfolgt anhand folgender Kriterien:

- Wurden personenbezogene Daten tatsächlich kompromittiert?
- Welche Kategorien und welchen Umfang an Daten betrifft der Vorfall?
- Handelt es sich um besonders sensible Daten (HR-Daten, Bewerberdaten)?
- Wie viele betroffene Personen sind (potenziell) betroffen?
- Besteht ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen?
- Ist der Vorfall bereits eingedämmt oder besteht er fort?

---

## 5. Reaktionsverfahren

### 5.1 Phase 1: Erkennung und Meldung

**Zeitrahmen:** Unverzüglich

**(1)** Sicherheitsvorfälle können erkannt werden durch:
- Automatisiertes Monitoring und Alarmierung (24/7)
- Audit-Log-Analyse
- Manuelle Feststellung durch den Auftragnehmer
- Meldung durch den Auftraggeber oder betroffene Personen
- Externe Hinweise (z. B. CERT, Sicherheitsforscher)

**(2)** Jeder erkannte oder vermutete Vorfall wird unverzüglich an den Incident Manager gemeldet.

**(3)** Der Incident Manager eröffnet ein Vorfallprotokoll mit:
- Eindeutiger Vorfall-ID
- Zeitpunkt der Entdeckung
- Beschreibung des Vorfalls
- Erstmelder
- Vorläufige Klassifizierung

### 5.2 Phase 2: Erstbewertung und Klassifizierung

**Zeitrahmen:** Innerhalb von 2 Stunden nach Erkennung

**(1)** Der Incident Manager bewertet den Vorfall anhand der Kriterien in Abschnitt 4.2 und legt die Severity-Stufe fest.

**(2)** Bei Severity 1 und 2 wird der Auftraggeber **unverzüglich**, spätestens innerhalb von **24 Stunden** nach Bekanntwerden informiert (§ 8 Abs. 1 AVV). Die Erstmeldung enthält:
- Beschreibung des Vorfalls
- Vorläufige Klassifizierung
- Sofort ergriffene Maßnahmen
- Erwarteter Zeitrahmen für weitere Informationen

### 5.3 Phase 3: Eindämmung

**Zeitrahmen:** Unverzüglich nach Klassifizierung

| Severity | Maßnahmen |
|----------|----------|
| Severity 1 | Sofortige Isolation betroffener Systeme; Sperrung kompromittierter Zugänge; Forensische Sicherung; Aktivierung aller Teammitglieder |
| Severity 2 | Isolation betroffener Mandanten-Container; Sperrung verdächtiger Zugänge; Sicherung relevanter Logs |
| Severity 3 | Verstärktes Monitoring; Überprüfung und Härtung betroffener Konfigurationen |
| Severity 4 | Dokumentation; reguläre Bearbeitung im nächsten Wartungsfenster |

### 5.4 Phase 4: Untersuchung und Analyse

**Zeitrahmen:** Parallel zur Eindämmung, Abschluss abhängig von Severity

**(1)** Forensische Analyse:
- Sicherung aller relevanten Logs und Systemzustände
- Bestimmung des Angriffsvektor bzw. der Ursache
- Ermittlung des Umfangs der Kompromittierung
- Identifikation aller betroffenen Daten und Personen
- Timeline-Erstellung

**(2)** Die Analyseergebnisse werden im Vorfallprotokoll dokumentiert.

### 5.5 Phase 5: Behebung und Wiederherstellung

**Zeitrahmen:** Nach Abschluss der Eindämmung

**(1)** Beseitigung der Ursache (Patching, Konfigurationsänderung, Zugriffswiderruf)

**(2)** Wiederherstellung betroffener Systeme aus sauberen Backups (sofern erforderlich)

**(3)** Verifikation der Systemintegrität vor Wiederinbetriebnahme

**(4)** Schrittweise Wiederherstellung des Normalbetriebs mit verstärktem Monitoring

### 5.6 Phase 6: Benachrichtigung

#### 5.6.1 Meldung an den Auftraggeber

| Severity | Zeitrahmen | Kanal |
|----------|-----------|-------|
| Severity 1 | Unverzüglich, spätestens **24 Stunden** | E-Mail + Telefonanruf |
| Severity 2 | Spätestens **24 Stunden** | E-Mail + Telefonanruf |
| Severity 3 | Spätestens **48 Stunden** | E-Mail |
| Severity 4 | Im nächsten regulären Statusbericht | E-Mail |

Die Meldung enthält die in § 8 Abs. 2 AVV genannten Informationen.

#### 5.6.2 Meldung an die Aufsichtsbehörde

**(1)** Die Meldung an die zuständige Aufsichtsbehörde obliegt dem **Auftraggeber als Verantwortlichem** gemäß Art. 33 DSGVO. Die Meldung muss innerhalb von **72 Stunden** nach Bekanntwerden der Verletzung erfolgen.

**(2)** Der Auftragnehmer unterstützt den Auftraggeber bei der Meldung, indem er alle erforderlichen Informationen gemäß Art. 33 Abs. 3 DSGVO bereitstellt:
- Art der Datenschutzverletzung
- Kategorien und ungefähre Zahl der betroffenen Personen
- Kategorien und ungefähre Zahl der betroffenen Datensätze
- Name und Kontaktdaten der Anlaufstelle
- Wahrscheinliche Folgen
- Ergriffene und vorgeschlagene Maßnahmen

**(3)** Der Auftragnehmer stellt diese Informationen dem Auftraggeber so rechtzeitig zur Verfügung, dass dieser seiner 72-Stunden-Meldefrist nachkommen kann.

#### 5.6.3 Benachrichtigung betroffener Personen

Die Entscheidung über die Benachrichtigung betroffener Personen gemäß Art. 34 DSGVO obliegt dem **Auftraggeber als Verantwortlichem**. Der Auftragnehmer unterstützt auf Anfrage bei der Ermittlung der betroffenen Personen und der Formulierung der Benachrichtigung.

---

## 6. Eskalationspfade

### 6.1 Eskalationsmatrix

```
Erkennung des Vorfalls
        │
        ▼
Erstbewertung (Incident Manager)
        │
        ├── Severity 4 ──► Dokumentation, reguläre Bearbeitung
        │
        ├── Severity 3 ──► Verstärktes Monitoring
        │                   Meldung an AG innerhalb 48h
        │
        ├── Severity 2 ──► Sofortige Eindämmung
        │                   Meldung an AG innerhalb 24h
        │                   Unterstützung bei Meldung an Aufsichtsbehörde
        │
        └── Severity 1 ──► Sofortige Isolation
                            Meldung an AG unverzüglich (max. 24h)
                            Unterstützung bei Meldung an Aufsichtsbehörde (72h)
                            Ggf. Benachrichtigung betroffener Personen (Art. 34 DSGVO)
```

### 6.2 Erreichbarkeit

| Zeitraum | Erreichbarkeit | Reaktionszeit |
|----------|---------------|---------------|
| Geschäftszeiten (Mo–Fr, 9–18 Uhr) | E-Mail, Telefon | Severity 1/2: 1 Stunde; Severity 3/4: 4 Stunden |
| Außerhalb Geschäftszeiten | Monitoring-Alarmierung, E-Mail | Severity 1: 2 Stunden; Severity 2: 4 Stunden |

---

## 7. Dokumentation

### 7.1 Vorfallprotokoll

Jeder Vorfall wird in einem Vorfallprotokoll dokumentiert, das mindestens folgende Informationen enthält:

| Feld | Beschreibung |
|------|-------------|
| Vorfall-ID | Eindeutige Kennung (Format: INC-YYYY-NNN) |
| Severity | Klassifizierung (1–4) |
| Zeitpunkt der Entdeckung | Datum und Uhrzeit |
| Zeitpunkt der Meldung an AG | Datum und Uhrzeit |
| Beschreibung | Art und Umfang des Vorfalls |
| Betroffene Systeme | Systeme, Container, Mandanten |
| Betroffene Daten | Datenkategorien, geschätzter Umfang |
| Betroffene Personen | Kategorien, geschätzte Anzahl |
| Ursache | Root Cause (nach Analyse) |
| Ergriffene Maßnahmen | Chronologische Auflistung |
| Status | Offen / In Bearbeitung / Geschlossen |
| Abschlussdatum | Datum der Schließung |
| Lessons Learned | Erkenntnisse und Verbesserungen |

### 7.2 Aufbewahrung

Vorfallprotokolle werden für die Dauer von **3 Jahren** nach Abschluss des Vorfalls aufbewahrt (vgl. Löschkonzept, Anlage 3).

---

## 8. Post-Incident-Analyse

### 8.1 Durchführung

**(1)** Nach jedem Vorfall der Severity 1–3 wird eine Post-Incident-Analyse (Lessons Learned) durchgeführt.

**(2)** Die Analyse erfolgt innerhalb von **10 Werktagen** nach Abschluss des Vorfalls und umfasst:

- Chronologische Rekonstruktion des Vorfalls
- Bewertung der Wirksamkeit der Reaktion
- Identifikation von Verbesserungspotenzialen
- Ableitung konkreter Maßnahmen mit Verantwortlichkeiten und Fristen
- Überprüfung, ob die Risikobewertung der DSFA (Anlage 4) angepasst werden muss

**(3)** Der Auftraggeber erhält auf Anfrage eine Zusammenfassung der Post-Incident-Analyse.

### 8.2 Verbesserungsmaßnahmen

Identifizierte Verbesserungsmaßnahmen werden:
- Mit Priorität, Verantwortlichem und Frist versehen
- In die regelmäßige Überprüfung der TOMs (Anlage 1) einbezogen
- Bei der nächsten Überprüfung der DSFA (Anlage 4) berücksichtigt
- Im nächsten regulären Bericht an den Auftraggeber kommuniziert

---

## 9. Tests und Übungen

**(1)** Der Incident-Response-Plan wird mindestens **jährlich** auf Aktualität überprüft.

**(2)** Es wird mindestens **einmal jährlich** eine Übung (Tabletop Exercise) durchgeführt, um die Wirksamkeit des Plans zu testen.

**(3)** Die Ergebnisse der Übungen werden dokumentiert und fließen in die Aktualisierung des Plans ein.

---

## 10. Zusammenspiel mit anderen Dokumenten

| Dokument | Bezug |
|----------|-------|
| AVV (§ 8) | Vertragliche Meldepflichten bei Datenschutzverletzungen |
| Anlage 1 (TOMs) | Präventive Sicherheitsmaßnahmen, Abschnitt 4.2 |
| Anlage 3 (Löschkonzept) | Aufbewahrungsfristen für Incident-Dokumentation |
| Anlage 4 (DSFA) | Risikobewertung und Maßnahmen zur Risikominimierung |
| AI-Act-Konformitätsdokumentation (Dokument 10) | Cybersecurity-Anforderungen, Logging-Anforderungen |

---

**Letzte Überprüfung:** April 2026
**Nächste planmäßige Überprüfung:** April 2027

---

_Dieser Incident-Response-Plan ist Bestandteil des Auftragsverarbeitungsvertrages (AVV) zwischen den Parteien._