Ihr SOC-2-Auditor schickt Ihnen die Vorbereitungsliste. Ein Punkt lautet: "Stellen Sie eine vollständige Zugriffshistorie für alle Drittanbieter- und Dienstleister-Accounts der letzten 12 Monate bereit - inklusive: wer den Zugriff genehmigt hat, worauf zugegriffen werden konnte, wann der Zugriff überprüft wurde und wann er entzogen wurde."
Für Ihre Mitarbeitenden? Sie ziehen einen Report. Erledigt.
Für Ihre externen Dienstleister? Gähnende Leere.
Das ist eine der häufigsten - und am leichtesten vermeidbaren - Fehlstellen in modernen Identity-Governance-Programmen. Und das Problem wird größer, je mehr Unternehmen mit erweiterter Belegschaft arbeiten. Externe Dienstleister, Freelancer und Berater machen laut U.S. Government Accountability Office inzwischen rund 30-40 % der US-Arbeitskräfte aus, andere Schätzungen gehen davon aus, dass die weltweite Freelancer-Quote bis 2025 auf 46,6 % der Gesamtbelegschaft steigt. Diese Personen arbeiten an Ihrem Code, in Ihren Cloud-Umgebungen, mit Ihren Kundendaten - und die meisten Organisationen können für keinen einzigen von ihnen eine saubere Zugriffsüberprüfung oder ein vollständiges Audit-Protokoll vorlegen.
Dieser Beitrag zeigt, wie Sie diese Lücke schließen, bevor Ihr Auditor sie findet.
Warum die Zugriffsspur von Dienstleistern abreißt
Die Ursache ist selten Nachlässigkeit. Es ist Ihre Architektur.
Die meisten Identity-Governance-Programme basieren auf einer einfachen Annahme: Die Belegschaft lebt im HR-System, und dieses HR-System triggert alle Identity-Workflows. Jemand wird eingestellt -> HR legt einen Datensatz an -> Zugriff wird provisioniert. Jemand verlässt das Unternehmen -> HR schließt den Datensatz -> Zugriff wird entzogen. Sauber, prüfbar, auditierbar - perfekte Protokollierung.
Externe Dienstleister sprengen jede einzelne dieser Ketten.
Sie werden "onboarded", weil ein Manager der IT geschrieben hat. Sie werden in einer Excel-Liste, einem Vendor-Portal oder schlicht im Posteingang einer Person geführt. Häufig nutzen sie Tools mit einer privaten E-Mail-Adresse statt mit einem Unternehmens-Account. In Ihrem Okta- oder Entra-Verzeichnis tauchen sie vielleicht nie auf. Und wenn das Projekt endet, gibt es kein HR-Austrittsereignis, das einen automatischen Deprovisioning-Workflow startet - es passiert also nichts, außer jemand denkt aktiv daran.
Das Ergebnis: ein Geist in Ihrem Stack. Aktive Berechtigungen, aber keine verantwortliche Person und keine belastbare Zugriffsüberprüfung.
Ein Bericht aus dem Jahr 2025 zeigt, dass rund 48 % der Unternehmen wissen, dass ehemalige Mitarbeitende weiterhin Zugang zu Unternehmenssystemen haben, wobei Vorfälle über Zugriff durch Dritte ein wachsender Risikotreiber sind. Laut dem Verizon Data Breach Investigations Report 2025 haben sich Sicherheitsverletzungen mit Third-Party-Beteiligung im Jahresvergleich verdoppelt - viele davon gehen auf übersehene Unterauftragnehmer zurück. Auditoren wissen das. Deshalb stellen sie härtere Fragen.
Die sechs Fragen der Auditoren - und die Antworten, die Ihnen fehlen
Wenn ein SOC-2-, ISO-27001- oder HIPAA-Auditor nach dem Zugriff für externe Dienstleister fragt, geht es nicht um Schätzwerte. Es geht um Belege: Zeitstempel, Namen der Genehmigenden, Umfang des Zugriffes, Nachweise über Zertifizierung von Zugriffen und Belege für den Entzug der Berechtigungen.
So sieht das in der Praxis aus - und genau hier sitzen die meisten Organisationen in der Falle:
| Frage des Prüfers | Mitarbeiter (HRIS-verbunden) | Auftragnehmer (kein HRIS-Eintrag) |
|---|---|---|
| Wann erhielt diese Person Zugriff? | ✅ Bereitstellungszeitstempel, automatisch protokolliert beim Einstellungsdatum | ❌ 'Irgendwann im letzten Frühling' - Prüfe die Ticket-Warteschlange |
| Wer hat den Zugriff genehmigt? | ✅ Genehmigername + Zeitstempel im Workflowprotokoll | ❌ 'Mein Vorgesetzter hat IT eine E-Mail geschickt' - vermutlich verloren gegangen |
| Auf welche Systeme hatten sie Zugriff? | ✅ Vollständiges App-Inventar, das mit dem Identitätsdatensatz verknüpft ist | ❌ Nur SSO-verbundene Apps sichtbar; direkte Logins sind unsichtbar |
| Wurden Berechtigungen während der Einbindung überprüft? | ✅ Geplante Zugriffsüberprüfungen mit Zertifiziererdatensatz | ❌ Nein - Sie waren nie im Überprüfungszyklus enthalten |
| Wann wurde der Zugriff entzogen? | ✅ Kündigungsereignis protokolliert; Deprovision bestätigt | ❌ 'Wir haben ihr Okta-Konto deaktiviert' - aber direkte App-Logins könnten weiterhin aktiv sein |
| Ist noch Zugriff aktiv? | ✅ Sauberer Deprovisioning-Bericht über alle verbundenen Apps | ⚠️ Unbekannt - Ohne manuelle Überprüfungen nicht feststellbar |
Das Muster ist immer gleich: Der Zugriff von Mitarbeitenden ist geregelt, weil die Mitarbeitenden in einem System existieren. Der Zugriff für externe Dienstleister wird - wenn überhaupt - durch Erinnerung, Tickets und Glück gesteuert.
Laut Gartners Research 2024 werden je nach Organisation zwischen 11 % und 40 % der Drittparteien als hochriskant eingestuft, dennoch fehlt vielen Programmen die systematische Dokumentation, die Auditoren erwarten. In vielen Third-Party-Risk-Programmen fallen Dokumentationslücken erst während der Compliance-Prüfung auf - nicht davor. Zu diesem Zeitpunkt ist es ein Audit-Finding, keine schnelle Korrektur.
Das Audit-Protokoll, das Sie wirklich brauchen
Eine vollständige Audit-Historie für den Zugriff durch Dritte ist nicht dasselbe wie Anwendungs-Logs. Logs zeigen, was in einer Anwendung passiert ist. Ein Audit-Trail zeigt, wer den Zugriff genehmigt hat, zu welchen Bedingungen, über welche Systeme hinweg und wie der Zugriff beendet wurde - und zwar in einer Form, die ein Auditor im Rahmen einer Compliance-Prüfung tatsächlich verwerten kann.
So sieht der Aufbau eines Dienstleister-Datensatzes aus, der einer Prüfung standhält:
- Identity-Anker: Ein gesteuerter Datensatz für die Identität des Dienstleisters - Name, Rolle, Sponsor/Manager und Projektdauer -, der außerhalb Ihres HRIS existiert, aber vollständig auf Ihrer Identity-Governance-Plattform nachverfolgbar ist
- Provisioning-Ereignis: Welche Zugriffe gewährt wurden, auf welche Systeme, mit welchem exakten Berechtigungsniveau (nicht nur "zu GitHub hinzugefügt", sondern: welches Repository, welche Rolle, welche Branch-Berechtigungen)
- Genehmigungskette: Wer den Zugriff wann und über welchen Workflow genehmigt hat - nicht eine E-Mail, sondern ein gesteuerter Request mit protokollierter Entscheidung und Zeitstempel
- Änderungen während des Engagements: Alle Eskalationen, Rollenwechsel oder zusätzlichen Zugriffsrechte im Projektverlauf, jeweils mit eigenem Genehmigungsnachweis
- Review-Events: Nachweis, dass der Dienstleister-Zugriff in Ihren regulären Zyklen zur Zertifizierung von Zugriffen aufgetaucht ist und von einer namentlich genannten Person aktiv bestätigt oder angepasst wurde
- Deprovisioning-Bestätigung: Ein Eintrag, der zeigt, wann der Zugriff entzogen wurde, über welche Systeme hinweg und dass keine Restberechtigungen bestehen - einschließlich Apps außerhalb Ihres SSO-Perimeters
Die meisten Organisationen stoßen an beiden Enden auf Lücken: bei der Provisionierung (kein gesteuerter Request-Workflow für Dienstleister) und beim Offboarding (keine automatisierte Entfernung von Rechten jenseits der SSO-angebundenen Anwendungen).
Warum SSO Sie hier nicht rettet
"Aber wir haben doch den Okta-Account deaktiviert."
Das ist der verbreitetste Irrtum beim Offboarding externer Dienstleister - und in einer Audit-Situation eine teure Erkenntnis.
Das Deaktivieren eines SSO-Accounts entzieht nur den Zugriff auf Anwendungen, die über diesen SSO-Provider authentifizieren. Es hilft nicht bei:
- Apps, auf die der Dienstleister mit einer privaten E-Mail-Adresse zugegriffen hat (weil er nie in Ihrem Verzeichnis war)
- Tools, die über einen geteilten Team-Account bereitgestellt wurden
- Direkt vergebenen Datenbank-Credentials, die informell weitergegeben wurden
- Anwendungen in Ihrem Stack, die nicht via SCIM oder SSO an Okta angebunden sind, weil dafür ein Enterprise-Plan-Upgrade nötig wäre
Die Falle des teilweisen Offboardings: Das Deaktivieren des SSO-Kontos eines Auftragnehmers entfernt den Zugriff auf Apps, die über SSO verbunden sind – aber nicht auf Apps, auf die sie direkt zugegriffen haben (E-Mail + Passwort, geteilte Zugangsdaten oder persönliche Konten, die zum Onboarden verwendet wurden). Ohne universelle App-Abdeckung zeigt Ihr Offboarding-Log 'fertig' an, während der Zugriff auf GitHub-Repositories, Notion-Arbeitsbereiche oder Figma-Projekte möglicherweise weiterhin aktiv ist.
Das ist die SCIM-Mauer in Reinform. Die meisten Midmarket-Unternehmen haben automatisierte Identity Governance für 20-40 % ihres App-Stacks - die SCIM-fähigen Tools, die an SSO hängen. Die übrigen 60-80 % - Legacy-Anwendungen, Nischen-SaaS, interne Tools, oder Apps, für deren SCIM-Anbindung Sie zuerst den Enterprise-Tarif kaufen müssten - bleiben für diese Governance-Schicht unsichtbar.
Externe Dienstleister, die ohnehin außerhalb dieses Perimeters stehen, sind doppelt unsichtbar: außerhalb der Identitätsquelle und in Apps unterwegs, die nicht von Ihrer Identity Governance abgedeckt werden. Wenn Sie einem Auditor sagen, Sie hätten den SSO-Account deaktiviert, sagen Sie damit noch lange nicht, dass der Figma-Zugriff, das Linear-Workspace oder die GitHub-Organisation ebenfalls bereinigt sind. Denn Sie wissen es schlicht nicht.
Wie Sie tatsächlich einen Audit-Trail für Dienstleister aufbauen
Das ist kein Einmalprojekt. Es ist eine Frage des Governance-Designs - und die Lösung ist kontinuierlich, nicht reaktiv.
Jeder Auftragnehmer benötigt einen verwalteten Identitätsdatensatz – auch wenn er nicht in Ihrem HRIS geführt wird. Erfassen Sie: Name, Rolle, Sponsor/Vorgesetzter, Beginn der Beschäftigung, Ende der Beschäftigung und die Anwendungen, auf die er Zugriff benötigt. Dies ist der Anker für jede nachfolgende Auditfrage. Ohne ihn gibt es keinen Nachweis, der aufgebaut werden kann.
Nie wieder 'Die IT hat eine Slack-Nachricht erhalten und sie eingerichtet'. Jede Zugriffserteilung für einen Auftragnehmer muss durch einen genehmigten Workflow mit einem expliziten Genehmigerdatensatz, einem Zeitstempel und den genauen Berechtigungen erfolgen – auf Ebene des Repository, Kanals oder der Projektebene. Wenn Ihre IGA-Plattform die App nicht erreicht, bleibt die Erteilung für Ihren Auditpfad unsichtbar.
Zeitlich begrenzter Zugriff (Just-in-Time oder JIT) ist Ihre Sicherheitsvorkehrung, wenn ein Auftragnehmer nicht erreichbar ist. Legen Sie beim Bereitstellen ein Enddatum der Beschäftigung fest. Wenn dieses Datum überschritten wird, wird der Zugriff automatisch widerrufen – unabhängig davon, ob jemand daran erinnert wird, der IT ein Ticket zu senden. Dies ist der Unterschied zwischen einem sauberen Offboarding und einem im Audit erst sechs Monate später entdeckten Konto.
Die meisten Tools zur Zugriffsüberprüfung ziehen standardmäßig die Liste aus Ihrem HRIS oder IDP. Auftragnehmer, die in keinem der Systeme enthalten sind, werden stillschweigend ausgeschlossen. Ihre Governance-Plattform muss Nicht-Mitarbeiter-Identitätsdatensätze unterstützen, die im gleichen Überprüfungsrhythmus wie Mitarbeiter erscheinen – mit derselben Zertifizierungsverantwortung und einem auditkonformen Ergebnisdatensatz.
Prüfer fragen zunehmend nach Änderungen während der Beschäftigung: 'Haben sich die Berechtigungen dieses Auftragnehmers geändert, während er aktiv war? Wer hat es genehmigt? Warum?' Ein unveränderliches Protokoll jeder Zugriffsänderung – bereitgestellt, geändert, eskaliert, widerrufen – ist der einzige Weg, diese Frage zuverlässig zu beantworten.
Wenn Ihr Auditor nach der Zugriffshistorie von Auftragnehmern fragt, müssen Sie mit einem Klick antworten können, statt drei Tage in Tabellenkalkulationen zu verbringen. Ihre Governance-Plattform sollte einen zeitgestempelten Zugriffshistoriebericht für jede Identität – Mitarbeiter oder Auftragnehmer – erstellen, der festhält, worauf sie Zugriff hatten, wann, wer es genehmigt hat, wann es überprüft wurde und wann der Zugriff entfernt wurde.
Die kritische Abhängigkeit in allen sechs Schritten ist die universelle App-Abdeckung. Schritte 1 bis 6 funktionieren nur, wenn Ihre Identity-Governance-Plattform die Anwendungen erreicht, die Ihre externen Dienstleister wirklich nutzen - inklusive der Tools ohne SCIM-Schnittstelle oder offizielle API.
Wenn Ihre Plattform nur SCIM-angebundene Anwendungen steuert, bauen Sie ein Audit-Protokoll mit bewusst in Kauf genommenen Lücken. Ein Auditor wird Ihnen die 40 %, die Sie sehen, nicht "anrechnen", wenn die übrigen 60 % ohne Protokollierung undokumentiert bleiben.
Genau diese Lücke trennt vollständige Identity Governance von SSO-nahen Punktlösungen. Klassische IGA-Plattformen sind für diesen Anwendungsfall oft zu träge und komplex - ein Implementierungsprojekt über sechs Monate hilft nicht, wenn Ihre nächste Compliance-Prüfung in acht Wochen ansteht. "Moderne IGA"-Tools, die an der SCIM-Grenze enden, lassen den Long Tail Ihres App-Stacks außen vor. Die eigentliche Lösung ist eine Plattform mit universellen Konnektoren - die jede Anwendung erreicht, mit der Ihre Dienstleister arbeiten, egal ob sie einen SCIM-Endpunkt hat oder nicht.
Wie das in einer echten Auditsituation aussieht
Ein Auditor prüft Ihre ISO-27001-Nachweise für Zugriffskontrollen. Er zieht eine Liste aller Nutzer, die im vergangenen Jahr Zugriff auf Ihre produktive GitHub-Organisation hatten. Drei Namen tauchen darin auf, die nicht zu Ihrer aktuellen Mitarbeitendenliste passen.
Mit einem vollständigen Audit-Trail für Zugriff durch Dritte klicken Sie in jeden Identitätsdatensatz und zeigen:
- Wann die Person onboarded wurde und wer sie gesponsert hat
- Auf welche Repositories sie genau Zugriff hatte (nicht nur "GitHub", sondern die konkreten Repos mit den jeweiligen Berechtigungsstufen)
- Dass ihr Zugriff im Rahmen der quartalsweisen Zertifizierung von Zugriffen im Q2 geprüft und von ihrem Sponsor bestätigt wurde
- Dass mit Ende des Vertrags der Zugriff in GitHub und den weiteren 11 Tools, in denen sie tätig war, widerrufen wurde - protokolliert, mit Zeitstempel, vollständig
- Dass heute kein Restzugriff existiert - belegt durch einen aktuellen Access-Report, nicht durch eine manuelle Stichprobe
Das ist ein sauberes Ergebnis. Vor allem aber: Das Gespräch ist in zehn Minuten beendet.
Ohne diesen Audit-Trail verbringen Sie drei Tage in Tabellen, sammeln Screenshots aus einzelnen Anwendungen, suchen nach der Führungskraft, die den Dienstleister beauftragt hat - und können am Ende trotzdem nicht sicher bestätigen, dass alle Berechtigungen entfernt wurden.
Laut Benchmark-Daten im Bereich Compliance geraten Organisationen ohne umfassende Protokollierung in verlängerte Audit-Zeiträume und riskieren nicht bestandene Prüfungen - genau das Szenario, das ein sauber aufgebauter Audit-Trail für Zugriff für externe Dienstleister verhindert.
Prüfen Sie Ihre eigene Bereitschaft
Vor Ihrer nächsten Compliance-Prüfung können Sie diesen kurzen Selbsttest durchführen. Er dauert weniger als zwei Minuten und zeigt Ihnen exakt, wo Ihr Audit-Trail zum Zugriff durch Dritte Lücken hat.
Was sich mit universeller Identity Governance ändert
Die Herausforderungen beim Audit von Zugriff für externe Dienstleister - Identitäten ohne HRIS-Anker, Anwendungen außerhalb des SSO-Perimeters, zeitlich befristete Engagements mit der Notwendigkeit automatischer Ablaufdaten - passen nahezu eins zu eins zu dem, was universelle Identity Governance adressiert.
Iden steuert alle Identitäten - Mitarbeitende, Dienstleister, Service Accounts, AI Agents - über eine einzige Plattform mit universellen Konnektoren, die Anwendungen unabhängig davon erreicht, ob sie SCIM, eine moderne API oder gar nichts davon unterstützen. Ihr Audit-Trail für externe Dienstleister umfasst damit den gesamten Stack, nicht nur den Teil, den Ihr SSO-Provider sieht.
Konkret bedeutet das:
- Identitätsdatensätze für Nicht-Mitarbeitende, die außerhalb Ihres HRIS angelegt und gesteuert werden, mit Engagement-Daten, die automatisierte Provisionierung und Deprovisioning auslösen
- Feingranulare Protokollierung von Zugriffen - nicht nur auf App-Ebene, sondern bis hinunter zu Repositories, Kanälen und Projekten, erfasst über 175+ Konnektoren
- Zeitlich begrenzte Zugriffe mit hartem Ablaufdatum, damit Dienstleister-Berechtigungen nicht über das Ende des Projekts hinaus bestehen bleiben
- Einbindung in Ihre Zyklen zur Zertifizierung von Zugriffen, unabhängig davon, ob die Identität im HRIS oder im IdP geführt wird
- Automatisierte Bestätigung des Deprovisioning über Ihren kompletten Stack - nicht nur für SSO-angebundene Anwendungen
- On-Demand-Auditnachweise - ein vollständiger Access-History-Report für jede Identität, der sich in Minuten statt in Tagen exportieren lässt
Das ist keine Implementierung über sechs Monate. Iden geht in etwa 24 Stunden live - ohne Engineering-Aufwand und ohne, dass Sie teure Enterprise-Upgrades kaufen müssen, nur um SCIM für geschäftskritische Anwendungen freizuschalten - keine "SCIM-Steuer".
Für Teams, die bereits mit Herausforderungen im Identity-Lifecycle-Management von Dienstleistern kämpfen oder durch Vorgaben wie NIS2 oder DORA unter Audit-Druck stehen, sind Probleme beim Audit-Trail für externe Dienstleister selten isoliert - sie sind ein Symptom teilweiser IGA-Abdeckung, deren Risiken sich über die Zeit aufschaukeln.
Das Fazit
Die meisten Organisationen sind nur eine einzige Auditorenfrage davon entfernt festzustellen, dass sie keinen Audit-Trail für ihre externen Dienstleister haben.
Die Lösung ist weder eine neue Excel-Liste noch ein weiteres Policy-Dokument. Sie besteht aus gesteuerten Identitätsdatensätzen für Nicht-Mitarbeitende, Access-Workflows, die jede Provisionierungsentscheidung protokollieren, automatischen Ablaufdaten, die nicht von manueller Erinnerung abhängen, und einer Identity Governance mit universeller App-Abdeckung - also Zugriffsüberprüfung und Protokollierung für jede Anwendung, nicht nur für die 40 %, die einen SCIM-Endpunkt haben.
Ihre Mitarbeitenden sind dokumentiert. Ihre Dienstleister haben Ihr Produkt mitgebaut, Ihre Kunden betreut und Ihre sensibelsten Systeme angefasst - und dennoch können die meisten Organisationen kaum etwas zur Zugriffshistorie dieser Personen nachweisen.
Das ist die Lücke. Schließen Sie sie, bevor der Auditor sie findet.
