IT-Teams im Finanzsektor bekommen keine "leichtgewichtigen" Audits.

SOC-2-Compliance steht neben SOX, PCI und lokalen Bankvorschriften. Wenn ein Prüfer fragt: "Wer hatte wann und warum Zugriff worauf?", reichen ein paar Okta-Screenshots nicht aus.

Hier ist eine praxisnahe Anleitung in fünf Schritten, um prüfungsreife Identity Governance aufzubauen:

  • SOC-2-Identitätskontrollen (CC6.x) auf Ihre Umgebung abbilden
  • Einheitliche, belegbare Prozesse für Bereitstellung und Entzug von Benutzerzugängen entwerfen
  • Least-Privilege-Zugriff für kritische Finanzsysteme durchsetzen
  • Zugriffsüberprüfungen so durchführen, dass Prüfer ihnen vertrauen
  • Governance-Nachweise im Voraus gebündelt bereitstellen

Diese Anleitung richtet sich an schlanke, überlastete IT-Teams im Finanzsektor. Das Ziel: kontinuierliche, prüfungsreife Identity Governance - ohne eine 20-köpfige IAM-Abteilung.

Bevor Sie starten: Voraussetzungen für SOC-2-fähiges Identity Management

Sie brauchen kein eigenes IAM-Team für SOC 2, aber ein solides Fundament.

Diese Punkte sollten vorbereitet oder im Aufbau sein, bevor Sie tiefer einsteigen:

  • Zentrale Identitätsquellen
    • HRIS als "Single Source of Truth" für Mitarbeitende und externe Kräfte
    • IdP/SSO (z. B. Okta, Entra ID) für Authentifizierung
  • Systeminventar
    • Listen Sie jede Anwendung auf, die Kunden-, Zahlungs-, Handels-, Hauptbuch- oder regulierte Daten verarbeitet
    • Benennen Sie Verantwortliche für jede kritische Anwendung (Salesforce, NetSuite, DocuSign, Kernbankensystem, Portfoliomanagement)
  • Grundlegende Richtlinienbasis
    • Übergeordnete Richtlinie zur Zugriffskontrolle (wer genehmigt was)
    • Dokumentierter Joiner/Mover/Leaver-(JML-)Prozess, auch wenn teilweise noch manuell
  • Ticket- oder Workflowsystem
    • Ein ITSM-Werkzeug (Jira, ServiceNow) oder eine Governance-Plattform wie Iden
  • Rückendeckung durch Führungskräfte
    • Security, IT und Compliance sind sich einig, dass SOC-2-Identitätskontrollen eine gemeinsame Priorität sind

Tipp
Wenn Ihr Systeminventar noch Lücken hat, beginnen Sie mit den führenden Systemen für Geld- und Kundendaten: Kernbankensystem, Handel, Hauptbuch, CRM, E-Signatur und Data Warehouses.

Schritt 1: SOC-2-Identitätskontrollen auf Ihren Finanz-Stack abbilden

Sie können nicht prüfungsbereit sein, wenn Sie nicht wissen, was Sie erfüllen müssen.

SOC-2-Berichte verwenden die AICPA Trust Services Criteria (TSC) für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz, ausgerichtet am internen Kontrollrahmen von COSO

Für Identität und Zugriff sind insbesondere folgende SOC-2-Kriterien relevant:

  • CC6.1 - Logische Zugriffssicherheit
    Zugriff auf Systeme und Daten durch Identifikation, Authentifizierung, MFA und Netzwerksegmentierung einschränken.
  • CC6.2 - Verwaltung des Kontolebenszyklus
    Sicheres Anlegen, Ändern und Entfernen von Konten für interne und externe Benutzer.
  • CC6.3 - Rollenbasierter Zugriff und Least Privilege
    Vergabe und Entzug von Rechten basierend auf Rolle, Least-Privilege-Prinzip und Funktionstrennung (SoD).SOC 2 CC6.1-CC6.3 fokussiert auf logische Zugriffskontrollen, Kontolebenszyklus-Management und rollenbasierten Zugriff mit Funktionstrennung

