Der Auftrag für einen Penetrationstest kommt im KMU selten aus der Sicherheit. Er kommt aus einem Vertrag. Im Rahmenvertrag eines Grosskunden steht ein Satz über einen jährlichen Penetrationstest, der Einkauf leitet ihn an die IT weiter, und zwei Wochen später liegen drei Angebote auf dem Tisch, die sich im Preis um ein Mehrfaches unterscheiden und inhaltlich kaum vergleichbar sind. Die Frage, die dann in der Geschäftsleitung landet, ist eine kaufmännische: Was kaufen wir hier, und was haben wir danach in der Hand?
Ein Penetrationstest beweist, dass eine definierte Angriffsfläche zu einem bestimmten Zeitpunkt überwunden werden konnte oder nicht. Er beweist nicht, dass ihr sicher seid, und er ersetzt keine Standortbestimmung. Er zahlt sich aus, wenn eine Entscheidung am Ergebnis hängt, die Feststellungen einen Besitzer haben und im Quartal danach Kapazität zur Behebung existiert. Sonst kaufst du eine Liste, die ein Jahr später gleich aussieht.
Wer den Test verlangt, bestimmt, was er beweisen soll
Vier Auslöser bringen in unserer Erfahrung die meisten Tests ins Haus, und jeder will etwas anderes.
- Ein Kunde. Er braucht einen Nachweis für sein eigenes Lieferantenmanagement. Ihn interessiert vor allem, dass ein unabhängiger Prüfer geschaut hat, weniger was im Detail gefunden wurde.
- Ein Versicherer. Der Fragebogen fragt nach regelmässigen Tests. Dort zählen der Rhythmus und der Nachweis, dass Gefundenes behoben wurde, weniger die Tiefe eines einzelnen Berichts.
- Der Verwaltungsrat. Meist nach einem Vorfall in der Branche. Die Frage dahinter heisst: Könnte das bei uns auch passieren? Ein Test auf ein einzelnes System antwortet darauf nur zum Teil.
- Die eigene IT. Vor einem Go-live oder nach einem grösseren Umbau. Das ist der sauberste Fall, weil eine Entscheidung am Ergebnis hängt.
Der häufigste Fehler passiert direkt danach: Die Formulierung aus der Vertragsklausel wird zum technischen Scope. "Jährlicher Penetrationstest der produktiven Systeme" ist kein Scope. Es ist eine Einladung, zehn Testtage zu kaufen, von denen drei das Ziel treffen, das der Kunde meint. Klärst du vorher, welche Frage der Test beantworten soll, kaufst du weniger ein und bekommst mehr zurück.
Was der Test belegt, und was er offen lässt
Ein Penetrationstest beweist, dass eine definierte Angriffsfläche zu einem bestimmten Zeitpunkt von einer bestimmten Person mit bestimmten Rechten und begrenzter Zeit überwunden werden konnte. Oder eben nicht. Das ist wertvoll, und es ist schmaler als der Eindruck, den ein sechzigseitiger Bericht hinterlässt. Kein Test beantwortet, ob eure Wiederherstellung aus dem Backup funktioniert, ob im Betrieb jemand den Angriff bemerkt hätte oder wer um drei Uhr nachts entscheidet, einen Standort vom Netz zu nehmen.
| Instrument | Beantwortet | Beantwortet nicht |
|---|---|---|
| Schwachstellenscan | Welche bekannten Lücken sind von aussen oder innen sichtbar? | Ob sie in eurer Umgebung ausnutzbar sind |
| Penetrationstest | Kommt ein Angreifer an dieser definierten Stelle durch? | Ob der Betrieb es merkt, ob Backups tragen, wer entscheidet |
| Security Assessment | Wo steht die Organisation insgesamt, was ist das grösste Risiko? | Ob eine einzelne Anwendung technisch überwindbar ist |
| Zertifizierungsaudit | Erfüllt das Managementsystem die Norm? | Ob die Technik einem Angriff standhält |
Zwei Dinge tauchen in Mandaten oft zusammen auf: ein frischer Testbericht und ein Ordner mit dem Bericht vom Vorjahr, in dem ein guter Teil der Feststellungen schon stand. Das ist kein Sicherheitsproblem, das ist ein Dimensionierungsproblem. Mehr Schutz. Weniger Tools. Weniger Kosten. Der Satz gilt auch für Prüfungen: lieber ein kleinerer Test, der behoben wird, als ein grosser, der verwaltet wird.
Wann lohnt sich ein Penetrationstest?
Ein Penetrationstest lohnt sich, wenn eine Entscheidung am Ergebnis hängt: eine Freigabe, ein Nachweis gegenüber einem Kunden, eine intern strittige Annahme über ein exponiertes System. Hängt keine Entscheidung daran, bleibt ein PDF. Drei Bedingungen entscheiden in der Praxis, ob sich das Geld in Schutz verwandelt oder in Dokumentation.
- Die Feststellungen haben einen Besitzer, bevor der Test startet. Ein Name, nicht "die IT". Ohne Besitzer wandert der Bericht in den Ordner, in dem schon der letzte liegt.
- Im Quartal nach dem Test existiert Kapazität. Wer kein Fenster für Behebung und Retest hat, kauft eine Momentaufnahme, die bereits beim Lesen veraltet.
- Das Ziel ist exponiert und geschäftskritisch. Kundenportal, API, Fernzugang, die Anwendung mit den Daten, deren Verlust euch den Kunden kostet. Der Rest wartet.
Fehlt die Standortbestimmung noch komplett, ist ein Test der teuerste Weg zur ersten Erkenntnis. Willst du zuerst wissen, wo die Organisation insgesamt steht, bringt eine strukturierte Selbstbeurteilung mehr. Das BACS stellt dafür ein Assessment-Werkzeug zum IKT-Minimalstandard bereit, verbindlich für Stromversorger seit 1. Juli 2024 und für Gasversorger seit 1. Juli 2025, für die übrigen Sektoren als Empfehlung. Was eine begleitete Standortbestimmung darüber hinaus liefert, steht in unserem Beitrag über das Security Assessment als Standortbestimmung.
Der Test ist der kleinere Teil der Rechnung
Die Offerte deckt den Test. Sie deckt nicht die Arbeit, die ihn wertvoll macht. Nach dem Bericht kommen Priorisierung, Behebung, Wartungsfenster, Entwicklerzeit und manchmal Gespräche mit dem Hersteller einer Software, die ihr nicht selbst gebaut habt. Dazu der Retest, sonst bleibt am Ende die Behauptung, es sei behoben. In unserer Erfahrung ist der externe Testaufwand der kleinere Posten. Der grössere liegt intern und trifft Teams, die bereits ein Backlog haben.
Behebung und Retest gehören deshalb in denselben Beschluss wie der Test und nicht ins nächste Budgetjahr. Ein Test ohne eingeplante Behebung ist eine Ausgabe, kein Schutz. Wie Security-Ausgaben im KMU überhaupt sichtbar werden und welche Töpfe es braucht, haben wir im Beitrag über das Security-Budget im KMU auseinandergenommen.
Woran erkennst du einen brauchbaren Test?
Am Scoping-Gespräch und am Bericht, nicht am Preis. Ein brauchbares Angebot nennt Methodik, Zeitbudget, die Rechte des Testers und das, was ausdrücklich nicht geprüft wird. Wer innert eines Tages eine Offerte schickt, ohne gefragt zu haben, was hinter der Anwendung läuft, verkauft meistens einen Scan mit einem besseren Namen.
- Methodik benannt. Für Webanwendungen etwa die OWASP-Testmethodik für Webanwendungen, aktuell in Version 4.2. Eine benannte Methodik macht Tests vergleichbar, auch über einen Anbieterwechsel hinweg.
- Feststellungen mit Geschäftswirkung. Ein Fund, der Daten anderer Mandanten sichtbar macht, ist etwas anderes als eine veraltete Bibliothek, zu der kein Pfad führt. Ein Bericht, der nur nach Punktwert sortiert, verschiebt diese Unterscheidung zu dir.
- Nachvollziehbare Beweisführung. Eure Entwickler müssen einen Fund reproduzieren können, ohne den Prüfer anzurufen.
- Retest eingeschlossen oder zum Festpreis angeboten. Ohne Retest endet der Test mit einer Vermutung.
- Ein Readout mit einem Menschen. Jemand, der die drei wichtigsten Feststellungen in fünf Minuten erklärt, auch der Geschäftsleitung, ohne Fachjargon.
Der Unterschied zwischen Scan und Test ist Handarbeit. Ein Scan läuft automatisiert und findet Bekanntes. Das ist nützlich und gehört in den laufenden Betrieb, nicht in eine Jahresrechnung. Ein Test findet Logikfehler, falsch gesetzte Berechtigungen und Verkettungen, die einzeln harmlos aussehen. Genau diese Handarbeit bezahlst du, und nur sie rechtfertigt den Preisunterschied.
Wie das in einem Betrieb aussieht
Ein Softwarehaus mit 230 Mitarbeitenden in der Nordwestschweiz bekommt mit dem neuen Rahmenvertrag seines grössten Kunden die Pflicht zu einem jährlichen Penetrationstest. Das erste Angebot umfasst zehn Tage: Kundenportal, internes Netz, mobile App, dazu eine Phishing-Simulation. Im Scoping zeigt sich, dass der Kunde etwas Engeres meint. Ihn interessiert das Portal, über das er seine Daten liefert, und die Trennung zu den Daten anderer Mandanten.
Der Scope wird auf Portal, API und Anmeldeverfahren reduziert. Der Test findet vierzehn Feststellungen, drei davon relevant, eine davon ernst: Über einen manipulierten Parameter sind Datensätze eines anderen Mandanten erreichbar. Die Behebung dauert länger als der Test, weil zwei Stellen im Berechtigungsmodell betroffen sind. Der Retest nach sechs Wochen bestätigt den Stand. Was zum Kunden geht, ist ein einseitiges Schreiben des Prüfers mit Scope, Zeitraum, Methodik und der Aussage nach dem Retest.
Im Jahr darauf wird nicht dasselbe nochmals geprüft, sondern die neue Schnittstelle zum ERP, die inzwischen produktiv ist. Der Scope wurde enger, und der Nachweis gegenüber dem Kunden trug mehr. Das interne Netz und die mobile App aus dem ersten Angebot sind nie getestet worden, und niemand hat sie vermisst, weil keine Entscheidung an ihnen hing.
Was die Geschäftsleitung aus einem Test erfahren muss
Drei Sätze genügen, und der dritte ist der einzige, der etwas bewegt: Was wurde geprüft, was wurde ausdrücklich nicht geprüft, und was ändert sich durch das Ergebnis an einer Entscheidung. In unserer Erfahrung fällt in der Berichterstattung regelmässig der zweite Satz weg. Genau dort entsteht das falsche Gefühl von Abdeckung. Wer hört, der Penetrationstest sei bestanden, hört: Wir sind sicher.
Deshalb gehört der Nicht-Scope laut ausgesprochen. Geprüft wurde das Kundenportal, nicht die Wiederherstellung aus dem Backup und nicht die Zahlungsfreigabe im ERP. Das klingt nach Relativierung und ist das Gegenteil: Es hält die offenen Themen im Blickfeld der Geschäftsleitung, statt sie hinter einem grünen Haken zu parkieren. Ein Testbericht ist damit ein Datenpunkt im Risikobild, der neben der Ausfallübung und der Lieferantenlage steht.
Wem der Bericht gehört
Der vollständige Bericht bleibt im Haus. Nach aussen geht eine Zusammenfassung oder ein Attestierungsschreiben des Prüfers: Scope, Zeitraum, Methodik, Aussage zum Stand nach dem Retest. Kunden brauchen eine Seite, nicht sechzig, und eine detaillierte Schwachstellenliste an Dritte weiterzugeben, ist ein eigenes Risiko. Steht im Vertrag ausdrücklich der vollständige Bericht, ist das eine Verhandlungsposition und kein Naturgesetz.
Intern gehört jede Feststellung mit Besitzer und Datum ins Risikoregister, auch die bewusst akzeptierten. Ein akzeptiertes Risiko ohne Unterschrift ist nur eine vergessene Feststellung. Und wenn im nächsten Bericht dieselben Punkte wieder auftauchen, lohnt sich die Frage, wer zwischen den beiden Tests entscheiden durfte.
Ob bei euch zuerst ein Test oder zuerst eine Standortbestimmung ansteht, hängt davon ab, was ihr schon belegen könnt. Die Reihenfolge, mit der wir in Mandaten arbeiten, steht mit Umfang und Preisen in der Paketübersicht mit Festpreisen.
Häufige Fragen
Reicht ein Schwachstellenscan statt eines Penetrationstests?
Für den laufenden Betrieb ist ein regelmässiger Scan oft wertvoller als ein jährlicher Test, weil er Veränderungen zeitnah sichtbar macht. Als Nachweis gegenüber einem Kunden reicht er selten, und Logik- oder Berechtigungsfehler findet er nicht. Die beiden ersetzen sich nicht, sie beantworten verschiedene Fragen.
Wie oft sollte ein KMU testen lassen?
Anlassbezogen statt kalendarisch, sofern kein Vertrag etwas anderes verlangt. Ein relevanter Anlass ist eine Änderung an einem exponierten System: neue Schnittstelle, neues Anmeldeverfahren, grösserer Umbau. Wo ein Kunde einen Jahresrhythmus verlangt, lohnt es sich, jedes Jahr etwas anderes in den Scope zu nehmen statt dieselbe Prüfung zu wiederholen.
Können wir intern testen statt extern einzukaufen?
Intern Scans zu fahren und Konfigurationen zu prüfen, ist sinnvoll und günstig. Für den Nachweis nach aussen fehlt die Unabhängigkeit, und wer ein System betreibt, prüft es selten gegen die eigenen Annahmen. In unserer Erfahrung finden interne Prüfungen vor allem das, was intern schon vermutet wurde.