Penetrationstest vs. Vulnerability Scan: Welche Sicherheitsbewertung Ihr Kleinunternehmen wirklich braucht

Ransomware taucht in 88 Prozent der Sicherheitsvorfälle bei Kleinunternehmen auf, und der durchschnittliche Vorfall bei einem Unternehmen mit weniger als 500 Mitarbeitern kostet etwa 3,31 Millionen US-Dollar. Vierzig Prozent der Kleinunternehmer sagen, dass ein einziger Angriff mit Kosten von 100.000 US-Dollar oder weniger sie in den Ruin treiben würde. Sie müssen kein Ziel sein, um Opfer zu werden: Automatisierte Bots sondieren jeden internetverbundenen Server, den Sie besitzen, jeden Tag – ganz gleich, ob jemand von Ihrem Unternehmen gehört hat oder nicht.

Die gute Nachricht ist, dass die beiden Standard-Sicherheitsbewertungen unterschiedliche Fragen beantworten, und die meisten Kleinunternehmen beide brauchen – in der richtigen Reihenfolge, mit der richtigen Häufigkeit. Ein Vulnerability Scan liefert Ihnen ein automatisiertes Inventar bekannter Schwachstellen. Ein Penetrationstest beauftragt einen Menschen damit, einzudringen, wie es ein Angreifer tun würde. Die beiden zu verwechseln ist teuer – in beide Richtungen: Entweder zahlen Sie einen fünfstelligen Betrag für einen simulierten Angriff, der Patches wiederentdeckt, die Sie nie eingespielt haben, oder Sie wedeln einem Auditor mit einem sauberen Scan-Bericht zu, der ausdrücklich einen Pen Test verlangt hat.

Dieser Leitfaden erklärt, was jede Bewertung leistet, was jede im Jahr 2026 kostet, wie oft Sie jeweils durchführen sollten, welche Compliance-Regeln die Wahl erzwingen und welche Entscheidungsreihenfolge einem Kleinunternehmen den meisten Schutz pro Euro bringt.

Die 60-Sekunden-Antwort​

Wenn Sie sich nur einen Absatz merken, dann diesen: Führen Sie automatisierte Vulnerability Scans kontinuierlich durch, beheben Sie, was sie finden, und beauftragen Sie einmal jährlich – oder nach jeder größeren Änderung – einen menschengeführten Penetrationstest. Der Scan ist Ihr Rauchmelder – günstig, immer aktiv und anfällig für Fehlalarme. Der Pen Test ist Ihre Feuerwehrinspektion – teuer, punktuell und das, wonach Ihr Versicherer und Ihre Enterprise-Kunden tatsächlich fragen.

Was ein Vulnerability Scan tatsächlich leistet​

Ein Vulnerability Scanner ist Software, die Ihre Systeme inventarisiert und die Ergebnisse mit Datenbanken bekannter Schwachstellen abgleicht – veröffentlichte CVEs, fehlende Patches, Fehlkonfigurationen, abgelaufene Zertifikate, offene Ports, die geschlossen sein sollten. Richten Sie ihn auf einen IP-Bereich, eine Domain oder ein Cloud-Konto, und wenige Stunden später erhalten Sie einen Bericht, der Befunde nach Schweregrad gruppiert, mit vorgeschlagenen Korrekturen, meist geordnet nach CVSS-Score.

Zwei Unterscheidungen sind wichtig, wenn Sie Scans planen und interpretieren:

Unauthentifizierte vs. authentifizierte Scans. Ein unauthentifizierter Scan sieht nur, was ein Außenstehender sieht: offene Ports, Service-Banner, TLS-Konfiguration. Ein authentifizierter Scan meldet sich mit Anmeldedaten an und kann Patch-Stände, lokale Konfiguration und installierte Software prüfen – deutlich tiefere Abdeckung. Authentifiziertes internes Scannen wurde 2025 unter PCI DSS ausdrücklich verpflichtend, und es ist der Modus, der den ungepatchten Server hinter Ihrer Firewall findet, den ein externer Scan nie sehen wird.

