Die 24-Stunden-Frist, die Ihren Betrieb retten kann

Willkommen bei IT for Business. Ich bin Mirko Peters.

Hier ist die Frage, die vor fast jedem Sicherheitsvorfall zu spät gestellt wird: Wann läuft die Frist eigentlich an? Nicht nach dem internen Krisenmeeting, nicht nach der Forensik und auch nicht dann, wenn endlich alle Details auf dem Tisch liegen. Die Frist beginnt in dem Moment, in dem Sie Kenntnis von einem meldepflichtigen Vorfall haben. Genau da versteckt sich das Risiko: verspätete Meldung, falsche Einstufung, lückenhafte Dokumentation. Wir klären jetzt Fristen, Sanktionen, persönliche Haftung und den sauberen Meldeweg zum BSI. Lassen Sie uns das Rauschen ausblenden und mit der eigentlichen Risikofrage anfangen.

Wer betroffen ist, irrt sich oft zuerst

Seien wir ehrlich: Viele Unternehmen steigen bei NIS2 mit der falschen Annahme ein, dass das Ganze nur klassische KRITIS-Betreiber betrifft – also Energie, Wasser, große Krankenhäuser oder offensichtliche Infrastruktur. Genau dort beginnt oft der erste Denkfehler, denn NIS2 zieht den Kreis deutlich weiter. Es erfasst nicht nur besonders wichtige Einrichtungen, sondern auch wichtige Einrichtungen in mehreren Sektoren. Was bedeutet das konkret für Sie? Die Einordnung läuft nicht nach Bauchgefühl und auch nicht nach dem Satz: „Wir sind doch nur Mittelstand.“ Sie hängt an drei Fragen. Erstens: In welchem Sektor sind Sie unterwegs? Zweitens: Welche Größe hat Ihr Unternehmen, typischerweise mit Blick auf Mitarbeitende und Umsatz? Drittens: Welche Rolle spielen Sie in der Leistungserbringung – wird Ihr Betrieb oder Ihr digitaler Dienst für diese Leistung tatsächlich gebraucht?

Gerade der dritte Punkt wird gern übersehen, weil er unbequemer ist als eine reine Branchenprüfung. Wenn Sie zum Beispiel IT-Services, digitale Plattformen, Rechenzentrumsleistungen, Cloud-nahe Dienste oder Managed Services liefern, reicht es oft nicht, nur auf Ihr Organigramm zu schauen. Dann müssen Sie prüfen, ob Ihre Systeme oder Ihr Betrieb Teil einer Leistung sind, deren Ausfall für andere richtig teuer oder operativ kritisch wird. Im Mittelstand sehe ich oft zwei gegensätzliche Fehlannahmen. Die eine lautet: „Wir fallen da sicher nicht drunter.“ Die andere lautet: „Dann melden wir im Zweifel einfach alles.“ Beides ist keine tragfähige Linie. Wer die eigene Betroffenheit kleinredet, baut blind auf Hoffnung. Wer ohne Prüfung alles in den gleichen Topf wirft, produziert nur Hektik und schlechte Entscheidungen.

Besonders häufig unterschätzen IT-Dienstleister ihre Rolle. Dasselbe gilt für Anbieter digitaler Dienste und für Managed Service Provider. Der Grund ist simpel: Sie betrachten sich oft als Unterstützer im Hintergrund, während der Kunde aus ihrer Sicht „der eigentliche Betreiber“ ist. Regulatorisch und operativ kann das zu kurz greifen, wenn Ihre Leistung für den laufenden Betrieb wesentlich ist oder wenn über Ihre Systeme Risiken in andere Unternehmen hineinreichen. Lassen Sie uns das kurz zerlegen. NIS2 fragt nicht nur: Was stellen Sie her oder betreiben Sie direkt? NIS2 schaut auch darauf, ob Ihre Dienste für die Sicherheit und Verfügbarkeit anderer Leistungen eine tragende Rolle spielen. Wenn Ihr Ausfall oder Ihre Kompromittierung bei Kunden zu schweren Betriebsstörungen führen kann, dann ist das kein Nebenschauplatz mehr. Damit kommt die Lieferkette ins Spiel. Das ist nicht kompliziert, es wird nur oft unnötig kompliziert erklärt. Wenn Ihre Systeme, Ihre Administration oder Ihr Service gebraucht werden, damit ein anderes Unternehmen eine wesentliche Leistung stabil erbringen kann, dann sind Sie zumindest in einer Zone, die sauber geprüft werden muss. Denken Sie nicht nur an Ihr eigenes Haus, sondern auch an die Leitungen, die durch Ihr Haus in andere Gebäude laufen. Genau da entstehen oft die blinden Flecken.

