Von Ausnahme-Falle bis „zu spät für Änderungen“ : Warum Compliance im Betrieb erodiert

Regeln verlieren ihre Wirkung schrittweise

Unternehmen verfügen über Sicherheitskonzepte, Freigabeprozesse, Rollenmodelle, Notfallpläne und Auditprogramme – auf dem Papier ist oft nahezu alles geregelt. Trotzdem entstehen gravierende Compliance-Risiken nicht nur dort, wo eine Vorgabe fehlt: Sie entstehen vor allem an den Übergängen zwischen Regelwerk, Projekt und laufendem Betrieb.

Das Muster ist selten spektakulär: Ein Fachbereich braucht kurzfristig ein neues Werkzeug, eine Führungskraft verlangt einen bequemeren Zugang, ein privilegiertes Konto wird vorübergehend eingerichtet, ein Backup-Job meldet Erfolg, aber niemand prüft die Wiederherstellung. Jede einzelne Entscheidung wirkt zunächst pragmatisch. Das Risiko wächst jedoch, weil die Abweichung(en) nicht sichtbar, nicht befristet sind oder nicht auf ihre Wirkung hin geprüft werden.

Für Governance, Risk und Compliance (GRC) ist deshalb nicht nur entscheidend, ob ein Control beschrieben wurde. Entscheidend ist, ob es im richtigen Moment greift, wer über Abweichungen entscheidet und woran die Organisation erkennt, dass die Kontrolle im Betrieb tatsächlich funktioniert.

Erosionsmechanismen

Reibung erzeugt Schattenprozesse

Schattenprozesse entstehen selten aus Sabotage. Meist versuchen Beschäftigte, ein konkretes Arbeitsproblem zu lösen: Der offizielle Dateiaustausch ist zu langsam, der genehmigte Speicher hat zu geringe Größenlimits, ein Freigabeprozess dauert länger als das Projekt oder ein zugelassenes Werkzeug erfüllt den fachlichen Bedarf nicht. Der private Cloud-Speicher, ein persönlicher Datenträger oder ein frei verfügbares KI-Tool erscheinen dann als schnellere und/oder pragmatische Lösung.

Besonders deutlich zeigt sich dieses Muster bei generativer künstlicher Intelligenz (KI): Ein Team entdeckt einen Dienst, der Berichte zusammenfasst, Texte überarbeitet oder Analysen beschleunigt. Wenige Minuten später verarbeitet ein externer Anbieter möglicherweise Kundeninformationen, interne Dokumente oder personenbezogene Daten – ohne Beschaffungsprüfung, Vertragskontrolle oder dokumentierte Risikoentscheidung.

Dass dies kein theoretisches Szenario ist, zeigte 2023 ein Vorfall bei Samsung [1]. Beschäftigte des Halbleiterbereichs hatten vertraulichen Quellcode und interne Inhalte in ChatGPT eingegeben, um Fehler zu analysieren und Texte zusammenzufassen. Samsung beschränkte daraufhin die Nutzung generativer KI-Dienste auf firmeneigenen Geräten und in internen Netzen.

Aus Sicht des Fachbereichs steht der Produktivitätsgewinn im Vordergrund. Aus Sicht von GRC, Informationssicherheit und Datenschutz stellen sich weitere Fragen: Welche Daten dürfen verarbeitet werden? Wo werden sie gespeichert? Nutzt der Anbieter Eingaben für eigene Zwecke oder zum Training? Welche Unterauftragnehmer sind beteiligt? Welche Löschfristen gelten? Und wer hat die Nutzung freigegeben?

