Um drei Uhr morgens geht der SIEM-Alert auf, der On-Call-Engineer schaut auf das Handy und merkt sofort, was wieder passiert ist. Der Patch steht seit Wochen offen, der Ruf nach der Geschäftsführung läuft ins Leere, und niemand weiß, wer den Vorfall eigentlich führt. Genau an diesem Punkt scheitern viele Unternehmen nicht an der Technik, sondern an fehlender Incident-Response-Organisation.
Im deutschsprachigen AT- und DACH-Kontext ist das kein Randthema mehr. Bereits 78 % der befragten Organisationen stellen laut Arista mindestens eine Person ausschließlich für Incident Response ab, 11 % sogar mehr als 25 Mitarbeitende, während nur 31 % ein Security Operations Center betreiben und 16 % diese Funktion auslagern. Gleichzeitig erkennen 65 % der Befragten an, dass das obere Management die Bedeutung von Incident Response für Datensicherheit und Geschäftsfähigkeit versteht, wie Arista in seiner Erhebung beschreibt. Das ist die Realität, auf der du dein Team aufbauen musst.
Inhaltsverzeichnis
- Wenn der Alert um drei Uhr morgens kommt
- Der Sechs-Phasen-Lebenszyklus als gemeinsame Sprache
- Rollen, Eskalation und Erreichbarkeit sauber aufsetzen
- Playbooks und Runbooks, die im Ernstfall halten
- On-Call-Modelle im Vergleich
- KI-Agenten und MCP-Connectoren sinnvoll einbinden
- Üben, messen, retrospektiv verbessern
Wenn der Alert um drei Uhr morgens kommt
Der erste Schaden entsteht oft nicht im Angriff selbst, sondern in den ersten Minuten danach. Laut Everbridge dauert es im Schnitt 27 Minuten, in einem schweren IT-Vorfall das Reaktionsteam zusammenzustellen, in Einzelfällen bis zu 150 Minuten. Dieselbe Erhebung beziffert ungeplante Ausfallzeiten mit durchschnittlich 8.662 US-Dollar pro Minute, der Median liegt bei 7.200 US-Dollar pro Minute, der Spitzenwert bei 100.000 US-Dollar pro Minute, so die Everbridge-Erhebung. Wer da noch improvisiert, bezahlt doppelt.
Die fünf Symptome eines unreifen Setups
Ein unreifes Incident-Response-Team erkennst du fast immer an denselben Mustern.
- Niemand führt den Vorfall sauber: Der Alert kommt an, aber kein klarer Incident Commander übernimmt.
- Eskalation hängt an Einzelpersonen: Ein Anruf bleibt unbeantwortet, und damit steht die gesamte Kette still.
- Tools sind fragmentiert: SIEM, Ticketing, Chat und Backup reden nicht sauber miteinander.
- Kommunikation ist ad hoc: Technik, Management und Fachbereiche hören unterschiedliche Versionen desselben Vorfalls.
- Wiederanlauf ist nicht geübt: Das Team weiß nicht, wer isoliert, wer dokumentiert und wer freigibt.
Praktische Regel: Wenn du erst im Vorfall klären musst, wer informiert wird, ist das Team noch keine Betriebsfunktion, sondern ein Improvisationsprojekt.
Die klare Konsequenz daraus ist unbequem, aber richtig. Ein Incident-Response-Team ist heute keine rein technische Sondertruppe, sondern eine operative Steuerungsfunktion, die Geschäft, Recht, Kommunikation und IT zusammenführt. Das ist auch der Grund, warum Management-Resonanz nicht reicht, wenn Zuständigkeiten, Eskalationswege und Backups nicht fest verankert sind.
Gerade im AT-Mittelstand mit ERP-, Legacy- und Produktionslandschaften wird die Lage sonst schnell teuer. Wenn ein Patch offensteht, ein Lieferant über Remote Access verbunden ist und das Team erst beim Alarm anfängt zu telefonieren, verlierst du Zeit an genau der Stelle, an der du sie nicht hast. Wer hier sauber aufbauen will, muss Rollen, Erreichbarkeit und Entscheidungsrechte zuerst klären, nicht erst nach dem nächsten Vorfall.
Der Sechs-Phasen-Lebenszyklus als gemeinsame Sprache
Ein belastbares Incident-Response-Team braucht eine gemeinsame Sprache, sonst diskutiert jeder in seiner eigenen Logik. Das sauberste Grundmodell bleibt der Sechs-Phasen-Lebenszyklus, also Vorbereitung, Identifikation, Eindämmung, Beseitigung, Wiederherstellung und Lessons Learned. SANS beschreibt genau diesen Ablauf als Grundlage wirksamer Incident Response, und Microsoft betont zusätzlich, dass Organisationen schon in der Vorbereitung festlegen sollen, was überhaupt als Incident gilt, SANS im Glossar zur Incident Response, Microsofts Lifecycle-Beschreibung.
Warum diese Phasen in AT-Unternehmen mehr sind als Theorie
Im AT-Kontext ist das kein akademisches Modell. Die Geschäftsführung will wissen, wann gemeldet wird, Legal will wissen, was dokumentiert ist, und die IT will wissen, wann sie Systeme isolieren darf. Cyber-GC fordert dafür einen Risiko-Assessment-Ansatz, definierte Kommunikationsmechanismen für Management und Stakeholder sowie belastbare Backup- und Patch-Prozesse als Basis der Response-Fähigkeit, Cyber-GC-Leitfaden.
Die praktische Logik ist simpel. Vorbereitung schafft Spielregeln. Identifikation klassifiziert den Vorfall. Eindämmung stoppt die Ausbreitung. Beseitigung entfernt die Ursache. Wiederherstellung bringt den Betrieb zurück. Lessons Learned sorgt dafür, dass derselbe Fehler nicht wieder auftaucht.
| Phase | Hauptverantwortliche | Kernartefakt | Typische Dauer |
|---|---|---|---|
| Vorbereitung | IR-Leitung, IT-Ops, Legal | Playbooks, Kontaktliste, Freigabewege | Laufend |
| Identifikation | Triage Lead, SOC, Fach-IT | Vorfallsklassifikation, Erstbewertung | Minuten bis Stunden |
| Eindämmung | Incident Commander, IT-Ops | Isolationsentscheid, Beweis-Log | Minuten bis Stunden |
| Beseitigung | Forensik, IT-Ops | Root-Cause-Notizen, Bereinigungsplan | Stunden bis Tage |
| Wiederherstellung | IT-Ops, Business Owner | Restore-Freigabe, Validierungsprotokoll | Stunden bis Tage |
| Lessons Learned | Incident Commander, Management | Retrospektive, Maßnahmenliste | Nach dem Vorfall |
Die Tabelle ist kein Formalismus, sondern eine Entscheidungshilfe. Wenn du nicht sofort sagen kannst, wer in welcher Phase das letzte Wort hat, ist dein Team nicht einsatzbereit genug. Genau deshalb sollten du und dein Management diese Phasen in Runbooks, Kommunikationsplänen und Freigaberechten sichtbar machen, statt sie nur in einer Policy zu parken.
Ein gutes Team ist nicht das Team mit den meisten Tools, sondern das Team, das in jeder Phase dieselbe Sprache spricht.
Rollen, Eskalation und Erreichbarkeit sauber aufsetzen
Ein Incident-Response-Team scheitert selten am Fachwissen. Es scheitert daran, dass im Ernstfall keiner eindeutig entscheidet und niemand klar erreichbar ist. Das britische NCSC empfiehlt deshalb, nicht nur technische Rollen zu erfassen, sondern auch Kontakte aus IT, Senior Management, Legal, PR, HR und Insurance, idealerweise mit mindestens zwei Kontaktmethoden und mindestens zwei Personen pro Funktion, NCSC-Leitfaden.
Wer wofür verantwortlich ist
Die Kernrollen brauchst du ohne Theater, aber mit klarer Zuständigkeit. Wenn die Rollen schwammig bleiben, verlierst du im Vorfall sofort Zeit.
- Incident Commander: trifft die operative Gesamtentscheidung und hält die Lage zusammen.
- Triage Lead: sortiert Alerts, prüft Plausibilität und priorisiert den ersten Handlungsbedarf.
- Communications Lead: steuert interne Updates, Management-Infos und externe Freigaben.
- Forensik: sichert Beweise, rekonstruiert den Ablauf und schützt die Nachvollziehbarkeit.
- Legal und PR: prüfen Meldepflichten, Haftung, Formulierungen und Außenwirkung.
- IT-Ops: isoliert Systeme, setzt den Wiederanlauf um und bringt den Betrieb zurück.
Der häufigste Fehler im Mittelstand ist der Single Point of Failure pro Rolle. Ein Ansprechpartner pro Funktion sieht im Organigramm sauber aus, bricht aber im Ernstfall sofort weg, wenn die Person im Urlaub, im Termin oder schlicht nicht erreichbar ist. Deshalb brauchst du pro Rolle mindestens eine echte Vertretung mit denselben Freigaberechten und demselben Zugang zu den Kommunikationskanälen.
Das gilt auch für neue Arbeitsweisen im IR-Alltag. Wenn du KI-Agenten oder MCP-Connectoren für Triage, Ticketpflege oder Statuszusammenfassungen einsetzt, müssen diese Aufgaben eine menschlich verantwortete Rolle haben. Sonst automatisierst du nur Verwirrung, statt Arbeit zu sparen.
So wird Eskalation in der Praxis handhabbar
Eine gute Eskalationsmatrix ist knapp, konkret und mehrfach abgesichert.
- Stufe 1, Technik prüft: Triage, erste Eindämmung, keine Außenkommunikation ohne Freigabe.
- Stufe 2, Incident Commander übernimmt: Fach-IT, Forensik und Communications Lead werden aktiviert.
- Stufe 3, Management wird eingebunden: Geschäftsführung, bei Bedarf Aufsicht oder Gesellschafterseite.
- Stufe 4, externe Stellen werden adressiert: Counsel, Versicherer, Behörden oder spezialisierte Dienstleister.
Die Reihenfolge allein reicht nicht. Erreichbarkeit entscheidet. Schichtmodelle, Bereitschaftszonen und Handover-Regeln müssen mit Arbeitsrecht und internen Betriebsvereinbarungen zusammenpassen, sonst baust du dir ein Modell auf dem Papier, das im Alltag niemand trägt. Der Maßstab ist einfach. Wenn jemand übernimmt, muss klar sein, welche Entscheidungen er oder sie wirklich treffen darf.
KI kann hier helfen, aber nur unter harter Kontrolle. Ein Agent darf einen Vorfall nicht selbst eskalieren oder Freigaben erteilen, wenn Audit-Trail, Rollenbindung und Eskalationslogik nicht sauber dokumentiert sind. Genau deshalb müssen auch Automatisierungen in dieselbe Verantwortungsstruktur fallen wie ein Mensch im Bereitschaftsdienst.
Das ist auch der Punkt, an dem du interne Rollen mit externer Unterstützung sauber trennen solltest. Wer das organisatorisch sauber strukturieren will, findet eine nützliche Perspektive auf technische und organisatorische Profile unter Cyber-Security-Jobs mit Praxisbezug. Entscheidend bleibt aber dein eigenes Runbook, nicht der Lebenslauf einzelner Leute.
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/mxbeRSry2VQ" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>Playbooks und Runbooks, die im Ernstfall halten
Strategische Playbooks und operative Runbooks werden ständig verwechselt, und genau das kostet im Ernstfall Zeit. Ein Playbook beschreibt den Rahmen für einen Vorfalltyp, also etwa Ransomware, Datenschutzvorfall oder OT-Vorfall. Ein Runbook beschreibt die konkreten Schritte auf einem konkreten System, also etwa M365, SAP, BMD, DATEV, Navision, Exact oder weclapp.
Was in ein Playbook gehört
Ein Playbook muss die Entscheidungslage klären, nicht jeden Klick auflisten. Es definiert Ziel, Trigger, Verantwortliche, Freigaben, Kommunikationslogik und Abbruchkriterien. Die US-Select-Agent-Guidance verlangt ausdrücklich, Incident-Response-Pläne nach einem standortspezifischen Risikobewertungsprozess zu entwickeln, pro Vorfalltyp eigene SOPs zu definieren und den Plan mindestens jährlich zu überprüfen und zu testen, US Select-Agent-Guidance.
Praktisch heißt das:
- Szenario eindeutig benennen: Ransomware ist nicht gleich Datenabfluss und nicht gleich OT-Störung.
- Entscheidungsrechte festhalten: Wer darf isolieren, wer darf extern melden, wer darf Services abschalten.
- Kommunikationspfad definieren: Intern, Management, Legal, PR und externe Partner.
- Dokumentationspflicht einbauen: Jede Maßnahme braucht Zeitstempel und Verantwortliche.
- Review-Takt festlegen: Jährlich ist Pflicht, häufiger ist besser, wenn du viele Änderungen hast.
Wie ein Runbook wirklich brauchbar wird
Ein Runbook ist nur dann gut, wenn es in Stresssituationen lesbar bleibt. Schreib es systembezogen, nicht abstrakt. Wenn du für SAP, M365 oder DATEV nichts Konkretes dokumentierst, improvisiert das Team beim ersten echten Ausfall und verliert wertvolle Minuten an Kleinigkeiten.
Ein brauchbares Runbook enthält immer dieselben Bausteine, aber nicht in derselben Gewichtung. Es braucht Vorbedingungen, die ersten Isolationsschritte, den Backup- oder Restore-Pfad, den Validierungsschritt und die Freigabe für Wiederanlauf. Die Technik muss dabei eng mit den fachlichen Freigaben verknüpft sein, sonst läuft der Wiederanlauf am Business vorbei.
Faustregel: Was du nicht in einer ruhigen Stunde in fünf Minuten erklären kannst, wird in der Nacht niemand sauber ausführen.
Für die Tests gilt dasselbe. Tabletop-Übungen decken Entscheidungswege auf, Purple-Team-Sprints prüfen technische Reaktionen, und Worst-Case-Simulationen zeigen, ob die Organisation unter Druck wirklich zusammenarbeitet. Ein guter Test misst nicht, ob jemand nett mitgemacht hat, sondern ob Eskalation, Kommunikation und Wiederanlauf im Ablauf funktionieren.
On-Call-Modelle im Vergleich
Beim On-Call gibt es keine perfekte Lösung, nur eine passende. Für den AT-Mittelstand stehen im Kern drei Modelle zur Wahl, ein reines Follow-the-Sun, eine regionale 24/7-Rotation oder ein Hybrid aus internem Kernteam und externem MSSP. Die richtige Wahl hängt nicht von einer Ideologie ab, sondern von Time-to-Acknowledge, Kosten, Burnout-Risiko, Auditierbarkeit und Regulierungsnähe.
Die drei Modelle im direkten Vergleich
| Modell | Time-to-Acknowledge | Kostenindex | Burnout-Risiko | Eignung AT-Mittelstand |
|---|---|---|---|---|
| Follow-the-Sun | Sehr niedrig, wenn global sauber organisiert | Hoch | Mittel | Eher für Konzerne |
| Regionale 24/7-Rotation | Niedrig bis mittel | Mittel | Hoch, wenn schlecht besetzt | Gut, aber personalintensiv |
| Hybrid intern plus MSSP | Niedrig, wenn Verträge und Playbooks sitzen | Mittel | Niedrig bis mittel | Sehr gut |
Das reine Follow-the-Sun-Modell funktioniert nur dann gut, wenn du wirklich mehrere Zeitzonen, saubere Übergaben und eine reife Dokumentation hast. Für viele österreichische Mittelständler ist das overengineered und organisatorisch unnötig komplex. Die regionale 24/7-Rotation ist näher an der Realität, kippt aber schnell in Bereitschaftsmüdigkeit, wenn das Kernteam zu klein ist.
Meine klare Empfehlung
Für die meisten Unternehmen in Österreich ist Hybrid intern plus MSSP die vernünftigste Lösung. Das interne Kernteam hält Lagebild, Governance und Freigaben zusammen, der MSSP übernimmt Erstalarmierung, Vorfilterung und Teile der Nachtreaktion. Das wirkt nur dann, wenn du vorher genau definierst, was der MSSP selbstständig darf und wo der Mensch aus deinem Haus zwingend zustimmen muss.
Die häufigste Schwachstelle ist nicht der Vertrag, sondern die Schnittstelle. Wenn Alarmierung, Ticketing, Chat, Dokumentation und Eskalation nicht aufeinander abgestimmt sind, gewinnt wieder das Chaos. Deshalb muss der Dienstleister in dein Runbook eingebaut werden, nicht umgekehrt.
Ein MSSP ohne klare Entscheidungsgrenzen ist kein Sicherheitsnetz, sondern ein zusätzlicher Übergabepunkt.
Die beste Regel für den Mittelstand bleibt simpel. Halte dein internes Kernteam klein, trainiert und entscheidungsfähig, kaufe Nachtschicht und Ersttriage gezielt zu, und automatisiere den ersten Alarm so weit, dass niemand mehr im Blindflug telefoniert. Alles andere produziert mehr Aufwand als Schutz.
KI-Agenten und MCP-Connectoren sinnvoll einbinden
Ein Incident-Response-Team gewinnt mit KI nur dann Tempo, wenn du die Aufgaben sauber begrenzt. Agenten sollen Vorarbeit erledigen, nicht selbst die Lageführung übernehmen. Der sinnvolle Einsatz liegt bei Triage, Erstanalyse, Beweissicherung in ERP-, CRM- und Legacy-Systemen, Entwürfen für Kommunikation und der Verdichtung von Erkenntnissen nach dem Vorfall.
Wo KI produktiv hilft
In der Vorbereitung fasst KI Logdaten zusammen, clustert Ticket-Historien und entwirft Standardtexte für Meldungen oder Management-Briefings. In der Identifikation erkennt sie Muster und formuliert erste Hypothesen. In der Eindämmung schlägt sie technische Schritte vor, die ein Mensch freigibt. In der Nachbereitung verdichtet sie Zeitstrahlen, Maßnahmen und Abweichungen aus mehreren Quellen.
Sobald ein Agent selbständig Systeme isolieren, Dritte informieren oder Daten verändern darf, wird aus Entlastung ein Audit- und Haftungsrisiko. Das gilt besonders bei MCP-Connectoren zu Systemen wie BMD, DATEV, Navision, Exact oder weclapp. Diese Verbindungen gehören nicht in eine Blackbox. Sie brauchen klare Berechtigungen, Protokolle und Freigabepfade.
Wo KI sofort gefährlich wird
Die typischen Fehler sind immer dieselben.
- Schreibzugriff ohne Approval-Pfad: Der Agent kann handeln, aber niemand prüft die Aktion vorab.
- Fehlende Log-Trennung: Menschliche Entscheidungen und Agentenaktionen landen im selben, unklaren Protokoll.
- Geteilte Identitäten: Mehrere Systeme laufen unter einem Sammelzugang, der später nicht sauber nachvollziehbar ist.
- Zu breite Konnektoren: Der Agent sieht mehr Daten als für die Aufgabe nötig.
- Unklare Prompt-Hygiene: Eingaben enthalten sensible Informationen, ohne dass du das Risiko begrenzt.
Das ist kein Argument gegen KI, sondern gegen unkontrollierte Implementierung. Wenn du MCP-Connectoren als Teil deiner internen Architektur betreibst, begrenzt du Zugriffe, machst Schritte auditierbar und beschleunigst Reaktionen. Behandelst du sie wie ein externes Spielzeug, verschiebst du das Problem nur vom Menschen zur Maschine.
Für die operative Einführung brauchst du ein klares Reifeverständnis. Wer die Organisation auf KI im Arbeitsalltag vorbereiten will, muss die eigene Ausgangslage ehrlich prüfen, etwa mit einem strukturierten Blick auf Fähigkeiten, Prozesse und Kontrollpunkte unter KI-Schulung und AI-Enablement für Unternehmen. Erst wenn dieses Fundament steht, bringt ein Agent im Incident-Response-Kontext mehr Nutzen als Risiko.
Üben, messen, retrospektiv verbessern
Ein Incident-Response-Team wird nicht durch Organigramme gut, sondern durch harte Übung mit klaren Ergebnissen. CISA beschreibt nach einem Vorfall eine formale Retrospektive, in der der Incident Manager den bekannten Zeitstrahl vorträgt, das Team Ergänzungen und Korrekturen einbringt, konkrete Verbesserungen ableitet und die Ergebnisse an Mitarbeitende kommuniziert, CISA-Leitfaden. Genau dieses Muster gehört in den Betriebsalltag, nicht in die Ablage.
Eine gute Retrospektive bleibt nicht abstrakt. Nimm ein konkretes Szenario, etwa einen Verschlüsselungsvorfall auf einem Fileserver mit betroffenen Freigaben, einem ungeklärten Erstzugriff und paralleler Kommunikation mit Legal, IT-Betrieb und Geschäftsführung. Dann prüfst du sauber, wann der Alert einging, wer ihn bestätigt hat, wie lange die Eindämmung gebraucht hat und an welcher Stelle Entscheidungen hängen geblieben sind. Wer so arbeitet, erkennt die echten Reibungspunkte, nicht nur gefühlte Schwächen.
Die Routine, die wirklich trägt
Eine belastbare Praxis sieht so aus.
- Monatliche Tabletops: kurze, szenariobasierte Diskussionen mit Technik, Legal und Kommunikation. Nimm dafür abwechselnd ein Ransomware-Szenario, einen Cloud-Fehlzugriff oder einen Identitätsdiebstahl, damit das Team nicht nur einen Fall auswendig kann.
- Halbjährliche Purple-Team-Sprints: Angriff und Verteidigung im Wechsel testen.
- Jährliche Worst-Case-Simulation: einmal mit Geschäftsführung, einmal ohne Vorwarnung im Realitätsmodus.
- Formale Retrospektive danach: Zeitstrahl, Abweichungen, Aufgaben, Owner, Termin.
Dazu kommt eine kleine, aber ehrliche KPI-Liste. Messe Time-to-Acknowledge, Time-to-Contain, die Quote erfolgreich durchgespielter Eskalationen, den Anteil der Vorfälle mit abgeschlossenem Post-Mortem, die Patch-Lead-Time und die Übungs-Findings-Close-Rate. Die CISA-Leitfaden orientiert die Nacharbeit an einem klaren Zeitstrahl, an Korrekturen und an der Rückmeldung an die Organisation, genau das sollte in deinen Kennzahlen und in deinem Verbesserungsplan sichtbar sein. Was du nicht nachhältst, verschwindet im Alltag.
Prüfe auch deine eigene Ausgangslage nüchtern. Mit einer strukturierten AI Self-Assessment für die eigene IR-Reife erkennst du schneller, ob Rollen, Freigaben, Protokollierung und Eskalationswege bereits tragen oder ob sie in einer echten Lage brechen. Wer KI-Agenten und MCP-Connectoren in die Reaktion einbindet, muss genau diese Punkte vorab testen, sonst verschiebt er Tempo nur in neue Audit- und Freigaberisiken.
Dein 30-Tage-Startpunkt
In der ersten Woche musst du die Rollen und Vertretungen festziehen. Im ersten Monat brauchst du die wichtigsten Playbooks und Runbooks in Version 1.0. Im ersten Quartal sollte mindestens ein echtes Szenario durchgespielt und nachverfolgt sein. Wenn du dazu noch dokumentierst, welche Abweichungen offen geblieben sind, hast du mehr Substanz als viele Teams nach einem Jahr.
Wenn ein Team nur reagiert, lernt es langsam. Wenn es übt, misst und nacharbeitet, wird es verlässlich.
Der wichtigste Punkt ist einfach. Ein Incident-Response-Team ist kein Ordner und kein Organigramm, sondern ein Kreislauf aus Entscheidung, Übung und Verbesserung. Wer diesen Kreislauf ernst nimmt, reduziert Chaos, verkürzt Stillstand und macht aus Security wieder Betriebsfähigkeit.