NIS-2 Nachweis: Digitale Signatur als Evidence für Duty of Care

Duty of Care in der Praxis: was NIS-2 von Unternehmen verlangt

Die NIS-2-Richtlinie (EU) 2022/2555 verändert die Cybersicherheitspflichten für eine große Zahl von Unternehmen in Europa. Sie erfasst sogenannte wesentliche und wichtige Einrichtungen in Sektoren wie Energie, Verkehr, Gesundheit, digitale Infrastruktur, Fertigung, Lebensmittel und digitale Dienste. In Deutschland erfolgt die Umsetzung über nationale Gesetze, die das Bundesamt für Sicherheit in der Informationstechnik (BSI) in der Aufsicht prägt. Wer als Softwarehersteller solche Unternehmen beliefert, merkt es früh: Kunden fragen nach Sicherheitsmaßnahmen, Lieferketten und Nachweisen.

Im Kern verlangt NIS-2 eine angemessene Sorgfalt im Risikomanagement. Artikel 21 verpflichtet Einrichtungen zu geeigneten und verhältnismäßigen technischen, operativen und organisatorischen Maßnahmen. Dazu gehören Konzepte für Risikoanalyse und Sicherheit von Informationssystemen, Bewältigung von Sicherheitsvorfällen, Betriebskontinuität, Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu Anbietern, Sicherheit beim Erwerb und bei der Entwicklung von Systemen, Bewertung der Wirksamkeit von Maßnahmen sowie Kryptografie und Zugriffskontrolle. Die Leitungsorgane tragen laut Artikel 20 eine unmittelbare Verantwortung für Billigung und Überwachung dieser Maßnahmen.

Für den Alltag heißt das: Sorgfalt muss nachweisbar sein. Es genügt nicht, Maßnahmen zu haben, man muss zeigen können, dass sie gelten und wirken. Genau hier liegt der Begriff Evidence: belastbare Daten und Dokumente, die einem Prüfer, einer Aufsicht oder der eigenen Geschäftsführung belegen, dass eine Pflicht ernst genommen wurde. Evidence ist weder ein Zertifikat noch ein Gütesiegel, sondern das Material, aus dem Nachweise gebaut werden.

Wie passt die digitale Signatur dazu? Signierte Dokumente sind in vielen Prozessen die Stelle, an der Verantwortung formalisiert wird: Verträge mit Dienstleistern, Auftragsverarbeitungsvereinbarungen, Richtlinien mit Bestätigung durch Mitarbeitende, Freigaben von Sicherheitskonzepten, Abnahmen von Maßnahmen. Wenn diese Vorgänge digital und nachvollziehbar ablaufen, entsteht ein Spurenbild, das die Sorgfalt belegt: Wer hat was wann bestätigt, in welcher Fassung, mit welcher Identifikation? Das ist Evidence für die Duty of Care.

Die eine harte Unterscheidung dieses Beitrags lautet: Ein Audit-Trail belegt, dass etwas geschehen ist. Er belegt nicht, dass es ausreichend war. NIS-2 fragt nach beidem. Ein Unternehmen kann lückenlos belegen, dass jede Mitarbeiterin die Sicherheitsrichtlinie bestätigt hat, und trotzdem eine ungeeignete Richtlinie haben. Die Signatur liefert den ersten Beleg, nicht den zweiten. Wer das verwechselt, riskiert, Nachweisqualität mit Maßnahmenqualität gleichzusetzen.

Ebenso klar sagen wir: Es gibt keine NIS-2-Zertifizierung für Signatur-APIs, und wir behaupten keine. Weder Sign2x noch ein anderer Anbieter kann Ihnen ein Siegel geben, das Ihre Sorgfaltspflichten erfüllt. Was wir liefern können, ist ein Baustein: eine Signaturstrecke, die Abläufe strukturiert protokolliert und Ihnen die Daten in Ihre eigene Hand gibt. Wie Sie diese Daten für Prüfungen nutzen, bleibt Ihre Aufgabe und die Ihres Sicherheits- und Compliance-Teams.

Was der Audit-Trail kann: Evidence aus Signaturvorgängen

