IT-Strategie und IT-Governance – passen diese zusammen?

Warum die eine ohne die andere wirkungslos bleibt – und wie der Regelkreis wirklich funktioniert

Zwei Disziplinen, eine Wirkung

Wer in einem Vorstandsmeeting von „IT-Strategie" spricht, erntet in der Regel wohlwollendes Nicken. Wer im gleichen Raum „IT-Governance" sagt, erlebt häufig das Gegenteil: Verwaltung. Bremse. Compliance-Overhead. Dabei beschreiben beide Begriffe nur zwei Seiten derselben Medaille.

Meine These, zugespitzt: IT-Strategie gibt die Richtung vor – IT-Governance sorgt dafür, dass die Organisation diese Richtung tatsächlich einschlägt und hält. Ohne Strategie wird Governance zur Bürokratie. Ohne Governance wird Strategie zum PowerPoint-Folienkino. Beides ist in regulierten Branchen nicht mehr tolerierbar – spätestens seit DORA, NIS-2 und dem EU AI Act ist der Vorstand persönlich in der Pflicht, beides zusammenzudenken.

In diesem Artikel ordne ich das Verhältnis beider Disziplinen ein, beschreibe den Regelkreis zwischen Strategie, Steuerung und Feedback und zeige, welche regulatorischen Treiber diese Verknüpfung heute erzwingen.

1. Grundverständnis: Was ist was?

IT-Strategie

IT-Strategie beantwortet die Frage: Wohin? Sie leitet sich aus der Geschäftsstrategie ab und übersetzt deren Ziele in eine IT-Landschaft, eine Sourcing-Logik, ein Technologie-Portfolio und ein Investitionsprofil. Sie legt fest, was die IT in den nächsten drei bis fünf Jahren können muss, um das Geschäftsmodell zu tragen – und was sie bewusst nicht mehr tun wird.

Eine belastbare IT-Strategie enthält typischerweise:

• eine Zielarchitektur (Applikations-, Daten- und Infrastrukturebene),
• eine Sourcing- und Cloud-Strategie,
• ein Security- und Resilienz-Zielbild,
• eine Roadmap mit Meilensteinen und Budgetrahmen,
• und – oft unterschätzt – ein klares Nicht-Portfolio.

IT-Governance

IT-Governance beantwortet die Frage: Wie stellen wir sicher, dass wir dort auch ankommen? Sie ist das Führungs- und Kontrollsystem, das Entscheidungsrechte, Verantwortlichkeiten, Prozesse und Kennzahlen definiert, mit denen die IT gesteuert wird. Governance adressiert drei Kernfragen:

1. Wer entscheidet was? (Entscheidungsrechte, Gremien, Rollen wie CIO, CISO, Data Owner)
2. Wie wird entschieden? (Prozesse, Policies, Eskalationspfade)
3. Woher wissen wir, dass wir auf Kurs sind? (KPIs, Audits, Reviews, Risikokennzahlen)

Abgrenzung zum operativen IT-Management

Hier lohnt eine saubere Unterscheidung, die in der Praxis ständig verschwimmt:

Governance ist nicht operatives Management. Sie greift nicht ins Tagesgeschäft ein, sondern setzt den Rahmen, innerhalb dessen das Management handelt. Wo Governance selbst operativ wird, ist sie meist falsch aufgesetzt.

2. Das Spannungsfeld: Warum so vieles schiefgeht

Dysfunktion 1: Strategie ohne Governance – das Folienkino

Die klassische Variante: Eine externe Beratung liefert eine brillante IT-Strategie, der Vorstand nickt sie ab, die IT-Leitung hängt sie ins Intranet. Zwei Jahre später fragt der Aufsichtsrat nach dem Umsetzungsstand – und niemand kann es belastbar beantworten. Kein Steuerungsgremium, keine Scorecard, keine Verbindung zwischen strategischen Zielen und dem Projektportfolio. Die Strategie war nie falsch. Sie war nur nie steuerbar.

Dysfunktion 2: Governance ohne Strategie – die Bürokratiefalle

