Ihr Auditor möchte Ihre Zugriffskontroll-Richtlinie nicht lesen. Er möchte sehen, dass sie funktioniert - mit Zeitstempel, Unterschrift und lückenloser Nachvollziehbarkeit über alle Systeme hinweg, auf die Ihre Mitarbeitenden zugreifen.

Diese Lücke zwischen "wir haben eine Richtlinie" und "hier sind die Belege" ist der Punkt, an dem die meisten ISO 27001- und SOC 2-Audits ins Stocken geraten. Findings häufen sich nicht, weil Organisationen keine Controls haben, sondern weil sie die Artefakte nicht vorweisen können, die belegen, dass diese Controls über einen längeren Zeitraum konsistent angewendet wurden. [1] ist genau deshalb eine so große Herausforderung: Controls, die keine Belege in einem akzeptablen Format - mit Zeitstempeln - erzeugen, bringen Teams in den Tagen vor einem Audit in Bedrängnis.

Dieses Playbook bildet jeden Identity-Artefakt ab, den ein Auditor verlangen wird - kontrollweise, für ISO 27001:2022 Annex A und SOC 2 Common Criteria (CC6). Für jeden Artefakttyp beschreiben wir, wie ein starkes Beleg-Paket aussieht und wo manuelle Ansätze scheitern.

Die Framework-Übersicht: ISO 27001 Annex A ↔ SOC 2 CC6

Bevor wir uns den Artefakten widmen, lohnt es sich zu verstehen, welche Controls Sie gleichzeitig erfüllen. [2] überschneiden sich erheblich: Die Belege, die für SOC 2 CC6.1 und ISO 27001 Annex A 5.15 erforderlich sind, sind weitgehend identisch - dokumentierte Zugriffskontroll-Richtlinien, Nachweise über regelmäßige User-Access-Reviews und Logs, die eine zeitnahe Deprovisionierung belegen. Für ein Audit erstellte Belege können direkt für das andere wiederverwendet werden.

ISO 27001:2022 Annex A enthält 93 Controls in vier Kategorien: Organisatorisch, Personenbezogen, Physisch und Technologisch. Der Zugriffskontroll-Cluster umfasst A.5.3 (Aufgabentrennung), A.5.15 (Zugriffskontrolle), A.5.16 (Identity Management), A.5.18 (Zugriffsrechte) und A.8.2 (Privilegierte Zugriffsrechte). Auf SOC-2-Seite regelt [3] alles von der logischen Zugriffsarchitektur bis hin zur Verwaltung von SSH-Keys. CC6 und CC7 zusammen machen 68 % der Ausnahmen in qualifizierten SOC-2-Berichten aus.

Generating image…

Die 8 Identity-Artefakt-Kategorien - und was Auditoren tatsächlich verlangen

1. User-Access-Review- / Zertifizierungsnachweise

ISO 27001 Controls: A.5.15, A.5.18 | SOC 2 Kriterien: CC6.3

[4] Bestandslisten (alle User mit Zugriff), Genehmigungsnachweise für die Provisionierung, regelmäßige Access-Reviews und der Nachweis, dass ausgeschiedene User zeitnah ihren Zugriff verlieren.

Was der Auditor fragt: "Zeigen Sie mir Ihren letzten Access-Review. Wer hat ihn durchgeführt, wann wurde er abgeschlossen, und welche Zugriffsrechte wurden infolgedessen entzogen?"

Wie starke Belege aussehen:

  • Datierte Review-Berichte mit namentlich genannten Reviewern und deren Freigabe (nicht nur ein Häkchen)
  • Ein Nachweis darüber, was sich geändert hat - entzogene Zugriffsrechte, beibehaltene Zugriffsrechte mit Begründung
  • Zeitstempel, die belegen, dass der Review innerhalb des vorgeschriebenen Rhythmus abgeschlossen wurde
  • [2], die vom Auditor stichprobenartig auf operative Wirksamkeit geprüft werden

