Incident Response Plan erstellen: Vorlage und Praxisbeispiel

Warum ein Incident Response Plan kein Nice-to-have ist

Der Ransomware-Angriff trifft das Unternehmen am Donnerstagabend um 22:15 Uhr. Der IT-Leiter bemerkt es am Freitagmorgen, als die ersten Mitarbeiter sich nicht mehr anmelden können. Er ruft den Geschäftsführer an, der gerade auf einer Messe ist. Der Geschäftsführer fragt: Was sollen wir tun? Der IT-Leiter weiß es technisch, aber organisatorisch fehlen alle Grundlagen. Wer informiert die Kunden? Wer spricht mit der Presse, wenn sie anruft? Wer meldet ans BSI? Wer entscheidet, ob das Lösegeld gezahlt wird? Und wer koordiniert das alles, während die IT gleichzeitig versucht, den Schaden einzugrenzen?

Ohne einen Incident Response Plan sind das alles offene Fragen in einem Moment, in dem du keine Zeit für offene Fragen hast. Jede Minute, die du mit Klärung von Zuständigkeiten verbringst, ist eine Minute, in der sich der Angriff ausbreiten kann, in der Fristen verstreichen und in der das Vertrauen von Kunden und Partnern erodiert.

Ein Incident Response Plan, kurz IRP, löst dieses Problem. Er definiert im Voraus, wer was tut, in welcher Reihenfolge, mit welchen Ressourcen und über welche Kommunikationswege. Er ist kein theoretisches Dokument für die Schublade, sondern ein operativer Leitfaden, der im Krisenfall funktionieren muss.

NIS2 fordert in Artikel 21 explizit die Bewältigung von Sicherheitsvorfällen als eine der zehn Mindestmaßnahmen. ISO 27001 widmet dem Thema die Controls A.5.24 bis A.5.28. Und die DSGVO setzt mit ihren 72-Stunden-Meldefristen voraus, dass du einen funktionierenden Meldeprozess hast. Ein IRP ist also nicht nur operativ sinnvoll, sondern regulatorisch gefordert.

Was ein Incident Response Plan ist und was nicht

Ein IRP ist kein allgemeiner Notfallplan, kein Business-Continuity-Plan und kein Disaster Recovery Plan. Er grenzt sich folgendermaßen ab:

In der Praxis greifen diese Dokumente ineinander. Bei einem schweren Ransomware-Angriff startest du mit dem IRP, aktivierst parallel den BCP, um den Geschäftsbetrieb aufrechtzuerhalten, und nutzt den DRP für die technische Wiederherstellung. Der IRP ist dabei das Dokument, das als erstes zum Einsatz kommt und die initiale Reaktion steuert.

Ein guter IRP für ein mittelständisches Unternehmen hat 15 bis 25 Seiten. Nicht 5 (zu oberflächlich) und nicht 80 (liest im Ernstfall niemand). Er muss so geschrieben sein, dass jemand unter Stress die relevanten Informationen in unter zwei Minuten findet. Klare Gliederung, Checklisten, Kontaktlisten und Entscheidungsbäume statt Fließtext.

Aufbau und Gliederung eines IRP

Ein vollständiger Incident Response Plan gliedert sich in acht Abschnitte. Jeder Abschnitt hat eine klare Funktion und sollte eigenständig nutzbar sein, damit du im Ernstfall direkt zum relevanten Kapitel springen kannst.

Abschnitt 1: Zweck und Geltungsbereich

Hier definierst du, wofür der Plan gilt und wofür nicht.

Zweck: Der IRP beschreibt den strukturierten Ablauf bei der Erkennung, Bewertung, Eindämmung, Beseitigung und Nachbereitung von Sicherheitsvorfällen im Unternehmen.

Geltungsbereich: Alle IT-Systeme, Netzwerke und Daten des Unternehmens, einschließlich Cloud-Dienste und extern gehosteter Systeme. Physische Sicherheitsvorfälle (Einbruch, Brand) werden im separaten Krisenmanagementplan behandelt, sofern sie keine IT-Komponente haben.

Definition Sicherheitsvorfall: Ein Sicherheitsvorfall ist jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationswerten des Unternehmens tatsächlich oder potenziell beeinträchtigt.

Abschnitt 2: Rollen und Verantwortlichkeiten

