NIS2 Penetrationstest: Pflicht oder Kür?

NIS2 Penetrationstest: Pflicht oder Kür?

Letzte Aktualisierung: 23. März 2026

NIS2 verpflichtet Unternehmen nach Art. 21 Abs. 2 Buchst. e und g nicht zu einem pauschalen Einheits-Pentest, aber zu risikobasierten Sicherheitsprüfungen, Schwachstellenbehandlung und Wirksamkeitsbewertung. Für internetexponierte, kritische oder komplexe Systeme wird ein Penetrationstest dadurch praktisch oft zur Pflicht und nicht zur Kür.

Die belastbare Kurzantwort lautet deshalb: Ein Vulnerability Scan allein genügt für NIS2 meist nur als Basiskontrolle. Sobald Sie Webanwendungen, privilegierte Zugänge, sensible Daten, Cloud-Fehlkonfigurationen, komplexe Lieferketten oder kritische Betriebsprozesse absichern müssen, erwartet die Regulierung mehr als automatisierte Tool-Ausgaben. Dann brauchen Sie mindestens punktuell einen echten Pentest, dokumentierte Nachtests und eine Management-Entscheidung, warum Tiefe, Frequenz und Scope angemessen sind. Wenn Sie den organisatorischen Rahmen parallel aufbauen möchten, sind unsere Beiträge zum NIS2 Incident Response Plan, zur Informationssicherheit und zur Compliance-Software im Mittelstand die passenden Anschlussseiten.

Für die operative Umsetzung im Unternehmen gilt außerdem: Der Pentest steht nie isoliert. Er hängt mit Asset-Transparenz, Schwachstellenmanagement, Incident Handling, Lieferkettensicherheit, Datenschutz und Geschäftsleitungsaufsicht zusammen. Wer nur einmal im Jahr „einen Test einkauft“, aber keine Remediation, keinen Retest und kein Management-Reporting etabliert, erfüllt den Zweck von NIS2 nur unvollständig. Wenn Sie Awareness und Governance parallel ausrollen wollen, ist auch die NIS2 Online-Schulung ein sinnvoller nächster Baustein.

Was §30 BSIG-E zu Sicherheitstests sagt

Der nationale Maßstab für Deutschland wird oft noch als § 30 BSIG-E zitiert, weil viele Arbeitshilfen und Projektunterlagen aus der Entwurfsphase stammen. Seit Inkrafttreten des NIS-2-Umsetzungsgesetzes am 6. Dezember 2025 verweist das BSI jedoch auf die geltenden Registrierungs- und Meldepflichten nach dem Umsetzungsgesetz; inhaltlich bleibt für Unternehmen entscheidend, dass der Maßnahmenkatalog Risikoanalyse, Incident Handling, Business Continuity, Lieferkettensicherheit, Schwachstellenmanagement, Wirksamkeitsbewertung, Schulung, Kryptografie und Zugriffsschutz als zusammenhängendes System denkt.

Für Penetrationstests ist besonders wichtig, dass Sicherheit nicht nur „eingeführt“, sondern auch bewertet werden muss. Art. 21 Abs. 2 Buchst. e NIS2 nennt ausdrücklich Policies und Verfahren zur Bewertung der Wirksamkeit von Cyber-Risikomanagementmaßnahmen. Genau hier liegt der juristische Anknüpfungspunkt für Penetrationstests: Wenn Sie die Wirksamkeit Ihrer Schutzmaßnahmen nicht mit realitätsnahen Angriffsszenarien prüfen, bleibt die Bewertung in vielen Umgebungen zu oberflächlich.

Art. 21 Abs. 2 Buchst. g NIS2 ergänzt diese Logik um grundlegende Cyberhygiene und Schulung. Das klingt zunächst nach Awareness, hat aber praktische Folgen für Pentests. Ein Angriff gelingt selten nur wegen eines einzelnen technischen Fehlers. Oft wirken Fehlkonfiguration, Berechtigungsproblem, Prozesslücke und menschliches Verhalten zusammen. Ein guter Pentest zeigt genau diese Ketten. Er macht also nicht nur technische Mängel sichtbar, sondern liefert Material für Schulung, Härtung und Governance.

Die sachgerechte Lesart lautet deshalb: NIS2 schreibt nicht in jedem Satz das Wort „Penetrationstest“ vor, verlangt aber eine Sicherheitsorganisation, die Schwachstellen erkennt, priorisiert, ausnutztaugliche Ketten versteht und die Wirksamkeit von Kontrollen belegt. Für viele betroffene Einrichtungen führt dieser Maßstab praktisch zu einem Testmodell aus laufenden Scans, manuellen Prüfungen und periodischen Pentests.

