Die meisten Sicherheits- und Notfallkonzepte sind darauf ausgelegt, nach einem Vorfall möglichst schnell wieder anzulaufen. Der Beitrag stellt diese Logik infrage: Wiederanlaufzeiten sind ein Eingeständnis, dass der Kern getroffen werden konnte. Wirtschaftlich entscheidend ist nicht, wie schnell ein Unternehmen zurückkommt, sondern ob es überhaupt weg war. Der Artikel zeigt, wie Unternehmen ihren geschäftskritischen Kern identifizieren, ihn architektonisch von der übrigen IT entkoppeln und so absichern, dass ein Wiederanlauf gar nicht erst nötig wird – mit Blick auf NIS2, BCM-Anforderungen und die Frage, welche Investitionen im Mittelstand tatsächlich Wirkung entfalten.

In Notfallhandbüchern steht eine Zahl im Mittelpunkt, auf die viele Organisationen stolz sind: die Wiederanlaufzeit. Wer sie von 14 auf vier Tage senkt, hat messbar etwas erreicht und kann es dokumentieren. Genau darin liegt ein blinder Fleck. Eine Wiederanlaufzeit ist keine Leistungs-, sondern eine Schadenskennzahl. Sie beziffert die Dauer eines Zustands, in dem das Unternehmen nicht liefert, nicht fakturiert und nicht disponiert – und ihre Optimierung setzt voraus, dass der Ausfall bereits als gegeben akzeptiert wurde.

Für die kaufmännische Betrachtung ist das ein erheblicher Unterschied. Ein Fertigungsunternehmen, das seine Wiederanlaufzeit halbiert, halbiert nicht seinen Schaden. Vertragsstrafen, verlorene Abrufe, Reputationsverluste bei Schlüsselkunden und der interne Nachlauf zur Datenkonsistenz folgen keiner linearen Logik: Bereits ein Stillstand von wenigen Tagen kann eine Lieferbeziehung dauerhaft beschädigen.

Die Lagezahlen stützen diese Sicht. Das Bundesamt für Sicherheit in der Informationstechnik verzeichnete von Juli 2024 bis Juni 2025 rund 950 gemeldete Ransom-ware-Angriffe in Deutschland, bei durchschnittlich 119 neuen Schwachstellen pro Tag [1]. Die Bitkom-Studie Wirtschaftsschutz 2026 beziffert den jährlichen Ge-samtschaden der deutschen Wirtschaft durch Datendiebstahl, Spionage und Sabotage auf 211 bis 270,8 Milliarden Euro, wovon rund drei Viertel auf Cyberangriffe entfallen; jedes fünfte betroffene Unternehmen berichtet von Folgewirkungen bei  Geschäftspartnern, etwa Produktionsstillständen [2].

Und Wiederherstellung bleibt teuer, selbst wenn sie gelingt: Die mittleren Wiederherstellungskosten nach einem Ransomware-Vorfall lagen zuletzt bei 1,7 Millionen US-Dollar, in 56 % der Angriffe wurden Daten tatsächlich verschlüsselt [3]. Wer die Wiederanlaufzeit als zentrale Steuerungsgröße wählt, optimiert damit die Bewältigung eines Zustands, den er besser vermeidet. Die wirtschaftlich relevante Frage lautet nicht, wie schnell ein Unternehmen zurückkommt, sondern ob es überhaupt weg war.

Der Kern ist kleiner, als das Organigramm vermuten lässt

Der Einwand liegt auf der Hand: Vollständige Vermeidung von Ausfällen ist unrealistisch. Das trifft für die gesamte IT-Landschaft zu – nicht aber, wenn der Betrachtungsgegenstand richtig zugeschnitten ist.

In den meisten mittelständischen Unternehmen ist die Zahl der Systeme, deren Ausfall unmittelbar den Geschäftsbetrieb zum Erliegen bringt, überraschend klein. Kollaborationsdienste, Dateiablagen, Reporting-Umgebungen, Testsysteme und ein Großteil der Fachanwendungen sind  wichtig, aber nicht kernkritisch: Ihr Ausfall erzeugt Reibung, keinen Stillstand. Kernkritisch sind in der Regel Auftrags- und Materialwirtschaft, Produktionssteuerung mit ihren Übergabepunkten, Lager- und Versandabwicklung sowie die Stammdatenhaltung, die diese Ketten zusammenhält. In nahezu allen Fällen laufen sie über das ERP-System.

