NIS2 Maßnahme 5 — Sichere Beschaffung und Entwicklung
Letzte Aktualisierung: 23. März 2026
NIS2 Maßnahme 5 nach Art. 21 Abs. 2 lit. e verpflichtet Unternehmen zur Sicherheit bei Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen — einschließlich Schwachstellenmanagement. Für NIS2 sichere Entwicklung bedeutet das konkret: Maßnahme 5 von 10 verlangt nicht nur sichere Softwareentwicklung, sondern auch belastbare Einkaufsprozesse, Patch-Management und den kontrollierten Umgang mit Sicherheitslücken über den gesamten Lebenszyklus von IT-Systemen.
Die wichtigste Konsequenz lautet: Sicherheit beginnt unter NIS2 nicht erst beim Penetrationstest kurz vor Go-live, sondern schon bei Ausschreibung, Lieferantenauswahl, Architektur, Code-Review, Update-Prozess und Support-Ende. Wer den regulatorischen Gesamtüberblick sucht, sollte ergänzend NIS2 Anforderungen nach Artikel 21 Maßnahmen, die NIS2 Checkliste, den NIS2 Implementierung Fahrplan, den Grundlagenartikel Was ist die NIS2-Richtlinie? und die Einordnung NIS2 Betroffenheit prüfen lesen.
NIS2 Maßnahme 5 — Sichere Beschaffung, Entwicklung und Wartung
Art. 21 Abs. 2 lit. e der Richtlinie (EU) 2022/2555 verlangt Sicherheitsmaßnahmen für die Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen. Diese Formulierung ist bewusst weit. Sie erfasst nicht nur Unternehmen, die selbst Software bauen, sondern auch Organisationen, die Standardsoftware einkaufen, SaaS-Dienste nutzen, externe Entwickler steuern oder OT- und IT-Systeme durch Dritte warten lassen.
Für die Praxis ist Maßnahme 5 deshalb eine Lebenszykluspflicht. Sicherheit muss vor dem Einkauf beginnen, im Entwicklungsprozess überprüfbar sein und während Wartung, Patch-Management und End-of-Life fortgeführt werden. Unternehmen müssen zeigen können, dass sie nicht zufällig sichere Systeme betreiben, sondern sichere Entscheidungen systematisch vorbereiten, dokumentieren und überwachen.
Gerade im Mittelstand wird diese Pflicht oft zu eng als Entwickler-Thema verstanden. Das greift zu kurz. Wenn ein Unternehmen eine unsichere SaaS-Lösung beschafft, auf vertragliche Meldepflichten verzichtet, keine Update-Zusagen prüft oder End-of-Life-Warnungen ignoriert, verletzt es den Schutzzweck der Maßnahme ebenso wie ein Haus mit unsicherem Eigen-Code. NIS2 betrachtet Sicherheit hier als Governance-Aufgabe zwischen Einkauf, IT, Informationssicherheit, Fachbereich und Geschäftsleitung.
Hinzu kommt der Zusammenhang mit Schwachstellenmanagement. Art. 21 Abs. 2 lit. e nennt Schwachstellen ausdrücklich, und Art. 12 NIS2 verweist auf koordinierte Offenlegung von Schwachstellen. Unternehmen brauchen deshalb einen belastbaren Prozess, um Sicherheitslücken zu erkennen, zu priorisieren, an Lieferanten weiterzugeben, Updates zu bewerten und Risiken bis zur Behebung kontrolliert zu überbrücken. Wer nur auf Ad-hoc-Patches reagiert, erfüllt die Maßnahme regelmäßig nicht.
Die folgende Tabelle verdichtet die Kernanforderungen nach Bereich:
| Bereich | Was NIS2 praktisch verlangt | Typische Nachweise |
|---|---|---|
| Beschaffung | Sicherheitsanforderungen vor Vertragsschluss definieren, Lieferanten bewerten, Wartungs- und Updatepflichten regeln | Ausschreibungskriterien, Due-Diligence, Sicherheitsanhang, Lieferantenbewertung |
| Entwicklung | Secure-by-Design, sichere Standards, Prüfprozesse und Freigaben in der Softwareentwicklung | SDLC, Coding-Guidelines, Code Reviews, Testprotokolle, Scan-Berichte |
| Wartung | Updates, Patches, Konfigurationskontrolle, Support-Zusagen und End-of-Life steuern | Patch-Prozess, Wartungsplan, Change-Protokolle, EOL-Register |
| Schwachstellenmanagement | Lücken erfassen, priorisieren, beheben und offenlegen | CVE-Monitoring, Ticketing, Priorisierung, Meldeprozess, Retest-Nachweise |
Die Management-Frage lautet damit nicht „Haben wir irgendwo Sicherheit eingebaut?“, sondern „Können wir für jede eingekaufte, entwickelte oder gewartete Komponente nachweisen, wie Sicherheitsrisiken gesteuert werden?“ Genau daran entscheidet sich die Umsetzbarkeit von Maßnahme 5.
Was Art. 21 Abs. 2 lit. e konkret fordert
Art. 21 Abs. 2 lit. e fordert wortlautnah „security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure“. Daraus ergeben sich drei Pflichtbereiche, die Unternehmen separat betrachten sollten: Beschaffung, Entwicklung und Wartung. Die Vorschrift ist knapp, aber gerade deshalb weit auszulegen, weil sie nicht einzelne Tools, sondern ganze Sicherheitsprozesse im Lebenszyklus adressiert.
Der erste Bereich ist die Beschaffung. Beschaffung bedeutet unter NIS2 nicht nur Einkauf im kaufmännischen Sinn, sondern die sicherheitsbezogene Auswahl, Bewertung und Beauftragung von Produkten, Diensten und Dienstleistern. Wer Netz- und Informationssysteme einkauft oder von Dritten betreiben lässt, muss vorab prüfen, ob Sicherheitsanforderungen, Update-Fähigkeit, Support-Zusagen, Rollenmodelle, Protokollierung, Schnittstellen und Abhängigkeiten tragfähig sind.
Der zweite Bereich ist die Entwicklung. Entwicklung betrifft Eigenentwicklungen ebenso wie beauftragte Individualsoftware, Integrationen, Konfigurationen mit erheblicher Logik und technische Änderungen, die Sicherheitsauswirkungen haben. Maßgeblich ist, ob Sicherheit planmäßig in den Entwicklungsprozess eingebettet ist. Das umfasst Architekturentscheidungen, sichere Programmierstandards, Tests, Freigaben und die kontrollierte Behebung erkannter Schwachstellen.
Der dritte Bereich ist die Wartung. Wartung meint mehr als gelegentliche Updates. NIS2 verlangt, dass Systeme auch nach Inbetriebnahme sicher bleiben. Dazu gehören Patch-Prozesse, sichere Konfigurationen, Change Management, Support- und End-of-Life-Überwachung, Notfall-Updates, Rollback-Szenarien und die Frage, wie Risiken bis zur endgültigen Behebung kompensiert werden. Wartung ist damit ein fortlaufender Sicherheitsprozess, kein bloßer Betriebsservice.
Besonders wichtig ist der Zusatz „including vulnerability handling and disclosure“. Unternehmen müssen also nicht nur intern mit Schwachstellen umgehen, sondern auch einen Prozess für Meldung, Bewertung und Offenlegung haben. Art. 12 NIS2 verpflichtet Mitgliedstaaten zu Regeln für koordinierte Offenlegung von Schwachstellen. Für Unternehmen bedeutet das praktisch: gemeldete Lücken dürfen nicht informell versanden, sondern brauchen Erfassung, Priorisierung, Kommunikation und dokumentierte Reaktion.
In Deutschland wird diese Logik durch die nationale Umsetzung im BSIG konkretisiert. Dort ist die Maßnahme als Bestandteil der Mindestmaßnahmen zur Cybersicherheit aufgenommen. Für Unternehmen zählt am Ende weniger die juristische Feinformulierung als die Nachweisfrage: Können Sie zeigen, wie Sicherheitsanforderungen vor dem Einkauf entstehen, wie sichere Entwicklung organisiert ist und wie Patches, Schwachstellen und Wartungsgrenzen gesteuert werden? Wenn nicht, bleibt Art. 21 Abs. 2 lit. e eine offene Lücke.
Sichere Beschaffung — IT-Einkauf unter NIS2
Sichere Beschaffung unter NIS2 bedeutet, dass Einkauf und Fachbereich Sicherheitsrisiken nicht erst nach Vertragsunterzeichnung entdecken dürfen. Maßnahme 5 verlangt, dass Sicherheitsanforderungen bereits in Ausschreibungen, Auswahlkriterien und Vertragsunterlagen verankert werden. Wer zuerst einkauft und erst danach fragt, wie Updates, Schwachstellenmeldungen oder Administrationsrechte geregelt sind, handelt nicht NIS2-konform.
Ausschreibungen sollten deshalb immer technische und organisatorische Sicherheitsanforderungen enthalten. Dazu gehören je nach Kritikalität etwa Anforderungen an Authentisierung, Rollen- und Rechtekonzepte, Logging, Verschlüsselung, Update-Fähigkeit, Notfallzugriffe, Support-Zeiten, Datenlokation, Mandantentrennung und die Frage, ob Subunternehmer eingebunden werden. Für Standardsoftware reicht ein Preis-Leistungs-Vergleich nicht aus, wenn das Produkt kritische Prozesse trägt.
Lieferantenbewertung muss risikobasiert erfolgen. Ein Kollaborationstool ohne privilegierte Integrationen ist anders zu bewerten als ein Fernwartungsdienstleister, ein Cloud-ERP oder ein Managed Security Provider. Kritische Anbieter sollten vor Vertragsschluss nach Sicherheitsorganisation, Incident-Prozess, Patch-Politik, Penetrationstests, Entwicklungsstandards und Support-Enddaten bewertet werden. Dabei ist entscheidend, welche Folgen ein Lieferantenausfall oder eine Lieferantenschwachstelle für Ihre eigenen Systeme hätte.
Verträge sind der eigentliche Hebel. Ohne vertragliche Sicherheitsklauseln bleibt sichere Beschaffung unverbindlich. Mindestinhalte sind typischerweise Meldepflichten bei Sicherheitsvorfällen, Zusagen zu Updates und Supportfenstern, Regelungen zum Schwachstellenmanagement, Audit- und Auskunftsrechte, Anforderungen an Subunternehmer, Exit-Regeln und die Pflicht, wesentliche Änderungen an Architektur oder Hosting transparent zu machen. Gerade bei kritischen Diensten sollten Unternehmen klare Fristen für sicherheitsrelevante Patches und definierte Eskalationswege vereinbaren.
Open Source ist unter NIS2 weder verboten noch per se unsicher. Open-Source-Prüfung bedeutet aber, dass Unternehmen Abhängigkeiten, Wartungszustand, Community-Aktivität, bekannte CVEs, Lizenzlage und Komponenten-Transparenz bewerten. Wenn geschäftskritische Software auf ungewarteten Bibliotheken beruht oder keine Übersicht über verwendete Komponenten besteht, steigt das Risiko erheblich. SBOMs, Release-Historien und Security Advisories sind hier praktische Nachweise.
Die Kernregel lautet: IT-Beschaffung ist unter NIS2 ein Sicherheitskontrollpunkt. Einkauf, IT und Informationssicherheit müssen daher gemeinsam definieren, welche Mindestanforderungen für kritische Beschaffungen verbindlich sind. Unternehmen, die dafür eine standardisierte Beschaffungsrichtlinie mit Risikoklassen, Pflichtklauseln und Freigabewegen aufbauen, reduzieren nicht nur Audit-Risiken, sondern verhindern teure Folgeschäden aus falsch eingekaufter Technologie.
Secure-by-Design — Sichere Softwareentwicklung
Secure-by-Design bedeutet unter NIS2, dass Sicherheitsanforderungen von Anfang an Bestandteil des Software-Lebenszyklus sind. Art. 21 Abs. 2 lit. e verlangt keine bestimmte Methode, aber der erwartete Standard ist klar: Ein Software Development Life Cycle darf Sicherheit nicht erst als Schlusskontrolle behandeln, sondern muss Risiken in Architektur, Implementierung, Test, Deployment und Wartung systematisch adressieren.
Ein belastbarer SDLC beginnt mit Sicherheitsanforderungen und Threat Modeling. Teams sollten vor Entwicklung klären, welche Daten verarbeitet werden, welche Angriffsflächen entstehen, welche Schnittstellen vertrauenswürdig sind und welche Missbrauchsszenarien realistisch sind. Gerade bei Portalen, APIs, Admin-Funktionen und Identitätssystemen verhindert diese Vorarbeit, dass gravierende Schwächen erst im Produktivbetrieb auffallen.
Sichere Entwicklung braucht klare Coding-Standards. In Web- und API-Projekten sind die OWASP Top 10 ein sinnvoller Referenzrahmen, weil sie typische Risiken wie Broken Access Control, Injection, kryptografische Schwächen und unsichere Konfigurationen greifbar machen. NIS2 verlangt zwar nicht ausdrücklich „OWASP“, aber Unternehmen müssen nachvollziehbar darlegen können, nach welchen Sicherheitsprinzipien sie entwickeln und welche Standardrisiken sie regelmäßig prüfen.
Code Reviews und automatisierte Prüfungen sind Pflichtinstrumente, weil sie unterschiedliche Fehlerklassen abdecken. Manuelle Reviews erkennen Logikfehler, unsaubere Autorisierung oder gefährliche Designentscheidungen, während SAST- und DAST-Verfahren bekannte Muster und technische Schwächen skalierbar sichtbar machen. Für kritische Anwendungen kommen zusätzlich Dependency Scans, Secret Scans, Container-Scans und gegebenenfalls Penetrationstests hinzu. Entscheidend ist nicht die Tool-Menge, sondern der dokumentierte Prozess: Findings müssen bewertet, priorisiert und vor Freigabe oder mit akzeptierten Restrisiken behandelt werden.
Secure-by-Design umfasst auch sichere Standardkonfigurationen. Eine Anwendung kann formal sauber entwickelt sein und trotzdem unsicher betrieben werden, wenn Debug-Schnittstellen offen bleiben, Default-Passwörter bestehen, Protokollierung fehlt oder Zugriffsrechte zu weit gefasst sind. Teams sollten deshalb Sicherheits-Baselines für Deployment, Secrets, Schlüssel, Logging und Berechtigungen definieren. Gerade bei Infrastruktur als Code und Cloud-Ressourcen ist diese Betriebsnähe Teil sicherer Entwicklung.
Die praktikable Leitfrage lautet: Können Sie für eine kritische Anwendung zeigen, wie Sicherheit von der Anforderung bis zum Release geprüft wurde? Wenn Sie diese Frage mit Architekturartefakten, Review-Regeln, Scan-Berichten, Freigaben und Remediation-Nachweisen beantworten können, nähern Sie sich Art. 21 Abs. 2 lit. e. Wenn Sicherheit nur auf Zuruf geprüft wird, fehlt die notwendige Reife für NIS2 sichere Entwicklung.
Schwachstellenmanagement nach NIS2
Schwachstellenmanagement nach NIS2 ist kein reines Patch-Thema, sondern ein vollständiger Steuerungsprozess für bekannte, gemeldete und neu erkannte Sicherheitslücken. Art. 21 Abs. 2 lit. e nennt vulnerability handling ausdrücklich, und Art. 12 NIS2 verankert die koordinierte Offenlegung von Schwachstellen. Unternehmen müssen Schwachstellen daher nicht nur technisch beheben, sondern organisatorisch erfassen, bewerten, priorisieren und nachvollziehbar kommunizieren.
Der erste Baustein ist Transparenz über Assets und Abhängigkeiten. Ohne Inventar wissen Unternehmen nicht, welche Systeme, Versionen, Bibliotheken oder Dienste von einer CVE betroffen sind. Deshalb ist ein gepflegtes Asset-Register die Grundlage jedes wirksamen Schwachstellenmanagements. Dazu gehören nicht nur Server und Endpunkte, sondern auch SaaS-Dienste, Container-Images, Bibliotheken, Netzwerkkomponenten und OT-nahe Systeme, soweit sie für den Betrieb relevant sind.
Der zweite Baustein ist CVE-Monitoring. Unternehmen sollten definieren, welche Quellen sie auswerten, wie Hinweise eingehen und wer die Relevanz bewertet. Für kritische Hersteller, Plattformen und Open-Source-Komponenten braucht es feste Verantwortlichkeiten. Eine Schwachstelle wird nicht dadurch beherrscht, dass ein Advisory irgendwo veröffentlicht wurde. Beherrscht ist sie erst, wenn klar ist, ob eigene Systeme betroffen sind, welches Risiko besteht und welche Frist für Gegenmaßnahmen gilt.
Der dritte Baustein ist Vulnerability Disclosure. Wenn interne Teams, Kunden, Sicherheitsforscher oder Lieferanten Schwachstellen melden, braucht es einen geregelten Empfangs- und Bewertungsprozess. Mindestens erforderlich sind ein definierter Meldekanal, Zuständigkeiten für Triage, eine Bewertung nach Kritikalität, Rückmeldungen an den Melder und eine dokumentierte Entscheidung über Behebung, Workaround oder Risikobehandlung. Gerade hier ist Art. 12 NIS2 relevant, weil die europäische Regelung koordinierte Offenlegung fördern will statt informeller Zufallsprozesse.
Der vierte Baustein ist Priorisierung und Behebung. Kritische Lücken in exponierten Systemen oder privilegierten Komponenten müssen schneller behandelt werden als theoretische Niedrigrisiken ohne reale Ausnutzbarkeit. Unternehmen sollten deshalb nicht nur CVSS-Werte übernehmen, sondern Kontextfaktoren wie Erreichbarkeit, Datenbezug, Rechteumfang, bestehende Kompensationsmaßnahmen und Geschäftsrelevanz einbeziehen. Gute Teams definieren dafür Reaktionszeiten je nach Kritikalität und prüfen nach dem Patch, ob die Schwachstelle tatsächlich geschlossen wurde.
Die Kernbotschaft lautet: NIS2 erwartet bei Schwachstellenmanagement einen geschlossenen Regelkreis aus Erkennen, Bewerten, Beheben und Nachweisen. Wer Sicherheitslücken nur sporadisch scannt oder Patches ohne Nachverfolgung verteilt, erfüllt die aufsichtsrelevante Erwartung regelmäßig nicht. Erst die Verbindung aus Inventar, Monitoring, Disclosure und dokumentierter Remediation macht Schwachstellenmanagement NIS2-tauglich.
Wartung und Patch-Management
Wartung und Patch-Management sind unter NIS2 keine technische Nebenroutine, sondern der Beweis dafür, dass Sicherheit auch nach Go-live erhalten bleibt. Maßnahme 5 verlangt, dass Systeme über ihren gesamten Nutzungszeitraum kontrolliert aktualisiert, sicher konfiguriert und bei Änderungen nachvollziehbar gesteuert werden. Ein Produkt, das sicher beschafft oder entwickelt wurde, kann durch schlechte Wartung trotzdem zum Compliance-Risiko werden.
Updates müssen deshalb geplant, priorisiert und dokumentiert sein. Unternehmen brauchen definierte Wartungsfenster, Kriterien für Notfall-Patches, Test- und Freigabeschritte sowie Regeln für Rollback und Kommunikation. Besonders kritisch sind Internet-exponierte Systeme, Identitätsdienste, Fernwartungslösungen, VPN-Komponenten, E-Mail-Infrastrukturen und geschäftskritische SaaS-Anbindungen. Hier dürfen Patches nicht im allgemeinen Backlog untergehen.
End-of-Life ist ein unterschätztes NIS2-Risiko. Wenn Software oder Hardware keine Sicherheitsupdates mehr erhält, entsteht ein strukturelles Restrisiko, das dokumentiert und behandelt werden muss. Unternehmen sollten deshalb ein Register für Support-Enden führen, frühzeitig Ersatz planen und Übergangsmaßnahmen festlegen. Wer bekannte EOL-Systeme ohne Entscheidungsdokumentation weiterbetreibt, kann schwer begründen, warum die Wartungspflichten aus Art. 21 Abs. 2 lit. e erfüllt sein sollen.
Konfiguration und Change Management gehören zwingend dazu. Jeder Patch und jede Wartungsmaßnahme kann Seiteneffekte auf Verfügbarkeit, Integrationen und Sicherheitskontrollen haben. Deshalb braucht es nachvollziehbare Freigaben, Testnachweise und Verantwortlichkeiten. Gute Wartung ist unter NIS2 nicht „möglichst schnell irgendetwas installieren“, sondern ein kontrollierter Prozess, der Risiko reduziert, ohne den Betrieb unkoordiniert zu gefährden.
Praxisleitfaden für KMU
KMU können NIS2 Maßnahme 5 pragmatisch umsetzen, wenn sie nicht mit Einzellösungen starten, sondern mit fünf klaren Bausteinen. Der erste Schritt ist ein Inventar aller kritischen Systeme, Anwendungen, Cloud-Dienste und wichtigen Softwarekomponenten. Ohne diese Übersicht lassen sich weder Beschaffung noch Schwachstellen noch Patches belastbar steuern.
Der zweite Schritt ist eine Beschaffungsrichtlinie für kritische IT. Diese Richtlinie sollte Mindestanforderungen an Sicherheitsprüfung, Vertragsklauseln, Update-Zusagen, Support-Enden und Lieferantentransparenz definieren. Der dritte Schritt ist ein Patch-Prozess mit Verantwortlichkeiten, Kritikalitätsklassen, Fristen und Nachweisdokumentation. Selbst ein schlanker Prozess in Ticketform ist besser als ungeplante Einzelreaktionen.
Der vierte Schritt ist regelmäßiges Scanning und CVE-Monitoring. KMU brauchen kein überdimensioniertes SOC, aber sie brauchen feste Routinen zur Erkennung von Schwachstellen in Servern, Endpunkten, Bibliotheken und relevanten Cloud-Komponenten. Der fünfte Schritt ist die Verpflichtung kritischer Lieferanten. Wer Software einkauft oder entwickeln lässt, sollte Sicherheits- und Meldepflichten vertraglich absichern statt auf Kulanz zu hoffen.
Praktisch sieht ein 90-Tage-Startprogramm so aus:
- Inventar für kritische Systeme, Anwendungen und Lieferanten anlegen.
- Beschaffungscheckliste mit Pflichtfragen und Vertragsklauseln einführen.
- Patch- und EOL-Register aufbauen.
- Monatliches Schwachstellen-Scanning und CVE-Review fest terminieren.
- Kritische Lieferanten schriftlich zu Incident-Meldung, Updates und Support verpflichten.
Die wichtigste Entscheidung ist, Maßnahme 5 nicht als reines Entwickler-Thema zu delegieren. Einkauf, IT, Betrieb, Informationssicherheit und Geschäftsleitung müssen denselben Mindeststandard kennen. Wenn Sie dafür einen schnellen, gemeinsamen Einstieg suchen, ist der direkte nächste Schritt: Jetzt NIS2-Schulung starten.
FAQ (Schema-relevant)
Was fordert NIS2 Maßnahme 5 konkret?
NIS2 Maßnahme 5 fordert nach Art. 21 Abs. 2 lit. e Sicherheitsmaßnahmen für Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen. Praktisch gehören dazu sichere Einkaufsprozesse, Secure-by-Design in der Entwicklung, geregeltes Schwachstellenmanagement, Patch-Prozesse, End-of-Life-Steuerung und dokumentierte Wartungsmaßnahmen.
Muss ich als Unternehmen sichere Softwareentwicklung nachweisen?
Ja, wenn Ihr Unternehmen Software selbst entwickelt oder entwickeln lässt. Nachweisbar sollten mindestens Sicherheitsanforderungen, Code Reviews, Testverfahren, Freigaben und die Behandlung erkannter Schwachstellen sein. NIS2 verlangt keinen bestimmten Tool-Stack, aber einen belastbaren, dokumentierten Prozess.
Wie setze ich Schwachstellenmanagement nach NIS2 um?
Setzen Sie Schwachstellenmanagement als festen Prozess auf: Asset-Inventar, Meldekanal, CVE-Monitoring, Risikobewertung, Priorisierung, Patch- oder Workaround-Entscheidung, Retest und Dokumentation. Wichtig ist außerdem, gemeldete Lücken strukturiert zu behandeln und nicht informell im Tagesgeschäft untergehen zu lassen.
Welche Anforderungen stellt NIS2 an IT-Beschaffung?
NIS2 verlangt, dass Sicherheit schon im Einkauf berücksichtigt wird. Unternehmen sollten Lieferanten risikobasiert bewerten, Sicherheitsanforderungen in Ausschreibungen aufnehmen, Support- und Updatepflichten prüfen, Audit- und Meldeklauseln vertraglich festlegen und kritische Open-Source- oder Drittkomponenten transparent machen.
Gilt NIS2 Maßnahme 5 auch wenn ich keine eigene Software entwickle?
Ja. Die Maßnahme betrifft ausdrücklich auch Beschaffung und Wartung. Wer Standardsoftware, SaaS oder Managed Services nutzt, muss trotzdem sicherstellen, dass Produkte sicher ausgewählt, gepflegt, gepatcht und bei Schwachstellen oder End-of-Life kontrolliert behandelt werden.
Was ist Secure by Design im Kontext von NIS2?
Secure by Design bedeutet, dass Sicherheit von Beginn an Teil des Entwicklungs- und Änderungsprozesses ist. Dazu gehören sichere Architekturentscheidungen, Threat Modeling, Coding-Standards, Tests gegen typische Risiken, sichere Standardkonfigurationen und die schnelle Behandlung entdeckter Schwachstellen.