NIS2 Artikel 21(2)(e): Sichere Entwicklung und Schwachstellenbehandlung für MSPs

Eine Logging-Bibliothek, die Ihr Kunde nie bewusst gewählt, nie absichtlich installiert hat und aus dem Kopf nicht benennen kann, veröffentlicht an einem Freitagnachmittag eine kritische CVE. Sie steckt drei Ebenen tief in einem Monitoring-Agenten, den Sie vor achtzehn Monaten für ihn ausgerollt haben. Die Uhr, die zählt, ist nicht die im Advisory des Herstellers — es ist die Uhr, die ein Prüfer startet, wenn er fragt, wie schnell Sie es wussten, wie schnell Sie handelten und wo der Nachweis ist.

Genau dieses Szenario soll NIS2 Artikel 21(2)(e) verhindern. Es ist die Maßnahme, die die meisten Berater überspringen, weil sie nach einem Entwicklerproblem klingt. Ist sie nicht. Sie ist ein Lieferketten- und Wartungsproblem, und für MSPs eine der am schwersten nachweisbaren Maßnahmen.

Artikel 21(2)(e) umfasst alles, was Sie bauen, kaufen und warten

Die zehn Risikomanagementmaßnahmen in Artikel 21(2) sind das Rückgrat der NIS2-Compliance. Die meiste Aufmerksamkeit gilt den sichtbaren — MFA, Backups, Vorfallmeldung. Maßnahme (e) ist leiser und breiter: "Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen."

Lesen Sie es langsam. Drei Verben — Erwerb, Entwicklung, Wartung — plus eine dauerhafte Pflicht, Schwachstellen zu behandeln und offenzulegen. Sie gilt, ob Sie Code schreiben, eine Plattform weiterverkaufen oder nur die Software eines anderen gepatcht halten. Es gibt keine Ausnahme für "wir entwickeln nichts." Wenn Sie die Systeme eines Kunden warten, gehört Ihnen die Wartungshälfte dieser Maßnahme.

Artikel 21 — 10 NIS2 Cybersicherheitsmaßnahmen
🛡️
Artikel 21
10 Cybersicherheitsmaßnahmen
📊
Governance & Strategie
1Risikoanalyse & Informationssicherheitsrichtlinien
6Bewertung der Wirksamkeit von Sicherheitsmaßnahmen
🚨
Vorfälle & Kontinuität
2Vorfallsbehandlung & Meldung
3Geschäftskontinuität & Notfallwiederherstellung
🔗
Lieferkette & Systeme
4Sicherheit der Lieferkette
5Sicherheit bei der Entwicklung von Netz- und Informationssystemen
🔐
Technische Kontrollen
8Kryptografie & Verschlüsselung
10Multi-Faktor-Authentifizierung & sichere Kommunikation
👥
Personal & Ressourcen
7Cyber-Hygiene & Schulung
9Personalsicherheit & Zugangskontrolle

Die vollständige Zuordnung, wie (e) mit den anderen neun Maßnahmen zusammenhängt, finden Sie in unserer Übersicht aller zehn Artikel-21-Maßnahmen.

Was "sicherer Erwerb, Entwicklung und Wartung" in der Praxis bedeutet

Zerlegen Sie die Maßnahme in die drei Dinge, die sie tatsächlich verlangt.

Erwerb bedeutet, dass Sie Software und Lieferanten mit Sicherheit als Auswahlkriterium wählen, nicht als Nachgedanken. Das heißt dokumentierte Lieferantenbewertung: Folgt der Lieferant sicheren Entwicklungspraktiken, veröffentlicht er Advisories, verpflichtet er sich, Schwachstellen in seinem Produkt offenzulegen? Ein Einzeiler "wir nutzen seriöse Lieferanten" überlebt kein Audit.

