Anforderungsprofil: IAM/IGA Lifecycle
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „IAM/IGA Lifecycle“.
Am Ende steht ein begrenzter, messbarer Identity-Lifecycle mit führender Quelle, definierten Ownern, getesteten Provisioningpfaden, Access Review und dokumentierten Ausnahmeprozessen.
Thema: iam-iga · Stand 2026-09-20Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Joiner/Mover/Leaver-Prozesse mit führender Quelle, Eigentümerschaft, Fehlerfällen und zeitnahem Deprovisioning praktisch testen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | Access Reviews mit realen Reviewern, Delegationen, Eskalationen und nachvollziehbarer Entscheidungsdokumentation pilotieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Entitlement-Katalog, Genehmigungswege, Laufzeiten und Rollenmodelle an konkreten Fachanwendungen validieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Connectoren für Cloud- und On-Premises-Zielsysteme inklusive Rückmeldung, Fehlerbehandlung und Orphan-Account-Erkennung prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | SoD-Regeln, Break-Glass-Konten, Audit-Export, Datenhaltung und Exit-/Migrationsweg vor Produktivsetzung festlegen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Role Mining oder Analytics unterstützen die Bereinigung historisch gewachsener Berechtigungen. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Nicht-menschliche Identitäten und technische Konten können inventarisiert und einem Owner zugeordnet werden. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | SoD-/Policy-Regeln lassen sich als nachvollziehbare Kontrollen mit Ausnahmeprozess modellieren. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Connector-Framework bzw. APIs erleichtern die Anbindung individueller Fachverfahren. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Werden Joiner, Mover und Leaver aus einer verlässlichen Quelle und mit definierten Fristen gesteuert?
Haben Berechtigungen Owner, Genehmigung, Laufzeit und überprüfbare Rezertifizierung?
Sind kritische Cloud- und On-Premises-Zielsysteme mit belastbaren Provisioning- und Rückmeldepfaden integrierbar?
Können kritische Berechtigungskombinationen vor oder spätestens bei der Vergabe erkannt werden?
Sind Genehmigungen, Änderungen, Entzüge, Fehler und Ausnahmen nachvollziehbar?
Kann das Team Connectoren, Datenqualität, Reviews und Störungen dauerhaft betreiben?
Gates als objektive Abnahmekriterien verwenden
Für den Pilot ist klar, welche Quelle welchen Identitätszustand bestimmt und wer Zugriffe fachlich verantwortet.
Für jeden Pilotprozess ist ein erwarteter Berechtigungszustand und ein verantwortlicher Entscheider dokumentiert.
Die Shortlist deckt die Muss-Kriterien für JML, Reviews und die ausgewählten Zielsysteme ab.
Berechtigungen werden innerhalb der definierten Fristen gesetzt oder entzogen; Fehler und Ausnahmen sind sichtbar und bearbeitbar.
Der nächste Scope ist priorisiert und hat keine unklaren Owner oder versteckte manuelle Dauerworkarounds.
Vor Produktivsetzung klären
- Connector- und Reconciliation-Fehler mit verantwortlichen Applikationsownern bearbeiten.
- Deprovisioning-Ausnahmen, verwaiste Konten und fehlgeschlagene Provisionierung überwachen.
- Access-Review- und Entitlement-Owner mit Eskalationswegen pflegen.
- Break-Glass- und Adminrollen regelmäßig getrennt vom Tagesbetrieb überprüfen.
Vor Vertragsbindung nachweisen
- Entitlements, Rollen, Review-Nachweise, Policies und Connector-Konfigurationen exportieren können.
- Cutover-/Koexistenz für Provisioning und Deprovisioning ohne doppelte Schreibhoheit planen.
- Nach Migration Orphan Accounts, ausstehende Requests und Berechtigungsabweichungen vollständig reconciliieren.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Lifecycle & Governance | 30 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Connectoren & Integration | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Kontrollen & Audit | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Betrieb & Ownership | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Identity-Source-Matrix
- JML-Sollzustände
- Berechtigungsowner-Matrix
- Muss-/Kann-Kriterien
- Finder-Profil
- Vergleichsmatrix
- Pilotarchitektur
- Access-Review-Protokoll
- Exception-Log
- Rollout-Roadmap
- Betriebs-Runbook