Operational Resilience galt lange als Sonderdisziplin für Krisenmanager, als Notfallplan für seltene, extreme Ereignisse: Rechenzentrum brennt, Leitungen fallen aus, Angriff trifft die Kernsysteme, Lieferant stürzt ab. Dann kam die Dauerkrise – nicht als einzelner Paukenschlag, sondern als Takt: Cloud-Migrationswellen, Release-Kadenz im Wochenrhythmus, global vernetzte Lieferketten, Meldepflichten mit engen Fristen, Angreifer, die sich industrialisiert haben, und Kundenerwartungen, die Ausfallzeiten nicht mehr entschuldigen. Was früher Ausnahmefall war, ist heute Betriebszustand. Operational Resilience 360° bedeutet deshalb nicht, mehr Notfallpläne zu schreiben oder größere Firewall-Wälle zu ziehen. Es bedeutet, das Unternehmen so zu gestalten, dass Störungen einkalkuliert sind, Entscheidungen unter Druck zuverlässig fallen, Wiederanläufe geprüft sind, Beweise nebenbei entstehen und der Normalbetrieb bereits den Krisenbetrieb enthält. Es ist ein Kultur- und Architekturwechsel – vom heroischen Improvisieren zur geprobten Beherrschbarkeit; vom Projekt zur Betriebsleistung; vom Dokument zur Demonstration.

In der Praxis beginnt dieser Wandel mit einer unbequemen Ehrlichkeit: Niemand kann alle Risiken vermeiden, niemand alle Abhängigkeiten herauslösen, niemand ein „Null-Ausfall“-Unternehmen bauen. Die Illusion vollständiger Kontrolle ist selbst ein Risiko, denn sie verführt zu guten Geschichten statt zu belastbaren Fähigkeiten. Wer Operational Resilience 360° ernst nimmt, verabschiedet sich von makelloser Fassade und arbeitet an den Mechaniken dahinter: Wirkzeit statt Reifegrad, Übungen statt Versprechen, Anschlussfähigkeit statt Einkaufsfolklore, Evidenz statt Erinnerung, Reduktion statt Sammeltrieb, und eine Zeitlogik, die über Sicherheit hinaus das Geschäft führt. Das Ergebnis ist keine Organisation, die nicht mehr stolpert, sondern eine, die beim Stolpern nicht fällt – und wieder in den Lauf findet, ohne erst ihren Schuh suchen zu müssen.

D ie Ära der wohlgeordneten Checklisten ist vorbei. Was lange als erstrebenswerter Zustand galt – „prüfungsreif“, „compliant“, „auditfähig“ – wirkt 2025 wie ein Raster aus einer anderen Zeit. Nicht, weil Gesetze unwichtiger geworden wären. Im Gegenteil: Nie zuvor griffen so viele Regelwerke gleichzeitig ineinander. Aber Compliance ist nicht mehr das Ziel, sondern die Einstiegshürde. Die wirkliche Führungsaufgabe heißt heute Governance: sichtbar steuern, wirksam priorisieren, unterbrechungsfrei reagieren – und das auf Basis von Evidenzen, die täglich entstehen. Wer 2025 nur Vorgaben abarbeitet, hat verloren. Wer Governance als Produktionsfaktor begreift, gewinnt Geschwindigkeit, Vertrauen und Krisenfestigkeit.

Dieser Beitrag beleuchtet, was sich im Kern verschoben hat: von Pflichten zu Fähigkeiten, von Papier zu Prozessen, von Kontrollen zu Kompetenz. Er zeigt, warum DORA, NIS2, AI Act, CRA, CSRD & Co. kein Wirrwarr sind, sondern ein einziger, klarer Imperativ: Bau dir eine Organisation, die beweisen kann, was sie kann. Und zwar nicht im Jahresbericht, sondern wenn es darauf ankommt.