Klartext: Wenn Sie erst im laufenden Vorfall anfangen zu prüfen, ob Sie überhaupt betroffen sind, haben Sie bereits Zeit verloren, die Sie bei NIS2 nicht haben. Dann diskutieren IT, Geschäftsführung, Datenschutz und vielleicht noch externe Berater über Grundsatzfragen, obwohl die Uhr längst läuft. Das ist kein juristisches Schönheitsproblem. Das ist ein operatives Risiko mit Ansage. Deshalb gehört die Betroffenheitsprüfung nicht in die Krisennacht, sondern auf den Tisch, bevor etwas passiert. Sie müssen wissen, ob Sie unter NIS2 fallen, in welcher Kategorie Sie unterwegs sind und wer diese Bewertung intern verantwortet. Sonst beginnt jeder Vorfall mit einem Organisationsfehler. Und sobald die Betroffenheit geklärt ist, kommt die nächste heikle Frage: Was ist überhaupt meldepflichtig?

Was ein meldepflichtiger Vorfall wirklich ist

Hier ist eine häufige Fehlannahme: Viele glauben, meldepflichtig sei nur der große Totalschaden – Stillstand, Blackout, komplette Verschlüsselung, nichts geht mehr. Die andere Überreaktion ist genauso unbrauchbar: jeder Angriff, jede Alarmmeldung, jeder verdächtige Logeintrag wird sofort als meldepflichtiger Vorfall eingestuft. Beides ist falsch.

Sie brauchen eine saubere Einordnung. NIS2 betrifft erhebliche Sicherheitsvorfälle. Das heißt: Sie prüfen nicht nur, dass etwas passiert ist, sondern welche Wirkung der Vorfall auf Ihren Betrieb, auf Ihre Leistungen und auf Dritte hat oder haben kann. Wenn Systeme gestört werden, Dienste ausfallen, spürbare finanzielle Schäden drohen oder andere Unternehmen, Kunden oder Nutzer betroffen sind, dann wird es ernst. Und wenn ein Vorfall Auswirkungen über Deutschland hinaus haben kann – etwa weil ein Dienst in mehreren Ländern genutzt wird oder eine vernetzte Struktur betroffen ist – steigt die Relevanz weiter.

Klartext: Der Maßstab ist nicht die technische Dramatik allein, sondern die betriebliche und wirtschaftliche Wirkung. Ein Angriff kann technisch unspektakulär beginnen und trotzdem meldepflichtig werden, weil er genau die falschen Systeme trifft. Umgekehrt kann ein lauter, aber folgenlos abgewehrter Angriff operativ unangenehm sein, ohne sofort eine Meldung auszulösen.

Nehmen Sie Ransomware mit Produktionsbezug. Wenn dadurch nicht nur ein einzelner Bürorechner blockiert ist, sondern Fertigung, Disposition oder ein zentraler Betriebsprozess ins Stocken gerät, dann reden wir nicht mehr über einen normalen IT-Zwischenfall, sondern über einen erheblichen Sicherheitsvorfall. Dasselbe gilt für den Ausfall kritischer Dienste – etwa ein zentrales Portal, eine Plattform, ein Authentifizierungsdienst oder eine betriebsnotwendige Infrastruktur, die über längere Zeit nicht verlässlich arbeitet. Und es trifft besonders zu, wenn ein Managed Service Provider kompromittiert wird, der bei mehreren Kunden tief im Betrieb hängt. Dann liegt das Risiko nicht nur im eigenen Haus, sondern wandert über Schnittstellen und Administrationswege weiter.

Genau deshalb sind Drittwirkungen so wichtig. Ein Vorfall wird nicht erst dann groß, wenn Ihr gesamtes Unternehmen steht. Er reicht schon in eine andere Kategorie, wenn erhebliche Folgen bei Kunden, Partnern oder versorgten Nutzern entstehen können. Das wird gern unterschätzt, vor allem bei Dienstleistern, die ihre eigene Rolle zu schmal auslegen.

