Die 25-Fragen-IGA-RFP-Checkliste: Abdeckungslücken erkennen, bevor Sie unterschreiben
Eine sofort einsetzbare 25-Fragen-IGA-RFP-Checkliste in 8 Abschnitten. Jede Frage ist darauf ausgelegt, die Lücken aufzudecken, die reine SCIM-Lösungen und Legacy-Systeme lieber im Verborgenen lassen - mit Bewertungshinweisen für jede Antwort.
10 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Die meisten IGA-Demos sehen überzeugend aus. Die Workflows sind sauber, die Dashboards poliert, und Compliance-Berichte werden in Sekunden generiert. Das Problem: Eine Demo ist eine kontrollierte Umgebung - Ihr Stack ist es nicht.
57 % der Unternehmen geben an, dass die hohen Kosten für professionelle Integrationsdienstleistungen ein wesentliches Hindernis bei der Umsetzung ihrer IGA-Implementierung darstellen. [1] Nur 15 % der Unternehmen haben mehr als 80 % ihrer Applikationen in ihre Identity-Governance-Plattform integriert. [1] Die Lücke zwischen "was der Anbieter uns gezeigt hat" und "was unseren Stack tatsächlich absichert" ist genau dort, wo das Zugriffsrisiko entsteht.
Diese Checkliste soll diese Lücke schließen, bevor Sie unterschreiben. Kopieren Sie sie in Ihr RFP. Bewerten Sie jede Anbieterantwort anhand der Hinweise. Die Fragen sind bewusst neutral formuliert - aber sie sind darauf ausgelegt, die Schwachstellen aufzudecken, die reine SCIM-Lösungen und Legacy-Tools lieber erst im siebten Monat der Implementierung sichtbar werden lassen, nicht im ersten Monat der Evaluierung.
Einen Überblick darüber, wie Anbieter in diesen Dimensionen abschneiden, finden Sie in unserem [2] und dem [3].
Abschnitt 1: Applikationsabdeckung & Konnektoren
F1. Stellen Sie eine Liste der Applikationen in unserem Stack bereit, die Sie heute unterstützen. Geben Sie für jede an, ob die Integration SCIM, eine proprietäre API oder einen anderen Mechanismus verwendet.
Starke Antwort: Der Anbieter ordnet Ihre spezifische Applikationsliste zu - keinen generischen Katalog - und unterscheidet klar zwischen SCIM- und Nicht-SCIM-Konnektoren. Vage Verweise auf "Tausende von Integrationen" ohne konkrete Angaben sind ein Warnsignal.
F2. Was leistet Ihre Plattform für Applikationen in unserem Stack, die keinen SCIM-Endpunkt haben? Erläutern Sie das anhand eines konkreten Beispiels.
Starke Antwort: Der Anbieter beschreibt einen konkreten alternativen Mechanismus (direkte API, RPA, UI-Automatisierung) mit einem namentlich genannten Beispiel. "Das müssten wir erst scopen" oder "wir würden einen individuellen Konnektor entwickeln" bedeutet für Sie manuellen Aufwand oder PS-Kosten.
F3. Welcher Prozentsatz unseres aktuellen Applikationsbestands wäre ab Tag eins vollständig automatisiert - und welcher erfordert manuelle Provisionierung oder eine spätere Phase?
Starke Antwort: Ein konkreter Prozentsatz mit einer nachvollziehbaren Methodik. Die SCIM-Abdeckung erreicht typischerweise nur 15-25 % des SaaS-Stacks eines Unternehmens, wenn die Kosten für Enterprise-Upgrades eingerechnet werden. [4] Jeder Anbieter, der vollständige Abdeckung behauptet, ohne den Long Tail zu adressieren, verdient kritische Nachfragen.
F4. Setzen einige Ihrer Konnektoren voraus, dass die Zielapplikation auf einem Enterprise- oder Premium-Pricing-Tier läuft? Nennen Sie diese konkret.
Starke Antwort: Eine transparente Liste. Die meisten SaaS-Anbieter sperren SCIM hinter Enterprise-Tarifen, wobei Upgrades die Kosten pro Applikation um das 3- bis 10-Fache erhöhen können - nur um die Provisionierung freizuschalten. [4] Ein Anbieter, der diese Frage nicht klar beantworten kann, gibt diese Kosten an Sie weiter.
F5. Wie gehen Sie mit der Konnektor-Wartung um, wenn ein SaaS-Anbieter seine API oder Benutzeroberfläche ändert? Wer ist verantwortlich, und welches SLA gilt für die Wiederherstellung eines defekten Konnektors?
Starke Antwort: Der Anbieter übernimmt die Wartung mit einem definierten SLA (z. B. 48-72 Stunden für kritische Konnektoren). Individuelle oder fragile Konnektoren, die lautlos ausfallen, sind ein häufiger versteckter Kostenfaktor bei Legacy-Deployments.
Abschnitt 2: Joiner-Mover-Leaver & das Mover-Problem
F6. Wenn ein Mitarbeiter die Rolle wechselt - zum Beispiel von Sales zu Engineering - beschreiben Sie genau, was mit seinen bestehenden Zugriffen passiert. Werden sie automatisch entzogen, zur Überprüfung markiert oder einfach übernommen?
Starke Antwort: Bestehende Zugriffe werden auf Basis von Richtlinien / Policies automatisch markiert oder entzogen - nicht standardmäßig übernommen. "Zugriffe werden übernommen und in einer Review-Kampagne geprüft" ist die Antwort, die langfristig zu Zugriffsakkumulation führt.
F7. Wie geht Ihre Plattform mit partiellen Rollenwechseln um - zum Beispiel wenn ein User das Team wechselt, aber eine Legacy-Projektzuweisung beibehält?
Starke Antwort: Feingranulare Zugriffskontrolle, die bestimmte Berechtigungen erhalten und andere entziehen kann - mit einem revisionssicheren Approval-Trail. Binäre Joiner/Leaver-Logik, die keine Nuancen abbilden kann, ist ein Mover-Problem, das nur auf seinen Moment wartet.
F8. Wie lange dauert es im Durchschnitt zwischen einem HR-Austrittsereignis und der vollständigen Zugriffsrevokation über alle verbundenen Applikationen?
Starke Antwort: Nahezu in Echtzeit (Minuten, nicht Stunden) mit einem dokumentierten SLA. 87 % der Unternehmen sind trotz verfügbarer Automatisierungstools noch immer auf manuelle Prozesse für zentrale IGA-Aufgaben angewiesen. [1] Verzögertes Offboarding gehört zu den häufigsten Audit-Feststellungen.
F9. Wie erkennt und behebt Ihre Plattform verwaiste Konten - also Konten, die in Applikationen existieren, aber keine entsprechende aktive Identität in Ihrer HR- oder IdP-Quelle haben?
Starke Antwort: Automatisierte Erkennung und Abgleich nach einem definierten Zeitplan, mit Belegen für die Behebung. Manuelle Abgleichprozesse oder quartalsweise Flat-File-Vergleiche sind in größeren Umgebungen nicht ausreichend.
Abschnitt 3: Access-Reviews & Zugangszertifizierungen
F10. Beschreiben Sie die Reviewer-Erfahrung bei einer Access-Review-Kampagne. Welche Informationen sieht ein Manager, und welche Aktionen kann er durchführen?
Starke Antwort: Reviewer sehen kontextbezogene Informationen (letzter Login, Berechtigungsbeschreibung, Peer-Vergleich) - nicht nur eine Liste von Checkboxen. Bei einer typischen Quartalsüberprüfung bestätigen die meisten Manager jeden Eintrag, ohne einen einzigen davon wirklich zu lesen. [5] Reviewer-Fatigue ist ein Governance-Versagen, kein Nutzerproblem.
F11. Können Sie risikobasierte Zugangszertifizierungen konfigurieren - bei denen hochriskante Berechtigungen häufiger überprüft werden als risikoarme? Wie wird das Risiko bewertet?
Starke Antwort: Ja, mit konfigurierbarer Risikobewertung auf Basis von Berechtigungssensitivität, letztem Nutzungsdatum und Peer-Group-Analyse. Jährliche Pauschalüberprüfungen aller Berechtigungen sind ein Compliance-Häkchen, keine Sicherheitsmaßnahme.
F12. Was passiert, wenn ein Reviewer eine Zertifizierungsfrist verpasst? Wird der Zugriff automatisch entzogen, verlängert oder eskaliert?
Starke Antwort: Konfigurierbare Richtlinien / Policies - idealerweise mit automatischem Entzug als Standard für hochriskante Berechtigungen und Eskalation für andere. "Zugriff wird bis zur Überprüfung verlängert" als Standard ist ein Muster, das Risiken akkumuliert.
Abschnitt 4: Feingranulare Zugriffskontrolle
F13. Können Sie für Slack, GitHub, Jira und Notion auf Kanal-, Repository-, Projekt- und Seitenebene provisionieren und deprovisionieren? Demonstrieren Sie das in einer Live-Umgebung.
Starke Antwort: Live-Demonstration der Sub-Ressourcen-Provisionierung für jede genannte Applikation. SCIM erstellt Konten, übernimmt aber keine granulare Zugriffsprovisionierung - wie das Hinzufügen von Usern zu bestimmten Gruppen, Kanälen oder Projekten basierend auf Rolle, Fachbereich oder Standort. [6] Anbieter, die nur auf Kontoebene provisionieren können, lassen die sensibelsten Zugriffsentscheidungen manuell.
F14. Wenn ein User deprovisioniert wird - entzieht Ihre Plattform dann API-Keys, aktive Sessions und OAuth-Berechtigungen, oder deaktiviert sie nur den primären Account-Login?
Starke Antwort: Vollständiger Entzug einschließlich Tokens, Sessions und OAuth-Scopes. Viele Systeme deaktivieren beim Deprovisionieren nur den UI-Login, was für die Unternehmenssicherheit nicht ausreicht. [7] Ein deaktivierter Login mit aktiven API-Keys ist keine deprovisionierte Identität.
F15. Wie behandelt Ihre Plattform Separation-of-Duties-Konflikte (SoD) auf Berechtigungsebene - nicht nur auf Rollenebene?
Starke Antwort: SoD-Richtlinien-Durchsetzung auf Berechtigungsebene mit Echtzeit-Konflikterkennung bei Zugriffsanfragen, nicht nur periodische Batch-Prüfungen. SoD auf Rollenebene übersieht genau die Konflikte, die tatsächlich zu Audit-Feststellungen führen.
Abschnitt 5: Nicht-menschliche Identitäten & KI-Agenten
F16. Wie erkennt, inventarisiert und verwaltet Ihre Plattform Service-Accounts, API-Keys und OAuth-Tokens - nicht nur menschliche User-Accounts?
Starke Antwort: Automatisierte Erkennung mit Eigentümerzuweisung, Ablaufrichtlinien und Access-Reviews für nicht-menschliche Identitäten (NHIs). Forschungsergebnisse von Rubrik Zero Labs zeigen ein Verhältnis von nicht-menschlichen zu menschlichen Identitäten von 45:1 im modernen Unternehmen. [8] Eine Plattform, die nur menschliche Identitäten verwaltet, deckt nur einen kleinen Teil Ihrer tatsächlichen Angriffsfläche ab.
F17. Für KI-Agenten und Automatisierungs-Bots, die Zugriff auf Produktionssysteme anfordern - wie sieht Ihr Governance-Modell aus? Wie werden sie eingebunden, überprüft und außer Betrieb genommen?
Starke Antwort: Ein definierter Lifecycle für KI-Agenten-Identitäten mit Eigentümerschaft, eingeschränkten Berechtigungen und regelmäßiger Überprüfung. Eine WEF-Analyse aus dem Jahr 2025 ergab, dass 51 % der Unternehmen keine klare Eigentümerschaft für KI-Identitäten haben. [9] "Daran arbeiten wir noch" ist 2026 keine akzeptable Antwort.
The NHI blind spot is the fastest-growing gap in IGA. {{fact}}The NHI population across the industry grew 44% between 2024 and 2025.{{/fact}} CSA NHI governance whitepaper Any vendor that treats NHI governance as a roadmap item rather than a current capability is selling you a platform that's already behind your threat model.
Abschnitt 6: Deployment & Time-to-Value
F18. Wie sieht ein realistischer Deployment-Zeitplan für ein Unternehmen unserer Größe und Stack-Komplexität aus? Schlüsseln Sie ihn nach Phasen auf, und erläutern Sie, was Ihr Team liefert und was wir beisteuern müssen.
Starke Antwort: Ein phasenweiser Zeitplan mit konkreten Meilensteinen, klarer Aufgabenteilung und einem namentlich genannten Referenzkunden vergleichbarer Größe. Legacy-IGA-Implementierungen benötigen typischerweise 12 bis 18 Monate, um vollständigen Mehrwert zu liefern. [10] Jeder Anbieter, der für ein Mid-Market-Deployment "6-18 Monate" angibt, sollte erklären, warum.
F19. Welche internen Ressourcen - Headcount, Engineering-Stunden, dediziertes IAM-Personal - sind erforderlich, um die Plattform nach dem Deployment zu betreiben?
Starke Antwort: Eine konkrete Schätzung in Stunden pro Woche, mit einem Referenzkunden, der ein ähnlich großes Team betreibt. Plattformen, die einen dedizierten IAM-Engineer benötigen, um betriebsfähig zu bleiben, sind nicht für schlanke Teams konzipiert.
F20. Können wir innerhalb von 30 Tagen einen Proof-of-Concept gegen unseren tatsächlichen Applikationsbestand durchführen - nicht in einer Sandbox? Was setzt das von unserer Seite voraus?
Starke Antwort: Ja, mit einem definierten PoC-Scope und einer klaren Liste von Voraussetzungen. Anbieter, die innerhalb von 30 Tagen keinen Mehrwert gegen Ihren echten Stack demonstrieren können, sagen Ihnen damit etwas über ihre Deployment-Komplexität.
Abschnitt 7: Preisstruktur & Gesamtkosten
F21. Schlüsseln Sie Ihr Preismodell auf: Was ist im Basis-Abonnement enthalten, und was löst zusätzliche Kosten aus? Konkret: Kosten pro Konnektor, erforderliche Enterprise-Upgrades für bestimmte Applikationen und Kosten für professionelle Dienstleistungen.
Starke Antwort: Eine vollständig aufgeschlüsselte Übersicht ohne "kommt darauf an"-Antworten. Kosten für professionelle Dienstleistungen bei IGA-Implementierungen machen typischerweise 20-40 % der gesamten Projektkosten aus. [11] Fordern Sie Kostenprojektionen für Jahr eins und Jahr drei separat an.
F22. Gibt es Konnektoren oder Funktionen, die nur auf höheren Pricing-Tiers verfügbar sind? Nennen Sie diese vollständig.
Starke Antwort: Eine vollständige Liste. Preismodelle, die Governance-Funktionen hinter Enterprise-Tarifen verstecken, führen dazu, dass die Plattform, die Sie evaluiert haben, nicht die Plattform ist, die Sie sich leisten können zu betreiben. Einen detaillierten Vergleich der Kostenstrukturen verschiedener Anbieter finden Sie in unserem [12].
F23. Wie hoch sind die Gesamtbetriebskosten (TCO) für ein Unternehmen unserer Größe über drei Jahre - einschließlich Software, Implementierung, professioneller Dienstleistungen und internem Personalaufwand?
Starke Antwort: Ein konkretes Drei-Jahres-TCO-Modell mit klar benannten Annahmen. Anbieter, die nur die Software-Kosten für Jahr eins nennen können, verschleiern die tatsächliche Zahl.
Abschnitt 8: Compliance & Audit-Belege
F24. Welche Belege produziert Ihre Plattform für ein SOC 2 Type II- oder ISO 27001-Audit automatisch? Zeigen Sie uns einen Muster-Access-Review-Bericht und ein Muster-Provisionierungs-/Deprovisionierungs-Log.
Starke Antwort: Live-Demonstration von auditfähigen Exporten - mit Zeitstempel, Reviewer-Zuordnung und in auditortauglichen Formaten exportierbar. "Das können wir generieren" ist etwas anderes als "hier ist es."
F25. Wenn ein Auditor nach dem Zugriff auf eine Applikation fragt, die nicht mit Ihrer Plattform verbunden ist - ein Tool, das Ihre Plattform nicht verwaltet - wie lautet Ihre Antwort?
Starke Antwort: Der Anbieter erkennt die Lücke an und erklärt, wie er mit nicht verwalteten Applikationen umgeht (Erkennung, manueller Attestierungsworkflow oder native Abdeckung). Ein Anbieter, der behauptet, dieses Szenario treffe auf seine Plattform nicht zu, hat Ihren Stack nicht verstanden.
Anbieterantworten bewerten
Verwenden Sie dieses Widget, um jeden Anbieter in den acht Abschnitten zu bewerten und einen gewichteten Vergleich zu erstellen.
Was Sie mit den Antworten tun
Eine starke RFP-Antwort ist kein Marketingdokument - sie ist eine Sammlung konkreter, nachweisbarer Aussagen. Für jede Antwort, die zählt, sollten Sie den Anbieter bitten, sie in einer Live-Umgebung gegen Ihren tatsächlichen Applikationsbestand zu belegen - nicht in einem vorkonfigurierten Demo-Tenant.
Die Fragen in Abschnitt 1 (Applikationsabdeckung) und Abschnitt 7 (Preisstruktur) erzeugen erfahrungsgemäß die größte Differenzierung. Anbieter, die F1, F4 und F21 nicht konkret beantworten können, signalisieren Ihnen, dass die Lücken und Kosten real sind - sie wollen sie nur nicht benennen, bevor Sie unterschreiben.
Einen tieferen Einblick in den Vergleich der führenden Plattformen in diesen Dimensionen finden Sie im [2] und dem [3].