Ein Signatur-Audit-Trail entsteht aus den Ereignissen, die eine Signaturstrecke pro Vorgang erzeugt: angelegt, versendet, geöffnet, identifiziert, signiert, abgelehnt, abgelaufen, widerrufen. Mit Zeitpunkt, Rolle, Referenz und Dokumentprüfsumme ergibt sich eine Kette, die einen Ablauf rekonstruierbar macht. Die Daten übermittelt die API per Webhook an Ihr System, wo sie in Ihrer Datenhaltung liegen, unabhängig vom Portal eines Anbieters. Wie Sie das technisch sauber gestalten, beschreibt der Beitrag Webhook State Management für E-Signatur-Events.

Was kann diese Kette im NIS-2-Kontext belegen? Erstens Verantwortungsübernahme: Leitungsorgane und Verantwortliche haben Konzepte, Richtlinien oder Risikoentscheidungen bestätigt, mit Datum und Person. Das stützt den Nachweis, dass die Leitung ihrer Verantwortung nach Artikel 20 nachgekommen ist, ohne ihn zu ersetzen. Zweitens Lieferkettenbeziehungen: Verträge mit IKT-Dienstleistern, Sicherheitsanhänge und Auftragsverarbeitungsvereinbarungen wurden formgerecht abgeschlossen, in welcher Fassung und von wem. Drittens Schulung und Bestätigung: Mitarbeitende haben Richtlinien zur Kenntnis genommen, und die Bestätigung ist zuordenbar.

Viertens Integrität: Weil die Signatur an die Dokumentversion gebunden ist, lässt sich belegen, dass eine Richtlinie in genau dieser Fassung bestätigt wurde. Spätere Änderungen sind erkennbar. Fünftens Zeitbezug: Sie können zeigen, wann Maßnahmen beschlossen und bestätigt wurden, etwa im Verhältnis zu einem Vorfall oder einer Prüfung. Sechstens Konsistenz: Wenn alle relevanten Vorgänge über dieselbe Strecke laufen, ist die Datenlage einheitlich, was Auswertungen und Prüfungen erleichtert. Siebtens Exportierbarkeit: Sie können Nachweise für Dritte aufbereiten, ohne in einem fremden Portal Screenshots zu sammeln.

Damit der Trail diese Leistung erbringt, braucht er ein gutes Schema. Mindestfelder sind Vorgangs-ID, Ereignistyp, UTC-Zeitpunkt, handelnde Rolle, Dokument-Hash und Signaturstufe. Bei AES und QES kommt das Ergebnis der Identifikation hinzu. Verwenden Sie eigene Kennungen für Mandant, Dokumenttyp und fachlichen Zusammenhang, damit Sie Ereignisse später filtern können, etwa „alle Bestätigungen der Informationssicherheitsrichtlinie im dritten Quartal“. Ohne solche Referenzen haben Sie Daten, aber keine Auskunftsfähigkeit.

Für die Auswahl der Signaturstufe gilt: SES oder AES genügt für viele interne Bestätigungen und Verträge, QES nur dort, wo Form oder Anforderung es verlangen. Sign2x unterstützt SES, AES und QES. Wir sind kein QTSP, QES läuft über einen Partner-QTSP wie Sign8. Wichtig für Ihren Nachweis ist, die gewählte Stufe je Dokumenttyp festzuhalten und zu begründen. Hilfe bei der Einordnung bietet der Beitrag AES vs QES per API.

Auch die Hosting-Frage gehört in die Nachweiskette. Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Für die Sicherheit der Lieferkette ist das eine klar benennbare Information: Standort, Betreiber und Rechtsrahmen lassen sich in Ihrer Lieferantendokumentation festhalten. Warum der Standort allein nicht genügt, erklärt der Beitrag Cloud Act vs Datensouveränität. Es ist eine Aussage über Betrieb und Jurisdiktion, keine Zertifizierung Ihres Produkts.

Was er nicht ersetzt: Grenzen ehrlich benennen

Ein Audit-Trail ist nur ein Element eines Sicherheitsmanagements. Er ersetzt keine Risikoanalyse. Ob Ihre Maßnahmen angemessen sind, hängt davon ab, welche Risiken Sie identifiziert, bewertet und behandelt haben. Das ist ein inhaltlicher Prozess mit Fachwissen, der sich nicht durch Protokolle ersetzen lässt. Ebenso wenig ersetzt er technische Schutzmaßnahmen: Verschlüsselung, Zugriffskontrolle, Härtung, Monitoring, Schwachstellenmanagement und Notfallübungen müssen unabhängig davon funktionieren.

