NIS2 für Softwareentwicklung: Was Entwicklungsdienstleister nachweisen sollten

Ein Kunde fragt nach Ihrem Schwachstellenmanagement. Oder nach einer Liste, wer Zugriff auf den Produktionsserver hat. Entwickeln oder warten Sie Software für Unternehmen, die unter NIS2 fallen? Solche Mails kennen Sie dann inzwischen. NIS2 Softwareentwicklung ist für viele kleine Teams kein abstraktes Thema mehr. Es ist eine konkrete Anfrage im Postfach, oft verbunden mit einer Frist.

Die gute Nachricht: Die Anforderungen lassen sich mit vertretbarem Aufwand erfüllen. Die schlechte Nachricht: Wer gar nichts dokumentiert, verliert am Ende den Auftrag. Nicht die Diskussion.

Warum NIS2 auch kleine Entwicklungsteams betrifft

NIS2 ist die EU-Richtlinie für Netz- und Informationssicherheit. Sie verpflichtet Unternehmen aus wichtigen Sektoren zu Mindeststandards bei der Cybersicherheit. Dazu zählen zum Beispiel Energie, Gesundheit, Verkehr und digitale Infrastruktur. Deutschland setzt die Richtlinie national um. Die Zahl der betroffenen Unternehmen ist größer, als viele erwarten.

Das Entscheidende dabei: NIS2-pflichtige Unternehmen müssen auch ihre Lieferkette absichern. Dazu gehört jeder Dienstleister, der Software entwickelt, pflegt oder hostet. Wenn Ihr Kunde unter NIS2 fällt, prüft er zunehmend auch Sie. Nicht aus Misstrauen. Sondern weil er selbst nachweisen muss, dass er seine Zulieferer kennt.

Für ein kleines Entwicklungsteam fühlt sich das oft nach Bürokratie für Konzerne an. Ist es aber nicht. Die Anforderungen sind im Kern das, was gute Softwareentwicklung ohnehin tun sollte. Wissen, wer Zugriff hat. Wissen, welche Lücken offen sind. Und das belegen können.

Was Kunden konkret von Ihnen verlangen

Die Anfragen sind meist weniger kompliziert, als der Name NIS2 vermuten lässt. In der Praxis tauchen vor allem drei Themen auf.

Sichere Entwicklung: Kunden wollen wissen, wie Code entsteht, getestet und freigegeben wird. Gibt es einen Review-Prozess? Wer darf Code in die Produktion bringen?

Schwachstellenmanagement: Wie erfahren Sie von neuen Sicherheitslücken in den eingesetzten Bibliotheken? Wie schnell reagieren Sie darauf?

Zugriffsrechte: Wer hat Zugang zu Servern, Datenbanken und Deployment-Werkzeugen? Wird dieser Zugang regelmäßig überprüft?

Das sind keine neuen Erfindungen. Es sind Fragen, die ein erfahrener Entwickler sich ohnehin stellen sollte. Neu ist nur, dass Kunden jetzt eine schriftliche Antwort erwarten. Nicht nur ein gutes Gefühl.

Oft kommt die Anfrage als Fragebogen mit zwanzig oder dreißig Punkten. Vieles davon betrifft Prozesse, nicht Technik. Wer schon einmal mit einem solchen Fragebogen gesessen hat, weiß: Die schwierigsten Fragen sind selten die technischen. Es sind die Fragen, bei denen niemand im Team eine klare Antwort parat hat.

Was passiert, wenn Sie keine Antwort liefern können

Hier wird es für viele kleine Dienstleister unangenehm. Ein NIS2-pflichtiges Unternehmen muss seine Lieferkette prüfen. Einen Dienstleister ohne Nachweise kann es sich auf Dauer nicht leisten. Nicht weil er Ihnen nicht vertraut. Sondern weil er selbst in der Prüfung steht.

Die Konsequenz ist selten eine Abmahnung. Sie ist unauffälliger. Der nächste Vertrag geht an einen Dienstleister, der die Fragen im Angebot schon beantwortet hat. Oder ein bestehender Kunde verlangt plötzlich einen Fragebogen. Können Sie ihn nicht ausfüllen, sucht er sich einen Partner, der das kann.

Das passiert zuerst dort, wo größere Auftraggeber genauer hinschauen. Einkaufsabteilungen prüfen inzwischen standardmäßig, wie kleine Teams Softwareentwicklung organisieren. Das geschieht meist, bevor überhaupt ein Auftrag vergeben wird. Wer darauf keine Antwort hat, scheidet oft schon in dieser Runde aus. Ohne dass es jemand explizit so nennt. Der Auftrag geht einfach woanders hin, mit einer freundlichen Absage als Begründung.

Was in einem kleinen Team realistisch umsetzbar ist

Sie brauchen kein Compliance-Team. Sie brauchen auch keine zwanzig Seiten Richtlinie. Sie brauchen drei Dinge, die Sie dokumentieren und bei Bedarf vorzeigen können.

Zugriffsrechte sauber führen

Eine einfache Liste reicht aus: Wer hat Zugriff auf welches System, seit wann, und warum. Nutzen Sie, wo möglich, persönliche Zugänge statt geteilter Passwörter. Entziehen Sie Zugriff, sobald jemand das Projekt verlässt. Das klingt banal. Genau hier scheitern aber die meisten kleinen Teams, wenn ein Kunde nachfragt.

Eine saubere Versionskontrolle in Legacy-Projekten gehört ebenfalls dazu. Können Sie nachvollziehen, wer wann welche Änderung eingespielt hat? Dann ist ein großer Teil der Dokumentation bereits erledigt.

Schwachstellenmanagement einführen

Sie müssen nicht jede CVE-Datenbank manuell durchsuchen. Automatisierte Werkzeuge prüfen eingesetzte Bibliotheken auf bekannte Lücken. Für die meisten Projekte reicht das völlig aus. Wichtig ist ein fester Rhythmus. Und eine klare Antwort auf die Frage, wie schnell Sie auf eine gefundene Lücke reagieren.

Sichere Entwicklung nachvollziehbar machen

Ein kurzes Dokument reicht aus. Wie läuft ein Code-Review ab? Wer darf in die Produktion deployen? Wie werden Tests vor einem Release durchgeführt? Das muss nicht perfekt sein. Es muss ehrlich sein und zur tatsächlichen Arbeitsweise passen.

Dokumentation ohne eigene Compliance-Abteilung

Der Trick liegt nicht in mehr Papier. Er liegt in weniger, dafür richtigem Papier. Ein einseitiges Dokument pro Thema reicht meist aus. Sie geben es bei jeder Kundenanfrage aktuell heraus, und erledigen damit die meisten Anfragen sofort. Den Rest beantworten Sie aus denselben Grundlagen heraus, wenn ein Kunde einen individuellen Fragebogen schickt.

Viele Teams schieben das auf. Compliance fühlt sich nach einem Projekt an, das nie fertig wird. Tatsächlich ist der erste Durchgang der aufwendigste. Danach pflegen Sie die Dokumente nur noch mit, statt sie neu zu schreiben.

Stecken in Ihrem System bereits technische Schulden? Veraltete Abhängigkeiten etwa, oder unklare Zugriffsstrukturen. Genau das wird bei dieser Arbeit sichtbar. Das ist unangenehm. Es ist aber auch eine gute Gelegenheit, es gleich mitzuerledigen. Statt es weiter ansammeln zu lassen.

Wenn Sie selbst nicht genau wissen, wo Sie stehen

Das ist der häufigste Fall. Kein Team startet mit perfekter Dokumentation. Der sinnvolle erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Systeme gibt es? Wer hat Zugriff? Welche Abhängigkeiten laufen seit Jahren ungeprüft weiter?

Danach priorisieren Sie, was ein konkreter Kunde tatsächlich verlangt. Statt zu versuchen, alles auf einmal zu lösen.

Ein Blick von außen hilft dabei oft schneller als interne Diskussionen. Wer von außen auf ein System schaut, sieht Lücken, die im Alltag übersehen werden. Weil man sich an sie gewöhnt hat.

Das gilt besonders für Teams, die seit Jahren an derselben Anwendung arbeiten. Die alten Entscheidungen kennt irgendwann niemand mehr im Detail. Warum ein Zugang so eingerichtet wurde, warum eine Bibliothek nie aktualisiert wurde: Solche Fragen beantwortet selten jemand sofort. Genau dort setzt eine saubere Bestandsaufnahme an.

Fazit: Nachweise sind Arbeit, aber keine Wand

NIS2 Softwareentwicklung klingt nach einem Projekt für große Unternehmen mit eigener Rechtsabteilung. Für ein kleines Team ist es in Wirklichkeit eine Checkliste. Zugriffsrechte dokumentieren. Schwachstellen im Blick behalten. Entwicklungsprozesse schriftlich festhalten. Nichts davon ist neu. Es muss nur aufgeschrieben werden.

Wer jetzt anfängt, hat die Nachweise fertig, bevor der nächste Kunde danach fragt. Wer wartet, beantwortet die Fragen unter Zeitdruck. Mitten in einer Vertragsverhandlung.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Systeme an. Und sagen Ihnen ehrlich, welche Nachweise Sie schon liefern können und wo noch etwas fehlt.