1.1 Eine Kontrolle-zu-System-Karte erstellen

Erstellen Sie eine einfache Tabelle (eine Tabellenkalkulation genügt):

  • Spalten: System, Datentyp, Owner, SOC 2 im Scope (J/N), CC6.x-Kontrollen, Weitere Rahmenwerke (SOX/PCI/usw.)
  • Zeilen: Jede im Scope befindliche Anwendung, insbesondere:
    • Kernbankensystem und Hauptbuch
    • Handels- und Portfolioplattformen
    • CRM (Salesforce)
    • E-Signatur (DocuSign)
    • Finanz-/ERP-System (NetSuite)
    • Data Warehouse/Analytics

Das ist Ihre Baseline für SOC-2-Identity-Governance.

1.2 Kritische Identitäts-Blindspots erkennen

Fragen Sie für jedes System:

  • Wird der Zugriff ausschließlich über SSO-Gruppen oder zusätzlich über lokale Rollen in der Anwendung gesteuert?
  • Haben nicht-menschliche Identitäten (Bots, Servicekonten) kritische Berechtigungen?
  • Sind direkte Logins (E-Mail + Passwort) möglich, die SSO umgehen?
  • Ist die Bereitstellung automatisiert, teilautomatisiert oder manuell?

Markieren Sie insbesondere folgende Punkte:

  • Manuelle Bereitstellung oder Entzug von Zugängen
  • Prozesse außerhalb der HR-gesteuerten JML-Flows
  • Steuerung über informelle Checklisten statt über definierte Workflows

Häufiger Fehler
"In Okta" mit "governed" gleichzusetzen. SOC 2 interessiert sich für den Zugriff je System - nicht nur dafür, wer sich anmelden kann. Lokale Admin-Rollen in Salesforce oder NetSuite sind entscheidend.

Schritt 2: Einen sauberen, belegbaren Prozess für Provisioning & Deprovisioning entwerfen

Prüfer wollen nicht nur sehen, was Sie tun, sondern belastbare Nachweise, dass Sie es jedes Mal tun.

Unter CC6.2 und CC6.3 wird ein dokumentierter Prozess für Joiner, Mover und Leaver über Ihren gesamten Stack erwartet.

2.1 Joiner-Flows (User Provisioning) standardisieren

Für jedes Schlüsselsystem:

  1. "Geburtsrecht"-Zugriffe definieren
    • Basiszugriff für alle Mitarbeitenden (E-Mail, Chat, HR-Portal)
    • Finanzspezifische Geburtsrechte (z. B. Controller vs. Front-Office)
  2. Rollenbasierten Zugriff definieren
    • Berufsrollen ("Trader", "Fondsbuchhalter", "Billing Specialist") auf Anwendungsrollen/-gruppen abbilden
    • SoD-Regeln festlegen (niemand darf Lieferantenzahlungen sowohl anlegen als auch freigeben)
  3. Den Workflow dokumentieren
    • Auslöser (typischerweise HRIS-Neueinstellungsereignis)
    • Genehmigende Person(en) (Führungskraft, Anwendungs-/Datenowner, Risiko/Compliance bei sensiblen Rechten)
    • Bereitstellungspfad (IdP-Gruppe, anwendungsspezifische Rolle, Skript oder Identity-Governance-Plattform wie Iden)

Tipp
Verlangen Sie für neue Rollen vorab eine SoD-Prüfung. Es ist deutlich einfacher, toxische Kombinationen ab Tag eins zu verhindern, als sie nach einem Audit-Befund zu korrigieren.

2.2 Teilweise Offboarding eliminieren (User Deprovisioning)

Teil-Offboarding ist einer der häufigsten - und gefährlichsten - Audit-Befunde.

