Penetrationstests ausschreiben: Leistungsbeschreibung, Vertraulichkeit und Haftung rechtssicher regeln

Ein kritischer Sicherheitsvorfall, ein Hinweis aus dem ISMS oder die Vorbereitung auf neue NIS-2-Pflichten führt oft zu derselben Frage: Wie lässt sich ein externer Penetrationstest beschaffen, ohne dabei den Betrieb zu gefährden oder den Auftrag rechtlich zu unbestimmt zu formulieren? Wer nur „Pentest durchführen“ ausschreibt, erhält kaum vergleichbare Angebote und schafft gefährliche Spielräume. Entscheidend sind ein klarer Testauftrag, verbindliche Betriebsgrenzen und Regeln für den Umgang mit den Ergebnissen.

Externe Penetrationstests sind kein bloßer technischer Einkauf. Sie berühren Vertraulichkeit, Verfügbarkeit und Integrität von IT-Systemen, häufig auch personenbezogene Daten, Geschäftsgeheimnisse sowie die Betriebsabläufe von Fachbereichen. Bei Red-Teaming-Aufträgen können zusätzlich physische Sicherheitsmaßnahmen, Social Engineering oder Reaktionen von Sicherheitsorganisationen betroffen sein. Deshalb müssen Vergabestelle, IT-Sicherheit, Datenschutz, Fachbereich und Rechtsverantwortliche frühzeitig zusammenarbeiten.

Warum der Bedarf an externen Tests steigt

Die Bedrohungslage verändert sich kontinuierlich. Angreifer nutzen Schwachstellen in extern erreichbaren Diensten, Fehlkonfigurationen in Cloud-Umgebungen, gestohlene Zugangsdaten und Abhängigkeiten in Lieferketten. Gleichzeitig erwarten Aufsichtsbehörden, Kunden und interne Revisionen einen nachvollziehbaren Sicherheitsprozess.

Die NIS-2-Richtlinie erhöht den Handlungsdruck für betroffene Einrichtungen und Unternehmen. Sie verlangt unter anderem angemessene Maßnahmen zum Risikomanagement im Bereich der Cybersicherheit. Ob und in welchem Umfang regelmäßige externe Penetrationstests im konkreten Fall erforderlich sind, hängt von Risikolage, Systemlandschaft, Kritikalität und vorhandenen Kontrollen ab. Ein Pentest ersetzt weder ein Informationssicherheitsmanagement noch Patch-Management, Monitoring oder Notfallvorsorge. Er kann aber gezielt prüfen, ob Sicherheitsmaßnahmen in der Praxis wirksam sind.

Für die Einordnung der Anforderungen hilft unser Beitrag zur NIS-2-Richtlinie: Wen sie betrifft und welche Pflichten gelten. Wenn du Sicherheitsanforderungen ohnehin in einer Ausschreibung nachweisbar und verhältnismäßig ausgestalten musst, beachte auch IT-Sicherheitsanforderungen ausschreiben: BSI C5, ISO 27001 und Nachweise rechtssicher fordern.

Pentest, Schwachstellenscan und Red Team sauber unterscheiden

Schon die Leistungsbeschreibung muss klarstellen, welche Prüfungsart du beschaffst. Die Begriffe werden in der Praxis oft vermischt, führen aber zu erheblich unterschiedlichen Leistungen und Risiken.

Prüfungsart	Typischer Zweck	Typische Tiefe
Schwachstellenscan	Bekannte Schwachstellen und Fehlkonfigurationen automatisiert erkennen	Breite Erfassung, begrenzte Verifikation
Penetrationstest	Schwachstellen identifizieren, validieren und kontrolliert ausnutzen	Zielgerichtete technische Prüfung
Red Teaming	Realistische Angriffssimulation gegen Menschen, Prozesse und Technik	Szenariobasiert, oft mit verdecktem Vorgehen
Purple Teaming	Abwehr und Angriff gemeinsam testen und verbessern	Zusammenarbeit von Testteam und Verteidigung