Das Herzstück des IRP. Hier wird festgelegt, wer welche Aufgabe übernimmt. In einem Unternehmen mit 50 bis 200 Mitarbeitern sind vier Kernrollen erforderlich, wobei Personen mehrere Rollen bündeln können.

Rolle 1: Incident Manager

Der Incident Manager ist die zentrale Koordinationsstelle während eines Vorfalls. Er oder sie hat die Gesamtverantwortung für die Vorfallsbehandlung und trifft operative Entscheidungen.

In einem Unternehmen mit 80 Mitarbeitern ist der Incident Manager oft der IT-Leiter oder der ISB. Wichtig ist, dass diese Person Entscheidungsbefugnis hat, ohne bei jeder Maßnahme die Geschäftsführung fragen zu müssen. Wenn der Incident Manager um 22 Uhr entscheidet, das Netzwerk vom Internet zu trennen, muss das innerhalb seiner Befugnisse liegen.

Rolle 2: Technisches Response-Team

Das Team, das die operative Arbeit leistet: Analyse, Eindämmung, Beseitigung, Wiederherstellung.

Für ein mittelständisches Unternehmen bedeutet das realistischerweise: zwei bis drei IT-Mitarbeiter aus dem bestehenden Team plus ein externer Dienstleister, der bei schweren Vorfällen hinzugezogen werden kann. Tools wie ISMS Lite helfen dabei, Rollen, Kontaktdaten und Eskalationsstufen zentral zu pflegen, sodass im Ernstfall alle Informationen sofort griffbereit sind. ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro, ohne Seat-Lizenzen oder versteckte Kosten erhältst du alle Module inklusive Incident-Management. Diesen Dienstleister solltest du vor dem Ernstfall unter Vertrag nehmen, nicht erst während der Krise suchen. Ein Retainer-Vertrag mit einem Incident-Response-Dienstleister kostet einen niedrigen vierstelligen Betrag pro Jahr und sichert dir Reaktionszeiten von wenigen Stunden. Die Anforderungen an externe Partner solltest du in einer Lieferanten-Sicherheitsrichtlinie festhalten.

Rolle 3: Kommunikationsverantwortlicher

Unterschätzt und im Ernstfall entscheidend. Jemand muss die interne und externe Kommunikation steuern, während die Techniker den Vorfall bearbeiten.

In vielen mittelständischen Unternehmen gibt es keine PR-Abteilung. Dann fällt diese Rolle der Geschäftsführung oder einer vertrauenswürdigen Führungskraft zu. Entscheidend ist, dass es genau eine Person gibt, die für Kommunikation zuständig ist. Wenn drei verschiedene Leute unterschiedliche Aussagen machen, verschärft das die Krise.

Rolle 4: Management-Liaison

Die Verbindung zwischen dem Incident-Response-Team und der Geschäftsleitung.

Abschnitt 3: Eskalationsstufen

Nicht jeder Vorfall erfordert das gleiche Maß an Aufmerksamkeit und Ressourcen. Drei klar definierte Eskalationsstufen helfen, die Reaktion proportional zum Vorfall zu gestalten.

Stufe 1: Standard-Incident

Stufe 2: Erhöhter Incident

Stufe 3: Krise

Abschnitt 4: Ablaufphasen

Der operative Kern des IRP beschreibt die sechs Phasen der Vorfallsbehandlung. Jede Phase hat klare Eingangsbedingungen, Aktivitäten und Ergebnisse.

Phase 1 - Erkennung und Meldung: Sicherheitsvorfälle werden über technisches Monitoring, Mitarbeiter-Meldungen oder externe Hinweise erkannt. Jede Meldung wird im Ticketsystem erfasst und dem Incident Manager zugewiesen. Ziel: Innerhalb von 15 Minuten liegt eine erste Einschätzung vor, ob es sich um einen echten Vorfall handelt.

Phase 2 - Erstbewertung und Klassifizierung: Der Incident Manager bewertet den Vorfall anhand der Schweregrad-Skala (1-10) und ordnet die passende Eskalationsstufe zu. Er aktiviert die entsprechenden Rollen und informiert die Beteiligten. Ziel: Innerhalb von 30 Minuten stehen Schweregrad, Eskalationsstufe und aktivierte Ressourcen fest.

Phase 3 - Eindämmung: Das technische Team stoppt die Ausbreitung des Vorfalls. Kurzfristige Maßnahmen (Systeme isolieren, Konten sperren) werden sofort umgesetzt. Langfristige Maßnahmen (temporäre Workarounds, forensische Sicherung) folgen parallel. Ziel: Die Ausbreitung ist gestoppt, Beweise sind gesichert.

Phase 4 - Beseitigung: Die Ursache des Vorfalls wird identifiziert und eliminiert. Malware wird entfernt, Schwachstellen werden gepatcht, kompromittierte Credentials werden rotiert. Ziel: Der Angriffsvektor ist geschlossen, alle Artefakte sind entfernt.

Phase 5 - Wiederherstellung: Systeme werden schrittweise wieder in Betrieb genommen, beginnend mit den geschäftskritischsten. Jedes System wird nach dem Hochfahren intensiv überwacht. Ziel: Normalbetrieb ist wiederhergestellt, erhöhtes Monitoring läuft.

Phase 6 - Nachbereitung: Innerhalb von zwei Wochen nach Abschluss findet ein Lessons-Learned-Workshop statt. Die Vorfallsdokumentation wird vervollständigt. Verbesserungsmaßnahmen werden definiert, priorisiert und in die Umsetzung gegeben. Ziel: Der IRP und die Sicherheitsmaßnahmen werden auf Basis der gewonnenen Erkenntnisse verbessert.

Abschnitt 5: Kommunikationsplan

Die Kommunikation während eines Sicherheitsvorfalls ist mindestens so wichtig wie die technische Reaktion. Schlechte Kommunikation verstärkt Krisen, gute Kommunikation begrenzt Schäden. Der Kommunikationsplan regelt, wer wann wen über welchen Kanal informiert.

Interne Kommunikation:

Externe Kommunikation:

Sprachregelungen:

Definiere im Voraus, was nach außen kommuniziert werden darf und was nicht. Als Grundregel gilt:

• Bestätige den Vorfall faktisch, ohne technische Details preiszugeben
• Beschreibe die ergriffenen Maßnahmen auf hoher Ebene
• Gib keine Informationen über den Angriffsvektor oder die Angreifer heraus
• Mache keine Aussagen über den Umfang des Schadens, bevor die Analyse abgeschlossen ist
• Alle externe Kommunikation wird vor Versand vom Kommunikationsverantwortlichen freigegeben

Eine vorbereitete Sprachregelung für den häufigsten Fall, einen Ransomware-Angriff, könnte wie folgt aufgebaut sein:

Gegenüber Kunden: "Wir haben am [Datum] einen Sicherheitsvorfall in unserer IT-Infrastruktur festgestellt. Wir haben sofort Gegenmaßnahmen eingeleitet und arbeiten mit externen Spezialisten an der Aufklärung und Behebung. [Konkreter Hinweis auf Auswirkungen für den Kunden]. Wir informieren dich, sobald weitere Erkenntnisse vorliegen."

Gegenüber Presse: "Wir können bestätigen, dass es einen Sicherheitsvorfall gegeben hat. Die Aufklärung läuft. Wir kooperieren mit den zuständigen Behörden. Zum Schutz der laufenden Untersuchung können wir zu diesem Zeitpunkt keine weiteren Details nennen."

Abschnitt 6: Kontaktliste

Die wichtigste Seite des gesamten Plans. In einer Krise muss jeder Beteiligte in unter einer Minute erreichbar sein. Diese Liste muss aktuell gehalten werden und sowohl digital als auch ausgedruckt verfügbar sein - denn bei einem Ransomware-Angriff ist das digitale Adressbuch möglicherweise nicht zugänglich.

Drucke diese Liste aus und lege sie an mindestens drei physischen Orten im Unternehmen ab: Büro des IT-Leiters, Büro der Geschäftsführung und Serverraum. Wenn die IT verschlüsselt ist und du die Nummern nur digital gespeichert hattest, stehst du vor einem vermeidbaren Problem.

Abschnitt 7: Werkzeuge und Ressourcen

Liste auf, welche Tools und Ressourcen dem Incident-Response-Team zur Verfügung stehen. Dazu gehören:

Technische Werkzeuge:

• SIEM-System: [Name, Zugang]
• EDR-Lösung: [Name, Admin-Zugang]
• Forensik-Tools: [Live-USB, Disk-Imaging-Software]
• Netzwerk-Analyse: [Wireshark, tcpdump, Netflow-Analyse]
• Log-Management: [Zentraler Log-Server, Zugang]
• Backup-System: [Name, Zugang, Standort der Offline-Backups]

Organisatorische Ressourcen:

• Meldeformular BSI: [URL, Zugangsdaten]
• Meldeformular Datenschutz-Aufsichtsbehörde: [URL, Zugangsdaten]
• Vorfallsdokumentations-Vorlage: [Speicherort]
• Kommunikationsvorlagen: [Speicherort]
• Retainer-Vertrag externer IR-Dienstleister: [Vertragsnummer, Aktivierungsprozess]
• Cyber-Versicherungspolice: [Vertragsnummer, gedeckte Leistungen, Schadensmeldeprozess]

Ausweich-Kommunikation: Was passiert, wenn E-Mail und Teams/Slack nicht mehr funktionieren? Definiere einen alternativen Kommunikationskanal. Das kann eine Signal-Gruppe sein, ein privater WhatsApp-Kanal oder im Notfall einfach Telefon. Der Kanal muss vorab eingerichtet und allen Beteiligten bekannt sein.

Abschnitt 8: Pflege und Tests

Ein IRP ist ein lebendes Dokument. Er muss regelmäßig aktualisiert und getestet werden, sonst veraltet er und versagt im Ernstfall.

Review-Zyklus: Mindestens jährlich, zusätzlich nach jedem tatsächlichen Vorfall und bei wesentlichen Änderungen an der IT-Infrastruktur oder Organisationsstruktur.

Verantwortlich für Pflege: Der ISB oder der benannte Incident Manager.

Versionierung: Jede Änderung wird versioniert. Die aktuelle Version ist klar gekennzeichnet. Alte Versionen werden archiviert, aber nicht gelöscht.

Ein Muster-IRP zum Mitnehmen

Hier die komprimierte Struktur eines IRP, die du als Ausgangspunkt für dein eigenes Dokument verwenden kannst. Ergänze die Platzhalter mit deinen unternehmensspezifischen Daten.

Deckblatt und Metadaten

Gliederung des Dokuments

1. Zweck und Geltungsbereich (1 Seite)

   • Warum existiert dieser Plan
   • Welche Systeme und Standorte sind abgedeckt
   • Definition Sicherheitsvorfall
   • Abgrenzung zu BCP, DRP und Krisenmanagementplan

2. Rollen und Verantwortlichkeiten (2-3 Seiten)

   • Incident Manager (inkl. Befugnisse und Stellvertreter)
   • Technisches Response-Team (inkl. Mindestbesetzung)
   • Kommunikationsverantwortlicher
   • Management-Liaison
   • Externe Partner (IR-Dienstleister, Anwalt, Versicherung)

3. Schweregrad-Skala und Eskalationsstufen (2 Seiten)

   • Schweregrad 1-10 mit Beispielen
   • Stufe 1 Standard, Stufe 2 Erhöht, Stufe 3 Krise
   • Aktivierte Rollen je Stufe
   • Reaktionszeiten je Stufe
   • Befugnisse je Stufe

4. Ablaufphasen (3-4 Seiten)

   • Phase 1: Erkennung und Meldung
   • Phase 2: Erstbewertung und Klassifizierung
   • Phase 3: Eindämmung (kurzfristig und langfristig)
   • Phase 4: Beseitigung
   • Phase 5: Wiederherstellung
   • Phase 6: Nachbereitung und Lessons Learned
   • Je Phase: Checkliste mit konkreten Aufgaben

5. Kommunikationsplan (2-3 Seiten)

   • Interne Kommunikationsmatrix
   • Externe Kommunikationsmatrix
   • Sprachregelungen (vorbereitet für Ransomware, Datenleck, DDoS)
   • Freigabeprozess für externe Kommunikation

6. Meldepflichten (1-2 Seiten)

   • NIS2: Fristen, Meldeportal, Inhalt
   • DSGVO: Fristen, Meldeportal, Inhalt
   • Entscheidungsbaum: Ist der Vorfall meldepflichtig?

7. Kontaktliste (1 Seite)

   • Alle Rollen mit Telefonnummern (dienstlich + privat)
   • Externe Dienstleister und Behörden
   • Ausweich-Kommunikationskanal

