Drittanbieter-Zugriff: Die schwächste Stelle Ihres Audits - und wie Sie sie schließen

Wenn ein Auditor Ihre Umgebung unter die Lupe nimmt, dreht sich die erste Frage selten um Ihre eigenen Mitarbeitenden. Es geht um alle anderen. Auftragnehmer, Berater, Integrationspartner, OAuth-Token, die vor drei Projekten an einen Anbieter ausgestellt wurden - externe Identitäten, die Ihre Systeme berührt haben, aber nie im HRIS aufgetaucht sind. Genau dort liegen die Lücken, und erfahrene Auditoren wissen das.

Das Problem ist nicht mangelndes Bewusstsein für Drittanbieter-Zugriffe. Das Problem ist, dass die Standard-JML-Automatisierung (Joiner-Mover-Leaver), die Ihre Mitarbeitenden steuert, nie dafür ausgelegt war, Personen ohne HR-Datensatz abzudecken. Wenn das Engagement eines Auftragnehmers endet, gibt es kein Beendigungsereignis in Workday, das die Deprovisionierung auslöst. Das Ergebnis: verwaiste Konten, überprivilegierte Berechtigungen und ein Audit-Trail, der bei "wir glauben, den Zugriff entzogen zu haben" aufhört.

Das ist 2026 keine vertretbare Position mehr.

Warum Drittanbieter-Zugriff ein Hotspot für Sicherheitsvorfälle und Audits ist

Die Zahlen sind eindeutig. Mindestens 35,5 % aller Datenpannen im Jahr 2024 gingen auf Drittanbieter-Kompromittierungen zurück - ein Anstieg von 6,5 % gegenüber 2023^[1]. Die durchschnittlichen Kosten einer Drittanbieter-Datenpanne überstiegen 2024 laut IBMs Cost of a Data Breach Report 5,08 Millionen US-Dollar^[2]. Und ^[2] zeigt, dass Drittanbieter-Vorfälle in der Behebung rund 40 % teurer sind als interne Vorfälle - weil die Komplexität mehrere Unternehmen, Rechtssysteme und Datenumgebungen umfasst.

Die Angriffsfläche ist groß und wächst weiter. Das U.S. Government Accountability Office schätzt, dass Zeitarbeitskräfte 30-40 % des US-amerikanischen Arbeitsmarkts ausmachen^[3]. Diese Arbeitskräfte - Auftragnehmer, Berater, Freiberufler und Integrationspartner - benötigen regelmäßig Zugriff auf Ihren SaaS-Stack, Ihre Code-Repositories und Ihre internen Tools. Da sie jedoch nicht im HRIS erfasst sind, profitieren sie nicht von den automatisierten Lifecycle-Kontrollen, die für Festangestellte gelten.

Das Muster des Zugangskontrollversagens ist vorhersehbar. 70 % der Drittanbieter-Datenpannen betreffen übermäßig privilegierte Konten, wie Censinet-Forschungen zeigen^[4]. Auftragnehmer werden mit weitreichendem Zugriff "für alle Fälle" ongeboardet, ihr Engagement endet - und niemand löst einen Deprovisionierungs-Workflow aus, weil es keinen gibt. Das Konto liegt brach: gültige Zugangsdaten, kein aktiver Eigentümer, keine Überwachung.

Mehr als 30 % der Organisationen benötigen länger als drei Tage, um nach dem Ausscheiden einer Person alle Systemzugriffe zu entziehen - und manche schließen diesen Prozess nie vollständig ab^[5]. Bei Auftragnehmern, wo kein HR-Beendigungsereignis die Automatisierung auslöst, ist diese Zahl mit hoher Wahrscheinlichkeit noch schlechter.

Die sechs Belege, die jeder Auditor einfordern wird

Ob Sie sich auf SOC 2 Type II, ISO 27001, HIPAA, PCI DSS oder DORA vorbereiten - die Anforderungen an Identity-Belege für Dritte laufen auf dieselben sechs Fragen hinaus. Wenn Sie nicht alle sechs mit strukturierten, mit Zeitstempel versehenen Aufzeichnungen beantworten können - keine Screenshots, keine Excel-Exporte -, haben Sie einen Befund.

