Es gibt Jahre, in denen Governance wie ein gepflegter Maschinenraum wirkt: saubere Schaltbilder, klare Zuständigkeiten, geölte Prozesse, Prüfzeichen am richtigen Ort. Und es gibt Jahre, in denen das gleiche Bild plötzlich alt aussieht. 2026 ist so ein Jahr. Die Architektur der Kontrolle – Regeln, Freigaben, Checklisten – bewährt sich weiterhin, aber sie reicht nicht mehr aus, um Organisationen durch eine Welt zu steuern, in der digitale Abhängigkeiten unübersichtlich, Lieferketten fragil, regulatorische Erwartungen dynamisch und Technologien wie KI, Cloud und vernetzte Produkte zum Taktgeber geworden sind. Der Satz „Kontrolle allein reicht nicht“ klingt wie eine Plattitüde. In Wahrheit markiert er einen Wendepunkt: Governance verschiebt sich von der Frage „Ist es freigegeben?“ zu „Hält es unter Last – und können wir das beweisen, während wir uns anpassen?“

Der Bruch mit der Kontrolllogik

Die Klassik der Governance wurde von zwei Grundgedanken getragen: Erstens lässt sich Risiko durch Regeln und Rollen beherrschen. Zweitens genügt es, die Einhaltung in Zyklen zu prüfen – Jahresabschluss, Auditplan, Projektgate. Das funktionierte, solange Veränderung langsam und Abhängigkeiten überschaubar waren. Heute kollidieren beide Annahmen mit der Praxis. Veränderungen passieren kontinuierlich (Feature-Rollouts, Infrastruktur-Drifts, Datenströme), und Abhängigkeiten ziehen systemische Effekte nach sich (ein Ausfall in der Lieferkette, ein Software-Bug, eine kompromittierte Identität). Kontrolle bleibt nötig – aber sie ist nicht mehr die Königsdisziplin. Die neue Frage lautet: Wie bleibt die Organisation handlungsfähig, obwohl Kontrolle versagen kann – und wie lernt sie schneller als die Welt sich ändert?

In der Welt der Informationssicherheit gab es immer wieder Schlagworte, die als „Must-have“ galten: Firewalls, Virenscanner, ISO 27001, Cloud Security, Zero Trust. Jedes dieser Themen hatte seine Zeit im Rampenlicht. Heute ist der Begriff, der in Vorträgen, Strategiepapiere und Gesetzesentwürfe gleichermaßen auftaucht, Cyber-Resilienz. Er klingt modern, fast schon schick – und genau deshalb wird er oft oberflächlich behandelt. Aber hinter diesem Schlagwort steckt weit mehr als ein Marketingtrend. Cyber-Resilienz ist nicht nur eine Erweiterung klassischer IT-Sicherheit, sondern ein strategischer Ansatz, der Unternehmen widerstandsfähig gegen digitale Angriffe, technische Störungen und sogar komplexe Krisen macht. Kurz gesagt: Es geht nicht mehr nur darum, Angriffe zu verhindern, sondern darum, auch dann handlungsfähig zu bleiben, wenn sie unvermeidlich eintreten.

Von Prävention zu Anpassungsfähigkeit: Was Cyber-Resilienz wirklich bedeutet

Der zentrale Unterschied zwischen traditioneller IT-Sicherheit und Cyber-Resilienz liegt in der Perspektive. Klassische Sicherheitskonzepte fokussieren stark auf Prävention – also darauf, Angriffe zu blockieren, Schwachstellen zu schließen und Risiken zu minimieren. Das ist wichtig, aber in einer Welt, in der Angreifer immer schneller neue Taktiken entwickeln und selbst hochgesicherte Systeme kompromittieren können, reicht Prävention allein nicht mehr aus. Cyber-Resilienz ergänzt diesen Ansatz um Detektion, Reaktion, Wiederherstellung und Lernen. Das bedeutet: Wir akzeptieren, dass ein Angriff oder Ausfall passieren kann, und sorgen dafür, dass wir schnell erkennen, angemessen reagieren und uns effizient erholen – ohne dass der Geschäftsbetrieb vollständig zum Erliegen kommt.