ISO 27001:2022 schreibt vor, dass privilegierte Zugriffsrechte mindestens alle 6 Monate überprüft werden müssen; SOC 2 legt keine Häufigkeit fest, erwartet aber regelmäßige Reviews mit dokumentierten Ergebnissen. [5] deckt beide Frameworks ab und ist in jedem Audit-Kontext vertretbar.

Das Warnsignal für Auditoren: Ein Review, bei dem niemand seinen Zugriff verloren hat. [6] - das signalisiert, dass der Review ein reines Durchwinken war und keine echte Kontrolle.

2. Joiner-Mover-Leaver (JML) Provisionierungs- und Deprovisionierungs-Logs

ISO 27001 Controls: A.5.15, A.5.16 | SOC 2 Kriterien: CC6.2

[7] verlangt einen formalen Prozess für die eindeutige Identifizierung und Registrierung von Usern, einschließlich der sofortigen Entziehung von Zugriffsrechten bei Beendigung des Arbeitsverhältnisses.

Was der Auditor fragt: "Zeigen Sie mir, was beim letzten Austritt einer Person passiert ist. Führen Sie mich durch die Belege."

Wie starke Belege aussehen:

  • [7] (z. B. Jira/ServiceNow) mit Zeitstempeln für die Erstellung und den Entzug von Zugriffsrechten
  • Abgleich aktueller Abgänge mit Listen aktiver Konten - [8]
  • Mover-Nachweise, die belegen, dass alte Berechtigungen bei Rollenwechseln entfernt wurden und nicht nur neue hinzugekommen sind
  • Belege, die den gesamten Applikations-Stack abdecken - nicht nur SSO-verbundene Apps

Das Warnsignal für Auditoren: [7]. Verwaiste Konten sind der häufigste identitätsbezogene Befund bei Compliance-Audits.

3. Berichte über Aufgabentrennung (Segregation of Duties, SoD)

ISO 27001 Controls: A.5.3, A.8.2 | SOC 2 Kriterien: CC6.3

[9]. Die klassische toxische Kombination: Dieselbe Person, die Zugriff beantragt, genehmigt ihn auch. Oder der Entwickler, der Code schreibt, deployt ihn auch in die Produktionsumgebung.

Was der Auditor fragt: "Zeigen Sie mir Ihre SoD-Matrix. Zeigen Sie mir, dass die Person, die Zugriff beantragt, ihn nicht auch genehmigen kann."

Wie starke Belege aussehen:

  • Eine definierte Matrix konfliktierender Rollen (z. B. Entwickler vs. Release Manager), versioniert und aktuell
  • RBAC-Konfigurationsexporte, die die technische Durchsetzung der Rollentrennung belegen
  • [9]
  • Für kleine Teams: dokumentierte Ausnahmen mit kompensierenden Controls (z. B. erweitertes Logging, unabhängige Management-Überprüfung) und die Begründung, warum eine vollständige Trennung nicht umsetzbar ist

Das Warnsignal für Auditoren: [10]. Eine Richtlinie, die besagt "alle Zugriffsanfragen werden von einer separaten autorisierten Person genehmigt", bricht in dem Moment zusammen, in dem ein Auditor drei aktuelle Tickets nachverfolgt und feststellt, dass der IT-Manager seine eigenen Anfragen genehmigt hat.

4. Nachweise für privilegierte Zugriffsrechte

ISO 27001 Controls: A.8.2 | SOC 2 Kriterien: CC6.3

[5]. Die Absicht ist framework-übergreifend einheitlich.

Was der Auditor fragt: "Zeigen Sie mir Ihre Liste privilegierter User. Zeigen Sie mir die Genehmigung für jeden einzelnen. Zeigen Sie mir den letzten Review."

Wie starke Belege aussehen:

  • [11]
  • [11]
  • [11]
  • Session-Logs oder PAM-Aufzeichnungen für sensible Operationen
  • Nachweis, dass privilegierte Logs dort gespeichert werden, wo der privilegierte User sie nicht bearbeiten kann - [12]