Ihr Leaver-Prozess sollte sicherstellen, dass bei einem durch HR ausgelösten Austritt:

  1. Die primäre Identität sofort deaktiviert wird
    • Deaktivierung in HRIS und IdP
    • Sitzungen/Tokens nach Möglichkeit ungültig gemacht werden
  2. Alle nachgelagerten Zugriffe entzogen werden
    • Entfernung aus SSO-Gruppen und lokalen Rollen in den Anwendungen
    • Entfernung von Admin-Rollen, API-Schlüsseln und Verknüpfungen mit Servicekonten
  3. Der Zugriffsentzug protokolliert und prüfbar ist
    • Jeder Deprovisioning-Vorgang hinterlässt eine unveränderliche Prüfs pur: wer, welches System, wann, verwendeter Workflow

Iden automatisiert dies - vollständige Lebenszyklusautomatisierung, ausgelöst durch HRIS/IdP, mit Zero-Touch-Offboarding, auch in nicht-SCIM-Systemen.

Häufiger Fehler
"Okta deaktiviert = Benutzer ist weg" zu setzen. SOC-2-Prüfer schauen gezielt auf Systeme wie Salesforce und NetSuite. Wenn Ex-Mitarbeitende dort weiterhin Zugriff haben, ist das ein erhebliches Problem.

2.3 Mover und temporäre Zugriffe sauber regeln

Rollenwechsel und zeitlich befristete Berechtigungen sind typische Schwachstellen im Least-Privilege-Modell.

  • Nutzen Sie Change-Workflows - verzichten Sie auf spontane "Drive-by"-Adminänderungen
  • Erzwingen Sie zeitlich begrenzte Berechtigungen für erhöhte Rollen (Trades, Datenexporte, Produktionsfixes)
  • Verlangen Sie Begründungen für erhöhte Zugriffe und halten Sie diese im Audit-Log fest

Agentische, KI-gestützte Workflows (Iden) steuern dies in Echtzeit - sie bewerten Anfragen anhand von Richtlinie, SoD und Kontext und übernehmen autonome Bereitstellung und Entzug.

Schritt 3: Least Privilege und SoD in kritischen Finanzsystemen umsetzen

Prüfer konzentrieren sich auf Personen, die Geld bewegen oder Aufzeichnungen verändern können, nicht nur auf Logins.

SOC 2 CC6.3 verlangt, dass Zugriff entsprechend Rollen, Least-Privilege-Prinzip und Funktionstrennung genehmigt, geändert oder entzogen wird

3.1 Ihre "Kronjuwelen" identifizieren

Konzentrieren Sie sich auf Systeme, bei denen Missbrauch reale finanzielle oder aufsichtsrechtliche Schäden verursachen kann:

  • Hauptbuch-/ERP-Systeme
  • Zahlungs- und Treasury-Plattformen
  • Handels- und Order-Management-Systeme
  • Kundendaten/CRM
  • E-Signatur- und Vertragsplattformen

Ermitteln Sie für jedes System:

  • Unterschied zwischen Standardnutzer- und Admin-Fähigkeiten
  • Welche Aktionen Finanzberichterstattungsrisiken oder Kundenschäden verursachen können

3.2 Rollen für echtes Least Privilege entwerfen

Gehen Sie über grobe Rollen wie "User" und "Admin" hinaus. Definieren Sie etwa:

  • "Trade Viewer" vs. "Trade Executor" vs. "Trade Approver"
  • "Rechnungsersteller" vs. "Rechnungsfreigeber" vs. "Zahlungsfreigeber"
  • Beschränken Sie "Datenexport"-Rollen auf die tatsächlich zuständigen Teams

Verknüpfen Sie diese Rollen mit Aufgabenprofilen und verankern Sie sie in Ihren Provisioning-Workflows.

3.3 SoD und kompensierende Kontrollen aufbauen