Entwicklung bedeutet, dass alles, was Sie bauen — ein Kundenportal, ein Automatisierungsskript, eine individuelle Integration — einen sicheren Lebenszyklus durchläuft. Sichere Codierstandards, Code-Review, Sicherheitstests vor der Bereitstellung und ein Prozess für Schwachstellen, die nach dem Go-live gefunden werden. Sie brauchen kein 40-seitiges SDLC-Dokument. Sie brauchen einen wiederholbaren Prozess, den Sie zeigen können.

Wartung ist, wo die meisten MSPs leben. Sie bedeutet Patchen, Änderungsmanagement und eine akkurate Bestandsaufnahme, was wo eingesetzt ist. Sie können nicht patchen, was Sie nicht sehen, und Sie können ohne Aufzeichnungen nicht nachweisen, dass Sie gepatcht haben.

Bauen Sie, oder warten Sie nur? Die Controls unterscheiden sich

Die Maßnahme gilt für alle im Anwendungsbereich, aber das Gewicht verschiebt sich je nachdem, was Sie tun. Nutzen Sie die Entscheidungslogik unten, um herauszufinden, welche Controls für Ihren Betrieb das größte Auditrisiko tragen.

Gilt NIS2 für Ihre Organisation?
1
Ist Ihre Organisation in einem wesentlichen oder wichtigen Sektor tätig (Energie, Verkehr, Gesundheit, digitale Infrastruktur usw.)?
Ja▼
Nein▼
2
Beschäftigt Ihre Organisation 50 oder mehr Mitarbeiter oder erzielt einen Jahresumsatz von mehr als 10 Millionen Euro?
✗
NIS2 gilt nicht unmittelbar für Ihre Organisation.
Ja▼
Nein▼
✓
NIS2 gilt für Ihre Organisation als wesentliche oder wichtige Einrichtung.
3
Ist Ihre Organisation ein Anbieter kritischer Infrastruktur oder ein qualifizierter Vertrauensdiensteanbieter?
Ja▼
!
NIS2 könnte für Ihre Organisation gelten — holen Sie rechtlichen Rat ein, um Ihren Status zu bestätigen.
1
Ist Ihre Organisation in einem wesentlichen oder wichtigen Sektor tätig (Energie, Verkehr, Gesundheit, digitale Infrastruktur usw.)?
Ja ↓Nein →
2
Beschäftigt Ihre Organisation 50 oder mehr Mitarbeiter oder erzielt einen Jahresumsatz von mehr als 10 Millionen Euro?
Ja ↓Nein →
3
Ist Ihre Organisation ein Anbieter kritischer Infrastruktur oder ein qualifizierter Vertrauensdiensteanbieter?
Ja ↓Nein →
✗
NIS2 gilt nicht unmittelbar für Ihre Organisation.
✓
NIS2 gilt für Ihre Organisation als wesentliche oder wichtige Einrichtung.
!
NIS2 könnte für Ihre Organisation gelten — holen Sie rechtlichen Rat ein, um Ihren Status zu bestätigen.
Gilt
Gilt möglicherweise
Gilt nicht

Wenn Sie nur Drittanbietersoftware warten, liegt Ihr Risiko in der Genauigkeit des Inventars, den Patch-SLAs und den Änderungsaufzeichnungen. Entwickeln Sie etwas Kundenorientiertes, ergänzen Sie sicheres Codieren, Code-Review und Pre-Release-Tests. Verkaufen Sie Plattformen anderer Anbieter weiter oder bündeln sie, werden Ihre Beschaffungscontrols — Lieferantenprüfung und Offenlegungsklauseln — das Erste, was ein Prüfer untersucht. Erfassen Sie Ihre Dienste ehrlich, bevor Sie das Control-Set aufbauen.

Schwachstellenbehandlung: Eingang, Triage und Patch-SLAs

Schwachstellenbehandlung ist eine Schleife, kein Projekt. Sie hat drei bewegliche Teile.

Eingang ist, wie Schwachstellen Sie erreichen — Hersteller-Advisories, Ihr eigenes Scanning, Pentests Dritter und ein Kanal, über den Außenstehende einen Fehler in etwas melden können, das Sie betreiben. Fehlt dieser letzte Posteingang, fehlt Ihnen ein Control, das die Richtlinie ausdrücklich nennt.

