BAIT neu gedacht: Warum IT-Governance jetzt härter bewertet wird

BAIT neu gedacht: Warum IT-Governance jetzt härter bewertet wird

Es gab eine Zeit, in der IT-Governance vor allem aus gut sortierten Ordnern bestand: Strategiepapiere, Richtlinien, Prozesslandkarten – sauber nummeriert, formal genehmigt, in Jahresabständen aktualisiert. Prüfungen folgten demselben Takt. Man bereitete eine Woche lang Dokumente auf, führte Interviews, hakte Checklisten ab und ging zur Tagesordnung über. Diese Zeit ist vorbei. Heute wird IT-Governance an ihrer Betriebswirkung gemessen: an Zahlen, Reaktionszeiten, Nachweisen aus echten Systemen, an der Kohärenz zwischen Risiko, Kontrolle, Vorfallbearbeitung und Lieferkette. BAIT ist nicht länger das „Policy-Regelwerk für die IT“, sondern ein Wirksamkeitsrahmen für die gesamte Organisation – von der Geschäftsleitung bis zum letzten Dienstleister. Die Latte liegt höher, weil die Erwartung klarer ist: führen, steuern, belegen. Und zwar jederzeit.

Von der Papierlage zur Betriebswirkung: der Paradigmenwechsel

Früher reichte der Nachweis, dass es eine Strategie, ein Risikokonzept, ein Notfallhandbuch gibt. Heute zählt, wie diese Bausteine in den Alltag greifen. Eine IT-Strategie ohne messbare Zielgrößen, ein Risiko-Prozess ohne eskalierende Schwellenwerte, ein Notfallhandbuch ohne geprobte Wiederherstellung – all das gilt nicht mehr als „ausreichend“. BAIT wird zu einem Messsystem: Es fragt nach Zusammenhängen, nach Taktung, nach der Fähigkeit, aus Kennzahlen Entscheidungen abzuleiten und diese Entscheidungen wiederum zu belegen. Governance ist damit kein Sammlungspunkt von Dokumenten mehr, sondern ein Betriebsmodell mit Evidenzen.

Drei Gründe, warum die Bewertung härter wird

Erstens: IT ist Produktionskern. Wertschöpfung hängt an Anwendungen, Datenströmen und Plattformen. Wer IT nicht steuert, steuert das Geschäft nicht.
Zweitens: Vernetzung & Auslagerung. Cloud, SaaS, Managed Services – Verantwortung bleibt im Haus, Nachweise wandern in die Lieferkette. Steuerungsfähigkeit wird am Ende-zu-Ende belegt, nicht am Vertragstext.
Drittens: Dynamik der Bedrohungen. Schwachstellenzyklen, Angriffsketten, Lieferkettenrisiken – die Aufsicht erwartet Spuren der laufenden Auseinandersetzung, nicht eine Jahresbilanz der guten Vorsätze.

Governance heißt Mandat, Takt und Kohärenz

Harte Bewertung beginnt ganz oben. „Die Geschäftsleitung trägt Verantwortung“ ist eine Binsenweisheit. Bewertet wird, wie sie diese Verantwortung sichtbar macht:

• Mandate: Sicherheitsorganisation mit Unabhängigkeit und Eskalationsrecht; Auslagerungssteuerung mit Gatekeeper-Rolle; klare Owner für kritische Services.
• Takt: Management-Reviews mit Kennzahlen, Beschlüsse mit Termin und Verantwortlichem, Nachhalten wie bei jedem anderen Business-Thema.
• Kohärenz: Dieselben Quellen in Gremien und Prüfungen – systemische Exporte statt hübsch formatierter Tabellen, die niemand wiederherstellen kann.

Governance „neu gedacht“ heißt: Entscheidungen sind datenbasiert, zeitgebunden und rekonstruierbar. Ohne diese Dreifaltigkeit bleibt jede Governance weich.

Risikosteuerung: von der Inventur zur Regelspur

BAIT verlangt kein „Risikobuch“, das einmal im Jahr abgestaubt wird, sondern eine Regelspur: vollständige Inventarisierung kritischer Prozesse und Assets, Schutzbedarfe (Vertraulichkeit, Integrität, Verfügbarkeit), Kritikalitäten, Risikobewertungen, Maßnahmen mit Fristen – und vor allem Schwellenwerte, die Alarm und Eskalation auslösen. Wer Risiken steuert, kann belegen, dass ein Schwellenwert gerissen wurde, dass alarmiert und entschieden wurde, wann, von wem und mit welchem Ergebnis. Diese Kette ist die neue Messgröße: Erkennen – Entscheiden – Handeln – Belegen.

