NIS2 ist 2026 kein Papiertiger mehr
Die NIS2-Richtlinie hätte bereits im Oktober 2024 in nationales Recht überführt sein müssen. Deutschland hinkte mit dem NIS2-Umsetzungsgesetz hinterher, doch 2026 ist die Lage klar: Der Rechtsrahmen greift, die Aufsichtsbehörden sind eingespielt, und die EU-Kommission hat säumige Mitgliedstaaten längst gemahnt. In Österreich gilt das novellierte NISG, in der Schweiz wirkt NIS2 über das EU-Marktprinzip und die Meldepflichten des revidierten Informationssicherheitsgesetzes indirekt hinein. Für Unternehmen im DACH-Raum heißt das: Wer bislang gehofft hat, das Thema aussitzen zu können, hat kein Argument mehr.
Der entscheidende Unterschied zur alten NIS-Richtlinie liegt in zwei Punkten. Erstens sind Geschäftsleitungen persönlich verantwortlich und haftbar. Die Leitungsorgane müssen Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und sich schulen lassen. Zweitens rückt die Lieferkette ins Zentrum. Artikel 21 der Richtlinie verlangt ausdrücklich die Absicherung der Sicherheit in der Lieferkette, einschließlich der Beziehungen zwischen jeder Einrichtung und ihren unmittelbaren Anbietern und Diensteanbietern. Software, die Sie einkaufen oder entwickeln lassen, ist damit kein reines Beschaffungsthema mehr, sondern regulatorisch relevant und im Ernstfall bußgeldbewehrt.
Wer 2026 wirklich in den Anwendungsbereich fällt
Der Kreis der betroffenen Organisationen ist deutlich größer als unter der alten Regelung. Es gilt eine Größenschwelle: Erfasst sind grundsätzlich mittlere und große Einrichtungen ab 50 Beschäftigten oder zehn Millionen Euro Jahresumsatz, die in einem der geregelten Sektoren tätig sind. Die Richtlinie unterscheidet dabei zwischen wesentlichen Einrichtungen wie Energie, Verkehr, Bankwesen, Gesundheit, Trinkwasser und digitaler Infrastruktur sowie wichtigen Einrichtungen wie Post- und Kurierdiensten, Abfallwirtschaft, Chemie, Lebensmittelproduktion, verarbeitendem Gewerbe und Anbietern digitaler Dienste.
Zwei Missverständnisse halten sich hartnäckig. Das erste: Viele Mittelständler glauben, als reiner Zulieferer nicht betroffen zu sein. Tatsächlich gibt es unabhängig von der Größe Sonderfälle, etwa qualifizierte Vertrauensdiensteanbieter, DNS-Dienste oder Anbieter öffentlicher elektronischer Kommunikationsnetze. Das zweite: Selbst wenn Sie formal nicht direkt reguliert sind, erreicht Sie NIS2 durch die Hintertür. Ihre regulierten Kunden müssen ihre Lieferkette absichern und geben die Anforderungen vertraglich an Sie weiter. Ein Softwarehaus, das ein Krankenhausinformationssystem oder eine Logistikplattform betreibt, wird die NIS2-Pflichten seiner Kunden in seinen Verträgen wiederfinden, ob es selbst in den Anwendungsbereich fällt oder nicht.
Praktischer Rat: Führen Sie eine dokumentierte Betroffenheitsanalyse durch und archivieren Sie sie. Auch das begründete Ergebnis, nicht betroffen zu sein, ist ein wertvolles Dokument gegenüber Kunden, Auditoren und Versicherern.
Lieferanten-Due-Diligence, die einer Prüfung standhält
Lieferketten-Sicherheit unter NIS2 bedeutet nicht, einmalig einen Fragebogen zu verschicken. Gefordert ist ein wiederkehrender, belegbarer Prozess über den gesamten Lebenszyklus einer Lieferantenbeziehung. Aufsichtsbehörden und Kundenauditoren fragen nicht, ob Sie Ihren Anbietern vertrauen, sondern womit Sie dieses Vertrauen begründen.
Ein tragfähiger Due-Diligence-Prozess umfasst diese Schritte:
- ▸Kritikalität einstufen: Kategorisieren Sie jeden Lieferanten nach Zugriff auf Daten, Systeme und Geschäftsprozesse. Ein Anbieter mit Administrationsrechten auf Produktionssystemen verdient eine andere Prüftiefe als ein reiner Grafikdienstleister.
- ▸Sicherheitsniveau nachweisen lassen: Verlangen Sie Belege statt Behauptungen. ISO 27001, SOC-2-Typ-2-Berichte, ein aktueller Penetrationstest oder ein ausgefüllter, unterschriebener Sicherheitsfragebogen sind belastbare Nachweise.
- ▸Vertraglich verankern: Schreiben Sie Meldefristen für Sicherheitsvorfälle, Audit- und Informationsrechte, Subunternehmer-Transparenz, Verschlüsselungs- und Patch-Anforderungen sowie das Recht zur außerordentlichen Kündigung bei gravierenden Mängeln fest.
- ▸Software-Bestandteile offenlegen: Fordern Sie eine Software Bill of Materials, damit Sie bei der nächsten kritischen Schwachstelle in einer Open-Source-Komponente innerhalb von Stunden statt Wochen wissen, ob Sie betroffen sind.
- ▸Kontinuierlich überwachen: Setzen Sie auf jährliche Neubewertungen, Schwachstellen-Monitoring und definierte Reaktionswege, wenn ein Anbieter selbst einen Vorfall meldet.
- ▸Alles dokumentieren: Halten Sie Entscheidungen, Nachweise und Ausnahmen versioniert fest. Was nicht dokumentiert ist, existiert für einen Auditor nicht.
Dieser Prozess greift ineinander mit anderen 2026 wirksamen Regelwerken: DORA verlangt für den Finanzsektor ein sehr ähnliches Register der IKT-Drittdienstleister, die DSGVO fordert Auftragsverarbeitungsverträge, und der EU AI Act ergänzt bei KI-Komponenten Transparenz- und Risikopflichten. Wer die Due Diligence einmal sauber aufsetzt, bedient mehrere Regime gleichzeitig.
Auditierbare Sicherheit in Software einbauen, nicht nachträglich aufkleben
Der teuerste Fehler ist, Sicherheit als abschließende Prüfung vor dem Go-live zu verstehen. Prüffähigkeit entsteht nur, wenn Nachweise als Nebenprodukt der täglichen Entwicklung automatisch anfallen. Auditierbar heißt: Für jede sicherheitsrelevante Entscheidung existiert eine nachvollziehbare Spur, ohne dass jemand sie nachträglich rekonstruieren muss.
Konkret bauen wir Prüffähigkeit über mehrere Ebenen auf. In der CI-Pipeline laufen automatisierte Abhängigkeits- und Schwachstellenscans, statische Codeanalyse und Secret-Scanning bei jedem Commit, sodass jeder Merge einen datierten Sicherheitsnachweis hinterlässt. Die Software Bill of Materials wird bei jedem Build automatisch erzeugt und versioniert. Zugriffe folgen dem Least-Privilege-Prinzip mit rollenbasierten Rechten, und jede privilegierte Aktion landet in einem manipulationssicheren, zentralisierten Audit-Log. Infrastruktur wird als Code beschrieben, damit jede Änderung an Firewalls, Netzsegmenten oder Verschlüsselung reviewt, versioniert und reproduzierbar ist. Vorfallreaktion wird als Runbook mit klaren Meldeketten geprobt, damit die NIS2-Frühwarnung binnen 24 Stunden und der Zwischenbericht binnen 72 Stunden realistisch einhaltbar sind. So wird ein Audit von einer Feuerwehrübung zum Export bereits vorhandener Belege.
Wie TuniCyberLabs das umsetzt: Nearshore aus Tunesien, verankert in der EU
TuniCyberLabs ist bewusst so aufgestellt, dass Compliance und Engineering nicht kollidieren. Unsere Muttergesellschaft sitzt in Estland (Tallinn), unser Büro in Zypern (Limassol), unser Engineering-Team im tunesischen Sousse. Für Sie bedeutet das: EU-Vertragsrahmen und DSGVO-konforme Auftragsverarbeitung über die estnische Gesellschaft, kombiniert mit echter Nearshore-Nähe. Sousse liegt in der mitteleuropäischen Zeitzone, unsere Entwickler arbeiten in Ihrem Arbeitstag, nicht mit zwölf Stunden Versatz, und wir kommunizieren nativ auf Deutsch, Englisch, Französisch und Arabisch.
So bauen wir: Zuerst verstehen wir Ihren regulatorischen Kontext und Ihre Bedrohungslage, klären ob und wie NIS2, DORA oder der AI Act greifen und leiten daraus konkrete Sicherheitsanforderungen ab. Dann designen wir eine Architektur, in der Segmentierung, Verschlüsselung, Protokollierung und Least Privilege von Beginn an eingeplant sind, statt nachträglich verschraubt zu werden. Anschließend bauen und deployen wir produktionsreife Systeme mit den oben beschriebenen automatisierten Nachweisen in der Pipeline, und schließlich begleiten wir Betrieb und Weiterentwicklung mit Monitoring, Patch-Management und geprobter Vorfallreaktion. Sie erhalten hochwertiges Custom-Engineering zu Nearshore-Konditionen und Software, die nicht nur funktioniert, sondern einem Audit standhält.
NIS2 ist keine reine Bürde. Wer Lieferketten-Sicherheit und Prüffähigkeit sauber aufsetzt, gewinnt schnellere Vertragsabschlüsse mit regulierten Kunden, niedrigere Versicherungsprämien und ein belastbares Fundament für die nächste Regulierungswelle. Der beste Zeitpunkt, das aufzubauen, war gestern. Der zweitbeste ist heute.