Risk-Meetings hatten lange einen festen Ablauf: Heatmaps, Erfahrungswerte, ein paar Szenarien, viele Bauchentscheidungen. Heute sitzt ein neuer Akteur am Tisch – unscheinbar, datenhungrig, unermüdlich: Algorithmen. Sie werten Logströme aus, gewichten Lieferkettenereignisse, schätzen Schadenshöhen, berechnen Eintrittswahrscheinlichkeiten, schlagen Maßnahmenkombinationen vor. „KI im Kontrollraum“ ist mehr als ein weiteres Tool im Baukasten. Es ist ein Paradigmenwechsel: Risiken werden laufend gemessen, modelliert und gesteuert – nicht nur beraten. Doch die Verheißung hat eine Bedingung: Nur wer Technik, Daten, Governance und Kultur gleichzeitig ernst nimmt, gewinnt Tempo und Vertrauen. Dieser Beitrag zeigt, wie das gelingt – ohne Mythos, ohne Illusion. Mit Architekturen, die funktionieren, mit Metriken, die handeln lassen, mit Rollen, die entscheiden, und mit Leitplanken, die Akzeptanz sichern.

1) Warum KI jetzt im Risikomanagement landet – und bleibt

Drei Entwicklungen treiben die Verlagerung in die Maschine:

Die EU verschärft ihre Anforderungen an die IT-Sicherheit – und zwar deutlich. Mit der NIS2-Richtlinie tritt ab Ende 2024 ein Regelwerk in Kraft, das für viele Unternehmen zum ersten Mal echte gesetzliche Pflichten im Bereich Cybersicherheit mit sich bringt. Die ursprüngliche NIS-Richtlinie aus dem Jahr 2016 war ein erster Schritt in Richtung mehr Resilienz gegen Cyberangriffe, wurde jedoch in vielen Mitgliedstaaten zu zögerlich umgesetzt. Die Unterschiede zwischen den Ländern waren groß, und viele kritische Branchen blieben außen vor. NIS2 will genau das ändern: einheitliche Standards in ganz Europa schaffen, den Anwendungsbereich massiv erweitern und bei Verstößen spürbare Konsequenzen durchsetzen.

Für Unternehmen bedeutet das: Wer bisher dachte, nicht zu den „klassischen“ Betreibern kritischer Infrastrukturen zu gehören, könnte jetzt überraschend feststellen, dass er doch betroffen ist. Der Geltungsbereich wurde so ausgeweitet, dass nicht nur Stromversorger oder Krankenhäuser, sondern auch IT-Dienstleister, Logistikunternehmen, Lebensmittelproduzenten oder Betreiber von Online-Plattformen in den Fokus rücken. Die Umsetzungsfrist läuft am 17. Oktober 2024 ab – wer bis dahin nicht vorbereitet ist, riskiert Bußgelder, Aufsichtsmaßnahmen und Reputationsschäden. Gleichzeitig eröffnet NIS2 die Chance, Sicherheit strukturiert auf ein neues Niveau zu heben – mit messbarem Nutzen für Betrieb, Kundenvertrauen und Krisenfestigkeit.

GRC – Governance, Risk & Compliance – galt jahrelang als vernünftiger Dreiklang, in der Praxis aber oft als Dreifaltigkeit der Silos. Governance schrieb Richtlinien, Risk malte Heatmaps, Compliance pflegte Ordner – jede Disziplin korrekt im eigenen Kosmos, selten im Gleichklang. Das Ergebnis: viele Aktivitäten, wenig Wirkung. Heute, mit überlappenden Aufsichten (DORA, NIS2, AI Act, CRA, CSRD), komplexen Lieferketten und softwaregetriebener Wertschöpfung, bricht dieses Modell sichtbar. Was fehlt, ist kein weiterer Standard, sondern eine Arbeitsweise, die GRC zu einem System macht: aus einem Guss geplant, aus Daten gespeist, im Betrieb verankert, mit Nachweisen, die aus dem Tun entstehen – nicht aus dem Nachzeichnen. Dieser Beitrag zeigt, wie die Integration gelingt: organisatorisch, technisch, kulturell. Und warum „integriert“ nicht bedeutet, alles zu zentralisieren, sondern Schnittstellen so zu gestalten, dass Arbeit fließt.

1) Warum die alte GRC-Logik scheitert – und zwar zuverlässig

Silos sind bequem. Jedes Team setzt seine Tools, seine Taxonomie, seine KPIs. Doch drei strukturelle Brüche machen das alte Modell unhaltbar:

Wenn wir heute das Wort „Hacker“ hören, schießen den meisten sofort stereotype Bilder in den Kopf: ein dunkler Raum, das fahle Licht eines Monitors, grüne Zeichenketten, die über den Bildschirm laufen, und irgendwo eine Person mit Kapuzenpulli, die blitzschnell tippt. Dieses Bild ist das Produkt von Filmen, Schlagzeilen und Popkultur – und es hat mit der Realität nur am Rande zu tun. Die Wahrheit ist: Hacker gibt es, seit es komplexe Systeme gibt. Lange bevor es Computer und Internet gab, versuchten Menschen, diese Systeme zu verstehen, zu hinterfragen, zu manipulieren oder zu verbessern. Die Geschichte des Hackens beginnt nicht mit Silicon Valley, sondern reicht zurück in eine Zeit, in der Nachrichten über optische Signale übertragen wurden und Telefonnetze noch von mechanischen Wählscheiben beherrscht wurden.

Frühe Systeme: Telegraf, Funk und der Informationsvorsprung

Der erste bekannte „Hack“ fand im Jahr 1834 statt und hatte mit Elektronik noch nichts zu tun. In Frankreich betrieb die Regierung ein hochmodernes optisches Telegrafensystem, bei dem Signale über große Entfernungen mithilfe von mechanischen Armen und Sichtlinien weitergegeben wurden. Zwei findige Geschäftsmänner, François und Joseph Blanc, erkannten, dass dieses Netz ihnen einen entscheidenden Vorteil an der Börse verschaffen konnte. Sie bestachen einen Telegrafenbeamten, der in den offiziellen Übertragungen winzige, kaum wahrnehmbare Veränderungen vornahm – Änderungen, die für Außenstehende bedeutungslos wirkten, für die beiden jedoch verschlüsselte Botschaften darstellten. So erhielten sie Kursinformationen schneller als alle anderen und konnten diese für gewinnbringende Geschäfte nutzen. Es war der erste dokumentierte Fall, bei dem ein bestehendes Kommunikationssystem manipuliert wurde, um einen Informationsvorsprung zu erlangen – der Urtypus des Hackens. Das 19. und frühe 20. Jahrhundert kannte viele solcher Manipulationen, auch wenn niemand sie damals als „Hacks“ bezeichnete. In den USA etwa nutzten Kriminelle schon in den 1860er-Jahren Telegrafenleitungen, um Pferderenn-Ergebnisse zu verzögern oder zu verändern und damit Wetten zu manipulieren; in den 1920er-Jahren traten Funkpiraten auf den Plan, die Radiowellen kaperten, um eigene Botschaften auszustrahlen oder offizielle Übertragungen zu stören. In allen Fällen ging es darum, die Funktionsweise eines Systems zu verstehen, seine Grenzen auszutesten und es dann kreativ – oder kriminell – zu nutzen.

C5 – der Cloud Computing Compliance Criteria Catalogue des BSI – hat eine erstaunliche Karriere hinter sich. Was als Antwort auf die notorische Intransparenz großer Plattformen begann, ist heute vielerorts Prüfstandard, Einkaufsfilter und Beruhigungspille in einem. Genau darin liegt die Gefahr: Wenn C5 nur noch als Etikett am Anbieterprofil hängt, verliert er seine Kraft. Dann wird aus der Idee einer belastbaren, nachvollziehbaren und anschlussfähigen Prüfung ein Alibi. Und Alibis sind bequem – bis der erste Vorfall Druck erzeugt und plötzlich alle wissen wollen, was, wann, warum geprüft wurde, wer wofür verantwortlich ist und welche Belege den Unterschied machen. Dieser Beitrag zeigt, wie C5 vom Stempel zur Steuerung wird: als operativer Prüfrahmen, der Architektur, Betrieb, Einkauf, Recht, Revision und Aufsicht zusammenbringt, statt sie in parallelen Diskussionen verharren zu lassen.

Vom Kriterienkatalog zum Betriebsinstrument

Die Frage „Audit oder Alibi?“ entscheidet sich an einer simplen Beobachtung: Entstehen Beweise nebenbei im Betrieb – oder werden sie nachträglich zusammengetragen, wenn ein Audit im Kalender steht? Ein Katalog allein beantwortet das nicht. C5 liefert die Sprache (Kontrollziele, Kontrollen, Feststellungen, Zeiträume), aber erst die Umsetzung schafft Substanz. Dort, wo Unternehmen C5 am Lebenszyklus ausrichten, verändert er das Arbeiten: