Plan zur Reaktion auf Sicherheitsvorfälle

QR Branding API – Art. 33-34 DSGVO

---

1. Ziel

Festlegung eines strukturierten Verfahrens zur Erkennung von, Reaktion auf und Meldung von Sicherheitsverletzungen, die personenbezogene Daten betreffen, im Einklang mit den Anforderungen von Art. 33 DSGVO (Meldung an die Aufsichtsbehörde) und Art. 34 (Benachrichtigung der betroffenen Personen).

---

2. Begriffsbestimmungen

---

3. Einstufung von Vorfällen

Stufe 1 – Kritisch (Verletzung des Schutzes personenbezogener Daten)

• Offenlegung von QR-Inhalten mit personenbezogenen Daten (vCards, E-Mail-Adressen, Telefonnummern)
• Offenlegung von KI-Prompts der Nutzer
• Abfluss von API-Schlüsseln (RapidAPI, LLM-Anbieter)
• Unbefugter Zugriff auf Application Insights mit Nutzerdaten
• Kompromittierung der Lieferkette (bösartige NuGet-Abhängigkeit)

Stufe 2 – Hoch (Sicherheitsvorfall ohne bestätigte Beteiligung personenbezogener Daten)

• Erfolgreiche Ausnutzung einer Schwachstelle (SSRF, Injection usw.)
• Anhaltende Dienstverweigerung (DoS)
• Kompromittierung der CI/CD-Pipeline (GitHub Actions)
• Unbefugter Zugriff auf Azure App Settings oder Secrets
• Auffälliges Verhalten eines LLM-Anbieters (Antworten mit Daten anderer Nutzer)

Stufe 3 – Mittel (eingedämmter Vorfall)

• Angriffsversuche, die vom Rate-Limiting erkannt und blockiert wurden
• Erkannte Schwachstellenscans
• Abhängigkeit mit veröffentlichter CVE (keine bestätigte Ausnutzung)
• Leistungseinbußen des Dienstes durch Ressourcenmissbrauch

Stufe 4 – Niedrig (informatives Ereignis)

• Fehlgeschlagene Authentifizierungsversuche
• Normales Auslösen von Rate-Limits
• Leistungswarnungen (Kaltstarts, Timeouts)

---

4. Reaktionsverfahren

Phase 1: Erkennung und Triage (T0 → T0+1h)

Phase 2: Eindämmung (T0+1h → T0+4h)

Phase 3: Meldung nach DSGVO (falls zutreffend)

Art. 33 – Meldung an die Aufsichtsbehörde (binnen 72h ab T0)

Nur erforderlich, wenn die Verletzung zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.

Inhalt der Meldung:

1. Art der Verletzung (welche Daten, geschätzte Zahl betroffener Personen)
2. Kontaktdaten des Verantwortlichen
3. Wahrscheinliche Folgen der Verletzung
4. Ergriffene oder vorgeschlagene Maßnahmen zur Behebung

Wann KEINE Meldung erforderlich ist:

• Verfügbarkeitsvorfälle (DoS) ohne Offenlegung von Daten
• Erfolgreich abgewehrte Angriffsversuche
• Vorfälle, die nur nicht personenbezogene Daten betreffen (Konfiguration, Code)

Kontext bei QR Branding: Da der Dienst zustandslos ist und keine personenbezogenen Daten speichert, stellen die meisten Vorfälle keine Verletzung des Schutzes personenbezogener Daten dar. Ausnahmen wären:

• Offenlegung von Application-Insights-Logs mit Metadaten von Anfragen
• Abfangen von Datenverkehr bei der Übertragung (mit TLS unwahrscheinlich)
• Auffälliges Verhalten eines LLM-Anbieters, das Prompts anderer Nutzer offenlegt

Art. 34 – Benachrichtigung der betroffenen Personen

Nur erforderlich, wenn die Verletzung ein hohes Risiko für die Rechte und Freiheiten darstellt.

Nicht erforderlich, wenn:

• Die Daten verschlüsselt oder anonymisiert waren
• Maßnahmen ergriffen wurden, die sicherstellen, dass das Risiko aller Wahrscheinlichkeit nach nicht mehr besteht
• Sie mit einem unverhältnismäßigen Aufwand verbunden wäre (in diesem Fall erfolgt eine öffentliche Bekanntmachung)

Phase 4: Beseitigung und Wiederherstellung (T0+4h → T0+48h)

Phase 5: Nachbereitung (T0+48h → T0+2 Wochen)

---

5. Vorfallsprotokoll (Art. 33(5))

Jeder Vorfall muss protokolliert werden, unabhängig davon, ob er der Behörde gemeldet werden muss. Das Protokoll muss enthalten:

---

6. Wichtige Kontakte

Aufsichtsbehörden (Referenz)

---

7. Übungen

Mindestens eine Übung zur Reaktion auf Vorfälle pro Jahr wird durchgeführt, um:

• Zu prüfen, ob das Verfahren funktioniert
• Reaktionszeiten zu messen
• Lücken bei Fähigkeiten oder Kommunikation zu erkennen
• Das Team mit dem Ablauf vertraut zu machen

---

Dokument erstellt am 2026-03-08. Nächste geplante Überprüfung: 2026-09-08.