Das Warnsignal für Auditoren: Die ISO-27001-Anforderung, privilegierte Zugriffsrechte alle 6 Monate zu überprüfen, wird häufig nicht eingehalten, weil Organisationen privilegierte und reguläre Access-Reviews zusammenfassen und dann jährlich durchführen.

5. Least-Privilege- / Berechtigungsnachweise

ISO 27001 Controls: A.5.15, A.5.18 | SOC 2 Kriterien: CC6.1, CC6.3

[8] für alle Entitäten - Mitarbeitende, Auftragnehmer, Service-Accounts und automatisierte Prozesse.

Was der Auditor fragt: "Zeigen Sie mir Ihr RBAC-Modell. Wie stellen Sie sicher, dass User nur den Zugriff haben, den sie für ihre aktuelle Rolle benötigen?"

Wie starke Belege aussehen:

  • [7]
  • Nachweis, dass Zugriff rollenbasiert und nicht auf persönliche Anfrage gewährt wird
  • Berechtigungsberichte, die aktuelle Berechtigungen im Vergleich zur Rollen-Baseline zeigen - mit Hervorhebung überprivilegierter Konten
  • Nachweise, dass bei einem Rollenwechsel alte Berechtigungen entzogen wurden (und nicht nur neue hinzugekommen sind)

Das Warnsignal für Auditoren: [8] - gehört zu den häufigsten Befunden, die Auditoren aufdecken.

6. Berichte über verwaiste und inaktive Konten

ISO 27001 Controls: A.5.16 | SOC 2 Kriterien: CC6.2

[8] - sind für die meisten Monitoring-Tools unsichtbar und ideal für Angreifer.

Was der Auditor fragt: "Zeigen Sie mir die Liste der User in Ihrem Active Directory. Zeigen Sie mir jetzt Ihre HR-Austrittsliste der letzten 90 Tage. Vergleichen wir beides."

Wie starke Belege aussehen:

  • Regelmäßige Berichte über verwaiste Konten, abgeglichen mit HRIS-Austrittsdaten
  • Berichte über inaktive Konten (Konten ohne Login-Aktivität seit 30/60/90 Tagen) mit Dispositionsnachweisen
  • Nachweis, dass entdeckte verwaiste Konten bereinigt wurden - nicht nur identifiziert
  • [13], mit Nachweis, dass Identitäten bei Abgängen zeitnah deaktiviert wurden

7. Nachweise für nicht-menschliche Identitäten / Service-Accounts

ISO 27001 Controls: A.5.16, A.8.2 | SOC 2 Kriterien: CC6.1, CC6.3

Service-Accounts, API-Keys, CI/CD-Tokens und Automatisierungs-Credentials sind der blinde Fleck in den meisten Identity-Programmen - und Auditoren wissen das.

Was der Auditor fragt: "Wie stellen Sie sicher, dass dieser spezifische API-Key nur für Datensicherungen verwendet wird? Wer ist verantwortlich? Wann wurde er zuletzt überprüft?"

Wie starke Belege aussehen:

  • [14] (z. B. AWS IAM, Azure RBAC)
  • Ein Inventar aller nicht-menschlichen Identitäten (NHIs) mit namentlich genannten menschlichen Verantwortlichen
  • Nachweis, dass Service-Accounts dem Least-Privilege-Prinzip folgen - [14]
  • Review-Nachweise, die belegen, dass Service-Accounts regelmäßig rezertifiziert werden und nicht nur erstellt und vergessen werden
  • [5] - sie benötigen einen Abkündigungs-Zeitplan, nicht nur einen Ausnahmevermerk

8. Zugriffsanfrage- und Genehmigungs-Trail

ISO 27001 Controls: A.5.15, A.5.18 | SOC 2 Kriterien: CC6.2, CC6.3

[15].

Was der Auditor fragt: "Zeigen Sie mir eine Stichprobe einer Zugriffsanfrage aus den letzten 90 Tagen. Wer hat sie gestellt, wer hat sie genehmigt, wann wurde sie erfüllt?"