Jede Organisation kennt sie, fast niemand denkt an sie: Multifunktionsgeräte, Druckerflotten, Scanner, Plotter, Etikettendrucker, Fax-Module, Kioskdrucker für Belege. Sie stehen unscheinbar im Flur, summen leise vor sich hin, produzieren zuverlässig Seiten – und werden in Security-Runden oft nur dann erwähnt, wenn es um Kosten oder papierlose Initiativen geht. Dabei sind genau diese Geräte in vielen Netzen hochprivilegierte, dauerhaft präsente, schwach gehärtete Systeme mit direktem Draht zu Fileservern, E-Mail-Gateways, Verzeichnisdiensten und manchmal sogar ins öffentliche Internet. Wer sie ignoriert, baut eine Sicherheitsarchitektur mit offener Seitentür. Zeit, das Licht einzuschalten: Warum sind Drucker, Scanner & Co. so attraktiv für Angreifer? Wo liegen die Schattenrisiken? Und wie macht man aus einem grauen Kasten im Flur ein steuerbares, belastbares Asset – statt einer vergessenen Schwachstelle?

Warum ausgerechnet Drucker? Die Logik des Angreifers

Angreifer suchen nicht den glamourösen Weg, sondern den einfachen. Sie lieben überall verfügbare Geräte mit weit offenen Protokollen, seltenen Patches, Standardpasswörtern, großzügigen Netzwerkrechten und Administrationsoberflächen, die niemand überwacht. Multifunktionsgeräte liefern dieses Paket frei Haus:

Es gibt Regulierungswellen, die über Unternehmen hinweglaufen, ein paar neue Formulare hinterlassen und dann im Tagesgeschäft versanden. Und es gibt Regulierungen, die die Statik eines Hauses verändern: wie Entscheidungen fallen, wie Risiken gemessen werden, wie Verträge geschrieben sind, wie IT gebaut, betrieben und wiederhergestellt wird. MaRisk war für viele Institute der Start in dieses neue Denken; DORA zwingt es nun zu Ende. Dazwischen liegen Jahre, in denen BAIT/VAIT/KAIT, EBA-Leitlinien, Outsourcing-Regelwerke, Datenschutz und sektorübergreifende Cybersicherheitsvorgaben das Puzzle immer dichter gemacht haben. Das Ergebnis ist mehr als „mehr Pflichten“. Es ist ein neues Governance-Paradigma: weg von Richtlinien als Selbstzweck, hin zu wirksamer Steuerung mit Evidenz – im Normalbetrieb und unter Stress.

Von der Checkliste zur Steuerung: Was MaRisk wirklich ausgelöst hat

MaRisk hat die Grundmechanik moderner Governance im Finanzsektor etabliert: Risikobasierung, Proportionalität, Verantwortlichkeit der Geschäftsleitung. Viele Häuser begannen, Ziele und Risiken systematisch zu kaskadieren, Kontrollfunktionen unabhängiger zu stellen und mit drei Verteidigungslinien zu arbeiten. Doch der vielleicht wichtigste Schritt fand still statt: die Einsicht, dass ein reproduzierbarer Entscheidungspfad wertvoller ist als die perfekte Einzelmaßnahme. Ein Limit nützt nichts ohne Schwellen, Eskalationsrechte, Fristen und Re-Checks. Ein Risiko ist nur dann „behandelt“, wenn die Maßnahme nachweislich wirkt – nicht, wenn sie einmal beschlossen wurde. Diese Logik wirkt heute in allen Vorgaben fort.

Die Cloud ist längst kein Zukunftsthema mehr, sondern Alltag. Unternehmen aller Größenordnungen verlagern Daten, Anwendungen und ganze Infrastrukturen in die Cloud – aus guten Gründen: Flexibilität, Skalierbarkeit, schnellere Time-to-Market und planbarere Kosten. Doch wo Geschwindigkeit und Dynamik steigen, wachsen auch die Risiken. Viele Organisationen gehen Cloud Security noch immer zu intuitiv an – ohne eindeutige Ziele, ohne messbare Kontrollen, ohne gelebte Verantwortlichkeiten. Die Folge: Fehlkonfigurationen bleiben unentdeckt, Identitäten sind überprivilegiert, Protokolle fehlen, Nachweise für Compliance sind lückenhaft. Wer Cloud Security ernst nimmt, braucht mehr als Tools – er braucht einen Plan: klar, wiederholbar, auditierbar.

Ziele und Schutzbedarfe: Was wirklich geschützt werden muss

Der wirksamste erste Schritt ist eine Schutzbedarfsanalyse mit eindeutiger Priorisierung. Typische Klassen sind: