Der User Access Review: Schritt-für-Schritt-Anleitung + kostenloses Template

User Access Reviews sind Pflicht für SOC 2, ISO 27001 und Co. - aber manuell kaum zu stemmen. Diese Anleitung zeigt, wie Sie Reviews strukturiert durchführen, Zombie-Accounts eliminieren und Audit-Nachweise automatisch generieren.

9 Min. Lesezeit · Zuletzt aktualisiert August 2026

Irgendwo in Ihrer SaaS-Landschaft gibt es gerade einen Account, der seit Monaten inaktiv ist. Sein Besitzer hat das Unternehmen längst verlassen - aber der Zugang zu GitHub, Notion oder Salesforce existiert noch. Kein Ticket, keine Revocation, kein Audit-Trail. Nur eine offene Tür.

Laut einer Analyse von Adallom haben 80 % der überwachten Unternehmen mindestens einen ehemaligen Mitarbeiter, dessen Zugangsdaten nicht deaktiviert wurden. Das ist kein Einzelfall - das ist der Normalzustand in SaaS-schweren Umgebungen, in denen Onboarding schnell geht, Offboarding aber oft im Ticket-Chaos untergeht.

Der User Access Review (UAR) ist das Gegenmittel. Dieser Leitfaden zeigt Ihnen, wie Sie einen Review strukturiert aufsetzen, welche Identitäten wirklich erfasst werden müssen - inklusive Non-Human Identities - und wie Sie aus einem manuellen Spreadsheet-Prozess ein kontinuierliches, audit-fähiges Governance-Programm machen.

Access Reviews in der Praxis

Kurz gezeigt: Wie eine Zugangszertifizierung abläuft, die Reviewer tatsächlich abschließen - inklusive revisionssicherer Belege.

Was ist ein User Access Review - und warum ist er Pflicht?

Ein User Access Review ist ein formaler Prozess, bei dem systematisch geprüft wird, wer Zugriff auf welche Systeme hat und ob diese Berechtigungen noch zur aktuellen Rolle passen. Das Ergebnis: eine dokumentierte Entscheidung - Zugang bestätigen, anpassen oder entziehen.

Rund 60 % der Datenpannen gehen auf übermäßige Berechtigungen durch Privilege Creep zurück - die schleichende Anhäufung von Zugriffsrechten, die nie widerrufen werden, wenn sich Rollen ändern.

Die Compliance-Anforderungen sind eindeutig:

SOC 2 (Trust Services Criteria CC6.1-CC6.3): Nachweis, dass Zugriffsrechte regelmäßig überprüft und angepasst werden.
ISO 27001 (Annex A, Control A.9.2.5 / A.5.18): Asset-Owner müssen Zugriffsrechte in geplanten Intervallen überprüfen - mit dokumentierten Nachweisen.
PCI DSS (Requirement 7.2.5): Mindestens halbjährliche Reviews für Cardholder-Data-Umgebungen.
NIST SP 800-53 (AC-2): Periodische Access Reviews, Frequenz abhängig von der Risikoklassifizierung des Systems.

ISO 27001:2022 und PCI DSS 4.0 verlangen, dass privilegierter Zugriff mindestens alle sechs Monate überprüft wird; PCI DSS fordert für Vendor-Zugriffe sogar ein Quartal.

SOC 2 schreibt keine feste Frequenz vor, erwartet aber periodische Reviews mit dokumentierten Ergebnissen. Auditors akzeptieren jährliche Reviews für Standard-User zunehmend nicht mehr als ausreichend. Quartalsweise Reviews für privilegierte Accounts gelten als Industriestandard.

Die häufigsten Fehler beim manuellen Review

Bevor wir in die Schritte einsteigen: Verstehen Sie, warum der Status quo scheitert.

Teams ohne Access-Review-Software verbringen laut Branchenberichten bis zu 48 Stunden pro Review-Zyklus mit manueller Datenpflege. Iden-Kundendaten bestätigen das: Durchschnittlich 120 Stunden pro Quartal gehen für manuelle Access Reviews drauf - für SOC 2 und ISO 27001 zusammen.

Die typischen Probleme:

Unvollständige Abdeckung: Nur SCIM-fähige Apps werden erfasst. Der Rest des Stacks - Notion, Figma, Linear, Slack-Channels, GitHub-Repos - bleibt blind.
Spreadsheet-Chaos: Exports aus verschiedenen Admin-Konsolen, manuell zusammengeführt, ohne Zeitstempel, ohne Audit-Trail.
Reviewer-Stau: Manager bestätigen Zugriffe, ohne den Kontext zu kennen. Rubber-stamping statt echter Prüfung.
Non-Human Identities vergessen: Service Accounts, API-Keys, Bot-Accounts - sie tauchen in keiner Spreadsheet-Zeile auf.
Keine Remediation-Nachverfolgung: Widerrufene Zugriffe werden nicht konsequent umgesetzt oder dokumentiert.