Triage ist, wie Sie ordnen, was eingeht. Schweregrad plus Exposition plus Ausnutzbarkeit, jedes Mal gleich bewertet, sodass zwei Ingenieure zum selben Ergebnis kommen.

Behebung ist der Patch, an eine Service-Level-Uhr gebunden. NIS2 schreibt keine Patchfristen vor, daher hat sich am Markt ein De-facto-Standard etabliert, den Abnehmer nun in Verträge schreiben: kritisch innerhalb von 24–48 Stunden, hoch innerhalb von 7 Tagen, mittel innerhalb von 30 Tagen, niedrig innerhalb von 90 — mit einem dokumentierten Ausnahmeprozess für Fälle, in denen Sie wirklich nicht rechtzeitig patchen können. Dieser Ausnahmeprozess zählt so viel wie die SLA. Ein Prüfer sucht keine perfekte Akte. Er sucht eine verteidigbare.

Der Haken für MSPs: Sie müssen diese Aufzeichnungen pro Kunde produzieren, zum Auditzeitpunkt, auf Anfrage. Scanning, das nur in einem Dashboard lebt, ist kein Nachweis. Eine datierte, exportierbare Spur schon.

Koordinierte Offenlegung von Schwachstellen und die EUVD

Die eigenen Schwachstellen zu behandeln ist die Hälfte der Maßnahme. Die andere Hälfte ist Offenlegung — und NIS2 hat dafür einen formalen Kanal gebaut.

Nach Artikel 12 benennt jeder Mitgliedstaat ein CSIRT als Koordinator für ein nationales Programm zur koordinierten Offenlegung von Schwachstellen (CVD). Dieses CSIRT wirkt als vertrauenswürdiger Vermittler zwischen demjenigen, der einen Fehler meldet, und dem Hersteller, dessen Produkt ihn enthält. Es kontaktiert die betroffenen Parteien, unterstützt den Meldenden und verhandelt Offenlegungsfristen — auch in den kniffligen Fällen, in denen eine Schwachstelle Produkte in mehreren Ländern gleichzeitig trifft.

Gespeist wird all das von der European Vulnerability Database (EUVD), betrieben von ENISA, die seit Januar 2024 als offizielle CVE Numbering Authority ein Schwachstellenregister führt. Für einen MSP ist die EUVD eine zweite Quelle der Wahrheit neben den Hersteller-Advisories — und zu wissen, wie man damit arbeitet, gehört jetzt dazu. Die praktische Seite behandeln wir in unserem EUVD-Leitfaden für MSPs.

Die praktische Lehre: Sie brauchen einen veröffentlichten Weg, über den jemand eine Schwachstelle in einem Produkt oder Dienst melden kann, den Sie betreiben, und eine Entscheidung, wie Sie am nationalen CVD-Prozess teilnehmen. Beides ist auditierbar. Keines ist optional, wenn Sie im Anwendungsbereich sind.

Wenn der Fehler eines Lieferanten zur Haftung Ihres Kunden wird

Hier hört Maßnahme (e) auf, abstrakt zu sein. Eine Schwachstelle im Produkt eines Lieferanten bleibt nicht eingekapselt. Sie kaskadiert — vom Lieferanten zu Ihnen, zu Ihrem Kunden, zu dessen Kunden — und die Lieferkettenpflichten von NIS2 (Maßnahme (d)) bedeuten, dass die Haftung mitreist.

