Ein Penetrationstest untersucht, ob sich Sicherheitsmaßnahmen eines festgelegten Systems unter vereinbarten Bedingungen umgehen lassen. Für Auftraggeber ist deshalb die wichtigste Frage nicht, welches Werkzeug der Prüfer verwendet, sondern welche belastbare Aussage sie anschließend erhalten. Ein Test einer öffentlichen Webseite sagt wenig über die Berechtigungen im internen Fachverfahren aus. Ein begrenzter Auftrag kann sinnvoll sein, wenn seine Grenzen offen beschrieben werden.
Der BSI-Praxis-Leitfaden für IS-Penetrationstests liegt in der hier herangezogenen Fassung als Version 1.2 vom November 2016 vor. Er beschreibt organisatorische und fachliche Vorbereitung, Durchführung und Berichterstattung. Seine Empfehlungen sind von heutigen gesetzlichen Anforderungen zu unterscheiden. Insbesondere ist das Dokument weder eine neue Ausgabe von 2026 noch ein Schema gesetzlich vorgeschriebener Pentest-Klassen I bis V.
Was ein Pentest nachweisen kann
Ein guter Auftrag beginnt mit einer konkreten Sicherheitsfrage. Beispielsweise soll geklärt werden, ob ein gewöhnliches Benutzerkonto auf Daten anderer Kunden zugreifen kann oder ob ein Angreifer über einen extern erreichbaren Dienst in weitere Systeme gelangt. Diese Frage bestimmt die benötigten Zugänge, Rollen und Schnittstellen. Die bloße Formulierung, das Unternehmen solle auf Sicherheit geprüft werden, lässt zu viele entscheidende Annahmen offen.
Ein Schwachstellenscan erfasst typischerweise bekannte technische Auffälligkeiten und muss fachlich ausgewertet werden. Ein Penetrationstest kann solche Ergebnisse vertiefen, Zusammenhänge untersuchen und innerhalb der Freigabe die Ausnutzbarkeit beurteilen. Eine Codeprüfung betrachtet dagegen den Quelltext und kann Fehler finden, die bei einer begrenzten Prüfung des laufenden Systems nicht erreicht werden. Die Verfahren ergänzen sich, ohne dieselbe Aussagekraft zu besitzen.
Der Pentest bleibt eine zeitlich und sachlich begrenzte Untersuchung. Ein Bericht ohne kritischen Befund beweist nicht, dass keine Schwachstelle existiert. Nicht untersuchte Funktionen, begrenzte Testzeit und spätere Änderungen müssen bei jeder Verwendung des Ergebnisses berücksichtigt werden. Der Bericht sollte deshalb genauso klar erklären, was nicht geprüft wurde, wie er die tatsächlich untersuchten Angriffsmöglichkeiten beschreibt.
Gesetzliche Pflicht und fachliche Empfehlung auseinanderhalten
Artikel 32 DSGVO verlangt unter anderem ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit von Sicherheitsmaßnahmen. Daraus folgt keine allgemeine Verpflichtung jedes Unternehmens, genau einmal oder zweimal jährlich einen externen Pentest zu beauftragen. Welche Prüfungen erforderlich sind, hängt vom konkreten Risiko und weiteren anwendbaren Vorgaben ab. Der Sicherheitsmaßstab des Artikels 32 betrifft außerdem mehr als die technischen Ergebnisse eines einzelnen Tests.
Für besonders wichtige und wichtige Einrichtungen verlangt § 30 des geltenden BSIG geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen einschließlich Verfahren zur Bewertung ihrer Wirksamkeit. Für bestimmte digitale Dienste haben europäische Durchführungsanforderungen Vorrang. Hinzu kommen gegebenenfalls sektorale Regeln und besondere Anforderungen an kritische Anlagen. Die Einordnung der deutschen NIS2-Umsetzung hilft, zuerst die eigene Betroffenheit zu bestimmen.
Auch gesetzliche Nachweispflichten und ein Pentest sind nicht gleichzusetzen. § 39 BSIG betrifft Nachweise für Betreiber kritischer Anlagen durch Sicherheitsaudits, Prüfungen oder Zertifizierungen und enthält eigene Fristen und Übergangsbedingungen. Ein beliebiger Pentestbericht erfüllt diesen umfassenderen Nachweis nicht automatisch. Klären Sie daher vor der Beauftragung, ob das Ergebnis einem gesetzlichen Nachweis, einer vertraglichen Zusage oder einer internen Risikoprüfung dienen soll.
Der BSI-Leitfaden empfiehlt in seiner Fassung von 2016 Wiederholungsprüfungen nach zwei bis drei Jahren. Das ist eine datierte fachliche Empfehlung und keine universelle gesetzliche Mindest- oder Höchstfrist. Wesentliche Änderungen, neue Angriffsmöglichkeiten oder besonders exponierte Anwendungen können frühere Prüfungen erfordern. Ein Unternehmen darf eine aktuell notwendige Prüfung nicht allein deshalb verschieben, weil seit dem letzten Termin noch keine drei Jahre vergangen sind.
Den Prüfgegenstand aus Geschäftsprozessen ableiten
Beschreiben Sie zuerst, welche Leistung das System unterstützt und welche Folgen ein erfolgreicher Angriff haben könnte. Ein Kundenportal umfasst häufig Anmeldung, Dokumentenabruf, Schnittstellen und Administrationsfunktionen. Wenn nur die sichtbaren Webseiten geprüft werden, bleiben möglicherweise gerade die entscheidenden Berechtigungsübergänge unberücksichtigt. Beziehen Sie deshalb die fachlich verantwortlichen Personen und die technische Betreuung in die Abgrenzung ein.
Hilfreich sind aktuelle Übersichten zu Systemen, Datenflüssen, Berechtigungen und externen Abhängigkeiten. Die Risikoanalyse nach BSI 200-3 kann die Auswahl besonders relevanter Prüfobjekte unterstützen. Sie ist aber nicht mit dem anschließenden Angriffstest identisch. Die Risikoanalyse erklärt, warum eine bestimmte Schnittstelle priorisiert wird; der Pentest untersucht die konkret vereinbarten Sicherheitsfragen an dieser Schnittstelle.
Legen Sie den Umfang nachvollziehbar fest: Anwendungen und Versionen, Umgebungen, freigegebene Adressen, Benutzerrollen und ausdrücklich ausgeschlossene Bereiche. Besonders bei gemeinsam genutzten Plattformen muss klar sein, welche Mandanten zum Auftrag gehören. Wird während der Untersuchung ein bislang unbekannter Dienst entdeckt, sollte er zunächst geklärt werden. Eine technisch erreichbare Adresse ist nicht allein dadurch vom Prüfauftrag umfasst.
Informationsstand und Prüftiefe bewusst wählen
Bei einem Blackbox-Test erhält das Prüfteam wenig Vorwissen. Bei einem Whitebox-Test stellt die Organisation umfangreiche Informationen über Aufbau und Konfiguration bereit. Dazwischen liegen abgestufte Modelle. Die Auswahl sollte der Sicherheitsfrage folgen. Geht es um einen möglichst breiten Erkenntnisgewinn innerhalb eines begrenzten Budgets, kann bereitgestelltes Wissen unnötige Sucharbeit reduzieren und die Untersuchung weniger sichtbarer Funktionen ermöglichen.
Der BSI-Leitfaden bevorzugt grundsätzlich Whitebox-Tests und eine moderate Angriffsstärke. Das sind Empfehlungen seines Vorgehensmodells. Wenn ein Auftrag bewusst den Blick eines uninformierten Außentäters untersuchen soll, müssen die daraus entstehenden Grenzen dokumentiert werden. Insbesondere darf ein ergebnisarmer Blackbox-Test nicht als Nachweis verwendet werden, dass ein informierter interner Benutzer keine Berechtigungsgrenzen überwinden könnte.
Die Prüftiefe sollte zwischen Beobachtung, technischer Validierung und weitergehender Ausnutzung unterscheiden. Ein Nachweis muss nicht automatisch mit dem massenhaften Auslesen echter Datensätze verbunden sein. Häufig reichen vereinbarte Testdaten oder ein begrenzter Beleg. Für risikoreichere Schritte ist ein gesonderter Freigabepunkt sinnvoll. Dadurch bleibt nachvollziehbar, wer über einen möglichen Eingriff in die produktive Verarbeitung entschieden hat.
Eine eindeutige Beauftragung schützt alle Beteiligten
Vor Beginn müssen die Prüfberechtigung und ihr Umfang geklärt sein. Ein schriftlicher Auftrag sollte Prüfobjekte, Zeitraum, zugelassene Methoden, Abbruchbedingungen und Ansprechpartner eindeutig festhalten. Die Schriftform dient hier besonders der sicheren Abgrenzung und Nachweisbarkeit. Eine pauschale Behauptung, jeder Test ohne Papiervertrag sei bereits deshalb strafbar, beschreibt die Rechtslage dagegen nicht korrekt.
Strafrechtlich kommt es unter anderem auf Befugnis, Handlung und geschützte Daten an. § 202a StGB erfasst unter seinen Voraussetzungen das unbefugte Überwinden einer Zugangssicherung; § 303a StGB betrifft rechtswidrige Datenveränderungen. Eine Freigabe eines Auftraggebers hilft nur innerhalb seiner tatsächlichen Befugnisse. Rechte eines Hosters, anderer Kunden oder sonstiger Dritter werden durch sie nicht automatisch beseitigt.
Bei Cloud- und Hostingdiensten müssen daher die Regeln und erforderlichen Zustimmungen des jeweiligen Anbieters berücksichtigt werden. Der Auftrag sollte auch erklären, wie fremde Daten oder unerwartete Zugänge behandelt werden. Ein zufälliger Fund außerhalb des Umfangs ist Anlass zur Meldung und Klärung, nicht zur eigenmächtigen Erweiterung des Tests. Änderungen des Auftrags gehören in eine nachvollziehbare neue Freigabe.
Produktivbetrieb und Testumgebung gegeneinander abwägen
Eine Testumgebung reduziert manche Betriebsrisiken. Ihre Aussagekraft hängt aber davon ab, wie gut sie die produktiven Bedingungen abbildet. Abweichende Zugriffsrechte, Netzfilter oder Softwarestände können einen Befund verstärken, abschwächen oder unsichtbar machen. Dokumentieren Sie diese Unterschiede. Das Ergebnis einer isolierten Umgebung darf nicht ohne Begründung auf die gesamte produktive Infrastruktur übertragen werden.
Bei einem Test im Produktivsystem braucht die Organisation erreichbare Betriebsverantwortliche und einen vorher besprochenen Umgang mit Störungen. Ein vorhandenes Backup genügt nicht, wenn die Wiederherstellung unbekannt oder im Prüfzeitraum nicht durchführbar ist. Klären Sie, welche Veränderungen rückgängig gemacht werden können und wer den Betrieb überwacht. Besonders empfindliche Systeme können eine andere Prüfmethode oder ein engeres Wartungsfenster erfordern.
Vereinbaren Sie konkrete Abbruchanlässe, etwa unerwartete Beeinträchtigung eines kritischen Dienstes oder Zugriff auf nicht freigegebene Datenbestände. Die Entscheidung zum Abbruch muss während der Prüfung erreichbar sein. Ein Kontakt, der lediglich am nächsten Werktag seine E-Mails liest, erfüllt diesen Zweck nicht. Auch das Prüfteam muss wissen, über welchen unabhängigen Kanal es die zuständige Person bei einem Ausfall erreicht.
Gleichzeitige Wartungen und Änderungen können die Ergebnisse verfälschen. Wenn während des Tests ein dringender Sicherheitsfehler behoben werden muss, sollte die Prüfung unterbrochen oder der veränderte Zustand klar neu erfasst werden. Die Aussage eines Berichts muss zu einer nachvollziehbaren Systemversion gehören. Ein späterer Leser sollte erkennen können, ob ein Befund vor oder nach einer bestimmten Änderung erhoben wurde.
Personenbezogene Daten und Beschäftigte mitdenken
Ein Pentest kann personenbezogene Daten in Protokollen, Bildschirmaufnahmen und Befundnachweisen erfassen. Legen Sie vorab fest, welche Daten wirklich benötigt werden, wer sie sehen darf und wie sie übertragen und gespeichert werden. Synthetische Testdatensätze können den Bedarf an echten Informationen reduzieren. Sie ersetzen aber keine Prüfung, ob die produktiven Berechtigungen tatsächlich korrekt umgesetzt sind.
Prüfen Sie die datenschutzrechtliche Rolle des Dienstleisters nach seiner konkreten Tätigkeit. Liegt Auftragsverarbeitung vor, gelten die Anforderungen des Artikels 28 einschließlich eines bindenden Vertrags oder eines anderen bindenden Rechtsinstruments nach Unions- oder mitgliedstaatlichem Recht, schriftlich einschließlich elektronischer Form. Der Leitfaden zur Auftragsverarbeitung erläutert diese Voraussetzungen. Eine reine Verschwiegenheitserklärung ersetzt die erforderlichen Regelungen nicht.
Vereinbaren Sie außerdem, wann technische Rohdaten und Nachweise gelöscht werden und welche Informationen für die Bearbeitung des Berichts erhalten bleiben müssen. Die Zugriffsgruppe sollte kleiner sein als der allgemeine Kreis aller Projektbeteiligten. Ein Pentestbericht kann besonders nützliche Informationen für Angreifer enthalten. Das gilt auch dann, wenn einzelne Kundennamen entfernt wurden und die technische Schwachstelle weiterhin genau beschrieben ist.
Social Engineering, Phishingübungen oder Tests gegen Beschäftigte sind kein stillschweigender Bestandteil jedes technischen Pentests. Sie benötigen eine eigene Bewertung von Zweck, Eingriffstiefe und gegebenenfalls Beteiligungsrechten. Der hier verwendete BSI-Leitfaden grenzt sein eigenes Vorgehen ausdrücklich von Social Engineering ab. Eine Freigabe zum Prüfen eines Servers erlaubt deshalb nicht automatisch eine täuschende Kampagne gegen seine Administratoren.
Prüfer auswählen, ohne Zertifikate zu überdehnen
Erfahrung sollte zum Prüfobjekt passen. Gute Kenntnisse einer Webanwendung sagen noch nichts über die Prüfung industrieller Steuerungen aus. Fragen Sie nach den tatsächlich eingesetzten Personen, ihrer Rolle im Projekt und einem nachvollziehbaren Vorgehen. Ein anonymisiertes Berichtsbeispiel kann zeigen, ob technische Befunde verständlich begründet und konkrete Abhilfen beschrieben werden. Es sollte keine vertraulichen Informationen anderer Auftraggeber offenlegen.
Das BSI bietet tatsächlich Personenzertifizierung für IS-Penetrationstester und Zertifizierungsverfahren für IT-Sicherheitsdienstleister an. Die pauschale Aussage, eine BSI-Zertifizierung existiere in diesem Bereich nicht, wäre falsch. Prüfen Sie jedoch genau, ob ein vorgelegter Nachweis eine Person, ein Unternehmen oder einen bestimmten Leistungsbereich betrifft und ob er für den Auftrag aussagekräftig ist.
Ein Qualifikationsnachweis ist keine Garantie, dass jede Schwachstelle gefunden wird. Ebenso wenig erhält Ihr geprüftes System automatisch ein BSI-Sicherheitszertifikat, weil der beauftragte Prüfer zertifiziert ist. Der BSI-Leitfaden betont zudem die Unabhängigkeit vom untersuchten Bereich. Beurteilen Sie mögliche Interessenkonflikte besonders dann, wenn derselbe Anbieter die Lösung aufgebaut hat und nun ihre Sicherheit bestätigen soll.
Vergleichen Sie Angebote anhand des gleichen Umfangs und der gleichen Ergebnisanforderungen. Berichterstattung, Abstimmung und Nachprüfung verursachen ebenfalls Aufwand. Ein niedriger Preis kann auf einem wesentlich engeren Test beruhen. Statt unbelegte Marktpreise oder feste Rentabilitätsquoten anzusetzen, lassen Sie erläutern, welche Arbeitspakete enthalten sind und welche zusätzliche Unterstützung bei kritischen Befunden verfügbar ist.
Vom Befund zur wirksamen Behebung
Der Bericht sollte Prüfobjekt, Zeitraum, Bedingungen und Einschränkungen nennen. Für die Leitung braucht es eine verständliche Darstellung der Risiken und Entscheidungen. Technische Verantwortliche benötigen ausreichend genaue Nachweise und Abhilfevorschläge. Eine lange Liste ungeprüfter Scannerwarnungen erfüllt diese Aufgabe nicht. Unbestätigte Hinweise müssen als solche erkennbar bleiben und dürfen nicht denselben Status wie nachvollzogene Schwachstellen erhalten.
Priorisieren Sie anhand der tatsächlichen Folgen und Angriffsmöglichkeiten. Ein technischer Schweregrad ist ein Hilfsmittel, aber kein vollständiger Ersatz für den eigenen Nutzungskontext. Ein Fehler an einer öffentlich erreichbaren Verwaltungsfunktion kann dringender sein als dieselbe Fehlerklasse in einem streng abgeschotteten Testsystem. Dokumentieren Sie Zuständigkeit, Termin, Zwischenmaßnahmen und verbleibende Unsicherheit, statt den Bericht nur abzulegen.
Die Behebung muss anschließend überprüft werden. Dabei sind eine gezielte Nachprüfung des konkreten Fehlers und eine erneute unabhängige Gesamtsicht unterschiedliche Aufgaben. Der BSI-Leitfaden unterscheidet interne Qualitätssicherung von unabhängigen Penetrationstests. Für Ihr Vorgehen bedeutet das: Eine Nachprüfung darf nicht nur bestätigen, dass eine einzelne Anfrage nun blockiert wird, wenn derselbe Berechtigungsfehler an anderen Stellen unverändert besteht.
Überführen Sie wiederkehrende Ursachen in Entwicklung und Betrieb. Die Hinweise zu sicherer Softwareentwicklung helfen, aus einzelnen Befunden dauerhafte Verbesserungen abzuleiten. Die IT-Grundschutz-Methodik ordnet solche Maßnahmen in ein breiteres Sicherheitsmanagement ein. Der Nutzen des Pentests entsteht wesentlich dadurch, dass Erkenntnisse anschließend systematisch bearbeitet werden.
Ein hypothetisches Kundenportal zeigt den Unterschied: Das Prüfteam findet einen Zugriff auf fremde Rechnungen, der nur über eine bestimmte Exportfunktion möglich ist. Eine Korrektur dieser Funktion genügt nicht als Nachweis, wenn dieselbe fehlende Berechtigungsprüfung auch Dokumentenvorschauen betrifft. Die verantwortliche Entwicklung sollte deshalb die gemeinsame Ursache untersuchen. Im Abschlussnachweis werden die konkret nachgeprüften Funktionen benannt; eine verbleibende Einschränkung wird offen dokumentiert. So bleibt die Aussage überprüfbar, ohne aus einem einzelnen erfolgreichen Nachtest eine unbegründete Sicherheitsgarantie für das gesamte Portal abzuleiten.
Wenn eine Prüfung einen echten Vorfall sichtbar macht
Ein gefundener Fehler ist nicht automatisch ein bereits eingetretener Datenschutzvorfall. Zeigen Protokolle jedoch unbefugten Zugriff oder verursacht die Prüfung selbst eine Verletzung personenbezogener Daten, muss die Organisation den Vorfall gesondert bewerten. Das Projektetikett Pentest ändert daran nichts. Sichern Sie relevante Belege und trennen Sie die vereinbarten Prüfhandlungen von sonstigen Aktivitäten.
Bei einer meldepflichtigen personenbezogenen Datenschutzverletzung informiert der Verantwortliche die zuständige Aufsicht unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, sofern die Verletzung nicht voraussichtlich ohne Risiko für Personen bleibt. Eine spätere Meldung benötigt eine Begründung. Jede Verletzung des Schutzes personenbezogener Daten ist nach Artikel 33 Absatz 5 zu dokumentieren, einschließlich nicht meldepflichtiger Verletzungen; bei voraussichtlich hohem Risiko kommt die gesonderte Information betroffener Personen nach Artikel 34 mit seinen gesetzlichen Ausnahmen hinzu. Der Ablauf zur Meldung einer Datenpanne sollte deshalb auch während des Testprojekts erreichbar sein.
Zum Projektabschluss gehören schließlich die Rücknahme temporärer Zugänge, die Entfernung vereinbarter Testartefakte und ein geregelter Umgang mit verbliebenen Nachweisen. Prüfen Sie, ob Änderungen aus der Vorbereitung wieder aufgehoben werden müssen. Ein geschlossenes Projektbudget beendet keine noch aktive Ausnahme in der Firewall. Erst wenn Ergebnisse, Maßnahmen und verbleibende Risiken den zuständigen Personen übergeben sind, wird aus dem einzelnen Test ein brauchbarer Beitrag zur laufenden Sicherheit.