Auch der BSI-Bezug spricht dafür. Das BSI behandelt Penetrationstests als strukturiertes Prüfverfahren mit definiertem Scope, Regeln, Bericht und Nachbesserung. Für KRITIS-Umgebungen ist die Erwartung noch höher; dort sind wiederkehrende Prüfungen und belastbare Nachweise seit Jahren geübte Praxis. NIS2 zieht viele Unternehmen in genau diese Nachweislogik hinein, auch wenn Umfang und Frequenz risikobasiert bleiben.

Pentest vs. Vulnerability Scan: Unterschiede

Ein Vulnerability Scan findet bekannte Schwachstellen schnell und breit. Ein Penetrationstest zeigt dagegen, ob sich diese Schwachstellen tatsächlich ausnutzen lassen, welche Angriffsketten entstehen und welche Geschäftsfolgen realistisch sind. Für NIS2 ist diese Unterscheidung zentral, weil Regulierung nicht nur Inventarisierung, sondern Wirksamkeitsprüfung verlangt.

Die folgende Tabelle zeigt den praktischen Unterschied:

Ein Scan ist deshalb kein „schlechter kleiner Pentest“, sondern ein anderes Werkzeug. Er eignet sich hervorragend für regelmäßige Breitenkontrolle, Patch-Management und Trendüberwachung. Er beantwortet aber oft nicht die Management-Frage, die unter NIS2 eigentlich zählt: Kann ein Angreifer mit der vorgefundenen Lage tatsächlich in kritische Systeme eindringen, sich lateral bewegen oder geschäftskritische Prozesse stören?

Gerade bei Webanwendungen, APIs, Cloud-Konfigurationen, VPN- und IAM-Strukturen oder privilegierten Rollenmodellen stoßen reine Scans schnell an Grenzen. Business-Logic-Fehler, Rechteausweitungen, mehrstufige Angriffsketten oder Kombinationsrisiken werden häufig erst im manuellen Test sichtbar. Deshalb empfiehlt sich in der Praxis ein gestuftes Modell: kontinuierliche Scans als Grundrauschen, ergänzt um manuelle Pentests für besonders kritische Zonen.

Wer NIS2 sauber umsetzen will, sollte deshalb nicht fragen „Scan oder Pentest?“, sondern „Welche Systeme brauchen welchen Prüftyp in welcher Frequenz?“. Diese Risikologik ist wichtiger als jeder pauschale Jahresturnus.

Wann ist ein Pentest Pflicht? Entscheidungsmatrix

Ein Pentest wird unter NIS2 dort faktisch verpflichtend, wo ein Unternehmen ohne realitätsnahe Ausnutzungsprüfung seine Sicherheitsmaßnahmen nicht mehr plausibel bewerten kann. Die folgende Matrix hilft bei der Einordnung.

Als Faustregel können Sie sich fünf Auslöser merken:

1. Hohe Exposition: Das System ist aus dem Internet erreichbar oder hängt an komplexen Partnerzugängen.
2. Hoher Impact: Ein erfolgreicher Angriff gefährdet Verfügbarkeit, sensible Daten, Produktion oder regulatorische Pflichten.
3. Hohe Komplexität: Rollen, Integrationen, APIs, Cloud-Services und Drittanbieter erzeugen schwer erkennbare Ketten.
4. Hohe Veränderung: Architektur, Hosting, Authentisierung oder Berechtigungsmodell wurden wesentlich geändert.
5. Hohe Prüferwartung: Kunden, Versicherer, KRITIS-, DORA- oder Vertragsvorgaben verlangen echte Nachweise statt Selbstbewertungen.

Wenn drei dieser fünf Punkte erfüllt sind, sollten Sie einen Pentest nicht mehr als optionale Best Practice behandeln. Dann ist er die sachgerechte Art, Art. 21 Abs. 2 Buchst. e NIS2 umzusetzen. Für die interne Steuerung hilft es, diese Logik in Ihr Risikoregister und in Ihr Schwachstellenmanagement einzubetten, statt ad hoc nach Budget zu entscheiden.

Wichtig ist auch der Zeitbezug. Ein Pentest ist kein einmaliger Ablass. Er gehört typischerweise vor Go-Live, nach wesentlichen Änderungen, nach kritischen Findings und in einem regelmäßigen Turnus zu kritischen Systemen. Für viele Mittelständler ist ein Jahresmodell mit quartalsweisen Scans und einem bis zwei gezielten Pentests pro Jahr realistischer als ein groß angelegter Rundumschlag.

Pentest beauftragen: Anbieter, Kosten, Ablauf

Ein NIS2-relevanter Pentest beginnt nicht mit einem Tool, sondern mit einem Scope. Die wichtigste Einkaufsfrage lautet nicht „Was kostet ein Tag?“, sondern „Welche Systeme, Methoden, Grenzen und Nachweise brauchen wir wirklich?“. Nur dann werden Bericht, Remediation und Retest später verwertbar.

