Fraud Risk along the Employee Lifecycle – Onboarding macht aus Identität Zugriff
Dieser Beitrag ist der zweite Deep Dive in der Artikelserie Fraud Risk along the Employee Lifecycle.
Der Dachartikel hat den Employee Lifecycle als praktische Perspektive eingeführt, um HR Fraud Risk entlang von Hiring, Onboarding, Rollenwechseln, Incentives, Access Rights und Offboarding sichtbar zu machen.
Der erste Deep Dive, Identity Risk Starts in HR, stellte die früheste kontrollrelevante Frage:
Wer ist diese Person?
Dieser zweite Deep Dive geht einen Schritt weiter.
Sobald eine Person als legitime organisatorische Identität akzeptiert wurde, muss die Organisation eine andere Frage beantworten:
Was darf diese Person jetzt tun?
Genau darin liegt die Kontrollbedeutung des Onboardings.
Onboarding begrüsst nicht nur neue Mitarbeitende, Contractors oder externe Benutzer. Onboarding übersetzt Identität in operative Fähigkeit. Rollen werden zugewiesen, Accounts aktiviert, Zugriffe vergeben, Personen mit Workflows verbunden, Freigabepfade definiert, Arbeitsmittel ausgegeben und neue Benutzer in die Kontrollumgebung eingebettet.
Anders gesagt:
Identität schafft organisatorische Präsenz. Onboarding schafft operative Fähigkeit.
Und operative Fähigkeit ist fraud-relevant.
Onboarding als Kontrollereignis
Onboarding wird häufig als administrativer oder operativer Prozess verstanden.
Praktisch ist es jedoch der Punkt, an dem ein Personendatensatz in operative Fähigkeit umgewandelt wird.
In dieser Phase passieren mehrere kontrollrelevante Schritte:
- Identität, Vertrag und Beschäftigungsstatus werden bestätigt
- Rollen und organisatorische Zuordnungen werden erfasst
- Access Requests werden gestellt und freigegeben
- Accounts, Geräte und Kollaborationstools werden aktiviert
- Rollenvorlagen und Freigabe-Workflows werden angewendet
- Ausnahmen werden gewährt, dokumentiert oder ungelöst stehen gelassen
Aus Fraud-Risk-Sicht sind das keine blossen Onboarding-Aufgaben.
Es sind Kontrollentscheidungen.
Onboarding bestimmt, ob eine Person Systeme betreten, Daten einsehen, Transaktionen anstossen, Workflows freigeben, Stammdaten beeinflussen, vertrauliche Informationen nutzen oder an kontrollrelevanten Prozessen teilnehmen kann.
Diese Umwandlung ist entscheidend, weil viele Fraud-Schemes mehr benötigen als Absicht. Sie benötigen Fähigkeit.
Fähigkeit kann Zugriff auf ein Finance-System bedeuten.
Sie kann bedeuten, Rechnungen freizugeben.
Sie kann Einsicht in Payroll-Daten bedeuten.
Sie kann die Berechtigung umfassen, Lieferantenstammdaten zu ändern.
Sie kann Zugriff auf vertrauliche Kundendaten bedeuten.
Sie kann die Möglichkeit schaffen, Spesen einzureichen, Arbeitszeiten freizugeben, Bestellanforderungen zu erstellen, Bankdaten zu ändern oder Kontrollen zu umgehen.
Onboarding ist der Moment, in dem viele dieser Fähigkeiten zum ersten Mal entstehen.
Von Identität zu Rolle
Die erste Kontrollübersetzung im Onboarding ist meist die Rollenzuweisung.
Eine Person wird nicht nur “aktiv”. Sie wird in einer Rolle aktiv.
Diese Rolle kann Job Title, Position, Funktion, Beschäftigungsart, Projektzuordnung oder Access Profile heissen. Die Begriffe unterscheiden sich je nach Organisation. Die Kontrolllogik ist ähnlich.
Eine Rolle beschreibt, was von einer Person erwartet wird.
Sie beschreibt aber auch, was Systeme und Kontrollverantwortliche dieser Person erlauben dürfen.
Damit wird Rollenzuweisung fraud-relevant.
Eine Rolle kann unter anderem steuern:
- Systemzugriffe
- Teilnahme an Workflows
- Freigabeautorität
- Funktionstrennung (Segregation of Duties)
- Kostenstellenzuordnung
- Reporting Lines
- Datenzugriff
- physischen Zutritt
- Trainingsanforderungen
- Policy-Pflichten
- Monitoring-Erwartungen
Eine Rolle ist deshalb nicht nur ein HR-Attribut.
Sie ist eine kontrollrelevante organisatorische Tatsache.
Wenn die Rolle falsch, unvollständig, von einer anderen Person kopiert oder nur aus administrativer Bequemlichkeit gewählt wurde, starten nachgelagerte Kontrollen mit einer falschen Annahme.
Access Provisioning als Fraud Control Surface
Access Provisioning ist eines der am meisten unterschätzten Fraud-Risk-Felder im Onboarding.
Der Grund ist einfach: Zugriff wird häufig technisch durch IT umgesetzt, aber fachlich durch HR und Business begründet.
Identity and Access Management-Systeme können Benutzerkonten anlegen, Gruppen zuweisen, Authentifizierung erzwingen und Zugriffe wieder entziehen. Viele Zugriffsentscheidungen beruhen jedoch auf HR-getriebenen Informationen: Beschäftigungsstatus, Rolle, Organisationseinheit, Manager, Standort, Vertragsart und Eintrittsdatum.
Wenn diese HR-Grundlage falsch ist, kann der technische Prozess trotzdem exakt wie vorgesehen funktionieren.
Die falsche Person kann Zugriff erhalten.
Die richtige Person kann zu viel Zugriff erhalten.
Ein Contractor kann employee-ähnliche Rechte erhalten.
Eine temporäre Ausnahme kann dauerhaft werden.
Eine Rollenvorlage kann mehr Rechte enthalten, als die Person tatsächlich benötigt.
Deshalb darf Onboarding nicht auf Account-Erstellung reduziert werden.
Zugriff bedeutet nicht nur, ob sich jemand einloggen kann.
Entscheidend ist, welche organisatorische Fähigkeit eine Person nach dem Login erhält.
NIST Identity and Access Management beschreibt Identity and Access Management als Fähigkeit, die dazu beiträgt, dass die richtigen Personen und Dinge zur richtigen Zeit den richtigen Zugriff auf die richtigen Ressourcen haben. Für Workforce-Kontexte ist diese Formulierung hilfreich, weil “richtiger Zugriff” nicht nur von Technologie abhängt, sondern auch von Rolle, Status und organisatorischem Kontext.
Genau hier kann Onboarding die Voraussetzungen für späteren Missbrauch von Zugriffsrechten, schwache Funktionstrennung (Segregation of Duties), Umgehung interner Kontrollen (Control Override), Umgehung von Freigabelimiten oder Datenmanipulation schaffen.
Das Risiko von Access Templates
Role-based Access Templates sind nützlich.
Sie beschleunigen Onboarding.
Sie reduzieren manuelle Einzelentscheidungen.
Sie schaffen Konsistenz.
Sie können Standardisierung, Nachvollziehbarkeit und Effizienz unterstützen.
Gleichzeitig schaffen sie ein spezifisches Fraud Risk: das Risiko, dass eine Vorlage das fachliche Urteil ersetzt.
Eine Vorlage kann veraltet sein.
Sie kann Legacy Rights enthalten.
Sie kann für eine breitere Rolle entwickelt worden sein als jene, die die neue Person tatsächlich ausübt.
Sie kann Prozessänderungen nicht abbilden.
Sie kann Zugriffsrechte enthalten, die irgendwann aus Bequemlichkeit ergänzt und nie wieder entfernt wurden.
Sie kann von einer leistungsstarken Mitarbeitenden, einem Vorgänger oder einer Führungsperson kopiert worden sein, ohne zu prüfen, ob die neue Person dieselbe Autorität wirklich benötigt.
Das Problem ist nicht die Existenz von Rollenvorlagen.
Das Problem ist unkontrolliertes Vertrauen in sie.
Eine Rollenvorlage sollte die Frage beantworten:
Welcher Zugriff ist für diese Rolle erforderlich?
Sie sollte nicht stillschweigend zur Antwort auf eine andere Frage werden:
Welchen Zugriff hatte jemand Ähnliches früher einmal?
Initialer Zugriff kann zum Langzeitrisiko werden
Onboarding ist häufig ein Moment mit hohem Zeitdruck.
Die neue Person soll schnell produktiv werden. Der Manager will keine Verzögerung. IT braucht vollständige Requests. HR möchte einen reibungslosen Start. Business-Teams behandeln Zugriff oft als dringend.
Daraus entsteht ein bekanntes Muster:
Zugriff wird “vorerst” gewährt.
Zusätzliche Rechte werden “zur Sicherheit” ergänzt.
Ein breites Rollenprofil wird genutzt, “damit es keine Verzögerung gibt”.
Temporärer Zugriff wird vergeben, “bis der Prozess geklärt ist”.
Eine Ausnahme wird genehmigt, “weil die Person morgen startet”.
Jede dieser Entscheidungen kann isoliert betrachtet nachvollziehbar sein.
Fraud Risk entsteht jedoch, wenn temporärer Zugriff nicht überprüft, breiter Zugriff nicht reduziert und Onboarding-Ausnahmen Teil der dauerhaften Kontrollrealität werden.
Deshalb sind Onboarding und spätere Rollenwechsel eng miteinander verbunden.
Ein beim Onboarding gewährter Zugriff kann jahrelang im Hintergrund bestehen bleiben. Sichtbar wird er vielleicht erst, wenn die Person die Rolle wechselt, in eine andere Abteilung geht, zusätzliche Autorität erhält oder eine alte Berechtigung ausnutzt.
Das Risiko entsteht früh.
Es kann sich deutlich später materialisieren.
Funktionstrennung beginnt beim Onboarding
Funktionstrennung (Segregation of Duties) wird oft im Zusammenhang mit Finance-Systemen, Procurement-Prozessen oder ERP-Kontrollen diskutiert.
Das ist richtig, aber zu spät, wenn widersprüchliche Berechtigungen bereits vergeben wurden.
Aus Employee-Lifecycle-Sicht sollte Funktionstrennung beim Onboarding beginnen.
Die Frage ist nicht nur, ob eine Transaktion später von der richtigen Person freigegeben wurde.
Die Frage ist auch, ob die Organisation verhindert hat, dass toxische Kombinationen von Zugriff und Autorität überhaupt entstehen.
Beispiele sind:
- Lieferanten anlegen und Lieferantenzahlungen freigeben
- Lieferantenbankdaten ändern und Zahlungen auslösen
- Rechnungen erfassen und Rechnungen freigeben
- Spesen einreichen und Spesen genehmigen
- Payroll-Daten pflegen und Payroll-Änderungen freigeben
- Bestellungen erstellen und Wareneingänge bestätigen
- Benutzerrechte administrieren und eigene Zugriffe genehmigen
- Stammdaten ändern und darauf bezogene Transaktionen ausführen
Solche Kombinationen erzeugen nicht automatisch Fraud.
Sie reduzieren jedoch die Notwendigkeit von Kollusion, schwächen detektive Kontrollen und erleichtern die Umgehung interner Kontrollen (Control Override).
Onboarding ist deshalb ein kritischer Zeitpunkt für präventive Funktionstrennung.
Rolle, Zugriff und Autorität sind nicht dasselbe
Eine häufige Schwäche im Onboarding liegt darin, Rolle, Zugriff und Autorität nicht sauber zu trennen.
Diese drei Begriffe hängen zusammen, sind aber nicht identisch.
Rolle beschreibt die organisatorische Funktion.
Zugriff beschreibt, welche Systeme, Daten und Workflows eine Person nutzen kann.
Autorität beschreibt, was eine Person entscheiden, genehmigen, freigeben oder übersteuern darf.
Eine Mitarbeitende kann Zugriff auf ein Procurement-System haben, ohne Purchase Orders genehmigen zu dürfen.
Eine Finance-Person kann Payroll-Daten sehen, ohne Bankdaten ändern zu dürfen.
Ein Manager kann Spesen genehmigen, ohne Administratorrechte zu besitzen.
Eine Projektleitung kann Ausgaben beeinflussen, ohne formale Budgetverantwortung zu haben.
Fraud Risk entsteht häufig dort, wo diese Unterscheidungen verschwimmen.
Eine Person “besitzt” formal keinen Prozess, kann ihn aber praktisch beeinflussen.
Eine Person ist keine Systemadministratorin, hat aber ausreichend Zugriff, um relevante Daten zu ändern.
Eine Person ist nicht offizielle Freigeberin, kann aber Workflows vorbereiten, weiterleiten oder die entscheidende Freigabe faktisch beeinflussen.
Schwach gesteuerte Freigabeautorität kann später die Umgehung interner Kontrollen, Management Override of Controls oder die Umgehung von Freigabelimiten unterstützen.
Onboarding sollte deshalb nicht nur fragen:
Welche Systeme benötigt diese Person?
Es sollte auch fragen:
Was kann diese Person innerhalb dieser Systeme tun?
Und:
Welche Entscheidungen akzeptiert die Organisation von dieser Person?
Externe Benutzer: die versteckte Onboarding-Lücke
Einige der grössten Onboarding-Risiken entstehen nicht bei Mitarbeitenden.
Sie entstehen bei Personen, die wie Mitarbeitende handeln dürfen, aber nicht wie Mitarbeitende gesteuert werden.
Contractors, Consultants, temporäre Arbeitskräfte, Vendor Users, Outsourcing-Personal und projektbasierte externe Benutzer können Zugriffe erhalten, die operativ sehr nahe an Mitarbeiterzugriffen liegen.
In manchen Organisationen werden solche Benutzer ausserhalb der normalen HR-Prozesse onboarded.
Sie kommen über IT, Procurement, Vendor Management, ein Projektbüro oder eine lokale Business Unit in die Organisation.
Dadurch kann fragmentierte Verantwortung entstehen.
HR besitzt den Datensatz möglicherweise nicht.
IT kennt den fachlichen Zweck möglicherweise nicht.
Procurement kennt den Lieferanten, aber nicht zwingend den einzelnen Benutzer.
Der Business Manager geht vielleicht davon aus, dass jemand anderes Enddaten, Access Reviews und Offboarding steuert.
Genau hier wird externer Zugriff zur versteckten Onboarding-Lücke.
Externe Benutzer dürfen nicht zwischen Governance-Modellen verschwinden.
Sie sind rechtlich vielleicht keine Mitarbeitenden. Trotzdem können sie employee-ähnliche Risiken schaffen: Missbrauch von Zugriffsrechten, Unklarheiten im Prüfpfad (Audit Trail), Insider Risk, Datenschutzrecht-Exponierung, GDPR / DSGVO-Risiken und Residual Access nach Ende des Engagements.
Beim Onboarding sollte jede externe Identität mindestens folgende Elemente haben:
- einen benannten fachlichen Owner
- einen definierten Zugriffszweck
- ein definiertes Startdatum
- ein definiertes Enddatum
- eine klare Rolle oder Zuordnung
- Zugriff begrenzt auf das Mandat
- Review-Pflichten
- klare Offboarding-Verantwortung
Ohne diese Elemente kann externer Zugriff zu einem langfristigen Kontrollblindspot werden.
Das Identity Lifecycle Management Playbook ist in diesem Zusammenhang nützlich, weil es Identität als etwas versteht, das über Zeit angelegt, verändert, gepflegt und deaktiviert werden muss. Diese Lifecycle-Sicht ist gerade für Contractors und andere externe Benutzer besonders relevant.
Onboarding und Zero-Trust-Denken
Die Employee Lifecycle Fraud Risk Lens ist kein Cybersecurity-Modell.
Es gibt aber eine nützliche Verbindung zum Zero-Trust-Denken.
NIST SP 800-207 Zero Trust Architecture beschreibt Zero Trust als Ansatz, der sich von statischen, netzwerkbasierten Annahmen löst und Benutzer, Assets und Ressourcen in den Mittelpunkt stellt. Zudem betont NIST, dass Authentication und Authorization getrennte Funktionen sind, bevor eine Session zu einer Unternehmensressource entsteht.
Für HR Fraud Risk lautet die praktische Lehre nicht, dass jede Organisation eine vollständige Zero Trust Architecture einführen muss.
Die praktische Lehre ist einfacher:
Zugriff sollte nicht gewährt werden, weil eine Person “innen” ist.
Zugriff sollte gewährt werden, weil die Person eine verifizierte Identität, eine legitime Rolle, einen aktuellen Bedarf und ein angemessenes Autoritätsniveau hat.
Onboarding ist der Moment, in dem diese Bedingungen erstmals geprüft werden sollten.
Typische Rollen- und Zugriffsszenarien
Rollen- und Zugriffsrisiken im Onboarding können sehr unterschiedlich auftreten.
1. Übermässiger initialer Zugriff
Eine neue Person erhält breitere Zugriffe, als ihre tatsächliche Rolle erfordert.
Das kann passieren, weil Rollenvorlagen zu breit sind, Zugriff von einer anderen Person kopiert wird oder Manager Rechte “zur Sicherheit” beantragen.
2. Falsche Rollenzuweisung
Die Person wird der falschen Rolle, Job Family, Organisationseinheit oder Beschäftigungskategorie zugeordnet.
Nachgelagerte Systeme können dann Zugriff auf Basis einer unzutreffenden Kontrollannahme vergeben.
3. Schwache Funktionstrennung
Widersprüchliche Berechtigungen werden im Onboarding vergeben, weil Funktionstrennung (Segregation of Duties) unvollständig, manuell, umgangen oder nicht mit HR-Rollendaten verbunden ist.
4. Nicht überprüfte Onboarding-Ausnahmen
Dringender Zugriff wird gewährt, bevor alle Standardprüfungen abgeschlossen sind.
Die Ausnahme wird nicht verfolgt, nicht überprüft und nicht geschlossen.
5. Contractor-Zugriff ohne Governance
Externe Benutzer erhalten employee-ähnliche Zugriffe ohne vergleichbare Sponsorship, Review-Disziplin, Enddaten oder Offboarding-Kontrollen.
6. Zu früh gewährte Freigabeautorität
Eine Person erhält Workflow-Freigaben, Zeichnungsrechte, Budgetautorität oder Release Permissions, bevor Rolle, Training, Delegation oder Kontrollverantwortung klar sind.
7. Zugriff ohne Verantwortlichkeit
Eine Person erhält Zugriff, aber niemand besitzt die Entscheidung, überprüft ihre fortdauernde Angemessenheit oder versteht die Kontrollwirkung.
8. Sensibler Zugriff in kritischen Prozessen
Eine Person erhält Zugriff auf Finance, Payroll, Procurement, HR Master Data, Systemadministration oder andere Bereiche mit hoher Risikobelastung kritischer Prozesse, ohne dass ein erhöhter Review erfolgt.
Schwache Onboarding-Kontrollen können payroll-bezogene Risiken unterstützen, einschliesslich Ghost Employee-Szenarien, übermässigem Zugriff auf Payroll-Daten oder unautorisierten Änderungen an Employee Master Data.
Red Flags
Rollen- und zugriffsbezogene Red Flags im Onboarding erscheinen oft als Prozessabkürzungen.
Einzeln betrachtet können sie effizient wirken.
In Kombination können sie jedoch auf eine schwache Zugriffskontrollumgebung hinweisen.
Relevante Red Flags sind unter anderem:
- Zugriff wird gewährt, bevor Beschäftigung oder Engagement vollständig genehmigt sind
- Access Requests werden ohne klare Rolle oder Business Purpose gestellt
- Rollenvorlagen wurden lange nicht überprüft
- Zugriff wird von einer anderen Person kopiert, ohne dokumentierte Begründung
- breiter Zugriff wird vergeben, um Onboarding-Verzögerungen zu vermeiden
- “temporärer” Zugriff hat kein Ablaufdatum
- Emergency Access wird nach Aktivierung nicht überprüft
- Funktionstrennung (Segregation of Duties) fehlt oder wird nicht wirksam geprüft
- Konflikte bei der Funktionstrennung werden ohne dokumentierte Risikoakzeptanz genehmigt
- externe Benutzer haben keinen benannten fachlichen Owner
- Contractors haben keine Enddaten
- Manager genehmigen Zugriffe, die sie fachlich nicht verstehen
- Privileged Access wird im Standard-Onboarding vergeben
- Zugriff auf Finance, Payroll, Procurement oder HR-Systeme erfolgt ohne erweiterten Review
- HR-Rolle, Identity and Access Management-Rolle und tatsächliche Business-Funktion passen nicht zusammen
- Freigabeautorität ist aktiv, bevor Training oder Delegation abgeschlossen sind
- Benutzerkonten sind aktiv, bevor Geräte, Verträge oder Rollenzuweisungen vollständig dokumentiert sind
Keine dieser Red Flags beweist für sich allein Fraud.
Jede davon sollte aber eine Kontrollfrage auslösen.
Kontrollfragen
Ein praktisches Fraud Risk Assessment kann beim Onboarding beginnen.
Rollenzuweisung
- Wer bestimmt die Rolle, die für Access Provisioning verwendet wird?
- Beruht die Rolle auf der tatsächlichen Funktion oder auf administrativer Bequemlichkeit?
- Sind Rollendefinitionen aktuell?
- Sind sensible Rollen klar identifiziert?
- Passt die zugewiesene Rolle zu Beschäftigungsart, Organisationseinheit und Manager?
Access Provisioning
- Welche Systeme verlassen sich auf HR-Daten, um Zugriff zu erzeugen oder zu genehmigen?
- Welche Access Rights werden beim Onboarding automatisch vergeben?
- Werden Access Templates periodisch überprüft?
- Können Manager Zugriff ausserhalb standardisierter Rollenprofile beantragen?
- Sind Access Requests mit Business Purpose und Rollenbedarf verknüpft?
Funktionstrennung
- Wird Funktionstrennung (Segregation of Duties) geprüft, bevor Zugriff vergeben wird?
- Decken diese Prüfungen sowohl Systemberechtigungen als auch Freigabeautorität ab?
- Wer darf Konflikte bei der Funktionstrennung genehmigen?
- Werden Konfliktgenehmigungen dokumentiert und periodisch überprüft?
- Sind kompensierende Kontrollen definiert, wenn Konflikte akzeptiert werden?
Autorität
- Wann erhält eine neue Person Freigabeautorität?
- Sind Freigabelimiten mit Rolle, Seniorität, Training oder Delegationsregeln verknüpft?
- Kann eine Person Transaktionen genehmigen, bevor ihre Rolle vollständig bestätigt ist?
- Sind Workflow-Berechtigungen mit formaler Autorität abgestimmt?
- Werden Manager-Wechsel in Freigabepfaden nachvollzogen?
Externe Benutzer
- Werden Contractors und Vendor Users über einen kontrollierten Prozess onboarded?
- Hat jeder externe Benutzer einen benannten fachlichen Owner?
- Sind Zugriffszweck, Umfang und Enddatum dokumentiert?
- Werden externe Benutzer in Access Reviews einbezogen?
- Gibt es eine klare Verbindung zwischen Vertragsdauer und Zugriffsdauer?
Ausnahmen
- Wie werden dringende Onboarding-Ausnahmen genehmigt?
- Sind Ausnahmen zeitlich begrenzt?
- Wer überprüft sie nach dem Onboarding?
- Sind Ausnahmen für Interne Kontrollen, Compliance oder IT Security sichtbar?
- Werden wiederholte Ausnahmen als Prozessschwäche analysiert?
Praktische Kontrollmassnahmen
Rollen- und Zugriffsrisiken lassen sich nicht durch eine einzelne Freigabe steuern.
Es braucht eine Kontrollkette über HR, IT, Business Management, Compliance, Finance und Interne Kontrollen hinweg.
Onboarding als Access-Control-Event behandeln
Onboarding sollte als der Punkt verstanden werden, an dem Identität zu operativer Fähigkeit wird.
Die Vergabe von Zugriff ist eine Kontrollentscheidung, nicht nur eine technische Folgeaufgabe.
Rollen- und Zugriffskatalog pflegen
Rollen sollten mit Standardzugriffen, Freigaberechten, sensiblen Berechtigungen und Funktionstrennung (Segregation of Duties) verknüpft werden.
Dieser Katalog sollte überprüft werden, wenn sich Prozesse, Systeme oder Organisationsstrukturen ändern.
Least Privilege von Beginn an anwenden
Initialer Zugriff sollte auf das beschränkt sein, was die Person für ihre Rolle benötigt.
Zusätzlicher Zugriff kann später auf Basis eines dokumentierten Bedarfs vergeben werden.
Das ist meist sicherer, als mit breitem Zugriff zu starten und später zu versuchen, ihn wieder zu reduzieren.
Rollenvorlagen periodisch überprüfen
Rollenvorlagen sollten nicht statisch sein.
Sie sollten auf veraltete Rechte, übermässige Berechtigungen, Konflikte bei der Funktionstrennung und Änderungen in Geschäftsprozessen geprüft werden.
Antrag, Genehmigung und Provisioning trennen
Die Person, die Zugriff beantragt, die Person, die Zugriff genehmigt, und die Person, die Zugriff technisch provisioniert, sollten in sensiblen Fällen nicht identisch sein.
Das gilt besonders für Privileged Access und finance-relevante Systeme.
Onboarding-Ausnahmen kontrollieren
Dringender Zugriff kann notwendig sein.
Ausnahmen sollten jedoch dokumentiert, zeitlich begrenzt, risikobewertet und nachträglich überprüft werden.
Eine Ausnahme ohne Abschluss ist kein temporärer Zugriff. Sie ist unkontrollierter Zugriff.
Funktionstrennung früh integrieren
Funktionstrennung (Segregation of Duties) sollte geprüft werden, bevor Zugriff vergeben wird, nicht erst nachdem Transaktionen stattfinden.
Präventive Prüfungen sind besonders wichtig in Finance, Payroll, Procurement, Master Data Management und Systemadministration.
Autorität getrennt von Zugriff definieren
Zugriff auf ein System sollte nicht automatisch Freigabeautorität bedeuten.
Freigabelimiten, Delegationsrechte und Workflow-Rollen sollten separat vergeben und überprüft werden.
Externe Benutzer in dieselbe Kontrolllogik einbeziehen
Contractors und Vendor Users sollten nicht ausserhalb des Identity- und Access-Governance-Modells stehen.
Ihr Zugriff sollte gesponsort, begrenzt, zeitlich befristet und überprüfbar sein.
Prüfpfad sichern
Die Organisation sollte nachvollziehen können, wer Zugriff beantragt hat, wer ihn genehmigt hat, welche Rolle verwendet wurde, welche Vorlage angewendet wurde, welche Ausnahmen gewährt wurden und welche Systeme aktiviert wurden.
Forensische Relevanz
Wenn ein Fall Missbrauch von Zugriffsrechten, Lieferantenbetrug, Payroll Fraud, Spesenbetrug, Procurement Fraud oder Datenmanipulation betrifft, beginnt die Untersuchung häufig bei der Transaktion.
Wer hat die Daten erfasst?
Wer hat die Änderung freigegeben?
Wer hat die Zahlung ausgelöst?
Wer hat auf das System zugegriffen?
Wer hat das Credential genutzt?
Diese Fragen sind notwendig.
Die Employee Lifecycle Fraud Risk Lens ergänzt sie jedoch um eine frühere Frage:
Warum hatte diese Person diese Fähigkeit überhaupt?
Relevante Beweismittel können unter anderem sein:
- HR-Onboarding-Unterlagen
- Dokumentation der Rollenzuweisung
- Access Request Tickets
- Access Approval Records
- Identity and Access Management Provisioning Logs
- Historie von Rollenvorlagen
- Ergebnisse von Funktionstrennungsprüfungen
- Ausnahmegenehmigungen
- Manager-Freigaben
- Workflow-Konfigurationen
- Freigabe- und Autoritätsmatrizen
- Privileged Access Records
- Trainings- und Delegationsnachweise
- Contractor-Onboarding-Unterlagen
- Systemaktivierungszeitpunkte
- Geräteausgabe- oder Versandnachweise
- Access Review Results
Das ist besonders wichtig, wenn die Handlung über formal gültigen Zugriff erfolgte.
Eine Transaktion kann über ein legitimes Benutzerkonto erfasst worden sein.
Ein Workflow kann die Freigabe akzeptiert haben.
Ein System kann die Änderung zugelassen haben.
Ein Prüfpfad (Audit Trail) kann eine benannte Person zeigen.
Das eigentliche Problem kann trotzdem upstream liegen: Diese Person hätte diese Rolle, dieses Zugriffsrecht oder diese Freigabeautorität gar nicht erhalten dürfen.
Warum das wichtig ist
Onboarding wird oft als Start der Produktivität gesehen.
Aus Fraud-Risk-Sicht ist es auch der Start operativer Fähigkeit.
Diese Fähigkeit kann angemessen, proportional und kontrolliert sein.
Oder sie kann übermässig, inkonsistent und schlecht gesteuert sein.
Der Unterschied ist im Moment des Onboardings nicht immer sichtbar.
Er wird vielleicht erst später sichtbar, wenn Zugriff missbraucht, eine Kontrolle umgangen, ein Konflikt bei der Funktionstrennung ausgenutzt oder ein externer Benutzer über den ursprünglichen Zweck hinaus aktiv bleibt.
Deshalb gehört Onboarding in die Fraud-Risk-Diskussion.
Nicht weil jede Onboarding-Schwäche Fraud ist.
Sondern weil Onboarding die Rollen-, Zugriffs- und Autoritätsannahmen schafft, auf die spätere Kontrollen vertrauen.
Fazit
Fraud Risk beginnt nicht immer mit einer Transaktion.
Manchmal beginnt es damit, dass eine legitime Identität in übermässige, unklare oder schlecht gesteuerte Fähigkeit umgewandelt wird.
Der erste Deep Dive dieser Serie fokussierte auf Identität.
Dieser zweite Deep Dive fokussierte auf das, was danach passiert.
Sobald die Organisation akzeptiert, dass eine Person hier existiert, bestimmt Onboarding, was diese Person hier tun kann.
Rollenzuweisung, Access Provisioning und Freigabeautorität sind deshalb keine administrativen Details.
Sie sind kontrollrelevante Tatsachen.
Wenn Onboarding übermässigen Zugriff, unklare Autorität, schwache Funktionstrennung oder unkontrollierte externe Benutzer schafft, operieren nachgelagerte Kontrollen auf einer fragilen Grundlage.
Die Employee Lifecycle Fraud Risk Lens hilft, diesen Zusammenhang sichtbar zu machen.
Bevor Organisationen fragen, ob eine Transaktion ordnungsgemäss freigegeben wurde, sollten sie auch fragen:
Wurde die Rolle korrekt zugewiesen, war der Zugriff proportional und wurde Autorität von Beginn an richtig kontrolliert?
Weitere Perspektiven
Dieser Beitrag ist Teil der Artikelserie Fraud Risk along the Employee Lifecycle.
Der Dachartikel hat den Employee Lifecycle als praktische Perspektive auf Fraud Risk in Hiring, Onboarding, Rollenwechseln, Incentives, Access Rights und Offboarding eingeführt.
Der erste Deep Dive untersuchte Identity Risk.
Dieser zweite Deep Dive fokussierte auf Onboarding, Rollenzuweisung und Access Creation.
Der nächste Beitrag wird die Move-Phase untersuchen: wie Rollenwechsel, interne Transfers und Reorganisationen Control Drift, kumulierte Zugriffe und veraltete Autorität schaffen können.
Verwandte Begriffe
- Interne Kontrollen
- Fraud Risk Assessment
- Betrugsprävention
- Missbrauch von Zugriffsrechten
- Access Rights Abuse
- Funktionstrennung (Segregation of Duties)
- Umgehung interner Kontrollen (Control Override)
- Management Override of Controls
- Umgehung von Freigabelimiten
- Red Flags
- Prüfpfad (Audit Trail)
- Datenmanipulation
- Spesenbetrug
- Expense Reimbursement Fraud
- Ghost Employee
- Lieferantenbetrug
- Vendor Fraud
- Risikobelastung kritischer Prozesse
- Datenschutzrecht
- GDPR / DSGVO
- Identitätsbetrug
- Employee Lifecycle Fraud Risk Lens
- Employee Lifecycle
- HR Fraud Risk
- Onboarding
- Identity and Access Management
- Access Rights
- Role-Based Access Control
- Least Privilege
- Privileged Access
- Approval Authority
- Contractor Risk
- Joiner-Mover-Leaver
- HR Master Data
- Data Integrity
- Payroll Fraud
- Procurement Fraud
- Zero Trust