MSPs: Kontrollketten vertraglich steuern

Managed Service Provider (MSPs) und Managed Security Service Provider (MSSPs) sind in digitalen Lieferketten mehr als externe Leistungserbringer. Sie betreiben Systeme, verwalten privilegierte Zugriffe, überwachen Sicherheitsereignisse und koordinieren häufig Cloud-, Software- oder weitere Unterauftragnehmer. Damit werden sie zu einer operativen Kontrollschnittstelle: Zwischen dem Risiko der Kundenorganisation und den technischen Abhängigkeiten mehrstufiger Lieferketten.

Entscheidend ist deshalb nicht allein, ob ein Provider allgemeine Sicherheitszusagen oder Zertifikate vorlegt. Kunden und Provider benötigen eine Vertrags- und Kontrollarchitektur, die konkret beschreibt, welche Leistung erbracht wird, wer welche Kontrolle verantwortet, welche Nachweise entstehen und wie bei Sicherheitsvorfällen zusammengearbeitet wird. Der von Trinity College Dublin koordinierte Praxisbericht verweist auf genau diese Herausforderung: Cyber-Lieferketten bilden häufig komplexe Ökosysteme mit nicht transparenten Abhängigkeiten sowie unklaren Kontroll- und Verantwortungsgrenzen.

Regulatorische Maßstäbe sauber trennen

NIS2, DORA und Cyber Resilience Act (CRA) setzen unterschiedliche Bezugspunkte. Sie sollten daher nicht pauschal zu einer einheitlichen Providerpflicht verdichtet werden.

Die Durchführungsverordnung (EU) 2024/2690 gilt unmittelbar für die dort benannten Kategorien relevanter Einrichtungen, darunter bestimmte Cloud-, Rechenzentrums-, Managed-Service- und Managed-Security-Service-Provider. Sie konkretisiert für diesen Anwendungsbereich Anforderungen an Lieferantensteuerung und Vertragsgestaltung. Dazu gehören, soweit angemessen, konkrete Cybersecurity-Anforderungen, unverzügliche Information über Incidents, Audit- oder Auditberichtrechte, Schwachstellenbehandlung, Anforderungen an die Unterauftragsvergabe und Pflichten zum Vertragsende.

DORA ist demgegenüber ein unmittelbar geltender sektoraler Maßstab für Finanzunternehmen. ICT-Verträge müssen Rechte und Pflichten klar schriftlich zuweisen. Bei Leistungen für kritische oder wichtige Funktionen sind unter anderem Leistungsumfang, zulässige Unterauftragsvergabe, Bedingungen dafür sowie Länder oder Regionen der Leistungserbringung und Datenverarbeitung einschließlich Vorabinformation über Standortänderungen abzudecken.

Der CRA ist produktbezogen. Eine reine Managed-Service-Leistung macht einen MSP oder MSSP nicht pauschal zum CRA-pflichtigen Hersteller. Die Rolle ist gesondert zu prüfen, wenn der Provider etwa Software entwickelt, vertreibt, paketiert oder wesentliche Produktänderungen verantwortet. Unterstützt er einen Hersteller bei Build-, Betriebs- oder Vulnerability-Prozessen, entstehen jedenfalls relevante Informations- und Mitwirkungsschnittstellen.

Vom Leistungsversprechen zur Kontrollkette

Eine belastbare Vertragsarchitektur besteht nicht aus einer einzelnen Klausel zu „branchenüblicher Sicherheit“. Sinnvoll ist ein abgestimmtes Paket aus Hauptvertrag, Leistungsbeschreibung, Sicherheitsanhang, Service-Level-Vereinbarung, Kontrollmatrix, Nachweisplan und Unterauftragnehmeranlage. Dieses Modell richtet den Blick nicht auf ein abstraktes Providermerkmal, sondern auf die konkret geschuldete Kontrolle.

Der Sicherheitsanhang sollte für jede wesentliche Leistung Kontrollziele, Messgrößen, verantwortliche Rollen, Nachweisartefakte, Prüffrequenzen, Eskalationswege und Abhilfefristen festlegen. Eine RACI- oder Kontrollmatrix kann dabei die praktische Zuordnung sichtbar machen. Besonders klärungsbedürftig sind:

Identitäts- und Privileged-Access-Management, einschließlich Genehmigung, Rezertifizierung und Sitzungsprotokollierung;
Logging, Monitoring und die Reichweite der Überwachung;
Konfigurations-, Change-, Patch- und Schwachstellenmanagement;
Backup, Wiederanlauf, Tests und Nachweise der Wiederherstellbarkeit;
Forensik, Kommunikationshoheit sowie die Vorbereitung regulatorischer Meldungen.

Die Matrix sollte dabei zwischen der Verantwortung für eine Kunden- oder Behördenmeldung und der technischen Zulieferpflicht des Providers unterscheiden. Der Provider kann beispielsweise Ereignisse erkennen, Belege sichern und Lageinformationen bereitstellen; ob, wann und an wen die Kundenorganisation meldet, ist eine davon getrennte Rolle.

Unterauftragnehmer und vierte Parteien sichtbar machen

Gerade bei Managed Services endet die Leistungserbringung selten beim Vertragspartner. Cloud-Infrastruktur, Softwarekomponenten, spezialisierte SOC-Leistungen oder Betriebsunterstützung können von weiteren Parteien abhängen. Die Durchführungsverordnung verlangt für ihren Anwendungsbereich ein aktuelles Verzeichnis direkter Lieferanten und Dienstleister mit Kontaktstellen sowie den bereitgestellten ICT-Produkten, ICT-Diensten und ICT-Prozessen.