Informationssicherheit als System: Use Cases statt Beruhigung

„Wir loggen“ ist keine Aussage, „wir erkennen“ schon. Governance wird härter bewertet, weil Sicherheitsüberwachung an Use Cases gemessen wird: unautorisierte Zugriffe, anomale Bewegungen privilegierter Konten, Datenabflussmuster, auffällige API-Nutzung, Region-Sprünge in der Cloud. Für jeden kritischen Use Case braucht es Regeln, Alarmwege, Reaktionszeiten (MTTD/MTTR) und Lessons Learned, die in Maßnahmen zurückfließen (Härtung, Erkennungsregeln, Rollenmodelle). Die Frage lautet nicht: „Wieviel Logvolumen haben Sie?“, sondern: „Welche Szenarien decken Sie wann mit welchem Erfolg ab?“

Notfallmanagement: Wiederherstellbarkeit ist messbar – oder nicht vorhanden

Es gibt nur zwei Arten von Notfallvorsorge: geübt oder eingebildet. Governance wird härter, weil Wiederanlauffähigkeit bewiesen werden muss. Restore-Tests auf Anwendungsebene (nicht nur Datei- oder Volumen-Restores) mit Integritätsnachweis (Checksummen, Transaktionskohärenz), RTO/RPO je Serviceklasse, dokumentierte Ergebnisse, Abweichungsanalyse, Re-Tests – das ist die neue Normalität. Ein Ordner voller Pläne ersetzt keinen einzigen Protokolleintrag eines erfolgreichen Restores.

Identitäten & Berechtigungen: End-to-End oder gar nicht

Kaum etwas zerstört Vertrauen so zuverlässig wie verwaiste Rechte und großzügige Privilegien. Die härtere Bewertung zeigt sich in fünf Punkten:

1. Rollenmodelle mit dokumentierter Funktionstrennung (und begründeten, befristeten Ausnahmen).
2. Lifecycle-Prozess: Eintritt, Wechsel, Austritt – systemisch gekoppelt, ohne Schattenlisten.
3. Privilegienkontrolle: Admin-Jump-Hosts, Sitzungsaufzeichnung, Just-in-Time-Rechte.
4. Rezertifizierung: Takt, Stichproben, Entzug nach Organisationswechseln – belegt.
5. Nachweise: Populationen, Stichproben, Freigabejournale – versioniert, unveränderlich, prüfbar.

Wer hier manuell „führt“, wird scheitern. Governance heißt: Automatisieren, begrenzen, belegen.

Entwicklung & Change: Policy as Code ist die neue Freigabe

Freigaben in Word und vier Augen am Telefon sind keine Steuerung, sondern Hoffnung. Härter bewertet wird, ob Qualität im Codepfad gesichert ist: Trennung Dev/Test/Prod, reproduzierbare Builds, Peer-Reviews, Testabdeckung, Abnahmekriterien inklusive Sicherheitsanforderungen, rücknehmbare Deployments, sauber geführte Konfigurationsbaselines. Parametrisierung wird wie Code behandelt. In der Plattformwelt gilt: Guardrails in der Landing Zone, Compliance-Checks in der Pipeline, Drift-Kontrollen im Betrieb. Governance ist hier sichtbar, wenn die Pipeline „Nein“ sagt – und das „Nein“ erklärt, protokolliert und auswertbar ist.

Lieferkette & Auslagerung: Steuerung statt Vertragspoesie

„Wir haben Auditrechte“ klingt gut, beweist aber nichts. Bewertet wird, ob ein Institut seine Lieferkette führt: Due Diligence vor Vertragsschluss, Informations- und Prüfungsrechte mit praktikabler Umsetzung (Attestierungen, kontrollierte On-Site-Formate, geteilte Audits), Meldepflichten bei Vorfällen, Transparenz über Sub-Dienstleister, Datenlokationen, Exit- und Portabilitätsregeln. Danach zählt das Monitoring: Scorecards mit SLA- und Sicherheitskennzahlen, technische Telemetrie wo möglich, Eskalationen, Änderungs-Trigger (Region, Sub-Provider, Architektur, Major Incidents) und – besonders wichtig – geübte Exit-Fähigkeit in angemessenem Zuschnitt. Governance zeigt sich daran, wie schnell und wie sauber ein Institut auf Lieferkettenstörungen reagiert – belegt durch Spuren, nicht durch Absicht.

