Klare Verantwortung
für Zugriffe im öffentlichen Dienst

Zugriffsverantwortung in öffentlichen Diensten klar regeln

Eine öffentliche Organisation kann Infrastruktur gemeinsam nutzen und die Verantwortlichkeiten dennoch auf Abteilungen und Behörden verteilt halten. Ein zentrales IT-Team betreibt etwa den Verzeichnisdienst, ein HR-Team pflegt die Beschäftigungsdaten, und eine für die Anwendung verantwortliche Person entscheidet, wer einen bestimmten Dienst benötigt. Die Steuerung von Zugriffsrechten verbindet diese Verantwortlichkeiten, damit sich die Entscheidung später nachvollziehen lässt.

easyIGA unterstützt Personen dabei, Zugriffsrechte auf Unternehmens- und Organisationsanwendungen zu beantragen, zu genehmigen und zu überprüfen. Als zugrunde liegende Identity-Governance-Plattform nutzt easyIGA midPoint. Fachlich Beteiligte arbeiten mit verständlichen Anfragen und den verfügbaren Nachweisen, während IAM-Fachleute die konfigurierten Quellen, Richtlinien und Integrationen pflegen.

Die erste Frage bei einer Implementierung im öffentlichen Sektor betrifft die Verantwortlichkeit. Wer ist für den Identitätsdatensatz verantwortlich? Wer darf den beantragten Zugriff genehmigen? Welches System bestätigt, dass die genehmigte Änderung tatsächlich erfolgt ist? Eine klare Antwort gibt den Mitarbeitenden einen nutzbaren Prozess und der Organisation eine Grundlage für die Aufsicht.

Für eine Abteilungsleitung wird die Steuerung von Zugriffsrechten nützlich, wenn eine Anfrage einen Dienst nennt, den sie kennt, und ihre Verantwortung deutlich macht. Sie kann den fachlichen Bedarf beurteilen, ohne midPoint zu administrieren. easyIGA liefert diese Oberfläche für Anfragen und Überprüfungen beim Zugriff der Beschäftigten auf Anwendungen, während midPoint die konfigurierten Änderungen ausführt. Die folgenden Beispielszenarien zeigen Versetzungen, gemeinsam genutzte Dienste und Zugriffe von Dienstleistern aus Sicht der Personen, die diese Entscheidungen verantworten.

Mit einem Dienst und dessen Verantwortlichen beginnen

Eine Abteilung, die sich eine bessere Verwaltung von Zugriffsrechten wünscht, beginnt vielleicht mit einer langen Liste von Anwendungen. Ein sinnvollerer Ausgangspunkt ist ein einzelner Dienst mit einer identifizierbaren verantwortlichen Person und einer wiederkehrenden Zugriffsentscheidung. Das kann eine Anwendung für die Vorgangsbearbeitung, ein internes Aktensystem oder ein gemeinsam genutzter Verwaltungsdienst sein.

Formulieren Sie die Zugriffsbeschreibung in einer Sprache, die die für den Dienst verantwortliche Person wiedererkennt. Mitarbeitende sollten verstehen, worin sich das Einsehen eines Vorgangs von der Administration der Anwendung unterscheidet. Eine technische Verzeichnisgruppe kann die Berechtigung umsetzen, doch ihr Name allein erklärt einer genehmigenden Person aus dem Fachbereich selten die Verantwortung.

Der Katalog von easyIGA bietet Mitarbeitenden und Führungskräften einen verständlichen Einstieg. Die zugrunde liegende Konfiguration bestimmt die Rolle und den Entscheidungsweg. Die Implementierung muss die Beschreibung mit den tatsächlichen Berechtigungen im Zielsystem in Einklang halten, insbesondere wenn sich die Anwendung ändert.

Die für den Dienst verantwortliche Person sollte auch festlegen, wer welche Rolle beantragen darf und wer darüber entscheidet. Ein Organigramm weist unter Umständen eine direkte Führungskraft aus, ohne die Person zu benennen, die für den Zugriff auf eine sensible Anwendung verantwortlich ist. Diese Befugnisse müssen im Prozess ausdrücklich miteinander verknüpft sein.