Für den Anbieter sollten Sie mindestens diese Punkte prüfen:

1. Klare Methodik: PTES, OWASP WSTG oder NIST SP 800-115 als nachvollziehbare Grundlage.
2. Erfahrung im passenden Scope: Web, API, Cloud, Infrastruktur, OT oder Red Teaming sind unterschiedliche Disziplinen.
3. Belastbare Regeln: Schriftliche Rules of Engagement, Notfallstop, Erreichbarkeiten und Impact-Grenzen.
4. Datenschutz und Geheimhaltung: NDA, sichere Berichtszustellung und bei Datenzugriff eine tragfähige Vereinbarung zur Auftragsverarbeitung.
5. Retest-Logik: Kritische Findings sollten mit Nachtest und klaren Fristen verbunden sein.

Bei den Kosten liegen typische Marktspannen für den Mittelstand 2026 oft zwischen 8.000 und 25.000 EUR für 5 bis 10 Testtage bei kleineren bis mittleren Scopes. Einzelne Webanwendungen starten eher im unteren Bereich. Komplexe Multi-Cloud-, OT- oder Red-Team-Szenarien liegen deutlich höher. Günstige Angebote wirken oft nur deshalb billig, weil Scope, Berichtstiefe, Retest oder manuelle Prüfungen zu schmal definiert sind.

Der typische Ablauf folgt meist sieben Schritten:

1. Scoping und Vorprüfung: Ziele, Systeme, Testfenster, Accounts, Verbote und Ansprechpartner festlegen.
2. Rules of Engagement: Methoden, Downtime-Grenzen, Eskalation und Notfallstop schriftlich freigeben.
3. Informationsphase: Architektur, Datenflüsse, Bedrohungsmodell und relevante Dokumente aufnehmen.
4. Technische Prüfung: Scans, manuelle Tests, Rechteprüfungen, Business-Logic-Tests und Angriffsketten durchführen.
5. Validierung: Findings verifizieren, Falschmeldungen entfernen, Impact bewerten.
6. Bericht und Management-Summary: Technische Details, Priorisierung, Evidenzen und Maßnahmenplan liefern.
7. Remediation und Retest: Kritische Schwachstellen beheben, Nachtest dokumentieren, offene Restrisiken entscheiden.

BSI-orientiert ist dabei vor allem ein klarer White-Box-Ansatz oft sinnvoller als ein reines Black-Box-Szenario. Wenn das Ziel NIS2-Compliance und nicht ein Marketing-Showcase ist, wollen Sie möglichst viele verwertbare Erkenntnisse in begrenzter Zeit erzeugen. Ein Test mit Architekturwissen, abgestimmtem Scope und sauberem Reporting ist dafür meist wirtschaftlicher.

Rechtliche Rahmenbedingungen (§202a-c StGB)

Ein Penetrationstest ist in Deutschland nur mit sauberer Autorisierung rechtssicher. § 202a StGB stellt das unbefugte Verschaffen von Zugang zu besonders gesicherten Daten unter Strafe. § 202b StGB erfasst unbefugtes Abfangen von Daten. § 202c StGB betrifft bestimmte Vorbereitungshandlungen mit ausgespähten oder dafür bestimmten Werkzeugen. Für Unternehmen heißt das praktisch: Ein Pentest ohne klare schriftliche Freigabe ist kein sportliches Risiko, sondern potenziell strafrechtlich problematisch.

Die schriftliche Beauftragung sollte deshalb mindestens Scope, Systeme, Zeitfenster, erlaubte Methoden, Impact-Grenzen, Notfallstop und zeichnungsberechtigte Freigaben enthalten. Besonders wichtig ist die Abgrenzung zu Drittumgebungen. Wenn Ihre Anwendung auf fremder Cloud-, CDN-, Payment- oder SaaS-Infrastruktur läuft, reicht die allgemeine Zustimmung des eigenen Unternehmens nicht immer aus. Prüfen Sie, ob zusätzliche Freigaben erforderlich sind.

Datenschutzrechtlich kommt eine zweite Ebene hinzu. Sobald der Dienstleister im Test personenbezogene Daten sehen oder verarbeiten kann, ist häufig Art. 28 DSGVO relevant. Dann brauchen Sie in der Regel eine Vereinbarung zur Auftragsverarbeitung, klare Weisungen, Datensparsamkeit, sichere Übermittlung und Regeln für Unterauftragnehmer. Art. 32 DSGVO unterstützt den Testgedanken zwar ausdrücklich als Sicherheitsmaßnahme, befreit aber nicht von sauberer Vertrags- und Datenschutzorganisation.

