Finanzunternehmen und professionelle Dienstleister leben und sterben mit ihren Prüfungsergebnissen.

Wenn ein Prüfer für SOX, SOC 2, ISO 27001, DSGVO oder DORA fragt: "Wer hatte an diesem Datum Zugriff auf dieses System, wer hat ihn genehmigt und wann wurde er zuletzt überprüft?", dann können Sie entweder:

  • einmal klicken und ihm einen sauberen Bericht übergeben oder
  • wochenlang Tickets, Exporte und alte Slack-Threads durchforsten.

Diese Anleitung ist für Teams, die genug von der zweiten Variante haben.

Sie lernen, Zugriffskontrollen und Identitätsverwaltung so zu gestalten, dass sie automatisch den Prüfpfad, die Nachweise und die Compliance-Berichte erzeugen, die Sie brauchen - ohne Ihr IT-Team in Vollzeit-Tabellenpfleger zu verwandeln.

Wir bleiben praxisnah, klar in der Meinung und orientieren uns an der Realität regulierter Unternehmen.

Was Sie lernen werden

Am Ende wissen Sie, wie Sie:

  • regulatorische Anforderungen (SOX, SOC 2, ISO 27001, PCI DSS, DSGVO, DORA) in konkrete Zugriffsdokumentation übersetzen
  • Joiner-Mover-Leaver-Workflows so gestalten, dass sie nachweislich vollständig sind
  • Benutzer-Zugriffsrezensionen zu echten Entscheidungen machen - statt zu reinen Alibi-E-Mails
  • einen Prüfpfad aufbauen, der manipulationssicher, datenschutzkonform und leicht durchsuchbar ist
  • von einmal im Jahr Compliance-Panik in der IT zu kontinuierlicher, reibungsarmer Governance wechseln

Gedacht ist das für Verantwortliche aus IT, Sicherheit und IAM in Finanzunternehmen und professionellen Dienstleistungsfirmen in den USA, UK und der DACH-Region, die schlanke Teams führen, aber unter starker Regulierung stehen.

Voraussetzungen: Was Sie vor dem Start brauchen

Sie brauchen kein riesiges IAM-Programm. Aber ein paar Grundlagen sind nötig:

  • Eine einzige, vertrauenswürdige Identitätsquelle
    • HR-System (Workday, Personio, BambooHR usw.) oder ein verlässliches, gepflegtes Verzeichnis
  • SSO oder zentrale Authentifizierung für so viele Anwendungen wie möglich
    • Okta, Microsoft Entra oder Ähnliches
  • Systeminventar
    • Liste der prüfungsrelevanten Anwendungen: ERP/Hauptbuch (SAP, NetSuite), CRM (Salesforce), Bank- oder Kanzleisysteme, DMS, elektronische Signatur, Datenräume, Dateifreigaben
  • Benannte Datenverantwortliche
    • Für jedes kritische System eine verantwortliche Person (oft aus Finanzen, Recht oder Operations, nicht aus der IT)
  • Einen Ort zur Ablage der Prüfungsnachweise
    • Eine Identity-Governance-Plattform wie Iden, ein GRC-Werkzeug oder im schlechtesten Fall ein klar strukturiertes Laufwerk mit sauberen Ablagen

Wenn Ihnen noch nicht alles davon zur Verfügung steht, nutzen Sie die folgenden Schritte, um die fehlenden Bausteine durchzusetzen.

Schritt 1: Vorschriften in konkrete Prüfungsfragen übersetzen

Die meisten Teams starten mit Rahmenwerken. Prüfer starten mit Fragen.

Statt "Wir müssen ISO 27001 einhalten" sollten Sie fragen: Was wird ein Prüfer konkret anfordern?