Wie starke Belege aussehen:

  • [16]
  • Zeitstempel in jeder Phase - Anfrage, Genehmigung, Provisionierung
  • Nachweis, dass Antragsteller und Genehmiger unterschiedliche Personen sind (SoD)
  • Nachweise, die den gesamten Applikations-Stack abdecken, einschließlich Apps ohne native Ticketing-Integrationen

Das Warnsignal für Auditoren: [8] - niemand kann nachvollziehen, was genehmigt wurde oder von wem.

Warum Excel-Listen den Audit-Belege-Test nicht bestehen

Manuelle und tabellenbasierte Ansätze scheitern bei Auditoren in drei konkreten Dimensionen:

Keine unveränderlichen Zeitstempel. [17]. Ein Auditor kann eine Excel-Liste nicht als Nachweis akzeptieren, dass ein Control an einem bestimmten Datum ausgeführt wurde - sie könnte rückdatiert oder bearbeitet worden sein. [18].

Lücken und Veralterung. [17]. [19]. Ein SOC 2 Type II Audit deckt 6-12 Monate Betrieb ab; eine Excel-Liste, die in der Woche vor dem Audit aktualisiert wurde, deckt davon nichts ab.

Abdeckungslücken. Manuelles Offboarding über 40+ SaaS-Apps am Tag, an dem jemand das Unternehmen verlässt, ist ohne Automatisierung operativ nicht möglich. [5] - und so häufen sich verwaiste Konten an. Apps ohne SCIM oder native API-Integrationen sind für eine tabellenbasierte Governance schlicht unsichtbar.

warning Warning

The SOC 2 Type 2 trap: A policy document is necessary but not sufficient. Operational evidence is required. Type 2 means the auditor will sample actual authentication events, access reviews, and deprovisioning records from across the entire audit period — not just the week before the audit.

Wie automatisierte, unveränderliche Belege aussehen

Der Goldstandard - [16] - liefert unwiderlegbare Nachweise für eine zeitnahe Entziehung von Zugriffsrechten und erfüllt damit direkt CC6.2 und A.5.15.

Eine automatisierte IGA-Plattform erzeugt generell Belege, die manuelle Ansätze strukturell nicht liefern können:

  • Unveränderliche Provisionierungs-Logs mit Akteur, Zeitstempel, Genehmiger und System - zum Zeitpunkt der Aktion generiert, nicht im Nachhinein rekonstruiert
  • Kontinuierliche Zugangszertifizierungen, die in einem definierten Rhythmus laufen, die Freigabe des Reviewers erfassen und dokumentieren, was sich infolgedessen geändert hat
  • Stack-übergreifende Abdeckung einschließlich Apps ohne SCIM oder APIs - damit das Beleg-Paket die gesamte Umgebung abdeckt, nicht nur die SSO-verbundene Ebene
  • Berichte über verwaiste und inaktive Konten, die automatisch gegen Live-HRIS-Daten generiert werden, anstatt vor jedem Audit manuell zusammengestellt zu werden
  • SoD-Konflikterkennung, die toxische Rollenkombinationen in Echtzeit markiert, nicht erst im Nachhinein
  • Nicht-menschliches Identitätsinventar mit Verantwortlichen, Datum der letzten Überprüfung und Berechtigungsumfang - jederzeit exportbereit

Genau das ist es, wofür Idens agentische IGA-Plattform entwickelt wurde. Mit universeller App-Abdeckung - einschließlich Apps ohne SCIM oder APIs - schließt Iden die Beweislücke, die SSO-only- und manuelle Ansätze für Auditoren weit offen lassen. Jede Provisionierungsaktion, jeder Access-Review und jedes Deprovisionierungsereignis wird mit unveränderlichen Zeitstempeln und Reviewer-Freigabe protokolliert und ist auf Abruf für einen Auditor bereit.

Einen tieferen Einblick in die Strukturierung Ihres ISO-27001-Programms von Grund auf finden Sie in unserem Schritt-für-Schritt-Leitfaden für Ihr erstes ISO 27001 2022. Für die SOC-2-spezifische Identity-Architektur lesen Sie unseren Schritt-für-Schritt-Leitfaden für SOC-2-konforme Identity.