Kennzahlen, die Führung beweisen

Harte Bewertung verlangt harte Zahlen. Fünf Kennzahlengruppen entscheiden, ob IT-Governance wirkt:

• Erkennung & Behebung: MTTD/MTTR, Klassifizierungs- und Meldezeiten.
• Schwachstellen & Patches: Age-Kurven, Remediation-Quoten, Ausnahmefristen.
• Wiederherstellung: Restore-Erfolgsquote, RTO/RPO-Einhaltung, Integritätsbelege.
• Identitäten: Rezertifizierungsquote, De-Provisioning-Dauer, Nutzung privilegierter Sitzungen.
• Lieferkette: SLA-Compliance, Vorfallmeldezeiten, Audit-/Assessment-Ergebnisse, Exit-Proben.

Diese Zahlen gehören ins Management, nicht in die Fußnote eines Audit-Reports. Ohne Management-Blick sind Kennzahlen Dekoration.

Kohärenz als Königsdisziplin

Die härteste Bewertung trifft Inkohärenz. Das Risikoregister behauptet A, die Testberichte zeigen B, das Incident-Log erzählt C, die Scorecards der Dienstleister D, und im Management-Report stehen E. Wer Governance ernst nimmt, etabliert Kohärenz-Reviews: regelmäßige Termine, in denen Verantwortliche Datenquellen übergreifend auf Widersprüche prüfen, Tickets eröffnen, Maßnahmen terminieren, Re-Checks durchführen. Diese Routine ist unspektakulär – und genau deshalb wirksam. Sie macht eine Geschichte aus vielen Quellen.

„Always Audit Ready“: Architektur statt Anspannung

„Immer prüffähig“ ist kein Motivationsspruch, sondern eine Architekturentscheidung:

• Single Sources of Truth: Servicekatalog/CMDB, Risikoregister, Auslagerungsregister, Ticketing/Monitoring, IAM/PAM – verbunden, versioniert, unveränderlich abgelegt.
• Standardisierte Exporte: Systemgenerierte Evidenzen mit Populationsdefinitionen und Zeitstempeln; kein Sammeln kurz vor der Prüfung.
• Zyklen & Rollen: Evidence-Tage, Rezertifizierungsfenster, Testkalender, Scorecards, Kohärenz-Reviews – mit RACI und Eskalationswegen.
• CAPA-Disziplin: Findings führen zu Corrective and Preventive Actions, Re-Tests sind terminiert, Wirkung wird gemessen.

So entsteht Ruhe – nicht, weil weniger geprüft wird, sondern weil weniger improvisiert werden muss.

Anti-Patterns, die zuverlässig scheitern

• Policies ohne Guardrails: Papiere sagen „muss“, Pipelines sagen „wird trotzdem gebaut“.
• IAM im Tabellenkalkulations-Modus: Rechte werden „verwaltet“, nicht gelebt; De-Provisioning hängt an Mails.
• Notfall ohne Restore-Beweis: Backups sind vorhanden, Integrität bleibt Behauptung.
• Outsourcing ohne Telemetrie: PDFs ersetzen Beobachtbarkeit; erste Störung bringt Überraschungen.
• Kennzahlen ohne Führung: Zahlen werden gesammelt, aber niemand entscheidet damit.
• Projekt statt Betrieb: BAIT wird „umgesetzt“ und dann abgelegt; Routine fehlt, Evidenz versiegt.

Cloud & Governance: Geschwindigkeit mit Geländer

Cloud verschärft die Governance-Anforderungen nicht, sie macht sie sichtbar. Wer die Plattform ernst nimmt, baut Guardrails, Policy-as-Code, Use-Case-Überwachung, Krypto- und Schlüssel-Governance sowie Exit-Pfade. Geschwindigkeit entsteht nicht trotz, sondern wegen klarer Leitplanken. Harte Bewertung belohnt Häuser, die Automatisierung und Nachweis zusammen denken: „Wir deployen schnell“ und „wir können auf Knopfdruck belegen, was, wann, wo, wie konfiguriert wurde“.

Daten-Governance: Lineage statt Legende

Keine Governance ohne Datenklarheit. Es genügt nicht, „Qualität“ zu fordern. Bewertet wird, ob Golden Sources definiert, Transformationsregeln dokumentiert, Freigaben nachvollziehbar und Lineage bis ins Reporting nachgezogen ist. Datenqualitätsregeln werden als Kontrollen betrieben – mit Tickets, KPIs, Ursachenanalysen. Der rote Faden: Daten fließen nicht „irgendwie“, sondern sichtbar, wiederholbar, belegt.

Drei Organisationsmuster – drei Zuschnitte

SaaS-zentriertes Institut
Schwerpunkt: Auslagerungssteuerung, Datenklassifikation, IAM-Disziplin, Incident-Meldeketten, Portabilität der Daten. Parametrisierung wird wie Code behandelt; Exit wird geübt.

Plattformorientiertes Haus
Schwerpunkt: Landing-Zone-Guardrails, Pipelines mit Policy-as-Code, Secrets-/Schlüsselmanagement, Use-Case-SIEM/XDR, Restore auf Anwendungsebene. Driftkontrolle und Standardisierung schlagen manuelles Heldentum.

Hybrid mit Legacy-Kern
Schwerpunkt: Segmentierung, Konfigurations- und Patch-Disziplin, End-to-End-Monitoring, abgestimmte Failover-Runbooks, Lieferkettentelemetrie. Kennzahlen verbinden Alt und Neu – Entscheiden bleibt einheitlich.

Roadmap: In sechs Monaten zur härtefesten Governance

Monate 1–2
Bestandsaufnahme kritischer Services/Assets, Schutzbedarfe/Kritikalitäten, Rollen & Mandate schärfen, Kennzahlen definieren, Gremien- und Review-Takte festlegen.

Monate 3–4
Evidence-Baukasten aufbauen (systemische Exporte, versionierte Ablage), IAM-Quickwins (De-Provisioning, Rezertifizierungen, PAM mit Sitzungsaufzeichnung), Testkalender mit Akzeptanzkriterien (RTO/RPO, Integrität), Lieferanten-Nachträge (Info-/Prüf-/Exit-Rechte, Sub-Provider-Transparenz).

Monat 5
Restore- und Tabletop-Übungen durchführen, Scorecards produktiv, erstes Kohärenz-Review, Management-Reporting auf Kennzahlen umstellen.

Monat 6
Probe-Audit „Operating Effectiveness“ mit echten Stichproben; CAPA-Plan, Re-Tests terminiert; Evidence-Tage und quartalsweise Kohärenz-Reviews institutionalisieren.

Danach ist Governance kein Projekt, sondern Routine – und Routine erzeugt die Evidenz, die härtere Bewertungen bestehen lässt.

Was Institute zurückbekommen

Die härtere Bewertung ist kein Selbstzweck. Sie erzwingt die Disziplin, die ein reifer Betrieb ohnehin braucht: weniger Ausfälle, schnellere Wiederherstellung, belastbarere Lieferketten, entschiedene Priorisierung, glaubwürdige Kommunikation. Vor allem aber schafft sie eine gemeinsame Sprache im Haus: Ziele, Risiken, Kontrollen, Evidenzen. Diese Sprache ersetzt Anekdoten durch Messwerte – und macht Führung wieder zu dem, was sie sein soll: Entscheiden unter Unsicherheit – begründet, nachvollziehbar, wiederholbar.

Fazit: Härte ist ein Geschenk – wenn man sie annimmt

„Härter bewertet“ klingt bedrohlich. In Wahrheit ist es die Einladung, IT-Governance aus der Papierwelt zu befreien. BAIT „neu gedacht“ heißt: Mandate mit Zähnen, Metriken mit Wirkung, Prozesse mit Evidenz. Wer diesen Schritt geht, muss die nächste Prüfung nicht fürchten. Er zeigt einfach, was er jeden Tag tut – und kann es beweisen. Genau darin liegt der Unterschied zwischen Governance als Last und Governance als Stärke. Die Latte liegt höher. Gut so. Denn über ihr beginnt die Stabilität, die Institute heute brauchen.