Die wichtigsten Rahmenwerke laufen auf dieselben Forderungen hinaus:

  • ISO/IEC 27001:2022 Anhang A 5.15-5.18 verknüpfen Zugriffskontrolle, Benutzerbereitstellung und regelmäßige Zugriffsüberprüfungen direkt mit prüfbaren Nachweisen
  • SOC 2 Trust Services Criteria CC6.1-CC6.3 verlangen Beschränkungen des logischen Zugriffs, das Prinzip der minimalen Rechtevergabe und regelmäßige Zugriffsüberprüfungen
  • PCI DSS v4.0 Anforderung 7 fordert, dass der Zugriff auf Karteninhaberdaten auf diejenigen beschränkt wird, deren Tätigkeit ihn erfordert
  • DSGVO/UK GDPR: IP-Adressen und Benutzerkennungen in Protokollen sind personenbezogene Daten, die geschützt und nur so lange aufbewahrt werden dürfen, wie nötig

Für Finanzunternehmen und professionelle Dienstleister kommen hinzu:

  • SOX und Finanzaufsicht (SEC/PCAOB, FCA/PRA, BaFin) fokussieren darauf, wer Buchungen anlegen, freigeben und verbuchen darf
  • DORA und NIS2 drängen auf stärkere Protokollierung und nachvollziehbare Zugriffe

Übersetzen Sie das in klare, leicht verständliche Prüfungsfragen:

  • Wer kann heute auf System X zugreifen? Mit welchem Berechtigungsniveau?
  • Wer hat den Zugriff jedes Benutzers genehmigt? Wann?
  • Wann wurde dieser Zugriff zuletzt überprüft, und von wem?
  • Was passiert, wenn jemand eintritt, die Rolle wechselt oder ausscheidet?
  • Können Sie Protokolle vorlegen, die belegen, ob dieser Benutzer an einem bestimmten Datum auf sensible Daten zugegriffen hat?

Schreiben Sie diese Fragen auf. Der Rest dieser Anleitung zeigt Ihnen, wie Sie Ihre Identitätsverwaltung so gestalten, dass Sie sie in Minuten beantworten können - nicht in Wochen.

Häufiger Fehler
Kontrollen einführen, ohne zuerst festzulegen, welche Prüferfragen Sie beantworten müssen. Sie haben dann zwar Protokolle, aber keine nachvollziehbare Geschichte.

Schritt 2: Identitäten, Systeme und "Kronjuwelen" abbilden

Ein prüfungssicheres Zugriffsmodell beginnt mit Klarheit: wen Sie steuern, welche Systeme betroffen sind und warum diese wichtig sind.

  1. Systeme nach Risiko und Regulierung klassifizieren

    • Hohes Risiko: Hauptbuch, Handelssysteme, Bankensysteme, Kanzleisoftware, Dokumentenverwaltung mit Mandantenakten, Kartenverarbeitung
    • Mittleres Risiko: CRM, Support, Kollaborationstools mit Kundendaten
    • Niedriges Risiko: interne Werkzeuge, Marketing

  2. Alle Identitätstypen erfassen

    • Mitarbeitende, Partner, externe Dienstleister
    • Dienstkonten, RPA-Bots, CI/CD-Konten
    • "Neue Identitätsspezies" - KI-Agenten, die in Ihrem Namen APIs aufrufen

  3. Verantwortlichkeiten dokumentieren

    • Für jedes System mit hohem und mittlerem Risiko festhalten:
      • Fachverantwortliche (z. B. Leiter Finanzen, Managing Partner, COO)
      • Technische Verantwortliche (Systemadministrator, IT)

  4. Systeme auf regulatorische Treiber abbilden

    • Beispiel: "NetSuite -> SOX, SOC 2, ISO 27001; Salesforce -> DSGVO, SOC 2; Kartenumgebung -> PCI DSS."

Diese Abbildung ist das Rückgrat Ihrer Zugriffsdokumentation - das Register für jede Überprüfung, Ausnahme und jeden Bericht.

Tipp
Starten Sie mit Ihren Top-10-Systemen (NetSuite, SAP, Salesforce, DocuSign, Kanzleisoftware, DMS, Datenraum usw.). Wenn das Muster einmal steht, ist die Erweiterung einfach.

Schritt 3: Zugriffsmodell und Datenverantwortung definieren