Verwenden Sie in der ersten Demo eine alltägliche Anfrage. Bitten Sie die antragstellende Person zu erklären, was sie ausgewählt hat, und die genehmigende Person, die Entscheidung zu erläutern, die sie trifft. Zeigen Sie dann das protokollierte Ergebnis. So prüfen Sie den gesamten Weg von der fachlichen Bedeutung bis zum Ergebnis im Zielsystem, statt das Produkt nur nach dem Aussehen seines Katalogs zu beurteilen.

Personalwechsel unterstützen, ohne alte Berechtigungen anzuhäufen

Beschäftigte im öffentlichen Dienst können zwischen Teams wechseln oder vorübergehend einen anderen Dienst unterstützen. Die neue Rolle erfordert unter Umständen zusätzliche Zugriffsrechte, während einige bisherige Berechtigungen enden sollten. Ein Wechsel ist deshalb eine Änderung der Zugriffsbeziehung und nicht bloß eine Aktualisierung des Kontos.

midPoint stellt die konfigurierte Grundlage für den Identitätslebenszyklus und die Provisionierung bereit. Das Implementierungsteam legt fest, wie sich Änderungen in maßgeblichen Quellen auf die Rollen in angebundenen Systemen auswirken. easyIGA liefert rund um midPoint die fachliche Oberfläche für Anfragen und Überprüfungen.

Definieren Sie bei einer Versetzung den Stand vorher und nachher. Listen Sie auf, welche Berechtigungen der neuen Zuweisung folgen, welche aus einem begründeten Anlass bestehen bleiben und welche entzogen werden müssen. Berücksichtigen Sie vorübergehende Zugriffsrechte, wenn die Person noch eine Übergabe abschließt. Die Regel sollte so konkret sein, dass eine prüfende Person eine Ausnahme erklären kann, ohne sich auf ihr Gedächtnis zu verlassen.

Führen Sie den Prozess mit synthetischen Identitäten vor. Zeigen Sie die Änderung in der Quelle, die konfigurierten Entscheidungen und die Ergebnisse in den Zielsystemen. Eine erfolgreich neu vergebene Berechtigung belegt nicht, dass die alten Berechtigungen entfernt wurden. Prüfen Sie beide Seiten des Wechsels und benennen Sie jedes Zielsystem, dessen Ergebnis noch aussteht oder unbekannt ist.

Die Organisation braucht außerdem einen Prozess, um verspätete oder ungenaue Quelldaten zu korrigieren. Ist die Zuordnung zur vorgesetzten Person falsch, kann eine Anfrage bei der falschen Person landen. Legen Sie fest, welches Team die Quelle korrigiert und wie der Zugriffsprozess die Zwischenzeit behandelt. Eine verständliche Oberfläche hilft den Beteiligten, die Aufgabe zu erkennen; sie ersetzt nicht die Verantwortung für die Daten.

Gemeinsame Dienste steuern, ohne Behördengrenzen aufzuheben

Gemeinsam genutzte Infrastruktur kann doppelte Verwaltungsarbeit verringern, macht aber nicht jede Zugriffsentscheidung zu einer Entscheidung der zentralen IT. Ein gemeinsam genutzter Dienst kann mehrere Behörden mit unterschiedlichen Verantwortlichen und unterschiedlichen Gründen für die Vergabe von Zugriffsrechten unterstützen. Das Identitätsmodell sollte diese Verantwortlichkeiten erhalten.

Ermitteln Sie zuerst, welche Fakten gemeinsam genutzt werden und welche für die jeweilige beteiligte Organisation spezifisch bleiben. Eine Person kann einen einzigen Identitätsdatensatz und mehrere organisatorische Beziehungen haben. Die Bedeutung jeder Beziehung muss vereinbart sein, bevor sie in einer Zugriffsrichtlinie verwendet wird.

Wählen Sie für eine Evaluierung eine Rolle, die in einer Abteilung angemessen ist, in einer anderen aber nicht automatisch. Bitten Sie das Implementierungsteam, die vorgesehene Sichtbarkeit der Anfragen und die Genehmigungsbefugnis vorzuführen. Prüfen Sie das Verhalten des vorgeschlagenen easyIGA-Releases, statt anzunehmen, dass eine allgemeine Funktion für mehrere Organisationen die Anforderung erfüllt.

Das IAM-Team sollte erklären, wie die zugrunde liegenden Rollen und Autorisierungen in midPoint die vereinbarte Grenze abbilden. Eine fachlich beteiligte Person sollte den Umfang anhand der Beschreibung der Anfrage erkennen können. Das sind zwei sich ergänzende Prüfungen: die Genauigkeit der Konfiguration und die Verständlichkeit in der Nutzung.