Er ersetzt auch keine Vorfallsmeldung. Artikel 23 verpflichtet zu mehrstufigen Meldungen erheblicher Sicherheitsvorfälle an die zuständige Stelle, mit einer Frühwarnung innerhalb von 24 Stunden, einer Meldung innerhalb von 72 Stunden und einem Abschlussbericht. Ein Signatur-Trail kann bei der Rekonstruktion helfen, wenn ein Vorfall Dokumentenprozesse betrifft, aber er löst weder die Erkennung noch die Bewertung noch die Meldung aus. Dafür brauchen Sie eigene Prozesse und Verantwortliche.

Er ersetzt außerdem keine Lieferantenbewertung. Dass ein Vertrag mit einem Dienstleister sauber signiert wurde, sagt nichts darüber aus, ob der Dienstleister sicher arbeitet. Die Bewertung von Anbietern, einschließlich Sicherheitsfragebögen, Zertifikaten, Audits und Verträgen mit Sicherheitsanforderungen, bleibt eine eigene Aufgabe. Die Signatur belegt, dass Verträge geschlossen wurden, nicht dass sie erfüllt werden. Hinweise zu Anforderungen an Informationssicherheit bietet das BSI, zu EU-weiten Perspektiven die ENISA.

Und er ersetzt keine rechtliche Beratung. Welche Pflichten für Ihr Unternehmen gelten, ob Sie wesentliche oder wichtige Einrichtung sind, welche Fristen Sie beachten müssen und wie die nationale Umsetzung aussieht, klären Sie mit Rechtsberatung und Ihrer Compliance. Wir erläutern Technik, nicht Rechtslage im Einzelfall. Wer uns fragt, ob eine bestimmte Maßnahme „NIS-2-konform“ sei, bekommt von uns die Gegenfrage, nach welchem Maßstab und durch wen das geprüft wird, denn ein solches Gütesiegel gibt es nicht.

Zuletzt ersetzt er keine Kultur der Sorgfalt. Evidence entsteht aus Prozessen, die gelebt werden. Wenn Richtlinien nur unterschrieben und nie gelesen werden, ist der Trail formal vollständig und inhaltlich leer. Prüfer erkennen das schnell, und wichtiger: Ein Vorfall erkennt es auch. Nutzen Sie die Signatur als Teil eines Prozesses, der Verständnis erzeugt, etwa mit kurzen Schulungen vor der Bestätigung und Rückfragemöglichkeiten.

Praxisbeispiel: Richtlinienbestätigung und Lieferantenverträge

Zwei Szenarien zeigen, wie der Trail im Alltag wirkt. Im ersten betreibt ein ISV für Gesundheitseinrichtungen ein Produkt, das von Kunden mit NIS-2-Bezug genutzt wird. Der ISV lässt seine Mitarbeitenden jährlich die Informationssicherheitsrichtlinie bestätigen und führt neue Beschäftigte beim Eintritt durch denselben Ablauf. Jede Bestätigung läuft als Signaturvorgang mit AES, die Ereignisse landen in der eigenen Datenhaltung, versehen mit Dokumenttyp und Version der Richtlinie. Fragt ein Kunde im Sicherheitsfragebogen nach Schulung und Bestätigung, exportiert der ISV die Übersicht, statt Listen aus verschiedenen Quellen zusammenzusuchen.

Im zweiten Szenario verwaltet ein ISV seine Dienstleisterverträge, darunter Hosting, Support und Unterauftragnehmer. Jeder Vertrag samt Sicherheitsanhang wird digital geschlossen, und die Datenhaltung führt für jeden Vertrag Gegenpartei, Version, Zeitpunkt und Signaturstufe. Die Lieferantenliste, die Kunden zunehmend verlangen, lässt sich daraus ableiten und aktualisieren. Der ISV kann belegen, dass Verträge formgerecht geschlossen wurden und welche Fassung galt. Wie gut die Dienstleister sind, belegt das nicht, dafür bleibt die Bewertung ein eigener Prozess.

