DORA hat eine Eigenschaft, die in vielen Organisationen erst spät wirklich ankommt: Es geht nicht nur darum, dass Sie Prozesse und Kontrollen haben. Es geht darum, dass Sie unter realistischen Bedingungen zeigen können, dass Ihr Betrieb Störungen aushält – und dass Sie daraus sichtbar besser werden. Genau deshalb rückt Testing unter DORA so stark in den Vordergrund. Und genau deshalb entsteht rund um „Threat-led Penetration Testing“ (kurz TLPT) ein besonderer Druck: Viele Teams hören „Penetrationstest“ und denken sofort an Technik. In der Praxis ist TLPT aber vor allem eine Disziplin der Steuerung: realistische Szenarien, klare Ziele, eng abgestimmte Grenzen, Einbindung von Dienstleistern, belastbare Nachweise und vor allem ein sauberer Umgang mit Ergebnissen.

Wenn Unternehmen sich an TLPT „verbrennen“, liegt das selten daran, dass sie grundsätzlich zu wenig können. Meist liegt es an zwei Dingen: Entweder man startet zu groß (zu viel Scope, zu viele Systeme, zu viele Stakeholder, zu wenig Routine). Oder man startet zu technisch (Tool-Fokus), während die entscheidenden Fragen ungelöst bleiben: Welche kritischen Services testen wir wirklich? Welche Abhängigkeiten sind in der Kette? Welche Entscheidungspunkte müssen im Ernstfall funktionieren? Und wie machen wir den Test so, dass er nicht nur „spannend“ ist, sondern für Betrieb und Nachweis wirklich verwertbar?

NIS2 wird in vielen Unternehmen zunächst als „Security-Thema“ einsortiert: IT und Informationssicherheit klären Maßnahmen, Compliance koordiniert, und irgendwann bekommt die Geschäftsleitung ein Update mit Ampeln. Das wirkt vertraut, weil viele Regulierungs- und Auditwellen so gelaufen sind. Der Unterschied bei NIS2 ist jedoch, dass sich die Erwartung an die Geschäftsleitung deutlich verändert – nicht nur als Empfänger von Berichten, sondern als sichtbarer Teil der Verantwortungskette. In der Praxis ist das weniger dramatisch, als es manchmal klingt, aber es ist konkreter: Es geht um Organisationsentscheidungen, um Priorisierung, um nachvollziehbare Steuerung – und darum, dass diese Steuerung im Ernstfall und in der Prüfung belegbar ist.

Genau hier entstehen typische Reibungen. Auf der einen Seite will die Geschäftsleitung keine zusätzlichen „Programme“, die den Betrieb lähmen. Auf der anderen Seite will sie nicht in einer Situation stehen, in der ein Vorfall eskaliert, die Aufsicht Fragen stellt oder ein Kunde Nachweise fordert – und man dann feststellt, dass vieles zwar „gemacht“ wurde, aber nicht sauber als Verantwortung, Entscheidung und Evidenz zusammenläuft. Das ist der eigentliche Kern: NIS2 verlangt nicht, dass Vorstände plötzlich technische Spezialisten werden. NIS2 verlangt, dass Verantwortung so organisiert ist, dass sie im Betrieb funktioniert und im Zweifel auch nachweisbar ist.

NIS2 wird in vielen Unternehmen gerade mit hohem Tempo umgesetzt. Das ist verständlich: Die Erwartungshaltung ist groß, der Druck ist real, und niemand möchte in eine Situation kommen, in der man im Ernstfall oder in einer Prüfung erklären muss, warum etwas „noch nicht fertig“ ist. Genau hier entsteht aber ein typisches Nebenproblem, das ich in der Praxis immer wieder sehe: Nachweise werden zu früh als „Dokumentationsprojekt“ verstanden. Dann wächst die Menge an Artefakten schnell – aber die Prüfbarkeit wird nicht automatisch besser. Im Gegenteil: Wenn zu viele Dinge als Nachweis gelten sollen, wird es unklar, was wirklich zählt. Und Unklarheit ist im Audit der schnellste Weg zu Nachforderungen.

Dieser Artikel hilft Ihnen, die NIS2-Nachweispflichten pragmatisch zu sortieren. Nicht nach dem Motto „möglichst viel sammeln“, sondern nach dem Prinzip: Welche Artefakte belegen im Zweifel wirklich, dass Ihr Betrieb sicher und handlungsfähig ist? Und welche Artefakte sehen zwar ordentlich aus, bringen Ihnen aber wenig, weil sie weder Entscheidungen stützen noch die Umsetzung im Alltag nachvollziehbar machen?