1. Wem wurde Zugriff gewährt? Eine vollständige Übersicht aller externen Identitäten, die während des Prüfzeitraums Zugriff hatten. Dazu gehören Auftragnehmer, Berater, Integrations-Service-Accounts und OAuth-Token, die an Partneranwendungen ausgestellt wurden. "Wir glauben, es waren etwa zwölf Personen" ist keine Antwort.

2. Von wem, und auf welcher Grundlage? Jede Zugriffsgenehmigung muss einen dokumentierten Genehmiger haben. Auditoren wollen sehen, dass der Zugriff beantragt, geprüft und von einer befugten Person genehmigt wurde - nicht einfach von der IT provisioniert, weil ein Manager eine Slack-Nachricht geschickt hat.

3. Wann wurde der Zugriff gewährt, und welchen Umfang hatte er? Zeitstempel der Provisionierung, die spezifisch gewährten Berechtigungen (nicht nur "Zugriff auf Jira" - welche Projekte, welche Berechtigungsstufe) und die geschäftliche Begründung. ^[6] zieht Stichproben von Zugriffsereignissen und prüft, ob Kontrollen über den 6- bis 12-monatigen Prüfzeitraum tatsächlich durchgesetzt wurden. Verteilte, manuelle Aufzeichnungen bestehen diesen Test nicht.

4. War der Zugriff zeitlich begrenzt? Regulierungsbehörden und Auditoren erwarten zunehmend, dass externer Zugriff ein explizites Ablaufdatum trägt. Dauerhafter Zugriff für Auftragnehmer - Zugriff, der unbegrenzt bestehen bleibt, bis sich jemand daran erinnert, ihn zu entziehen - ist unter allen gängigen Frameworks eine Kontrollschwäche. Der benötigte Beleg ist ein bei der Provisionierung festgelegtes, dokumentiertes Ablaufdatum - keine nachträgliche Behauptung, man hätte den Zugriff entzogen.

5. Wurde der Zugriff während des Engagements überprüft? Bei längerfristigen Auftragnehmern wird eine regelmäßige Zugangszertifizierung erwartet. Hat jemand mit fachlichem Kontext - mindestens quartalsweise - bestätigt, dass die Berechtigungen noch angemessen sind? ^[6] mit Zugriff auf die Karteninhaberdaten-Umgebung.

6. Wurde der Zugriff beim Ausscheiden entzogen, und wann? Der Zeitstempel der Deprovisionierung, die Bestätigung, dass alle Systeme abgedeckt wurden (nicht nur die primäre Anwendung), und der Nachweis, dass kein Restzugriff verblieben ist. Hier scheitern die meisten Organisationen - nicht weil sie den Zugriff nicht entzogen haben, sondern weil sie es in einem SaaS-lastigen Stack nicht lückenlos belegen können.

Die JML-Lücke: Warum Auftragnehmer durchs Raster fallen

Standard-JML-Automatisierung ist an Ihr HRIS geknüpft. Wenn ein Mitarbeitender eintritt, löst sein Workday-Datensatz die Provisionierung aus. Wenn er das Unternehmen verlässt, löst das Beendigungsereignis die Deprovisionierung aus. Das System funktioniert - für Festangestellte.

Auftragnehmer haben keine Workday-Datensätze. Sie werden über Beschaffungssysteme, SOW-Dokumente oder informelle Absprachen verwaltet. Wenn ihr Engagement endet, gibt es kein Systemereignis. Der Zugriff bleibt einfach... bestehen.

Das ist die strukturelle Lücke, die Drittanbieter-Identity-Governance zu einem eigenständigen Problem macht - verschieden vom Lifecycle-Management der Belegschaft. ^[7] - Konten, die aktiv bleiben, nachdem die dahinterstehende Identität verschwunden ist - sind überproportional häufig ein Auftragnehmer-Problem, eben weil der Offboarding-Auslöser in den Systemen, die die Automatisierung antreiben, nicht existiert.

Die Lösung erfordert zwei Dinge, die zusammenwirken: eine verlässliche Quelle für Auftragnehmer-Identitäten (getrennt vom HRIS oder als Erweiterung davon) und Governance-Tooling, das auf Basis dieser Quelle über den gesamten Applikationslandschaft hinweg handeln kann - einschließlich der Long-Tail-SaaS-Tools, die kein SCIM unterstützen und daher vollständig außerhalb der Standard-Provisionierungsautomatisierung liegen.