Die noch häufigere Variante: Nach einem Prüfungsbefund oder der Einführung eines neuen Regulativs (BAIT, DORA, NIS-2) werden Policies, Gremien und Berichtspflichten aufgebaut – ohne dass jemand fragt, wohin die IT eigentlich will. Das Ergebnis sind Kontrollen, die niemand mehr versteht, Gremien, die Informationen verwalten statt Entscheidungen treffen, und Mitarbeiter, die Governance als Feind wahrnehmen.

Das ist die teuerste Form von Governance: Sie kostet viel Geld, produziert Widerstand und liefert keinen Steuerungsnutzen, weil ihr der strategische Bezugspunkt fehlt. Governance, die nicht auf eine Strategie einzahlt, ist Bürokratie mit ISO-Siegel.

Dysfunktion 3: Scheingovernance – die Gremien-Inflation

Die subtilste Variante: Alles ist formal vorhanden – IT-Lenkungsausschuss, Architektur-Board, Security-Komitee, Risk-Council. Aber die Gremien tagen monatlich, produzieren Protokolle und entscheiden nichts. Entscheidungen fallen außerhalb, in Zweier-Runden oder per Mail. Die Gremien sind Theater. Die Strategie taucht nur auf der Agenda auf, wenn der Jahresplan vorgestellt wird.

Das Gegenmittel ist nicht mehr Governance, sondern bessere Governance: weniger Gremien, klare Entscheidungsrechte, ein echter Bezug zu strategischen Kennzahlen.

3. Der Regelkreis: Wie Strategie und Governance zusammenwirken

Wenn beides richtig ineinandergreift, entsteht ein Regelkreis, der in vier Phasen läuft:

1. Direct (Richtung vorgeben). Der Vorstand verabschiedet die IT-Strategie und die daraus abgeleiteten Governance-Prinzipien: Risikoappetit, Entscheidungsrechte, zentrale Policies. Das ist kein Einmal-Ereignis, sondern ein jährlicher Akt.

2. Execute (Umsetzen). Die IT-Organisation setzt die Strategie über Programme, Projekte und Betrieb um. Governance stellt hier die Leitplanken: Architektur-Prinzipien, Sourcing-Regeln, Security-Standards, KI-Freigabeprozesse.

3. Monitor (Überwachen). Steuerungskennzahlen laufen in ein IT-Cockpit zurück – nicht als Tapete für den Lenkungsausschuss, sondern als echte Entscheidungsgrundlage. Typische Kennzahlen: Strategie-Umsetzungsgrad, IT-Risikoindex, Cloud-Migrationsquote, Recovery-Zeiten kritischer Services, Anteil nicht-konformer Applikationen.

4. Evaluate (Bewerten und Anpassen). Einmal pro Jahr – mindestens – wird gefragt: Stimmt die Richtung noch? Was hat sich im Markt, in der Regulatorik, in der Technologie verändert? Welche strategischen Annahmen sind überholt? Dieser Schritt schließt den Kreis und wird in den meisten Organisationen entweder vergessen oder zum Pflichttermin degradiert.

Der entscheidende Punkt: Dieser Regelkreis ist keine theoretische Schönheit, sondern regulatorisch zunehmend vorgeschrieben. Wer ihn nicht nachweisen kann, hat bei der nächsten Prüfung ein Problem.

Vom strategischen KPI zur operativen Kennzahl

Einer der praktisch anspruchsvollsten Schritte ist die Übersetzung strategischer Ziele in Governance-taugliche Kennzahlen. Ein Beispiel:

Die mittlere Spalte ist die Governance-Ebene – genau dort entscheidet sich, ob Strategie steuerbar wird oder in Allgemeinplätzen stecken bleibt.

4. Regulatorischer Kontext: Warum das Thema auf der Vorstandsagenda steht

Bis vor wenigen Jahren war die Verknüpfung von IT-Strategie und IT-Governance primär eine Frage guter Unternehmensführung. Heute ist sie rechtlich verpflichtend – und der Kreis der betroffenen Organisationen wächst mit jeder Novelle.

DORA: Governance als Grundpfeiler der digitalen Resilienz