Laut einer 2025 Studie übersteigen Non-Human Identities menschliche Accounts im Durchschnitt um Faktor 82 zu 1 - und werden selten mit derselben Sorgfalt überprüft.

Schritt-für-Schritt: Der strukturierte User Access Review

Schritt 1: Scope definieren - wen und was Sie reviewen

Legen Sie fest, welche Systeme und Identitäten in diesem Review-Zyklus erfasst werden. Orientieren Sie sich an Risikoklassen:

Kategorie	Beispiele	Empfohlene Frequenz
Kritische Systeme / Privileged Access	Produktionsdatenbanken, Identity Provider, Cloud-Root-Accounts	Quartalsweise
Sensitive SaaS-Apps	GitHub, Salesforce, Jira, Slack	Quartalsweise bis halbjährlich
Standard-SaaS	Notion, Figma, Linear, Miro	Halbjährlich
Non-Human Identities	Service Accounts, API-Keys, Bot-Accounts	Quartalsweise (privilegiert: monatlich)
Externe Nutzer / Contractors	Vendor-Accounts, Freelancer	Quartalsweise

Wichtig: Schließen Sie Non-Human Identities explizit ein. Service Accounts umgehen MFA, laufen 24/7 mit persistentem Zugriff und haben oft Admin-Rechte - ein ideales Angriffsziel. Weisen Sie jedem Machine Account einen menschlichen Owner zu.

Schritt 2: Daten sammeln - vollständig, nicht nur SCIM

Exportieren Sie für jede App im Scope:

Alle aktiven User-Accounts (inkl. Guests, Contractors, Service Accounts)
Zugewiesene Rollen und Berechtigungen (so granular wie möglich: Channel-, Repo-, Projekt-Ebene)
Letzter Login / Last-Activity-Datum
Account-Erstellungsdatum und zugehöriger Business-Owner

Das Problem bei manuellen Exports: Viele Apps liefern keine vollständigen Daten über Standard-Exports. Apps ohne SCIM oder API - und das sind in den meisten Stacks die Mehrheit - erfordern manuelle Screenshots oder Admin-Konsolen-Zugriff. Genau hier entstehen Lücken.

Priorisieren Sie bei der Datenbeschaffung: Beginnen Sie mit den Systemen, die Auditors zuerst fragen werden – Identity Provider, Cloud-Plattformen, Code-Repositories und Finanzsysteme. Dann erst Long-Tail-SaaS.

Schritt 3: Reviewer zuweisen - mit klarer Verantwortung

Definieren Sie, wer welche Entscheidungen trifft:

Standard-Accounts: Direkter Manager des Users - er kennt die aktuelle Rolle am besten.
Privilegierter Zugriff (Admin, Prod-Umgebungen): Duales Approval - Manager und Security Team oder System Owner.
Service Accounts / API-Keys: Team Lead oder Engineering Manager, der die Integration verantwortet.
Externe Nutzer / Vendors: Interner Sponsor des Vendor-Engagements.

Setzen Sie klare Deadlines. Ohne Deadline ist ein Review-Request eine E-Mail, die im Postfach versinkt.

Schritt 4: Review durchführen - drei mögliche Entscheidungen

Für jeden Account gibt es genau drei Optionen:

Certify / Bestätigen: Zugriff ist korrekt und notwendig. Dokumentiert mit Zeitstempel und Reviewer-Name.
Modify / Anpassen: Zugriff ist zu weit gefasst. Berechtigungen werden auf das Minimum reduziert (Least Privilege).
Revoke / Entziehen: Zugriff ist nicht mehr gerechtfertigt. Account wird deaktiviert oder gelöscht.

Achten Sie auf diese Hochrisiko-Signale:

Letzter Login vor mehr als 90 Tagen -> Zombie-Account-Kandidat
Admin-Rechte ohne dokumentierten Business Case
Contractor-Account nach Projektende
Service Account ohne zugewiesenen Owner
Berechtigungen, die über die aktuelle Rolle hinausgehen (Privilege Creep)

Schritt 5: Remediation umsetzen und dokumentieren

Jede Revoke- oder Modify-Entscheidung muss umgesetzt und nachverfolgt werden. Manuell bedeutet das: IT loggt sich in jede App einzeln ein, entzieht den Zugriff, dokumentiert die Aktion im Ticket-System.

