IT-Dienstleistervertrag nach NIS2: Sicherheitsklauseln, SLA und Incident-Meldungen

Ein IT-Dienstleistervertrag nach NIS2 darf sich nicht auf eine Konformitätserklärung, eine allgemeine Sicherheitsklausel und eine monatliche Verfügbarkeitskennzahl beschränken. Er muss die mit der Leistung verbundenen Risiken in klare Verantwortlichkeiten, messbare Service Levels, eine schnelle Kommunikation bei Sicherheitsvorfällen, den Zugang zu belastbaren Nachweisen und einen umsetzbaren Exit-Plan übersetzen. Ausgangspunkt sind die Kritikalität der Leistung und die tatsächliche Verteilung der Kontrollmöglichkeiten zwischen den Parteien. Erst auf dieser Grundlage lässt sich festlegen, welche Sicherheitsmaßnahmen, Fristen, Prüfungsrechte und Meldepflichten vertraglich zu regeln sind.

Der Vertrag als Instrument der Risikosteuerung

Die Vertragsprüfung sollte nicht mit einer vorformulierten Sicherheitsklausel beginnen, sondern mit einer Übersicht über die Abhängigkeiten der Organisation von ihren Dienstleistern. Für jeden Anbieter sind die betroffenen Services, Prozesse, Systeme, Daten und Standorte zu erfassen. Anschließend werden die Auswirkungen eines Ausfalls oder einer Sicherheitsverletzung bewertet. Vorrangig zu betrachten sind Abhängigkeiten, deren Störung den Betrieb unterbrechen, die Erfüllung von Verpflichtungen beeinträchtigen oder die Bearbeitung eines Sicherheitsvorfalls erschweren kann. Nicht jede IT-Leistung benötigt daher dasselbe vertragliche Absicherungsniveau.

Die Kritikalitätsklassifizierung eines Dienstleisters sollte auf einer Business-Impact-Analyse und einer Risikobewertung beruhen – nicht allein auf dem Vertragswert. Besondere Aufmerksamkeit erfordern Leistungen, bei denen das Unternehmen für Kontinuität und Incident Management verantwortlich bleibt, während der Anbieter die technischen Informationen, Ereignisprotokolle, Backups oder die für eine Wiederherstellung erforderliche Umgebung kontrolliert. Aufseiten der Organisation ist außerdem ein Verantwortlicher für das dienstleisterbezogene Risiko zu benennen. Fehlt diese Rolle, bleibt die Verantwortung zwischen Einkauf, IT, Informationssicherheit und Prozessverantwortlichen verteilt.

Die Vertragsinhalte sollten anhand konkreter Störungsszenarien entwickelt werden: Serviceausfall, Cyberangriff, Verlust oder Beschädigung von Daten, Ausfall von Personal des Dienstleisters, Unterbrechung der Unterauftragnehmerkette und Beendigung der Zusammenarbeit. Für jedes Szenario sind Maßnahmen, Verantwortlichkeiten, Informationswege und Wiederherstellungsbedingungen festzulegen. Daraus ergeben sich Verfügbarkeitsziele, Reaktions- und Wiederherstellungszeiten, die erforderliche Dokumentation sowie angemessene Prüfungsrechte.

Die Zusage einer hohen Verfügbarkeit beantwortet nicht, wie lange beispielsweise ein Produktionsleitsystem ausfallen darf, ab welchem Zeitpunkt die Ausfallzeit gemessen wird oder wer die für die Incident-Bewertung benötigten Daten bereitstellt. Ebenso wenig gewährleistet sie den Zugang zu Kopien von Ereignisprotokollen, Informationen über Unterauftragnehmer oder Daten für einen sicheren Anbieterwechsel. Solche Lücken werden meist erst im Störungsfall sichtbar – also genau dann, wenn die Verantwortungsverteilung nicht länger unausgesprochen bleiben kann.

Ein Verweis auf NIS2 oder die einschlägigen Anforderungen des KSC sollte die Analyse von Risiken und Verantwortlichkeiten abschließen, aber nicht die operativen Vertragsregelungen ersetzen. Den weiter gefassten Managementkontext erläutert der Beitrag NIS2 für Produktionsunternehmen: Wer ist betroffen, welche Pflichten gelten und wie lässt sich die Organisation vorbereiten, ohne das Thema ausschließlich auf die IT zu reduzieren. Der Änderungsumfang eines Vertrags ist jeweils an die Rolle der Organisation, die Kritikalität der Leistung und die tatsächliche Verteilung der Kontrollmöglichkeiten anzupassen.