Die Digital Operational Resilience Act (DORA), seit Januar 2025 anwendbar, macht die Verknüpfung explizit. Artikel 5 DORA verpflichtet das Leitungsorgan, einen Rahmen für das IKT-Risikomanagement zu definieren, regelmäßig zu überprüfen und zu verantworten – inklusive digitaler operationeller Resilienzstrategie, klarer Rollen und Reporting-Pflichten. DORA unterscheidet sich von früheren Regimen wie der BAIT dadurch, dass sie Verantwortung nicht delegieren lässt: Das Leitungsorgan muss nachweislich steuern, nicht nur unterschreiben.

Für die Praxis bedeutet das: Eine IT-Strategie ohne darauf abgestimmte Governance-Architektur (Risikoappetit, TPRM, Incident-Reporting, Resilience-Testing) ist DORA-seitig unzureichend. Und umgekehrt: Governance-Dokumente ohne strategischen Bezug zur Resilienz-Zielarchitektur bestehen keine Aufsichtsprüfung.

BAIT nach DORA-Anpassung

Die Bankaufsichtlichen Anforderungen an die IT (BAIT) wurden mit dem 7. MaRisk-Novellenkreis und den DORA-Anpassungen inhaltlich deutlich überarbeitet. Die grundsätzliche Forderung bleibt: Institute müssen eine dokumentierte IT-Strategie vorhalten, die aus der Geschäftsstrategie abgeleitet ist, und ein Steuerungs- und Überwachungssystem betreiben, das deren Umsetzung sicherstellt.

Wer die Entwicklung beobachtet, erkennt einen klaren Trend: Aufsichtsbehörden akzeptieren zunehmend keine Strategie- und Governance-Dokumente mehr, die nebeneinander leben. Sie prüfen die Verbindung: Lässt sich nachvollziehen, wie ein strategisches Ziel über Governance-Mechanismen in operative Steuerung überführt wird?

NIS-2: IT-Governance als Vorstandspflicht

Die NIS-2-Richtlinie verschiebt die Verantwortung explizit auf die Leitungsebene. Artikel 20 fordert, dass Leitungsorgane die Risikomanagementmaßnahmen im Bereich Cybersicherheit billigen, ihre Umsetzung überwachen und für Verstöße persönlich verantwortlich gemacht werden können. Zusätzlich müssen Mitglieder von Leitungsorganen regelmäßig an Schulungen teilnehmen.

Das ist ein Paradigmenwechsel: NIS-2 macht IT-Governance zur Chefsache im Wortsinn – nicht delegierbar, nicht auslagerbar, persönlich haftungsrelevant. Wer als IT-Leiter die NIS-2-Umsetzung plant, muss mit dem Vorstand reden, nicht mit dem IT-Betrieb.

EU AI Act: Governance für eine neue Technologiekategorie

Mit dem EU AI Act tritt eine weitere Schicht hinzu. Für Hochrisiko-KI-Systeme und – branchenabhängig – auch darunter verlangt die Verordnung Governance-Strukturen: Risikomanagement, Datenmanagement, Dokumentation, menschliche Aufsicht, Transparenzpflichten. In meiner Rolle als KI-Verantwortlicher im Bankenumfeld habe ich gelernt: KI-Governance funktioniert nur als Erweiterung der bestehenden IT-Governance, nie als Parallelstruktur. Die Strategie gibt vor, wo KI eingesetzt wird – die Governance entscheidet, wie verantwortungsvoll das geschieht.

5. Was gute Praxis ausmacht – sieben Prinzipien

Aus Gesprächen mit CIOs und CISOs in regulierten Branchen sowie aus eigener Erfahrung haben sich für mich sieben Prinzipien herauskristallisiert, die den Unterschied zwischen funktionierender und dysfunktionaler Governance ausmachen:

1. Strategie zuerst, Governance danach. Wer Governance ohne klare Strategie aufbaut, baut Bürokratie. Jede Policy, jedes Gremium, jede Kennzahl muss auf ein strategisches Ziel zurückführbar sein. Findet sich keine Verbindung – streichen.

