In Prüfungen im Gesundheitswesen, in der Verteidigungsindustrie und bei Finanzdienstleistern taucht jedes Quartal dasselbe Szenario auf: Ein Compliance-Review fragt: "Wer hatte in den letzten 12 Monaten Zugriff auf dieses System?" In der Antwortliste steht ein Berater, dessen Projekt seit acht Monaten abgeschlossen ist. Sein Zugriff - auf das KIS, die CUI-Umgebung, die Produktionsdatenbank - ist immer noch aktiv.
Das ist 2026 in vielen Branchen nicht mehr nur ein Governance-Fehler. Es ist ein klarer Verstoß gegen regulatorische Vorgaben.
Ob eine Lücke bei Dienstleister-Identitäten als peinlicher Prüfungsbefund oder als materielle Compliance-Verletzung gewertet wird, hängt davon ab, nach welchem Rahmenwerk Sie arbeiten. Inzwischen fordert jede große regulierte Branche explizit, dass Sie den Zugriff von Dritten steuern - nicht nur den von Mitarbeitenden. Nicht nur Apps, die an Ihr SSO angebunden sind. Alles, mit belastbarem Nachweis.
Die Governance-Lücke, die alle regulierten Branchen betrifft
Wie wir in unserem Beitrag zu Contractor-Identity-Chaos und JML-Prozessen beschrieben haben, ist die Ursache strukturell: Die meisten Identity-Governance-Programme gehen davon aus, dass die gesamte Belegschaft im HRIS abgebildet ist. Für Dienstleister gilt das selten. Sie werden in Tabellen, Projekt-Tickets und E-Mail-Threads erfasst - wenn überhaupt.
Contingent Worker machen mittlerweile rund 30-40 % der US-Arbeitskräfte aus, doch die meisten Identity-Governance-Programme tun immer noch so, als bestünde die Workforce ausschließlich aus Angestellten mit HRIS-Datensätzen.
Die Governance-Lücke ist real und gut dokumentiert. In regulierten Branchen sind die Konsequenzen jedoch deutlich gravierender. Es geht nicht nur um ein Sicherheitsrisiko oder einen unangenehmen Audit-Fund - es sind genau die Arten von Findings, die Korrekturmaßnahmenpläne, regulatorische Sanktionen und im Verteidigungsumfeld sogar den Verlust der DoD-Vertragsfähigkeit nach sich ziehen können.
Dieser Beitrag fokussiert auf die regulatorische Dimension: Was die wichtigsten Rahmenwerke konkret von Ihrer Third-Party-Identity-Governance verlangen - und wie "nicht konform" in der Praxis aussieht.
Der gemeinsame Faden bei HIPAA, CMMC, DORA und SOC 2: Alle vier Rahmenwerke verlangen jetzt explizit eine nachweisbare Kontrolle über den Zugang Dritter und Auftragnehmer - nicht nur beim Onboarding, sondern kontinuierlich, mit auditierbaren Nachweisen. 'Wir verwenden Okta' ist keine ausreichende Antwort, wenn der Prüfer nach einem Auftragnehmer fragt, der vor acht Monaten gegangen ist.
Gesundheitswesen: Das Business-Associate-Problem von HIPAA
HIPAA hat seine Anforderungen schon immer über die eigentliche "Covered Entity" hinaus ausgedehnt. Der Health Insurance Portability and Accountability Act umfasst jeden Business Associate - also jede Organisation, die in Ihrem Auftrag PHI erstellt, entgegennimmt, speichert oder überträgt. Dazu gehören Abrechnungsdienstleister, EHR-Anbieter, Transkriptionsservices, Cloud-Provider, IT-Support, Rechtsberater und Vernichtungsunternehmen.
Das Netz ist weit gespannt. Der Radiologie-IT-Dienstleister mit temporärem Zugriff auf Ihre Epic-Umgebung oder der externe klinische Analyst, der beim Aufbau Ihres Data Warehouse geholfen hat, fallen vollständig in den Scope - nicht nur während des Projekts, sondern solange ihr Zugriff technisch existiert.
Sowohl Covered Entities als auch ihre Business Associates haften direkt für Verstöße. Der HITECH Act hat Business Associates explizit in die direkte Verantwortung genommen.
Was sich mit der HIPAA Security Rule 2026 ändert
Ab 2026 steigen die Anforderungen deutlich. Die Änderungen der HIPAA Security Rule umfassen unter anderem die verpflichtende Verschlüsselung aller ePHI im Ruhezustand und während der Übertragung, verpflichtende Multi-Faktor-Authentifizierung für ePHI-Zugriffe, 72-Stunden-Meldepflicht an das HHS bei Sicherheitsvorfällen, jährliche Penetrationstests, Vulnerability-Scans alle sechs Monate und erhöhte Dokumentationspflichten. Es ist das erste große Update der HIPAA-Sicherheitsstandards seit 2013.
Entscheidend für die Steuerung von Dienstleister-Zugriffen: Benutzerkonten müssen innerhalb von einer Stunde nach Ausscheiden eines Mitarbeitenden oder Contractors deaktiviert werden, und Rechteänderungen erfordern eine zusätzliche MFA-Bestätigung.
Eine Stunde. Nicht "bis zum Tagesende". Nicht "wenn IT dazukommt". Eine Stunde - über jede Anwendung mit ePHI-Zugriff hinweg, nicht nur in Ihren SSO-angebundenen Systemen.
Business-Associate-Agreements mit Anbietern, Dienstleistern und Service-Providern müssen mit konkreten, detaillierten Sicherheitsanforderungen aktualisiert werden. Vage Formulierungen reichen nicht mehr aus - Verschlüsselung, MFA und regelmäßige Sicherheitstests müssen explizit vertraglich gefordert werden. Das gilt für jede dritte Partei, die ePHI verarbeitet oder einsehen kann.
Der vorgeschlagene Regulierungsrahmen verlangt außerdem jährliche Compliance-Audits und verpflichtet Business Associates, ihren Compliance-Status einmal pro Jahr gegenüber der Covered Entity zu berichten.
Für Gesundheitsorganisationen, die Dienstleister-Zugriffe noch mit manuellen Offboarding-Checklisten und IT-Tickets steuern: Die 2026er-Regel nimmt diese "Kulanzzeit" weg. Eine Stunde ist ein automatisiertes SLA, kein manueller Prozess.
Verteidigung: CMMC und die CUI-Flowdown-Pflicht
Für Verteidigungsaufträge ist das Bild in der Identity Governance noch deutlicher. Die CMMC-2.0-Regel ist seit dem 10. November 2025 in Kraft und macht die CMMC-Standards verbindlich - sie ist vom lange diskutierten Konzept zur rechtlichen und geschäftlichen Realität für jeden Auftragnehmer geworden, der Federal Contract Information (FCI) oder Controlled Unclassified Information (CUI) verarbeitet.
Der Punkt, den viele unterschätzen: CMMC gilt nicht nur für den Hauptauftragnehmer (Prime). Die Anforderungen betreffen alle Unternehmen, die CUI oder FCI handhaben - Primes, Subunternehmer und kritische Zulieferer. Die Regel schreibt einen expliziten Flowdown der Anforderungen vor.
Auftragnehmer müssen 32 CFR 170.23 in Bezug auf den Flowdown von CMMC-Anforderungen beachten und die jeweils passende CMMC-Stufe in Unteraufträge und andere vertragliche Instrumente "flowdownen". Wenn Sie Prime Contractor sind und ein Subunternehmer Zugriff auf CUI-führende Systeme hat - selbst nur peripher - dann ist dessen Identity-Governance-Status Ihr Problem.
Im neuen Regime muss jedes System, das FCI oder CUI verarbeitet, mit einer eigenen CMMC Unique Identifier im SPRS registriert werden; Auftragnehmer müssen über die gesamte Vertragslaufzeit einen "aktuellen" CMMC-Status aufrechterhalten.
Die Phase-2-Deadline, die niemand verpassen darf
Auftragnehmer in der Verteidigungsindustrie, die Controlled Unclassified Information verarbeiten, müssen spätestens bis zum 10. November 2026 bereit für ein Third-Party-Assessment zu CMMC Level 2 sein. Im Schnitt benötigen Unternehmen 12 Monate oder mehr, um wirklich assessment-ready zu werden.
Die Auswirkungen auf Identity Governance sind eindeutig: Zugriffskontrolle, Least Privilege und die Fähigkeit, nachzuweisen, wer wann Zugriff auf CUI-Systeme hatte, sind Kernanforderungen aus NIST SP 800-171, die Prüfer genau anschauen. Branchenschätzungen zufolge haben bislang nur etwa 1,4 % der Unternehmen in der Defense Industrial Base eine vollständige CMMC-Level-2-Compliance erreicht - das bedeutet, die Mehrheit der Subunternehmer mit CUI-Zugriff betreibt Zugriffskontrollen, die in einem formalen Assessment scheitern würden.
Verwaiste Subunternehmer-Accounts in einer CUI-Umgebung sind nicht nur eine Sicherheitslücke. Im CMMC-Kontext sind sie ein Kontrollversagen, das die CUI Compliance und letztlich die Vertragsfähigkeit gefährdet.
Für Unternehmen in der Verteidigungslieferkette bietet unser Schritt-für-Schritt-Guide zu CMMC-Level-2-Access-Management einen praxisnahen Fahrplan, um vor der November-2026-Deadline assessment-ready zu werden.
Finanzdienstleistungen: DORA und das Mandat für Third-Party-ICT-Risiko
Der Digital Operational Resilience Act (DORA) gilt seit Januar 2025 und markiert einen deutlichen Wandel darin, wie Finanzinstitute und ICT-Dienstleister digitale Risiken und regulatorische Compliance angehen.
Die Third-Party-Risk-Bestimmungen von DORA - die Artikel 28 bis 30 - sind der Punkt, an dem die Governance von Dienstleister-Identitäten unmittelbar relevant wird. Die Verordnung fordert ein umfassendes ICT-Risikomanagement, Incident-Reporting, Resilienztests und eine strenge Überwachung von Third-Party-Service-Providern.
Das ist keine abstrakte Aufsicht. Eine Unternehmensberatung mit Produktionszugriff auf Handelssysteme oder eine Payment-Beratung mit Zugang zur Zahlungsabwicklung zählt als ICT-Drittpartei im Sinne von DORA. Die Verordnung verlangt die Führung eines Registers aller solcher Dienstleister, eine sorgfältige Due Diligence vor der Vergabe von Zugriffen und durchsetzbare Sicherheitsanforderungen in Verträgen - einschließlich klarer Regelungen, was mit den Zugriffsrechten nach Ende des Mandats passiert. Wer DORA ernsthaft umsetzt, kommt an konsequenter dora richtlinien einhaltung nicht vorbei.
Neue regulatorische Vorgaben wie DORA spiegeln einen globalen Trend wider: Vertrauen muss kontinuierlich verdient werden, nicht einmal jährlich nachgewiesen. Diese Perspektive ist entscheidend. DORA-Prüfer fragen nicht, ob Ihre Access-Governance-Policy existiert. Sie fragen, ob Ihre Kontrollen im Prüfzeitraum wirksam funktioniert haben - und ob Sie das belegen können.
SOC 2, das viele Finanzdienstleister zusätzlich oder alternativ zu DORA verfolgen, vertritt eine ähnliche Position. SOC 2-Compliance erstreckt sich explizit auf Dritte und Anbieter, die regulierte oder sensible Daten verarbeiten oder darauf zugreifen. Vendor-Risk-Management-Systeme unterstützen Unternehmen dabei, Lieferanten hinsichtlich Cyberrisiken, Compliance-Reife und Vertragstreue zu bewerten und zu überwachen. Dazu gehören Due-Diligence-Prüfungen, regelmäßige Reviews und die Verpflichtung von Vendors, angemessene Kontrollen aufrechtzuerhalten - ein Kernaspekt von effektivem soc 2 zugriffsmanagement.
Für Finanzberater im engeren Sinne - etwa bei der Modellvalidierung in Produktionsumgebungen einer Bank oder als Fintech-Integrator mit API-Zugriff auf Zahlungsströme - muss der Access Lifecycle genauso streng gesteuert werden wie bei Angestellten. Zugriffe werden mit klar definiertem Scope vergeben, regelmäßig überprüft und nach Ende des Mandats automatisch beendet.
Die meisten Organisationen können all das heute nicht nachweisen, weil ihre Governance-Werkzeuge dafür schlicht nicht ausgelegt sind.
Das verbindende Element: Regulatoren haben die "Ist ja nur ein Contractor"-Lücke geschlossen
Betrachtet man HIPAA, CMMC, DORA und SOC 2 gemeinsam, ergibt sich ein klares Bild: Der regulatorische Perimeter umfasst inzwischen explizit Ihre Contractors, Berater, externen Dienstleister und Subunternehmer. Die Identity-Governance-Kontrollen, die Sie auf Mitarbeitende anwenden, gelten gleichermaßen für jede Person, die mit regulierten Daten oder kritischen Systemen in Berührung kommt - und Sie brauchen den Audit-Trail, um das nachzuweisen.
| Rahmenwerk | Branche | Geltungsbereich Dritter | Anforderung an Zugriffskontrollen | Audit- und Nachweis-Anforderung | Durchsetzungsstatus |
|---|---|---|---|---|---|
| HIPAA Security Rule (2026) | Gesundheitswesen | Alle Geschäftspartner und externen Anbieter, die auf ePHI zugreifen | Zugriff wird innerhalb einer Stunde nach Trennung des Auftragnehmers beendet; MFA für alle ePHI-Portale | Jährliche Compliance-Audits; Geschäftspartner müssen den Compliance-Status jährlich an betroffene Stellen melden | 🔴 Endgültige Regel wird voraussichtlich Mai 2026 erwartet – 180-Tage-Frist beginnt |
| CMMC Level 2 (CUI) | Verteidigung | Hauptauftragnehmer + alle Unterauftragnehmer, die FCI/CUI verarbeiten | Zugriffskontrollen gemäß NIST SP 800-171 über alle Systeme, die CUI berühren; Weitergabe an Unterauftragnehmer sicherstellen | Jährliche Bestätigung durch die oberste Führungsebene; SPRS UID pro System; kontinuierliche Compliance erforderlich | 🔴 Phase 2 C3PAO-Bewertungen ab dem 10. November 2026 verpflichtend |
| SOC 2 (CC6.x) | Branchenübergreifend (SaaS, Finanzen, Tech) | Alle Anbieter und Berater mit Zugriff auf Systeme oder Daten, die im Geltungsbereich liegen | Dokumentierte Bereitstellung/Deprovisionierung; regelmäßige Zugriffsüberprüfungen; Durchsetzung des Minimalprivilegien-Prinzips | Typ II: Nachweis, dass Kontrollen über die Zeit effektiv funktionieren; Unterdienstleister (Subservice-Organisationen) im Bericht identifiziert | 🟡 Freiwillig, aber vom Kunden verlangt – Audits laufen das ganze Jahr über weiter |
| DORA (Art. 28-30) | EU-Finanzdienstleistungen | Alle ICT-Drittanbieter-Dienstleister (einschließlich Berater mit Produktionszugang) | Vertragliche Sicherheitsanforderungen; Überwachung des Drittanbieter-Risikos; dokumentierte Exit-Strategien | ICT-Drittanbieter-Risiko-Register; jährliche Resilienz-Tests; Aufsicht über kritische Anbieter | 🔴 Ab dem 17. Januar 2025 vollständig anwendbar – Aufsichtstätigkeit aktiv |
Die obige Tabelle macht die konkreten Anforderungen greifbar. Auffällig ist der eindeutige Trend: Rahmenwerke entwickeln sich weg von vager Vendor-Management-Sprache hin zu konkreten, operativ überprüfbaren Kontrollen. Die HIPAA-Vorgabe zur Konto-Deaktivierung innerhalb einer Stunde ist das deutlichste Beispiel. Eine Ein-Stunden-SLA lässt sich nicht mit einem manuellen Offboarding-Ticket erfüllen.
Warum die meisten Unternehmen diese Anforderungen heute nicht erfüllen können
Das Problem ist nicht mangelndes Bewusstsein. Die meisten IT- und Compliance-Verantwortlichen wissen, dass Dienstleister-Zugriffe eine Lücke darstellen. Das Problem ist strukturell - die vorhandenen Werkzeuge wurden nie dafür gebaut.
Die HRIS-Lücke. Standard-JML-(Joiner-Mover-Leaver-)Automatisierung basiert auf Events aus dem HR-System. Contractors sind dort oft nicht erfasst. Es entsteht kein offizielles "Termination Event", das sich durch die Systeme propagiert. Der Zugriff des Contractors bleibt unbegrenzt bestehen, weil kein automatisierter Prozess "weiß", dass das Mandat beendet ist.
Die SCIM-Mauer. Moderne IGA-Tools und SSO-nahe Plattformen automatisieren Provisionierung für Apps, die SCIM unterstützen - typischerweise 20-40 % des Stacks. Der Rest - der Notion-Workspace, die GitHub-Organisation, das Jira-Projekt, geteilte Datenbank-Credentials - bleibt manuell. Gerade Contractors landen häufig in den Long-Tail-Apps ohne SCIM-Unterstützung.
Die Coverage-Gap. Selbst bei SCIM-fähigen Anwendungen deprovisionieren viele Governance-Plattformen nur auf App-Ebene - nicht auf Ressourcenniveau. Wenn ein Contractor nach Projektende weiterhin Lesezugriff auf drei spezielle GitHub-Repositories behält, ist das eine Zugriffslücke, die reines SCIM-Deprovisioning nicht erkennt. Regulierte Branchen brauchen fein granulare, ressourcenbezogene Steuerung.
Die Audit-Lücke. Wenn ein DORA-Prüfer oder SOC-2-Assessor einen Nachweis zur Wirksamkeit Ihrer Zugriffskontrollen über einen Zeitraum verlangt, zwingen manuelle Prozesse Sie dazu, Historien aus Screenshots, E-Mail-Threads und halbfertigen Tabellen zu rekonstruieren. Das ist kein Audit-Trail - das ist ein Auditrisko.
Nutzen Sie das folgende Tool, um Ihre eigene Governance für Dienstleister-Zugriffe gegen diese Rahmenwerke zu bewerten und Ihren fremdfirmenzugang verwalten Ansatz zu hinterfragen:
Wie "vollständige" Third-Party-Identity-Governance aussieht
Die Ein-Stunden-Vorgabe von HIPAA, die CUI-Zugriffskontrollen in CMMC, das Third-Party-ICT-Risikomanagement in DORA und die Vendor-Management-Erwartungen von SOC 2 sind keine vier separaten Programme. Es handelt sich um eine einheitliche, sauber umgesetzte Identity-Governance-Fähigkeit, die Ihren gesamten App-Stack abdeckt - inklusive Non-SCIM- und Non-API-Apps - mit automatisiertem Lifecycle-Management und unveränderlichen Audit-Logs.
In der Praxis bedeutet vollständige Third-Party-Identity-Governance für regulierte Branchen:
Eine Source of Truth, die Contractors einschließt. Nicht nur HRIS-Datensätze - sondern ein kontrolliertes Register jeder aktiven Non-Employee-Identität, ihres Zugriffsscope, des Enddatums des Mandats und aller provisionierten Berechtigungen über alle Apps hinweg.
Automatisierte, zeitlich begrenzte Provisionierung. Zugriffe für Dienstleister werden mit einem klar definierten Scope vergeben, nicht nach dem Muster "Gib ihnen das gleiche Setup wie dem Team". Berechtigungen laufen automatisch mit Mandatsende aus. Kein manuelles Ticket erforderlich.
Offboarding mit Vollabdeckung des Stacks. Wenn ein Contractor-Mandat endet, wird Deprovisionierung über jede angebundene Anwendung ausgelöst - nicht nur Okta, nicht nur SCIM-fähige Tools, sondern GitHub, Notion, Jira, Slack, die Produktionsdatenbank, das Vendor-Portal. Jedes System. Automatisiert.
Fein granulare Kontrolle. Nicht nur "Zugriff auf GitHub", sondern "Zugriff auf diese drei Repositories mit Lese-Rechten". Läuft das Engagement aus, werden genau diese Berechtigungen entzogen. Nichts darüber hinaus bleibt bestehen.
Kontinuierliche Access Reviews. Quartalsweise oder häufigere Überprüfungen von Dienstleister-Berechtigungen - keine Durchwink-Genehmigungen durch Manager, die den tatsächlichen Bedarf des Contractors nicht kennen. Policy-getrieben und mit auditfähigen Nachweisen.
Unveränderliche Audit-Logs. Die Fähigkeit, Fragen wie "Wer hatte an diesem Datum mit welchen Rechten Zugriff auf dieses System?" in Minuten zu beantworten - nicht erst nach wochenlanger manueller Rekonstruktion.
Genau das verlangen die HIPAA-Änderungen ab 2026. Genau das wird ein CMMC-Level-2-C3PAO-Assessor im November 2026 sehen wollen. Und genau das erwartet die Aufsicht im Rahmen der dora richtlinien einhaltung, wenn sie Ihre ICT-Third-Party-Risikokontrollen prüft.
Iden: Für dieses Problem über Ihren gesamten Stack gebaut
Iden wurde für Organisationen entwickelt, die aus manueller Provisionierung und Flickwerk-Automatisierung herausgewachsen sind, aber dennoch mit schlanken IT-Teams arbeiten. Die Universal-Connector-Technologie von Iden erreicht jede App - ob sie SCIM, eine API oder gar nichts davon unterstützt - sodass Third-Party-Identity-Governance nicht am Rand Ihres SSO-Perimeters aufhört. Kein SCIM-Aufpreis. Keine Lücken in der Abdeckung.
Endet das Mandat eines Contractors, stößt Iden automatisiert Deprovisioning über alle angebundenen Anwendungen an. Wenn ein HIPAA-Auditor Belege dafür braucht, wer vor acht Monaten Zugriff auf ein ePHI-System hatte, stehen diese Informationen sofort zur Verfügung. Wenn ein CMMC-Assessor Nachweise für Least-Privilege-Zugriffskontrollen bei einem Subunternehmer mit CUI-Zugriff verlangt, ist der Audit-Trail vorhanden - ein wichtiger Baustein einer stringenten cui compliance.
Entscheidend ist, dass Iden fein granulare Steuerung ermöglicht - Provisionierung und Deprovisionierung auf Kanal-, Repository- und Projektebene, nicht nur auf Applikationsebene. Das ist der Unterschied zwischen bloßer Erfüllung des Wortlauts einer Compliance-Vorgabe und der tatsächlichen Beseitigung des Zugriffsrisikos.
Für Unternehmen in Verteidigung, Gesundheitswesen oder Finanzdienstleistungen, die festgestellt haben, dass ihre bisherigen Werkzeuge nur die 20-30 % des Stacks abdecken, die SCIM unterstützen, schließt Iden diese Lücke - ohne Enterprise-Plan-Upgrade, ohne sechsmonatige Implementierung und ohne dediziertes IAM-Team. Wer etwa itar compliance software und moderne Identity Governance zusammenbringen will, kommt mit klassischen IGA-Produkten kaum ans Ziel - Iden adressiert genau diese Lücke.
Um zu verstehen, wie sich regulierte Branchen hinsichtlich der Anforderungen an Third-Party-Governance unterscheiden, bietet unser Buyer's Guide zu Regulatory-Ready Identity Governance eine detaillierte Betrachtung von HIPAA, CMMC, DORA, NIS2 und SOC 2.
Fazit
Im Jahr 2026 senden die Regulierungsrahmen im Gesundheitswesen, in der Verteidigung und in den Finanzdienstleistungen eine eindeutige Botschaft: Zugriffe von Dienstleistern sind kein Sonderfall. Sie sind im Scope. Sie müssen gesteuert werden. Und Sie brauchen den Audit-Trail, um das zu belegen.
Die HIPAA-Vorgabe zur Konto-Deaktivierung innerhalb einer Stunde. Der CMMC-Flowdown von CUI-Anforderungen auf Subunternehmer. Das DORA-Register für ICT-Drittparteien. Die SOC-2-Anforderung an belastbare Vendor-Access-Nachweise. Das sind keine "Best Practices", sondern durchsetzbare Kontrollen - und Prüfer achten gezielt darauf.
Die Unternehmen, die diese Audits bestehen, sind nicht diejenigen mit den meisten Policies. Es sind diejenigen mit dem richtigen Tooling für die Umsetzung: automatisiertes On- und Offboarding von Contractors, Full-Stack-Abdeckung, fein granulare Kontrollen und unveränderliche Audit-Logs, die Compliance-Fragen in Minuten statt in Wochen beantworten.
Das ist kein Merkmal klassischer IGA-Plattformen. Das leisten reine SCIM-Tools nicht. Es ist das Bild vollständiger Identity Governance - und genau das wird in regulierten Branchen heute verlangt.