Planen Sie auch organisatorische Veränderungen ein. Eine Zusammenlegung von Abteilungen kann die Verantwortlichkeit ändern, ohne dass sich die Anwendung selbst ändert. Halten Sie fest, wer die Rollenbeschreibungen und Genehmigungszuständigkeiten aktualisiert und wie die überarbeitete Konfiguration getestet wird. Das Identitätsprogramm braucht eine gepflegte Abbildung der Organisation, keine einmalige Kopie einer Struktur, die später veraltet.

Ausgelagerte Arbeit an eine interne Verantwortung binden

Ein Dienstleister kann Support- oder Projektpersonal stellen, ohne selbst darüber zu entscheiden, welche Zugriffsrechte sein Personal innerhalb der öffentlichen Organisation erhält. Die Organisation braucht einen internen Sponsor, der die Arbeit versteht und die beantragten Berechtigungen begründen kann.

Schaffen Sie eine klare Identitätsquelle für externe Mitarbeitende. Legen Sie die Beziehung zum Dienstleister, den internen Sponsor und die Angaben fest, die nötig sind, um jede Person zu unterscheiden. Verwenden Sie keine Sammelkonten als Ersatz für eine definierte Zugriffsbeziehung, wenn die Richtlinie der Organisation individuelle Verantwortlichkeit verlangt.

easyIGA bietet den jeweiligen Beteiligten einen Ort, an dem sie Zugriff auf Anwendungen beantragen und darüber entscheiden. Der Weg zur Genehmigung richtet sich weiterhin nach der konfigurierten Richtlinie. Ein Verweis auf den Vertrag kann den fachlichen Kontext erklären, sollte aber nicht automatisch zur Berechtigung für jedes System werden, das mit dem Dienstleister in Verbindung steht.

Ein sinnvoller Test umfasst eine Verlängerung und einen Wechsel des Sponsors. Externe Mitarbeitende können im selben Projekt bleiben, während die interne Führungskraft wechselt. Der Zugriffseintrag sollte an eine aktuelle Verantwortung gebunden bleiben, und die Organisation sollte wissen, wer ihn als Nächstes prüft.

Prüfen Sie am Ende des Einsatzes das Ergebnis im Zielsystem, statt sich allein auf die Abmeldung durch den Dienstleister zu verlassen. Ein genehmigter Entzug kann noch auf eine angebundene Anwendung warten. Legen Sie fest, wer nachfasst und welche Einträge nötig sind, um den Abschluss nachzuweisen. So schließt sich die Lücke zwischen einem Beschaffungsvorgang und dem tatsächlichen Zugriff auf Anwendungen.

Prüfenden nützliche Nachweise geben, ohne eine Historie zu erfinden

Die Aufsicht im öffentlichen Sektor verlangt oft eine Erklärung, warum eine Person zu einem bestimmten Zeitpunkt Zugriff hatte. Eine Liste der aktuellen Berechtigungen beantwortet nur einen Teil dieser Frage. Die Entscheidung und die verfügbare Historie sind ebenfalls relevant.

easyIGA stellt Zugriffsrechte zur Überprüfung mit dem Kontext dar, den die angebundenen Quellen und die erfassten Genehmigungseinträge liefern. „Letzte Nutzung“, „Gewährt von“ und „Genehmigt von“ können einer prüfenden Person helfen, doch diese Felder müssen ihre tatsächliche Bedeutung behalten. Die für ein Konto verantwortliche Person ist nicht automatisch die Person, die den Zugriff ursprünglich gewährt oder genehmigt hat.

Bei Anfragen, die über das Produkt gestellt werden, protokolliert easyIGA die antragstellende Person und die erfassten Genehmigungsschritte. Zugriffsrechte, die außerhalb von easyIGA vergeben wurden, werden gesondert ausgewiesen; dafür dienen die von midPoint protokollierten Erstellungsdaten. Bei historischen Einträgen kann die genehmigende oder vergebende Person fehlen; fehlende Informationen werden ausdrücklich angezeigt.