Zeitbasierter Zugriff: Der richtige Standard für externe Mitarbeitende

Die sauberste Lösung für das Auftragnehmer-Offboarding-Problem besteht darin, dauerhaften Zugriff zur Ausnahme statt zur Regel zu machen. ^[8] provisioniert Berechtigungen für ein definiertes Zeitfenster und entzieht sie automatisch, wenn dieses Fenster schließt - kein manueller Auslöser erforderlich.

Für Auftragnehmer passt das natürlich zur Engagement-Struktur. Ein Berater, der für ein 90-Tage-Projekt engagiert wird, erhält Zugriff für 90 Tage provisioniert. Verlängert sich das Engagement, wird der Zugriff über einen expliziten Approval-Workflow erneuert. Endet es früher, übernimmt das Ablaufdatum die Entziehung. Der Audit-Trail ist eingebaut: Provisionierungs-Zeitstempel, Ablaufdatum, Genehmiger, Umfang.

^[9] formalisiert dieses Prinzip - es eliminiert dauerhaft erhöhten Zugriff zugunsten zeitbasierter Berechtigungen auf Basis definierter Richtlinien und geschäftlichem Kontext. Auf Drittanbieter-Identitäten angewendet bedeutet Zero Standing Privilege:

• Kein Auftragnehmer hat dauerhaften Zugriff auf sensible Systeme zwischen aktiven Arbeitssitzungen
• Jede Zugriffsgenehmigung hat ein explizites Ablaufdatum, das bei der Provisionierung festgelegt wird
• Automatischer Entzug erfolgt, wenn der Timer abläuft - unabhängig davon, ob jemand ein Ticket einreicht
• Jede Genehmigung, Verlängerung und Entziehung wird mit Zeitstempel und Genehmiger-Eintrag protokolliert

Unit-42-Forschungen ergaben, dass 99 % aller Cloud-User, Rollen und Service-Accounts überprivilegiert sind und mehr Berechtigungen halten, als sie tatsächlich benötigen^[8]. Zeitbasierter, abgegrenzter Zugriff für Auftragnehmer adressiert genau das - nicht indem er einschränkt, was Auftragnehmer während ihres Engagements tun können, sondern indem er sicherstellt, dass der Zugriff verschwindet, wenn die Arbeit erledigt ist.

Kontinuierliche Überprüfung: Nicht auf das Audit-Fenster warten

Punktuelle Access-Reviews sind ein Compliance-Mindeststandard, keine Ziellinie. Bis Ihr jährliches Review ein überprivilegiertes Auftragnehmer-Konto aufdeckt, kann dieses Konto elf Monate lang brach gelegen und angreifbar gewesen sein.

Das bessere Modell ist die kontinuierliche Zugangszertifizierung - automatisierte, fortlaufende Überprüfung von Drittanbieter-Berechtigungen, die Anomalien in Echtzeit meldet statt einmal im Jahr. Das bedeutet:

• Erkennung von Berechtigungs-Drift: Alarm, wenn der Zugriffsumfang eines Auftragnehmers über das ursprünglich Genehmigte hinaus wächst
• Inaktivitätsüberwachung: Markierung von Konten, die seit 30 Tagen nicht genutzt wurden (ein starkes Signal dafür, dass das Engagement informell beendet wurde)
• Regelmäßige Re-Zertifizierungsaufforderungen: automatische Weiterleitung von Auftragnehmer-Zugriffen an den Business Owner zur Bestätigung in einem definierten Rhythmus - ohne auf den jährlichen Review-Zyklus zu warten

^[10] verpflichtet Organisationen, Informationssicherheit in Lieferantenbeziehungen zu managen - einschließlich Zugriffskontrollen und Monitoring. Die Erwartung an Belege ist kein einmaliger Schnappschuss, sondern ein nachgewiesener, fortlaufender Prozess.

In regulierten Branchen sind die Einsätze höher. Gesundheitsorganisationen unterliegen HIPAA-Pflichten hinsichtlich des Zugriffs von Geschäftspartnern. Finanzdienstleister unter DORA müssen operative Resilienz in ihren Drittanbieter-Beziehungen nachweisen - einschließlich der Zugriffs-Governance. Energie- und kritische Infrastrukturunternehmen unter NIS2 stehen vor ähnlichen Anforderungen. In allen Fällen lautet die Frage des Auditors gleich: Zeigen Sie mir den Prozess, nicht nur die Richtlinie.