Leistungsumfang und Verantwortlichkeiten

Die Aufgabenverteilung gehört in einen technischen Anhang und sollte nicht in einer allgemeinen Beschreibung des Vertragsgegenstands verbleiben. Der Anhang sollte die betreuten Ressourcen und Umgebungen, Datenarten, Verarbeitungs- und Leistungsstandorte, Schnittstellen, Supportzeiten und Ausschlüsse benennen. Ohne diese Angaben lässt sich nicht eindeutig bestimmen, wo die Verantwortung des Anbieters endet, welches Ereignis die SLA-Messung auslöst und wer die Übergänge zwischen Systemen absichert.

Sicherheitsmaßnahmen sollten über das erwartete Ergebnis, die verantwortliche Partei und den erforderlichen Umsetzungsnachweis beschrieben werden. Technische Einzelheiten können in gelenkter technischer Dokumentation geführt werden. So sinkt das Risiko, dass der Vertrag durch technische Änderungen schnell veraltet. Einen standardisierten Maßnahmenkatalog des Dienstleisters sollte der Auftraggeber erst übernehmen, nachdem er ihn mit den Risiken der konkreten Leistung abgeglichen und festgestellte Lücken geschlossen hat. Eine Verantwortungsmatrix sollte zwischen dem Verantwortlichen für die Maßnahme, der ausführenden Stelle und der Instanz unterscheiden, die Ausnahmen genehmigen darf.

Wird die Umgebung durch den Dienstleister administriert, muss der Vertrag zusätzlich den privilegierten Zugriff regeln: Funktionstrennung, Authentisierungsverfahren, Protokollierung administrativer Tätigkeiten und unverzüglichen Entzug von Berechtigungen bei Rollenwechsel oder Beendigung der Zusammenarbeit. Die bloße Erklärung, dass Backups erstellt werden, reicht nicht aus, wenn der Kunde nicht weiß, wer sie verschlüsselt, wo sie gespeichert sind, wer sie wiederherstellen kann und welcher Nachweis das Ergebnis eines Wiederherstellungstests dokumentiert.

Der Anbieter sollte ein aktuelles Verzeichnis aller für die Leistung relevanten Unterauftragnehmer führen, einschließlich ihrer Rollen und Verarbeitungsstandorte, und ihnen mindestens gleichwertige Anforderungen auferlegen. Der Vertrag muss unterscheiden, welche Änderungen einer vorherigen Zustimmung bedürfen und bei welchen eine Benachrichtigung mit erneuter Risikobewertung ausreicht. Ein Managementsystemzertifikat kann diese Bewertung unterstützen, ersetzt jedoch keine servicespezifisch geregelte Verantwortung. Diesen Zusammenhang vertieft der Beitrag NIS2 und DIN EN ISO 27001: Was ein Zertifikat leistet und was für die Erfüllung der KSC-Anforderungen weiterhin fehlt.

Überprüfbare Sicherheitsklauseln

Eine Sicherheitsklausel wird erst dann überprüfbar, wenn sie das erwartete Ergebnis, den Anwendungsbereich, die Häufigkeit der Maßnahme, die Art des Umsetzungsnachweises und den Umgang mit Abweichungen festlegt. Formulierungen wie „nach anerkannten Best Practices“ oder „mit angemessener Sorgfalt“ können konkrete Anforderungen ergänzen. Für sich allein ermöglichen sie jedoch keine belastbare Bewertung, ob der Dienstleister seine Verpflichtung ordnungsgemäß erfüllt hat. Für jede Maßnahme sollten der Anforderungsverantwortliche, die Aufbewahrungsdauer der Nachweise und die zur Genehmigung einer Ausnahme befugte Stelle benannt werden.

Die Anforderungen sollten mindestens das Schwachstellen- und Patchmanagement, sichere Konfigurationen, Verschlüsselung, Schutz und Aufbewahrung von Ereignisprotokollen, Backups, Wiederherstellungstests, Änderungsmanagement und Zugriffskontrollen abdecken. Die Intervalle für Berechtigungsüberprüfungen, Wiederherstellungstests und Berichte sowie die Fristen zur Behebung von Schwachstellen sind aus dem Risiko der jeweiligen Leistung abzuleiten. Einheitliche Vorgaben für sämtliche Dienstleister sind in der Regel nicht risikogerecht.

