Montagmorgen, 8:12 Uhr. Der externe Auditor sitzt bereits im Besprechungsraum, die ERP-Verantwortliche sucht in drei Ordnern nach Nachweisen, und der Fachbereich sagt, der KI-Agent habe die Mahnungen „einfach so“ verschickt. In österreichischen Mittelstandsunternehmen ist genau das der Normalfall, ein System wächst, Zugriffe werden verteilt, Automationen kommen dazu, und am Ende weiß niemand mehr sauber, wer was freigegeben hat oder wer die Kontrolle beweisen kann. Ein Security Governance Framework löst nicht jedes Sicherheitsproblem, aber es beendet dieses Chaos an der Wurzel.
Inhaltsverzeichnis
- Wenn der Auditor klopft und niemand zuständig ist
- Was ein Security Governance Framework wirklich ist
- Komponenten die in ERP, CRM und KI Architekturen wirklich zählen
- Implementierungsfahrplan für Mittelstand und Enterprise
- Metriken, Reporting und typische Audit-Fallen
- Praxisbeispiele aus ERP, CRM und Agenten-Architekturen
- Governance Checkliste für die ersten 30 Tage
Wenn der Auditor klopft und niemand zuständig ist
Ein Audit scheitert selten an einer fehlenden Firewall. Es scheitert daran, dass ein ERP-Zugriff historisch gewachsen ist, ein CRM-Plugin noch vom letzten Projekt hängt und ein KI-Agent inzwischen in Slack und Mail mitarbeitet, ohne dass jemand die Freigabekette sauber kennt. Genau dann fliegt auf, dass die Organisation zwar Tools gekauft hat, aber keine belastbare Verantwortungskette.
Der typische Bruch in österreichischen Unternehmen
Ich sehe denselben Fehler immer wieder. Die IT verwaltet Accounts, der Fachbereich definiert Prozesse, der Dienstleister baut Integrationen, und am Ende liegt die Beweispflicht irgendwo zwischen Ticket-System, E-Mail und einem halb gepflegten Wiki. Das ist kein Governance-System, das ist ein Sammelsurium.
Die harte Wahrheit ist einfach. Seit der DSGVO vom 25. Mai 2018 den Rahmen für Governance, Rollen, Nachweispflichten und Sanktionen bei personenbezogenen Daten gesetzt hat, ist fehlende Steuerung kein Schönheitsfehler mehr, sondern ein Rechts- und Finanzrisiko. Laut einer 2025 zusammengefassten Auswertung führen 32 % aller Datenpannen zu behördlichen Strafen, und 48 % dieser Strafen liegen über 100.000 US-Dollar. Das ist kein theoretischer Randfall, das ist genau der Grund, warum Governance in Österreich Chefsache sein muss. Siehe die zusammengefasste Auswertung zu Compliance- und Governance-Statistiken 2025 bei ConversationalGeek.
Praktische Regel: Wenn Sie für einen Zugriff, eine Automatisierung oder eine Datenfreigabe keinen Owner benennen können, haben Sie dort kein kontrolliertes System, sondern nur eine Duldung.
Warum KI das Problem nicht kleiner macht
KI-Agenten verschärfen das Ganze, weil sie nicht nur lesen, sondern handeln. Sobald ein Agent Rechnungen vorbereitet, Kunden anschreibt oder Daten aus einem ERP zieht, braucht er klare Grenzen, klare Rechte und klare Nachweise. Sonst wird aus „Automatisierung“ sehr schnell eine nicht nachvollziehbare Abkürzung.
Das ist der Punkt, an dem viele Unternehmen falsch abbiegen. Sie bauen erst den Agenten und suchen dann nach einer Governance-Story. Das funktioniert nicht. Die Steuerung muss vorher stehen, sonst prüft der Auditor am Ende nur noch, wie viel Risiko Sie ohne kontrollierten Betrieb akzeptiert haben.
Was ein Security Governance Framework wirklich ist
Ein Security Governance Framework ist kein Sicherheitskonzept im PDF-Format. Es ist das operative Regelwerk dafür, wer entscheiden darf, was erlaubt ist, wie Risiken bewertet werden und woran die Organisation beweist, dass Kontrollen wirklich laufen. Firewalls, MFA und SIEM sind wichtig, aber sie sind Werkzeuge. Governance ist die übergeordnete Steuerung.
Die fünf Bausteine, die wirklich tragen
Der erste Baustein sind Rollen. Ohne eindeutigen Owner bleibt jede Policy ein Papier mit hübschem Titel. In der Praxis braucht jedes kritische System, ob SAP, Dynamics 365, BMD oder ein KI-Agent, eine benannte fachliche und technische Verantwortung.
Der zweite Baustein sind Richtlinien. Sie müssen sagen, was erlaubt ist, was ausgeschlossen ist und was nur nach Freigabe geht. Eine Richtlinie ohne Durchsetzung ist bloß internes Marketing.
Der dritte Baustein ist das Risikomanagement. Hier wird entschieden, welche Risiken akzeptiert, reduziert oder eskaliert werden. Die Verbindung zu Risikoanalyse und Kontrollzuordnung ist auch in der Governance-Praxis klassisch, etwa in einem strukturierten Risk Assessment Framework.
Der vierte Baustein sind Kontrollen. Das sind die messbaren Maßnahmen, also Zugriffsbeschränkungen, Vier-Augen-Prinzip, Logging, Freigabe-Workflows und Review-Zyklen. ENISA beschreibt Governance-Frameworks genau deshalb als Kernbaustein für nationale Cybersecurity-Strategien, weil Organisationen ohne klare Steuerung keine belastbare Rechenschaft aufbauen. Die starke Verankerung solcher Frameworks in Europa ist relevant, selbst wenn sich Unternehmen lieber hinter Einzelmaßnahmen verstecken. Siehe ENISA zu effektiven Governance-Frameworks.
Der fünfte Baustein ist Reporting. Wer Kontrollen nicht regelmäßig berichtet, kennt ihren Zustand nicht. Ein Policy-Dokument ohne KPI-, KRI- und Audit-Nachweise wird schnell zu einem hübsch formatierten PDF, das im Ernstfall niemand verteidigen kann.
Governance ist kein Regelstapel. Es ist ein Organigramm der Verantwortung mit angeschlossenen Kontrollen.
Rollen, Richtlinien und Nachweise
Für den Alltag heißt das, Governance muss an Entscheidungen hängen, nicht an Absichtserklärungen. Wenn ein KI-Agent eine Mahnung verschickt oder ein CRM-Feld überschreibt, braucht es eine dokumentierte Zuständigkeit, eine erlaubte Aktion, ein Protokoll und einen Review-Punkt. Ohne diese vier Dinge bleibt das Ganze lose gekoppelt und damit audit-anfällig.
Ein Baustellenbetrieb würde auch nie ohne klare Gefährdungsbeurteilung arbeiten. Wer sich ein prägnantes Beispiel für strukturierte Pflicht und Nachweis ansehen will, kann die Baustellensicherheit nach Vorschrift als gute Analogie lesen. Genau so muss Sicherheits-Governance im Unternehmen funktionieren, nur eben für Daten, Identitäten und Automatisierung.
Komponenten die in ERP, CRM und KI Architekturen wirklich zählen
In ERP-, CRM- und Finanzumgebungen zählt nicht, wie sauber ein Framework auf der Folie aussieht. Entscheidend ist, ob die Kontrolle im Betrieb greift. Das NIST Cybersecurity Framework ordnet Governance in die Funktionen Identify, Protect, Detect, Respond und Recover ein, und genau dort müssen Sie ansetzen, nicht bei abstrakten Schlagworten. Governance in Identify umfasst ausdrücklich Asset Management, Risk Assessment und Risk Management Strategy. Siehe die NIST-basierte Einordnung von Governance und Kontrollen in Security Governance Framework Components.
Die Funktionen müssen in echte Controls übersetzt werden
Identify heißt zuerst einmal: Welche Systeme, Daten und Agenten gibt es überhaupt? Ohne vollständige Inventur laufen Berechtigung, Monitoring und Incident Response ins Leere, weil niemand weiß, wogegen geprüft werden soll. Für ERP und CRM heißt das, alle produktiven Instanzen, Integrationen, Service-Accounts und Automationen zu erfassen. Wer KI-Agenten oder Low-Code-Workflows betreibt, muss auch deren Auslöser, Datenquellen und Rückschreibungen dokumentieren. Sonst fehlt im Audit der Nachweis, wo ein Prozess tatsächlich beginnt und wer ihn beeinflussen kann.
Protect ist der Bereich der harten Schranken. Hier gehören Rollenmodelle, Berechtigungsgruppen, MFA, Verschlüsselung und Freigaberegeln hinein. Für Rechnungsfreigaben braucht es zum Beispiel das Vier-Augen-Prinzip, nicht eine freundliche Erinnerung im Posteingang. Bei CRM-Änderungen und ERP-Buchungen gilt dasselbe. Wenn ein Fachbereich eigene Automationen baut, müssen dieselben Schranken gelten wie für klassische IT-Prozesse, sonst entsteht Schatten-IT mit Freigaberecht.
Detect muss auf klare Signale trainiert werden. Wenn ein KI-Agent plötzlich mehr Datensätze zieht als üblich, auf andere Systeme zugreift oder Workflows außerhalb der vorgesehenen Kette startet, muss das sichtbar werden. Logging ohne Auswertung ist nur Datensammlung. Wer ernsthaft prüfen will, braucht Schwellenwerte, Alarmwege und Verantwortliche, die Auffälligkeiten auch lesen. Alles andere produziert nur Protokolle für den Ordner.
Respond braucht vorbereitete Reaktionsmuster. Wer einen Agenten abschalten, eine Session sperren oder einen Freigabepfad unterbrechen will, braucht definierte Zuständigkeiten. Sonst diskutiert das Team im Vorfall erst über die Ursache und dann über die Zuständigkeit. In ERP-, CRM- und Low-Code-Umgebungen heißt das auch, Notfallzugriffe, Eskalationen und manuelle Übersteuerungen vorab zu regeln. Der Vorfall darf nicht mit dem Organigramm verhandeln.
Recover bedeutet Wiederanlauf, Rückabwicklung und Nachvollziehbarkeit. Ein gutes Governance-Framework weiß nicht nur, wie man Angriffe erkennt, sondern auch, wie der Betrieb danach sauber weiterläuft. Für ERP und CRM heißt das, Backout-Pläne, Datenkorrekturen und Wiederfreigaben so vorzuhalten, dass Buchungen, Kundenstammdaten und Integrationen nach einem Zwischenfall wieder konsistent sind. Ohne diesen Teil bleibt jede Wiederherstellung Improvisation.
Was der Reifegrad in der Praxis trennt
Der Abstand zwischen Theorie und Realität ist in Unternehmen oft peinlich groß. Viele Organisationen haben irgendein Cybersecurity-Framework auf dem Papier, aber keine saubere Data-Governance im Tagesgeschäft. Der eigentliche Befund ist simpel, ein Framework wird erst dann ernst, wenn es Rollen, Nachweise und Entscheidungen in den operativen Systemen erzwingt. Genau diese Lücke wird bei KI, ERP und CRM teuer, weil Fachbereiche Workflows selbst bauen und die zentrale Kontrolle dabei oft aussetzt.
Die ENISA beschreibt diese Governance-Lücke klar in ihrer Veröffentlichung zur Verankerung von Governance in nationalen Cybersecurity-Strategien. Der Punkt ist nicht akademisch. Wenn Governance nicht im Prozess verankert ist, bleiben Freigaben, Ausnahmen und Kontrollen beliebig, und Audit-Feststellungen sind vorprogrammiert. Die Referenz dazu ist ENISA zur Rahmenverankerung und Governance-Lücke.
NIST GV und die harten Entscheidungsregeln
Der NIST-CSF-Teil GV konkretisiert, was gute Governance wirklich braucht. Organisationen müssen ihre Risikotoleranz und Risk-Appetite festlegen, Rollen, Verantwortlichkeiten und Befugnisse kommunizieren, eine unternehmensweite Cybersecurity-Policy etablieren und die Ergebnisse des Risikomanagements laufend zur Strategieanpassung nutzen. Das ist für ERP-, CRM- und Accounting-Umgebungen entscheidend, weil KI-Automatisierung ohne klare Entscheidungsregeln an Freigaben, Ausnahmen und unklarer Ownership scheitert. Die Referenz dazu ist NIST CSF GV.
Merksatz: Wenn Sie eine Automatisierung nicht mit einem klaren Owner, einem klaren Scope und einem klaren Eskalationspfad beschreiben können, ist sie nicht produktionsreif.
Implementierungsfahrplan für Mittelstand und Enterprise
Wer Governance seriös einführt, macht das nicht als Big-Bang-Projekt. Der richtige Weg ist klein, technisch, nachvollziehbar und eng an den wichtigsten Systemen gestartet. Das entspricht auch dem Grundgedanken, dass Organisationen Governance durch wiederholbare Steuerung aufbauen, nicht durch PowerPoint-Programme.
Die vier Phasen in der richtigen Reihenfolge
Phase 1, Scoping und Asset-Inventur. Zuerst müssen ERP, CRM, Finance-Systeme, Datenflüsse und KI-Agenten erfasst werden. Ohne Inventur gibt es keinen Schutz, keine sinnvolle Priorisierung und keine belastbare Prüfung.
Phase 2, Governance-Organe und Owner. Ein Mittelstand braucht hier meist ein schlankes Governance-Komitee mit klar benannten System- und Prozess-Ownern. Enterprise-Organisationen trennen sauber zwischen CISO-Stab, Fachbereichsverantwortlichen und Internal Audit, damit Entscheidungen nicht im Mittelfeld versanden.
Phase 3, Policies und Controls. Jetzt werden Berechtigungen, Freigaben, Logging, Review-Zyklen und Ausnahmeregeln verbindlich umgesetzt. Für KI-Agenten und Low-Code-Flows braucht es eigene Regeln, weil klassische IT-Frameworks dort oft blind sind, sobald Fachbereiche selbst Workflows bauen.
Phase 4, Überprüfung und Reporting. Governance lebt vom Nachweis. Monatliche Reports, Review-Meetings und dokumentierte Korrekturen machen sichtbar, ob Controls wirken oder nur versprochen wurden.
Für Unternehmen, die die Einführung als Veränderung im Betrieb begreifen wollen, ist ein strukturierter Blick auf Strategien für erfolgreiche Veränderung nützlich, nicht wegen Theorie, sondern weil Governance scheitert, wenn Fachbereiche nicht mitziehen.
Die typischen Stolpersteine in den ersten 90 Tagen
Der erste Fehler ist ein zu breiter Scope. Wer sofort alle Systeme gleichzeitig anfässt, erzeugt nur Widerstand und unklare Ergebnisse. Der zweite Fehler ist ein Governance-Gremium ohne Entscheidungsrecht. Dann wird jede Sitzung zur Diskussion über Zuständigkeit statt zur Steuerung.
Der dritte Fehler ist, KI-Agenten und Low-Code-Workflows als Nebenthema zu behandeln. Genau dort entstehen Schattenprozesse, die niemand im Audit sauber erklären kann. Wer hier früh eine saubere Registrierungs-, Freigabe- und Monitoring-Logik baut, spart sich später einen teuren Kontrollnachlauf.
Für den operativen Aufbau lohnt sich ein Blick auf die interne Ausrichtung von KI-Strategie entwickeln, wenn Sie die Governance mit der tatsächlichen Automatisierungs-Roadmap verzahnen müssen.
Metriken, Reporting und typische Audit-Fallen
Governance ohne Kennzahlen ist Selbsttäuschung. In Österreich ist das besonders heikel, weil der IKT-Sicherheitskatalog für Energie- und Telekommunikationsunternehmen klare Pflichten vorgibt, darunter ein ISMS nach ISO/IEC 27001, ein Risikomanagementprozess, dokumentierte Rollen und Verantwortlichkeiten sowie regelmäßige Management-Reviews und Interne Audits. Das adressiert nicht Theorie, sondern nachweisbare Steuerung mit Auditierbarkeit und Verantwortlichkeit. Die Quelle dazu ist ORCA Security zum IKT-Sicherheitskatalog.
Was im Management-Report stehen muss
Die Kennzahlen müssen nicht schön sein, sie müssen belastbar sein. Ich würde für den Start nur wenige Kennzahlen zulassen, dafür sauber, regelmäßig und systembezogen. Das sind die Werte, die Führungskräfte wirklich sehen müssen.
| Wesentliche Governance-Kennzahlen | Zweck | Quelle / Norm |
|---|---|---|
| Aktive Konten mit dokumentierter MFA | Zeigt, ob Identitäten geschützt sind | NIST CSF GV, ISO/IEC 27001 |
| Abgedeckte Systeme mit freigegebenen Rollenmodellen | Zeigt, ob Berechtigungen kontrolliert sind | IKT-Sicherheitskatalog, ISO/IEC 27001 |
| Abgeschlossene Risiko-Assessments im Plan | Zeigt, ob Risikomanagement lebt | DSGVO, IKT-Sicherheitskatalog |
| Offene Findings aus internen Audits | Zeigt, ob Abweichungen nachverfolgt werden | IKT-Sicherheitskatalog, ISO/IEC 27001 |
| Vorliegende Nachweise für Kontrollen | Zeigt, ob Kontrollen nur dokumentiert oder auch wirksam sind | DSGVO, ISO/IEC 27001 |
Die wichtigste Kette ist simpel. Erst wenn eine Kennzahl, ein Owner und ein Prüfbeleg zusammenkommen, entsteht ein echtes Steuerungssignal. Alles andere ist Reporting-Theater.
Die Audit-Fallen, die ich am häufigsten sehe
Die erste Falle sind dokumentierte, aber nicht gelebte Policies. Ein Auditor merkt das sofort, wenn Freigaben immer über Umwege laufen. Die zweite Falle ist fehlende Evidenz. Wenn ein Control „existiert“, aber kein Log, kein Review und kein Protokoll vorliegt, zählt es praktisch nicht.
Die dritte Falle ist fehlende KI- und Agenten-Governance. Dann laufen automatische Workflows zwar produktiv, aber ohne definierte Ownership, ohne Change-Nachweis und ohne Monitoring. Die vierte Falle sind unklare Rollen zwischen IT, Fachbereich und externen Dienstleistern. Genau dort zerfällt die Nachweisfähigkeit in Stücke.
Auditierbarkeit heißt nicht, dass alles perfekt läuft. Sie heißt, dass Sie jede Kontrolle belegen können.
Praxisbeispiele aus ERP, CRM und Agenten-Architekturen
Ein gutes Governance-Framework zeigt sich erst dann, wenn ein Schaden ausbleibt. Nicht in der Regel, sondern im echten Ablauf. Zwei typische Fälle aus ERP- und CRM-Landschaften reichen, um das zu sehen.
Ein falscher Datensatz, ein falscher Klick, ein echter Schaden
Im ersten Fall arbeitet ein Mitarbeitender im ERP mit Lieferantenstammdaten. Ein manipuliertes Master-Record hätte eine falsche Überweisung ausgelöst, weil das System zwar technisch funktionierte, aber keine saubere Kontrollkette zwischen Änderung, Freigabe und Zahlung hatte. Das Unternehmen hat die Freigabe anschließend über ein genehmigtes Workflow-Template, ein striktes Rollenmodell und automatisiertes Logging abgesichert.
Der entscheidende Punkt war nicht die Sperre selbst. Entscheidend war, dass die Organisation den Stammdatenfluss als Governance-Thema behandelt hat und nicht als reines IT-Detail. So wurde aus einem potenziellen Buchungsfehler ein nachvollziehbarer Prüfpfad.
Im zweiten Fall agierte ein KI-Agent in Slack und Mail zu frei. Er verschickte Inhalte und löste Folgeaktionen aus, ohne dass eine Governance-Domäne für Agenten existierte. Das Unternehmen hat das korrigiert, indem es ein Agenten-Register, Freigabeprozesse und Monitoring eingeführt hat.
Für Teams, die solche Agenten bauen oder integrieren, ist Chatbot Development Services ein sinnvoller Einstieg, wenn Sie die technische Umsetzung mit Governance verknüpfen wollen, statt sie nachträglich anzuschrauben.
Was diese Fälle gemeinsam haben
Beide Fälle zeigen dieselbe Wahrheit. Werkzeuge sind nicht das Problem. Das Problem ist unklare Verantwortung bei wirksamen Aktionen. Sobald ein System über Daten hinaus in Prozesse eingreift, brauchen Sie einen kontrollierten Betrieb.
Die beste Governance verhindert nicht Nutzung, sie verhindert unkontrollierte Nutzung. Das ist ein ehrlicher Unterschied, und genau den müssen Fachbereich und IT gemeinsam akzeptieren.
Governance Checkliste für die ersten 30 Tage
Die ersten 30 Tage müssen auf Inventur, Ownership und minimale Steuerung zielen. Wer sofort mit riesigen Richtlinienkatalogen beginnt, produziert nur Widerstand. Wer klein startet, baut dagegen schnell Nachweisfähigkeit auf und schafft operative Disziplin.
Womit Sie morgen anfangen sollten
- Systeme und Agenten inventarisieren: Listen Sie ERP, CRM, Finance, Schnittstellen und alle KI-Agenten mit Produktivbezug auf. Ohne Inventur gibt es keine Steuerung.
- Owner je System benennen: Jeder kritische Baustein braucht einen fachlichen und einen technischen Verantwortlichen. Ohne Owner gibt es keine Eskalation.
- Minimales Governance-Komitee festlegen: Setzen Sie eine kleine Runde aus Fachbereich, IT, Security und Audit auf. Das Gremium muss entscheiden können, nicht nur diskutieren.
- Risk Appetite und Risikotoleranz schriftlich festhalten: NIST GV verlangt klare Entscheidungsregeln, und die brauchen Sie auch intern. Sonst bleibt jede Ausnahme eine Einzelfalldebatte.
- Drei bis fünf Kennzahlen auswählen: Nehmen Sie nur Metriken, die Sie monatlich belegen können. Weniger ist hier besser.
- Erstes Management-Review terminieren: Legen Sie den Termin fest, bevor die Umsetzung versandet. Reporting ohne Termin endet fast immer im Sande.
- ERP- und CRM-Rechte trennen: Fach- und Administratorrechte dürfen nicht vermischt werden. Das ist eine Grundregel, kein Luxus.
- Audit-Logs aktivieren und prüfen: Wenn ein System etwas ändern darf, muss es auch sauber protokollieren. Sonst gibt es keinen Nachweis.
Der nächste sinnvolle Schritt ist kein großes Programm, sondern ein kontrollierter Start an den kritischen Stellen. Specialty Tokens unterstützt Unternehmen dabei, Governance mit echten ERP-, CRM- und KI-Integrationen in Produktion zu bringen, statt nur Konzepte zu schreiben. Wenn Sie das Thema jetzt sauber aufsetzen wollen, besuchen Sie Specialty Tokens und holen Sie sich ein Team, das Governance direkt in operative Systeme übersetzt.