Vorfälle beherrschen.Entscheidungen belegen.
Ein Alarm ist noch kein Sicherheitsvorfall. Incident DCH verbindet qualifizierte Signale mit einer geführten Reaktion. Es hält fest, wer entscheidet, was eingedämmt wurde, welche Stellen informiert werden müssen und wann der Betrieb belastbar zurückkehrt.
Vom Signal zur
beherrschten Lage.
Die Kette beginnt mit einem belastbaren Signal und endet nicht mit dem geschlossenen Ticket. Eindämmung, Wiederherstellung, Kommunikation und Lernen haben eigene Verantwortungen. Kontinuität und Wiederanlauf werden nur aktiviert, wenn die Auswirkung dies verlangt.
Qualifizieren
Quelle, Zeit, betroffene Umgebung und Vertrauensgrad des Signals prüfen.
Bewertetes Signal
Einstufen
Auswirkung, Reichweite, Kritikalität und Meldebezug bestimmen. Incident Lead benennen.
Klassifizierter Vorfall
Begrenzen
Angriffspfad unterbrechen, Beweise sichern und unkontrollierte Folgeschäden vermeiden.
Stabilisierte Lage
Entscheiden
Geschäftsauswirkung, Priorität, externe Meldung und Kommunikationsbedarf verantworten.
Dokumentierte Entscheide
Freigeben
Sauberen Zustand herstellen, Dienste kontrolliert freigeben und Restgefahr beobachten.
Freigegebener Betrieb
Belegen
Ursache, Wirkung, Zeitlinie, Massnahmen, Meldungen und verbleibendes Risiko zusammenführen.
Abschlussnachweis
Nachführen
Kontrollen, Playbooks, Architektur und Übungen mit Owner, Termin und Wirksamkeitsprüfung verbessern.
Geprüfte Verbesserung
Kein Automatismus. Der Incident Lead löst diese Prozesse aus, wenn kritische Leistungen oder Wiederherstellungsziele betroffen sind. Damit bleibt die technische Reaktion von Notbetrieb und Disaster Recovery unterscheidbar.
Forensische Sicherung beginnt vor zerstörerischen Eingriffen, soweit die Lage dies zulässt. Integrität, Herkunft, Übergaben und Zugriffe auf Beweismittel bleiben nachvollziehbar.
Eine Lage.
Klare Mandate.
In kleinen Organisationen können Personen mehrere Rollen übernehmen. Führung, technische Ausführung und unabhängige Nachprüfung bleiben trotzdem unterscheidbar. Für jeden Vorfall ist erkennbar, wer führen und wer verbindlich entscheiden darf.
Führt Lage und Takt. Hält Klassifikation, Arbeitsspuren, Abhängigkeiten und Entscheidungen zusammen. Eskaliert, wenn Wirkung oder Unsicherheit die eigene Kompetenz überschreiten.
Untersuchen und stabilisieren. Sie sichern Spuren, grenzen ein, bereinigen und stellen den technischen Zustand wieder her. Massnahmen werden mit Wirkung und Nebenwirkung protokolliert.
Verantworten Auswirkung und Aussage. Service Owner, Management, Recht, Datenschutz und Kommunikation entscheiden über Geschäftspriorität und adressatengerechte Information.
Prüft Abschluss und Lernen. Sie kontrolliert, ob Ursache, Restgefahr, Meldepflichten und Verbesserungen nachvollziehbar behandelt wurden.
Die Zeitlinie trägt
den Nachweis.
Ein belastbarer Vorfallnachweis entsteht während der Reaktion. Nachträglich rekonstruierte Zeiten und Entscheidungen verlieren unter Audit, Aufsicht oder Haftungsfragen schnell an Wert.
Eröffnung
Signalquelle, Erkennungszeit, erste Bewertung, betroffene Services und verantwortlicher Incident Lead.
Lagebild
Reichweite, Geschäftsauswirkung, Angriffspfad, Unsicherheit, Klassifikation und nächste Entscheidungszeit.
Entscheidungsprotokoll
Entscheid, Verantwortlicher, Zeitpunkt, Begründung und erwartete Wirkung jeder wesentlichen Massnahme.
Melderegister
Geprüfter Adressatenkreis, Fristbeginn, übermittelte Inhalte, Freigabe, Eingang und offene Ergänzungen.
Rückkehrnachweis
Bereinigter Zustand, Wiederherstellungstest, Freigabe, verstärktes Monitoring und verbleibende Einschränkungen.
Abschluss und Lernen
Ursache, Wirkung, Kosten, Restgefahr und Verbesserungen mit Owner, Termin und späterer Wirksamkeitsprüfung.
Die Pflicht folgt
dem Anwendungsbereich.
Die Uhr darf nie aus einer einzigen Schlagzeile übernommen werden. Organisation, Sektor, Ereignisart und Wesentlichkeit bestimmen, ob eine Meldung erforderlich ist, wann die Frist beginnt und welche Folgeberichte verlangt werden.
| Profil | Im Prozess verankern | Zeitbezug | Grenze |
|---|---|---|---|
| Allgemeines ISMS | Eskalationsmatrix, Kontaktwege, Beweissicherung, Kommunikation, Rückkehr und Lernen. | Interne Reaktionsklassen und vertragliche Pflichten. | ISO 27001 setzt keine universelle staatliche Meldefrist. |
| NIS2 und deutsches BSIG | Betroffenheit der Einrichtung, erheblicher Sicherheitsvorfall, Frühwarnung, Meldung und Abschlussbericht getrennt prüfen. | Fristen gelten nur bei erfülltem Anwendungsbereich und meldepflichtigem Ereignis. | Sektorale Ausnahmen und nationale Umsetzung sind zu beachten. |
| DORA | ICT Vorfälle erkennen, managen, klassifizieren und schwerwiegende Vorfälle über die vorgesehenen Meldestufen berichten. | Die DORA Meldefristen folgen der geltenden delegierten Regelung und der Klassifikation. | Nur für erfasste Finanzunternehmen und weitere ausdrücklich erfasste Akteure. |
| FINMA | Wesentlichkeit für kritische IKT, kritische Daten und Prozesse prüfen, FINMA Vororientierung und Folgemeldung dokumentieren. | Bei erfassten wesentlichen Cyberattacken sieht RS 2023/1 eine Vororientierung innert 24 Stunden und Pflichtfelder innert 72 Stunden vor. | Adressatenkreis und Aufsichtspraxis des Instituts sind zu prüfen. |
| Schweizer Meldepflicht | Prüfen, ob eine erfasste kritische Infrastruktur und ein meldepflichtiger Cyberangriff vorliegen. | Erstmeldung innert 24 Stunden, fehlende Angaben können nach dem BACS Merkblatt ergänzt werden. | Nicht jede Organisation und nicht jedes Ereignis fällt darunter. |
| CRA Produktsicherheit | Aktiv ausgenutzte Produktschwachstellen und schwere Sicherheitsvorfälle des Produkts in den Produktprozess übergeben. | CRA Fristen beginnen erst bei einem Ereignis, einer Rolle und einem Produkt im gesetzlichen Anwendungsbereich. | Kein Ersatz für den allgemeinen Unternehmensvorfallprozess. |
Geschwindigkeit ohne
Kontrollverlust.
Entscheidend sind nicht möglichst viele geschlossene Incidents. Gute Steuerung zeigt, ob kritische Signale rechtzeitig qualifiziert, wirksame Entscheide getroffen, Pflichten eingehalten und Wiederholungen tatsächlich verhindert werden.
Zeit vom belastbaren Signal bis zur dokumentierten Einstufung und Übernahme durch den Incident Lead.
Zeit bis zur nachgewiesenen Begrenzung des Angriffspfads oder der schädlichen Wirkung.
Offene kritische Entscheide ohne verantwortliche Person oder nächste Entscheidungszeit.
Fristgerechte Meldungen mit nachvollziehbarem Auslöser, Freigabe und dokumentierten Ergänzungen.
Dienste, die ohne dokumentierte technische Prüfung oder ohne Freigabe wieder in Betrieb gingen.
Erneute Vorfälle mit bereits beschlossener, aber nicht wirksam umgesetzter Verbesserung.
Werkzeuge stützen.
Menschen führen.
SIEM, SOAR, On Call, ITSM und Statuskommunikation tragen verschiedene Teile der Kette. Kein Werkzeug entscheidet allein über Wesentlichkeit, externe Meldung oder die geschäftliche Rückkehr.
SOARWiederkehrende Schritte für Untersuchung und Reaktion nachvollziehbar orchestrieren.Vergleich öffnen →
Incident Management und On CallAlarmierung, Bereitschaft, Eskalation und Koordination über Rollen hinweg steuern.Vergleich öffnen →
Status und Incident CommunicationInterne und externe Lageinformationen kontrolliert publizieren.Vergleich öffnen →
Ransomware RecoverySaubere Wiederherstellung und kontrollierte Rückkehr nach Erpressungsangriffen.Vergleich öffnen →
BackupWiederherstellbare, geschützte Kopien und belastbare Recovery Tests bereitstellen.Vergleich öffnen →
Aktuelle Basis.
Klare Reichweite.
Die Quellen decken Managementsystem, Reaktionspraxis und sektorale Meldung ab. STOP.LI verbindet sie zu einer Prozesskette, ersetzt aber weder Rechtsprüfung noch Aufsichtskommunikation im Einzelfall.
Managementsystem
Annex A.5.24 bis A.5.28 stützen Vorbereitung, Bewertung, Reaktion, Lernen und Beweissicherung. Die Zuordnung wurde gegen die lizenzierte Normfassung geprüft.
Incident Response
Die 2025 veröffentlichte Revision verbindet Vorbereitung, Erkennung, Reaktion und Wiederherstellung mit dem Risikomanagement des NIST CSF 2.0.
Finanzsektor EU
Artikel 17 verankert einen Prozess zur Erkennung, Behandlung und Meldung von ICT Vorfällen. Klassifikation und Berichtspflichten folgen den weiteren DORA Vorgaben.
EU und Deutschland
Artikel 21 fordert Incident Handling als Risikomassnahme. Artikel 23 regelt die mehrstufige Meldung erheblicher Sicherheitsvorfälle für erfasste Einrichtungen.
Schweizer Banken
Verbindet Cyberreaktion, Wiederherstellung, Wesentlichkeit und Aufsichtsmeldung mit kritischer IKT, kritischen Daten und Prozessen.
Schweiz
Das Merkblatt beschreibt Ereigniskriterien, Erstmeldung und Ergänzung für erfasste Betreiberinnen kritischer Infrastrukturen.
Ereignisse werden
geführt.
Incident Management verbindet Erkennung, Entscheidung, Kommunikation und Wiederherstellung. Referenzen strukturieren die Reaktion, Nachbarprozesse liefern Kontext und Werkzeugklassen unterstützen Beobachtung, Koordination und Forensik.
| Referenz | Beitrag zum Prozess | Grenze |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.24 bis A.5.28 decken Vorbereitung, Bewertung, Reaktion, Lernen und Beweissicherung ab. | Ersetzt keine Meldeentscheidung im Einzelfall. |
| NIST SP 800-61 Rev. 3 | Ordnet Incident Response in ein breiteres Cybersecurity-Risikomanagement ein. | Definiert keinen organisationsunabhängigen Eskalationsweg. |
| DORA und NIS2 | Enthalten für erfasste Organisationen Anforderungen an Incident-Management und Meldungen. | Fristen und Zuständigkeiten folgen dem konkreten Sachverhalt und Anwendungsbereich. |
| Inhalt | Beitrag | Weiter |
|---|---|---|
| 19 Monitoring | Liefert Signale, Erkennungsnachweise und technische Beobachtungen. | Prozess öffnen → |
| 22 Kontinuität | Steuert Mindestleistungen und Handlungsfähigkeit bei schweren Störungen. | Prozess öffnen → |
| 23 Wiederanlauf | Plant die Rückkehr in einen kontrollierten Betriebszustand. | Prozess öffnen → |
Security Tool Navigator · Werkzeuge zum Prozess
Werkzeuge nach Gebiet einordnen.
Die Werkzeugklassen dieses Prozesses sind im Security Tool Navigator nach Sicherheitsgebieten geordnet. Die Gebietsseiten zeigen Abgrenzung, Auswahlfragen für CIO und CISO und alle Werkzeugklassen im Zusammenhang.