Governance, Risk, Compliance:
Security für SAP-Landschaften verstehen

Der regulatorische Rahmen: Warum GRC keine freiwillige Übung ist

GRC ist kein Nice-to-have. Das deutsche Gesellschaftsrecht verpflichtet Vorstände und Geschäftsführungen persönlich zu Sorgfalt, Risikofrüherkennung und wirksamen Kontrollstrukturen. Das Aktiengesetz (§ 93 AktG) und das GmbH-Gesetz (§ 43 GmbHG) regeln die persönliche Haftung der Leitungsebene. Nach § 91 Abs. 2 AktG müssen Vorstände ein Überwachungssystem einrichten, damit bestandsgefährdende Entwicklungen früh erkannt werden. Das StaRUG verpflichtet seit 2021 auch GmbH-Geschäftsführer und andere Geschäftsleiter haftungsbeschränkter Unternehmen zu einer fortlaufenden Krisenfrüherkennung. Und das Ordnungswidrigkeitengesetz (§ 130 OWiG) bestraft die Verletzung von Aufsichtspflichten mit hohen Geldbußen.

Auf diesem Fundament setzen zahlreiche spezifische Regulierungen auf, die GRC-Verantwortliche kennen müssen.

Fünf Risiken, die GRC-Verantwortliche nicht ignorieren dürfen

Die Angriffsfläche von SAP-Landschaften wächst, durch Cloud-Migration, neue Schnittstellen und den Einsatz von KI. Gleichzeitig werden Angreifer professioneller und schneller. Diese fünf Risikobereiche verdienen besondere Aufmerksamkeit.

Vom Risiko zur Lösung: Wie Sie Ihre SAP-Landschaft schützen

Die gute Nachricht: Für jedes der genannten Risiken gibt es erprobte Ansätze und Werkzeuge. Die Herausforderung liegt nicht im Mangel an Lösungen, sondern in ihrer richtigen Auswahl, Implementierung und Verzahnung.

GRC oder die Frage, ob Sie Ihr Kernsystem im Griff haben

Im Gespräch mit Karl Ludwig Hahne

Karl Ludwig Hahne kennt die Herausforderungen, vor denen GRC-Verantwortliche in SAP-Landschaften stehen, aus jahrelanger Praxis. In unserem Interview spricht er über regulatorischen Druck, typische Fehler und die Frage, warum der persönliche Austausch unter Expert*innen unersetzlich bleibt.

Herr Hahne, warum ist GRC gerade jetzt so relevant wie nie zuvor?

Weil drei Entwicklungen zusammenfallen und sich gegenseitig verstärken.

Erstens hat sich der regulatorische Rahmen deutlich verdichtet: DORA, NIS2, das KRITIS-Dachgesetz und der EU AI Act betreffen nicht nur Dokumentation – sie betreffen die Systeme, in denen Buchhaltung, Einkauf und Personalprozesse laufen.

Zweitens ist die Bedrohungslage konkreter geworden. Die 2025 bekannt gewordene kritische NetWeaver-Schwachstelle wurde schnell aktiv ausgenutzt. Wenn ein ERP-Kernsystem betroffen ist, geht es um Lieferfähigkeit, Produktion und finanzielle Prozesse.

Drittens steht bei vielen Unternehmen der Umbau an. Mehr als die Hälfte arbeitet noch mit ECC oder älteren Business-Suite-Versionen. Mit dem Wartungsende 2027 – und möglichen Verlängerungen bis 2030 – entsteht konkreter Transformationsdruck.

Im Kern: Regulierung verlangt belastbare Nachweise, die Bedrohungslage macht wirksame Kontrollen unverzichtbar, und die Migration eröffnet ein Zeitfenster, die Kontrollarchitektur neu aufzusetzen. GRC ist deshalb keine Dokumentationspflicht mehr – sondern zeigt, ob ein Unternehmen sein Kernsystem wirklich im Griff hat.

Karl Ludwig Hahne ist geschäftsführender Gesellschafter der Hahne Digital Assurance GmbH und seit September 2024 Leiter der Fachgruppe SAP des ISACA Chapter Germany. Sein Fokus liegt auf den Gebieten SAP-Compliance und IT-Governance sowie der Prüfung von IT-gestützten Geschäftsprozessen. Ein besonderer Schwerpunkt seiner Arbeit ist dabei die ERP-Compliance im Mittelstand.