Prüfer hassen "Stammeswissen". Sie erwarten dokumentierte Zugriffskontrollregeln, die auf Geschäftsrollen abgebildet sind.

Mindestens sollten Sie festlegen:

  1. Rollenmodell pro System

    • Rollenbasierte Zugriffskontrolle (RBAC): Geschäftsrollen (Kreditorenbuchhalter, Portfoliomanager, Partner, Associate) auf Systemrollen und Berechtigungen abbilden.
    • Für Sonderfälle Attribut-basierte Zugriffskontrolle (ABAC) zulassen: z. B. "Region = EU" oder "Standort = London" begrenzt Zugriff auf Mandantenakten.
    • Moderne Empfehlungen sehen eine Kombination aus RBAC für Grundrollen und ABAC für feinere Einschränkungen in regulierten Umgebungen vor. Branchenübliche Best Practices kombinieren zunehmend RBAC für Basisrollen mit ABAC für fein granulare Einschränkungen in regulierten Umgebungen

  2. Funktionstrennung (Segregation of Duties, SoD)

    • Verbotene Kombinationen definieren:
      • Zahlung anstoßen + Zahlung freigeben
      • Lieferanten anlegen + Lieferanten freigeben
      • Hauptbuch-Buchung erfassen + Hauptbuch-Buchung freigeben
    • SoD-Regeln in Ihr Rollendesign einbauen, sodass Verstöße technisch unmöglich sind - oder zumindest automatisch markiert werden.

  3. Verantwortung und Genehmigungsregeln

    • "Zugriff auf Rollen zur Hauptbuchbuchung erfordert Genehmigung durch den Leiter Finanzen."
    • "Zugriff auf das Mandantenakten-DMS muss vom verantwortlichen Partner genehmigt werden."

Dokumentieren Sie dies in einer einfachen, lebendigen Spezifikation - eine Tabelle pro System genügt, wenn sie aktuell ist.

Häufiger Fehler
RBAC nur im Kopf einzelner Personen oder in einer 40-seitigen Richtlinie zu verstecken. Prüfer wollen live einsehbare, überprüfbare Berechtigungen sehen, die mit der tatsächlichen Konfiguration übereinstimmen.

Schritt 4: Joiner-Mover-Leaver-Prozesse selbstdokumentierend machen

Die meisten gravierenden Prüfungsfeststellungen in Finanzunternehmen und Kanzleien entstehen durch unvollständiges Offboarding und holprige Rollenwechsel - nicht durch das Onboarding.

Ihr Ziel: Jeder Eintritt, Rollenwechsel und Austritt erzeugt automatisch saubere, konsistente Dokumentation.

4.1 Den JML-Prozess standardisieren

Für jeden Identitätstyp (Mitarbeitende, Externe, Dienstkonten):

  • Joiner
    • Basiszugriffe nach Abteilung, Standort und Rolle
    • Zeitlich begrenzte oder strikt minimale Standardrechte für sensible Systeme
  • Mover
    • Ausgelöst durch Stellenänderung im HR-System, nicht durch eine zufällige E-Mail an die IT
    • Sowohl Vergabe als auch Entzug von Berechtigungen erzwingen - keine schleichende Rechteausweitung
  • Leaver
    • Ein einziges, maßgebliches Beendigungsereignis (aus HR-System oder Identitätsprovider)
    • Automatisches Deprovisioning über alle relevanten Systeme hinweg - auch solche ohne SCIM oder moderne APIs

Schlanke Teams kämpfen oft damit, dass die meisten Werkzeuge nur SCIM-fähige Anwendungen automatisieren und den Rest manuell lassen. Iden setzt auf vollständige Abdeckung - inklusive Long-Tail-SaaS, On-Premises-Systemen und spezialisierten Finanzanwendungen ohne moderne APIs.

4.2 Nachweise automatisch miterzeugen