Perfekte SoD ist schwierig - insbesondere für kleine Teams. Wenn sie nicht vollständig praktikabel ist, ergänzen Sie kompensierende Kontrollen im Sinne von CC6.3:

  • Vier-Augen-Prinzip für risikoreiche Aktionen (z. B. zwei Freigaben für hohe Auslandsüberweisungen)
  • Unabhängige Überprüfung von Admin-Protokollen
  • Regelmäßige Prüfungen kritischer Datenänderungen (z. B. Stammdaten von Lieferanten)

Tipp
Führen Sie eine Liste mit "verbotenen Kombinationen" (z. B. darf nicht zugleich Lieferanten anlegen und freigeben). Erzwingen Sie diese in Ihrem IGA oder über automatisierte Prüfungen. Prüfer schätzen so etwas sehr.

Schritt 4: Benutzerzugriffsprüfungen so betreiben, dass Prüfer ihnen vertrauen

Jährliche, statische Reviews reichen im Finanzsektor nicht aus.

Regulierte Branchen - Finanzwesen, Gesundheitswesen, öffentlicher Sektor - führen typischerweise vierteljährliche Benutzerzugriffsprüfungen für sensible Systeme durch
SOX erwartet vierteljährliche oder halbjährliche Zugriffsreviews für Systeme der Finanzberichterstattung

4.1 Den richtigen Prüfturnus festlegen

Empfehlung:

  • Vierteljährlich für zentrale Finanz- und Kundendatensysteme
  • Halbjährlich für mittelrisikobehaftete interne Werkzeuge
  • Jährlich für risikoarme/Read-only-Systeme

Dokumentieren Sie diesen Turnus und mappen Sie ihn auf SOC 2 CC6.x.

4.2 Reviews wirklich entscheidungsorientiert gestalten - statt Abnicken

Gestalten Sie Reviews so, dass echte Entscheidungen getroffen werden:

  • Leiten Sie Finanzsysteme an Systemverantwortliche oder direkte Führungskräfte - nicht nur an IT
  • Stellen Sie Kontext bereit: Rolle, letzter Login, Abteilung, Vorgesetzte/r, Begründung
  • Verlangen Sie explizite Aktionen: behalten, entfernen, herabstufen
  • Erfassen Sie Gründe für Ausnahmen ("Projekt bis 30.06.2026")

Eine leistungsfähige Governance-Plattform:

  • Führt unveränderliche Protokolle für alle Bestätigungen
  • Erzeugt Nachweispakete pro Kampagne
  • Entzieht bestätigten Entzugen automatisch die Rechte

Iden-Anwender sparen rund 120 Stunden pro Quartal bei Zugriffsreviews, indem sie Kampagnen automatisieren und Nachweise automatisch sammeln
Für ein dreiköpfiges IT-Team ist das der Unterschied zwischen Überleben und Überlastung in der Audit-Saison.

Häufiger Fehler
Manuelle "Tabellenkalkulation + E-Mail"-Reviews mit verspäteter Nachbearbeitung. Prüfer erwarten heute Closed-Loop-Reviews: Zertifizierungen führen direkt zu automatisierten Änderungen.

4.3 Nicht-menschliche Identitäten einbeziehen

Behandeln Sie Servicekonten, Bots und API-Schlüssel als Hochrisiko-Identitäten:

  • Weisen Sie Owner zu
  • Prüfen Sie ihre Reichweite (Anwendungen, Daten)
  • Nehmen Sie sie in regelmäßige Zugriffsreviews auf

Iden verwaltet alle Identitäten - menschlich und nicht-menschlich - an einem Ort für einheitliche, skalierbare Reviews.

Schritt 5: Ihr SOC-2-Identity-Governance-Nachweispaket aufbauen

Sie haben:

  1. SOC-2-Kontrollen den Systemen zugeordnet
  2. JML-Prozesse standardisiert
  3. Least Privilege und SoD verankert
  4. Zugriffsreviews operationalisiert

Jetzt bündeln Sie, was Prüfer sehen wollen.