Externe vs. interne Scans. Externe Scans sondieren Ihre internetseitige Angriffsfläche: die Website, den E-Mail-Server, das VPN-Gateway, den Remote-Desktop-Port, den jemand während der Pandemie geöffnet und dann vergessen hat. Interne Scans laufen innerhalb des Netzwerks und sehen Workstations, Drucker, Dateifreigaben und den Buchhaltungsserver. Beide sind wichtig, weil Angreifer von außen eindringen und sich dann seitwärts im Inneren bewegen.

Scans haben drei strukturelle Grenzen, die Sie verstehen sollten, bevor Sie sich auf einen verlassen. Erstens kennen sie nur bekannte Schwachstellen – ein Scanner kann keinen Logikfehler finden, der einzigartig in Ihrer Webanwendung ist, weil dieser Fehler in keiner Datenbank existiert. Zweitens melden sie Möglichkeiten, nicht Beweise: Ein „kritischer" Befund kann sich in Ihrer Konfiguration als unerreichbar erweisen, weshalb Scan-Berichte den Ruf haben, Fehlalarme zu enthalten. Drittens verkettet ein Scan niemals Befunde so, wie es ein Angreifer tut. Drei „mittlere" Probleme – eine exponierte Login-Seite, Passwort-Wiederverwendung und ein Backup-Konto mit zu vielen Berechtigungen – können sich zu einer vollständigen Übernahme verbinden, die kein einzelner Befund vorhersagt. Diese Ketten zu finden ist die Aufgabe von Menschen.

Was ein Penetrationstest tatsächlich leistet​

Ein Penetrationstest ist ein kontrollierter, autorisierter Angriff auf Ihre Systeme, durchgeführt von Sicherheitsfachleuten, die automatisierte Tools mit manuellen Techniken kombinieren. Während ein Scan fragt „welche Schwachstellen existieren?", fragt ein Pen Test „welche davon können tatsächlich ausgenutzt werden, wie weit kann ein Angreifer kommen, und welcher geschäftliche Schaden entsteht?" Jeder Befund in einem guten Pen-Test-Bericht kommt mit Beweis – Screenshots, erfasste Daten oder eine Shell – plus einer Auswirkungsanalyse und priorisierten Behebungsschritten, geschrieben für die Menschen, die es beheben müssen.

Die meisten Engagements folgen einem standardmäßigen vierphasigen Prozess nach dem Vorbild von NIST SP 800-115: Planung und Aufklärung, Discovery-Scanning, Angriffsausführung und Berichterstellung. Die darüber gelegte Methodik hängt vom Ziel ab – OWASP-Testrichtlinien für Webanwendungen, PTES für allgemeine Engagements –, aber die Form ist dieselbe: Informationen sammeln, Schwachstellen finden, versuchen, sie innerhalb vereinbarter Regeln auszunutzen, und dann alles dokumentieren.

Sie wählen außerdem, wie viel die Tester im Voraus wissen, was sowohl Realismus als auch Preis bestimmt:

• Black-Box-Testing gibt dem Team keine Insider-Informationen und simuliert einen externen Angreifer. Am realistischsten und langsamsten, weil Tester abrechenbare Tage mit Aufklärung verbringen, die Sie ihnen kostenlos hätten übergeben können.
• White-Box-Testing übergibt Architekturdiagramme, Quellcode und Anmeldedaten und maximiert die Abdeckung pro Testtag. Es findet die meisten Probleme, ähnelt aber eher einem Insider als einem Fremden aus dem Internet.
• Grey-Box-Testing liegt in der Mitte – typischerweise ein Standard-Benutzerkonto und grundlegende Dokumentation. Für die meisten Kleinunternehmen ist das das beste Preis-Leistungs-Verhältnis: realistisch genug, um relevant zu sein, effizient genug, um es sich leisten zu können.

Ein Pen Test endet mit zwei Dingen, die ein Scan nie liefert: der Bestätigung, was tatsächlich ausnutzbar ist (wodurch Sie die anderen 200 Scanner-Befunde mit gutem Gewissen ignorieren können), und dem narrativen Bericht, den Ihr Auditor, Ihr Cyber-Versicherer und der Vendor-Fragebogen Ihres größten Interessenten alle sehen wollen.