Wählen Sie für die Evaluierung eine Stichprobe mit vollständigem Eintrag und eine weitere mit unvollständiger Historie. Fragen Sie, welche Schlussfolgerung die prüfende Person jeweils stützen kann. Manche Berechtigungen werden unter Umständen nur gelegentlich benötigt; deshalb sollte fehlende jüngste Nutzung zu einer fachlichen Bewertung führen und nicht zu dem automatischen Schluss, dass der Zugriff unnötig ist.

Vereinbaren Sie den nächsten Schritt bei Unsicherheit. Die für die Anwendung verantwortliche Person muss unter Umständen eine Berechtigung untersuchen oder eine neue fachliche Entscheidung einholen. Verfolgen Sie nach einer Entscheidung zum Entzug die Änderung bis zu ihrem protokollierten Ergebnis. So wird die Überprüfung zu einem nützlichen betrieblichen Prozess und nicht bloß zu einer abgehakten Verwaltungsaufgabe.

Die Zugriffsentscheidung von ihrer Ausführung trennen

Eine Führungskraft kann Zugriff genehmigen, während die Zielanwendung nicht verfügbar ist. Ein Konfigurationsfehler kann eine Änderung stoppen, nachdem die fachliche Entscheidung bereits getroffen wurde. Zeigt die Oberfläche nur die Genehmigung an, können sowohl die antragstellende Person als auch die für die Kontrolle verantwortliche Person die tatsächliche Lage missverstehen.

easyIGA unterscheidet zwischen verifizierten, ausstehenden, fehlgeschlagenen und unbekannten Ergebnissen. Das schafft ein gemeinsames Vokabular für fachlich Beteiligte und das technische Betriebspersonal. Welches Ergebnis sich verifizieren lässt, hängt vom angebundenen System und den Nachweisen ab, die es liefert.

Im Kontext des öffentlichen Dienstes sollte die Verantwortung für die Nachverfolgung ausdrücklich geregelt sein. Die Person, die auf den Zugriff wartet, muss wissen, dass eine genehmigte Anfrage noch in Bearbeitung ist. Das Betriebspersonal braucht genug Informationen, um die betroffene Integration zu identifizieren. Die für den Dienst verantwortliche Person braucht einen Weg, einen Fall zu eskalieren, der die Arbeit beeinträchtigt.

Testen Sie während des Pilotprojekts ein nicht verfügbares Zielsystem. Beobachten Sie den Status und den anschließenden Weg zur Wiederherstellung. Dass sich eine Änderung wiederholen lässt, macht die Prüfung des endgültigen Ergebnisses nicht überflüssig. Halten Sie fest, welche Operation abgeschlossen wurde und welche offen bleibt.

Nutzen Sie dieselbe Unterscheidung, wenn Sie Berichte erstellen. Die Zahl der Genehmigungen sollte nicht als Zahl verifizierter Änderungen in Zielsystemen ausgewiesen werden. Eine Überprüfung offener Fälle kann sich dann auf die Arbeit konzentrieren, bei der noch Handlungsbedarf besteht. Das ist ein kleiner, aber folgenreicher Unterschied in der Bedeutung eines Zugriffseintrags.

Mit midPoint als Basis die technische Kontrolle behalten

midPoint ist open source. Die Plattform für Identitätsmanagement und Identity Governance ist öffentlich dokumentiert und stellt die zugrunde liegenden Mechanismen für konfigurierte Identitätsdaten, Rollen und Provisionierung bereit. easyIGA ergänzt die fachliche Oberfläche für Anfragen, Entscheidungen und Überprüfungen.

Diese Aufteilung können sowohl Organisationen bewerten, die midPoint bereits betreiben, als auch solche, die ein neues Identitätsprogramm planen. Legen Sie beim Vergleich der Optionen denselben Anwendungsumfang zugrunde. Die Frage ist, was sich für die entscheidenden Personen ändert und was bei den IAM-Fachleuten bleibt, die midPoint betreiben.

Eine technische Evaluierung sollte die Operationen in den Zielsystemen, die Quelldaten und das Rollenmodell untersuchen. Der Konnektorkatalog von midPoint ist ein Ausgangspunkt, belegt aber keine Kompatibilität mit jeder Version oder Berechtigungsstruktur einer Anwendung im öffentlichen Sektor.