Interaktiv: Erstellen Sie Ihre Beweislücken-Analyse

Nutzen Sie dieses Tool, um zu ermitteln, welche Artefakt-Kategorien Sie abgedeckt haben, welche unvollständig sind und welche fehlen - und erhalten Sie eine priorisierte Aktionsliste.

Die druckfertige Audit-Belege-Checkliste

Drucken Sie diese aus, teilen Sie sie mit Ihrem Team und nutzen Sie sie als Checkliste für Ihr Audit-Belege-Paket. Jeder Punkt ist den ISO-27001- und SOC-2-Controls zugeordnet, die er erfüllt.

Audit-Belege-Artefakt ISO 27001 Control SOC 2 Kriterien Mindeststandard
Access-Review-Berichte mit Reviewer-Freigabe und Zeitstempeln A.5.15, A.5.18 CC6.3 Vierteljährlich; namentlich genannter Reviewer; Änderungen dokumentiert
JML-Provisionierungs-Logs (Joiner) A.5.15, A.5.16 CC6.2 Mit Zeitstempel; Genehmiger namentlich genannt; rollenbasiert
JML-Deprovisionierungs-Logs (Leaver) A.5.15, A.5.16 CC6.2 Entzug am selben Tag; alle Systeme abgedeckt
Mover-Nachweise (Rollenwechsel) A.5.15, A.5.18 CC6.2 Alte Berechtigungen entzogen; neue Berechtigungen begründet
SoD-Konfliktmatrix + Durchsetzungsnachweise A.5.3, A.8.2 CC6.3 Technische Durchsetzung + operative Belege
Inventar privilegierter Zugriffsrechte + Genehmigungsnachweise A.8.2 CC6.3 Namentlich genannte Verantwortliche; 6-Monats-Review-Rhythmus
Privilegierte Session- / Aktions-Logs A.8.2 CC6.3 Unveränderlich; außerhalb der Reichweite von Admins gespeichert
Least-Privilege- / RBAC-Berechtigungsbericht A.5.15, A.5.18 CC6.1, CC6.3 Rollen-zu-Berechtigungs-Mapping; überprivilegierte Konten markiert
Bericht über verwaiste Konten + Bereinigungsnachweise A.5.16 CC6.2 Abgeglichen mit HRIS; Dispositionen protokolliert
Bericht über inaktive Konten (30/60/90 Tage) A.5.16 CC6.2 Regelmäßiger Rhythmus; Bereinigung dokumentiert
Inventar nicht-menschlicher Identitäten / Service-Accounts A.5.16, A.8.2 CC6.1, CC6.3 Namentlich genannte Verantwortliche; Least-Privilege; regelmäßiger Review
Zugriffsanfrage- und Genehmigungs-Trail A.5.15, A.5.18 CC6.2, CC6.3 Antragsteller ≠ Genehmiger; vollständige Stack-Abdeckung
lightbulb Tip

Dual-framework efficiency: Evidence prepared for ISO 27001 Annex A 5.15 can be directly reused for SOC 2 CC6. If you're pursuing both certifications, build your evidence package once and map it to both frameworks. Strategic integration of both frameworks through a unified approach can reduce audit burden by up to 40%.

Der Unterschied zwischen einem sauberen Audit und einem mit vielen Findings liegt fast immer an der Qualität der Belege, nicht an der Absicht hinter den Controls. Richtlinien sind das Minimum. Was Auditoren tatsächlich prüfen, ist, ob Ihre Controls konsistent ausgeführt wurden, unveränderliche Aufzeichnungen erzeugt haben und Ihre gesamte Umgebung abdecken - einschließlich der 30 SaaS-Apps, die nicht in Ihrem SSO sind.

Das ist die Lücke, die Iden schließt: vollständige Identity Governance über Ihren gesamten Stack, mit einem automatisierten Audit-Trail, der bereit ist, bevor der Auditor fragt.