Jetzt zu den Grauzonen, denn da entstehen in der Praxis die meisten Fehlentscheidungen. Ein abgewehrter Angriff ohne erkennbare Wirkung ist nicht automatisch meldepflichtig. Wenn Ihr Schutz gegriffen hat, der Angriff keine Störung verursacht hat und keine belastbaren Hinweise auf Schäden oder Auswirkungen vorliegen, dann ist das erst einmal ein Sicherheitsereignis, aber nicht zwingend ein erheblicher Vorfall. Eine interne Fehlkonfiguration ohne Folgen nach außen fällt ebenfalls nicht automatisch darunter, jedenfalls dann nicht, wenn sie keine erhebliche Betriebsstörung ausgelöst und keine Dritten beeinträchtigt hat. Dasselbe gilt für geplante Wartung oder bewusst herbeigeführte Unterbrechungen, die organisiert, angekündigt und kontrolliert ablaufen.

Das heißt aber nicht, dass Sie locker bleiben und einfach abwarten. Sie müssen sauber prüfen – nicht hektisch, aber zügig. Es geht nicht um Panikmeldungen, sondern um eine belastbare Einstufung unter Zeitdruck. Das ist ein Unterschied. Wer aus Angst vor Sanktionen alles meldet, zeigt keine Reife, sondern fehlende Steuerung. Wer aus Bequemlichkeit erst einmal nichts meldet, spielt auf Zeit mit offenem Ausgang.

Darum ist die Frühwarnung auch keine Aufforderung zur Vollständigkeit, sondern eine erste tragfähige Lageeinschätzung. Sie melden, was Sie nach aktuellem Stand belastbar sagen können: Was ist passiert, was ist betroffen, welche Wirkung sehen Sie bisher und wie schwer wirkt der Vorfall im Moment. Mehr nicht, aber auch nicht weniger. Erst danach wird das Bild schärfer.

Genau an dieser Stelle entscheidet sich, ob die 24-Stunden-Frist Ihnen hilft oder Ihnen um die Ohren fliegt.

Die 24 Stunden, die über Ruhe oder Chaos entscheiden

Kommen wir zum Punkt, an dem viele Unternehmen im Ernstfall scheitern – obwohl der Vorfall selbst oft noch beherrschbar wäre. Die Frist beginnt mit der Kenntniserlangung. Nicht erst dann, wenn die Forensik abgeschlossen ist, nicht nach der internen Freigabeschleife und auch nicht dann, wenn ein externer Dienstleister den Befund bestätigt hat. Sobald Ihr Unternehmen belastbar erkannt hat, dass ein erheblicher Sicherheitsvorfall vorliegt oder mit hoher Wahrscheinlichkeit vorliegt, läuft die Uhr.

Genau das wird in der Praxis oft falsch verstanden. Da sitzt ein Team in einem Call, die IT sammelt Logdaten, der Dienstleister prüft noch, die Geschäftsführung will erst eine saubere Einordnung, und irgendjemand sagt: „Wir warten besser noch auf gesicherte Ergebnisse.“ Klingt vernünftig – ist es oft nicht. Denn regulatorisch zählt nicht, wann Sie sich intern vollständig wohlfühlen, sondern wann Sie von dem Vorfall Kenntnis haben. Das ist ein Unterschied, und der kann teuer werden.

Die erste Meldung an das BSI ist deshalb als Frühwarnung gedacht, nicht als Schlussbericht, sondern als erste belastbare Lage. Sie müssen darin nicht schon jede Ursache bis ins letzte Detail auflösen, aber Sie müssen sagen können, was nach aktuellem Stand bekannt ist, welche Systeme oder Dienste betroffen sind und wie schwer der Vorfall im Moment wirkt. Mehr verlangt die erste Stufe nicht, aber weniger reicht auch nicht.

Klartext: Schnelligkeit schlägt Vollständigkeit, aber Schnelligkeit ersetzt keine Struktur. Eine brauchbare Frühwarnung enthält die Art des Vorfalls, die betroffenen Systeme oder Dienste, eine erste Vermutung zur Ursache, bereits eingeleitete Maßnahmen und natürlich verlässliche Kontaktdaten. Wenn Sie nur schreiben, dass es einen Sicherheitsvorfall gibt und man noch prüft, dann ist das keine tragfähige Meldung. Wenn Sie dagegen sauber benennen können, dass etwa ein zentraler Dienst gestört ist, welche Umgebung betroffen ist, welche Wirkung bisher sichtbar ist und wer erreichbar ist, dann erfüllen Sie den Zweck der Frühwarnung.