Ein automatisierter Scan kann Bestandteil eines Pentests sein, genügt aber nicht als dessen Ersatz. Umgekehrt kann ein Pentest, der produktive Systeme berührt, nicht ohne Risikovorgaben durchgeführt werden. Red Teaming ist besonders eingriffsintensiv und sollte nur beauftragt werden, wenn Ziele, Freigaben, Eskalationswege und das Zusammenspiel mit dem Security Operations Center belastbar vorbereitet sind.

Die Leistungsbeschreibung beginnt mit dem Prüfziel

Eine gute Leistungsbeschreibung beschreibt nicht nur Systeme, sondern auch den Sicherheitsnutzen, den du erwartest. Formuliere deshalb zunächst das Prüfziel: Soll der externe Angriffspfad auf ein Fachverfahren geprüft werden? Geht es um eine Webanwendung vor dem Go-live? Sollen Administratorrechte in einer hybriden Umgebung erlangt werden? Oder soll das interne Erkennen und Reagieren auf einen simulierten Angriff getestet werden?

Danach grenzt du den Leistungsumfang ab. Dazu gehören insbesondere:

• Zu prüfende Anwendungen, Schnittstellen, IP-Adressbereiche, Mandanten und Cloud-Dienste
• Einbezogene Umgebungen wie Entwicklung, Test, Staging und Produktion
• Bereitgestellte Testkonten, Rollen, Mehrfaktor-Authentisierung und Berechtigungsstufen
• Zulässige Testmethoden und ausdrücklich ausgeschlossene Methoden
• Anforderungen an die Dokumentation von Befunden und Nachtests
• Erwartete Abstimmungstermine, Zwischenberichte und Abschlusspräsentationen

Die Leistungsbeschreibung darf funktionsorientiert sein. Du musst nicht vorgeben, mit welchen Tools ein Auftragnehmer arbeitet. Du darfst aber verlangen, dass er sein methodisches Vorgehen, die Qualitätssicherung und die Qualifikation des eingesetzten Personals darlegt. Das ist besonders sinnvoll, wenn der Auftrag sensible Produktivsysteme betrifft.

Grundsätzlich gelten auch hier die allgemeinen Anforderungen an eine eindeutige und erschöpfende Leistungsbeschreibung. Wie du Leistungen vergaberechtlich belastbar strukturierst, erläutern wir in Leistungsbeschreibung erstellen: das Herz der Ausschreibung.

Testumfang und Testfenster praxistauglich festlegen

Der technische Scope muss so konkret sein, dass keine Zweifel über die Erlaubnis bestehen. Ein Pentest ohne eindeutige Autorisierung kann strafrechtliche Risiken auslösen und den Betrieb gefährden. Lege deshalb in einer Anlage zum Vertrag verbindlich fest, welche Systeme getestet werden dürfen. Nutze eindeutige Kennungen wie Hostnamen, URLs, Mandantenbezeichnungen, IP-Bereiche, API-Endpunkte oder Anwendungen.

Ebenso wichtig ist der zeitliche Rahmen. Ein Testfenster definiert, wann aktive Prüfhandlungen zulässig sind. Das kann etwa bei geschäftskritischen Anwendungen auf Wartungszeiten oder Zeiten mit geringer Last begrenzt werden. Für kritische Sicherheitslücken muss es einen geregelten Ausnahmeprozess geben, wenn außerhalb des Testfensters ein unmittelbarer Handlungsbedarf besteht.

Folgende Punkte sollten in der Leistungsbeschreibung oder im Testauftrag stehen:

• Beginn, Ende und zulässige Uhrzeiten der Testaktivitäten
• Ansprechpartner auf Auftraggeber- und Auftragnehmerseite mit Vertretungsregelung
• Technische Kontaktwege für dringende Meldungen außerhalb üblicher Geschäftszeiten
• Maximal zulässige Last, Anzahl paralleler Anfragen und Grenzen für automatisierte Tests
• Verbot von Denial-of-Service-Tests, Datenlöschung oder dauerhaften Konfigurationsänderungen, sofern nicht ausdrücklich freigegeben
• Verfahren zum sofortigen Abbruch bei Betriebsstörungen oder Sicherheitsvorfällen
• Regelung für Systeme Dritter, etwa Hosting-, SaaS- oder Cloud-Anbieter

