Von Excel-Listen zu kontinuierlicher Zertifizierung: Ein 90-Tage-Plan für Access-Reviews

Jedes Quartal läuft dasselbe Ritual ab. Jemand exportiert zehntausende Zeilen mit Berechtigungen in eine Excel-Tabelle, verschickt sie per E-Mail an hundert Manager und wartet. ^[1] Die Manager, ohnehin schon unter Deadlines begraben, tun das einzig Rationale: Alles markieren -> Genehmigen. Die Tabelle kommt zu 95 % grün zurück. Der Compliance-Haken wird gesetzt. Und nichts hat sich wirklich verändert.

Das ist kein Personalproblem. Es ist ein strukturelles - und es wird immer schwieriger, es vor Auditoren zu verbergen.

In einer SailPoint-Studie aus dem Jahr 2024 gaben 58 % der Identity-Verantwortlichen an, dass ihre Access-Reviews wirkungslos seien, während 42 % erklärten, die Reviewer hätten nicht genug Kontext für fundierte Entscheidungen. ^[2] Das ist kein Governance-Programm. Das ist Governance-Theater.

Die gute Nachricht: Sie brauchen kein 12-monatiges Transformationsprojekt, um das zu beheben. Ein fokussierter 90-Tage-Plan - aufgeteilt in drei Phasen - kann Sie vom manuellen Spreadsheet-Chaos zu einer kontinuierlichen, revisionssicheren Zertifizierung führen, die einem Auditor im Jahr 2026 standhält. Hier ist genau, wie das geht.

Access Reviews in der Praxis

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

---

Warum Spreadsheet-Reviews scheitern (und warum Auditoren es bemerken)

Bevor es zum Plan geht, lohnt es sich, präzise zu benennen, warum der aktuelle Ansatz versagt. Es gibt nicht einen, sondern vier strukturelle Schwachstellen.

1. Sie sind punktuell - veraltet, bevor die Tinte trocken ist

Eine Tabelle erfasst einen einzelnen Moment und ist sofort überholt. In SaaS-Umgebungen ändern sich Zugriffsrechte kontinuierlich. ^[3] In dem Moment, in dem Sie die Daten exportieren, wird jemand befördert, ein Projekt eines externen Mitarbeiters endet oder ein Entwickler erhält Zugriff auf ein sensibles Repository. Wenn die Reviewer die Zertifizierung abgeschlossen haben, spiegelt der Datensatz die Realität längst nicht mehr wider. Die Reviewer bestätigen einen Geisterzustand.

2. Sie produzieren Stempel, keine Entscheidungen

Studien zeigen konsistent, dass Reviewer bei Zertifizierungskampagnen über 95 % der Zugriffsrechte genehmigen - im Durchschnitt verbringen sie weniger als 10 Sekunden pro Entscheidung. ^[1] Wenn ein Manager 200 Berechtigungszeilen ohne Nutzungsdaten, ohne Vergleichswerte und ohne Risikokontext vor sich hat, kann er keine sinnvolle Entscheidung treffen. Also trifft er keine. Er genehmigt alles, um die Deadline einzuhalten. ^[4] Das Ergebnis ist eine Zertifizierung, die eine Abschlussquote erfüllt, aber das tatsächliche Zugriffsrisiko in keiner Weise reduziert.

3. Sie erfassen nicht den Nicht-SCIM-Bereich - wo das eigentliche Risiko lauert

Die meisten IGA-Tools verwalten die Apps, die SCIM sprechen. Aber weniger als 7 % der Anwendungen unterstützen SCIM, was bedeutet, dass der weitaus größte Teil Ihres Stacks - Notion, Figma, Linear, interne Tools, Legacy-Systeme - vollständig außerhalb der automatisierten Governance liegt. ^[5] Diese Apps werden über Flat-File-Uploads, gemeinsam genutzte Admin-Konsolen und quartalsweise Tabellen verwaltet, denen niemand vertraut. ^[6] Dort häufen sich verwaiste Konten an, und dort landen Audit-Findings.

4. Sie liefern schwache Audit-Belege