Was lückenlose Abdeckung hier wirklich bedeutet

Das Drittanbieter-Zugriffsproblem hat eine Abdeckungsdimension, die leicht unterschätzt wird. Ihre primären SaaS-Tools - die mit SCIM-Unterstützung und Enterprise-Integrationen - sind der einfache Teil. Der schwierige Teil ist der Long Tail: das Projektmanagement-Tool ohne SCIM-Unterstützung, das Legacy-interne System ohne API, die Nischen-Branchenanwendung, die Ihre Auftragnehmer benötigen, die Ihr IGA-Anbieter aber nicht abdeckt.

Genau hier versagt Standard-IGA-Tooling. Wenn Ihre Governance-Plattform nur SCIM-fähige Apps abdeckt, haben Sie einen blinden Fleck, der mit jedem Tool in Ihrem Stack wächst, das diese Anforderung nicht erfüllt. Auftragnehmer in diesen nicht verwalteten Apps sind für Ihre Access-Reviews, Ihre Deprovisionierungs-Workflows und Ihren Audit-Trail unsichtbar.

Diese Lücke zu schließen erfordert eine IGA-Plattform mit universeller App-Abdeckung - eine, die Zugriff in Apps mit SCIM, Apps mit APIs und Apps ohne beides verwalten kann. Das ist kein Nice-to-have für die Audit-Bereitschaft. Es ist der Unterschied zwischen einem Audit-Trail, der Ihre gesamte Umgebung abdeckt, und einem, der nur die einfachen Teile davon abdeckt.

---

Checkliste: Audit-Belege für Drittanbieter-Zugriff

Nutzen Sie diese Checkliste, um Ihre Bereitschaft zu prüfen, bevor ein Auditor fragt. Jeder Punkt sollte mit strukturierten, mit Zeitstempel versehenen Aufzeichnungen beantwortbar sein - nicht durch manuelle Rekonstruktion.

Identitätsinventar

• Vollständige Liste aller externen Identitäten (Auftragnehmer, Berater, Integrations-Service-Accounts, OAuth-Token), die während des Prüfzeitraums aktiv waren
• Jede Identität ist einem namentlich genannten Business Owner und einem spezifischen Engagement oder Vertrag zugeordnet
• Auftragnehmer-Identitäten werden in einem System of Record erfasst, das vom HRIS getrennt ist oder es erweitert

Belege zur Zugriffsprovisionierung

• Zeitgestempelter Provisionierungsnachweis für jede externe Identität
• Namentlich genannter Genehmiger für jede Zugriffsgenehmigung
• Dokumentierter Umfang: spezifische Anwendungen, Berechtigungsstufen und Datenzugriff - nicht nur "Zugriff auf [Tool]"
• Explizites Ablaufdatum bei der Provisionierung für jede Auftragnehmer-Zugriffsgenehmigung

Belege zur Zugriffsprüfung

• Regelmäßige Zugangszertifizierungsnachweise für Auftragnehmer mit Engagements von mehr als 90 Tagen
• Nachweis, dass Business Owner (nicht nur die IT) bestätigt haben, dass Berechtigungen noch angemessen sind
• Inaktivitätswarnungen oder Markierungen für Konten, die seit mehr als 30 Tagen nicht genutzt wurden

Offboarding-Belege

• Zeitgestempelter Deprovisionierungsnachweis für jeden Auftragnehmer, der während des Prüfzeitraums ausgeschieden ist
• Bestätigung, dass die Deprovisionierung alle Systeme abgedeckt hat - einschließlich Long-Tail-SaaS-Apps
• Keine verbleibenden aktiven Konten für Identitäten, deren Engagements beendet wurden

Belege zur kontinuierlichen Governance

• Berechtigungs-Drift-Warnungen: Nachweis, dass Umfangserweiterungen eine Überprüfung ausgelöst haben
• Abdeckungsbestätigung: Governance-Tooling deckt 100 % der relevanten Apps ab - einschließlich Nicht-SCIM-Tools
• Audit-Trail ist maschinell generiert und kontinuierlich - nicht aus Tickets und E-Mails rekonstruiert

Das Ziel ist nicht, das Audit zu bestehen. Es geht darum, Ihre Umgebung so zu betreiben, dass das Audit zur Formsache wird.