Gerade bei Cloud-Diensten ist zu prüfen, ob die Vertragsbedingungen des Dienstanbieters Sicherheitstests regeln oder eine vorherige Anmeldung verlangen. Der Auftraggeber kann einem Pentester nur Zugriffe erlauben, zu denen er selbst berechtigt ist.

Produktivsysteme testen, ohne den Betrieb aufs Spiel zu setzen

Tests in Produktionsumgebungen sind häufig unvermeidbar, etwa weil Konfiguration, Identitäten, Schnittstellen und Berechtigungen in Testumgebungen nicht realitätsnah abgebildet sind. Sie verlangen jedoch eine abgestufte Risikosteuerung.

Fordere zunächst eine Testplanung mit Methoden, potenziellen Auswirkungen, Rückfallebene und Eskalationswegen. Bei besonders kritischen Systemen kann ein stufenweises Vorgehen sinnvoll sein: Zuerst passive Prüfung und Konfigurationsanalyse, dann kontrollierte aktive Tests und erst nach Freigabe eine eingeschränkte Ausnutzung bestätigter Schwachstellen.

Die Ausnutzung darf nicht mit unkontrolliertem Datenabfluss verwechselt werden. Definiere, welche Nachweise genügen. Häufig reicht ein technisch nachvollziehbarer Proof of Concept, ohne vollständige Datenbestände zu kopieren. Werden personenbezogene Daten verarbeitet, sind Datenminimierung, Zweckbindung und geeignete Schutzmaßnahmen zu beachten. Je nach Rollenverteilung kann außerdem ein Auftragsverarbeitungsvertrag erforderlich sein. Die Grundlagen dazu findest du in Auftragsverarbeitungsvertrag (AVV): Pflichten nach Art. 28 DSGVO.

Befunde melden, priorisieren und nachverfolgen

Der Abschlussbericht darf nicht die erste Nachricht über eine kritische Schwachstelle sein. Vereinbare ein mehrstufiges Meldeverfahren. Kritische Befunde müssen unverzüglich an klar benannte Stellen gehen, etwa an den CISO, das Incident-Response-Team oder den technischen Bereitschaftsdienst. Für normale und niedrige Befunde können regelmäßige Statusberichte genügen.

Der Bericht sollte mindestens enthalten:

• Beschreibung der Schwachstelle und betroffene Systeme
• Nachweis der erfolgreichen Validierung in angemessenem Umfang
• Risikoeinstufung mit nachvollziehbarer Begründung
• Angriffsweg und Voraussetzungen für eine Ausnutzung
• Konkrete Handlungsempfehlungen mit Priorisierung
• Angaben zu Testmethode, Grenzen und nicht geprüften Bereichen
• Management-Zusammenfassung für Leitung und Fachverantwortliche

Verlange eine nachvollziehbare Risikobewertung, ohne zwingend ein bestimmtes Bewertungssystem vorzuschreiben. Wichtig ist, dass Kritikalität, Eintrittsvoraussetzungen und mögliche Auswirkungen verständlich dokumentiert werden. Plane zudem einen Nachtest ein. Nur so lässt sich feststellen, ob die Schwachstelle tatsächlich wirksam behoben wurde.

Vertraulichkeit, Geheimnisschutz und Umgang mit Testdaten

Pentester erhalten oft Informationen, die selbst intern nur wenigen Personen zugänglich sind: Netzpläne, Konfigurationsdaten, Zugangsdaten, Quellcodeauszüge, Sicherheitsarchitektur und Befunde. Eine allgemeine Vertraulichkeitsklausel reicht dafür meist nicht aus.