Beide Szenarien haben dieselbe Struktur: ein wiederholbarer Vorgang, ein klares Schema, eine eigene Datenhaltung und ein Export. Der Aufwand liegt nicht in der Signatur, sondern in der Disziplin, Dokumenttypen und Referenzen konsequent zu pflegen. Wer das einmal etabliert hat, gewinnt bei jedem Kundenfragebogen Zeit. Wichtig ist dabei die Ehrlichkeit in der Darstellung: „Wir können belegen, dass die Bestätigung erfolgt ist“ ist eine zutreffende und starke Aussage. „Wir sind damit NIS-2-konform“ wäre es nicht.

Rollen und Verantwortung: wer im Unternehmen den Nachweis pflegt

Evidence entsteht nicht von selbst, und sie gehört nicht in die Verantwortung einer einzelnen Person. Bewährt hat sich eine Aufteilung in drei Rollen. Die fachliche Verantwortung liegt bei den Bereichen, die Richtlinien, Verträge und Freigaben verantworten, etwa Informationssicherheit, Einkauf oder Personal. Sie legen fest, welche Dokumente signiert werden, in welcher Stufe und mit welchem Turnus. Die technische Verantwortung liegt bei Entwicklung oder IT: Sie stellt sicher, dass Ereignisse zuverlässig erfasst, gespeichert und exportierbar sind.

Die dritte Rolle ist die Kontrollfunktion, in vielen Unternehmen die Compliance oder das Risikomanagement. Sie prüft stichprobenartig, ob der Trail vollständig ist, ob Abweichungen erklärt sind und ob die Aufbewahrung den Vorgaben entspricht. Diese Trennung verhindert, dass dieselbe Person Nachweis erzeugt und bewertet. Außerdem ist sie ein Argument gegenüber Aufsicht und Kunden, weil sie zeigt, dass Evidence nicht nur existiert, sondern gepflegt und kontrolliert wird.

Die Leitungsebene sollte den Überblick behalten, ohne in Details zu versinken. Ein quartalsweiser Bericht mit wenigen Kennzahlen genügt: Anteil abgeschlossener Bestätigungen, offene Vorgänge, Auffälligkeiten, Änderungen am Schema. Das passt zum Gedanken des Artikels 20, wonach die Leitungsorgane Maßnahmen billigen und überwachen. Auch hier gilt: Die Signatur ist ein Werkzeug, das diese Überwachung erleichtert, aber nicht ersetzt.

Zusammenspiel mit DORA: zwei Regime, ein Evidence-Fundament

Viele Unternehmen, die NIS-2 betrifft, unterliegen zugleich anderen Regimen. Finanzunternehmen müssen die Verordnung DORA (EU) 2022/2554 erfüllen, die als sektorspezifisches Recht für Fragen der digitalen Betriebsstabilität Vorrang vor allgemeinen Vorgaben hat. Für ISVs, die beide Welten bedienen, lohnt ein gemeinsames Fundament: Wenn Ihr Ereignisbestand strukturiert ist, können Sie ihn für DORA-Nachweise zur IKT-Lieferkette und für NIS-2-Nachweise zur Sorgfaltspflicht gleichermaßen nutzen.

Die Unterschiede liegen im Fokus. DORA richtet sich auf IKT-Risiko und vertragliche Mindestinhalte, die Artikel 30 für IKT-Drittdienstleister vorgibt. NIS-2 richtet sich breiter auf Cybersicherheitsmaßnahmen und Lieferkettensicherheit. Gemeinsam ist beiden die Erwartung, dass Sie belegen können, was Sie zugesagt haben. Der Beitrag DORA Artikel 30 und der Signatur-Audit-Trail zeigt, wie sich dieselben Ereignisse für Lieferkettennachweise nutzen lassen. Das Prinzip ist identisch: Zusage und Beleg trennen und für den Beleg sorgen.

Praktisch bedeutet das, dass Sie einmal ein Evidence-Schema entwerfen und für beide Regime nutzen. Ereignisse werden gespeichert, mit Mandanten- und Dokumenttypreferenz versehen und exportierbar gemacht. Je Regime definieren Sie Abfragen und Berichte: für DORA etwa Verträge mit IKT-Dienstleistern und deren Standorte, für NIS-2 etwa Bestätigungen von Richtlinien und Lieferantenverträge mit Sicherheitsanhang. Die Datenbasis bleibt gleich, die Sicht wechselt.