Direktvergleich: Methode, Tiefe, Dauer und Ergebnis​

Die beiden Bewertungen unterscheiden sich in jeder Dimension, die für Budgetierung und Terminplanung relevant ist:

• Methode. Scans sind vollautomatisiert und laufen unbeaufsichtigt nach Zeitplan. Pen Tests sind per definitionem teilweise manuell – Tools übernehmen die Discovery, Menschen die Ausnutzung und Analyse.
• Breite vs. Tiefe. Ein Scan deckt eine breite Asset-Palette kostengünstig, aber oberflächlich ab. Ein Pen Test geht in die Tiefe bei einem definierten Umfang: eine Anwendung, ein Netzwerksegment, ein Cloud-Konto.
• Dauer. Ein Scan dauert Stunden bis einen Tag. Ein Pen Test für Kleinunternehmen läuft typischerweise ein bis zwei Wochen inklusive Berichterstellung.
• Ergebnis. Ein Scan erzeugt eine toolgenerierte, nach Schweregrad geordnete Liste. Ein Pen Test erzeugt einen von Beratern verfassten Bericht mit Nachweisen, Bewertungen der Geschäftsauswirkung und einer Executive Summary, die Sie einem Vorstand oder Versicherer vorlegen können.
• Erforderliche Kompetenz Ihrerseits. Fast jeder kann einen Scan planen. Ein Pen Test erfordert, dass Sie den Umfang definieren, Zugänge organisieren, Verantwortliche für Befunde zuweisen und den Retest terminieren, der bestätigt, dass die Korrekturen gewirkt haben.

Aus all dem folgt eine Reihenfolgeregel: erst scannen, dann beheben, dann Pen Test. Tester dafür zu bezahlen, fehlende Patches wiederzuentdecken, die ein Scanner für Pfennige aufgelistet hätte, ist die häufigste Art, wie Kleinunternehmen ein Sicherheitsbudget verschwenden.

Was jede Bewertung im Jahr 2026 kostet​

Vulnerability Scanning ist ein Abonnement oder ein kostenloses Tool. Tenable Nessus Professional, der gebräuchlichste Scanner für Kleinunternehmen, liegt bei etwa 4.800 US-Dollar pro Jahr für unbegrenzte IPs von einem einzigen Scanner; Nessus Essentials ist für begrenzte Nutzung kostenlos. Qualys' cloudbasiertes Scanning startet höher, im niedrigen Tausenderbereich pro Jahr für kleine Umgebungen. Greenbones OpenVAS bleibt kostenlos und leistungsfähig, erfordert aber echte Linux-Wartungszeit, die für die meisten kleinen Firmen – sobald Personalstunden gezählt werden – mehr kostet als eine kommerzielle Lizenz. Vollständig verwaltetes Scanning – ein Anbieter führt die Scans durch, filtert Fehlalarme heraus und übergibt Ihnen eine Aktionsliste – kostet typischerweise 5.000 bis 10.000 US-Dollar pro Jahr. Viele Unternehmen landen alles in allem im niedrigen dreistelligen Dollarbereich pro Monat.

Penetrationstests werden pro Engagement abgerechnet. Für ein Kleinunternehmen mit definiertem Umfang – eine Webanwendung, ein kleines Büronetzwerk, eine überschaubare API – kostet ein professioneller Test 5.000 bis 15.000 US-Dollar. Die meisten fokussierten Engagements für kleine und mittlere Unternehmen liegen zwischen 10.000 und 20.000 US-Dollar, mit einem branchenweiten Durchschnitt über alle Typen von nahezu 18.000 US-Dollar. Netzwerktests liegen am unteren Ende der Spanne; Webanwendungs- und API-Tests mit mehreren Benutzerrollen kosten mehr; alles mit compliance-tauglicher Berichterstattung (PCI DSS, SOC 2) berechnet zusätzliche Stunden für den Papierkram, unabhängig von der Größe der Umgebung.