5.1 Zentrale Unterlagen, die Prüfer erwarten

  • Richtlinie zur Zugriffskontrolle - Rollen, Genehmigungen, SoD, Review-Turnus
  • Prozesse für Provisioning/Deprovisioning - JML-Flows mit Diagrammen/Screenshots
  • Systeminventar - alle Systeme im Scope, Owner, Risiko, Kontrollzuordnungen
  • Verfahren für Zugriffsreviews - Turnus, Scope, Reviewer, Remediation-Prozess

5.2 Beweisartefakte

Für den Prüfzeitraum (typischerweise 12 Monate bei Typ-2-Berichten):

  • Nachweise zur Benutzerbereitstellung - Tickets/Workflow-Genehmigungen
  • Nachweise zum Deprovisioning - Belege für zeitnahe Entzüge
  • Kampagnen zu Zugriffsreviews - Entscheidungen und Nachbearbeitung
  • Rollen- & SoD-Dokumentation - Definitionen, Zuordnung zu Funktionen, "verbotene Kombinationen"
  • Log-Auszüge - aus IdP, Schlüsselsystemen und Governance-Plattform

Eine robuste Plattform exportiert unveränderliche Audit-Logs und Berichte in Minuten - nicht in Wochen.

SOC 2 fokussiert im Bereich Sicherheit auf logischen Zugriff, Kontoverwaltung und Durchsetzung des Least-Privilege-Prinzips als zentrale Kontrollen

5.3 Kompakte Compliance-Checkliste

Nutzen Sie diese Pre-Audit-Checkliste:

  • SOC-2-relevante Systeme CC6.x zugeordnet
  • JML-Flows definiert und umgesetzt
  • Geburtsrecht- und rollenbasierter Zugriff mit SoD-Regeln etabliert
  • Offboarding startet bei HR/IdP und entfernt alle lokalen Konten
  • Nicht-menschliche Identitäten inventarisiert und im Review
  • Regelmäßige Zugriffsreviews (vierteljährlich für Hochrisikosysteme)
  • Review-Ergebnisse inkl. Remediation protokolliert
  • Nachweispaket bereit (Richtlinien, Logs, Tickets, Kampagnen)

Tipp
Führen Sie ein internes "Mini-Audit" durch - wählen Sie 10 Benutzer und 3 kritische Systeme. Prüfen Sie mit Nachweisen, dass jeder Zugriff genehmigt, regelmäßig überprüft und beim Austritt entzogen wurde.

Wo Iden ins Bild passt

Sie können all dies mit Tabellenkalkulationen und Skripten erledigen - aber das skaliert nicht, insbesondere nicht im Finanzsektor.

Iden schließt diese Lücke:

  • Vollständige Abdeckung, nicht nur SCIM-Anwendungen
    Automatisiert Provisioning, Deprovisioning und Reviews über SaaS, Legacy- und nicht-SCIM/API-Umgebungen hinweg mittels universeller Konnektoren.Iden deckt über 175 Anwendungen ab und fügt schnell neue Konnektoren hinzu - inklusive Nischenwerkzeugen, die viele "moderne IGA"-Lösungen auslassen

  • Agentische, KI-gesteuerte Workflows
    Autonome, richtlinienbasierte Workflows übernehmen Routinezugriffe und Nachweiserstellung, sodass Sie sich nur um Ausnahmen kümmern müssen.

  • Kontinuierliche Governance und automatisierte Compliance
    Iden-Kunden haben manuelle Zugriffstickets um bis zu 80 % reduziert und sparen rund 120 Stunden pro Quartal bei Benutzerzugriffsreviews - entscheidend für schlanke IT-Teams unter SOC 2 und SOX

Für Finanz- oder Professional-Services-Teams mit 3-10 IT-Mitarbeitenden ist das der Unterschied zwischen Minimal-Compliance-Theater und echter, kontinuierlicher Governance.

Nächste Schritte für Ihr Team