Jede Abweichung sollte mit Begründung, Behebungsfrist, Risikoverantwortlichem und kompensierenden Maßnahmen in einem Register erfasst werden. Vor der Genehmigung ist zu bewerten, ob die Ersatzmaßnahmen das Risiko tatsächlich auf ein von der Organisation akzeptiertes Niveau reduzieren.

Eine Klausel zur regelmäßigen Datensicherung bleibt unvollständig, wenn sie weder die einbezogenen Daten und Systeme noch die Aufbewahrungsdauer, den Schutz vor Veränderung oder Löschung, die Zugriffsregeln und die Häufigkeit von Wiederherstellungstests festlegt. Sie sollte außerdem regeln, wie der Dienstleister fehlgeschlagene Backups oder Tests meldet, wer die Korrekturmaßnahmen genehmigt und welcher Bericht ihren Abschluss nachweist. Entsprechend benötigt die Pflicht zur Schwachstellenbehebung ein Klassifizierungsverfahren, risikobasierte Reaktionsfristen, Regeln für aufgeschobene Updates und einen dokumentierten Nachweis temporärer Schutzmaßnahmen.

Nachweise sollten in regelmäßig zu übermittelnde Unterlagen und auf Anforderung bereitzustellende Informationen unterteilt werden. Zur ersten Gruppe können zusammenfassende Schwachstellenberichte, Updateberichte, Ergebnisse von Wiederherstellungstests und Bestätigungen durchgeführter Berechtigungsprüfungen gehören. Nach einem Incident, einer wesentlichen Änderung oder einer festgestellten Abweichung können detaillierte Testergebnisse, Ereignisprotokolle, Änderungshistorien, Ausnahmeregister und Korrekturmaßnahmenpläne erforderlich sein. Umfang, Verantwortlichkeiten und Aufbewahrungsfristen dieser Unterlagen sollten mit den im Beitrag NIS2- und KSC-Dokumentation vor einer Prüfung: Welche Richtlinien, Register und Nachweise tatsächlich erforderlich sind dargestellten Grundsätzen abgestimmt werden.

Das Prüfungsrecht sollte abgestuft und auch gegenüber Cloud-Anbietern praktisch umsetzbar sein. Die erste Stufe kann eine Dokumentenprüfung und ein Klärungsgespräch umfassen, die nächste unabhängige Berichte oder vereinbarte Tests. Ein Vor-Ort-Audit kann für ein erhöhtes Risiko, einen wesentlichen Incident oder das Fehlen belastbarer Nachweise vorbehalten werden. Der Vertrag sollte Fristen, Vertraulichkeit, technischen Umfang und den Umgang mit Feststellungen regeln, ohne dem Kunden Rechte einzuräumen, die in einer gemeinsam genutzten Umgebung faktisch nicht ausgeübt werden können.

SLA für Resilienz – nicht nur für Verfügbarkeit

Service Level Agreements sollten aus der Business-Impact-Analyse abgeleitet werden und nicht lediglich den Standardparametern des Anbieters folgen. Der Prozessverantwortliche bestimmt zunächst die tolerierbare Unterbrechungsdauer, den zulässigen Datenverlust sowie die Auswirkungen auf Produktion, Kundenservice, Abrechnung und rechtliche Pflichten. Erst daraus werden Wiederherstellungsziele, Anforderungen an Ersatzleistungen und Notbetriebsverfahren sowie Ticketprioritäten abgeleitet. Eine monatliche Verfügbarkeitsquote beantwortet nicht, ob ein einzelner Ausfall in einem kritischen Zeitfenster den Prozess länger unterbricht, als die Organisation verkraften kann.

Neben der Verfügbarkeit sollte der Vertrag die Fristen für die Bestätigung einer Meldung, den Beginn der Diagnose, die Wiederherstellung der Funktion und die Behebung der Ursache festlegen. Hinzu kommen die Frequenz von Statusmeldungen, Eskalationsstufen und das Vorgehen außerhalb regulärer Betriebszeiten. Reaktionszeit ist nicht gleich Wiederherstellungszeit, und eine Übergangslösung bedeutet noch keine nachhaltige Fehlerbehebung. Die klare Trennung dieser Begriffe zeigt dem operativen Team, wann es wieder arbeitsfähig ist, und dem Service Owner, wann der Anbieter die Ursachenanalyse und eine dauerhafte Korrekturmaßnahme abgeschlossen haben muss.