NIS2-Sanktionseskalation — Jenseits der Geldbuße
!
Auslöser
Non-Compliance erkannt oder Vorfall tritt ein
Eine Aufsichtsbehörde identifiziert eine Compliance-Lücke oder eine Organisation erfüllt die NIS2-Anforderungen nicht
Behörden können verhängen
▼
Nicht-finanzielle Sanktionen
1
Anordnungen mit bindenden Fristen
2
Verpflichtende Sicherheitsaudits auf eigene Kosten
3
Öffentliche Bekanntmachung von Verstößen
4
Bindende Anweisungen zu spezifischen Sicherheitsmaßnahmen
Eskaliert zu
▼
Betriebliche und persönliche Konsequenzen
1
Aussetzung von Zertifizierungen oder Betriebsgenehmigungen
2
Vorübergehendes Verbot von Leitungsfunktionen für Personen
3
Öffentliche Benennung verantwortlicher natürlicher Personen
Auslöser
Nicht-finanziell
Betrieblich / persönlich

Wenn eine von Ihnen ausgerollte Komponente einen ungepatchten kritischen Fehler trägt und ein Kunde dadurch kompromittiert wird, ist "der Lieferant hätte es uns sagen müssen" keine Verteidigung. Die Richtlinie erwartet, dass Sie diesen Lieferanten bewertet, Offenlegung vertraglich vereinbart und einen Prozess hatten, um zu handeln, als das Advisory kam. Deshalb sind Beschaffung und Schwachstellenbehandlung eine Maßnahme und nicht zwei — die Schwäche kommt über das herein, was Sie gekauft haben, und wird über das gemanagt, was Sie danach tun. Unsere Übersicht zur Lieferkettensicherheit behandelt die vertragliche Seite.

Der Nachweis, nach dem ein Prüfer wirklich fragt

Maßnahme (e) wird an Papierspuren gemessen, nicht an Absichten. Halten Sie diese bereit, pro Kunde, wo relevant:

Ein aktuelles Software- und Lieferanteninventar, keine Tabelle vom letzten Jahr. Lieferantenbewertungen, die zeigen, dass Sicherheit ein Auswahlkriterium war. Eine Patch-Richtlinie mit schweregradbasierten SLAs, plus die Logs, die belegen, dass Sie sie eingehalten haben — und die Ausnahmeaufzeichnungen, wo nicht. Änderungsmanagement, das jede Änderung an eine Freigabe bindet. Ein Eingangs- und Offenlegungskanal für Schwachstellen, der existiert und überwacht wird. Und, falls Sie etwas entwickeln, sichere SDLC-Notizen: Codierstandards, Review-Nachweise, Ergebnisse von Pre-Release-Tests.

Nichts davon ist exotisch. Alles davon ist der Unterschied zwischen einem bestandenen Audit und der Erklärung, nach einem Vorfall, warum die Aufzeichnungen fehlen. Maßnahme (f) — zu bewerten, ob Ihre Controls tatsächlich funktionieren — sitzt direkt auf dieser; siehe unseren Audit-Loop-Leitfaden dazu, wie die beiden zusammenhängen.

Beginnen Sie mit dem, was Sie sehen können

Die meisten MSPs erledigen bereits 60% dieser Maßnahme — sie patchen, sie verfolgen Änderungen, sie wählen anständige Lieferanten. Die Lücke liegt fast immer im Nachweis und im Offenlegungskanal, nicht in der zugrundeliegenden Arbeit. Der schnellste Weg, Ihre spezifischen Lücken zu finden, ist, Ihre Wartungs- und Beschaffungscontrols durch die Linse von Artikel 21(2)(e) zu betrachten und zu markieren, was Sie einem Prüfer heute übergeben könnten, versus was Sie mühsam zusammensuchen müssten.

Wenn Sie diese Lücke für sich kartieren lassen möchten, führen Sie einen kostenlosen NIS2 Quick Scan durch — er zeigt pro Maßnahme genau, wo Ihre Haltung zu sicherer Entwicklung und Schwachstellenbehandlung im Vergleich zur Richtlinie steht.

Maßnahme (e) ist nicht der auffälligste Teil von NIS2. Sie ist der Teil, der am ehesten dünn ausfällt, wenn ein Prüfer daran zieht, gerade weil sie nach der Arbeit eines anderen aussieht. Für einen MSP ist sie Ihre.