Regle konkret, welche Informationen vertraulich sind, wer darauf zugreifen darf und zu welchem Zweck sie verarbeitet werden dürfen. Verpflichtungen des Auftragnehmers sollten auch für eingesetzte Beschäftigte und Unterauftragnehmer gelten. Unterauftragnehmer dürfen nur nach vorheriger Zustimmung eingesetzt werden. Außerdem braucht es Vorgaben für sichere Übertragungswege, Verschlüsselung, Aufbewahrungsfristen, Rückgabe und Löschung der Unterlagen.

Besondere Aufmerksamkeit verdienen Zugangsdaten. Sie dürfen nur personalisiert, zeitlich begrenzt und nach dem Test unverzüglich deaktiviert werden. Zugangsdaten gehören nicht unverschlüsselt in Tickets, E-Mails oder Abschlussberichte. Der Bericht selbst muss geschützt bereitgestellt werden, denn er ist eine wertvolle Anleitung für potenzielle Angreifer.

Haftung und vertragliche Einordnung

Ein Pentest bewegt sich in einem Spannungsfeld: Der Auftragnehmer soll Schwachstellen fundiert prüfen, darf dabei aber keine vermeidbaren Schäden verursachen. Die vertragliche Regelung muss dieses Spannungsfeld angemessen abbilden.

Lege fest, dass der Auftragnehmer nur innerhalb des freigegebenen Scopes und der vereinbarten Methoden handelt. Verstöße gegen diese Grenzen können haftungsrechtlich erheblich sein. Umgekehrt muss der Auftraggeber vollständige und richtige Informationen zu kritischen Betriebsbedingungen, Systemabhängigkeiten und Einschränkungen bereitstellen.

Prüfe insbesondere:

• Welche Pflichten bei Betriebsstörungen und Sicherheitsvorfällen gelten
• Ob Mindestanforderungen an eine Berufshaftpflichtversicherung sachlich erforderlich sind
• Wie Haftungsbegrenzungen ausgestaltet sind und ob sie zum Schadensrisiko passen
• Welche Rechte bei mangelhafter Leistung, unvollständiger Dokumentation oder Fristüberschreitung bestehen
• Wem Prüfberichte, Arbeitsergebnisse und entwickelte Testskripte zustehen
• Wie Gewährleistung und Nachbesserung, insbesondere beim Nachtest, geregelt sind

Für öffentliche Auftraggeber kommen abhängig von Leistungsgegenstand und Vertragsgestaltung geeignete EVB-IT-Vertragstypen oder ergänzende Vertragsbedingungen in Betracht. Entscheidend ist, dass die Regelungen zu Leistung, Datenschutz, Informationssicherheit und Haftung konsistent sind. Einen Überblick bietet unser Beitrag EVB-IT verstehen: die Verträge im Überblick.

Checkliste vor der Veröffentlichung

Prüfe vor dem Start des Verfahrens diese Fragen:

• Ist das Prüfziel eindeutig und mit dem Sicherheitsrisiko begründet?
• Sind alle testbaren Systeme, Schnittstellen und Umgebungen eindeutig benannt?
• Sind ausgeschlossene Systeme und Methoden ausdrücklich festgelegt?
• Gibt es Testfenster, Abbruchkriterien und erreichbare Eskalationskontakte?
• Ist geklärt, ob Dritte dem Test zustimmen müssen?
• Sind Datenschutz, Geheimnisschutz und Löschpflichten geregelt?
• Gibt es ein Sofortmeldeverfahren für kritische Befunde?
• Sind Bericht, Management-Zusammenfassung und Nachtest als Leistung definiert?
• Passen Eignungsanforderungen, Zuschlagskriterien und Vertragsbedingungen zum Risiko?

Eine präzise Ausschreibung schafft nicht nur Vergleichbarkeit im Wettbewerb. Sie schützt auch den laufenden Betrieb, erleichtert die Zusammenarbeit mit dem Auftragnehmer und sorgt dafür, dass aus technischen Befunden wirksame Sicherheitsmaßnahmen werden. Passende Seminare und Termine findest du bei uns auf cmt.de.