Zu jedem JML-Ereignis sollten Sie nachweisen können:

  • Wer die Änderung angefordert hat (HR, Führungskraft oder System)
  • Wer sie genehmigt hat (Fachverantwortliche) oder ob sie richtliniengesteuert war
  • Welche Berechtigungen hinzugefügt oder entfernt wurden
  • Wann die Provisionierung bzw. Deprovisionierung je System abgeschlossen wurde

Eine moderne Identity-Governance-Plattform liefert dies über unveränderliche Prüfprotokolle. In einer "Gaffer-Tape-Welt" ist es eine Mischung aus:

  • Tickets (ServiceNow, Jira) mit klaren Feldern
  • Änderungsprotokollen in Ihrem Identitätswerkzeug
  • exportierbaren Berichten aus den wichtigsten Systemen

Tipp
Lassen Sie die Systeme den Nachweis von selbst erzeugen - verlangen Sie nicht von Menschen, "Belege anzuhängen". Wenn Ihr Joiner-Prozess über eine Identity-Governance-Plattform mit agentischen Workflows und unveränderlichen Prüfprotokollen läuft, schreibt sich Ihre Zugriffsdokumentation während der Arbeit von selbst.

Schritt 5: Zugriffsanfragen und Genehmigungen zentralisieren

E-Mails und Slack-Direktnachrichten sind keine Zugriffsdokumentation.

Wechseln Sie zu einem einzigen Kanal für Anfragen (ITSM, Portal oder Identity-Governance-Oberfläche) für alle relevanten Systeme:

  • Finanzsysteme (SAP, NetSuite, Handelssysteme)
  • Kundengerichtete Systeme (CRM, DMS, elektronische Signatur)
  • Gemeinsame Datendienste und Datenräume

Für jede Anfrage sollten Sie immer erfassen:

  • Anfragende Person, Zielbenutzer, System sowie Rolle/Berechtigung
  • Geschäftliche Begründung (Pflichtfreitext)
  • Automatisch zugewiesene genehmigende Person gemäß Ihrem Rollenmodell
  • Zeitlich begrenzter oder dauerhafter Zugriff
  • Endgültige Entscheidung mit Zeitstempeln

Moderne Leitlinien für IAM und IGA betonen die Protokollierung von Zugriffsanfragen und -genehmigungen als Teil der Umsetzung von ISO 27001 Anhang A 5.15 und als Kernevidenz für SOC 2 Kontrollen zur Zugriffskontrolle

Häufiger Fehler
Nur für "sensible" Systeme Genehmigungen zu protokollieren. Prüfer erwarten inzwischen denselben Standard für alles, was Kundendaten oder Finanzdaten berührt - nicht nur für Kernbankensysteme oder das Hauptbuch.

Schritt 6: Benutzer-Zugriffsüberprüfungen in kontinuierliche Governance verwandeln

Die meisten Teams führen jährliche Tabellen-Reviews durch, "weil die IT für SOC 2 oder ISO Benutzer-Zugriffsüberprüfungen braucht".

In der Praxis führen viele mittelständische Organisationen Benutzer-Zugriffsüberprüfungen nur einmal jährlich per Tabellenkalkulation durch, die an Führungskräfte gemailt wird, was zu Rechteaufblähung und Alibi-Genehmigungen führt

Das mag gerade noch durch die Prüfung kommen, hält aber selten stand, wenn Aufsichtsbehörden nach einem Vorfall kritisch nachfragen.

Streben Sie an:

  1. Risikobasierte Überprüfungshäufigkeit

    • Systeme mit hohem Risiko: vierteljährliche oder monatliche Benutzer-Zugriffsüberprüfungen
    • Mittleres Risiko: halbjährlich
    • Niedriges Risiko: jährlich oder nach größeren Organisationsänderungen

  2. Überprüfungen durch Fachverantwortliche, nicht durch IT

    • Die IT kann nicht wissen, ob Sarah in der Steuerabteilung weiterhin Exportrechte im Hauptbuch braucht.
    • Überprüfungen müssen an die Datenverantwortlichen gehen (z. B. Leiter Steuern, verantwortlicher Partner).

  3. Kontextreiche Oberflächen für Reviews

    • Für jeden Benutzer anzeigen:
      • Rolle, Abteilung, Vorgesetzte
      • Letzte Anmeldung und wesentliche Aktivitäten
      • Wann der Zugriff gewährt wurde und von wem
    • So werden aus "alles genehmigen"-Klicks echte Geschäftsentscheidungen.

  4. Automatisierte Workflows und Nachweise

    • Überprüfungen werden automatisch nach Plan gestartet
    • Ausbleibende Antworten werden eskaliert
    • Endgültige Entscheidungen werden unveränderlich und exportfähig protokolliert

