Ein genehmigter Unterauftragnehmer ist noch kein genehmigtes Administratorkonto. Umgekehrt beweist ein technisch freigeschalteter Zugang nicht, dass das dahinterstehende Unternehmen für die betreffende Leistung zugelassen wurde. Bei Fernwartung müssen deshalb Vertragsbeziehung, tatsächliche Person oder technische Identität und konkreter Wartungsauftrag zusammengeführt werden.
Das Ergebnis ist ein Abgleichregister. Es zeigt, welche Zugänge erforderlich und freigegeben sind, welche Zuordnung fehlt und wie entfernte Berechtigungen überprüft wurden. Die Methode ergänzt das übergreifende Management von IKT-Drittparteirisiken, ersetzt aber keine Prüfung der jeweils anwendbaren vertraglichen oder gesetzlichen Anforderungen.
Den Wartungsvorgang als Ausgangspunkt wählen
Beginnen Sie mit einem bestimmten System und einer konkreten Leistung. Halten Sie fest, wer den Hauptauftrag ausführt, welche weiteren Unternehmen beteiligt sind und welche technischen Tätigkeiten sie übernehmen. Eine allgemeine Liste aller Konzernunternehmen des Dienstleisters beantwortet diese Frage nicht.
Ermitteln Sie anschließend die tatsächlichen Zugangswege: Wartungsportal, VPN, Sprungserver, cloudbasierte Verwaltung, lokale Konten und technische Schlüssel. Ein Weg kann mehrere Systeme erreichen. Ein einzelnes Unternehmen kann zugleich mehrere Wege nutzen. Das Register muss diese Beziehungen abbilden können, ohne sie auf einen einzigen Namen zu reduzieren.
Die Informationssicherheitsrichtlinie sollte Zuständigkeiten und Freigabegrundsätze vorgeben. Der konkrete Abgleich hält fest, wie diese Vorgaben für einen Wartungsfall umgesetzt werden und welche Abweichungen bestehen.
Vertragsfreigabe und technische Freigabe trennen
Prüfen Sie zunächst, welche Unternehmen nach dem jeweiligen Vertrag eingesetzt werden dürfen und für welche Leistungen. Bei personenbezogenen Daten ist zusätzlich die passende Rollen- und Vertragsprüfung erforderlich. Der Leitfaden zur Auftragsverarbeitung behandelt diesen rechtlichen Zusammenhang; eine technische Zugriffsliste ersetzt ihn nicht.
Die technische Freigabe beantwortet andere Fragen: Welche Identität darf wann welche Handlung auf welchem Zielsystem ausführen? Welche Authentisierung ist notwendig? Wer kann den Zugang beenden? Eine allgemeine Zustimmung zum Unternehmen darf nicht als unbegrenzte Erlaubnis für sämtliche technischen Konten verstanden werden.
Dokumentieren Sie beide Entscheidungen mit Datum und Verantwortlichem. Wenn eine Freigabe nur für eine bestimmte Wartungsleistung gilt, muss diese Einschränkung im Register sichtbar bleiben. Ein späterer Auftrag benötigt gegebenenfalls eine erneute Prüfung, auch wenn derselbe Dienstleister beteiligt ist.
Das Abgleichregister aufbauen
| Feld | Inhalt | Typischer Befund |
|---|---|---|
| Unternehmen | Hauptauftragnehmer und Unterauftragnehmer | Schreibweisen stimmen nicht überein |
| Leistung | System, Aufgabe und Wartungsbedarf | Konto ohne aktuellen Auftrag |
| Identität | Stabile Konto-ID und verantwortliche Person | Geteiltes Konto ohne nachvollziehbare Zuordnung |
| Berechtigung | Rolle, Zielsystem und erreichbare Ressourcen | Breitere Rechte als für die Aufgabe nötig |
| Zeitfenster | Beginn, Ende und Verlängerungsentscheidung | Dauerzugang für einen einmaligen Einsatz |
| Freigaben | Vertragliche und technische Referenzen | Eine der beiden Entscheidungen fehlt |
| Nutzung | Verfügbare Protokolle und deren Zeitraum | Nutzung außerhalb des vereinbarten Fensters |
| Abschluss | Entzug, Prüfung und offene Ausnahme | Ticket geschlossen, Zugriff weiter möglich |
Verwenden Sie stabile Kennungen für Unternehmen und Konten. Namen allein sind für einen verlässlichen Abgleich zu unsicher. Halten Sie außerdem die Herkunft jeder Liste fest, damit später nachvollziehbar ist, ob eine Abweichung auf veralteten Vertragsdaten oder auf der technischen Umgebung beruht.
Vier Listen miteinander vergleichen
Benötigt werden die genehmigten Unternehmen, die aktuellen Wartungsaufträge, die eingerichteten Konten und die beobachteten Zugriffe. Keine dieser Listen ist für sich vollständig. Ein Konto kann eingerichtet, aber ungenutzt sein; ein genutzter Sammelzugang kann mehrere Personen verdecken.
Prüfen Sie die Verbindungen einzeln. Existiert zu jedem aktiven Konto ein verantwortliches Unternehmen? Gibt es einen aktuellen Bedarf? Decken die Freigaben das Zielsystem ab? Passt die Nutzung zum erlaubten Zeitraum? Fehlende Verbindungen werden als eigene Befunde erfasst, statt durch Vermutungen ergänzt zu werden.
NIST SP 1305 liefert einen Rahmen für Risiken in Lieferbeziehungen. NIST SP 800-53A beschreibt Methoden zur Bewertung von Kontrollen. Beide Quellen wurden am 27. September 2026 geprüft; das hier vorgeschlagene Register ist eine eigene Umsetzungshilfe.
Beispiel: Wechsel des Wartungspartners
Ein fiktives Unternehmen beauftragt einen Hauptdienstleister mit der Wartung seiner Produktionsplanung. Dieser ersetzt seinen bisherigen Unterauftragnehmer durch einen neuen Partner. Der Einkauf dokumentiert den Wechsel, während die IT lediglich neue Konten anlegt. Die alten Konten bleiben bestehen, weil niemand ihre Kennungen dem ausgeschiedenen Unternehmen zuordnet.
Der Abgleich verbindet die Vertragsänderung mit dem technischen Verzeichnis. Zwei alte Konten haben weiterhin Zugriff auf den Sprungserver; eines besitzt zusätzlich eine lokale Berechtigung auf dem Zielsystem. Der Wartungsbedarf besteht für diese Identitäten nicht mehr. Die Entscheidung umfasst deshalb beide Ebenen des Entzugs.
Nach der Änderung prüft die IT die Gruppenmitgliedschaften und den direkten Zugang zum Zielsystem. Die neue Wartungsfirma erhält nur die für ihren Auftrag vorgesehenen Rechte. Ein kontrollierter Funktionstest bestätigt, dass die erforderliche Wartung möglich bleibt. Das Register enthält die ursprünglichen Konten, die Entscheidung und die Nachweise des Ergebnisses.
Der Fall zeigt auch eine organisatorische Ursache: Vertragsänderungen erreichen den technischen Kontenverantwortlichen nicht zuverlässig. Die Korrektur betrifft daher nicht nur zwei Konten, sondern auch die verbindliche Übergabe bei einem Partnerwechsel.
Sammelkonten und technische Identitäten behandeln
Ein Sammelkonto erschwert die Zuordnung einer Handlung zu einer Person. Prüfen Sie, ob individuelle Zugänge möglich sind und welche Nachweise bei einem unvermeidbaren gemeinsamen Zugang verfügbar bleiben. Eine Namensliste in einer E-Mail beweist nicht, wer eine konkrete Sitzung tatsächlich genutzt hat.
Technische Konten benötigen einen internen Verantwortlichen, einen beschriebenen Zweck und einen geregelten Umgang mit Zugangsmitteln. Hinterlegen Sie keine nutzbaren Geheimnisse im Abgleichregister. Verweisen Sie auf die dafür vorgesehene, geschützte Verwaltung und dokumentieren Sie die Prüfung der Berechtigungen.
Das Protokollierungskonzept hilft bei der Frage, welche Ereignisse nachvollziehbar sein müssen. Erfassen Sie auch die Grenzen: fehlende Sitzungsdaten, kurze Aufbewahrung oder nicht erfasste Zielsysteme. Ein unvollständiges Protokoll darf nicht als Nachweis verwendet werden, dass es keinerlei Zugriff gab.
Ausnahmen mit einem Ende versehen
Für dringende Wartung kann ein temporärer Zugang notwendig sein. Dokumentieren Sie Anlass, Zielsystem, genehmigende Person, Einschränkungen und Ende. Die Dringlichkeit erklärt den beschleunigten Prozess, beseitigt aber nicht die Notwendigkeit einer späteren Prüfung.
Prüfen Sie, ob das Ende technisch durchgesetzt wird oder eine manuelle Aufgabe auslöst. Bei manueller Entfernung braucht es einen Verantwortlichen und eine Eskalation. Ein Datum in einer Tabelle beendet keine Sitzung und entfernt keine Gruppenmitgliedschaft.
Wenn eine sofortige Sperrung den Betrieb gefährden würde, halten Sie den konkreten Konflikt und eine begrenzte Zwischenlösung fest. Die zuständige Person entscheidet über das verbleibende Risiko. Die Ausnahme darf nicht stillschweigend zu einem dauerhaften Standardzugang werden.
Entfernung und Wirksamkeit nachweisen
Unterscheiden Sie angeordneten Entzug, ausgeführte Änderung und bestätigtes Ergebnis. Prüfen Sie mögliche alternative Wege, etwa direkte Rollen, verschachtelte Gruppen oder lokale Konten. Ein erfolgreicher Löschbefehl für eine Identität beweist nicht, dass ein Unternehmen keinerlei weitere Zugänge besitzt.
Die Sicherheitsanforderungen des Artikels 32 DSGVO bilden bei personenbezogenen Daten einen zusätzlichen Kontext. Die konkrete Verifikation richtet sich nach dem System und dem Risiko. Bewahren Sie nur die erforderlichen Nachweise auf und schützen Sie das Register, weil es sensible Informationen über administrative Wege enthält.
Den Abgleich im Betrieb erhalten
Lösen Sie eine erneute Prüfung bei Partnerwechsel, neuer Leistung, erweitertem Zugriff, beendetem Vertrag oder unerwarteter Nutzung aus. Ergänzen Sie einen risikogerechten regelmäßigen Abgleich, ohne eine universelle gesetzliche Frist zu behaupten. Entscheidend ist, dass die gewählte Organisation tatsächlich funktioniert.
Ein vollständiger Abschluss zeigt für jeden relevanten Zugang Unternehmen, Bedarf, Freigabe und Ergebnis. Offene Zuordnungen bleiben mit Verantwortlichem sichtbar. Damit kann ein neuer Mitarbeiter den Fall übernehmen, ohne zuerst Vertragsakten, Tickets und technische Listen unabhängig voneinander rekonstruieren zu müssen.
Einen Abgleich ohne Treffer kontrollieren
Auch ein scheinbar fehlerfreier Abgleich benötigt eine kurze Plausibilitätsprüfung. Vergleichen Sie die Anzahl der Konten mit der vorherigen Erhebung und erklären Sie größere Abweichungen. Eine leere Liste kann bedeuten, dass keine Zugänge vorhanden sind, aber auch, dass ein Filter oder eine Abfrage nicht funktioniert hat. Prüfen Sie deshalb mindestens einen bekannten Zugang und ein bekanntes Zielsystem. Halten Sie außerdem fest, welche Wartungswege die Abfrage nicht erfasst. Erst diese Kontrolle erlaubt es, fehlende Treffer als belastbare Information zu verwenden und den Prüfbericht mit einem nachvollziehbaren Umfang abzuschließen. Bleibt dabei ein Konto ohne sichere Zuordnung, beginnt die gesonderte Klärung von Identität und Wartungsbedarf.
Einen unklaren Zugang bis zur Klärung einordnen
Beim Abgleich entsteht häufig kein eindeutiger Treffer. Ein Konto trägt etwa den Namen des Hauptdienstleisters, die Sitzung kommt aber aus dem Netz einer anderen Firma. Weder der Kontoname noch die Netzadresse beweist allein, wer gehandelt hat. Erfassen Sie zunächst die verfügbaren Anhaltspunkte: Zeitpunkt, Zugangspfad, Auftrag, Sitzungskennung, hinterlegte Kontaktperson und die Quelle jeder Information. Markieren Sie die Zuordnung als ungeklärt, statt den wahrscheinlichsten Namen stillschweigend zu übernehmen.
Die Entscheidung über eine Zwischenmaßnahme hängt vom erreichbaren System und vom aktuellen Bedarf ab. Bei einem ruhenden Konto ohne Auftrag kann eine vorläufige Sperre naheliegen. Für eine laufende Störungsbehebung kann ein eng begrenzter, beaufsichtigter Zugriff erforderlich sein, während die Identität geklärt wird. Diese Beispiele sind Empfehlungen für die Risikobewertung, keine pauschale Sperrpflicht. Halten Sie fest, wer die Zwischenlösung genehmigt, welche Zugriffswege sie umfasst und wann erneut entschieden wird.
Fordern Sie beim Hauptauftragnehmer eine Zuordnung zu einer konkreten Leistung und einer verantwortlichen Person an. Fragen Sie ausdrücklich, ob weitere Unternehmen oder gemeinsam genutzte Konten beteiligt sind. Eine Antwort „gehört zu unserem Support“ reicht für einen weitreichenden Administratorzugang nicht aus. Prüfen Sie anschließend die Aussage gegen technische Daten und den Auftrag. Wenn die Belege nicht zusammenpassen, bleibt der Befund offen und wird an Vertrags- und Systemverantwortliche übergeben. Das verhindert, dass ein gelöstes Ticket fälschlich als gelöste Zugangsfrage gilt.
Freigabe bei einem geänderten Wartungsauftrag neu bestimmen
Ein neuer Unterauftragnehmer kann dieselbe technische Rolle benötigen wie sein Vorgänger, aber nicht zwingend denselben Zugriffsumfang. Vergleichen Sie zuerst die Arbeitsschritte: Muss er Einstellungen lesen, Änderungen einspielen oder Diagnosedaten exportieren? Daraus ergeben sich unterschiedliche Rechte und mögliche Datenflüsse. Der Vergleich sollte Zielsysteme und Nebenwege einschließen, etwa ein Supportportal, über das sich zusätzliche Protokolle herunterladen lassen.
Legen Sie einen Übergabezeitpunkt fest, an dem alter und neuer Partner eindeutig benannt sind. Falls eine kurze Überschneidung für die Wartung erforderlich ist, beschreiben Sie sie als begrenzte Ausnahme mit Ende und verantwortlicher Überwachung. Prüfen Sie vor der Freigabe des neuen Zugangs, ob die Authentisierung, der Sitzungsweg und die Protokollierung tatsächlich funktionieren. Nach dem letzten Einsatz des alten Partners folgt dessen Entzug; beide Vorgänge benötigen getrennte Ergebnisnachweise.
Bei einem Eilauftrag kann die Vertragsprüfung noch offen sein, während der Betrieb Hilfe verlangt. Eskalieren Sie diese Differenz an die zuständigen Entscheider, statt technische Berechtigungen als stillschweigende Vertragsgenehmigung zu behandeln. Dokumentieren Sie, welche Handlung bis zur Klärung erlaubt ist und welche Daten dabei erreichbar sind. Das entspricht dem Grundgedanken, Lieferantenanforderungen zu definieren und zu kommunizieren, den die NIST-Leitlinie zur Cyber-Lieferkette beschreibt; die konkrete Übergaberegel bleibt eine betriebliche Entscheidung.
Die Aussagekraft der Zugriffsbelege begrenzen
Ein Berechtigungs-Export zeigt in der Regel den Zustand zum Abfragezeitpunkt. Er sagt nicht ohne Weiteres, welche Rolle eine Identität gestern hatte oder ob eine lokale Sitzung bereits geöffnet war. Ein Sitzungsprotokoll zeigt beobachtete Nutzung, aber ein fehlender Eintrag kann an einer nicht angebundenen Quelle, kurzer Aufbewahrung oder einem Filter liegen. Notieren Sie deshalb zu jedem Beleg Quelle, Erhebungszeit, erfasste Systeme und bekannte Lücken. Diese Angaben bestimmen, welche Schlussfolgerung zulässig ist.
Für eine Stichprobe wählen Sie nicht nur ein auffälliges Konto. Nehmen Sie auch einen bekannten, rechtmäßig genutzten Wartungszugang auf. Er muss in Vertragsliste, Auftrag und technischer Liste wiederzufinden sein. So erkennen Sie, ob eine leere oder sehr kleine Treffermenge auf den Abfrageweg zurückgeht. Bei verschachtelten Gruppen prüfen Sie die wirksame Berechtigung auf dem Zielsystem; eine entfernte Mitgliedschaft auf dem Sprungserver lässt eine direkte lokale Rolle möglicherweise unberührt.
Zur Bestätigung eines Entzugs können Konfigurationsstand, Identitätsstatus und ein sicherer Zugriffstest kombiniert werden. Ein Test darf weder Produktionsdaten verändern noch unnötig Geheimnisse offenlegen. Die in NIST SP 800-53A beschriebene Anpassbarkeit von Bewertungsverfahren unterstützt diese Auswahl verschiedener Nachweisarten. Formulieren Sie das Ergebnis genau: „Zugang über die geprüften Wege nicht mehr möglich“ ist belastbarer als die unbelegte Aussage, es existiere nirgends ein Zugang.
Verantwortung für Folgeaufträge verankern
Der Abgleich verliert seinen Wert, wenn er nur einmal zum Audit erstellt wird. Legen Sie fest, welches Ereignis einen neuen Datensatz auslöst: neuer Wartungsauftrag, Erweiterung eines Zielsystems, Wechsel einer Person oder Beendigung der Leistung. Der Vertragsverantwortliche meldet Änderungen der beteiligten Unternehmen; der Systemverantwortliche prüft den technischen Umfang; die Zugangsstelle führt Freigabe und Entzug aus. Diese Rollen können organisatorisch zusammenfallen, ihre Entscheidungen sollten aber unterscheidbar bleiben.
Nutzen Sie eine Übergabe mit eindeutiger Auftrags- und Konto-ID. Eine E-Mail mit einem Unternehmensnamen genügt nicht, wenn mehrere Konten und Systeme betroffen sind. Der Empfänger bestätigt, welche Änderungen er ausgeführt hat und welche nicht möglich waren. Bleibt ein lokales Konto wegen eines offline befindlichen Systems zunächst aktiv, wird der Vorgang mit Frist, Zwischenmaßnahme und erneutem Prüfschritt weitergeführt. Er darf nicht allein wegen einer erledigten zentralen Aufgabe geschlossen werden.
Bei der nächsten Regelprüfung wählen Sie Fälle aus unterschiedlichen Wartungswegen und vergleichen ihre Abschlussbelege. Achten Sie darauf, ob Ausnahmen auffällig oft verlängert werden oder ob Zugänge nach dem Ende eines Auftrags bestehen bleiben. Solche Muster deuten auf eine Lücke im Übergabeprozess hin. Die Korrektur kann eine klarere Benachrichtigung, eine technische Befristung oder eine Änderung der Zuständigkeit sein. Das Register liefert dafür konkrete Fälle, ohne eine vollständige Sicherheit der Lieferkette zu behaupten.