Manche Sicherheitsgeschichten beginnen mit einem Genie an der Kommandozeile, einem Domain-Admin im Mantel der Nacht, einem perfekt orchestrierten Angriff auf Kerberos oder KMS. Die meisten beginnen anders: mit alltäglichen Rechten, die niemand für gefährlich hält. Ein „Viewer“ in der Doku-Plattform. Ein „Reporting“-Zugang im CRM. Ein „Guest“ im Kollaborationstool. Ein Servicekonto mit Leserechten auf Logdateien. Ein Praktikanten-Account, der nur Tickets lesen darf. Diese scheinbar harmlosen Berechtigungen sind die Welt des Insider light – Personen und Prozesse innerhalb (oder knapp außerhalb) der Organisation, die keine „großen“ Rechte brauchen, um große Lücken zu reißen. Nicht, weil sie Superhacker wären, sondern weil unsere Systeme Informationen großzügig streuen, Workflows automatisch auslösen und Meta­daten verräterischer sind, als uns lieb ist. Wer Sicherheit heute ernst meint, darf das kleine Licht nicht unterschätzen, denn es beleuchtet überraschend viele Wege bis ins Herz der Organisation.

Was genau ist „Insider light“?

„Insider“ weckt oft das Bild des böswilligen Mitarbeiters mit Vollzugriff. „Light“ verschiebt die Perspektive: Es geht um Akteure mit begrenzten, formal unkritischen Rechten, die dennoch kritische Wirkung entfalten – absichtlich, fahrlässig oder weil sie selbst zum Opfer werden. Das Spektrum ist breit:

Es knirscht selten laut, wenn es passiert. Kein großer Knall, keine rot blinkenden Warnlampen. Stattdessen: eine kleine Konfigurationsänderung bei einem Dienstleister, ein unscheinbares Update, eine freundliche E-Mail eines „Partners“, ein Browser-Plugin aus einem Hersteller-Marketplace. Wochenlang wirkt alles normal, die Dashboards bleiben grün. Und doch hat sich die Risikolage grundlegend verschoben – nur eben nicht dort, wo das eigene SOC hinschaut. Die Schwachstelle liegt außerhalb des Perimeters, außer Reichweite der üblichen Telemetrie und häufig auch jenseits der eigenen Zuständigkeiten. Genau dort, wo moderne Wertschöpfung in der Praxis stattfindet: bei Third Parties.

Dass Drittparteien zur Achillesferse werden, ist keine überraschende Schlagzeile – aber die Mechanik dahinter wird in vielen Unternehmen unterschätzt. Third Parties stehen mitten in unseren Prozessen, tragen weitreichende Berechtigungen, hosten Daten, signieren Updates, verwalten Identitäten, triagieren Tickets, betreiben Infrastruktur und liefern das, was Kundinnen und Kunden direkt erleben: Verfügbarkeit, Geschwindigkeit, Qualität. In dieser Rolle sind sie nicht „außen“, sondern innen – oft mit mehr Rechten, mehr Einblick und mehr Steuerungsmacht als das, was wir im eigenen Haus für selbstverständlich halten.

Backups gelten als Sicherheitsgurt der IT. Sie beruhigen, wenn alles andere schiefgeht, sie legitimieren mutige Veränderungen und sie sind – so die bequeme Erzählung – die letzte Verteidigungslinie gegen Ransomware, Fehlkonfigurationen und menschliche Irrtümer. Doch genau in dieser Bequemlichkeit steckt ein Risiko. Wer Backups nur als „haben wir“ verbucht, übersieht, dass sie selbst zu Angriffsfläche, Compliance-Falle, Kostenbremse und Operations-Risiko werden können. Dieses Paradoxon begegnet man erst dann, wenn es weh tut: im Incident Room, wenn Wiederherstellungen scheitern; im Audit, wenn Aufbewahrungsfristen und Löschpflichten kollidieren; in der Lieferkette, wenn ein Dienstleister die Telemetrie nicht liefert; im Budget, wenn Zombie-Backups in der Cloud unbemerkt Millionen verschlingen. Zeit, hinzusehen: Wann werden Backups zur Gefahr – und wie baut man sie so, dass sie nicht zum Problem, sondern zum Beweis der eigenen Handlungsfähigkeit werden?

Das Backup-Paradoxon

Je erfolgreicher die Datensicherung, desto unsichtbarer wird sie. Sie läuft nachts, sie meldet „grün“, sie erzeugt beruhigende Reports. Doch Sichtbarkeit ist nicht gleich Wirksamkeit. „Job erfolgreich“ bedeutet nicht, dass sich eine kritische Anwendung konsistent wiederherstellen lässt. „Immutability aktiv“ bedeutet nicht, dass Angreifer nicht doch Löschbefehle platzieren können – über die falschen Adminrechte, die richtige API oder einen Delegationsfehler. „Replikation aktiv“ bedeutet nicht, dass man ein sicheres Restore-Zeitfenster hat; Replikation multipliziert auch Korruption und Verschlüsselung in Rechenzeit, nicht in Tagen. Was zählt, ist nicht die Existenz von Kopien, sondern die Fähigkeit, gezielt, schnell und integer zu rekonstruieren – und das nachweisbar.