8. Werkzeuge und Ressourcen (1 Seite)

   • Technische Tools mit Zugangsinformationen
   • Formulare und Vorlagen mit Speicherorten
   • Ausweichsysteme und Offline-Ressourcen

9. Anhang (2-3 Seiten)

   • Vorfallsdokumentations-Vorlage
   • Checkliste Erstbewertung
   • Checkliste Meldepflicht-Check
   • Änderungshistorie

Den IRP testen: Übung macht den Unterschied

Ein IRP, der nie getestet wurde, gibt dir ein falsches Gefühl der Sicherheit. Du glaubst, vorbereitet zu sein, und entdeckst im Ernstfall, dass Telefonnummern veraltet sind, Befugnisse nicht geklärt sind und die Hälfte des Teams nicht weiß, wo der Plan liegt.

Testmethode 1: Tabletop-Übung

Die einfachste und effektivste Methode. Alle Beteiligten sitzen zusammen (oder im Videocall) und spielen ein Szenario durch, ohne tatsächlich Systeme anzufassen.

Ablauf einer Tabletop-Übung:

Vorbereitung (1 Stunde):

• Szenario auswählen und aufschreiben (Ransomware am Freitagabend ist ein Klassiker)
• Timeline mit Injections vorbereiten (neue Informationen, die im Lauf der Übung eingestreut werden)
• Beobachter benennen, der Notizen macht

Durchführung (2-3 Stunden):

• Moderator beschreibt die Ausgangssituation
• Teilnehmer erklären, was sie tun würden, basierend auf dem IRP
• Moderator streut neue Informationen ein (die Geschäftsführerin ist nicht erreichbar, der Backup-Server ist auch verschlüsselt, die Presse ruft an)
• Teilnehmer reagieren auf die neuen Entwicklungen
• Beobachter notiert Lücken, Verzögerungen und Unklarheiten

Auswertung (1 Stunde):

• Was hat funktioniert?
• Wo gab es Unklarheiten oder Stockungen?
• Welche Informationen fehlten?
• Welche Anpassungen am IRP sind notwendig?

Ein konkretes Tabletop-Szenario:

Donnerstag, 22:15 Uhr. Der Nachtschicht-Mitarbeiter im Lager bemerkt, dass das Warenwirtschaftssystem nicht mehr reagiert. Er ruft beim IT-Bereitschaftsdienst an.

Injection 1 (10 Minuten): Der IT-Mitarbeiter stellt fest, dass auf dem Server eine Ransomware-Note liegt. Die Angreifer fordern 200.000 Euro in Bitcoin. Drei weitere Server sind ebenfalls verschlüsselt.

Injection 2 (30 Minuten): Die Überprüfung zeigt, dass auch der Backup-Server betroffen ist. Die letzten sauberen Offline-Backups sind zwei Wochen alt. Das ERP-System mit allen Kundendaten ist verschlüsselt.

Injection 3 (60 Minuten): Ein Journalist einer Regionalzeitung ruft an und fragt nach dem Cyberangriff. Offenbar hat ein Mitarbeiter in sozialen Medien darüber geschrieben.

Injection 4 (90 Minuten): Die Angreifer posten Auszüge aus eurer Kundendatenbank im Darknet als Druckmittel. Name, Adresse und Bestellhistorie von 5.000 Kunden sind öffentlich sichtbar.

Dieses Szenario testet nahezu alle Aspekte des IRP: Erkennung außerhalb der Geschäftszeiten, Eskalation, Eindämmung, Kommunikation (intern, extern, Presse), Meldepflichten (NIS2 und DSGVO) und strategische Entscheidungen (Lösegeld ja oder nein). In ISMS Lite lassen sich solche Übungsszenarien dokumentieren und die daraus resultierenden Maßnahmen direkt als Tickets nachverfolgen.

Testmethode 2: Simulierter Vorfall

Einen Schritt weiter geht der simulierte Vorfall, bei dem tatsächlich Aktionen durchgeführt werden, allerdings in einer kontrollierten Umgebung:

• Ein simulierter Phishing-Angriff wird an das Unternehmen gesendet (vorher mit dem Management abgestimmt)
• Die Erkennung und Meldung durch Mitarbeiter wird beobachtet
• Der Incident-Response-Prozess wird durchlaufen, als wäre es ein echter Vorfall
• Erst nach Abschluss der Erstbewertung wird aufgelöst, dass es eine Übung war

