a943db9c54
Teil 5 des Compliance-Updates: - docs/legal/: data-processing-inventory.md, subprocessors.md, technical-organizational-measures.md, retention-and-deletion.md, incident-response.md, licenses-and-attributions.md — Ist-Zustand aus der Analyse, offene Punkte als Platzhalter - Reine Consent-Regeln nach src/lib/legal-rules.ts ausgelagert (kein Prisma) + Texte nach src/lib/legal-content.ts (7 Pflichtbestätigungen) — für Testbarkeit - Vitest eingerichtet (vitest.config.ts, test-Script); 13 Tests grün: Pflicht-Dokumenttypen, Re-Consent bei neuer Version, normale Benutzer ≠ Org-Vertreter, 7 Org-Bestätigungen, Platzhalter-Erkennung, keine erfundenen Subprozessoren Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
45 lines
2.0 KiB
Markdown
45 lines
2.0 KiB
Markdown
# Incident-Response — Lageplan
|
|
|
|
Stand: 2026-07-23 · sorgfältiger Entwurf. **Manueller Entscheidungsprozess** — es erfolgt KEINE
|
|
automatische Meldung an Behörden. Meldepflichten werden im Einzelfall geprüft.
|
|
|
|
## Kontakte (auszufüllen)
|
|
- Verantwortlich (Betreiber): `[NAME]` · `[KONTAKT]`
|
|
- Datenschutzkontakt: siehe `src/config/legal.ts` (`privacyContactEmail`)
|
|
- Technischer Notfallkontakt: `[NAME/TELEFON]`
|
|
- Zuständige Aufsichtsbehörde (CH): EDÖB — `[LINK/KONTAKT]`
|
|
|
|
## Ablauf
|
|
|
|
1. **Erkennung** — Quelle (Monitoring, Meldung, Nutzerhinweis), Zeitpunkt und Symptome festhalten.
|
|
2. **Interne Eskalation** — Verantwortliche informieren; Vorfall im Vorfallprotokoll eröffnen.
|
|
3. **Eindämmung** — betroffene Systeme/Zugänge isolieren, ggf. Dienste temporär sperren.
|
|
4. **Beweissicherung** — Logs/Artefakte sichern, bevor Änderungen erfolgen.
|
|
5. **Bewertung betroffener Daten** — welche Datenkategorien/Personen sind betroffen?
|
|
6. **Risikobewertung** — Eintritts-/Schadenswahrscheinlichkeit für Betroffene.
|
|
7. **Information betroffener Organisationen** — ohne unangemessene Verzögerung, sachlich.
|
|
8. **Prüfung Behördenmeldung** — Meldepflicht (z.B. EDÖB) im Einzelfall prüfen und **manuell** entscheiden/dokumentieren.
|
|
9. **Passwort-/Schlüsselrotation** — Secrets, Tokens, ggf. Nutzer-Passwörter rotieren.
|
|
10. **Wiederherstellung** — aus sauberem Stand/Backup; Integrität prüfen.
|
|
11. **Nachbearbeitung** — Ursachenanalyse, Massnahmen, Lessons Learned.
|
|
|
|
## Vorfallprotokoll (Vorlage)
|
|
| Feld | Inhalt |
|
|
|---|---|
|
|
| Vorfall-ID / Datum | |
|
|
| Entdeckt durch / wann | |
|
|
| Beschreibung | |
|
|
| Betroffene Daten/Personen | |
|
|
| Sofortmassnahmen | |
|
|
| Risikobewertung | |
|
|
| Information an Organisationen (wann/wie) | |
|
|
| Behördenmeldung (ja/nein, Begründung) | |
|
|
| Rotation durchgeführt | |
|
|
| Wiederherstellung | |
|
|
| Abschluss / Massnahmen | |
|
|
|
|
## Vom Betreiber zu treffende Entscheidungen
|
|
- Verbindliche Kontaktliste und Erreichbarkeit.
|
|
- Melde-Schwellen und interne Fristen.
|
|
- Aufbewahrung des Vorfallprotokolls.
|