Das ERP ist damit nicht bloß eine besonders große Anwendung, sondern der Integrationsknoten, an dem betriebswirtschaftliche Prozesse, Produktionsdaten und Finanzfl üsse zusammenlaufen. Der Baustein APP.4.2 des IT-Grundschutz-Kompendiums trägt dem Rechnung, indem er ERP-Systeme als eigenes Schutzobjekt mit spezifischen Anforderungen an Berechtigungssteuerung, Mandantentrennung und Protokollierung führt [4]. In der Praxis wird das ERP jedoch häufig im selben Netzsegment, unter derselben Administrationslogik und mit denselben Identitäten betrieben wie die Dateiablage der Marketingabteilung. Damit teilt der Kern das Schicksal der Peripherie.

Kernidentifikation: von der Prozesslandkarte zum Schutzobjekt

Die Bestimmung des Kerns ist keine technische, sondern eine betriebswirtschaftliche Aufgabe – und methodisch gut vorbereitet. Der BSI-Standard 200-4 beschreibt mit der Business-Impact-Analyse ein Verfahren, das zeitkritische Geschäftsprozesse identifiziert und ihnen Kenngrößen zuordnet: maximal tolerierbare Ausfallzeit, angestrebte Wiederanlaufzeit, tolerierbarer Datenverlust und Mindestbetriebsniveau, also der reduzierte Leistungsumfang, mit dem ein Unternehmen im Notbetrieb geschäftsfähig bleibt [5]. ISO 22301 formuliert dieselbe Systematik als Anforderung an ein Business-Continuity-Managementsystem [6].

Entscheidend ist eine Umdeutung dieser Kenngrößen. Klassisch dienen sie der Dimensionierung von Wiederanlaufmaßnahmen: Wer eine maximal tolerierbare Ausfallzeit von acht Stunden ermittelt, plant Redundanzen und Notfallverfahren, die diese acht Stunden einhalten. Verwendet man dieselben Werte als Abgrenzungskriterium, entsteht etwas anderes – eine belastbare Liste jener Prozesse und der sie tragenden Systeme, deren Ausfall gar nicht erst eintreten darf. Diese Liste ist der geschäftskritische Kern.

Drei Präzisierungen haben sich bewährt. Erstens ist der Kern prozessual, nicht applikatorisch zu schneiden: Nicht das ERP-System insgesamt gehört zum Kern, sondern die Mandanten, Buchungskreise, Module und Schnittstellen, die die zeitkritischen Ketten tragen. Zweitens gehören dazu zwingend die Voraussetzungen seines Betriebs – Verzeichnisdienst, Namensauflösung, Zertifikatsinfrastruktur, Datenbankplattform und Administrationswege. Ein Kern, dessen Authentifizierung an einem kompromittierbaren Verzeichnisdienst hängt, ist kein Kern. Drittens ist der Kern zu begrenzen: Wer mehr als 10–15 % der Anwendungslandschaft als kernkritisch einstuft, hat die Analyse nicht zu Ende geführt und wird die Schutzmaßnahmen ökonomisch nicht durchhalten.

Was die Regulierung verlangt – und was sie offenlässt

Das NIS-2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten und stellt rund 29.500 Unternehmen und Einrichtungen unter die Aufsicht des BSI; zuvor waren es etwa 4.500 [7]. Betroffene müssen sich binnen drei Monaten registrieren, erhebliche Sicherheitsvorfälle binnen 24 Stunden erstmelden, binnen 72 Stunden bewerten und binnen eines Monats abschließend berichten. Der Maßnahmenkatalog nach § 30 BSIG nennt ausdrücklich die Aufrechterhaltung des Betriebs, das Backup-Management und das Krisenmanagement; die Verantwortung für Umsetzung und Überwachung liegt bei der Geschäftsleitung [8].

Damit ist der regulatorische Rahmen klar – und zugleich in einem Punkt unscharf. Die Anforderungen richten sich auf Aufrechterhaltung und Wiederherstellung, ohne zu bestimmen, mit welcher Architektur beides erreicht wird. Ein Unternehmen erfüllt die Pflicht formal bereits, wenn es Notfallpläne, Sicherungskonzepte und Wiederanlaufübungen vorweisen kann. Ob diese Pläne jemals gebraucht werden, ist aufsichtsrechtlich nachrangig, betriebswirtschaftlich aber die eigentliche Frage.

Wer den Kern architektonisch entkoppelt, erfüllt die regulatorischen Anforderungen deshalb nicht schlechter, sondern besser: Die Business-Impact-Analyse ist ohnehin zu erstellen, die Betriebskontinuität ohnehin nachzuweisen, das Krisenmanagement ohnehin zu üben. Die Entkopplung nutzt dieselbe Vorarbeit, verschiebt aber das Ziel vom belegbaren Wiederanlauf zur belastbaren Nichtbetroffenheit des Kerns – und setzt damit an einer Größe an, die im Unternehmen unmittelbar verstanden wird: der Lieferfähigkeit.