Langlebige Systeme verdienen besondere Aufmerksamkeit. Eine Anwendung nimmt Kontoänderungen unter Umständen über einen anderen Mechanismus an als den, über den sie Berechtigungen bereitstellt. Dokumentieren Sie die Integrationsgrenze und jede verbleibende manuelle Arbeit. Eine bekannte Einschränkung lässt sich handhaben; eine bloß vermutete Fähigkeit kann in einem gescheiterten Abnahmetest enden.

Die Seite zum öffentlichen Sektor von Evolveum beschreibt Anwendungsfälle für midPoint. Eine easyIGA-Demo kann sich auf die Personen konzentrieren, die mit einer bestimmten Anwendung des öffentlichen Dienstes arbeiten. Lassen Sie die verantwortliche Person der Abteilung die Anfrage bewerten, das Team für gemeinsam genutzte Dienste das technische Ergebnis prüfen und die für die Kontrolle verantwortliche Person die verfügbaren Nachweise untersuchen. So orientiert sich das Gespräch an der tatsächlichen Aufteilung der Verantwortung zwischen der Behörde und ihrem Dienstleister.

Festlegen, wo Identitätsdaten hingehören

Die selbst gehostete Bereitstellung ist das Standardmodell von easyIGA. Die Organisation kann die Lösung auf ihrer eigenen Infrastruktur und in dem von ihr gewählten Rechtsraum betreiben. 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 der Bereitstellung allein beantwortet nicht jede Frage der Daten-Governance. Legen Sie fest, welche Identitätsattribute der Workflow benötigt, wer sie einsehen darf und wie Einträge aufbewahrt werden. Der Zugriff auf Personaldaten sollte einem nachvollziehbaren Zweck folgen und nicht der Annahme, dass jedes verfügbare Feld in die Identitätsplattform kopiert werden sollte.

Die Beschaffungs- und Sicherheitsprüfung sollte auch den betrieblichen Zugriff untersuchen. Klären Sie, wer den Dienst administriert, wie Updates gehandhabt werden und welche Support-Vereinbarungen gelten. Fordern Sie die tatsächlichen Bedingungen für eine von unserem Team betriebene Option an, statt aus ihrem Standort ein Service-Level oder eine Regelung zur Datenverarbeitung abzuleiten.

Benennen Sie bei selbst gehostetem Betrieb eine für den Betrieb verantwortliche Person und planen Sie den internen Aufwand ein. Backups, Wiederherstellungstests und die Pflege der Konnektoren gehören zu einem funktionierenden Dienst. Die Implementierung sollte festlegen, wie Konfigurationsänderungen geprüft werden, bevor sie sich auf Zugriffsrechte auswirken.

Für diese Fragen braucht es keine weitreichenden öffentlichen Zusagen, sondern einen konkreten Bereitstellungsvorschlag mit klar zugeordneten Verantwortlichkeiten. Nutzen Sie die Seite zur Bereitstellung und die Sicherheitsinformationen, um dieses Gespräch vorzubereiten, und halten Sie anschließend die Nachweise fest, die der Genehmigungsprozess Ihrer eigenen Organisation verlangt.

Bei der Beschaffung gleichwertige Umfänge 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 eine kommerzielle Ebene mit einem veröffentlichten jährlichen Abonnementmodell pro verwalteter Identität; die Einführung in einem vereinbarten Umfang ist enthalten. Aktuelle Preise und der vertraglich vereinbarte Funktionsumfang müssen schriftlich bestätigt werden.

Definieren Sie in einem öffentlichen Vergabeverfahren die Personengruppen und Anwendungen für alle bewerteten Optionen einheitlich. Beschäftigte, externe Mitarbeitende und Servicekonten können unterschiedliche Governance-Anforderungen mit sich bringen. Die Definition einer verwalteten Identität sollte so eindeutig sein, dass künftiges Wachstum keine unerwartete Auslegung nach sich zieht.

Benennen Sie die Verantwortlichkeiten für Integration und Migration. Ein Angebot sollte die Systeme und Operationen im Umfang, die von der Organisation erwartete Datenbereinigung und die Nachweise für die Abnahme ausweisen. Eine inbegriffene Einführung bedeutet weder eine unbegrenzte Migration noch einen festen Fertigstellungstermin unabhängig von der Qualität der Quelldaten.