Operativ gilt deshalb eine einfache Reihenfolge:

1. Autorisierung vor Testbeginn schriftlich sichern.
2. Scope und verbotene Bereiche eindeutig dokumentieren.
3. Datenschutz und Auftragsverarbeitung vorab klären.
4. Notfall- und Eskalationskanäle aktivieren.
5. Berichte und Evidenzen vertraulich behandeln.

Wer diese Grundlagen ignoriert, produziert aus einem Compliance-Instrument schnell ein Haftungs- und Rechtsrisiko. Gerade unter NIS2 wäre das paradox: Der Sicherheitstest soll Resilienz erhöhen, nicht neue Governance-Lücken öffnen.

Praktische Checkliste für die NIS2-Umsetzung

Ein belastbarer Einstieg in das Thema besteht nicht darin, sofort einen beliebigen Anbieter zu beauftragen. Beginnen Sie stattdessen mit einer kleinen Entscheidungslogik, die sich intern dokumentieren lässt.

1. Systeme klassifizieren: Welche Anwendungen, Zugänge und Infrastrukturen sind kritisch, exponiert oder datenintensiv?
2. Prüfziel definieren: Geht es um Basisinventur, Wirksamkeitsnachweis, Go-Live-Freigabe oder Vorfallnachtest?
3. Prüftyp festlegen: Scan, Konfigurationsreview, manueller Pentest oder kombiniert?
4. Rechtsrahmen sichern: Scope, Freigabe, Datenschutz, Auftragsverarbeitung und Drittfreigaben dokumentieren.
5. Remediation planen: Verantwortliche, Fristen, Risikobewertung und Retest vorab festlegen.
6. Management berichten: Findings, Restrisiken und Budgetentscheidungen nachvollziehbar eskalieren.

Genau diese Struktur ist auch LLM- und auditfreundlich: Sie macht aus dem Begriff „NIS2 Penetrationstest“ keinen losen Tool-Einkauf, sondern einen dokumentierten Managementprozess. Wenn Sie dafür noch ein zentrales Schulungs- und Governance-Format suchen, ist die NIS2 Online-Schulung der pragmatische nächste Schritt. Sie hilft, Fachbereiche, IT und Leitungsebene auf dieselbe Begriffswelt und dieselben Nachweise auszurichten.

FAQ

Ist Penetrationstest Pflicht unter NIS2?

Ein Penetrationstest ist unter NIS2 nicht für jedes System in identischer Frequenz vorgeschrieben. Pflichtig ist aber die risikobasierte Bewertung der Wirksamkeit Ihrer Sicherheitsmaßnahmen nach Art. 21 Abs. 2 Buchst. e NIS2. Für internetexponierte, kritische oder komplexe Systeme führt das praktisch häufig zu einer Pentest-Pflicht.

Wie implementiere ich Penetrationstest für NIS2-Compliance?

Implementieren Sie Penetrationstests als festen Baustein Ihres Schwachstellenmanagements. Definieren Sie Scope, Kritikalität, Testfrequenz, Anbieteranforderungen, Datenschutz, Freigaben, Remediation und Retest. Erst diese Kette ist compliance-tauglich.

Reicht ein Vulnerability Scan für NIS2 aus?

Ein Scan reicht für Basistransparenz und laufende Breitenkontrolle oft aus, aber nicht immer für die Wirksamkeitsbewertung. Wo Business-Logic, Rechteketten, Cloud-Fehlkonfigurationen oder reale Angriffspfade relevant sind, brauchen Sie zusätzlich einen manuellen Pentest.

Wie oft sollte ein NIS2-Pentest stattfinden?

NIS2 nennt kein starres Intervall. In der Praxis ist ein risikobasierter Rhythmus sinnvoll: laufende Scans, zusätzliche Pentests nach wesentlichen Änderungen, vor Go-Live kritischer Systeme, nach schweren Vorfällen und periodisch für besonders relevante Anwendungen.

Welche Unterlagen sollte ich bei einer Prüfung sofort vorlegen können?

Sie sollten Scope, Rules of Engagement, Beauftragungsvertrag, Freigabe, Datenschutzunterlagen, Bericht, Priorisierung, Nachbesserungsplan und Retest-Nachweise vorlegen können. Ohne diese Unterlagen ist ein Pentest für Audits oft deutlich weniger wert.

Darf jeder Anbieter einfach Produktivsysteme testen?

Nein. Produktivtests brauchen klare Freigabe, belastbare Impact-Grenzen und eine methodisch passende Durchführung. Besonders bei OT, Zahlungsprozessen oder personenbezogenen Daten muss der Scope eng gesteuert und rechtlich sauber dokumentiert sein.