Eine Warnung: Verwechseln Sie die Regime nicht in der Kommunikation. Wenn ein Kunde nach DORA fragt, antworten Sie nicht mit NIS-2-Formulierungen, und umgekehrt. Beide Regime haben eigene Begriffe, Pflichten und Zuständigkeiten. Ihr Vorteil entsteht nicht daraus, sie zu vermischen, sondern daraus, eine gemeinsame technische Grundlage zu haben und je Regime präzise zu antworten. Eine Übersicht zum Thema Souveränität in der Lieferkette liefert der Beitrag Open Sovereign Cloud für die E-Signatur-API.

Checkliste für ISVs: NIS-2-nahe Evidence vorbereiten

Die folgende Liste ist keine Rechtsberatung. Sie hilft, die Technik so zu gestalten, dass NIS-2-bezogene Kundenfragen ohne Hektik beantwortbar sind.

• Dokumenttypen inventarisieren: Welche Vorgänge in Ihrem Produkt sind sorgfaltsrelevant, etwa Lieferantenverträge, Richtlinienbestätigungen, Freigaben?
• Stufen festlegen: Ordnen Sie je Dokumenttyp SES, AES oder QES zu und halten Sie die Begründung fest.
• Ereignisschema definieren: Vorgangs-ID, Ereignistyp, UTC-Zeit, Rolle, Dokument-Hash, Stufe, Identifikationsergebnis.
• Ereignisse persistieren: Speichern Sie Webhook-Ereignisse in Ihrer eigenen Datenhaltung, idempotent und mit Historie.
• Referenzen vergeben: Mandant, Dokumenttyp und fachlicher Zusammenhang für spätere Auswertungen.
• Export testen: Prüfen Sie, ob Sie Nachweise für Dritte vollständig und nachvollziehbar aufbereiten können.
• Lieferkette dokumentieren: Halten Sie Hosting auf OSC und Partner-QTSP-Rolle in Ihrer Dokumentation fest.
• Grenzen kommunizieren: Formulieren Sie klar, dass der Trail Evidence liefert und keine Zertifizierung ersetzt.

Wenn Sie diese Punkte abgearbeitet haben, steht eine tragfähige Basis. Weitere Orientierung bieten der Developer Hub mit Dokumentation und Sandbox, das Help Center für Begriffe und die Seite Use Cases für Praxisbeispiele. Eine erste Einordnung Ihrer Lage unterstützt das Sign2x Quiz, und weitere Fachartikel finden Sie im Sign2x Blog. Für ein Gespräch zu Ihrer Situation nutzen Sie den Kontakt.

NIS-2-Evidence mit uns besprechen

Verwandte Beiträge: GwG-konforme Signatur-API für ISVs und QTSP-Partner für ISVs. Rechtsgrundlagen der Signaturstufen in der eIDAS-Verordnung.

Häufige Fragen

Gibt es eine NIS-2-Zertifizierung für Signatur-APIs?

Nein. NIS-2 sieht keine Zertifizierung für Signatur-APIs vor. Ein Audit-Trail liefert Evidence für Sorgfaltsnachweise, ersetzt aber weder Risikoanalyse noch technische Maßnahmen.

Was belegt ein Signatur-Audit-Trail im NIS-2-Kontext?

Dass bestimmte Vorgänge geschehen sind: Bestätigungen, Freigaben, Vertragsabschlüsse, mit Zeit, Rolle und Dokumentversion. Er belegt nicht, dass die zugrunde liegenden Maßnahmen ausreichend waren.

Ersetzt der Trail die Meldung von Sicherheitsvorfällen?

Nein. Er kann bei der Rekonstruktion helfen, löst aber weder Erkennung noch Bewertung noch Meldung aus. Dafür brauchen Sie eigene Prozesse.

Wie hängen NIS-2 und DORA bei der Evidence zusammen?

Beide erwarten belegbare Zusagen. Ein gemeinsames Ereignisschema dient als Datenbasis, aus der Sie je Regime eigene Abfragen und Berichte erzeugen.

Wo wird Sign2x gehostet und ist es ein QTSP?

Auf der Open Sovereign Cloud (OSC) von T-Systems. Sign2x ist kein QTSP, für QES läuft die Qualifikation über einen Partner wie Sign8.