Vergleichen Sie neben der Software auch Support und Betrieb. Eine Organisation mit einem etablierten midPoint-Team verteilt die Arbeit unter Umständen anders als eine, die einen neuen Dienst in Auftrag gibt. Bilden Sie diesen Unterschied im Kostenmodell ab, statt anzunehmen, dass jede Option denselben internen Aufwand erfordert.

Die Preisseite zeigt das aktuelle Modell, und der Vergleich mit midPoint erläutert die Aufteilung der Verantwortung. Nutzen Sie tatsächliche schriftliche Angebote und Ihre eigenen Zahlen zur Arbeitslast. So entsteht eine Diskussion im Beschaffungsverfahren, die sich überprüfen lässt, ohne sich auf ungemessene Einsparungen oder die Behauptung zu stützen, eine Option sei grundsätzlich günstiger.

Zugriffe von Beschäftigten und Bürgerdienste auseinanderhalten

Ein öffentliches Portal authentifiziert etwa Einwohnerinnen und Einwohner, während eine interne Anwendung festlegt, was Beschäftigte mit einem Vorgang tun dürfen. Das sind getrennte Identitätsbeziehungen. Der Governance-Umfang für Beschäftigte sollte die Berechtigungen von Beschäftigten und Dienstleistern benennen, die er steuert, ohne nahezulegen, dass easyIGA einen nationalen elektronischen Identitätsdienst bereitstellt.

Bitten Sie bei einem Beispiel aus der Vorgangsbearbeitung die für den Dienst verantwortliche Person, die interne Rolle und die Informationen zu beschreiben, auf die die Rolle den Zugriff erlaubt. Das Identitätsteam kann dann bewerten, wie diese Rolle in der Zielanwendung abgebildet ist. Dass Bürgerinnen und Bürger ein Formular einreichen können, begründet keinerlei Befugnis von Beschäftigten, den Dienst zu administrieren.

Diese Unterscheidung verbessert auch die Beschaffung. Beschreiben Sie die tatsächliche Personengruppe und die Operationen im Umfang, damit ein IGA-Angebot für Beschäftigte nicht mit einem sachfremden Dienst für Kundenidentitäten oder Authentifizierung verglichen wird. Wo die Systeme zusammenwirken, dokumentieren Sie die genehmigte Grenze und testen Sie sie ausdrücklich.

Den Workflow im öffentlichen Dienst vor dem Ausbau testen

Ein praxisnahes Pilotprojekt sollte eine klare Frage zu einem Dienst beantworten. Wählen Sie die Zugriffsrolle, die dafür verantwortlichen Personen und ein repräsentatives Zielsystem aus. Verwenden Sie zunächst synthetische Datensätze, damit für die Demo keine echten Personal- oder Vorgangsdaten geteilt werden müssen.

Nehmen Sie eine Versetzung zwischen Teams und einen Fall mit einem Dienstleister auf. Ergänzen Sie eine Anfrage ohne fachlich verantwortliche Person und eine Operation, deren Ergebnis im Zielsystem nicht sofort bestätigt werden kann. Diese Beispiele zeigen, wo die Organisation eine Richtlinienentscheidung, eine Korrektur der Quelldaten oder eine betriebliche Übergabe braucht.

Bitten Sie Personen aus dem Fachbereich zu erklären, was ihnen die Ansicht sagt. Bitten Sie die IAM-Fachleute, die Konfiguration und den Ausnahmepfad zu zeigen. Halten Sie beide Ergebnisse fest. Ein technischer Erfolg, den die genehmigende Person nicht versteht, und eine verständliche Anfrage, die sich nicht ausführen lässt, sind unterschiedliche Probleme; die Evaluierung sollte beide erkennen können.

Halten Sie bei der Abnahme das Release und den genau vorgeführten Umfang fest. Trennen Sie geplante Funktionen von den aktuell verfügbaren. Dokumentieren Sie offene Lücken bei den Nachweisen und weisen Sie ihnen einen nächsten Schritt zu. Diese Aufzeichnung macht eine spätere Ausweitung überlegter, weil das Team weiß, was die erste Phase tatsächlich belegt hat.

30-minütige Demo anfragen. Prüfen Sie dabei mit unserem Team den aktuellen easyIGA-Workflow. Bringen Sie eine Zugriffsentscheidung mit, die Ihre Organisation klarer gestalten möchte, und legen Sie damit die technischen und fachlichen Fragen fest, die eine abgegrenzte Evaluierung beantworten sollte.