Welche Fehler sehen Sie in der Praxis am häufigsten, wenn Unternehmen GRC umsetzen?

Der häufigste Fehler ist organisatorisch, nicht technisch: GRC wird als Tool-Einführung behandelt. Man kauft eine Lösung, lädt ein Standardregelwerk hoch – und wundert sich, dass Tausende Funktionstrennungskonflikte aufleuchten, für die niemand zuständig ist. Das Tool macht Unordnung sichtbar, beseitigt sie aber nicht.

Vorab muss geklärt werden: Welche Risiken sind wirklich relevant? Welche Kontrollen begrenzen sie? Und wer trägt dafür die Verantwortung? Ohne diese Antworten entstehen Listen, aber keine wirksame Steuerung.

Dazu kommen historisch gewachsene Berechtigungen, deren Ursprung niemand mehr kennt – was oft erst bei einer Prüfung oder SAP-S/4HANA-Migration auffällt. Gerade dort sehe ich ein weiteres Risiko: Das ECC-Berechtigungskonzept wird eins zu eins übernommen. Im neuen System laufen Debitoren- und Kreditorenpflege auf einer Oberfläche zusammen – wer die fachliche Trennung nicht neu abbildet, verliert sie, mitunter unbemerkt.

Und schließlich: GRC darf nicht mit dem Go-live enden. Temporäre Notberechtigungen und nicht nachgehaltene SoD-Konflikte werden schnell zu dauerhaften Risiken.

SAP S/4HANA, Cloud, KI: Welches Thema bereitet GRC-Verantwortlichen aktuell die größten Kopfschmerzen?

Ehrlich gesagt: alle drei, aber aus unterschiedlichen Gründen. Und sie hängen eng zusammen.

SAP S/4HANA ist das akuteste Thema, weil der Zeitrahmen feststeht. Wer die Migration zu spät mit GRC-Fragen verbindet, übernimmt gewachsene Zugriffs- und Berechtigungsrisiken in die neue Umgebung. In der Praxis werden Fragen zu Rollen, Risiken und Verantwortlichkeiten oft erst gestellt, wenn die Transformation bereits weit fortgeschritten ist.

Cloud – etwa im Kontext von RISE oder GROW with SAP – ist das häufig unterschätzte Thema. Betriebsaufgaben verlagern sich, die Verantwortung für Rollen, Berechtigungen und Funktionstrennung bleibt. Das Shared-Responsibility-Modell muss verstanden und in konkrete Zuständigkeiten übersetzt werden.

KI hat die steilste Lernkurve. Mit Assistenten wie SAP Joule und agentischen Funktionen rückt eine zentrale GRC-Frage in den Mittelpunkt: Unter welcher Identität und mit welchen Berechtigungen handeln KI-Systeme? Viele Kontrollmechanismen sind noch auf menschliche Nutzer ausgelegt – nicht auf automatisierte Prozesse.

Wenn ich eines nennen müsste: SAP S/4HANA, weil der Termin fest ist. Wer die Migration klug nutzt, legt aber zugleich das Fundament für Cloud und KI.

Welchen einen Rat würden Sie jedem GRC-Verantwortlichen mit auf den Weg geben?

Nutzen Sie den Umbau, den Sie ohnehin machen müssen, um GRC von Anfang an mitzuplanen – nicht erst, wenn der Prüfer kommt.

Wer nach SAP S/4HANA migriert oder in die Cloud geht, hat ein seltenes Zeitfenster zum Aufräumen. Definieren Sie vorab die kritischen Prozesse und die Kontrollen, die darin wirken sollen. Überarbeiten Sie die Funktionstrennungsmatrix, statt die alte zu kopieren. Und klären Sie, wer im Fachbereich welche Risiken verantwortet.

Für KI gilt dasselbe: Governance vor dem Rollout. Berechtigungen, Freigaben und Verantwortlichkeiten müssen geklärt sein, bevor KI-Funktionen in produktive Prozesse eingebunden werden.

GRC nachträglich einzubauen ist fast immer teurer und weniger wirksam. Ein sauber kontrolliertes System ist zudem stabiler, transparenter und leichter veränderbar.

Und: Diese Fragen müssen Sie nicht allein lösen. Der Austausch mit anderen, die vor denselben Herausforderungen stehen, hilft – bewährte Ansätze kennenlernen, typische Fehler früher erkennen. 

Herr Hahne, wir danken für das spannende Gespräch.

Buchtipps