# Notfall-Leitfaden - Demo-Betrieb Kornblume-Shop (erfunden)

Musterarbeit von GL Tools. Betrieb, Zahlen und Rollen sind erfunden; <PLATZHALTER> setzt der Kunde ein.

## 1. Schweregrade

| Stufe | Wann | Erste Reaktion | Update an Betroffene |
|---|---|---|---|
| SEV1 | Shop komplett nicht erreichbar, Zahlung unmoeglich oder Datenabfluss vermutet | sofort, innerhalb von 15 Minuten | alle 30 Minuten |
| SEV2 | Hauptfunktion gestoert (Warenkorb, Login), Umgehung schwer | innerhalb von 30 Minuten | stuendlich |
| SEV3 | Nebenfunktion gestoert oder einzelne Kunden betroffen, Umgehung moeglich | innerhalb von 4 Stunden | taeglich |
| SEV4 | Schoenheitsfehler, kein Kundenschaden | naechster Werktag | im Ticket |

Im Zweifel die hoehere Stufe waehlen; herabgestuft wird spaeter.

## 2. Ablauf

1. Erkennen: Meldung aufnehmen (Zeit, Quelle, was ist zu sehen). Wer sie bekommt, eroeffnet sofort das Ticket <TICKET-LINK>.
2. Einstufen: Stufe nach Abschnitt 1 festlegen und die Rollen besetzen.
3. Eindaemmen: erst Schaden begrenzen (Wartungsseite, Funktion abschalten, Zugaenge sperren), dann Ursache suchen. Beweise sichern: Logs und Zeitpunkte kopieren, bevor etwas neu gestartet wird.
4. Beheben: kleinste Aenderung, die den Betrieb wiederherstellt; Rollback vor Reparatur. Danach Kontrolle mit der Gesundheitspruefung.
5. Abschliessen: Entwarnung melden, Ticket schliessen, Review innerhalb von 5 Werktagen ansetzen.

Rollen: Einsatzleitung (<NAME>, entscheidet), Technik (<NAME>, behebt), Kommunikation (<NAME>, schreibt alle Meldungen), Protokoll (<NAME>, haelt Zeitleiste fest). Bei kleinen Teams ist eine Person mehrere Rollen; die Einsatzleitung darf nicht gleichzeitig die Technik sein.

Datenpanne mit personenbezogenen Daten: Meldung an die Aufsichtsbehoerde ohne unangemessene Verzoegerung, nach Moeglichkeit binnen 72 Stunden nach Bekanntwerden (Art. 33 DSGVO); Rechtsberatung einholen, dieser Leitfaden ersetzt sie nicht.

## 3. Vorlagen fuer Meldungen

Intern (Start):
> [SEV<STUFE>] <KURZBESCHREIBUNG> seit <UHRZEIT>. Einsatzleitung: <NAME>. Betroffen: <BEREICH>. Naechstes Update um <UHRZEIT>.

Kunden (Stoerung):
> Wir haben seit <UHRZEIT> eine Stoerung bei <FUNKTION>. Bestellungen sind <MOEGLICH/NICHT MOEGLICH>. Wir arbeiten daran und melden uns um <UHRZEIT> wieder. Dringende Fragen: <KONTAKT>.

Kunden (Entwarnung):
> Die Stoerung bei <FUNKTION> ist seit <UHRZEIT> behoben. Betroffen waren <WER/WAS>. Wenn bei Ihnen etwas nicht stimmt, schreiben Sie an <KONTAKT>.

## 4. Post-Incident-Review (Vorlage)

Grundsatz: Wir suchen Ursachen im Ablauf und im System, keine Schuldigen. Fragen lauten "Was liess das zu?", nicht "Wer war das?".

- Titel, Datum, Stufe, Dauer: <...>
- Auswirkung: was haben Kunden gemerkt, wie lange, wie viele Bestellungen/Nutzer (nur gemessene Zahlen): <...>
- Zeitleiste (Uhrzeit, Ereignis, Entscheidung): <...>
- Ursache und beitragende Faktoren: <...>
- Was hat gut funktioniert, was nicht: <...>
- Massnahmen: je Massnahme ein Verantwortlicher und eine Frist.

| Massnahme | Verantwortlich | Frist |
|---|---|---|
| <...> | <NAME> | <DATUM> |

Massnahmen verringern das Risiko; zugesagt wird nie, dass etwas nicht wieder vorkommt.