Teams, die Benutzer-Zugriffsüberprüfungen und Nachweiserfassung automatisieren, sparen rund 120 Stunden pro Quartal für Compliance-Aufgaben und verbessern gleichzeitig ihre Prüfungsergebnisse

Tipp
Richten Sie die Überprüfungen an Ihrem geschäftlichen Takt aus: Quartalsabschluss, Prüfungsausschuss, interne Kontrollen - nicht an willkürlichen Kalenderdaten.

Schritt 7: Eine Prüfpfad-Architektur entwerfen, die wirklich trägt

Alle nicken zu "Prüfpfad", aber nur wenige definieren und implementieren ihn sauber.

Für regulierte Branchen reicht das Protokollieren von Anmeldungen nicht aus. Prüfer und Aufsichtsbehörden erwarten:

  • Umfassende Protokolle aller sicherheitsrelevanten Ereignisse
  • Manipulationsschutz (unveränderlich oder manipulationsoffenbar)
  • Aufbewahrungsregeln, die zu Recht und Geschäft passen
  • Datenschutzkontrollen für Protokolldaten (entscheidend unter DSGVO/UK GDPR)

ISO/IEC 27001:2022 Anhang A 8.15 verlangt von Organisationen, Protokollierung und Prüfpfade so umzusetzen, dass wesentliche Sicherheitsereignisse erfasst, Protokolle vor Manipulation geschützt und für festgelegte Zeiträume nach rechtlichen und geschäftlichen Erfordernissen aufbewahrt werden

7.1 Was protokolliert werden sollte

Mindestens für Systeme mit hohem Risiko:

  • Anmeldeereignisse (erfolgreich, fehlgeschlagen, MFA)
  • Änderungen von Rechten (Rollen/Berechtigungen)
  • Datenzugriffe auf sensible Objekte (Mandantenordner, Zahlungsläufe)
  • Administratorhandlungen (Konfigurationsänderungen, SoD-Übersteuerungen)

7.2 Wie Protokolle gespeichert werden sollten

  • Protokolle nach Möglichkeit in einem SIEM oder einem Security Data Lake zentralisieren
  • Für Identitätsereignisse die unveränderlichen Prüfprotokolle Ihrer Identity-Governance-Plattform nutzen, damit Administratoren die Historie nicht nachträglich verändern können
  • Erzeugung der Protokolle immer von deren Auswertung trennen

Unveränderliche oder manipulationssichere Prüfprotokollierung gilt inzwischen weithin als Best Practice für regulierte Branchen, in denen die rechtliche Belastbarkeit von Zugriffsaufzeichnungen entscheidend ist

7.3 Aufbewahrung und Datenschutz

  • Aufbewahrungsfristen festlegen:
    • Finanzsysteme: häufig 7+ Jahre (gemäß Gesetz und Prüferempfehlung)
    • Andere Systeme: 1-3 Jahre können ausreichen
  • Protokolle als personenbezogene Daten nach DSGVO/UK GDPR behandeln:
    • Zugriff auf Rohkennungen begrenzen
    • Zweckbindung und Datenminimierung beachten

Häufiger Fehler
Entweder "alles für immer protokollieren" (teuer, datenschutzkritisch) oder "den Standardeinstellungen vertrauen" (für Prüfungen meist unzureichend). Beide Ansätze brechen unter regulatorischer Prüfung zusammen.

