NIS2 bringt viele Organisationen dazu, Sicherheitsmaßnahmen zu „listen“: man schaut auf Kataloge, orientiert sich an Standards, erstellt Maßnahmenpläne. Das ist grundsätzlich sinnvoll. Die unangenehme Wahrheit ist aber: Nicht jede Maßnahme, die auf dem Papier gut aussieht, trägt im Ernstfall wirklich. Und umgekehrt sind es oft ein paar Basics, die darüber entscheiden, ob ein Vorfall kontrollierbar bleibt – oder ob er sich in Chaos, Stillstand und Nacharbeit übersetzt.

Wenn man über „Basics“ spricht, klingt das schnell nach Allgemeinplätzen. In der Praxis ist es deutlich konkreter. „Basics, die tragen“ sind Maßnahmen, die in kritischen Momenten zwei Dinge gleichzeitig ermöglichen: schnelle Entscheidungen und stabile Abläufe. Genau das erwartet NIS2 im Kern: nicht Perfektion, sondern Betriebsfähigkeit.

Wer in einer Organisation für Informationssicherheit, Compliance oder IT verantwortlich ist, weiß: Sicherheitsvorfälle passieren nicht nur bei anderen. Irgendwann kommt der Tag, an dem ein System ausfällt, Daten abfließen oder ein Cyberangriff den Geschäftsbetrieb stört. Für viele Unternehmen ist das ein Schreckmoment, der Adrenalin freisetzt und schnell in hektisches Handeln münden kann. Genau hier setzt DORA mit klaren Vorgaben für das Incident Reporting an – der strukturierten Meldung von schweren IKT-Vorfällen an die zuständigen Behörden. Die Idee dahinter ist einfach: Wenn Vorfälle einheitlich, zeitnah und vollständig gemeldet werden, können Aufsichtsbehörden die Lage besser einschätzen, koordinierte Gegenmaßnahmen einleiten und vor allem verhindern, dass ähnliche Angriffe unbemerkt andere Unternehmen treffen. Für die betroffenen Organisationen bedeutet das aber auch, dass sie ihre internen Prozesse so aufstellen müssen, dass sie im Ernstfall nicht improvisieren, sondern nach einem klaren Plan vorgehen.

Was unter DORA als schwerwiegender IKT-Vorfall gilt – und warum das nicht nur „große Hacks“ sind

Der erste Schritt ist das Verständnis, was unter DORA überhaupt als „schwerwiegender IKT-Vorfall“ gilt. Hier geht es nicht nur um spektakuläre Hackerangriffe oder großflächige Systemausfälle. Auch lang anhaltende Beeinträchtigungen einzelner kritischer Prozesse, der Verlust sensibler Daten oder sicherheitsrelevante Störungen in der Lieferkette können meldepflichtig sein. DORA definiert Kriterien, die sich an der Auswirkung auf Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität orientieren. Dazu zählen unter anderem die Anzahl betroffener Kunden, die Dauer der Störung, die geographische Reichweite, die potenziellen finanziellen Verluste und mögliche Auswirkungen auf die Stabilität des Finanzsystems. Unternehmen müssen diese Kriterien nicht erst im Ernstfall nachschlagen, sondern schon vorab in ihre eigenen Bewertungsverfahren integrieren. Gute Praxis ist eine interne Schwellwertmatrix, die technische Indikatoren (z. B. Umfang der Beeinträchtigung, Exfiltrationsindikatoren) mit Geschäftsauswirkungen (z. B. SLAs, verpasste Zahlungen, Marktkommunikation) verbindet und so schnell zur Entscheidung „meldepflichtig – ja/nein“ führt.