Bei einem System zur Steuerung eines Produktionsprozesses kann ein kritischer Incident eine sofortige Eskalation und fortlaufende Kommunikation bis zur Aktivierung des Notbetriebs erfordern. Dieselbe Störung in einer Schulungsumgebung kann eine niedrigere Priorität erhalten. Die Klassifizierung muss sich daher an den geschäftlichen Auswirkungen und nicht ausschließlich an der technischen Fehlerbeschreibung orientieren. Liegen belastbare historische Daten vor, sollten bei der Festlegung der Schwellenwerte tatsächliche Reaktions- und Wiederherstellungszeiten, Verfügbarkeitsergebnisse und die Zahl wiederkehrender Störungen berücksichtigt werden.

Der Messmechanismus sollte Datenquelle, Zeitzone, Start und Ende der Zeitmessung, vereinbarte Servicezeiten, Wartungsfenster und Regeln für eine Änderung der Incident-Klasse definieren. Ausschlüsse sind in einem abschließenden und überprüfbaren Katalog festzuhalten. Ereignisse im Verantwortungsbereich des Dienstleisters dürfen nicht pauschal von der Messung ausgenommen werden. Ob diese Regelungen mit der tatsächlichen operativen Bereitschaft übereinstimmen, lässt sich im Rahmen eines NIS2-Audits in einem Produktionsunternehmen – wie sich die Bereitschaft für die neuen Anforderungen bewerten lässt prüfen.

Servicegutschriften oder symbolische Entschädigungen stellen einen Prozess nicht wieder her und begrenzen nicht die Folgen einer Betriebsunterbrechung. Wesentlicher sind die Pflicht zur Vorlage eines Maßnahmenplans, eine Managementeskalation, zusätzliche Resilienztests und ein Kündigungsrecht bei dauerhafter oder wiederholter Unterschreitung der vereinbarten Service Levels. Finanzielle Sanktionen können die Verbindlichkeit erhöhen, ersetzen aber weder die Wiederherstellung der Leistung noch die Ursachenbeseitigung und Prävention weiterer Ausfälle.

Sicherheitsvorfälle und Meldepflichten

Der Vertrag sollte den Dienstleister verpflichten, jedes Ereignis unverzüglich zu melden, das Auswirkungen auf die Leistung, Daten, Geschäftskontinuität oder Sicherheit des Kunden haben kann. Die Erstmeldung darf nicht davon abhängig gemacht werden, dass Ursache, Schadensumfang oder rechtliche Einordnung bereits vollständig geklärt sind. Die vertragliche Frist sollte einen ausreichenden Puffer enthalten, damit der Kunde eine eigene Bewertung vornehmen und gegebenenfalls externe Meldefristen einhalten kann. Sie ist aus der Kritikalität des Services und der Verfügbarkeit eines rund um die Uhr erreichbaren Kontakts abzuleiten – nicht aus der organisatorischen Bequemlichkeit der Parteien.

Der Informationsfluss sollte in Erstwarnung, Lageaktualisierungen, Abschlussbericht und Ursachenanalyse gegliedert werden. Für jede Phase sind Datenumfang, zulässiger Kommunikationskanal, Empfänger, Aktualisierungsfrequenz und Eskalationsregeln bei Nichterreichbarkeit festzulegen. Die Erstmeldung sollte mindestens den Erkennungszeitpunkt, betroffene Ressourcen und Leistungen, die erwarteten Auswirkungen, bereits eingeleitete Maßnahmen, verfügbare technische Indikatoren, das Risiko einer weiteren Ausbreitung und den Zeitpunkt der nächsten Aktualisierung enthalten. Die Kontaktliste muss Vertretungen vorsehen und regelmäßig geprüft werden – auch außerhalb der üblichen Arbeitszeiten.

Erkennt der Anbieter ungewöhnlichen Datenverkehr in der Umgebung einer geschäftskritischen Anwendung, sollte er den Kunden warnen, bevor abschließend feststeht, ob eine Sicherheitsverletzung vorliegt. Der Kunde aktiviert seinen eigenen Incident-Management-Prozess, bestimmt die Entscheidungsverantwortlichen, bindet das Reaktionsteam und gegebenenfalls den Versicherer ein und legt fest, wer externe Meldungen und die Kundenkommunikation freigibt. Der Dienstleister sichert die vereinbarten Protokolle und technischen Spuren, unterstützt Analyse, Eindämmung und Ermittlung des Vorfallsumfangs, übernimmt jedoch nicht die regulatorische Verantwortung des Kunden.