Bei 50 Widerrufen über 20 Apps bedeutet das manuell 8 bis 12 Stunden reine Umsetzungsarbeit.

Dokumentieren Sie für jede Remediation:

Welcher Account wurde geändert / deaktiviert
Wann (Zeitstempel)
Von wem (IT-Mitarbeiter)
Auf Basis welcher Reviewer-Entscheidung

Schritt 6: Audit-Nachweise sichern

Am Ende des Review-Zyklus brauchen Sie ein vollständiges Evidence-Paket:

Liste aller reviewten Accounts mit Entscheidung (Certify / Modify / Revoke)
Zeitstempel jeder Entscheidung
Name des Reviewers
Nachweis der umgesetzten Remediation
Ausnahmen mit Begründung

Auditors bei SOC 2 und ISO 27001 wollen sehen: Wer hat was überprüft, was wurde geändert, und wie schnell wurden Probleme behoben.

Non-Human Identities: Der blinde Fleck im Access Review

Die meisten UAR-Prozesse fokussieren auf menschliche Accounts. Das ist ein strukturelles Problem.

Laut Microsoft werden weniger als 5 % der Berechtigungen, die Non-Human Identities gewährt werden, tatsächlich genutzt - aber über die Hälfte gilt als hochriskant. In Cloud-Umgebungen sind 99 % der Service Accounts über-provisioniert, viele auf Admin-Niveau.

Service Accounts folgen keinem normalen Employee Lifecycle. Sie werden von Entwicklern, Cloud-Teams oder Vendoren erstellt, laufen jahrelang, werden geteilt und haben oft breiten Zugriff, weil jemand eine Integration schnell zum Laufen bringen musste. Wenn das Projekt endet, bleibt der Account.

Checkliste für Non-Human Identity Reviews:

Vollständiges Inventar aller Service Accounts, API-Keys, Bot-Accounts, Automation-Credentials
Jedem Account ist ein menschlicher Owner zugewiesen
Business Purpose und technischer Scope sind dokumentiert
Berechtigungen entsprechen dem Least-Privilege-Prinzip
Credentials werden nach definiertem Zeitplan rotiert
Inaktive Accounts (kein Activity-Log seit 90+ Tagen) werden deaktiviert
Privilegierte Machine Accounts werden separat und häufiger reviewt
Temporäre Zugänge haben ein Ablaufdatum

Vom periodischen Review zur kontinuierlichen Governance

Ein quartalsweiser Review ist der Mindeststandard. Aber er hat eine strukturelle Schwäche: Zwischen zwei Review-Zyklen können Wochen vergehen, in denen ein Zombie-Account unentdeckt bleibt oder ein überprivilegierter Service Account als Einfallstor dient.

Angreifer können SaaS-Applikationen in weniger als 9 Minuten kompromittieren und mit der Datenexfiltration beginnen. Ein quartalsweiser Review-Zyklus ist kein Schutz gegen Angriffe, die in Minuten eskalieren.

Die Antwort ist kontinuierliche Access Governance: Policy-gesteuerte Workflows, die Zugriffsänderungen in Echtzeit erkennen, automatisch Zertifizierungskampagnen auslösen und Audit-Nachweise als Built-in-Output generieren - nicht als nachträgliche Dokumentationsaufgabe.

Das bedeutet konkret:

Event-getriggerte Reviews: Offboarding, Rollenänderung, Contractor-Engagement-Ende -> sofortiger Review, nicht beim nächsten Quartalszyklus.
Continuous Monitoring: Abweichungen von der definierten Policy werden sofort gemeldet, nicht erst beim nächsten Audit.
Zero Standing Privilege: Privilegierter Zugriff wird zeitgebunden vergeben (Just-in-Time), nicht dauerhaft.
Automatische Remediation: Widerrufene Zugänge werden direkt über die Plattform entzogen - mit Zeitstempel als Audit-Nachweis.

Wo manuelle Reviews und SCIM-only-Tools scheitern

Das eigentliche Problem vieler Teams: Sie reviewen nur, was sie sehen können. Und sie sehen nur, was SCIM-fähig ist.

Das durchschnittliche Unternehmen verwaltet rund 106 SaaS-Apps - aber nur ein Bruchteil davon unterstützt SCIM nativ. Der Rest des Stacks - Notion, Figma, Linear, Miro, branchenspezifische Tools - bleibt in den meisten IGA-Lösungen ein blinder Fleck. Auditors fragen nach diesen Apps trotzdem.

