Compliance ist das Nebenprodukt, nicht das Ziel
Ein technischer Regelkreis hält die Server im sicheren Zustand — aber er spricht eine Sprache, die kein Geschäftsführer versteht. Wie man aus Maschinenzustand eine Risikoposition macht, über die man entscheiden kann. Teil zwei.
Im ersten Teil ging es um einen geschlossenen Regelkreis: Ein Inventar, das weiß, was existiert. Eine Automation, die durchsetzt, wie es sein soll. Eine Überwachung, die prüft, ob es so bleibt, und bemerkt, wenn jemand daran rüttelt. Ein System, das sich selbst im sicheren Zustand hält.
Dieser Kreis funktioniert. Er hat nur einen blinden Fleck, und der sitzt nicht in der Technik, sondern an der Grenze zwischen Maschine und Mensch. Denn alles, was der Kreis produziert, ist in einer Sprache verfasst, die die Geschäftsführung nicht spricht. Ein Ticket über eine abweichende SSH-Konfiguration. Ein Prüfergebnis zur Firewall. Eine Meldung des File Integrity Monitoring. Das sind Fakten — präzise, aktuell, belastbar. Aber es sind Maschinenfakten, und für die Person, die das Unternehmen führt, sind sie ungefähr so aussagekräftig wie ein Röntgenbild für jemanden ohne medizinische Ausbildung.
Ein Geschäftsführer kann nicht über sshd_config entscheiden. Er kann über Risiko entscheiden.Die Frage, die ihn erreicht, muss lauten: Welche Gefahr besteht für welche Fähigkeit des Unternehmens, wie wahrscheinlich ist sie, und was kostet es, sie zu schließen oder zu tragen? Zwischen dem Maschinenfakt und dieser Frage liegt eine Übersetzung, die nicht von allein passiert.
Die fehlende Ebene
Diese Übersetzung ist die Aufgabe der Ebene über dem technischen Kreis. In meinem Stack übernimmt sie CISO Assistant — und ich benutze den Namen mit einer Vorbemerkung, weil er in die falsche Erwartung führt. Das Werkzeug wird als GRC-Plattform verkauft, als etwas für "Governance, Risk und Compliance". Wer es so einsetzt, bekommt genau das: einen Aktenschrank für Normen. Das ist nicht das, wovon ich hier rede.
Interessant wird das Werkzeug, wenn man es umgekehrt betrachtet. Nicht als Ort, an dem man Normen ablegt, sondern als Glasscheibe, durch die der Maschinenzustand von unten zur Risikoposition wird. Die Evidenz, die der Regelkreis ohnehin ununterbrochen erzeugt — welche Kontrollen greifen, welche Abweichungen auftreten, welcher Teil der Flotte in welchem Zustand ist — wird hier nicht neu erhoben, sondern eingeordnet. Aus „diese Kontrolle ist auf 40 von 42 Servern aktiv" wird eine Aussage über ein konkretes Risiko und darüber, wie weit es geschlossen ist.
Das ist der eigentliche Wert: nicht eine weitere Liste, sondern die Verbindung zwischen dem, was die Maschinen wissen, und dem, worüber Menschen entscheiden müssen.
Restrisiko ist eine Entscheidung, kein Zufall
Ein gut gebauter Regelkreis schließt die meisten Risiken automatisch. Er härtet, prüft, korrigiert — und tut das, ohne dass jemand morgens daran denken muss. Genau deshalb entsteht eine gefährliche Bequemlichkeit: Man verwechselt „das meiste ist abgedeckt" mit „wir sind sicher".
Was übrig bleibt, ist das Restrisiko. Und Restrisiko hat eine unangenehme Eigenschaft: Es existiert, ob man es benennt oder nicht. Der Unterschied ist nur, ob es eine bewusste Entscheidung ist oder eine stille Voreinstellung.
Ein Risiko, das niemand ausgesprochen hat, ist nicht kleiner — es ist bloß unentschieden. Und unentschieden heißt in der Praxis: Es wurde akzeptiert, ohne dass jemand die Verantwortung dafür übernommen hätte.
Hier liegt der strategische Kern. Die Aufgabe der Risikoebene ist nicht, das Restrisiko wegzuzaubern — das kann sie nicht. Ihre Aufgabe ist, es auf den Tisch zu legen. Sichtbar zu machen, was der Regelkreis nicht abdeckt, und diese Lücke zu einer Wahl zu machen: tragen, mindern oder verlagern. Das ist eine unternehmerische Entscheidung, keine technische. Und sie gehört dorthin, wo im Unternehmen Entscheidungen über Chancen und Gefahren getroffen werden — nicht in ein IT-Ticket, das per Voreinstellung „so lassen" bedeutet.
Sicherheit wird damit vom Zustand, den die IT verwaltet, zum Instrument, mit dem die Geschäftsführung steuert.
Warum das ein Verkaufsargument ist
Und jetzt kippt die ganze Perspektive. Dieselbe Evidenz, die einen Auditor zufriedenstellen würde, ist nämlich zu schade, um sie nur einem Auditor zu zeigen.
Stellen Sie sich zwei Unternehmen vor, die um denselben Auftrag konkurrieren, und der Kunde fragt beide nach ihrer Informationssicherheit. Das erste legt einen Ordner vor: Richtlinien, Prozessbeschreibungen, ein Zertifikat von vor zwei Jahren. Alles korrekt, alles papiern, und niemand im Raum weiß, wie viel davon im Alltag tatsächlich gilt. Das zweite zeigt eine aktuelle Risikoposition, gestützt auf Evidenz aus einem laufenden System, das seinen eigenen Zustand ununterbrochen prüft — und kann sagen: Diese Risiken schließen wir automatisch, dieses Restrisiko haben wir bewusst so entschieden, und hier ist der Nachweis, dass beides stimmt.
Der Unterschied ist nicht Gründlichkeit. Der Unterschied ist zwischen einem Versprechen und einem Beleg.
Der erste Anbieter behauptet Sicherheit. Der zweite führt sie vor.
In einem Markt, in dem der Kunde jedem misstrauen muss, ist die Fähigkeit, den eigenen Zustand zu zeigen statt ihn zu beteuern, kein Compliance-Vorteil. Es ist ein Vertriebsvorteil.
Und genau deshalb ist Compliance in dieser Architektur das Nebenprodukt. Sie fällt ab, ohne das Ziel zu sein. Wer den technischen Regelkreis baut und ihn mit einer ehrlichen Risikoebene überzieht, erfüllt die meisten Normen als Kollateraleffekt — nicht, weil er auf die Norm hingearbeitet hat, sondern weil eine Norm im Kern nichts anderes will als das, was hier ohnehin passiert: einen definierten, überwachten, entschiedenen Umgang mit Risiko.
Man bekommt das Häkchen geschenkt, wenn man die Substanz gebaut hat. Umgekehrt funktioniert es nicht.
Zwei Ebenen, ein Zweck
Damit stehen die beiden Teile zusammen. Der Regelkreis unten hält die Flotte ehrlich — er sorgt dafür, dass der tatsächliche Zustand dem entspricht, den man deklariert hat. Die Risikoebene oben hält das Unternehmen informiert — sie sorgt dafür, dass die Geschäftsführung weiß, was dieser Zustand bedeutet, und über das entscheidet, was er offenlässt.
Das eine ohne das andere ist unvollständig. Ein technischer Kreis ohne Risikoebene produziert Sicherheit, die niemand im Management versteht und über die niemand entscheidet. Eine Risikoebene ohne technischen Unterbau produziert Aussagen ohne Deckung — den Ordner von oben, papierne Sicherheit, die im Ernstfall nicht hält.
Zusammen ergeben sie etwas, das im Mittelstand selten ist: Sicherheit, die keine Kostenstelle ist, sondern ein Führungsinstrument. Etwas, das man nicht erträgt, weil man muss, sondern einsetzt, weil es wirkt — und weil man damit im entscheidenden Moment etwas kann, das der Wettbewerb nicht kann: den eigenen Zustand zeigen, statt ihn zu behaupten.
Über den Autor
Gerd Kopp ist Wirtschaftsinformatiker und war über 14 Jahre CIO, zuletzt als Head of Corporate Operations. Seit 2020 ist er selbstständiger Interim Manager und IT-Berater. Er arbeitet mit Mittelstandsunternehmen, die Wachstum, Effizienz und Wettbewerbsfähigkeit nicht dem Zufall überlassen wollen — und die verstanden haben, dass die richtigen Prozesse, Strukturen, Technologien und der gezielte Einsatz von KI dabei keine Nebensache sind, sondern der Unterschied.
Mehr unter gerds-it.de. In seinem Innovation Lab erprobt und bewertet er Technologien und Architekturen wie die hier beschriebene, bevor sie in den Produktiveinsatz gehen.
Transparenzhinweis: Dieser Beitrag entstand mit KI-Unterstützung. Konzept, Architektur und die zugrunde liegende Praxis stammen aus meinem eigenen Stack — die KI war Werkzeug, nicht Autor.