
Cyber Governance
Cyber Governance betrachtet den Umgang mit Cyberrisiken als Führungs- und Steuerungsaufgabe.
Von Dr. Markus Groß
GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Das COBIT-Rahmenwerk basiert auf folgendem Prinzip: Um die Informationen bereitzustellen, die das Unternehmen zur Erreichung seiner Ziele benötigt, muss das Unternehmen in IT-Ressourcen investieren und diese verwalten und steuern. Dazu muss es einen strukturierten Satz von Prozessen verwenden, um die Dienste bereitzustellen, die die erforderlichen Unternehmensinformationen liefern. Die Verwaltung und Kontrolle von Informationen sind das Herzstück des COBIT-Frameworks und tragen dazu bei, die Anpassung an die Geschäftsanforderungen sicherzustellen.
Die Verwaltung und Kontrolle von Informationen sind das Herzstück des COBIT-Frameworks und tragen dazu bei, die Anpassung an die Geschäftsanforderungen sicherzustellen. COBIT definiert IT-Aktivitäten in einem generischen Prozessmodell innerhalb von vier Domänen. Diese Domänen sind Planen und Organisieren (PO), Akquirieren und Implementieren (AI), Bereitstellen und Unterstützen (DS) sowie Überwachen und Bewerten (ME). Die Domänen entsprechen den traditionellen Verantwortungsbereichen der IT: Planen, Erstellen, Ausführen und Überwachen.
Um die IT effektiv zu verwalten, ist es wichtig, die Aktivitäten und Risiken innerhalb der IT zu kennen, die verwaltet werden müssen. Sie sind in der Regel den Zuständigkeitsbereichen Planen, Bauen, Betreiben und Überwachen zugeordnet. Innerhalb des COBIT-Rahmens werden diese Bereiche genannt:
PLAN AND ORGANISE (PO)
Dieser Bereich umfasst Strategie und Taktik und betrifft die Ermittlung der Art und Weise, wie die IT am besten zur Erreichung der Geschäftsziele beitragen kann. Dieser Bereich befasst sich in der Regel mit den folgenden Managementfragen:
- Sind die IT und die Geschäftsstrategie aufeinander abgestimmt?
- Erreicht das Unternehmen eine optimale Nutzung seiner Ressourcen?
- Versteht jeder in der Organisation die IT-Ziele?
- Werden die IT-Risiken verstanden und gemanagt?
- Ist die Qualität der IT-Systeme den Geschäftsanforderungen angemessen?
ACQUIRE AND IMPLEMENT (AI)
Zur Umsetzung der IT-Strategie müssen IT-Lösungen identifiziert, entwickelt oder beschafft, sowie implementiert und in den Geschäftsprozess integriert werden. Darüber hinaus fallen Änderungen und Wartung bestehender Systeme in diesen Bereich, um sicherzustellen, dass die Lösungen weiterhin den Geschäftszielen entsprechen. Dieser Bereich befasst sich in der Regel mit den folgenden Managementfragen:
- Sind neue Projekte geeignet, Lösungen zu liefern, die den Geschäftsanforderungen entsprechen?
- Werden neue Projekte wahrscheinlich pünktlich und innerhalb des Budgets geliefert?
- Werden die neuen Systeme nach der Implementierung ordnungsgemäß funktionieren?
- Werden Änderungen vorgenommen, ohne den laufenden Geschäftsbetrieb zu stören?
DELIVER AND SUPPORT (DS)
In diesem Bereich geht es um die tatsächliche Bereitstellung der erforderlichen Dienste, wozu die Bereitstellung von Diensten, das Management von Sicherheit und Kontinuität, die Unterstützung der Nutzer und die Verwaltung von Daten und Betriebseinrichtungen gehören. Er befasst sich in der Regel mit den folgenden Managementfragen:
- Werden die IT-Dienstleistungen in Übereinstimmung mit den Geschäftsfachleuten erbracht?
- Werden die IT-Kosten optimiert?
- Sind die Mitarbeiter in der Lage, die IT-Systeme produktiv und sicher zu nutzen?
- Sind angemessene Vertraulichkeit, Integrität und Verfügbarkeit für die Informationssicherheit gewährleistet?
MONITOR AND EVALUATE (ME)
Alle IT-Prozesse müssen im Laufe der Zeit regelmäßig auf ihre Qualität und die Einhaltung der Kontrollanforderungen hin überprüft werden. In diesem Bereich geht es um Leistungsmanagement, Überwachung der internen Kontrolle, Einhaltung von Vorschriften und Governance. Er befasst sich in der Regel mit den folgenden Managementfragen:
- Wird die Leistung der IT gemessen, um Probleme zu erkennen, bevor es zu spät ist?
- Stellt das Management sicher, dass die internen Kontrollen effektiv und effizient sind?
- Kann die IT-Leistung wieder mit den Geschäftszielen verknüpft werden?
- Sind angemessene Vertraulichkeits-, Integritäts- und Verfügbarkeitskontrollen für die Informationssicherheit vorhanden?
Ein Prinzip an einer Zielkollision überprüfen. Betrachten Sie eine Entscheidung, bei der Nutzen, Risiko und Ressourcen gegeneinander abzuwägen sind. Halten Sie fest, wer diese Abwägung trifft und welche Informationen dafür benötigt werden.
Cyber Governance betrachtet den Umgang mit Cyberrisiken als Führungs- und Steuerungsaufgabe.
Von Dr. Markus Groß
Die damalige Beobachtung zu „Die grundlegenden COBIT-Prinzipien“ wird hier nicht ersetzt, sondern praktisch weitergedacht. Im Fokus stehen bei Prozessnutzen überprüfbare Voraussetzungen, erkennbare Grenzen und ein im Alltag belastbarer Umgang.
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Die grundlegenden COBIT-Prinzipien“ zu einer klaren Prüffrage: Es ist zu klären, welche nächste Fähigkeit wichtiger ist als eine möglichst hohe Stufe. Beim Schwerpunkt „Die grundlegenden COBIT-Prinzipien“ geht es um ein Management- oder Governance-Framework und seine praktische Nutzung sowie um den Bezug zu „Managementbedarf“; zu entscheiden ist, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Verbesserungsschritt“), ohne das Framework zum Selbstzweck zu machen. Die Grenze der Betrachtung bleibt eindeutig: Ein Framework liefert Orientierung (hier bezogen auf „Arbeitsergebnis“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Im Regelbetrieb wird folgender Punkt verankert: Reife an beobachtbarer Praxis statt an Selbsteinschätzung festmachen. Der vorgesehene Nachweis lautet: ein priorisierter Entwicklungsschritt mit messbarem Abschluss. Als Messperspektive dient: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „klare Zuständigkeiten und Entscheidungsrechte“ aufnehmen; als Bezugspunkt dient „Arbeitsergebnis“. Aus der Perspektive „Managementbedarf“ entsteht daraus eine konkrete Rückfrage an die Umsetzung.
Für die heutige Einordnung von „Managementbedarf“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, ob die Maßnahme das beabsichtigte Risiko oder Ergebnis tatsächlich verändert. Beteiligt sind hier vor allem Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision; ihre Perspektiven treffen beim Aspekt „Rollenklarheit“ unmittelbar aufeinander; bezogen auf „Verbesserungsschritt“ ist die konkrete Ausprägung separat zu entscheiden. Besondere Aufmerksamkeit verdient das Szenario, in dem Terminologie und Prozessbilder wachsen (hier bezogen auf „Auswahl der Praktiken“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Die praktische Konsequenz heißt: Design, Ausführung und Wirkung getrennt beurteilen; die Umsetzung wird dabei an „Methodenumfang“ gespiegelt. Der vorgesehene Nachweis lautet: eine Wirkungsprüfung mit Gegenbeispiel und Folgemaßnahme; im Fokus steht dabei „Auswahl der Praktiken“. Als Messperspektive dient: der Zusammenhang zwischen „Managementbedarf“ und „Rollenklarheit“. Der gewählte Weg sollte sich außerdem umkehren lassen, falls die Annahmen zu „Rollenklarheit“ später nicht mehr tragen.
Für die belastbare Anwendung von „Reifeentwicklung“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, welche Alternativen zwischen vollständigem Verbot und uneingeschränkter Freigabe liegen. Als belastbare Grundlage dienen Zielproblem, ausgewählte Praktiken, Rollenentscheidung, Arbeitsergebnisse, Abweichungen und Verbesserungsnachweise; für den Aspekt „Reifeentwicklung“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Methodenumfang“ sollte deshalb ausdrücklich festhalten, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Methodenumfang“), ohne das Framework zum Selbstzweck zu machen; als Bezugspunkt dient „Anpassungstiefe“. Der nächste Arbeitsschritt lautet: Optionen nach Nutzen, Risiko, Aufwand und Rückbaubarkeit vergleichen; im Fokus steht dabei „Wirkungsprüfung“. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: eine dokumentierte Optionsentscheidung mit verworfenen Alternativen; die Umsetzung wird dabei an „Integration“ gespiegelt. Die Ergebnisbeobachtung richtet sich auf: die beobachtbare Veränderung beim Aspekt „Kosten, Aufwand und eine faire Verteilung“; im Fokus steht dabei „Integration“. Die Leserperspektive auf „Kosten, Aufwand und eine faire Verteilung“ schärft den Blick dafür, ob „Methodenumfang“ nur beschrieben oder tatsächlich gesteuert wird.
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Prozessnutzen“ zu einer klaren Prüffrage: Es ist zu klären, welcher bestehende Prozess den neuen Prüfschritt sinnvoll aufnehmen kann. Die alltagstaugliche Übersetzung für „Prozessnutzen“ lautet: Nur die für das Ziel erforderlichen Elemente werden übernommen und anhand beobachtbarer Ergebnisse weiterentwickelt – betrachtet im Kontext „Die grundlegenden COBIT-Prinzipien“. Damit wird zugleich die Grenze beim Aspekt „Wirkungsprüfung“ sichtbar: Ein Framework liefert Orientierung (hier bezogen auf „Anpassungstiefe“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Für den nächsten Review wird vereinbart: Beschaffung, Berechtigung, Änderung oder Offboarding gezielt erweitern; für „Die grundlegenden COBIT-Prinzipien“ ist das Ergebnis gesondert festzuhalten. Der vorgesehene Nachweis lautet: ein eingebetteter Kontrollpunkt ohne parallelen Sonderprozess; der konkrete Prüfmaßstab wird aus „Managementbedarf“ abgeleitet. Als Messperspektive dient: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung; die Umsetzung wird dabei an „Managementbedarf“ gespiegelt. Im Managementdialog muss beim Aspekt „Prozessnutzen“ erkennbar bleiben, welche Unsicherheit akzeptiert und welche aktiv reduziert wird.
Für die heutige Einordnung von „Rollenklarheit“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Entscheidung nicht an Technik oder Dokumentation delegiert werden darf. Ein realistischer Belastungstest betrachtet den Fall, dass Terminologie und Prozessbilder wachsen (hier bezogen auf „Integration“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben; „Managementbedarf“ liefert dafür den praktischen Anwendungsfall. Für die beteiligten Rollen – Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision – braucht der Aspekt „Rollenklarheit“ daher einen vorab geklärten Entscheidungsweg. Für den nächsten Review wird vereinbart: Zielkonflikt, Optionen, Konsequenzen und Empfehlung entscheidungsreif verdichten; als Bezugspunkt dient „Prozessnutzen“. Der vorgesehene Nachweis lautet: eine nachvollziehbare Managemententscheidung mit Auftrag; der Belastungstest erfolgt mit Blick auf „Rollenklarheit“. Als Messperspektive dient: der Zusammenhang zwischen „Rollenklarheit“ und „Die grundlegenden COBIT-Prinzipien“. Die bisherige Diskussion liefert mit „Messbarkeit und nachgewiesene Wirkung“ einen zusätzlichen Prüfstein; er sollte mit „Die grundlegenden COBIT-Prinzipien“ verbunden und nicht isoliert bewertet werden.
Der Praxistest für Reifeentwicklung bleibt bewusst einfach: Die Regel zu Prozessnutzen muss im Normalbetrieb verständlich, beim Aspekt Rollenklarheit im Ausnahmefall entscheidbar und nach einer Änderung erneut prüfbar sein. Fehlt eine dieser Eigenschaften, besteht bei Verbesserungsschritt weiterer Handlungsbedarf.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 28
Ich würde gern einen Punkt vertiefen: wie Verantwortlichkeiten und Entscheidungen im Alltag nachvollziehbar bleiben. Wie lässt sich das mit überschaubarem Aufwand überprüfen?
Aus meiner Sicht sollte man mit einem kritischen, aber überschaubaren Fall beginnen. Daran werden fehlende Zuständigkeiten meist schneller sichtbar als in einer allgemeinen Bewertung.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Den Punkt würde ich gern vertiefen. Welche Schritte eignen sich für einen Einstieg, ohne gleich das ganze Modell umzusetzen?
Ich würde mit einem konkreten Steuerungsproblem beginnen und dafür Ziele, Verantwortliche und einen überprüfbaren Ablauf festhalten.
Wer sollte bei der praktischen Umsetzung entscheiden, ob nach dem ersten Versuch nachgebessert werden muss? Damit könnte die Lösung im Alltag wachsen, ohne beliebig zu werden. Das sollte möglichst im normalen Arbeitsablauf sichtbar werden.
Für mich liegt der entscheidende Punkt bei klare Entscheidungsrechte. Daran zeigt sich früh, ob der Ansatz im Alltag trägt.
Ein weiterer Punkt: Sind Governance und operatives Management im Alltag wirklich sauber trennbar?
Wie verhindert man, dass aus dem Governance-Rahmen eine reine Prüfliste wird?
Ich sehe darin vor allem eine Gestaltungsfrage. Ich würde jedes ausgewählte Ziel mit einer Verantwortlichkeit und einer tatsächlichen Entscheidung verbinden. Sonst bleibt die Umsetzung auf der Dokumentationsebene.
Dazu eine Rückfrage: Wie wählt man aus einem umfangreichen Framework einen angemessenen Einstieg aus? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Ausgangspunkt wären für mich Unternehmensziele und die wichtigsten Risiken. Alles gleichzeitig umzusetzen würde eher die Priorisierung verdecken. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich würde die Ausnahme nicht verstecken, sondern mit Begründung, zuständiger Person und Prüfanlass festhalten. Dann kann man auch später erkennen, ob die Grundlage noch gilt. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Die Ausgangsfrage „Wie wählt man aus einem umfangreichen Framework einen angemessenen Einstieg aus?“ ist damit für mich noch nicht vollständig beantwortet.
Wann wäre bei Verknüpfung von Unternehmenszielen und IT-Zielen eine erneute Entscheidung sinnvoller als die bloße Fortschreibung eines Status?
Eine neue Entscheidung wäre für mich erforderlich, wenn Grenzen oder tragende Annahmen nicht mehr passen. Eine Statusmeldung allein erklärt noch nicht, wie die Veränderung bewertet wurde. Für Verknüpfung von Unternehmenszielen und IT-Zielen würde ich den ersten Prüfschritt bewusst klein halten.
Der Ansatz wird aus meiner Sicht durch klare Entscheidungsrechte in der IT-Governance belastbar. Entscheidend ist auch die dokumentierte Konsequenz aus Abweichungen.
Wichtig erscheint mir dabei klare Entscheidungsrechte. Gerade die Übergaben zwischen mehreren Beteiligten verdienen Aufmerksamkeit.
Ein sinnvoller nächster Schritt wäre eine begrenzte Erprobung von klare Entscheidungsrechte. So werden offene Annahmen schnell sichtbar.
Für klare Entscheidungsrechte in der IT-Governance braucht es aus meiner Sicht keine Vielzahl neuer Kennzahlen. Zwei oder drei klar interpretierbare Signale wären oft hilfreicher.
Der praktische Wert von klare Entscheidungsrechte in der IT-Governance hängt für mich an einer einfachen Frage: Führt die Information rechtzeitig zu einer besseren Entscheidung?
Der praktische Wert von klare Entscheidungsrechte hängt für mich an einer Frage: Führt die Information rechtzeitig zu einer besseren Entscheidung?
Bei klare Entscheidungsrechte scheint mir die zeitliche Perspektive wichtig. Eine einmalige Prüfung sagt wenig über dauerhafte Wirksamkeit aus.
Welche Entscheidung müsste zu Zuständigkeit für Steuerungsentscheidungen zuerst fallen, wenn die verfügbaren Nachweise lückenhaft sind?
Ich würde zunächst die Lücke offen dokumentieren und einen überprüfbaren nächsten Schritt vereinbaren, statt Vollständigkeit zu unterstellen. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Zuständigkeit für Steuerungsentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.