Die Klauseln sollten zudem die Sicherung und Bereitstellung von Nachweisen, den Schutz ihrer Integrität, die Dokumentation von Entscheidungen und die Aufbereitung der für Meldungen und spätere Ursachenanalysen erforderlichen Daten regeln. Fristen, Adressaten und Inhalte externer Meldungen sind jeweils anhand der aktuellen Rechtslage, des Status der Organisation und der Art des Ereignisses zu prüfen. Protokolle zu Meldungen, Entscheidungen, Eskalationen und Maßnahmen sollten mit dem Beitrag „NIS2- und KSC-Dokumentation vor einer Prüfung: Welche Richtlinien, Register und Nachweise tatsächlich erforderlich sind“ verknüpft werden; für den Umsetzungszeitplan ist der Beitrag Umsetzung von NIS2 nach Aufnahme in das KSC-Verzeichnis – Maßnahmenplan bis zum 3. April 2027 relevant.

Umsetzung, Überwachung und sicherer Exit

Mit der Unterzeichnung eines Nachtrags ist das Dienstleistermanagement nicht abgeschlossen. Der Vertragsverantwortliche sollte SLA-Ergebnisse, Incidents, Abweichungen, Korrekturmaßnahmen, Änderungen bei Unterauftragnehmern und die Aktualität der Nachweise regelmäßig überprüfen. Grundlage der Überwachung ist ein Vertragsregister, das mindestens das Verlängerungsdatum, den Verantwortlichen, die Kritikalität der Leistung und den Abstimmungsstatus der Sicherheitsmaßnahmen enthält. Eine Konformitätserklärung ersetzt keine Berichte, Testergebnisse oder Aufzeichnungen, die die tatsächliche Erfüllung der Verpflichtungen belegen.

Vor einer Vertragsverlängerung oder einer wesentlichen Serviceänderung sind Kritikalität, technische und prozessuale Abhängigkeiten, die Konzentration von Leistungen bei einem einzelnen Anbieter, die Umsetzbarkeit der Sicherheitsmaßnahmen und die Möglichkeit eines Wechsels auf eine Ersatzlösung erneut zu bewerten. Auf dieser Grundlage lässt sich entscheiden, ob ein Nachtrag ausreicht oder ein neues Beschaffungsverfahren erforderlich ist. Verweigert ein strategischer Anbieter ein Audit oder eine Vertragsanpassung, sollte die Organisation die Lücke dokumentieren und zwischen kompensierenden Maßnahmen, einer formalen Akzeptanz des Restrisikos und einem Anbieterwechsel entscheiden.

Der Exit-Plan muss bereits vor einer Kündigung praktisch umsetzbar sein. Er sollte die Rückgabe und Übertragung von Daten in einem nutzbaren Format, Migrationsunterstützung, Kontinuität während der Übergangsphase, Entzug von Zugriffsrechten, Löschung von Kopien und die Bestätigung dieser Schritte umfassen. Gleichzeitig sind Aufzeichnungen aufzubewahren, die für rechtliche, beweissichernde oder Audit-Zwecke erforderlich sind. Ein belastbarer Praxistest besteht darin, Daten probeweise bei einem anderen Anbieter wiederherzustellen und dabei Vollständigkeit, Migrationsdauer und die Deaktivierbarkeit der bisherigen Konten zu prüfen.

Die Überarbeitung des Vertragsportfolios sollte bei den Leistungen mit den größten geschäftlichen Auswirkungen beginnen. Festgestellte Lücken sind nach Auswirkung und Dringlichkeit zu priorisieren. Die Wirksamkeit der vereinbarten Mechanismen lässt sich durch eine Incident-Übung und ein Audit stichprobenartig ausgewählter Nachweise überprüfen. Ergebnisse aus SLA-Reviews, Incidents, Abweichungen, Korrekturmaßnahmen und Exit-Tests zeigen, ob die Anforderungen in der Praxis funktionieren oder nur auf dem Papier bestehen.

Der Bewertungsumfang kann an den Beitrag „NIS2-Audit in einem Produktionsunternehmen – wie sich die Bereitschaft für die neuen Anforderungen bewerten lässt“ angelehnt werden. Die Pflichten der Organisation sind dabei unter Berücksichtigung ihres jeweiligen Status zu bestimmen; hierzu bietet der Beitrag NIS2-Richtlinie – für wen gilt sie und welche Unternehmen müssen die neuen Anforderungen erfüllen? eine Einordnung.