NIS2 Checkliste für Software und IT-Consulting: der praktische Fahrplan

Software- und Beratungshäuser sind bei NIS2 doppelt gefragt: einmal für den eigenen Betrieb, einmal als Anbieter, an dem regulierte Kunden ihre Lieferkettenpflicht erfüllen. Was dabei oft untergeht, ist die Frage, welche der beiden Rollen überhaupt greift, und dass für das eigene Produkt noch ein zweites Regelwerk dazukommt.

Wen erfasst die NIS2 Checkliste für Software und IT-Consulting, und wen nicht?

Nicht die Branche entscheidet, sondern die Rolle. Die Anlage 1 des BSIG führt Managed Services Provider und Managed Security Services Provider als eigene Einrichtungsarten, dazu Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Content Delivery Networks, DNS-Diensteanbieter und Vertrauensdiensteanbieter. Wer eine dieser Rollen ausfüllt und die Größenschwellen erreicht, ist selbst Einrichtung im Sinne des Gesetzes.

Die reine Beratung kommt in dieser Aufzählung nicht vor. Ein Haus, das ausschließlich konzipiert, entwickelt und berät, ohne Systeme oder Dienste für andere zu betreiben, wird über den Sektor nicht erfasst. Es wird über die Lieferkette seiner regulierten Kunden gebunden, und das ist eine vertragliche Pflicht und keine gesetzliche. Umgekehrt gilt: Mehrfachbetroffenheit ist der Normalfall. Ein Haus mit Beratung, eigenem Hosting und Managed Services erfüllt mehrere Einrichtungsarten gleichzeitig, und die Einordnung gehört je Geschäftsbereich dokumentiert, nicht für das Unternehmen als Ganzes.

Was verlangt die NIS2 Checkliste für Software und IT-Consulting für die Software-Lieferkette?

Zwei Regelwerke, und das zweite ist konkreter. § 30 Absatz 2 Nummer 5 BSIG verlangt Sicherheit in Beschaffung, Entwicklung und Wartung einschließlich des Managements und der Offenlegung von Schwachstellen. Das reicht in die Entwicklung und nicht nur in den Betrieb.

Deutlich präziser wird der Cyber Resilience Act, sobald ein Produkt in Verkehr gebracht wird. Anhang I Teil II Nummer 1 verlangt die Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen. Und Artikel 13 setzt einen Zeitraum: Der Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre, kürzer nur, wenn die voraussichtliche Nutzungsdauer kürzer ist. Sicherheitsaktualisierungen müssen nach ihrer Bereitstellung mindestens zehn Jahre verfügbar bleiben oder für die verbleibende Dauer des Unterstützungszeitraums, je nachdem welcher Zeitraum länger ist. Das ist kein Dokumentationsthema, sondern eine Aussage über den Produktlebenszyklus, und sie gehört in die Kalkulation.

Welche Zugänge stehen bei der NIS2 Checkliste für Software und IT-Consulting im Fokus?

Die privilegierten, und davon gibt es hier mehr als in anderen Branchen. Nach innen sind es Repositories, Build- und Deployment-Pipelines, Secrets und Cloud-Konsolen. Nach außen sind es die Zugänge in die Systeme der Kunden, über die beraten, entwickelt und betrieben wird.

Der zweite Punkt ist der unangenehme. Ein Beratungs- oder Softwarehaus ist ein Weg in viele Netze gleichzeitig, und genau deshalb schauen regulierte Kunden dort zuerst hin. § 30 Absatz 2 BSIG nennt Zugriffskontrolle und Mehrfaktor-Authentifizierung ausdrücklich, und praktisch bedeutet das getrennte Zugänge je Kunde, namentliche Konten statt geteilter Zugänge, protokollierte Sitzungen und eine Regel, wann ein Zugang offen ist und wann nicht. Wer das belegen kann, beantwortet damit die härteste Frage jedes Vendor-Assessments.

Wem gegenüber ist bei der NIS2 Checkliste für Software und IT-Consulting zu melden?

Bis zu vier Adressaten, und sie haben verschiedene Fristen. An das BSI läuft die gestufte Kette des § 32 BSIG mit Frühwarnung binnen 24 Stunden, Meldung mit erster Bewertung binnen 72 Stunden und Abschlussbericht binnen eines Monats. An die Kunden läuft eine Unterrichtung, die sich je nach Rolle aus § 35 BSIG oder aus dem Vertrag ergibt.

Dazu kommt die Datenschutzseite: Als Auftragsverarbeiter besteht nach Artikel 33 Absatz 2 DSGVO die Pflicht, den Verantwortlichen unverzüglich zu informieren. Und ab dem 11. September 2026 kommt für Hersteller vernetzter Produkte der Meldeweg des Cyber Resilience Act hinzu, mit einer Frühwarnung binnen 24 Stunden über eine zentrale Plattform der ENISA. Ein Vorfall, vier Wege, vier Uhren. Wer diese Kette nicht vorher aufgeschrieben hat, verbringt die erste Stunde mit der Frage, wer zuerst erfährt.

Welche Punkte werden bei der NIS2 Checkliste für Software und IT-Consulting am häufigsten übersprungen?

Drei. Erstens die Komponentenübersicht mit Versionsstand. Ohne sie ist keine Software-Stückliste erzeugbar und keine Aussage möglich, ob eine bekannt gewordene Schwachstelle das eigene Produkt betrifft. Diese Liste ist das Vorprodukt von fast allem anderen.

Zweitens der Unterstützungszeitraum als Vertragsthema. Was nach fünf Jahren gilt, was mit Altversionen beim Kunden passiert und wer den Aufwand trägt, steht in den meisten Verträgen nicht. Drittens die Geräte und Zugänge der Beraterinnen und Berater. In projektgetriebenen Häusern wechseln Menschen zwischen Kunden, und das Entziehen von Rechten muss am Projektende hängen und nicht am Austritt aus dem Unternehmen.

Was steht in der Checkliste?

• Vier Situationen, in denen NIS2 für Software- und Beratungshäuser konkret wird, von der Rolle als Anbieter bis zur Haftung der Leitungsebene
• Eine Readiness in sechs Schritten, von der Betroffenheitsprüfung über Registrierung, Risiken und Maßnahmen bis zu Meldung, Leitung und Schulung
• Drei typische Stolperfallen, von der unterschätzten eigenen Betroffenheit über die ignorierte Software-Lieferkette bis zum fehlenden Meldeprozess
• Drei Quick Wins, unter anderem die Synergien mit ISO 27001 und Sicherheit als Verkaufsargument

Die Checkliste richtet sich an Geschäftsführungen, CTOs sowie Sicherheits- und Serviceverantwortliche in Software-Häusern, IT-Beratungen und bei Managed-Service-Providern. Laden Sie sie kostenfrei herunter.