Vier Dinge treiben ein Pen-Test-Angebot nach oben oder unten: Umfangsgröße (Hosts, Anwendungen, API-Endpunkte), Anwendungskomplexität (Benutzerrollen, Mandantenfähigkeit, Drittanbieter-Integrationen), Wissensmodell des Testers (Black-Box-Aufklärung kostet Tage, bevor das Testen überhaupt beginnt) und Berichtsanforderungen (ein Schreiben für Ihren Versicherer ist günstig; ein PCI-taugliches Nachweispaket ist es nicht). Die einzige beste Kostenkontrolle ist eine präzise Umfangserklärung: Nennen Sie die Ziele, nennen Sie, was tabu ist, und fügen Sie das Architekturdiagramm bei, statt Fremde dafür zu bezahlen, es rückwärts zu entwickeln.

Für die Budgetplanung ist ein vernünftiger Ausgangspunkt für Kleinunternehmen kontinuierliches Scanning für einige Tausend Dollar pro Jahr plus ein jährlicher Grey-Box-Pen-Test Ihres risikoreichsten Systems. Vergleichen Sie das mit der Alternative, die die Branche immer wieder misst: Ein volles Testjahr kostet für ein mittelständisches Unternehmen etwa 1 Prozent des durchschnittlichen Vorfalls.

Wie oft Sie jeweils durchführen sollten​

Scans: kontinuierlich, mindestens monatlich. Weil Scans günstig und automatisiert sind, ist die Häufigkeit nahezu kostenlos – viele Firmen scannen wöchentlich oder bei jedem Deployment. Scannen Sie mindestens monatlich, scannen Sie nach jeder wesentlichen Änderung (neuer Server, Firewall-Regeländerung, größeres Software-Update), und stellen Sie sicher, dass Ihre vierteljährlichen PCI-Scans tatsächlich stattfinden, wenn Kartendaten Sie in den Geltungsbereich bringen. Veraltete Scan-Ergebnisse sind kaum besser als keine Ergebnisse: Neue CVEs werden täglich veröffentlicht, und das Fenster zwischen Offenlegung und massenhafter Ausnutzung schrumpft immer weiter.

Pen Tests: jährlich, plus nach größeren Änderungen. Jährliches Testen ist die Branchennorm und die ausdrückliche Compliance-Untergrenze nach PCI DSS sowie den meisten Versicherungs- und Enterprise-Vendor-Anforderungen. Testen Sie früher nach, wenn sich die Angriffsfläche wesentlich ändert: eine neue kundenorientierte Anwendung, eine Cloud-Migration, eine Fusion, die zwei Netzwerke verbindet, oder ein erheblicher Vorfall anderswo in Ihrer Software-Lieferkette, der Ihren Stack betrifft. Und vereinbaren Sie den Retest immer im Voraus – ein kurzes Folgeengagement, oft inklusive oder rabattiert, in dem die Tester Ihre Korrekturen überprüfen, statt Sie behaupten zu lassen, sie hätten gewirkt.

Die Reihenfolge, die am wenigsten Geld verschwendet, sieht so aus: scannen, die kritischen und hohen Befunde beheben, mit einem erneuten Scan verifizieren, dann Pen Test. Die Tester verbringen ihre Tage dann mit den verketteten, logikbezogenen und konfigurationsbezogenen Problemen, die kein Scanner finden konnte, statt Ihnen dafür Rechnung zu stellen, zu bestätigen, dass der Druckserver noch Firmware von 2019 ausführt.

Die Compliance-Regeln, die die Wahl erzwingen​

Für viele Kleinunternehmen wird die Debatte Scan vs. Test von dem entschieden, der ihre Zahlungen abwickelt oder ihr Risiko zeichnet. Die am häufigsten anzutreffenden Regeln:

PCI DSS Requirement 11 ist die große für jeden, der Kartendaten verarbeitet. Die meisten kleinen Händler brauchen vierteljährliche externe Scans durch einen von PCI gelisteten Approved Scanning Vendor, interne Vulnerability Scans mindestens jährlich und nach wesentlichen Änderungen sowie – für SAQ-D-Händler und jeden, der Netzwerksegmentierung zur Reduzierung des Geltungsbereichs nutzt – jährliche Penetrationstests der Cardholder Data Environment und aller Segmentierungskontrollen. Beachten Sie die Entwicklung: PCI DSS Version 4 hat mehrere Testpunkte von Empfehlungen zu Pflichten gemacht, einschließlich authentifiziertem internen Scannen. Wenn Sie Karten annehmen und Ihren SAQ-Typ nicht seinen Testpflichten zugeordnet haben, tun Sie das, bevor Sie etwas kaufen.

SOC 2, HIPAA und Cyber-Versicherung sind weniger präskriptiv hinsichtlich der Methode, aber in der Praxis zunehmend konkret. SOC-2-Auditoren erwarten Nachweise für laufendes Vulnerability Management plus regelmäßige Penetrationstests; die von HIPAA geforderte Risikoanalyse wird routinemäßig mit demselben Paar erfüllt; und Cyber-Versicherungsanträge fragen heute üblicherweise, wann Ihr letzter Pen Test war, wobei einige Versicherer die Prämie danach bepreisen oder die Deckung ablehnen. Der Vendor-Security-Fragebogen eines Enterprise-Interessenten wird sowohl die Scan-Kadenz als auch die aktuellste Pen-Test-Executive-Summary abfragen – sie bereitzuhaben verkürzt Verkaufszyklen.

Die praktische Erkenntnis: Wenn eine Regel oder ein Vertrag eine bestimmte Bewertung nennt, ist diese Bewertung nicht optional, und die andere ersetzt sie nicht. Ein Stapel sauberer Scan-Berichte wird einen Auditor, der einen Pen Test verlangt hat, nicht zufriedenstellen, und ein Pen Test erfüllt nicht die Anforderung vierteljährlicher Scans in den anderen elf Monaten des Jahres.

Häufige Fehler, die das Budget verschwenden​

• Pen Testen vor dem Patchen. Ein 12.000-Dollar-Engagement gegen Systeme mit 300 ungepatchten Scanner-Befunden zu beauftragen, kauft Ihnen eine wunderschön geschriebene Liste von Patches. Erst scannen und beheben.
• Einen sauberen Scan als Sicherheitsbeweis behandeln. Ein Scanner meldet die Abwesenheit bekannter Probleme in seiner Datenbank, nicht die Anwesenheit von Sicherheit. Eigener Code, Business-Logic-Fehler und verkettete mittlere Befunde verstecken sich alle davor.
• Den Test weg vom echten Risiko scopen. Das alte Abrechnungsportal auszuschließen, „weil es nächstes Jahr ersetzt wird", garantiert nur, dass der Ersatz eine ungetestete Integration erbt. Angreifer respektieren Ihre Scope-Ausschlüsse nicht.
• Den Bericht abheften statt beheben. Befunde ohne Verantwortliche und Fristen sind Schubladenware. Weisen Sie jedem hohen und kritischen Befund eine verantwortliche Person zu, bevor das Debriefing endet, und tragen Sie Retest-Termine in den Kalender ein, während die Tester noch engagiert sind.
• Den Retest überspringen. Behebungen erweisen sich beim Retest routinemäßig als unvollständig – der Patch wurde auf einen Server angewendet, aber nicht auf seinen Zwilling. Der Retest ist der günstigste Teil des Engagements und der Teil, der beweist, dass der Rest es wert war.
• Den Papierkram vergessen. Versicherer und Auditoren fragen Monate später nach Berichten. Bewahren Sie den Bericht, das Scope-Schreiben und die Retest-Bestätigung zusammen mit Ihren Finanzunterlagen auf.

Ein praktischer Entscheidungsrahmen​

Beantworten Sie drei Fragen der Reihe nach:

1. Entscheidet eine Regel bereits für Sie? Nehmen Sie Karten an, speichern Sie Gesundheitsdaten, halten Sie einen SOC-2-Bericht oder tragen Sie eine Cyber-Versicherung mit Testgarantien? Ordnen Sie zunächst jede Verpflichtung ihrer erforderlichen Bewertung und Häufigkeit zu. Compliance-Punkte sind die Untergrenze, nicht die Obergrenze.

2. Haben Sie gescannt und gepatcht? Wenn nicht – oder nicht im letzten Quartal –, ist das Schritt eins, unabhängig davon, was Sie sonst noch kaufen. Richten Sie authentifiziertes Scannen innerhalb des Netzwerks und unauthentifiziertes Scannen außerhalb ein, arbeiten Sie die kritischen und hohen Warteschlangen auf null ab, und machen Sie die Kadenz zur Gewohnheit, bevor Sie Pen-Test-Geld ausgeben.

3. Was hat sich seit Ihrem letzten tiefen Blick geändert? Neue öffentliche Anwendung, Cloud-Migration, Büroumzug, Fusion oder einfach „hatten wir noch nie" deuten alle auf einen Grey-Box-Pen-Test des risikoreichsten Systems mit vereinbartem Retest hin. Keine größeren Änderungen und ein sauberer aktueller Test? Weiter scannen, weiter patchen und den nächsten Test für den Jahreszyklus aufheben.

Für ein typisches Kleinunternehmen, das sein Programm ausbaut, sehen die Stufen so aus. Stufe eins: monatliches Scannen plus zeitnahes Patchen – einige Tausend Dollar pro Jahr und der höchste verfügbare Schutz pro Dollar. Stufe zwei: einen jährlichen Grey-Box-Pen-Test des riskantesten Systems mit Retest hinzufügen und die Berichte dort ablegen, wo Versicherung und Vendor-Fragebögen sie finden. Stufe drei: kontinuierliches, an Deployments gekoppeltes Scannen, jährliche Pen Tests, die über Systeme rotieren, und gezielte Tests nach jeder größeren Änderung. Die meisten Leser dieses Blogs sollten sich fest auf Stufe zwei befinden; Stufe eins ist der Punkt, an dem Sie dieses Quartal beginnen, wenn Sie bei null anfangen.

Noch eine Verbindung, die in einen Finanzblog gehört: Jeder Dollar hier ist gewöhnliche Betriebsausgabe und verdient dieselben Bücher wie jede andere Betriebsausgabe. Bewertungsgebühren, Stunden von Behebungs-Dienstleistern, Scanner-Abonnements und Cyber-Versicherungsprämien sollten jeweils auf separate Konten laufen, damit Sie die vollen Kosten des Programms zum Verlängerungszeitpunkt sehen – und damit der Fragebogen des Versicherers nach einem Vorfall Antworten aus dem Hauptbuch erhält statt aus dem Gedächtnis. Ein Plain-Text-Eintrag genügt:

2026-10-14 * "Security vendor" "Annual grey-box pen test plus retest"
  Expenses:Professional-Services:Security  12000.00 USD
  Assets:Checking

Bewahren Sie das Engagement-Schreiben und den Abschlussbericht zusammen mit dem Transaktionsdatensatz auf. Wenn ein Interessent nach Ihrer aktuellsten Pen-Test-Zusammenfassung fragt oder Ihr Versicherer einen Nachweis kontinuierlichen Scannens verlangt, liegt der Beleg nur eine Suche von der Zahlung entfernt, die beweist, dass Sie ihn gekauft haben.

Halten Sie Ihre Sicherheitsausgaben von Anfang an organisiert​

Während Sie Scanning, Testing und Behebung ausbauen, ist die Pflege klarer Finanzunterlagen über das Programm das, was Sicherheitsausgaben in Verlängerungen, beantwortete Fragebögen und schnellere Reaktion auf Vorfälle verwandelt. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen vollständige Transparenz und Kontrolle über Ihre Finanzdaten gibt – keine Blackbox, kein Vendor-Lock-in. Starten Sie kostenlos und sehen Sie, warum Entwickler und Finanzfachleute auf Plain-Text-Buchhaltung umsteigen.