Für kritische Unterauftragnehmer reicht eine pauschale Zustimmung zur Subunternehmernutzung nicht aus. Vertraglich zweckmäßig sind ein gepflegtes Verzeichnis, Risikoklassen und eine Vorabinformation bei wesentlichen Änderungen. Ergänzend sollten dokumentierte Risikobewertungen, die Weitergabe vereinbarter Sicherheitsanforderungen an Subunternehmer und angemessene Abhilfe- oder Kündigungsrechte geregelt werden. DORA-regulierte Kunden sollten zudem Leistungs- und Datenstandorte sowie Veränderungen dieser Standorte gezielt in ihren Vertragsprüfpfad aufnehmen.

Auditrechte müssen praktisch nutzbar bleiben. Wo ein unmittelbares Audit bei einem Unterauftragnehmer nicht erreichbar ist, können Auditberichte oder andere vereinbarte Nachweise eine Rolle spielen. Sie ersetzen jedoch nicht automatisch die Kontrolle, ob die konkret vereinbarten Maßnahmen für den genutzten Service wirksam umgesetzt werden.

Nachweise für Build, Betrieb und Resilienz strukturieren

Nachweise sollten kontrollbezogen angefordert und bewertet werden. Ein Zertifikat kann ergänzende Sicherheit geben, belegt aber nicht ohne Weiteres eine spezifische Betriebsleistung, einen einzelnen Standort oder eine konkrete Subunternehmerbeziehung. Für kritische Beschaffungen nennt die Durchführungsverordnung unter anderem Sicherheitsupdates über den Lebenszyklus, Komponenteninformationen, sichere Konfigurationen, Konformitätszusicherungen und Validierungsnachweise.

Ein praxistauglicher Nachweisplan kann insbesondere folgende Artefakte zuordnen:

privilegierte Zugriffsrezertifizierungen und Sitzungsprotokolle;
Konfigurationsbaselines, Change Records und dokumentierte Freigaben;
Patch- und Schwachstellen-Tickets mit Bearbeitungsstatus;
Nachweise zu Log- und Monitoring-Abdeckung;
Testergebnisse sowie Backup- und Wiederherstellungsnachweise;
bei produktnahen Leistungen Secure-Development-Artefakte und Komponenteninformationen.

Als freiwillige Orientierung nennt der britische Software Security Code of Practice unter anderem geschützte und geloggte Build-Umgebungen, Vulnerability Disclosure, dokumentiertes Vulnerability Management, zeitnahe Sicherheitsupdates sowie Kundeninformationen über Support, Wartung und erhebliche Vorfälle. Die Guidance ist keine unmittelbar übertragbare EU- oder deutsche Rechtspflicht. Sie kann aber als Strukturhilfe für überprüfbare Vertrags- und Nachweisfragen dienen.

Incident-Schnittstellen vor dem Vorfall festlegen

Ein Incident-Anhang sollte keinen isolierten Meldezeitpunkt definieren, sondern einen gemeinsamen Betriebsprozess. Er braucht Auslösekriterien, 24/7-Kontaktstellen, Fristen für die Erstinformation, Mindestinhalte von Lageupdates, einen Aktualisierungsrhythmus, Regeln zur Beweissicherung und Zugriffsmöglichkeiten auf relevante Protokolle. Ebenso wichtig sind die Mitwirkung an Forensik, Kommunikationsfreigaben, Lessons Learned und die Unterstützung bei Kunden- oder Behördenmeldungen.

Für die erfassten MSPs und MSSPs benennt Artikel 10 der Durchführungsverordnung konkrete Kriterien für signifikante Incidents. Dazu zählen etwa eine vollständige Dienstunverfügbarkeit von mehr als 30 Minuten oder eine Beeinträchtigung von Integrität, Vertraulichkeit oder Authentizität von Daten infolge einer mutmaßlich böswilligen Handlung. Solche regulatorischen Kriterien ersetzen jedoch nicht die vertragliche Definition operativer Eskalationsschwellen. Diese sollten früh genug greifen, damit der Kunde seine eigene Bewertung und Kommunikation vorbereiten kann.

In CRA-relevanten Produktkonstellationen sind zusätzliche Informationswege erforderlich. Seit dem 11. September 2026 gelten für CRA-pflichtige Hersteller Meldepflichten zu aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen über die CRA Single Reporting Platform. Verträge können deshalb festlegen, welche technischen Fakten, Komponenteninformationen und Forensikergebnisse ein beteiligter MSP oder MSSP zuliefern muss. Die regulatorische Meldeverantwortung des Herstellers wird dadurch nicht auf den Dienstleister verlagert.

Prüffragen für Vertragsmanagement und Provider Governance

Ist der Serviceumfang einschließlich Betriebsgrenzen, privilegierter Zugriffe und Kundenmitwirkung eindeutig beschrieben?
Existiert eine Kontrollmatrix für Zugangsschutz, Logging, Schwachstellen, Wiederanlauf, Forensik und Meldungen?
Sind Nachweisartefakte, Frequenzen, Empfänger und Folgen bei Abweichungen verbindlich festgelegt?
Werden kritische Unterauftragnehmer, Standorte und wesentliche Änderungen transparent und steuerbar?
Ist der Incident-Prozess als gemeinsamer Ablauf einschließlich Informations-, Beweis- und Eskalationspflichten vorbereitet?

Verträge für Managed Services werden belastbar, wenn sie die reale Kontrollkette abbilden: vom Kunden über den MSP oder MSSP bis zu Cloud-, Software- und weiteren Unterauftragnehmern. Das reduziert weder technische Risiken noch regulatorische Verantwortung automatisch. Es schafft aber nachvollziehbare Zuständigkeiten, prüfbare Sicherheitsleistungen und belastbarere Entscheidungsgrundlagen, wenn ein Vorfall oder eine Lieferkettenänderung tatsächlich eintritt.