Danach wird das Lagebild präziser. Innerhalb von 72 Stunden folgt die nächste Meldung mit mehr Substanz – also einer besseren Einschätzung zu Ursache, Ausmaß, betroffenen Dritten und den bis dahin ergriffenen Gegenmaßnahmen. Und damit endet es noch nicht. Spätestens innerhalb eines Monats braucht es eine Abschlussmeldung, in der der Vorfall vollständig aufgearbeitet wird: Ursache, Ablauf, Auswirkungen, Wiederherstellung und die Maßnahmen, die dauerhaft nachgezogen werden. Das ist kein bürokratischer Anhang, sondern Teil der regulatorischen Pflicht und am Ende auch Teil Ihrer eigenen Absicherung.

Der operative Engpass liegt oft an einer ganz anderen Stelle – nicht bei der Technik, sondern bei der Vorbereitung des Meldewegs. Wenn der Vorfall da ist, sollten Sie nicht erst anfangen, den Zugang zum BSI-Portal zu suchen, Zuständigkeiten zu diskutieren oder intern zu klären, wer überhaupt meldeberechtigt ist. Das muss vorher stehen. Sie brauchen eingerichtete Zugänge, definierte Personen mit Vertretung, klare Kommunikationswege und eine Liste der betroffenen Assets oder Dienste, die im Ernstfall schnell greifbar ist. Sonst diskutieren drei Leute über Formalitäten, während die Frist läuft.

Was ich im Mittelstand regelmäßig sehe, ist ein sehr menschlicher, aber riskanter Reflex: Alle wollen erst das vollständige Bild. Die IT will technische Sicherheit, das Management will keine halbfertige Aussage nach außen geben, externe Partner wollen sich nicht zu früh festlegen – also wartet man, und genau dieses Warten reißt dann die Frist. Nicht aus bösem Willen, sondern aus dem Wunsch, sauber zu arbeiten. Das Problem ist nur: Bei NIS2 ist sauberes Arbeiten nicht gleichbedeutend mit spätem Melden, sondern bedeutet, früh sauber genug zu melden und danach systematisch nachzuschärfen.

Stellen Sie sich vor, Sie haben einen Hausbrand. Sie rufen die Feuerwehr nicht erst dann, wenn die Ursache des Kabelbrands im Verteilerkasten eindeutig geklärt ist, der Elektriker eine Stellungnahme geschrieben hat und intern abgestimmt wurde, wer mit der Leitstelle spricht. Sie melden den Brand, weil er da ist, weil Gefahr besteht und weil die Lage früh eingeordnet werden muss. Genau so funktioniert die Logik der 24-Stunden-Frist: erst melden, was belastbar bekannt ist, dann aufklären, eingrenzen und präzisieren.

Dafür brauchen Sie keinen perfekten Prozess, aber einen tragfähigen. Meldefähigkeit ist am Ende nichts anderes als vorbereitete Handlungsfähigkeit unter Druck. Wenn Sie dafür erst im Vorfall anfangen, Strukturen zu bauen, dann bauen Sie im Rauch.

Und wenn dieser Prozess nicht vorbereitet ist, wird aus einem Sicherheitsvorfall sehr schnell ein Führungsproblem.

Was Geschäftsführung und IT-Leitung persönlich riskieren

Spätestens hier wird die Meldepflicht zum Leitungsthema. NIS2 betrachtet Cybersicherheit nicht länger als reine IT-Aufgabe, die man an die Abteilung delegiert und sich dann im Monatsreport erklären lässt. Die Verantwortung liegt auf der Leitungsebene – das ist keine akademische Feinheit, sondern der Punkt, an dem viele Geschäftsführungen ihre Rolle noch falsch einschätzen. Seien wir ehrlich: Hier entscheidet sich, ob Sie führen oder nur verwalten.

Für Sie heißt das konkret: Sie müssen nicht jeden technischen Befund selbst beurteilen können, aber Sie müssen die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und sich in Cybersicherheit schulen lassen. Genau das ist der Punkt – nicht blind nicken, nicht wegdelegieren, nicht auf den externen Dienstleister zeigen, sondern nachvollziehbar entscheiden und kontrollieren. Wenn Ihre Organisation im Ernstfall nicht meldefähig ist, ist das nicht nur ein Problem der IT-Leitung, sondern ein Führungsmangel.

Die Branche redet an dieser Stelle gern über Tools, Detection und Reaktionszeiten – alles richtig, aber das greift zu kurz. Ein Unternehmen scheitert regulatorisch oft nicht an fehlender Technik, sondern daran, dass niemand sauber festgelegt hat, wer Risiken bewertet, wer meldet, wer freigibt und wer der Geschäftsführung mit belastbaren Informationen zuarbeitet. Dann hängt alles an Einzelpersonen, an Gewohnheiten oder an hektischen Anrufen. So arbeitet man vielleicht im Alltag, aber nicht unter Aufsicht.

