<!-- Canonical: https://easyiga.com/de/branchen/finanzdienstleistungen -->

[Startseite](https://easyiga.com/de/) / Lösungen / Finanzdienstleistungen

easyIGA für Finanzdienstleister

# Zugriffsentscheidungen im Finanzwesen
nachvollziehbar machen

Geben Sie Führungskräften den nötigen Kontext, um Zugriff auf Anwendungen zu genehmigen und bestehende Berechtigungen zu überprüfen. easyIGA baut auf midPoint auf und verbindet die Entscheidung, die konfigurierten Richtlinienprüfungen und das protokollierte Ergebnis.

[Demo anfragen](https://easyiga.com/de/demo)

Verantwortlichkeiten im Finanzbereich, Überprüfungsnachweise und Umfang der IGA-Lizenzierung.

[Die Skyline von Lower Manhattan in New York City, über das Wasser hinweg gesehen]

Symbolfoto. [Peter Beke / Unsplash](https://unsplash.com/photos/lower-manhattan-skyline-in-new-york-gAB5VwuwmUM).

Auf dieser Seite

[Jeder Zugriffsentscheidung einen fachlichen Grund geben](https://easyiga.com/de/branchen/finanzdienstleistungen#give-every-access-decision-a-business-reason)[Eine Anfrage auf dem Weg durch das Finanzteam](https://easyiga.com/de/branchen/finanzdienstleistungen#follow-a-request-through-the-finance-team)[Konflikte anhand der Verantwortlichkeiten im Finanzbereich definieren](https://easyiga.com/de/branchen/finanzdienstleistungen#define-conflicts-in-terms-of-financial-responsibilities)[Berechtigungen mit ausreichendem Kontext rezertifizieren](https://easyiga.com/de/branchen/finanzdienstleistungen#review-existing-access-with-enough-context)[Teamwechsel und befristeten Zugriff sichtbar machen](https://easyiga.com/de/branchen/finanzdienstleistungen#make-staff-moves-and-temporary-access-explicit)[DORA als Rahmen für Kontrollen](https://easyiga.com/de/branchen/finanzdienstleistungen#treat-dora-as-a-control-context)[Wie easyIGA und midPoint zusammenarbeiten](https://easyiga.com/de/branchen/finanzdienstleistungen#understand-the-engine-and-the-business-interface)[IGA-Lizenzierung auf derselben Grundlage vergleichen](https://easyiga.com/de/branchen/finanzdienstleistungen#compare-iga-licensing-on-the-same-basis)[Altanwendungen anbinden, ohne die Grenzen zu verbergen](https://easyiga.com/de/branchen/finanzdienstleistungen#connect-legacy-applications-without-hiding-the-limits)[Ein Bereitstellungsmodell wählen, das Ihr Team betreiben kann](https://easyiga.com/de/branchen/finanzdienstleistungen#choose-a-deployment-model-your-team-can-operate)[Eine gezielte Evaluierung mit Kontrollverantwortlichen vorbereiten](https://easyiga.com/de/branchen/finanzdienstleistungen#prepare-a-focused-evaluation-with-your-control-owner)

## Jeder Zugriffsentscheidung einen fachlichen Grund geben

Eine Anwendungsrolle im Finanzbereich kann es erlauben, einen Bericht einzusehen, Lieferantendaten zu pflegen oder eine Transaktion zu autorisieren. Diese Berechtigungen sind mit unterschiedlicher Verantwortung verbunden. Ein sinnvoller Identity-Governance-Prozess erklärt der genehmigenden Person den Unterschied und bewahrt die Einträge auf, die nötig sind, um die Entscheidung später nachzuvollziehen.

easyIGA ist Software, mit der Zugriff auf die Anwendungen Ihrer Organisation beantragt, genehmigt und überprüft wird. Als zugrunde liegende Identity-Governance-Plattform dient midPoint. Beteiligte aus dem Fachbereich arbeiten mit verständlichen Anfragen, während IAM-Fachleute die Rollen und Integrationen konfigurieren, die die Änderungen in angebundenen Systemen bestimmen.

Für eine Bank, einen Versicherer oder ein anderes Finanzunternehmen sollte die Evaluierung mit einer echten Kontrollfrage beginnen. Wählen Sie eine Anwendung und den Zugriff, den die für diese Anwendung verantwortliche Person steuern muss. Klären Sie, wer zur Genehmigung befugt ist, welche Richtlinie gilt und welche Nachweise ein abgeschlossener Vorgang liefern soll. So bleibt das Gespräch an einem Prozess verankert, den die Organisation testen kann.

Für die Anwendungsverantwortlichen beginnt ein sinnvoller Zugriffsprozess mit einer erkennbaren Verantwortung. Wer für das Finanzreporting verantwortlich ist, sollte eine Reporting-Rolle beurteilen können, ohne jede dahinterliegende Verzeichnisgruppe entschlüsseln zu müssen. easyIGA verbindet diese fachliche Entscheidung mit dem konfigurierten Workflow in midPoint. Die folgenden beispielhaften Fälle verfolgen eine Anfrage über die Genehmigung, die Ausführung im Zielsystem und die spätere Überprüfung. Sie zeigen, wo jede beteiligte Person mitwirkt und welche Einträge helfen, das Ergebnis zu erklären.

## Eine Anfrage auf dem Weg durch das Finanzteam

Nehmen Sie als Beispiel eine fiktive Person, die neu in ein Reporting-Team kommt. Sie braucht Zugriff auf eine Reporting-Anwendung, aber nicht die Berechtigungen, mit denen Zahlungen freigegeben werden. Ein technischer Gruppenname allein macht diesen Unterschied möglicherweise weder für die Person selbst noch für die Führungskraft deutlich.

Die erste Aufgabe besteht darin, der Anfrage eine fachliche Beschreibung zu geben. Der Katalog von easyIGA bietet Mitarbeitenden und Führungskräften einen verständlichen Einstieg. Ihre Implementierung ordnet diese Beschreibung der konfigurierten Rolle zu. Die Organisation entscheidet, welche Rollen beantragt werden können und welche Personen befugt sind, sie zu genehmigen.

In der Entscheidungsphase prüft die genehmigende Person die Anfrage und die Ergebnisse der konfigurierten Richtlinien. Die Oberfläche sollte ihr helfen, den beantragten Zugriff zu verstehen, ohne dass sie midPoint administrieren muss. Genehmigungen sind auch direkt in Microsoft Teams möglich. Den unterstützten Workflow und die Nachweisfelder Ihres vorgesehenen Releases sollte die Demo zeigen.

Nach der Genehmigung führt midPoint die konfigurierte Änderung aus. easyIGA zeigt das protokollierte Ergebnis an. Diese letzte Phase ist wichtig, weil eine nicht verfügbare Anwendung, ein unvollständiger Identitätsdatensatz oder ein Integrationsfehler verhindern kann, dass aus einer genehmigten Entscheidung nutzbarer Zugriff wird.

Bitten Sie während einer Demo die antragstellende Person und die Führungskraft, den Prozess in eigenen Worten zu erklären. Erkennt die antragstellende Person, was sie beantragt? Kann die Führungskraft benennen, welche Verantwortung sie übernimmt? Findet die Person im Betrieb den Grund, warum eine Änderung nicht abgeschlossen wurde? Diese Beobachtungen erlauben eine bessere Einschätzung der Benutzerfreundlichkeit als die allgemeine Behauptung, eine Oberfläche sei einfach.

Ein Workflow zur gemeinsamen Prüfung

- 01Reporting-Zugriff wird beantragt

- 02Anwendungsverantwortliche Person entscheidet

- 03midPoint ändert die Rolle

- 04Entscheidung und Ergebnis werden überprüft

Beispielhafter Prozess. Das Ergebnis hängt von den konfigurierten Quellen, Richtlinien und Zielsystemen ab.

## Konflikte anhand der Verantwortlichkeiten im Finanzbereich definieren

Bei der Funktionstrennung geht es um Kombinationen von Zugriffsrechten, die nach dem Willen Ihrer Organisation getrennt bleiben sollen. Ein gängiges Beispiel in Evaluierungen ist die Möglichkeit, einen Zahlungsempfänger zu pflegen und die zugehörige Zahlung zu autorisieren. Die tatsächliche Regel hängt von Ihren Anwendungen und der Ausgestaltung Ihrer Kontrollen ab; sie ist keine allgemeingültige Richtlinie, die eine Website vorgeben kann.

easyIGA zeigt zum Zeitpunkt der Genehmigung das ausgewertete Ergebnis der in midPoint konfigurierten Ausschlussrichtlinien an. Einen in der midPoint-Konfiguration bekannten Konflikt kann die genehmigende Person schon vor ihrer Entscheidung sehen. So wird das Richtlinienergebnis Teil der Entscheidung und kein separates Dokument, an das die genehmigende Person denken und das sie erst heraussuchen muss.

Ihre IAM-Fachleute müssen weiterhin die relevanten Rollen bestimmen und die Ausschlussregeln pflegen. Verfügbare und geplante Funktionen bleiben klar getrennt. Konflikte mit konfigurierten Richtlinien werden zum Entscheidungszeitpunkt ausgewertet und angezeigt. Das Erstellen und Simulieren von Regeln in easyIGA ist geplant und sollte ohne gesonderte Bestätigung für das jeweilige Release nicht als Teil des aktuellen Kaufumfangs betrachtet werden.

Testen Sie die Regel mit mehr als einem Weg zur selben Berechtigung. Wenn Zugriff auf eine Anwendung über eine geerbte Rolle oder eine Verzeichnisgruppe entstehen kann, muss die Implementierung dieses Modell berücksichtigen. Eine Demo mit einer sorgfältig ausgewählten Rolle belegt nicht, dass jede Kombination von Berechtigungen abgedeckt ist.

Legen Sie außerdem fest, wer für eine Richtlinienänderung verantwortlich ist. Ein umgestalteter Zahlungsprozess kann die Bedeutung bestehender Rollen verändern. Dokumentieren Sie die fachlich verantwortliche Person, die für die Konfiguration zuständige Fachperson und den Test, der das beabsichtigte Ergebnis belegt. Das Produkt kann ein konfiguriertes Richtlinienergebnis anzeigen; ob diese Richtlinie die Kontrolle der Organisation korrekt abbildet, entscheidet weiterhin die Organisation selbst.

## Berechtigungen mit ausreichendem Kontext rezertifizieren

Bei einer Rezertifizierung von Berechtigungen, auch Zugriffsüberprüfung genannt, wird eine Führungskraft oder die für eine Anwendung verantwortliche Person gefragt, ob Berechtigungen weiterhin gerechtfertigt sind. Eine abgeschlossene Überprüfung ist nicht dasselbe wie eine gut begründete Entscheidung. Prüfende Personen brauchen eine verständliche Beschreibung des Zugriffs und relevante Nachweise zur Person und zur Historie.

easyIGA zeigt neben dem zu überprüfenden Zugriff den verfügbaren Kontext an. Die Felder „Letzte Nutzung“, „Gewährt von“ und „Genehmigt von“ sind nützlich, wenn die angebundenen Systeme und die erfasste Genehmigungshistorie sie liefern. Jedes Feld beantwortet eine andere Frage. Jüngste Aktivität rechtfertigt eine Berechtigung nicht automatisch, und die aktuelle Führungskraft ist nicht unbedingt die Person, die sie ursprünglich autorisiert hat.

easyIGA protokolliert bei Anfragen, die über das Produkt gestellt werden, die antragstellende Person und die erfassten Genehmigungsschritte. Außerhalb von easyIGA vergebener Zugriff wird gesondert ausgewiesen, und zwar anhand der von midPoint protokollierten Erstellungsdaten. In historischen Einträgen können Angaben zur genehmigenden oder vergebenden Person fehlen; fehlende Informationen werden ausdrücklich angezeigt.

Nehmen Sie in eine Evaluierung Zugriff auf, der über den vorgesehenen Prozess erteilt wurde, und Zugriff mit unvollständiger Historie. Fragen Sie die prüfende Person, was sie aus jedem Eintrag schließen kann. Wo die Nachweise nicht ausreichen, vereinbaren Sie einen Weg zur Untersuchung, statt fehlende Informationen als Grund für eine automatische Genehmigung zu behandeln.

Verfolgen Sie eine Entscheidung zum Entzug bis in die Zielanwendung. Eine Auditstichprobe sollte die Entscheidung der prüfenden Person vom Ergebnis der Entzugsoperation unterscheiden können. Ist das Ergebnis unbekannt oder ausstehend, muss die für die Kontrolle verantwortliche Person wissen, wie dieser Fall nachverfolgt wird. An diesem Punkt wird ein Überprüfungsprozess mit der betrieblichen Umsetzung verbunden.

## Teamwechsel und befristeten Zugriff sichtbar machen

Eine Person, die zwischen Finanzteams wechselt, kann Berechtigungen behalten, die nicht mehr zu ihrer Rolle gehören. Wird der Zugriff des neuen Teams hinzugefügt, ohne den bisherigen Zugriff zu prüfen, wächst in der Organisation ein Bestand an Berechtigungen, der sich möglicherweise schwer erklären lässt.

midPoint bildet die Grundlage für Identitätslebenszyklus und Provisionierung. Ihre IAM-Fachleute konfigurieren maßgebliche Quellen und die Regeln, die Identitätsänderungen mit Zielsystemen verbinden. easyIGA bietet den Beteiligten aus dem Fachbereich die dazugehörigen Anfrage- und Überprüfungsabläufe. Das Ergebnis hängt von der Qualität der Quelldaten und vom Umfang der Integration ab.

Wählen Sie für das Pilotprojekt einen Wechselfall (Mover). Halten Sie schriftlich fest, welcher Zugriff vor und nach der Änderung benötigt wird. Bestimmen Sie die Berechtigungen, die entzogen werden sollen, die Berechtigungen, die bestehen bleiben sollen, und jede Ausnahme, die eine neue Entscheidung erfordert. Der Test sollte jede Kategorie sichtbar machen, statt den Erfolg nur daran zu messen, dass das neue Konto vorhanden ist.

Befristete Zuweisungen erfordern einen ähnlichen Ansatz. Eine Vertretungsregelung, ein Projekt oder ein externer Auftrag kann einen berechtigten kurzfristigen Bedarf begründen. Wenn der konfigurierte Prozess ein Enddatum verwendet, zeigen Sie, wie dieses Datum in die relevante Richtlinie gelangt und was bei einer Verlängerung geschieht. Dass ein Datum in einem HR-System steht, beweist nicht, dass der Zugriff auf die Anwendung abläuft.

Wenn ein Quelldatensatz unvollständig ist, legen Sie fest, wer ihn korrigiert. Ein Zugriffs-Workflow sollte weder eine Führungskraft erfinden noch eine Genehmigung stillschweigend umgehen, nur weil ein organisatorischer Datensatz fehlt. Eine sichtbare Ausnahme gibt dem Team die Gelegenheit, den Prozess zu korrigieren und die Auswirkung auf den beantragten Zugriff zu verstehen.

## DORA als Rahmen für Kontrollen

DORA befasst sich mit der digitalen operationalen Resilienz im Finanzsektor. [Artikel 9 der Verordnung (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) umfasst Richtlinien, die den physischen oder logischen Zugang zu Informations- und IKT-Assets auf den Umfang beschränken, der für rechtmäßige und zulässige Funktionen und Tätigkeiten erforderlich ist, sowie Konzepte, Verfahren und Kontrollen für Zugangs- und Zugriffsrechte. IGA kann den Teil des Kontrollumfelds der Organisation unterstützen, der den logischen Zugriff betrifft; der Kauf eines Produkts stellt keine Compliance her. Für Institute in Deutschland hebt die BaFin die BAIT schrittweise auf. Institute, die ab dem 17. Januar 2025 ein IKT-Risikomanagement nach Artikel 5 bis 15 oder Artikel 16 DORA betreiben müssen, sind seitdem aus dem Anwenderkreis der BAIT ausgenommen. Ab dem 1. Januar 2027 gelten die Vorgaben von DORA nach § 1a Abs. 2a in Verbindung mit § 65a Abs. 3 KWG auch für Institute, die nicht nach Artikel 2 DORA in deren Anwendungsbereich fallen, und zwar mit dem vereinfachten IKT-Risikomanagementrahmen nach Artikel 16 DORA. Mit Ablauf des 31. Dezember 2026 werden die BAIT vollständig aufgehoben. Die MaRisk in der Fassung vom 30. Juni 2026 (Rundschreiben 06/2026 (BA)) enthalten die bisherigen Vorgaben zur Vergabe und regelmäßigen Überprüfung von IT-Berechtigungen aus AT 4.3.1 Tz. 2 und AT 7.2 Tz. 2 nicht mehr. Unverändert müssen miteinander unvereinbare Tätigkeiten von verschiedenen Personen ausgeführt werden (AT 4.3.1 Tz. 1), und bei IKT-gestützter Bearbeitung ist die Funktionstrennung durch entsprechende Verfahren und Schutzmaßnahmen sicherzustellen (BTO Tz. 7). Nach dem Übersendungsschreiben der BaFin ist mit dem stärker prinzipienorientierten Ansatz keine grundsätzliche Absenkung des Anforderungsniveaus verbunden.

Übersetzen Sie die Kontrollfrage in eine Evaluierung. Welche Anwendung gehört zum Umfang? Wer darf die Rolle autorisieren? Was protokolliert der konfigurierte Workflow? Wie stellt die Organisation fest, dass die Änderung im Zielsystem stattgefunden hat? Die Antworten sollten so konkret sein, dass die für die Kontrolle verantwortliche Person eine Stichprobe prüfen kann.

Grenzen Sie die übrige Resilienzarbeit davon ab. Der Identitäts-Workflow ersetzt weder Regelungen zur Geschäftsfortführung noch das Vorfallmanagement oder die Bewertung von Drittparteienrisiken. Eine Produktdemo kann eine Zugriffsentscheidung und die zugehörigen Einträge zeigen, aber nicht belegen, dass ein Institut jede anwendbare Pflicht erfüllt hat.

Vereinbaren Sie für die Vorbereitung von Nachweisen die erforderlichen Einträge, bevor Sie einen Bericht konfigurieren. Ein sinnvoller Eintrag verbindet Identität und Berechtigung mit der Entscheidung und dem Ergebnis, soweit diese Informationen verfügbar sind. Aufbewahrung, Zugriff auf die Einträge und der Umgang mit fehlender Historie erfordern ebenfalls betriebliche Entscheidungen.

Die [DORA-Seite von easyIGA](https://easyiga.com/de/dora) bietet einen passenden Ausgangspunkt. Ihre Compliance- und Rechtsabteilungen sollten die Anwendbarkeit und die genaue Auslegung der Kontrolle bestimmen. Mit einer abgegrenzten Demo können sie dann beurteilen, ob das Produkt die Nachweise liefert, die für den konkreten Workflow benötigt werden, den sie prüfen.

## Wie easyIGA und midPoint zusammenarbeiten

midPoint bietet bereits Funktionen für Identitätsmanagement und Identity Governance. midPoint verarbeitet konfigurierte Identitätsdaten, Rollen und Änderungen an angebundenen Systemen. easyIGA baut auf dieser Grundlage auf, statt sie zu ersetzen.

Diese Aufteilung ist für ein Finanzunternehmen mit bestehendem Identitätsteam wichtig. IAM-Fachleute bleiben für die Konfiguration und die Integrationen von midPoint verantwortlich. Führungskräfte und Anwendungsverantwortliche nutzen die fachlich ausgerichteten Anfrage- und Überprüfungs-Workflows. Ein Produktvergleich sollte zeigen, was jede beteiligte Person tatsächlich tut, und nicht nahelegen, dass dieselbe Arbeit aus dem System verschwunden ist.

Vergleichen Sie einen bestehenden midPoint-Prozess mit der vorgeschlagenen easyIGA-Oberfläche anhand derselben Rolle und derselben Zielanwendung. Bitten Sie eine Führungskraft, eine gewöhnliche Anfrage und eine Anfrage mit einem bekannten Konflikt zu prüfen. Bitten Sie die Person im Betrieb, eine unvollständige Änderung im Zielsystem zu finden. So wird der zusätzliche Produktnutzen beobachtbar, ohne zu behaupten, dass midPoint diese zugrunde liegenden Governance-Mechanismen nicht besitzt.

Die [Übersicht über midPoint](https://docs.evolveum.com/book/02-midpoint-overview/) und [der Konnektorkatalog](https://docs.evolveum.com/connectors/connectors/) bieten technischen Hintergrund. Klären Sie die genaue Anwendungsversion und die unterstützten Operationen mit Ihrem Integrationsteam. Ein Konnektor kann Konfiguration oder Erweiterung erfordern, damit sich die gewünschten Berechtigungen verwalten lassen.

Die [Seite zu Finanzdienstleistungen](https://evolveum.com/midpoint-in-financial-services/) von Evolveum beschreibt Anwendungsfälle für midPoint. Für easyIGA besteht der nächste Schritt darin, den fachlichen Workflow mit Ihren eigenen Anwendungsverantwortlichen und Ihrem Identitätsteam zu prüfen. Verwenden Sie eine Reporting- oder Genehmigungsrolle, die beide kennen, nehmen Sie einen konfigurierten Konflikt auf und verfolgen Sie die daraus folgende Änderung. So erhält jede beteiligte Person eine konkrete Grundlage, um die vorgeschlagene Lösung mit dem heutigen Prozess zu vergleichen.

## IGA-Lizenzierung auf derselben Grundlage vergleichen

Für midPoint fällt keine Softwarelizenzgebühr an. Einige Funktionen von midPoint, etwa Simulationen, Hochverfügbarkeits-Clustering oder eine andere Datenbank als PostgreSQL, erfordern ein Evolveum-Abonnement, das wir für Sie organisieren und in Ihr Angebot aufnehmen. easyIGA ist ein kommerzielles Produkt. Das veröffentlichte Modell ist ein Jahresabonnement pro verwalteter Identität, wobei die Einführung in einem vereinbarten Umfang enthalten ist. Die endgültigen Preise je Stufe und der vertraglich vereinbarte Funktionsumfang müssen vor dem Kauf bestätigt werden.

Ein Vergleich im Einkauf sollte bei den zu zählenden Identitätsgruppen beginnen. Klären Sie, wie Mitarbeitende, externe Mitarbeitende und Servicekonten gezählt werden. Eine große Zahl technischer Konten kann den Umfang verändern, auch wenn die Zahl der Mitarbeitenden stabil bleibt. Fragen Sie, wie das vorgeschlagene Modell mit Wachstum und inaktiven Datensätzen umgeht, statt anzunehmen, dass jeder Anbieter dieselbe Definition verwendet.

Vergleichen Sie als Nächstes Funktionalität und Lieferumfang. Listen Sie die Anwendungen, die erforderlichen Operationen und die Umgebungen auf. Ermitteln Sie den Aufwand für Migration und Datenbereinigung. Halten Sie die Supportverantwortlichkeiten und Abnahmekriterien fest. Zwei Angebote mit ähnlichen wiederkehrenden Preisen können wesentlich unterschiedliche Arbeit bedeuten, wenn eines nur die Ersteinrichtung eines Konnektors und das andere eine größere Migration umfasst.

Schätzen Sie den Betriebsaufwand anhand der eigenen Zahlen der Organisation. Erfassen Sie die Zeit für die Bearbeitung einer Zugriffsanfrage, die Vorbereitung von Überprüfungsnachweisen und die Klärung von Ausnahmen. Trennen Sie aktiv geleistete Arbeitszeit von der Wartezeit auf eine Entscheidung. Verbesserungen bei beidem können wichtig sein, sollten aber nicht als dieselbe finanzielle Einsparung gezählt werden.

Die [Preisseite](https://easyiga.com/de/preise) und [der Einsparungsrechner](https://easyiga.com/de/preise#roi) bieten eine Grundlage für ein Gespräch über einen abgegrenzten Umfang. Sie liefern keine allgemeingültige Einsparung und ersetzen kein schriftliches Angebot. Beziehen Sie Übergangs- und Verlängerungsbedingungen in den Vergleich ein und bewerten Sie dann den gezeigten Workflow zusammen mit den Kosten.

## Altanwendungen anbinden, ohne die Grenzen zu verbergen

Ein Finanzunternehmen betreibt möglicherweise langlebige Anwendungen neben neueren Cloud-Diensten. Das Identitätsdesign muss klären, wie Zugriff in jedem Zielsystem abgebildet wird. Das kann eine Anwendungsrolle, eine Verzeichnisgruppe oder eine Kombination von Berechtigungen mit fachlicher Bedeutung sein.

Beginnen Sie mit einer Bestandsaufnahme der benötigten Operationen. Konten zu lesen ist etwas anderes, als Berechtigungen zu ändern. Ein Konto anzulegen ist etwas anderes, als es zu deaktivieren. Klären Sie, wie die Integration Fehler meldet und welche Informationen verfügbar sind, um eine erfolgreiche Änderung zu verifizieren.

Die Implementierung muss auch Änderungen berücksichtigen, die außerhalb des normalen Anfrageprozesses vorgenommen werden. Ein Abgleich (Reconciliation) kann die konfigurierte Identitätssicht mit Informationen aus dem Zielsystem vergleichen, aber die verfügbaren Daten und die gewählte Richtlinie bestimmen, welche Schlüsse sich ziehen lassen. Einem entdeckten Konto sollte nicht automatisch eine erfundene genehmigende Person aus dem Fachbereich zugeordnet werden.

Nehmen Sie in das Pilotprojekt ein Zielsystem auf, das eine brauchbare Bestätigung zurückgibt, und eines mit einer eingeschränkteren Schnittstelle. Vereinbaren Sie, wie der Betrieb mit beiden umgeht. Bleibt ein manueller Schritt, halten Sie die Verantwortung und den erwarteten Nachweis fest. Eine teilweise Integration kann dennoch nützlich sein, wenn ihre Grenzen bekannt sind; irreführend wird sie, wenn diese Grenzen hinter einer einheitlichen Erfolgsmeldung verborgen werden.

Berücksichtigen Sie das Supportmodell auf lange Sicht. Ein Upgrade der Anwendung kann die relevante Schnittstelle oder Berechtigungsstruktur verändern. Legen Sie Verantwortlichkeiten für Konnektortests und Rollenpflege fest. Das gehört zu den Betriebskosten und sollte in der Evaluierung sichtbar sein, statt erst nach dem ersten Go-live entdeckt zu werden.

Verantwortlichkeiten vergleichen

## Was der Fachbereich entscheidet. Was IAM-Fachleute konfigurieren.

easyIGA unterstützt den fachlich ausgerichteten Workflow; midPoint bleibt die konfigurierte Identity-Governance-Plattform. Verwenden Sie beim Vergleich der Optionen denselben Anwendungsumfang.

Verantwortlichkeiten im vorgeschlagenen Workflow für Finanzdienstleistungen

| Situation | Fachliche Entscheidung mit easyIGA | Arbeit der IAM-Fachleute mit midPoint
| Anfrage für eine Finanzanwendung | Die beantragte Geschäftsrolle verstehen. | Die Rolle den vorgesehenen Berechtigungen zuordnen.
| Unvereinbare Aufgaben | Das konfigurierte Richtlinienergebnis zum Entscheidungszeitpunkt sehen. | Die Rollen und Ausschlussregeln pflegen.
| Zugriffsüberprüfung | Den aktuellen Bedarf anhand verfügbarer Nachweise beurteilen. | Quelldaten bereitstellen und unterstützte Änderungen umsetzen.
| DORA-Kontrollstichprobe | Die Entscheidung und das protokollierte Ergebnis prüfen. | Die Nachweise der angebundenen Anwendung validieren.

[easyIGA mit midPoint und midPoint allein im Vergleich ansehen](https://easyiga.com/de/vergleich/midpoint).

## Ein Bereitstellungsmodell wählen, das Ihr Team betreiben kann

Das Standardmodell für die Bereitstellung von easyIGA ist der selbst gehostete Betrieb. Die Organisation betreibt die Lösung auf ihrer eigenen Infrastruktur und in dem von ihr gewählten Rechtsraum. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die von unserem Team betrieben wird.

Der Standort einer Bereitstellung ist nur ein Teil der Entscheidung. Klären Sie die Verantwortlichkeiten für Updates, Monitoring und Wiederherstellung. Legen Sie fest, wer den Dienst administrieren darf und wie der Zugriff auf Nachweise kontrolliert wird. Die Betriebsvereinbarung muss zu der Umgebung passen, die Sie nutzen wollen.

Fordern Sie bei einer betriebenen Option die relevanten Service- und Auftragsverarbeitungsbedingungen im Rahmen der Due Diligence an. Leiten Sie aus der Formulierung „in der EU gehostet“ kein vereinbartes Service-Level, keine Liste von Unterauftragsverarbeitern und keine Wiederherstellungszusage ab. Diese Details müssen für den vorgesehenen Dienst ausdrücklich dokumentiert werden.

Beziehen Sie beim selbst gehosteten Betrieb den internen Aufwand in den Business Case ein. Ihr Team betreibt die erforderliche Infrastruktur vielleicht bereits, doch auch der neue Dienst braucht klare Zuständigkeiten. Legen Sie fest, wie Konfigurationsänderungen geprüft werden und wie eine fehlgeschlagene Integration eskaliert wird. Eine verantwortliche Stelle im Betrieb ist ebenso notwendig wie eine verantwortliche genehmigende Person im Fachbereich.

Nutzen Sie die [Informationen zur Bereitstellung](https://easyiga.com/de/bereitstellung) und [die Sicherheitsseite](https://easyiga.com/de/sicherheit), um diese Fragen einzuordnen. Ergebnis des Gesprächs sollte eine Liste von Verantwortlichkeiten und Abnahmenachweisen sein, keine allgemeine Zusicherung, dass das gewählte Hosting-Modell jedes Risiko löst.

## Eine gezielte Evaluierung mit Kontrollverantwortlichen vorbereiten

Bringen Sie eine Anwendung und eine kleine Auswahl repräsentativer Rollen zur Demo mit. Nehmen Sie eine gewöhnliche Anfrage, einen Konflikt und einen Rollenwechsel auf. Verwenden Sie zunächst synthetische Identitäten, damit für das Gespräch keine echten Kunden- oder Personaldaten geteilt werden müssen.

Lassen Sie die fachlich verantwortliche Person festlegen, was die genehmigende Person verstehen muss. Lassen Sie das technische Team bestimmen, was das Zielsystem bestätigen kann. Die Evaluierung sollte diese beiden Perspektiven verbinden. Eine Anfrage, die sich leicht genehmigen, aber nicht bis zu einem Ergebnis im Zielsystem zurückverfolgen lässt, beantwortet eine wichtige Frage nicht.

Halten Sie das genaue Release und die gezeigte Konfiguration fest. Notieren Sie, welche Nachweisfelder vorhanden waren und welche nicht verfügbar blieben. Geplante Funktionen sollten gesondert gekennzeichnet werden. So sind die Ergebnisse für den Einkauf nutzbar, und ein künftiger Roadmap-Punkt wird nicht versehentlich zur Abnahmebedingung für das aktuelle Produkt.

Unser Team hat mindestens 14 midPoint-Einführungen umgesetzt. Das ist Implementierungserfahrung und von der Nutzung von easyIGA getrennt zu betrachten. Nutzen Sie diese Erfahrung als Anlass, über die technische Eignung zu sprechen, und bewerten Sie das Produkt dann anhand einer konkreten Demo. Die Beispiele auf dieser Seite stellen weder ein Kundenergebnis noch eine finanzielle Einsparung in Aussicht.

[Fordern Sie eine 30-minütige Demo](https://easyiga.com/de/demo) bei unserem Team an. Der nächste sinnvolle Schritt ist, Ihre Zugriffsentscheidung, ihren Richtlinienkontext und das protokollierte Ergebnis zu prüfen und dann zu vereinbaren, ob eine abgegrenzte Evaluierung die verbleibenden Fragen beantworten kann.

Das Produkt im Einsatz sehen

## Eine Zugriffsentscheidung mitbringen.
Sehen, wie der Workflow damit umgeht.

Bringen Sie eine Rolle zur Zahlungsfreigabe oder eine Zugriffsüberprüfung in eine Live-Demo mit. Sehen Sie, wie eine Führungskraft die verfügbaren Richtlinienprüfungen berücksichtigt und wie die Entscheidung mit ihrem Ergebnis verbunden bleibt.

[Demo anfragen](https://easyiga.com/de/demo)[Funktionen von easyIGA entdecken →](https://easyiga.com/de/produkt)

## Quellen und Weiterführendes

Quellen geprüft am 6. Oktober 2026; Angaben zu BaFin, KWG und MaRisk geprüft am 21. Oktober 2026. Szenarien und Prozessdiagramme dienen der Veranschaulichung. Öffentliche Referenzen zu midPoint sind von den Produktnachweisen für easyIGA getrennt.

- [Evolveum: midPoint in Finanzdienstleistungen](https://evolveum.com/midpoint-in-financial-services/)

- [Evolveum: midPoint im Überblick](https://docs.evolveum.com/book/02-midpoint-overview/)

- [Evolveum: Konnektorkatalog](https://docs.evolveum.com/connectors/connectors/)

- [Europäische Union: DORA, Verordnung (EU) 2022/2554, 14. Dezember 2022](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)

Foto: [Peter Beke](https://unsplash.com/photos/lower-manhattan-skyline-in-new-york-gAB5VwuwmUM), verwendet unter der [Unsplash License](https://unsplash.com/license). Rechte geprüft am 6. Oktober 2026.