Wenn Sie diesen Monat nur drei Dinge tun, dann diese:

  • Führen Sie einen Zugriffsreview für Ihr risikoreichstes Finanzsystem durch - mit Least-Privilege, SoD, kontextbezogenen Entscheidungen und Closed-Loop-Umsetzung.
  • Schließen Sie Offboarding-Lücken, sodass HR-Austritte automatisch zu IdP- und anwendungsseitigem Deprovisioning führen - einschließlich nicht-SCIM-Werkzeugen.
  • Zentralisieren Sie Identitätsnachweise (Tickets, Logs, Reviews), damit Ihr nächstes SOC 2 nicht im Screenshot-Marathon endet.

Wenn das Fundament steht, prüfen Sie, wie Identity-Governance-Plattformen wie Iden Sie ganzjährig SOC-2-ready halten können.

FAQ: SOC-2-Identity-Management im Finanzsektor

1. Worin unterscheidet sich SOC 2 von SOX in Bezug auf Identität und Zugriff?

SOC 2 bezieht sich auf Kontrollen von Dienstleistungsorganisationen: Sicherheit, Verfügbarkeit, Integrität, Vertraulichkeit, Datenschutz. Identitätskontrollen fallen unter Sicherheit (CC6.x). SOX fokussiert auf interne Kontrollen über die Finanzberichterstattung. SOC 2 ist breiter und umfasst üblicherweise mehr Systeme. Eine starke, an SOC 2 ausgerichtete Governance deckt einen Großteil von SOX für Finanzanwendungen mit ab.

2. Wie häufig sollten wir Benutzerzugriffsreviews durchführen?

Für den Finanzsektor sollten Sie planen:

  • Vierteljährlich für Systeme, die Finanzdaten oder Kundendaten betreffen
  • Halbjährlich für moderates Risiko
  • Jährlich für geringes Risiko/interne Werkzeuge

Prüfer achten vor allem auf Konsistenz und Nachweise - vierteljährlich für Schlüsselsysteme gilt als Standard.

3. Sind Tabellenkalkulationen für SOC-2-Zugriffsreviews ausreichend?

Technisch ja - wenn sie kontrolliert, versioniert und mit Nachweisen versehen sind. In der Praxis bedeuten Tabellen oft:

  • Abnick-Genehmigungen
  • Fehlender Kontext oder fehlende Begründungen
  • Manuelle Nachbearbeitung ohne Closed Loop

Prüfer erwarten strukturierte, wiederholbare Workflows und unveränderliche Nachweise. Automatisierung macht Compliance erreichbar, ohne die IT zu überlasten.

4. Brauchen wir ein dediziertes IAM-Team für SOC 2?

Nein. Viele Finanz- und Professional-Services-Unternehmen mit 100-1.000 Mitarbeitenden bestehen SOC-2-Audits mit schlanken IT- und Security-Teams. Entscheidend sind:

  • Klare Verantwortlichkeiten
  • Dokumentierte JML-Prozesse
  • Automatisierte oder streng gesteuerte Provisioning-, Deprovisioning- und Review-Prozesse

Plattformen wie Iden ermöglichen kleinen Teams vollständige Identity Governance - ohne zusätzliche IAM-Stellen.

5. Wie sollten wir Auftragnehmende und Servicekonten im Rahmen von SOC 2 behandeln?

Prüfer behandeln Auftragnehmende und nicht-menschliche Identitäten wie feste Mitarbeitende:

  • Onboarding/Offboarding von Auftragnehmenden mit denselben JML-Prozessen und festen Enddaten
  • Zuweisung von Ownern für Servicekonten/API-Schlüssel; Verknüpfung mit konkreten Use Cases; regelmäßige Überprüfung
  • Einbezug in Zugriffsreviews und Nachweiserhebung

Die Vernachlässigung dieser Identitäten führt häufig zu Auditversagen - insbesondere im Finanzsektor, in dem Automatisierung und Drittparteien oft ein hohes Risiko bedeuten.