Schritt 8: Compliance-Berichte automatisieren und Dokumentation "lebendig" halten

Wenn Sie Ihre Zugriffsdokumentation erst kurz vor der Prüfungswoche aktualisieren, sind Sie bereits im Rückstand.

Streben Sie lebende Dokumentation an - nur eine dünne Schicht über Ihren Echtzeit-Identitätsdaten.

Praktische Schritte:

  • Zentrale Sicht auf Identitäten und Zugriffe

    • Nutzen Sie Identity Governance (wie Iden), um Folgendes zu bündeln:
      • Benutzer (menschlich und nicht-menschlich)
      • Rollen und Berechtigungen
      • Zugriffe und SoD-Prüfungen
      • JML- und UAR-Ereignisse
    • Das wird faktisch zu Ihrem Standardnachweis für Prüfer.

  • Berichtsvorlagen pro Rahmenwerk

    • SOX: Zugriff auf Finanzsysteme, SoD-Konflikte, Benutzer-Zugriffsüberprüfungen
    • SOC 2: Abbildung auf CC6.*, Nachweise aller Provisionierungen/Deprovisionierungen/Überprüfungen
    • ISO 27001: Evidenzpakete für Anhang A 5.15/5.18 und 8.15

  • Agentische Workflows für Nachweise

    • KI-gestützte, autonome Workflows nutzen, um:
      • Zugriffsüberprüfungen zu starten und nachzuverfolgen
      • Quartalsweise Nachweise zusammenzustellen
      • verwaiste oder "Zombie"-Konten zur Bereinigung zu markieren

Automatisierte, richtliniengesteuerte Identitäts-Workflows reduzieren manuelle Zugangstickets um bis zu 80 % und ermöglichen schlanken IT-Teams, sich auf echten Geschäftsnutzen statt auf permanentes Compliance-Feuerlöschen zu konzentrieren

Tipp
Zugriffsdokumentation sollte wie ein Live-Dashboard überwacht werden, nicht wie ein einmal jährlich abzuhakendes Projekt. Wenn Ihre Dashboards gesund sind, wird die Prüfung selbst zur Formsache.

Nächste Schritte: Vom "Prüfungsstress" zur kontinuierlichen Sicherheit

In Finanzunternehmen oder professionellen Dienstleistungsfirmen zählen Mühe und Absicht wenig. Nachweisbare Kontrolle zählt.

Um vom Prüfungsstress zur belastbaren Sicherheit zu kommen:

  • Ihre 5-10 wichtigsten prüfungsrelevanten Systeme abbilden (Verantwortliche, Rollen, SoD, Vorschriften)
  • JML-Prozesse standardisieren, notfalls mit einer disziplinierten Checkliste
  • Zugriffsanfragen und -genehmigungen in einem Kanal bündeln
  • Automatisierte Reviews zunächst für ein System mit hohem Risiko pilotieren
  • Eine Prüfpfad-Architektur aufbauen, die auf Knopfdruck beantwortet: "Wer hat was wann getan?"

Wenn Sie Identitätslücken noch mit SSO, Tickets und Tabellenkasperle füllen, bewegen Sie sich im Gefahrenbereich. Iden schließt diese Lücke: vollständige Abdeckung (auch für Anwendungen ohne SCIM/APIs), fein granulare Steuerung und kontinuierliche, prüfungsreife Governance - gebaut für schlanke Teams, nicht für 30-köpfige IAM-Abteilungen.

FAQ: Prüfungssichere Zugriffsdokumentation in der Praxis

1. Wie oft sollten wir in regulierten Branchen Benutzer-Zugriffsüberprüfungen durchführen?

Es gibt keinen weltweiten Standard, aber klare Muster:

  • Hochrisiko-Finanzsysteme: vierteljährlich (oder häufiger, wenn Prüfer es verlangen)
  • Mittleres Risiko: halbjährlich
  • Niedriges Risiko: jährlich