2. Entscheidungsrechte vor Prozessen. Die wichtigste Governance-Frage ist nicht „Welchen Prozess?", sondern „Wer entscheidet?". Eine RACI- oder DACI-Matrix auf Ebene der zentralen IT-Entscheidungen schlägt jedes dicke Policy-Handbuch.

3. Wenige, starke Gremien statt vieler schwacher. Drei Gremien mit echten Entscheidungsrechten sind wirksamer als acht Gremien, die berichten. IT-Lenkung, Architektur-Board und Risiko-Ausschuss reichen in den meisten Organisationen. Alles darüber hinaus begründungspflichtig.

4. Kennzahlen, die man dem Vorstand zeigen kann. Wenn die Governance-Scorecard nicht auf eine Seite passt und in 15 Minuten erklärbar ist, steuert sie nichts. Sie berichtet.

5. Governance als Enabler positionieren. Der größte Kulturfehler ist, Governance als Prüfungsinstanz zu inszenieren. Wer Governance als Schutzraum für gute Entscheidungen etabliert – mit Architektur-Standards, die Entwicklung beschleunigen, mit Sourcing-Guardrails, die Einkaufsentscheidungen vereinfachen, mit klaren Freigabewegen für KI – gewinnt die Organisation.

6. Jährlicher Strategie-Governance-Check. Einmal pro Jahr die Frage stellen: Passen unsere Governance-Strukturen noch zur Strategie? Haben sich die strategischen Prioritäten verschoben, ohne dass die Governance nachgezogen hat? Dieser Check ist der wichtigste Einzeltermin im Governance-Kalender.

7. Dokumentation, die gelesen wird. Policies, die niemand liest, schützen nicht – sie schaffen Scheinsicherheit. Besser: kurze, klare Dokumente mit konkreten Beispielen, die in die täglichen Arbeitswerkzeuge integriert sind (Wiki, Jira, Tickets), statt 80-seitiger PDF-Grabsteine im SharePoint.

6. Eine unbequeme Diagnose zum Schluss

Viele Organisationen haben heute sowohl eine IT-Strategie als auch eine IT-Governance – auf dem Papier. Was ihnen fehlt, ist die Verbindung. Strategie und Governance leben in unterschiedlichen Dokumenten, unterschiedlichen Gremien, unterschiedlichen Abteilungen. Die Strategie entsteht einmal im Jahr mit Beratung und Vorstand, die Governance läuft das Jahr über mit Compliance und Audit. Sie treffen sich nirgendwo außer in der Ergebnispräsentation.

Genau diese Trennung ist es, die in Prüfungen auffällt, Reorganisationen scheitern lässt und aus Governance eine Kostenstelle ohne Wirkung macht. Wer das ändern will, braucht keine neue Norm und kein neues Tool. Er braucht drei Dinge:

• einen expliziten Regelkreis zwischen Strategie, Steuerung und Feedback,
• Kennzahlen, die beide Ebenen verbinden,
• und einen Vorstand, der versteht, dass IT-Governance kein Delegationsthema ist – spätestens seit NIS-2 und DORA auch rechtlich nicht mehr.

IT-Strategie und IT-Governance passen nicht nur zusammen. Sie funktionieren nur zusammen.

Reifegrad-Selbstcheck

Wenn Sie sich gerade gefragt haben, wo Ihre eigene Organisation auf dem Kontinuum zwischen Strategie-Folienkino und Governance-Bürokratie steht: Auf it-governance.dev stehen kostenlose, browserbasierte Tools bereit, mit denen Sie Ihren Reifegrad strukturiert einschätzen können – von der ISO-27001-Gap-Analyse über die DORA- und NIS-2-Betroffenheitsprüfung bis zur IT-Rollenmatrix. Keine Anmeldung, keine Datenübertragung, alles läuft lokal im Browser.

Ein guter Einstiegspunkt ist die IT-Rollenmatrix: Sie macht innerhalb von 20 Minuten sichtbar, wo Entscheidungsrechte unklar sind – und das ist meist der erste Riss, durch den Strategie und Governance auseinanderdriften.