Die Datenschutz-Grundverordnung (DSGVO) verlangt für personenbezogene Daten eine Rechtsgrundlage (siehe etwa https://dsgvo-gesetz.de). Verarbeitet ein externer Anbieter Daten im Auftrag des Unternehmens, muss geprüft werden, ob die Voraussetzungen nach Artikel 28 erfüllt sind. Artikel 32 verlangt ein dem Risiko angemessenes Schutzniveau. Diese Prüfung darf nicht erst beginnen, nachdem das Tool bereits produktiv genutzt wird!

Die Verantwortung für einen Regelverstoß bleibt zwar bei der handelnden Person. Für die Organisation wäre es dennoch zu bequem, wiederkehrende Umgehungen ausschließlich als individuelles Fehlverhalten zu behandeln: Wenn viele Beschäftigte dieselbe Abkürzung wählen, liegt häufig ein strukturelles Hindernis vor. Policies lösen kein Usability-, Kapazitäts- oder Prozessproblem. GRC muss Grenzen setzen und zugleich sichere Alternativen schaffen, die im Arbeitsalltag funktionieren.

Macht verdrängt Kontrolle

Ein zweiter Erosionsmechanismus entsteht, wenn Sicherheitsanforderungen für einflussreiche Personen aufgeweicht werden: Eine Führungskraft empfindet Multi-Faktor-Authentifizierung als störend, verlangt eine Ausnahme von Passwortvorgaben oder benötigt kurzfristig weitreichende Berechtigungen. Die IT setzt den Wunsch um, weil eine Ablehnung politisch schwierig erscheint oder ein formaler Eskalationsweg fehlt.

Gerade bei privilegierten Konten müsste das Gegenteil gelten. Je größer Reichweite und Wirkung einer Rolle sind, desto belastbarer müssen Authentifizierung, Protokollierung, Rezertifizierung und Überwachung sein. Das Risiko ergibt sich nicht aus dem Status einer Person, sondern aus dem möglichen Schaden, den ihre Berechtigung bei Fehlbedienung, Missbrauch oder Kompromittierung verursachen kann.

Eine sachlich begründete Ausnahme kann durchaus notwendig sein – etwa für eine zeitkritische Störung oder einen eng begrenzten Test. Sie darf aber nicht allein durch Hierarchie legitimiert werden. Erforderlich sind ein dokumentierter Zweck, eine Risikoeinschätzung, eine angemessene Genehmigung, kompensierende Kontrollen und ein technisch oder organisatorisch gesichertes Ende – „bis auf Weiteres“ ist keine belastbare Laufzeit.

Konfiguration versus Wirksamkeit

Viele Auditfeststellungen beginnen mit einem beruhigenden Satz: „Das haben wir geregelt.“ Backup-Konzept, Notfallhandbuch, Zutrittsregelung oder ein Prozess für technische Konten existieren – der Nachweis, dass diese Kontrollen im Betrieb funktionieren, fehlt jedoch häufig.

Ein konfigurierter Backup-Job beweist beispielsweise nicht, dass Daten vollständig gesichert werden oder sich innerhalb der geforderten Zeit wiederherstellen lassen. Erst Monitoring, Fehlerbehandlung und regelmäßige Restore-Tests schaffen belastbare Wiederherstellbarkeit. Ein Notfallplan belegt ebenfalls keine Resilienz, solange man Rollen, Kontaktdaten, Abhängigkeiten und Wiederanlaufverfahren nicht regelmäßig überprüft und in Übungen trainiert und verifiziert.

Der Ransomware-Angriff auf den irischen Gesundheitsdienst HSE [2] hat 2021 die Folgen [3] einer solchen Lücke aufgezeigt: Eine interne Prüfung aus dem Jahr 2019 hatte festgestellt, dass kein standardisierter Ansatz für Backup und Recovery über die Rechenzentren hinweg existierte und die nationale Backup- und Recovery-Policy noch nicht fertiggestellt war. Nach dem Angriff wäre die Wiederherstellung der zahlreichen Systeme aus Sicherungen erheblich zeitaufwendiger gewesen als die Entschlüsselung mit einem später verfügbaren Werkzeug. 99 % der Anwendungen waren 130 Tage nach dem Angriff wiederhergestellt.

Dasselbe Problem zeigt sich bei Identitäten und Berechtigungen: Dienstkonten überleben häufig das System oder Projekt, für das sie eingerichtet wurden. Ohne eindeutigen Owner, technischen Zweck, Ablaufdatum, regelmäßige Rezertifizierung und Verknüpfung mit dem Asset-Lifecycle mutiert ein historischer Zugang jedoch zu einem dauerhaften Risiko.

Eine wirksame Kontrolle benötigt daher mehr als eine Richtlinie oder Konfiguration. Sie braucht einen Sollzustand, messbare Kriterien, einen verantwortlichen Owner, regelmäßige Tests und eine dokumentierte Behandlung von Abweichungen. Eine Kontrolle, deren Zustand niemand beobachtet, verkommt mit der Zeit zur bloßen Behauptung.

Ausnahmen ohne Ende

Ausnahmen lassen sich nicht vollständig vermeiden – Produktionsstörungen, Migrationsprojekte, technische Altlasten oder dringende Geschäftsanforderungen können zeitweise Abweichungen erforderlich machen. Nicht jede Ausnahme ist problematisch, wohl aber eine Ausnahme ohne kontrollierten Lebenszyklus.

Ein belastbarer Prozess beantwortet hier mindestens sechs Fragen:

• Wer trägt die Verantwortung?
• Welche Vorgabe wird aus welchem Grund nicht eingehalten?
• Welches Risiko entsteht?
• Welche kompensierenden Maßnahmen gelten?
• Wann endet die Ausnahme?
• Anhand welcher Bedingung wird die Ausnahme beendet oder erneut darüber entschieden?

Diese Informationen gehören in ein zentrales Register. Kritische Ausnahmen benötigen überdies eine angemessene Genehmigung und eine sichtbare Eskalation, wenn Fristen überschritten werden. Wo möglich, sollte man auf zeitlich begrenzte Berechtigungen und technische Ablaufmechanismen setzen – ein Kalendereintrag allein entzieht keine Domänen-Admin-Berechtigung.

Für den Einstieg genügt eine einfache Übung: Die Organisation identifiziert ihre wichtigsten dauerhaften Abweichungen und prüft, ob jeweils Owner, Risikoentscheidung, kompensierende Kontrolle, Enddatum und Schließungskriterium vorhanden sind. Das Ergebnis ist häufig aussagekräftiger als eine weitere allgemeine Policy.

Compliance-Entscheidung vor Investition

Viele Unternehmen organisieren Compliance als abschließende Kontrollstation: Zuerst wird ein Prozess entworfen, ein Tool ausgewählt, ein Dienstleister eingeplant oder ein Datenfluss technisch umgesetzt. Kurz vor dem Produktivstart sollen dann Datenschutz, Legal, Informationssicherheit und Compliance bestätigen, dass das Vorhaben zulässig ist.

Zu diesem Zeitpunkt sind wirtschaftliche und politische Bindungen bereits entstanden – Budgets wurden ausgegeben, Termine kommuniziert und Erwartungen aufgebaut. Jede notwendige Änderung erscheint nun als Verzögerung. Aus einer fachlichen Prüfung wird ein Konflikt zwischen Projektziel und Kontrolle.

Security und Privacy by Design drehen diese Reihenfolge um: Schutzbedarf, Rechtsgrundlagen, Datenflüsse, Rollen, Drittparteien, Protokollierung, Löschung, Berechtigungen und Exit-Szenarien sind hierfür als Anforderungen des Vorhabens zu behandeln. Das beschleunigt Projekte letztlich, weil man unzulässige oder technisch nicht beherrschbare Lösungen aussortiert, bevor sie teurer werden.

In der Praxis braucht es dafür verbindliche Entscheidungspunkte. Neue Systeme und wesentliche Änderungen sollten definierte GRC-, Datenschutz- und Security-Prüfungen durchlaufen. Architektur-Boards, Beschaffungsprozesse oder Projekt-Stage-Gates eignen sich als Anker. Eine fehlende Prüfung darf nicht nur als offene Dokumentationsaufgabe in die nächste Phase verschoben werden.

Freigaben gelten nur im konkreten Kontext

Eine technische oder konzerninterne Freigabe beantwortet nicht automatisch alle regulatorischen Fragen. Internationale Unternehmen benötigen zu Recht einheitliche Mindeststandards. Diese beseitigen jedoch nicht die Unterschiede zwischen Rechtsordnungen, Aufsichtsregimen und branchenspezifischen Anforderungen.

Ein global vorgesehener Administrationszugriff kann in einem regulierten Umfeld zusätzliche Genehmigungen, Protokollierung oder lokale Einschränkungen erfordern. Ein konzernweit etablierter Dienstleister kann etwa an Vorgaben zu Datenstandorten, Berufsgeheimnissen, Bankaufsicht oder kritischen Infrastrukturen scheitern. Die Frage lautet deshalb nicht nur, ob eine Lösung technisch und wirtschaftlich funktioniert, sondern auch, ob sie im konkreten Land, Sektor und Einsatzkontext zulässig ist.

Bewährt haben sich benannte lokale Ansprechpartner, die globale Programme in die jeweilige Regulierung übersetzen, sowie klare Eskalationswege für Konflikte zwischen Konzernstandard und lokaler Pflicht. Lokale Prüfung bedeutet nicht, für jedes Land ein eigenes Kontrollsystem zu bauen: Sie ergänzt globale Vorgaben aber dort, wo Recht und Aufsicht es verlangen.

Betriebsmodell statt Kontrollkatalog

Die vier beschriebenen Erosionsmechanismen zeigen, warum mehr Dokumentation allein das Problem nicht löst: Compliance braucht ein Betriebsmodell, das Abweichungen früh sichtbar macht und Entscheidungen erzwingt.

Dazu gehören kurze und verständliche Freigabewege für häufige Anwendungsfälle, technisch durchgesetzte Leitplanken, verbindliche Stage-Gates, ein zentrales Ausnahme- und Maßnahmenregister sowie Wirksamkeitsnachweise für kritische Kontrollen. Ergänzend sollte das Management wenige aussagekräftige Signale erhalten: überfällige Ausnahmen, ungeklärte Control-Owner, fehlgeschlagene Restore-Tests, fehlende Rezertifizierung privilegierter Konten, ungeprüfte Drittanbieter und wiederkehrende Umgehungen desselben Prozesses.

Solche Kennzahlen dienen nicht der Sammlung weiterer Compliance-Daten, sondern zeigen, an welcher Stelle Regelwerk und Betriebsrealität auseinanderlaufen und wo eine Managemententscheidung erforderlich ist.

Fazit

Gelebte Compliance misst sich nicht an der Zahl der Richtlinien, sondern an den Entscheidungen des Alltags: Ein verfügbares Tool ist noch nicht freigegeben. Eine hierarchische Anweisung ersetzt keine Risikoentscheidung. Eine technische Kontrolle ist nicht wirksam, nur weil sie konfiguriert wurde. Und eine Ausnahme darf sich nicht unbemerkt zum Normalfall wandeln.

Die wichtigste Aufgabe für GRC, Informationssicherheit, Datenschutz und Compliance besteht deshalb darin, früher in Projekte und Betriebsentscheidungen zu gelangen: nicht als nachgelagerte Instanz, die fertige Lösungen abzeichnet, sondern als Mitgestalter von Anforderungen, sicheren Arbeitswegen und belastbaren Freigabekriterien.

Der konkrete Hebel liegt in der Verringerung unnötiger Reibung, einer eskalationsfesten Kontrolle privilegierter Entscheidungen, messbaren Wirksamkeitsnachweisen und einem konsequenten Ausnahmeprozess. Denn die günstigste Compliance-Korrektur ist diejenige, die erfolgt, bevor ein unzulässiger Prozess, eine unkontrollierte Berechtigung oder ein nicht beherrschter Datenfluss produktiv wird.

Sabine Frömling ist freiberufliche Beraterin für IT/OT-Security sowie Governance, Risk & Compliance (GRC, https://froemling.consulting) und Autorin des Praxisratgebers „ISMS für die Industrie“ (Springer Vieweg, 2026).

Literatur

• _{[1] Michael Linden, Samsung verbietet Mitarbeitern die Nutzung generativer KI, Golem, Mai 2023, https://glm.io/173848}
• _{[2] PricewaterhouseCoopers (PwC), Conti cyber attack on the HSE Independent Post Incident Review, Dezember 2021, online verfügbar via https://cyberireland.ie/conti-cyber-attack-on-the-hse/}
• _{[3] Office of the Comptroller and Auditor General, Financial impact of cyber security attack, Chapter 12 in: Report on the accounts of the public services 2021, September 2022, https://data.gov.ie/dataset/financial-impact-of-cyber-security-attack}