Aktivierungsregel: Sobald ein Informationssicherheitsvorfall bestätigt ist oder aufgrund belastbarer Anhaltspunkte vermutet wird, wird dieser Prozess durch die Incident-Management-Verantwortung aktiviert. Bei Unsicherheit gilt: zuerst melden, dann gemeinsam bewerten.
Führungsregel: Für jeden aktiv bearbeiteten Vorfall gibt es genau eine benannte Incident-Leitung, ein führendes Incident-Ticket und eine nachvollziehbare Zeitlinie. Technische Maßnahmen, Kommunikation und externe Meldungen werden koordiniert und freigegeben.
Entwurfswarnung: Rollenbesetzung, Erreichbarkeit, technische Werkzeuge, externe Unterstützung, Wiederanlaufkriterien und interne Reaktionsziele sind vor der Freigabe organisationsbezogen zu ergänzen und in einer Übung zu testen. Diese Musterseite ist ohne diese Nachweise noch kein vollständig einsatzfähiger Incident-Response-Plan.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-05-02 |
| Dokumentenart | Verfahren / Incident-Response-Playbook |
| Wiki.js-Pfad | /ISMS/05-Vorfaelle-und-Notfallmanagement/Incident-Response |
| Verantwortlich | Incident-Management-Verantwortliche/r |
| Fachlich geprüft durch | IT, ISMS, Datenschutz, Compliance, Krisenmanagement und betroffene Fachbereiche |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Rollen und Einsatzfähigkeit nicht freigegeben |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Nächste Prüfung | Mindestens jährlich sowie nach Übungen und wesentlichen Vorfällen |
| Schutzklasse | Intern |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.24 bis 5.28, 5.29, 5.30 und 6.8 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 1.6 Incident- und Krisenmanagement |
| Ergänzende Orientierung | ISO/IEC 27035-1:2023 und NIST SP 800-61 Rev. 3 |
Dieses Verfahren beschreibt die koordinierte Bearbeitung eines vermuteten oder bestätigten Informationssicherheitsvorfalls von der Aktivierung bis zum dokumentierten Abschluss.
Ziele sind:
Der Meldeweg für Sicherheitsvorfälle erklärt, wer was über welchen Kanal meldet. Diese Seite beginnt mit der Annahme und Aktivierung und erklärt, wie das Response-Team den Vorfall bearbeitet.
Notfall-, Krisen- und Wiederanlaufpläne bleiben zusätzlich anwendbar. Eine Aktivierung dieses Verfahrens ersetzt weder den Schutz von Menschen noch notwendige betriebliche Notfallmaßnahmen.
Das Verfahren gilt innerhalb des festgelegten ISMS-Geltungsbereichs insbesondere für:
Vorfälle außerhalb des formalen ISMS-Geltungsbereichs werden ebenfalls eskaliert, wenn sie den Geltungsbereich, Kunden, gesetzliche Pflichten oder die Geschäftskontinuität beeinflussen können.
| Begriff | Bedeutung in diesem Verfahren |
|---|---|
| Informationssicherheitsereignis | Beobachtetes Vorkommnis, das für die Informationssicherheit relevant sein kann |
| Informationssicherheitsvorfall | Einzelnes oder zusammenhängendes Ereignis mit tatsächlicher oder wahrscheinlicher Beeinträchtigung von Vertraulichkeit, Integrität, Verfügbarkeit oder Authentizität |
| Incident-Leitung | Für den konkreten Vorfall benannte Rolle mit Koordinations- und Entscheidungsverantwortung |
| Triage | Erste strukturierte Prüfung von Plausibilität, Umfang, Auswirkungen, Dringlichkeit und benötigten Kompetenzen |
| Eindämmung | Kurz- oder langfristige Maßnahmen zur Begrenzung von Ausbreitung und Schaden |
| Bereinigung | Beseitigung bestätigter Ursachen, Schadkomponenten, kompromittierter Zugänge und unsicherer Zustände |
| Wiederherstellung | Kontrollierte Rückführung in einen sicheren, überwachten und fachlich freigegebenen Betrieb |
| Beweismittel | Daten oder Gegenstände, die Ursache, Ablauf, Umfang oder Verantwortlichkeit nachvollziehbar machen können |
| Lagebild | Aktuell bestätigte Fakten, Annahmen, offene Fragen, Auswirkungen, Maßnahmen und Entscheidungen |
Es gelten folgende Grundsätze:
Der Incident-Response-Prozess wird aktiviert, wenn mindestens eines der folgenden Kriterien erfüllt oder plausibel vermutet wird:
| Feld | Eintrag |
|---|---|
| Incident-ID | [INC-JJJJ-NNN] |
| Beginn/Kenntniszeitpunkt | [Datum, Uhrzeit, Zeitzone, Quelle] |
| Incident-Leitung | [Rolle/Name] |
| Stellvertretung | [Rolle/Name] |
| Ausgangsmeldung | [Link/Referenz] |
| Vorläufige Einstufung | [S1/S2/S3/S4] |
| Betroffene Assets/Prozesse | [Referenz zum Asset-Inventar] |
| Führendes Ticket/Lageprotokoll | [Geschützter Link] |
| Kommunikationskanal | [Geschützter Kanal/Bridge] |
| Nächste Lageaktualisierung | [Datum/Uhrzeit] |
| Datenschutzprüfung | [Offen/Ja/Nein – Rolle] |
| Rechts-/Vertragsprüfung | [Offen/Ja/Nein – Rolle] |
| Kunden-/TISAX-Bezug | [Offen/Ja/Nein – Rolle] |
Für einen realen Vorfall wird eine eigene geschützte Akte angelegt. Die Wiki-Seite enthält keine aktiven Incident-Daten, personenbezogenen Falldetails, Zugangsdaten oder forensischen Rohdaten.
Die meldende Person muss keine Einstufung vornehmen. Die Incident-Leitung bestätigt oder ändert die Stufe nach der Triage und bei jeder wesentlichen Lageänderung.
| Stufe | Typische Merkmale | Steuerung | Internes Reaktionsziel im Entwurf |
|---|---|---|---|
| S1 – Kritisch | Aktive erhebliche Ausbreitung, Gefahr für Menschen, kritischer Produktions-/Geschäftsausfall, erheblicher Datenabfluss oder Krisenlage | Sofortige Incident-/Krisenaktivierung, fortlaufendes Lagebild, Geschäftsleitung einbinden | Sofort; konkrete Zielzeit festzulegen |
| S2 – Hoch | Bestätigte Kompromittierung, sensible Daten oder wichtiger Kunde betroffen, größere Betriebswirkung oder schnelle Eskalation möglich | Priorisierte Bearbeitung, Incident-Leitung und Fachrollen aktivieren | Unverzüglich; konkrete Zielzeit festzulegen |
| S3 – Mittel | Begrenzter Vorfall ohne aktuelle erhebliche Ausbreitung, kontrollierbare lokale Auswirkung | Koordinierte Bearbeitung im Incident-Prozess | Zielzeit festzulegen |
| S4 – Niedrig | Geringe, eingegrenzte Auswirkung; kein Hinweis auf Ausbreitung oder externe Pflicht | Planmäßige Analyse und dokumentierter Abschluss | Zielzeit festzulegen |
Die Einstufung berücksichtigt mindestens:
| Rolle | Verantwortung und Befugnis |
|---|---|
| Meldungsannahme/Service Desk | Meldung erfassen, Empfang bestätigen, keine vorschnelle Entwarnung geben und eskalieren |
| Incident-Leitung | Priorität, Team, Taktung, Lagebild, Maßnahmen, Entscheidungen und Abschluss koordinieren |
| Technische Einsatzleitung | Analyse-, Eindämmungs-, Bereinigungs- und Wiederherstellungsmaßnahmen planen und dokumentieren |
| System-/Asset-Owner | Kritikalität und Geschäftsauswirkung bewerten; Maßnahmen und Wiederanlauf fachlich mitentscheiden |
| ISMS-Verantwortung | Kontrollbezug, Risikobehandlung, Nachweise, Lessons Learned und TISAX-/ISO-Auswirkungen steuern |
| Datenschutz | Personenbezug, Risiko, Dokumentation und erforderliche Meldungen/Benachrichtigungen prüfen |
| Recht/Compliance | Gesetzliche, regulatorische, vertragliche und beweisrechtliche Anforderungen prüfen |
| Krisenmanagement | Bei erheblicher Geschäfts-, Personen-, Produktions- oder Reputationsauswirkung die Krisensteuerung übernehmen |
| Kommunikation | Freigegebene interne und externe Aussagen erstellen, Zielgruppen und Ausgabekanäle steuern |
| Personal | Personalbezogene Maßnahmen, Fürsorge und arbeitsrechtliche Abstimmung unterstützen |
| Einkauf/Lieferantenmanagement | Externe Leistungserbringer aktivieren, Vertragsrechte und Lieferantenmaßnahmen verfolgen |
| TISAX-/Kundenkoordination | Kunden-, Prototypen-, Assessment- und ISA-Auswirkungen bewerten |
| Geschäftsführung | Kritische Geschäftsentscheidungen, Ressourcen, Risikoakzeptanz und externe Kommunikation freigeben |
| Externe Forensik/IR-Unterstützung | Nur nach Beauftragung und Vertraulichkeitsprüfung spezialisierte Leistungen erbringen |
Für jeden Vorfall werden mindestens benannt:
Unklare Zuständigkeiten werden an die Geschäftsführung eskaliert. Die lauteste oder technisch erfahrenste Person übernimmt nicht automatisch die Incident-Leitung.
| Phase | Ziel | Verbindliches Ergebnis |
|---|---|---|
| 0. Vorbereitung | Einsatzfähigkeit herstellen und erhalten | Getestete Rollen, Zugänge, Werkzeuge, Backups, Kontakte und Playbooks |
| 1. Triage und Analyse | Vorfall bestätigen, Umfang und Priorität bestimmen | Dokumentiertes Lagebild, Einstufung, Hypothesen und Maßnahmenplan |
| 2. Eindämmung | Ausbreitung und Schaden begrenzen | Genehmigte, protokollierte Kurz- und Langzeiteindämmung |
| 3. Bereinigung | Ursache und Angriffsartefakte entfernen | Nachweis über bereinigte Systeme, Identitäten und Schwachstellen |
| 4. Wiederherstellung | Sicheren und kontrollierten Betrieb herstellen | Sicherheits-, technische und fachliche Wiederanlauffreigabe |
| 5. Abschluss und Lernen | Wirksamkeit bewerten und Verbesserungen umsetzen | Abschlussbericht, Lessons Learned, Risiken und Maßnahmen |
Phasen können sich überlappen oder wiederholt werden. Neue Erkenntnisse können eine Rückkehr zu Analyse oder Eindämmung erfordern.
Vor einem Vorfall müssen mindestens folgende Voraussetzungen geplant, geschützt und getestet sein:
| Voraussetzung | Festlegung/Nachweis im Entwurf |
|---|---|
| Incident-Team und Rufbereitschaft | [Rollen, Kontakte, Vertretungen, Zeiten] |
| Sichere Out-of-Band-Kommunikation | [Kanal, Zugang, Testnachweis] |
| Incident-Ticket und Lageprotokoll | [Werkzeug, Berechtigungen, Vorlage] |
| Protokoll- und Zeitquellen | [Systeme, Aufbewahrung, Zeitsynchronisierung] |
| Forensische Werkzeuge und Datenträger | [Bestand, Schutz, verantwortliche Rolle] |
| Backup und Wiederherstellung | [Backup-Schutz, Restore-Test, Verantwortliche] |
| Netzwerk-/Identitätssperren | [Befugnisse, Notfallzugänge, Protokollierung] |
| Externe Forensik/IR-Unterstützung | [Vertrag, Kontakt, Aktivierungsbefugnis] |
| Cyberversicherung | [Vertrag, Kontakt, Melde-/Freigabebedingungen] |
| Behörden-/Datenschutz-/Kundenwege | Siehe Meldeweg für Sicherheitsvorfälle |
| Szenario-Playbooks | [Ransomware, Konto, Daten, Cloud, OT, Lieferant] |
| Übungen | [Plan, Teilnehmer, Ergebnisse, Maßnahmen] |
Notfallkonten, Werkzeuge und Kontaktlisten werden gegen unberechtigten Zugriff geschützt und so bereitgehalten, dass sie auch bei Ausfall der normalen Umgebung verfügbar sind.
Die Incident-Leitung veranlasst:
Das Lagebild trennt mindestens:
| Kategorie | Inhalt |
|---|---|
| Bestätigte Fakten | Durch nachvollziehbare Quellen belegte Erkenntnisse |
| Unbestätigte Hinweise | Plausible, aber noch nicht verifizierte Beobachtungen |
| Hypothesen | Mögliche Ursachen, Eintrittswege oder Auswirkungen |
| Betroffenheit | Assets, Daten, Personen, Kunden, Standorte, Lieferanten und Prozesse |
| Auswirkungen | Aktuelle und potenzielle Schäden oder Ausfälle |
| Maßnahmen | Geplant, freigegeben, in Umsetzung, erfolgreich oder zurückgenommen |
| Entscheidungen | Entscheidung, Zeitpunkt, verantwortliche Rolle und Begründung |
| Offene Fragen | Benötigte Informationen, Owner und Zieltermin |
| Fristen | Interne, gesetzliche und vertragliche Prüfpunkte |
Die Zeitlinie verwendet eine festgelegte Zeitzone. Nachträgliche Änderungen bleiben erkennbar; ursprüngliche Einträge werden nicht spurlos überschrieben.
Vor einer Eindämmungsmaßnahme werden – soweit die Dringlichkeit dies zulässt – bewertet:
| Bereich | Beispiele – nur nach Lagebewertung |
|---|---|
| Identitäten | Konto sperren, Sitzungen widerrufen, Zugangsschlüssel rotieren, privilegierte Zugriffe begrenzen |
| Endgeräte/Server | Vom Netz isolieren, Fernzugriff sperren, Systemzustand erhalten, kontrollierte Abschottung |
| Netzwerk | Segment sperren, Regel anpassen, Indikatoren blockieren, ausgehende Verbindung begrenzen |
| Cloud/SaaS | Token widerrufen, Freigaben einschränken, Schlüssel rotieren, verdächtige App-Integration deaktivieren |
| Nachricht zurückziehen/quarantänisieren, Absender/URL blockieren, betroffene Konten schützen | |
| OT/Produktion | In abgestimmten sicheren Zustand wechseln; Arbeitssicherheit und Anlagenverantwortung einbinden |
| Physisch | Bereich sichern, Zutritt sperren, Schlüssel/Ausweise deaktivieren, Datenträger schützen |
| Lieferant | Schnittstelle kontrolliert begrenzen, Notfallklausel aktivieren, zusätzliche Nachweise anfordern |
Ein Gerät wird nicht allein zur „Sicherheit“ ausgeschaltet oder neu gestartet, wenn dadurch flüchtige Daten, Wiederherstellbarkeit oder Betriebssicherheit gefährdet werden können. Die technische Einsatzleitung entscheidet anhand der Lage; bei unmittelbarer Gefahr gilt die örtliche Notfallregel.
Kurzfristige Eindämmung darf notwendige langfristige Bereinigung nicht ersetzen. Verbleibende Risiken und temporäre Ausnahmen werden dokumentiert, befristet und nachverfolgt.
Die Bereinigung umfasst abhängig vom Vorfall:
| Prüffeld | Ergebnis/Nachweis |
|---|---|
| Ursache beziehungsweise Eintrittsweg behandelt | [Ja/Nein/teilweise – Begründung] |
| Schadkomponenten und Persistenz entfernt | [Prüfung/Nachweis] |
| Identitäten und Geheimnisse abgesichert | [Prüfung/Nachweis] |
| Schwachstellen behoben/kompensiert | [Maßnahme/Referenz] |
| Weitere Betroffenheit geprüft | [Scope/Methode/Ergebnis] |
| Überwachung angepasst | [Regel/Alarm/Zeitraum] |
| Restrisiko bewertet | [Risikoreferenz/Entscheidung] |
Wenn die Ursache nicht sicher geklärt werden kann, werden Unsicherheit, zusätzliche Überwachung, Wiederanlaufbeschränkungen und Entscheidung ausdrücklich dokumentiert.
Ein betroffenes System oder ein Prozess wird erst wieder produktiv genutzt, wenn:
| Freigabefeld | Entscheidung |
|---|---|
| Technische Einsatzleitung | [Freigabe/Ablehnung, Datum, Begründung] |
| System-/Asset-Owner | [Freigabe/Ablehnung, Datum, Begründung] |
| Informationssicherheit | [Freigabe/Auflagen, Datum, Begründung] |
| Datenschutz/Recht, soweit erforderlich | [Prüfergebnis/Auflagen] |
| Geschäfts-/Krisenleitung bei S1/S2 | [Entscheidung/Auflagen] |
| Verstärkte Überwachung bis | [Datum/Uhrzeit/Kriterien] |
| Rückfallplan | [Link/Verantwortung] |
Eine Wiederinbetriebnahme unter Zeitdruck wird nicht als stillschweigende Risikoakzeptanz behandelt. Abweichungen benötigen eine dokumentierte, befristete Entscheidung durch die zuständige Risikorolle.
Ein Vorfall wird erst geschlossen, wenn:
| Abschnitt | Mindestinhalt |
|---|---|
| Zusammenfassung | Was ist passiert und welche Auswirkungen wurden bestätigt? |
| Zeitlinie | Kenntnis, Eskalationen, Maßnahmen, Entscheidungen und Wiederanlauf |
| Ursache und Beitragende Faktoren | Bestätigte Ursache, Kontrollschwächen und organisatorische Faktoren |
| Betroffenheit | Assets, Daten, Personen, Kunden, Standorte, Lieferanten und Prozesse |
| Reaktion | Analyse, Eindämmung, Bereinigung und Wiederherstellung |
| Kommunikation/Meldungen | Zielgruppe, Inhalt, Entscheidung, Versand und Nachweis |
| Wirksamkeit | Was funktionierte, was verzögerte oder erschwerte die Reaktion? |
| Restrisiken | Verbleibende Risiken, Ausnahmen und Überwachung |
| Verbesserungen | Maßnahme, Owner, Priorität, Termin und Wirksamkeitsprüfung |
Lessons Learned dienen der Verbesserung und nicht der vorschnellen Schuldzuweisung. Personelle oder rechtliche Sachverhalte werden getrennt, vertraulich und durch befugte Rollen behandelt.
| Entscheidung | Vorschlag durch | Freigabe/Bestätigung |
|---|---|---|
| Aktivierung und erste Stufe | Meldungsannahme/ISMS/IT | Incident-Leitung |
| Wechsel zu S1/S2 | Incident-Leitung | Krisen-/Geschäftsleitung informieren beziehungsweise einbinden |
| Betriebswirksame Eindämmung | Technische Einsatzleitung | Incident-Leitung und betroffener Asset-/Prozess-Owner |
| Abschaltung kritischer Systeme | Technische Einsatzleitung | Incident-/Krisenleitung und Betriebsverantwortung; Notfallbefugnis beachten |
| Externe Forensik/IR-Unterstützung | Incident-Leitung | Befugte Beschaffungs-/Geschäftsrolle |
| Meldung an Behörde | Datenschutz/Recht/Compliance | Gesetzlich zuständige und intern autorisierte Rolle |
| Kunden-/Lieferanteninformation | Vertrags-/Kunden-Owner | Recht/Incident-/Geschäftsleitung nach Kommunikationsregel |
| Öffentliche Aussage | Kommunikation | Geschäftsleitung und Recht |
| Wiederanlauf | Technische Einsatzleitung | Asset-/Prozess-Owner und erforderliche Sicherheits-/Geschäftsrollen |
| Risikoakzeptanz/Abweichung | Risk Owner | Gemäß Risikomethodik und Befugnismodell |
| Incident-Abschluss | Incident-Leitung | ISMS und betroffener Asset-/Prozess-Owner; bei S1/S2 Geschäftsleitung |
Entscheidungen werden mit Zeitpunkt, verfügbaren Fakten, Alternativen, Restrisiko und verantwortlicher Rolle protokolliert.
| Zielgruppe | Zweck | Verantwortung | Freigabe | Nachweis |
|---|---|---|---|---|
| Response-Team | Koordination und Aufgaben | Incident-Leitung | Incident-Leitung | Lageprotokoll |
| Geschäfts-/Krisenleitung | Entscheidung und Ressourcen | Incident-Leitung | Incident-Leitung | Lagebericht |
| Beschäftigte | Handlungsanweisung/Information | Kommunikation/Personal | Incident-Leitung und zuständige Fachrolle | Freigegebene Mitteilung |
| Kunden/Partner | Vertragliche oder sachlich erforderliche Information | Kunden-/Vertrags-Owner | Recht und Geschäfts-/Incident-Leitung | Versandnachweis |
| Datenschutzaufsicht/betroffene Personen | Gesetzliche Prüfung und gegebenenfalls Meldung/Benachrichtigung | Datenschutz/Verantwortlicher | Zuständige autorisierte Rolle | Meldenachweis |
| BSI/andere Behörde | Prüfung und gegebenenfalls gestufte Meldung | Compliance/ISMS/Recht | Zuständige autorisierte Rolle | Meldenachweis |
| Versicherer | Deckungs- und Mitwirkungsbedingungen | Versicherung/Finanzen/Recht | Zuständige autorisierte Rolle | Vorgangsreferenz |
| Öffentlichkeit/Medien | Konsistente öffentliche Aussage | Kommunikation | Geschäftsleitung und Recht | Freigegebene Aussage |
Vorlagen dürfen nur genutzt werden, wenn Fakten, Empfänger, Rechtsgrundlage, Schutzbedarf und Freigabe für den konkreten Vorfall geprüft wurden.
Die Incident-Leitung startet unmittelbar nach der Triage die Fristenprüfung. Sie entscheidet externe Meldungen nicht allein, sondern weist die Prüfung den zuständigen Rollen zu.
Das führende Lageprotokoll enthält mindestens:
| Prüffeld | Dokumentation |
|---|---|
| Kenntniszeitpunkt | [Datum/Uhrzeit/Zeitzone und Begründung] |
| Mögliche Rechts-/Vertragsgrundlage | [Referenz] |
| Zuständige Prüferrolle | [Rolle/Name] |
| Früheste/kürzeste mögliche Frist | [Datum/Uhrzeit] |
| Entscheidung und Begründung | [Melden/nicht melden/noch offen] |
| Freigabe und Versand | [Rolle, Zeitpunkt, Empfänger, Nachweis] |
| Folgemeldungen/Statusberichte | [Termin, Owner, Status] |
Die konkreten gesetzlichen und vertraglichen Auslöser, Fristen und Zuständigkeiten werden im Meldeweg für Sicherheitsvorfälle und im Rechts- und Vertragskataster gepflegt. Keine Frist darf aus einer pauschalen Annahme abgeleitet werden; zugleich darf eine ungeklärte Anwendbarkeit die frühe Prüfung nicht verzögern.
| Evidence-ID | Beschreibung/Quelle | Erhoben durch | Datum/Zeit/Zeitzone | Integritätsnachweis | Übergaben | Geschützter Ablageort |
|---|---|---|---|---|---|---|
[EVI-JJJJ-NNN] |
[Artefakt/Quelle] |
[Rolle/Name] |
[Zeitpunkt] |
[Hash/Methode] |
[Chain of Custody] |
[Link/Referenz] |
Zugangsdaten, Geheimnisse und besonders sensible Inhalte werden nicht ungeschützt in Tickets oder Wiki-Seiten eingefügt.
Für wiederkehrende Szenarien werden separate, getestete Playbooks geführt:
| Szenario | Erste besondere Prüfpunkte | Playbook-Status |
|---|---|---|
| Phishing/Kontokompromittierung | Sitzungen, MFA, Weiterleitungen, OAuth-Apps, privilegierte Nutzung, betroffene Nachrichten | [Zu erstellen/Link] |
| Ransomware/Schadsoftware | Ausbreitung, Netzwerkisolation, Backups, Identitäten, Erpressungskommunikation, Meldepflichten | [Zu erstellen/Link] |
| Datenabfluss/Fehlversand | Datenarten, Empfänger, Abruf/Widerruf, Personen-/Kundenbezug, Nachweis | [Zu erstellen/Link] |
| Cloud-/SaaS-Vorfall | Tenant, Token, Schlüssel, Protokolle, Provider-Support, Regionen und Unterauftragnehmer | [Zu erstellen/Link] |
| Schwachstelle/Zero-Day | Exposition, Ausnutzbarkeit, Kompensation, Patch, Lieferanteninformation und Monitoring | [Zu erstellen/Link] |
| Verlust/Diebstahl | Verschlüsselung, Fernsperre/-löschung, Zugangsmittel, physische Informationen, Anzeigeentscheidung | [Zu erstellen/Link] |
| OT-/Produktionsvorfall | Arbeitssicherheit, Anlagenzustand, Segmentierung, Herstellerfreigaben und manueller Betrieb | [Zu erstellen/Link] |
| Lieferanten-/Supply-Chain-Vorfall | Eigene Exposition, Schnittstellen, Zugang, Vertragsrechte, Nachweise und Alternativen | [Zu erstellen/Link] |
| Physischer Sicherheitsvorfall | Personenschutz, Zutritt, Schlüssel, Aufzeichnungen, Standort- und Behördenwege | [Zu erstellen/Link] |
Playbooks konkretisieren dieses Verfahren, dürfen dessen Rollen-, Freigabe-, Dokumentations- und Kommunikationsregeln aber nicht stillschweigend außer Kraft setzen.
Bei externem Bezug werden geprüft:
Die Verantwortung für eigene Entscheidungen und Pflichten wird nicht vollständig auf einen Lieferanten übertragen.
Bei möglicher Betroffenheit werden mindestens geprüft:
Alle 46 Informationssicherheitsfragen des ISA-Reiters „Informationssicherheit“ müssen umgesetzt und bewertet werden. Es gibt keine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der ISO-Statement-of-Applicability. Erkenntnisse aus Vorfällen werden in allen betroffenen Fragen bewertet und in der VDA-ISA-Selbsteinschätzung sowie im Maßnahmenplan und Reifegrad aktualisiert.
TISAX bedeutet nicht automatisch, dass jeder interne Vorfall an ENX oder einen Audit-Provider gemeldet wird. Teilnahmebedingungen, Assessmentstatus, Kundenverträge und bestätigte Verfahrensvorgaben sind für den konkreten Fall zu prüfen.
Incident-ID:
[INC-JJJJ-NNN]Stand:
[Datum/Uhrzeit/Zeitzone]Einstufung:
[S1–S4]Incident-Leitung:
[Rolle/Name]Nächste Aktualisierung:
[Datum/Uhrzeit]
[Fakt mit Quelle][Bestätigt/möglich – Asset, Prozess, Daten, Kunde, Person, Standort][Maßnahme, Ergebnis, Zeitpunkt]| Maßnahme | Owner | Zielzeit | Status | Ergebnis/Risiko |
|---|---|---|---|---|
[Maßnahme] |
[Rolle] |
[Zeit] |
[Offen/Läuft/Erledigt/Blockiert] |
[Ergebnis] |
[Entscheidung/Bedarf, zuständige Rolle, Termin][Prüfung, Frist, Owner, Status][Frage, Owner, Zielzeit]| Übung/Prüfung | Mindestinhalt | Turnus im Entwurf | Nachweis |
|---|---|---|---|
| Kontakt- und Alarmierungstest | Erreichbarkeit, Vertretung, Ausfallkanal | Mindestens halbjährlich | Testprotokoll |
| Tabletop S1/S2 | Lageführung, Entscheidungen, Kommunikation und Fristen | Mindestens jährlich | Übungsbericht |
| Technische Übung | Analyse, Isolation, Protokolle und Beweissicherung | Risikoorientiert, mindestens jährlich | Technischer Nachweis |
| Restore-/Wiederanlauftest | Backup-Integrität, Wiederaufbau, Freigabe und Monitoring | Nach BCM-/Backup-Plan | Testprotokoll |
| Lieferantenübung | Kontakt, Eskalation, Datenbereitstellung und Vertragswege | Risikoorientiert | Übungs-/Lieferantennachweis |
| Lessons-Learned-Nachverfolgung | Maßnahmenabschluss und Wirksamkeit | Nach jedem wesentlichen Vorfall/Übung | Maßnahmenstatus |
| Kennzahl | Definition | Zielwert |
|---|---|---|
| Zeit bis Annahme | Eingang bis bestätigte Annahme | [Festzulegen] |
| Zeit bis Triage | Eingang bis dokumentierte Ersteinstufung | [Festzulegen] |
| Zeit bis Eindämmungsentscheidung | Aktivierung bis dokumentierte Entscheidung | [Festzulegen je Stufe] |
| Zeit bis Eindämmung | Aktivierung bis wirksame Begrenzung | [Festzulegen je Szenario] |
| Wiederherstellungszeit | Ausfall bis freigegebener Wiederanlauf | [Gemäß Kritikalität/BCM] |
| Fristgerechte Prüfungen/Meldungen | Rechtzeitig abgeschlossene Prüfungen beziehungsweise Meldungen | 100 % |
| Abschlussberichte | Fristgerecht freigegebene Berichte für relevante Vorfälle | [Festzulegen] |
| Überfällige Verbesserungsmaßnahmen | Offene Maßnahmen nach Zieltermin | 0 kritische; übrige Zielwerte festzulegen |
| Übungsabdeckung | Durchgeführte gegenüber geplanten Übungen | 100 % des freigegebenen Plans |
Kennzahlen werden nicht durch unbestätigte oder unvollständige Daten als erfüllt dargestellt. Messmethode, Datenquelle, Ausnahmen und Auswertungszeitraum werden dokumentiert.
| Erkenntnis/Auswirkung | Folgemaßnahme |
|---|---|
| Neues oder verändertes Asset | Asset-Inventar aktualisieren |
| Neues/verändertes Risiko | Risikoregister aktualisieren |
| Zusätzliche Behandlung erforderlich | Risikobehandlungsplan ergänzen |
| Kontrollgestaltung betroffen | Statement of Applicability prüfen |
| Rechts-/Vertragsanforderung betroffen | Rechts- und Vertragskataster aktualisieren |
| TISAX-Bewertung betroffen | VDA-ISA-Selbsteinschätzung und Maßnahmenplan aktualisieren |
| Abweichung/Korrektur erforderlich | Abweichungen und Korrekturmaßnahmen erfassen |
| Auditprogramm betroffen | Auditprogramm risikoorientiert anpassen |
| Managemententscheidung erforderlich | Managementbewertung vorbereiten |
| Kontinuität/Wiederanlauf betroffen | Notfallvorsorge und BCM aktualisieren |
| Rollen/Awareness betroffen | Schulungs-, Rollen- und Kommunikationsmaßnahmen aktualisieren |
Für relevante Vorfälle werden abhängig von Umfang und Schutzbedarf aufbewahrt:
| Nachweisbereich | Geschützte Ablage | Zugriff | Aufbewahrung |
|---|---|---|---|
| Vorfallsakte | [System/Pfad] |
[Rollen] |
[Frist/Regel] |
| Forensische Daten | [System/Pfad] |
[Rollen] |
[Frist/Regel] |
| Externe Meldungen | [System/Pfad] |
[Rollen] |
[Frist/Regel] |
| Lessons Learned/Maßnahmen | [System/Pfad] |
[Rollen] |
[Frist/Regel] |
| Prüffrage | Status Entwurf |
|---|---|
| Sind Incident-Leitung, Stellvertretung und Rufbereitschaft namentlich beziehungsweise funktional besetzt? | Nein |
| Sind Kontakt- und Ausfallkanäle getestet? | Nein |
| Sind Entscheidungs- und Notfallbefugnisse freigegeben? | Nein |
| Sind Incident-Ticket, Lageprotokoll und geschützte Ablagen eingerichtet? | Nein |
| Sind Protokollzugriff und Beweissicherung technisch vorbereitet? | Nein |
| Sind externe Forensik, Versicherer und wichtige Lieferanten erreichbar und vertraglich geprüft? | Nein |
| Sind Wiederanlaufkriterien mit BCM, IT und Fachbereichen abgestimmt? | Nein |
| Sind rechtliche und vertragliche Fristen im Kataster bestätigt? | Nein |
| Sind mindestens die priorisierten Szenario-Playbooks vorhanden? | Nein |
| Wurde eine End-to-End-Übung erfolgreich durchgeführt? | Nein |
| Sind aus der Übung entstandene kritische Mängel geschlossen? | Nein |
| Liegt eine dokumentierte fachliche Prüfung und Freigabe vor? | Nein |
Eine Freigabe ist erst vertretbar, wenn Abweichungen dokumentiert, verantwortet und mit Termin behandelt werden. Der Dokumentstatus darf nicht allein aufgrund der Erstellung auf „freigegeben“ gesetzt werden.
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Musterverfahren für Incident Response erstellt | Incident-Management-Verantwortliche/r | Ausstehend | – |
Maßgeblich bleiben die aktuellen amtlichen Rechtsquellen, bestätigten Verträge und Kundenanforderungen, die freigegebenen organisatorischen Rollen und Befugnisse sowie die gültigen TISAX-Verfahrensunterlagen. Dieses Muster ersetzt keine fallbezogene Rechtsberatung oder technische Einsatzentscheidung.