Tabellen können zeigen, dass jemand auf "Genehmigen" geklickt hat - aber sie können nicht beweisen, dass Systeme diese Änderungen tatsächlich umgesetzt haben. ^[3] Es gibt keinen unveränderlichen Zeitstempel, keinen Remediation-Trail, keine Verknüpfung zwischen der Entscheidung und der nachgelagerten Aktion. Im Jahr 2026 erwarten Auditoren zunehmend, dass Organisationen nachweisen können, dass ihre Access-Governance-Prozesse kontinuierlich, dokumentiert und durchsetzbar sind - punktuelle Beweiserhebung reicht für die meisten Audit-Engagements nicht mehr aus. ^[7] Eine Tabelle mit einer Genehmigungsquote von 96 % ist kein solcher Nachweis.

---

Der 90-Tage-Plan

Die drei Phasen unten sind bewusst in dieser Reihenfolge angeordnet. Sie können nicht zertifizieren, was Sie nicht sehen. Sie können nicht automatisieren, was Sie nicht definiert haben. Und Sie können nicht auf kontinuierliche Governance umstellen, bevor Sie bewiesen haben, dass das periodische Modell funktioniert.

Phase 1: Tage 0-30 - Ein vollständiges Berechtigungsinventar aufbauen

Sie können keinen Zugriff zertifizieren, von dem Sie nicht wissen, dass er existiert. Die ersten 30 Tage drehen sich ausschließlich um Transparenz - und zwar vollständige Transparenz, nicht nur den SCIM-freundlichen Ausschnitt Ihres Stacks.

Was zu tun ist:

• Verbinden Sie Ihre Identity-Quellen. Ziehen Sie Daten aus Ihrem HRIS und IdP, um eine einzige verlässliche Quelle dafür zu schaffen, wer existiert, welche Rolle diese Person hat und wann sie eingetreten ist, die Stelle gewechselt oder das Unternehmen verlassen hat.
• Inventarisieren Sie jede App - nicht nur SCIM-Apps. Erfassen Sie Ihre gesamte Applikationslandschaft: SCIM-verbundene Apps, API-verbundene Apps und den langen Schwanz der Apps, die beides nicht unterstützen. Das ist der Schritt, den die meisten Teams überspringen - und genau dort entstehen Audit-Findings. Weniger als 4 % der Organisationen haben ihre zentralen Identity-Workflows vollständig automatisiert; die verbleibenden 96 % sind auf menschenzentrierte Prozesse angewiesen, die schwer skalierbar und fehleranfällig sind. ^[8] Die Nicht-SCIM-Apps in dieser Lücke sind Ihre risikoreichsten blinden Flecken.
• Normalisieren Sie Berechtigungen. Rohe Berechtigungsexporte aus SaaS-Apps sind oft technische Bezeichner, die Business-Reviewer nicht interpretieren können. Übersetzen Sie diese in verständliche Beschreibungen mit Risikoklassifizierungen, bevor ein Review beginnt.
• Weisen Sie Verantwortliche zu. Jede App braucht einen Owner - entweder einen technischen App-Owner oder einen fachlichen Daten-Owner -, der für die Zertifizierung des Zugriffs verantwortlich ist. Weisen Sie nicht alles standardmäßig den direkten Vorgesetzten zu; ein Marketing-Manager kann Datenbankberechtigungen nicht sinnvoll beurteilen.

Was zu messen ist:

• Gesamtzahl der Apps im Scope vs. Apps mit aktiver Governance-Abdeckung
• Anteil der normalisierten und risikoklassifizierten Berechtigungen
• Anteil der Apps mit einem namentlich bestätigten Owner

Häufige Falle: Teams, die bei ihren SSO-verbundenen Apps aufhören, erklären den Sieg bei 30-40 % Abdeckung. ^[9] Die anderen 60-70 % - die Tools, die Ihre Engineering-, Finance- und Operations-Teams täglich nutzen - bleiben ungeregelt. Genau dort wartet der nächste Sicherheitsvorfall oder das nächste Audit-Finding.

---

Phase 2: Tage 31-60 - Kampagnen definieren, Workflows automatisieren, Belege erfassen

Mit einem vollständigen Berechtigungsinventar können Sie Ihre ersten strukturierten Zertifizierungskampagnen durchführen. Das Ziel ist hier nicht Perfektion - es geht darum, das Spreadsheet-Ritual durch einen wiederholbaren, revisionssicheren Prozess zu ersetzen.

Was zu tun ist:

• Stufen Sie Reviews nach Risiko ab. Nicht jeder Zugriff verdient dieselbe Review-Frequenz. Privilegierter Zugriff, Admin-Rollen und Zugriff auf sensible Daten sollten monatlich oder bei jeder Rollenänderung überprüft werden. Standard-SaaS-Zugriff kann quartalsweise geprüft werden. Risikoarmer, lesender Zugriff kann halbjährlich überprüft werden. ^[10] Die Frequenz am tatsächlichen Risiko auszurichten ist das, was Governance von Compliance-Theater unterscheidet.
• Automatisieren Sie Reviewer-Workflows. Leiten Sie Kampagnen an den richtigen Reviewer weiter - App-Owner für technische Berechtigungen, Daten-Owner für sensible Daten, Vorgesetzte für Standard-Zugriff - mit vorausgefülltem Kontext: Zeitpunkt der Zugriffsvergabe, letztes Nutzungsdatum, Peer-Vergleich und Risiko-Flag. Das ist die wirksamste Einzelmaßnahme gegen Rubber-Stamping. ^[1]
• Erfassen Sie unveränderliche Genehmigungsnachweise. Jede Entscheidung - Genehmigen, Entziehen, Eskalieren - muss mit Zeitstempel versehen, einer Person zugeordnet und in einem unveränderlichen Audit-Log gespeichert werden. Die Entscheidung und die nachgelagerte Durchsetzungsmaßnahme müssen verknüpft sein. ^[11] Auditoren müssen nachvollziehen können, wer den Zugriff geprüft hat, welche Entscheidungen getroffen wurden, wann Zertifizierungen abgeschlossen wurden und ob entzogener Zugriff tatsächlich entfernt wurde.
• Beginnen Sie mit der Behandlung von Versetzungen. Rollenänderungen sind eine der häufigsten Quellen von Privilege Creep. Wenn jemand von Engineering zu Sales wechselt, sollte der GitHub-Repository-Zugriff nicht mitgenommen werden. Bauen Sie Mover-Workflows auf, die innerhalb von 48 Stunden nach einer HRIS-Aktualisierung eine gezielte Re-Zertifizierung der geänderten Berechtigungen auslösen.

Was zu messen ist:

• Kampagnen-Abschlussquote (Ziel: >95 %)
• Durchschnittliche Zeit pro Entscheidung (Reviewer mit <5 Sekunden pro Eintrag markieren)
• Entzugsrate (ein gesundes Programm entzieht 5-15 % der geprüften Zugriffsrechte)
• Zeit von der Entzugsentscheidung bis zur Durchsetzung im Zielsystem

Häufige Falle: Reviewer-Ermüdung. Über 75 % der Organisationen räumen ein, dass Rubber-Stamping ein erhebliches Problem bei ihren Access-Review-Prozessen darstellt. ^[1] Das Gegenmittel sind nicht mehr Erinnerungen - sondern kleinere Batches, besserer Kontext und das Hervorheben nur der Anomalien, die tatsächlich eine menschliche Entscheidung erfordern. Begrenzen Sie Review-Sitzungen auf 10-15 Einträge. Markieren Sie die Ausreißer. Lassen Sie die Automatisierung die offensichtlichen Genehmigungen übernehmen.

---

Phase 3: Tage 61-90 - Auf kontinuierliche, ereignisgesteuerte Zertifizierung umstellen

Periodische Kampagnen sind eine Untergrenze, keine Obergrenze. Das Ziel von Phase 3 ist der Wechsel von geplanten Reviews zu ereignisgesteuerter Zertifizierung - bei der Zugriffsrechte immer dann neu bewertet werden, wenn sich etwas Wesentliches ändert, und nicht erst, wenn der Kalender es vorgibt.

Was zu tun ist:

• Zertifizierungen durch Identity-Events auslösen. Ein New Hire, eine Rollenänderung, ein Projektabschluss, das Vertragsende eines externen Mitarbeiters - jedes dieser Ereignisse sollte automatisch eine gezielte Zertifizierung der betroffenen Berechtigungen auslösen. Damit wird die Lücke zwischen Review-Zyklen geschlossen, in der sich Privilege Creep still ansammelt.
• Entzüge automatisch umsetzen. Wenn ein Reviewer einen Zugriff entzieht, sollte die Durchsetzungsmaßnahme automatisch und sofort erfolgen - nicht über ein Ticket, das drei Tage in einer Queue liegt. Für Apps mit direkten Konnektoren bedeutet das eine Deprovisionierung in Echtzeit. Für Nicht-SCIM-Apps bedeutet es einen automatisierten Workflow, der die Änderung ausführt und das Ergebnis protokolliert.
• Revisionssichere Berichte auf Abruf generieren. Bis Tag 90 sollten Sie in der Lage sein, die Frage "Wer hat Zugriff auf was, und seit wann?" in Minuten zu beantworten - nicht in Wochen. ^[11] Ihr Audit-Belegspaket sollte enthalten: ein vollständiges Berechtigungsinventar mit Zeitstempeln, eine Kampagnenhistorie mit jeder Review-Entscheidung und ihrem Ergebnis, ein Remediation-Log, das Entscheidungen mit Durchsetzungsmaßnahmen verknüpft, und ein Ausnahmeregister für jeden Zugriff, der trotz Risiko-Flags genehmigt wurde.
• Den Nicht-SCIM-Bereich schließen. Kontinuierliche Zertifizierung funktioniert nur, wenn sie Ihren gesamten Stack abdeckt. Für Apps ohne SCIM oder APIs bedeutet das den Einsatz einer Plattform mit universeller Konnektoren-Abdeckung - einer, die Notion, Figma, Linear und Ihre internen Tools mit derselben Sorgfalt verwalten kann wie Okta-verbundene Apps.

Was zu messen ist:

• Mittlere Zeit vom Identity-Event bis zum Abschluss der Zertifizierung (Ziel: <48 Stunden für Hochrisiko, <7 Tage für Standard)
• Anteil der automatisch umgesetzten Entzüge vs. manuell erstellter Tickets
• Anzahl verwaister Konten (sollte gegen null tendieren)
• Abrufzeit für Audit-Belege (Ziel: <30 Minuten für jedes angeforderte Artefakt)

Häufige Falle: Kontinuierliche Zertifizierung als "erledigt" zu deklarieren, während der Nicht-SCIM-Bereich weiterhin auf Spreadsheets basiert. ^[5] Die Apps, die keine Identity-Standards unterstützen, sind kein Randfall - sie sind eine dauerhafte Haftung. Ihre Resistenz gegenüber Automatisierung schafft die Governance-Lücken, die in Sicherheitsvorfalluntersuchungen und Audit-Findings auftauchen, oft lange nachdem der Zugriff hätte entfernt werden sollen.

---

Wie ein gutes Ergebnis an Tag 90 aussieht

Nach 90 Tagen sieht ein reifes Programm so aus:

---

Die 90-Tage-Checkliste

---

Das grundlegende Problem, das die meisten Pläne nicht lösen

Es gibt einen Grund, warum die meisten 90-Tage-Pläne in Phase 2 ins Stocken geraten: Sie verwalten nur die Apps, die ihre IGA-Plattform erreichen kann. Wenn Ihre Plattform bei SCIM aufhört, haben Sie Governance für einen Bruchteil Ihres Stacks automatisiert und den Rest auf Spreadsheets belassen - das bedeutet, Sie haben ein kontinuierliches Zertifizierungsprogramm mit einer eingebauten Abdeckungslücke von 60-70 % aufgebaut.

Die Regulierungsrahmen geben keine Teilpunkte. Regulatorische Compliance-Frameworks wie SOX, HIPAA, DSGVO, ISO 27001, NIS2 und DORA schreiben kontinuierliche, periodische und gut dokumentierte Access-Reviews vor. ^[12] Ein Auditor, der fragt "Wer hat Zugriff auf Ihre Finanzdaten?", akzeptiert "Wir verwalten die SCIM-Apps" nicht als Antwort. Er will das vollständige Bild - einschließlich der Tools, die Ihr Finance-Team täglich nutzt und die nie eine Provisioning-API gebaut haben.

Genau diese Lücke wurde Iden entwickelt, um sie zu schließen. Universelle Konnektoren-Abdeckung - SCIM, API oder keines von beidem - bedeutet, dass Ihr kontinuierliches Zertifizierungsprogramm tatsächlich Ihr kontinuierliches Risiko abdeckt. Nicht nur die einfachen 30 %.

Wenn Sie auf Ihren nächsten SOC 2 Type II, eine ISO 27001-Überwachungsaudit oder eine DORA-Compliance-Deadline hinarbeiten, gibt Ihnen der obige 90-Tage-Plan die Struktur. Die Frage ist, ob Ihr Tooling ihn über Ihren gesamten Stack hinweg umsetzen kann.