SOX, SOC 2 und ISO 27001 schreiben keine exakten Frequenzen vor, erwarten aber "regelmäßige" und risikobasierte Überprüfungen; Aufsichtsbehörden stellen jährliche Reviews für Hochrisikosysteme zunehmend als zu selten infrage

Wenn Sie eine Bank, ein Wertpapierhaus oder ein börsennotiertes Unternehmen sind, setzen Ihre Prüfer die Messlatte - richten Sie Ihren Plan daran aus und automatisieren Sie ihn dann in Ihrer Identity-Plattform.

2. Was ist der "Minimum Viable" Prüfpfad für ein mittelständisches Finanz- oder Dienstleistungsunternehmen?

Für kritische Systeme sollten Sie abdecken:

  • Anmeldeereignisse (inklusive MFA)
  • Änderungen an Rollen/Berechtigungen
  • Administratoraktionen
  • Zugriffe auf Schlüsselobjekte (Buchungen posten, Mandantendaten ändern)

Zusätzlich:

  • Unveränderliche bzw. manipulationsoffenbare Protokollspeicherung
  • Klare Aufbewahrungsrichtlinien
  • Dokumentierte Verfahren zur Protokollauswertung

Wenn Sie nicht für ein Datum im letzten Jahr rekonstruieren können "wer was geändert hat und wer es genehmigt hat", haben Sie keinen belastbaren Prüfpfad.

3. Wie gehen wir in der Zugriffsdokumentation mit nicht-SCIM-fähigen, Legacy- oder Nischen-SaaS-Anwendungen um?

Genau hier scheitern Teams besonders häufig in Prüfungen.

Mögliche Ansätze:

  • Integration über universelle Konnektoren oder agentenbasierte Modelle (die Spezialität von Iden), sodass diese Anwendungen an Provisionierung, Reviews und Protokollierung teilnehmen.
  • Wenn das nicht möglich ist, mindestens:
    • Eine aktuelle Zugriffsliste pflegen und regelmäßig exportieren
    • Manuelle Reviews mit dokumentierter Freigabe durchführen
    • Lokale Administratoränderungen auf einen zentralen Änderungsdatensatz zurückführen

Aber klar ist: Manuelle Inseln sind die Orte, an denen Prüfungslücken, SoD-Verstöße und Vorfälle sich häufen.

4. Was ist der Unterschied zwischen "statischen Prüfungen" und "kontinuierlicher Governance"?

  • Statische Prüfungen sind Einzelereignisse: jährliche Reviews, Rezertifizierungen, Offboarding-Checklisten.
  • Kontinuierliche Governance bedeutet:
    • JML-Ereignisse werden automatisch verarbeitet und protokolliert
    • SoD-Konflikte werden bei jeder Zugriffsanfrage geprüft
    • Zugriffsüberprüfungen laufen nach Plan und reagieren auf Organisationsänderungen
    • Protokolle und Alarme sind an das Monitoring angebunden und melden Auffälligkeiten schnell

Statische Prüfungen reichen in regulierten Branchen mit permanenten Angriffsversuchen nicht mehr aus.

5. Wie beweisen wir Prüfern, dass unsere Zugriffsdokumentation vertrauenswürdig ist?

Prüfer achten auf Konsistenz und Nachvollziehbarkeit:

  • Zeigen, dass Ihre Dokumentation (Rollen, SoD, Genehmigungen) mit den realen Systemeinstellungen übereinstimmt
  • Belegen, dass jede Änderung (Gewährung, Entzug, Review) einen unveränderlichen Eintrag hinterlässt
  • Stichproben über längere Zeiträume liefern, nicht nur "den Export vom letzten Monat"

Wenn Sie:

  1. alle Benutzer mit einer sensiblen Rolle für beliebige Stichtage ziehen können,
  2. zeigen, wer dies genehmigt hat und wann,
  3. belegen, dass Ausgeschiedene den Zugriff zeitnah verloren haben,

... sind Sie vielen bereits voraus - und auf einem sehr guten Weg zu wirklich prüfungssicherer Zugriffsdokumentation.