Die Revisionsstelle war da, der Management Letter liegt auf dem Tisch – und darin stehen sie wieder: SAP_ALL bei Dialogbenutzern, Entwickler, die ihre eigenen Transporte importieren, ein offenes Produktivsystem, Tabellenänderungen ohne Protokoll. Solche Audit Findings sind unangenehm, aber gut lösbar. Entscheidend ist, dass Sie sie nicht nur für den nächsten Prüftermin «zudecken», sondern die Ursache beheben und den Nachweis sauber führen.
Dieser Beitrag zeigt die typischen SAP-Feststellungen zu Berechtigungen, Transporten und Änderungen, was jeweils dahintersteckt, was Sie sofort tun können und wie die Lösung aussieht, die beim nächsten Audit hält.
Warum Prüfer im SAP-System genau hinschauen
Bei der Jahresabschlussprüfung stützt sich die Revisionsstelle auf Zahlen, die im SAP-System entstehen. Sie muss deshalb beurteilen, ob diesen Daten zu trauen ist. Geprüft werden dafür die sogenannten IT General Controls (ITGC) – in der Schweiz im Rahmen der Prüfung des internen Kontrollsystems (IKS), das bei der ordentlichen Revision nach Art. 728a OR bestätigt wird. Für SAP sind drei Bereiche zentral:
- Zugriffe (Access Management): Wer darf was – und ist das angemessen, genehmigt und überwacht?
- Änderungen (Change Management): Gelangen Programme und Customizing nur getestet und freigegeben in die Produktion?
- Betrieb und Protokollierung: Werden kritische Vorgänge aufgezeichnet und ausgewertet?
Ein Finding bedeutet nicht automatisch, dass etwas passiert ist. Es bedeutet, dass die Kontrolle fehlt oder nicht nachweisbar funktioniert – und dass der Prüfer deshalb mehr Stichproben ziehen oder seine Aussage einschränken muss.
Die häufigsten Findings im Überblick
| Bereich | Typisches Finding | Prüfen mit |
|---|---|---|
| Berechtigungen | SAP_ALL oder SAP_NEW bei Dialogbenutzern | SUIM, RSUSR002 (Profil) |
| Berechtigungen | Kritische Berechtigungen und Funktionstrennungskonflikte (SoD) | RSUSR008_009_NEW |
| Berechtigungen | Standardbenutzer mit Standardkennwort, SAP* nicht abgesichert | RSUSR003, RSPARAM |
| Berechtigungen | Ausgetretene, inaktive und Sammelbenutzer | RSUSR200, HR-Abgleich |
| Berechtigungen | Notfallbenutzer ohne Protokoll und Nachkontrolle | Firefighter-Log, Security Audit Log |
| Transporte | Entwickler importieren eigene Aufträge in die Produktion | Rolle mit S_CTS_ADMI, STMS-Importhistorie |
| Transporte | Keine nachweisbare Freigabe vor dem Import | STMS, Ticketsystem |
| Änderungen | Produktivsystem bzw. -mandant offen für Änderungen | SE06, SCC4 |
| Änderungen | Direkte Tabellenänderungen, Debugging mit Ändern | SE16N-Protokoll, Security Audit Log |
| Änderungen | Tabellenprotokollierung nicht aktiv | rec/client, SCU3 |
Berechtigungen: was dahintersteckt und was hilft
SAP_ALL, SAP_NEW und «fast alles»-Rollen
Das Klassiker-Finding. SAP_ALL gibt sämtliche Berechtigungen, SAP_NEW alle neuen Berechtigungen aus Upgrades – beides hat bei Dialogbenutzern im Produktivsystem nichts verloren. Oft steckt kein böser Wille dahinter, sondern Bequemlichkeit aus Projektzeiten oder ein technischer Benutzer, der «einfach funktionieren» sollte. Ebenso kritisch sind Z-Rollen mit Sternwerten in S_TCODE oder S_TABU_DIS, die faktisch dasselbe bewirken.
- Sofort: SAP_ALL und SAP_NEW bei Dialogbenutzern entziehen, Notfallzugriff über einen Firefighter-Prozess abdecken.
- Technische Benutzer: Mit dem Berechtigungstrace (STAUTHTRACE) ermitteln, was wirklich gebraucht wird, und eine passende Rolle bauen.
- Nachhaltig: Eine Liste kritischer Rollen, Profile und Transaktionen festlegen und regelmässig – besser automatisch – dagegen prüfen.
Kritische Berechtigungen und Funktionstrennung
Prüfer arbeiten mit Listen kritischer Berechtigungen: Benutzer- und Rollenpflege (S_USER_GRP, S_USER_AGR), Tabellenpflege (S_TABU_DIS mit Aktivität 02), Debugging mit Ändern (S_DEVELOP mit Objekttyp DEBUG und Aktivität 02), Ausführen beliebiger Reports oder Funktionsbausteine. Dazu kommen Funktionstrennungskonflikte, etwa Kreditor anlegen und Zahlung freigeben in derselben Person.
- Sofort: Treffer mit den Fachbereichen durchgehen. Nicht jeder Treffer ist falsch – aber jeder braucht eine Begründung.
- Bewusst akzeptieren: Wo eine Trennung nicht möglich ist (kleine Teams), eine kompensierende Kontrolle definieren und dokumentieren, zum Beispiel eine monatliche Durchsicht der kritischen Buchungen.
- Nachhaltig: Kritische Kombinationen als Regelwerk hinterlegen (RSUSR008_009_NEW oder ein Werkzeug) und bei jeder Rollenänderung prüfen – nicht erst beim Audit.
Standardbenutzer, inaktive und ausgetretene Benutzer
SAP*, DDIC, EARLYWATCH und TMSADM mit bekannten Kennwörtern, ein fehlender Schutz von SAP* über den Parameter login/no_automatic_user_sapstar, Benutzer von Mitarbeitenden, die das Unternehmen längst verlassen haben, oder Sammelbenutzer wie «LAGER» ohne eindeutige Person – das alles fällt in einer Prüfung schnell auf.
- Sofort: RSUSR003 in allen Mandanten ausführen und Standardkennwörter ändern; ausgetretene Benutzer sperren und mit Gültigkeitsende versehen.
- Nachhaltig: Austritte mit dem HR- bzw. Identity-Prozess koppeln, inaktive Benutzer (z. B. 90 Tage ohne Anmeldung) automatisch melden, Sammelbenutzer abschaffen.
Notfallbenutzer ohne Nachkontrolle
Ein Notfallbenutzer mit weitreichenden Rechten ist erlaubt – wenn er nur auf Antrag, zeitlich begrenzt und mit Protokoll genutzt wird und jemand die Aktivitäten danach durchsieht. Das Finding lautet meist: Der Benutzer ist dauerhaft entsperrt, mehrere Personen kennen das Kennwort, und das Protokoll liest niemand.
- Sofort: Notfallbenutzer sperren, Kennwort ändern, Freischaltung nur über ein Ticket.
- Nachhaltig: Firefighter-Lösung (z. B. SAP GRC Emergency Access Management oder ein schlanker eigener Prozess), Security Audit Log für diese Benutzer vollständig aktiv, dokumentierte Durchsicht nach jedem Einsatz.
Transporte: Wer bringt was in die Produktion?
Entwickler importieren ihre eigenen Aufträge
Wer entwickelt, darf nicht auch selbst in die Produktion importieren – sonst kann eine nicht geprüfte Änderung ohne zweites Augenpaar live gehen. Technisch hängt das am Berechtigungsobjekt S_CTS_ADMI mit den Funktionen IMPA und IMPS (Import aller bzw. einzelner Aufträge). Prüfer vergleichen die Liste der Personen mit Importrecht in der Produktion mit der Liste der Entwickler.
- Sofort: Importrechte im Produktivsystem auf das Basis- bzw. Release-Team beschränken.
- Nachhaltig: Trennung in der Rollenstruktur festhalten (Entwickler-, Transport- und Basis-Rolle), Ausnahmen mit Begründung und Kontrolle.
Keine nachweisbare Freigabe vor dem Import
Selbst wenn nur das Basis-Team importiert: Der Prüfer will sehen, dass jeder Transport in der Produktion getestet und fachlich freigegeben war. Fehlt die Verbindung zwischen Transportauftrag und Freigabe, zieht er Stichproben – und findet dann Aufträge ohne Test oder Ticket.
- Sofort: Für die Importe der Prüfperiode die Freigaben zusammentragen (Ticketnummer im Auftragstext hilft enorm).
- Nachhaltig: Das QA-Genehmigungsverfahren in STMS aktivieren oder ein Werkzeug wie SAP Cloud ALM bzw. ChaRM nutzen, Ticketnummer im Auftragstext verpflichtend machen, Importhistorie regelmässig gegen die Freigaben abgleichen.
Notfall-Transporte
Dringende Korrekturen am Abend sind Alltag. Problematisch wird es, wenn sie den normalen Weg dauerhaft umgehen. Ein definierter Notfallprozess mit nachträglicher Freigabe innerhalb weniger Tage ist für Prüfer in Ordnung – undokumentierte Abkürzungen nicht.
Änderungen direkt im Produktivsystem
System oder Mandant offen
Ist die Systemänderbarkeit (SE06) auf «änderbar» oder erlaubt der Produktivmandant in SCC4 Änderungen an Customizing und Repository, kann jemand mit den passenden Rechten direkt in der Produktion ändern – ohne Transport, ohne Test. Prüfer fragen nach jeder Öffnung im Prüfzeitraum.
- Sofort: System und Produktivmandant schliessen. Für Einstellungen, die in der Produktion gepflegt werden müssen (laufende Einstellungen wie Wechselkurse oder Buchungsperioden), braucht es keine Öffnung.
- Nachhaltig: Jede Öffnung nur mit Ticket, festem Zeitfenster und Freigabe; Nachweis über die Änderungsprotokolle in SCC4 und das Security Audit Log.
Direkte Tabellenänderungen und Debugging mit Ändern
Datenkorrekturen über SE16N, eigene Pflegeprogramme oder das Ändern von Feldwerten im Debugger umgehen sämtliche Prüfungen der Anwendung – und häufig auch die Änderungsbelege. Gerade das Debugging mit Ändern ist im Produktivsystem eine der gefährlichsten Berechtigungen überhaupt.
- Sofort: S_DEVELOP mit DEBUG und Aktivität 02 sowie Tabellenpflegerechte in der Produktion entziehen bzw. nur über den Notfallprozess vergeben.
- Nachweisen: Änderungen über SE16N werden in den Tabellen SE16N_CD_KEY und SE16N_CD_DATA protokolliert; Debugging-Ereignisse erscheinen im Security Audit Log und im Systemlog (SM21).
- Nachhaltig: Datenkorrekturen nur über freigegebene, transportierte Korrekturprogramme mit Protokoll.
Tabellenprotokollierung und Security Audit Log
Viele Customizing-Tabellen sind zur Protokollierung vorgesehen, aufgezeichnet wird aber nur, wenn die Protokollierung über den Profilparameter rec/client eingeschaltet ist. Ausgewertet wird mit SCU3. Fehlt die Protokollierung, kann niemand belegen, wer eine Einstellung geändert hat. Dasselbe gilt für das Security Audit Log: aktiv, aber ohne Filter oder ohne Auswertung ist es für den Prüfer wertlos.
So gehen Sie mit dem Management Letter um
Die technische Lösung ist das eine. Für die Revisionsstelle zählt ebenso, wie Sie das Finding bearbeiten. Bewährt hat sich dieses Vorgehen:
- Verstehen: Welche Kontrolle fehlt genau, für welches System und welchen Zeitraum? Bei Unklarheiten direkt beim Prüfer nachfragen.
- Ursache klären: Ein Benutzer mit SAP_ALL ist das Symptom. Die Ursache ist meist ein fehlender Prozess – etwa keine Prüfung bei der Rollenzuordnung.
- Massnahmenplan: Je Finding Massnahme, verantwortliche Person und Termin festhalten. Diese Management-Stellungnahme gehört in den Bericht.
- Umsetzen und belegen: Jede Massnahme mit einem Nachweis abschliessen – Auswertung, Bildschirmfoto mit Datum, Ticket, Protokoll.
- Wirksamkeit zeigen: Kontrollen über die Zeit laufen lassen. Der Prüfer will im Folgejahr sehen, dass die Kontrolle die ganze Periode funktioniert hat – nicht nur am Stichtag.
Priorisieren: Was zuerst?
| Zeitraum | Massnahmen |
|---|---|
| Diese Woche | SAP_ALL/SAP_NEW bei Dialogbenutzern entziehen, Standardkennwörter ändern, ausgetretene Benutzer sperren, Produktivsystem und -mandant schliessen, Debugging mit Ändern in PRD entziehen |
| 30 Tage | Importrechte trennen, Notfallprozess definieren, Security Audit Log und Tabellenprotokollierung aktivieren, kritische Berechtigungen mit den Fachbereichen bereinigen |
| 90 Tage | Regelwerk für kritische Berechtigungen und SoD, Freigabeprozess für Transporte mit Ticketbezug, regelmässige Rezertifizierung der Rollenzuordnungen, automatische Überwachung mit Meldung |
Tipp aus der Praxis: Führen Sie die wichtigsten Prüfungen nicht einmal im Jahr für den Prüfer durch, sondern monatlich für sich selbst – mit gespeicherter Auswertung. Dann ist der Nachweis beim nächsten Audit bereits vorhanden, und Abweichungen fallen auf, bevor sie zum Finding werden.
Checkliste: bereit für das nächste Audit
- Kein Dialogbenutzer mit SAP_ALL oder SAP_NEW in der Produktion
- Liste kritischer Berechtigungen und SoD-Regeln definiert und regelmässig geprüft
- Standardbenutzer abgesichert, RSUSR003 ohne Befund in allen Mandanten
- Ausgetretene und inaktive Benutzer gesperrt, Sammelbenutzer abgeschafft
- Notfallbenutzer nur auf Antrag, mit Protokoll und Durchsicht
- Importrecht in PRD getrennt von der Entwicklung
- Jeder Transport mit Ticket und Freigabe, Notfallprozess dokumentiert
- Produktivsystem und -mandant geschlossen, Öffnungen begründet
- Kein Debugging mit Ändern und keine Tabellenpflege in PRD ausser im Notfall
- Security Audit Log und Tabellenprotokollierung aktiv und ausgewertet
- Rollenzuordnungen mindestens jährlich durch die Verantwortlichen bestätigt
Werkzeuge, die den Nachweis erleichtern
Mit den SAP-Standardreports kommen Sie weit, der Aufwand liegt aber im Zusammentragen, Bewerten und Dokumentieren. Unser SAPify Security Audit deckt die Berechtigungsseite in einem Durchgang ab: SAP_ALL und kritische Profile, Rollen nach Ihrer Bewertungsliste, kritische Berechtigungen nach Ihren Regeln, Eigenänderungen (wer hat sich selbst Rechte gegeben?), externe und inaktive Benutzer, kritische Transaktionen – berechtigt und tatsächlich genutzt – sowie das Security Audit Log und dessen Administration. Das Ergebnis gibt es als PDF-Bericht für die Revision, Monitoring-Regeln melden neue Treffer per Mail. In der Live-Demo können Sie das mit Beispieldaten selbst ausprobieren.
Wenn ein Management Letter bereits vorliegt, unterstützen wir Sie im Rahmen unserer SAP Security Beratung bei der Bewertung der Findings, dem Massnahmenplan und der Umsetzung – vom Rollenumbau bis zum sauberen Transportprozess. Wie ein tragfähiges Berechtigungskonzept aufgebaut ist, lesen Sie in unserem Beitrag Warum macht ein SAP-Berechtigungskonzept Sinn?
Häufige Fragen
Müssen alle Findings bis zur nächsten Prüfung behoben sein?
Reicht es, SAP_ALL kurz vor der Prüfung zu entziehen?
Wir sind ein kleines Team – wie sollen wir Entwicklung und Import trennen?
Brauchen wir dafür zwingend SAP GRC?
Fazit
Die meisten SAP Audit Findings zu Berechtigungen, Transporten und Änderungen haben dieselbe Wurzel: Eine Kontrolle fehlt oder läuft nicht regelmässig. Die schnellen Korrekturen – SAP_ALL entziehen, System schliessen, Importrechte trennen – sind in wenigen Tagen erledigt. Wirklich gelöst ist ein Finding aber erst, wenn ein Prozess dahintersteht, der die Abweichung künftig verhindert oder sofort meldet, und wenn sich das über das ganze Jahr belegen lässt.
SAP, SAP S/4HANA, SAP Cloud ALM und SAP GRC sind Marken beziehungsweise eingetragene Marken der SAP SE in Deutschland und anderen Ländern. Die Nennung erfolgt ausschliesslich zu Beschreibungszwecken. Dieser Beitrag ersetzt keine Prüfungs- oder Rechtsberatung.