Diese Methode ist aufwändiger, liefert aber realistischere Ergebnisse, weil die Beteiligten unter echtem Stress handeln.

Testfrequenz

Die fünf häufigsten Schwachstellen in Incident Response Plans

Aus der Praxis lassen sich typische Muster erkennen, an denen IRPs im Ernstfall scheitern:

Schwachstelle 1: Veraltete Kontaktdaten. Der häufigste und gleichzeitig vermeidbarste Fehler. Mitarbeiter wechseln die Abteilung, verlassen das Unternehmen, ändern ihre Telefonnummer. Wenn du im Ernstfall den Incident Manager anrufst und eine fremde Person drangeht, hast du ein Problem, das durch einen vierteljährlichen Kontaktlisten-Check vollständig vermeidbar gewesen wäre.

Schwachstelle 2: Unklare Befugnisse. Der IRP sagt, der Incident Manager entscheidet über die Eindämmung. Aber darf er das Netzwerk vom Internet trennen, wenn das die Produktion stoppt? Darf er ohne Rücksprache einen externen Dienstleister für 15.000 Euro beauftragen? Wenn Befugnisse nicht explizit dokumentiert und vom Management freigegeben sind, führen sie im Ernstfall zu Verzögerungen und Konflikten.

Schwachstelle 3: Kein Ausweich-Kommunikationskanal. Wenn die gesamte IT verschlüsselt ist, funktionieren auch E-Mail und Teams nicht mehr. Ohne einen vorab definierten alternativen Kanal, sei es eine Messenger-Gruppe, eine Telefonkette oder ein physisches Treffen, bricht die Koordination zusammen.

Schwachstelle 4: Fehlende Einbindung der Geschäftsführung. Wenn die Geschäftsführung den IRP nie gelesen hat und bei einer Krise zum ersten Mal von Meldepflichten und Eskalationsstufen hört, fehlt das Verständnis für die Dringlichkeit. Warum das Thema Awareness für Führungskräfte so wichtig ist, zeigt sich genau hier. Die Geschäftsführung muss den Plan kennen, die eigene Rolle verstanden haben und idealerweise mindestens einmal an einer Tabletop-Übung teilgenommen haben.

Schwachstelle 5: Der Plan liegt im verschlüsselten System. Eine Ironie, die häufiger vorkommt als man denkt: Der IRP ist nur als digitales Dokument auf dem Fileserver gespeichert, der bei einem Ransomware-Angriff nicht mehr zugänglich ist. Drucke den Plan aus, lege ihn an mehreren physischen Orten ab und stelle sicher, dass mindestens eine Person die Kontaktliste auch auf dem privaten Smartphone gespeichert hat.

Vom leeren Blatt zum fertigen IRP: Ein realistischer Zeitplan

Wenn du bei null anfängst und einen vollständigen IRP erstellen willst, ist das kein Monats-Projekt, aber auch keine Sache von einer Stunde. Hier ein realistischer Zeitplan für ein Unternehmen mit 50 bis 200 Mitarbeitern:

Nach acht Wochen hast du einen funktionsfähigen IRP. Er wird nicht perfekt sein, und das muss er auch nicht. Entscheidend ist, dass er existiert, dass die relevanten Personen ihn kennen und dass er regelmäßig getestet und verbessert wird.

Jede Tabletop-Übung wird Schwachstellen aufdecken, jeder tatsächliche Vorfall wird Anpassungen erfordern, und jedes Organisations-Update wird Aktualisierungen nötig machen. Das ist kein Zeichen von Unreife, sondern von einem lebendigen Prozess. Ein IRP, der sich nicht verändert, ist ein IRP, der nicht genutzt wird.

Weiterführende Artikel

• Sicherheitsvorfall erkennen, bewerten und melden – der komplette Ablauf
• Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand
• Notfallhandbuch für die IT: Aufbau, Inhalt und PDF-Vorlage
• Tabletop-Übung planen und durchführen: So testest du deinen Notfallplan
• NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat – was wann fällig ist

Der wichtigste Schritt ist der erste: Setz dich hin und schreib auf, wer bei einem Sicherheitsvorfall angerufen wird und was diese Person dann tun soll. Alles Weitere baut darauf auf.