Schauen wir uns die Sanktionen nüchtern an. Für besonders wichtige Einrichtungen drohen Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist. Für wichtige Einrichtungen sind es bis zu 7 Millionen Euro oder 1,4 Prozent des weltweiten Jahresumsatzes. Das ist keine Kleinigkeit, die man als Betriebskosten abhakt. Das kann Investitionsspielräume zerlegen, Finanzierungsgespräche belasten und intern sehr schnell die Frage auslösen, wer die Verantwortung getragen hat.

Damit sind wir bei dem Teil, der für Geschäftsführer oft unangenehmer ist als das Unternehmensbußgeld. Das Unternehmen zahlt vielleicht die formale Sanktion, aber intern beginnt dann die zweite Rechnung: Regressansprüche gegen die Geschäftsleitung drohen, wenn Pflichtverletzungen nachweisbar werden. In bestimmten Konstellationen können auch persönliche Geldbußen relevant werden. Dazu kommt der Reputationsschaden, der im Mittelstand oft unterschätzt wird – nicht wegen einer Schlagzeile allein, sondern weil Kunden, Banken, Beirat und Gesellschafter sehr genau hinschauen, wenn ein Vorfall nicht nur passiert ist, sondern auch schlecht gemanagt wurde.

Noch brisanter wird es bei schweren oder wiederholten Verstößen. Dann reden wir nicht mehr nur über Geld, sondern auch über mögliche Leitungsverbote. Klartext: Wenn die Aufsicht den Eindruck hat, dass Pflichten systematisch ignoriert oder grob verfehlt wurden, steht nicht nur die Sicherheitslage des Unternehmens infrage, sondern auch die Eignung der Leitung. Das ist der Teil, über den Anbieter ungern sprechen, weil er nicht gut ins Verkaufsgespräch passt.

Ein häufiger Irrtum lautet: Wir haben doch einen externen IT-Dienstleister, einen SOC, vielleicht noch einen MSSP, also sind wir abgesichert. Nein. Sie können Leistungen auslagern, aber keine Organverantwortung. Der Dienstleister kann erkennen, analysieren, melden vorbereiten und technisch reagieren – er kann Sie auch sauber durch einen Vorfall führen. Was er nicht kann: Ihre gesetzliche Verantwortung übernehmen. Wenn intern niemand entschieden hat, welche Maßnahmen gelten, welche Eskalationswege verbindlich sind und wer auf welcher Grundlage meldet, dann haben Sie die Lücke selbst.

Deshalb ist Dokumentation kein Selbstzweck und keine Fleißarbeit für Auditoren – sie ist Haftungsschutz. Sie müssen Entscheidungen festhalten, die Logik Ihrer Einstufung dokumentieren, Maßnahmen und Eskalationen nachvollziehbar machen und Freigaben sauber protokollieren. Nicht als Roman, sondern so, dass später erkennbar ist, wer wann was wusste, welche Optionen geprüft wurden und warum eine Entscheidung so gefallen ist. Wenn Sie das nicht können, wirkt selbst eine vernünftige Entscheidung im Nachhinein schnell wie Improvisation.

Die eigentliche Absicherung entsteht also nicht im Tool, sondern in nachvollziehbarer Führung. Wer Risiken billigt, muss sie verstanden haben; wer Maßnahmen überwacht, muss Berichte einfordern; wer melden muss, braucht einen dokumentierten Weg dorthin. Alles andere ist Hoffnung mit besserer Verpackung.

Aber das ist nur die halbe Wahrheit, denn oft läuft parallel noch eine zweite Meldepflicht.

Wenn NIS2 und DSGVO gleichzeitig zuschlagen

Jetzt kommt der Punkt, an dem viele Unternehmen im Vorfall beginnen, die falschen Dinge zu vermischen. NIS2 und DSGVO hören sich auf den ersten Blick ähnlich an, weil in beiden Fällen Fristen laufen und Behörden informiert werden müssen – trotzdem verfolgen sie nicht denselben Zweck. NIS2 fokussiert sich auf die Sicherheit und Verfügbarkeit von Diensten und Systemen; die DSGVO auf personenbezogene Daten und die Frage, ob für betroffene Personen ein Risiko entsteht.