Iden schließt genau diese Lücke. Die Plattform verbindet sich mit jeder App im Stack - ob SCIM, API oder keines von beidem - und liefert granulare Kontrolle bis auf Channel-, Repo- und Projekt-Ebene. Kein Enterprise-Plan-Upgrade erforderlich, kein SCIM-Tax.

Das Ergebnis: Access Reviews, die wirklich den gesamten Stack abdecken. Policy-gesteuerte Workflows, die Onboarding, Rollenänderungen und Offboarding automatisch über alle Systeme hinweg umsetzen. Und Audit-Nachweise, die als Built-in-Output entstehen - nicht als 120-Stunden-Quartalsprojekt.

Das kostenlose UAR-Template

Nutzen Sie diese Struktur als Ausgangspunkt für Ihren nächsten Review-Zyklus. Kopieren Sie die Tabelle in Ihre bevorzugte Spreadsheet-Lösung oder importieren Sie sie in Ihr IGA-Tool.

Häufige Fragen zum User Access Review

help_outlineWie oft muss ein User Access Review durchgeführt werden?expand_more

Die Frequenz hängt von der Risikoklasse ab. Privilegierte Accounts und kritische Systeme sollten quartalsweise reviewt werden (SOC 2, PCI DSS, NIST 800-53 AC-6). Standard-User-Accounts mindestens jährlich (ISO 27001, HIPAA). ISO 27001:2022 und PCI DSS 4.0 verlangen für privilegierten Zugriff mindestens halbjährliche Reviews. Quartalsweise Reviews für alle Access-Typen decken alle gängigen Frameworks ab und sind in jedem Audit-Kontext vertretbar.

help_outlineMüssen Non-Human Identities in den Access Review einbezogen werden?expand_more

Ja – und das wird von Auditors zunehmend explizit geprüft. ISO 27001 Control A.9.2.5 verlangt die Überprüfung aller Zugriffsrechte, einschließlich Service Accounts. Non-Human Identities sollten in einem separaten Review-Strang mit eigener Frequenz (quartalsweise für privilegierte Machine Accounts) behandelt werden.

help_outlineWas ist Privilege Creep und wie verhindert man ihn?expand_more

Privilege Creep bezeichnet die schleichende Anhäufung von Berechtigungen, die nie widerrufen werden, wenn sich Rollen ändern. Mitarbeiter sammeln über Jobwechsel, Projekte und Abteilungswechsel Zugriffsrechte an, die sie nicht mehr benötigen. Gegenmaßnahmen: regelmäßige Access Reviews, event-getriggerte Reviews bei Rollenänderungen, Least-Privilege-Policies und automatische Deaktivierung inaktiver Accounts.

help_outlineWelche Audit-Nachweise brauche ich für SOC 2 und ISO 27001?expand_more

Auditors erwarten: eine vollständige Liste der reviewten Accounts mit Entscheidung (Certify/Modify/Revoke), Zeitstempel jeder Entscheidung, Name des Reviewers, Nachweis der umgesetzten Remediation für alle Revoke-Entscheidungen sowie Dokumentation von Ausnahmen mit Begründung. Spreadsheet-basierte Nachweise werden akzeptiert, sind aber fehleranfällig und schwer zu skalieren.

help_outlineWas ist der Unterschied zwischen einem Access Review und einer Access Certification?expand_more

Die Begriffe werden oft synonym verwendet. Technisch bezeichnet 'Access Review' den Prozess der Überprüfung, 'Access Certification' die formale Bestätigung (Attestierung) durch einen autorisierten Reviewer. In IGA-Plattformen ist eine Certification Campaign der strukturierte Workflow, der Reviewer benachrichtigt, Entscheidungen erfasst und Audit-Nachweise generiert.

Fazit: Review ist kein Projekt - es ist ein Prozess

Ein User Access Review, der einmal im Jahr als Compliance-Pflichtübung durchgeführt wird, schützt Sie nicht. Er schützt Sie auch nicht, wenn er nur die SCIM-fähigen Apps erfasst und den Rest des Stacks ignoriert.

Echter Schutz entsteht durch kontinuierliche Governance: vollständige Abdeckung aller Apps, granulare Kontrolle auf Berechtigungsebene, automatische Remediation und Audit-Nachweise als Built-in-Output - nicht als nachträgliche Dokumentationsarbeit.

Wenn Ihr Team heute noch 120 Stunden pro Quartal in manuelle Spreadsheet-Reviews investiert, ist das keine Governance. Das ist Schadensbegrenzung.

Iden ist in ~24 Stunden live - ohne Enterprise-Plan-Upgrades, ohne dediziertes IAM-Team, ohne SCIM-Tax. Vollständige Coverage, granulare Kontrolle, sofortiger Time-to-Value.