Das führt in der Praxis zu einem einfachen, aber oft übersehenen Ergebnis: Eine Meldung ersetzt die andere nicht. Wenn ein Vorfall unter NIS2 meldepflichtig ist, melden Sie an das BSI; wenn derselbe Vorfall zugleich eine Datenschutzverletzung mit relevantem Risiko darstellt, melden Sie zusätzlich an die zuständige Datenschutzaufsicht. Zwei Wege, zwei Zwecke, zwei Prüfungen. Wer denkt, eine BSI-Meldung decke den Datenschutz gleich mit ab, baut sich die nächste Lücke direkt in den Prozess ein.

Typisch tritt das bei Ransomware oder bei einer kompromittierten Anmeldung mit weitreichenden Rechten auf. Stellen Sie sich einen Fall vor, in dem ein Angreifer Systeme verschlüsselt, Betriebsabläufe stört und gleichzeitig auf personenbezogene Daten zugreifen konnte. Dann haben Sie nicht nur ein Problem mit der Betriebsfähigkeit, sondern auch eines mit dem Datenschutz. Dasselbe gilt, wenn ein Konto übernommen wird, über das produktive Systeme gesteuert werden und zugleich Kundendaten, Mitarbeiterdaten oder sensible Vertragsdaten zugänglich waren. Solche Doppelvorfälle sind keine Ausnahme mehr, sondern längst Alltag.

Entscheidend ist, dass Sie die Fristen sauber auseinanderhalten. Die Frühwarnung für NIS2 läuft innerhalb von 24 Stunden ab Kenntnis; für die DSGVO sind es 72 Stunden zur Meldung an die Datenschutzaufsicht. Diese Fristen laufen parallel, nicht nacheinander – Sie melden also nicht erst an das BSI und kümmern sich danach um den Datenschutz. Beides muss von Anfang an mitgedacht werden, auch wenn die Details am Anfang noch unscharf sind.

Und dann endet die Sache oft noch nicht bei zwei Behörden. Viele Unternehmen haben zusätzlich vertragliche Meldepflichten gegenüber Kunden, und Cyber-Versicherer verlangen ebenfalls häufig eine sehr frühe Information, teils mit eigenen Fristen und Formvorgaben. Wenn Sie diese Pfade nicht vorbereitet haben, entsteht in kurzer Zeit ein sehr unangenehmes Bild: Die IT arbeitet am Vorfall, Legal prüft Texte, der Datenschutz wartet auf Fakten, der Vertrieb fragt nach Kundenaussagen und die Geschäftsführung versucht gleichzeitig, die Lage überhaupt erst zu sortieren.

Klartext: In der ersten Incident-Stunde entscheidet sich, ob Sie einen Vorfall managen oder ob Sie nur noch Fristen hinterherrennen. Genau dort trennt sich ein belastbarer Prozess von einem Krisenritual, bei dem jeder beschäftigt ist, aber niemand den Überblick hat.

Am Ende des Tages bleibt nur eine vernünftige Konsequenz: Vorbereitung vor dem Ernstfall.

Was Sie vor dem nächsten Vorfall festziehen sollten

Sie brauchen vor allem fünf Dinge – und zwar bevor der nächste Alarm losgeht.

Erstens: eine interne Einstufungslogik. Nicht theoretisch, sondern so, dass Ihr Team damit arbeiten kann. Wann ist ein Vorfall erheblich?

Zweitens: einen schriftlichen Meldeprozess mit klaren Rollen für IT, Datenschutz, Legal und Geschäftsführung. Unter Druck wird nicht über Zuständigkeiten verhandelt – das kostet Zeit.

Drittens: eingerichtete BSI-Zugänge, Vertretungen, Kontaktlisten und Vorlagen. Alles muss griffbereit sein.

Viertens: Übungen. Eskalation und Meldung müssen einmal praktisch durchgespielt sein. Theorie allein reicht nicht.

Fünftens: Räumen Sie Ihre Architektur und Dokumentation auf. Frankenstein-Integrationen verlangsamen jede Lagebewertung, weil niemand schnell sagen kann, was wo dranhängt.

Abschluss

Gute Incident Response beginnt nicht beim Tool, sondern bei der Entscheidung, wer in den ersten 24 Stunden was tun muss.

Wenn Sie solche IT-Entscheidungen aus der Praxis einordnen wollen, abonnieren Sie den Podcast und sprechen Sie mit Ihrem Team – bevor der nächste Vorfall Sie zu Entscheidungen unter Zeitdruck zwingt.