Wie oft sollten Sie einen Penetrationstest durchführen lassen?
Kurzantwort: Mindestens einmal alle 12 Monate und erneut nach jeder wesentlichen Änderung an den Systemen im Scope. Diese zweiteilige Regel, Kalender plus Änderung, bildet die praktische Untergrenze für jedes Framework, mit dem Käufer konfrontiert werden. Nur PCI DSS schreibt dies als verbindliche Anforderung vor. SOC 2 und ISO 27001 nennen überhaupt keine Frequenz; sie sind risikobasiert, und ein jährlicher Turnus ist schlicht die Frequenz, die Auditoren erwarten. Wenn Ihre Umgebung jede Woche Code ausliefert oder hochsensible Daten verarbeitet, ist einmal im Jahr eine Untergrenze, die es zu erreichen gilt, kein Ziel, das man anstrebt.
Die Frage wird gestellt, weil „jährlich“ wie eine Regel klingt, die von offizieller Stelle vorgegeben wurde. Für einen Standard trifft das zu. Für die anderen ist es eine Konvention, die sich um risikobasierte Formulierungen herum entwickelt hat. Zu wissen, was davon zutrifft, bewahrt Sie sowohl vor unnötigen Ausgaben als auch vor Überraschungen im Audit. Hier ist, was die einzelnen Standards tatsächlich besagen.
Die Kurzfassung nach Framework
Vier Gründe veranlassen die meisten Käufer zu einem Test: ein Kreditkartenabwickler, ein SOC 2-Bericht, ein ISO-Zertifikat oder ein Formular der Cyberversicherung. Nur einer davon schreibt eine konkrete Zahl vor.
| Treiber | Nennt eine Frequenz? | Etablierte Frequenz bei Käufern |
|---|---|---|
| PCI DSS v4.0 | Ja, präskriptiv | Mindestens alle 12 Monate und nach wesentlichen Änderungen |
| SOC 2 (AICPA) | Nein, risikobasiert | Jährlich, innerhalb des Type 2-Beobachtungszeitraums, nach Auditoren-Konvention |
| ISO/IEC 27001 | Nein, risikobasiert | Jährlich ist üblich; Frequenz wird durch Ihre Risikobeurteilung festgelegt |
| Cyberversicherung | Variiert je nach Versicherer | Oft jährliche Bestätigung; lesen Sie die jeweilige Police |
| Keinerlei Vorgabe | N/A | Jährliche Untergrenze, mehr bei schnellen Änderungen oder hochsensiblen Daten |
Die zweiteilige Regel: Kalender plus Änderung
Jede fundierte Antwort zur Frequenz besteht eigentlich aus zwei kombinierten Regeln, und das Auslassen einer davon hinterlässt eine Lücke.
Der Kalender-Teil existiert, weil ein Penetrationstest eine Momentaufnahme ist. Er beschreibt die Systeme im Scope während des Testzeitraums im Hinblick auf die Techniken in den Rules of Engagement. Neue Schwachstellenklassen werden entdeckt, neue Exploits veröffentlicht und Ihr Team stellt weiterhin neuen Code bereit. Ein jährlicher Test setzt diese Uhr zurück, bevor das Bild zu veraltet ist.
Der Änderungs-Teil existiert, weil der Kalender nicht weiß, wann Sie Ihren Authentifizierungs-Flow neu gebaut oder eine neue API freigeschaltet haben. Ein Test aus dem März sagt nichts über den Dienst aus, den Sie im Juni gestartet haben. Deshalb kombiniert jedes ernstzunehmende Framework „mindestens alle 12 Monate“ mit „und nach jeder wesentlichen Änderung“. Und das ist der Teil, den Käufer am häufigsten vernachlässigen.
Was als wesentliche Änderung gilt
PCI DSS überlässt die Definition und Begründung von „wesentlich“ der jeweiligen Organisation, aber die Branchenbeispiele sind eindeutig. Betrachten Sie jeden dieser Punkte als Auslöser für einen Test des betroffenen Scopes, unabhängig davon, wann der letzte jährliche Test stattfand:
- Ein großes Anwendungs-Release oder ein Neuschreiben einer sicherheitsrelevanten Komponente.
- Ein neuer über das Internet erreichbarer Dienst, eine Subdomain oder eine API, die die Angriffsfläche vergrößert.
- Eine Cloud-Migration oder eine wesentliche Änderung der Cloud-Architektur oder des IAM.
- Eine Änderung an der Authentifizierung, dem Single Sign-On oder dem Session-Handling.
- Eine Änderung der Netzwerksegmentierung, der Firewall-Regeln oder der Isolierung von Umgebungen.
- Eine Übernahme oder eine neue Drittanbieter-Integration, die die Angriffsfläche eines anderen Unternehmens in Ihre integriert.
Der gemeinsame Nenner ist die Exposition. Wenn die Änderung beeinflusst, was von außen erreichbar ist, wie Identitäten nachgewiesen werden oder wo eine Vertrauensgrenze verläuft, bildet der letzte Test nicht mehr die Realität ab.
Was die einzelnen Frameworks tatsächlich besagen
PCI DSS v4.0 ist der präskriptive Standard. Anforderung 11.4 verlangt interne und externe Penetrationstests mindestens einmal alle 12 Monate sowie nach jedem wesentlichen Upgrade oder jeder wesentlichen Änderung der Infrastruktur oder Anwendung nach einer dokumentierten Methodik, die auf einem branchenweit anerkannten Ansatz wie NIST SP 800-115 basiert. Wenn Segmentierung genutzt wird, um Systeme außerhalb der Karteninhaber-Datenumgebung zu halten, wird diese Segmentierung bei Händlern mindestens alle 12 Monate und bei Dienstanbietern mindestens alle 6 Monate getestet, und Feststellungen werden nach der Behebung erneut getestet. Das ist die klarste Antwort auf die Frage nach dem „Wie oft“, die Ihnen eines dieser Frameworks gibt.
SOC 2 nennt keine Frequenz. Die AICPA Trust Services Criteria sind als Ziele formuliert, nicht als Zeitpläne, sodass es keine Zeile gibt, die einen jährlichen Test vorschreibt. In der Praxis erwarten Auditoren jedoch mindestens einmal jährlich einen Test, der zeitlich in den Type 2-Beobachtungszeitraum fällt. Welche Kriterien genau auf Tests verweisen, haben wir im Detail beschrieben unter erfordert SOC 2 einen Penetrationstest?
ISO/IEC 27001 ist explizit risikobasiert. Der Standard fordert das Management technischer Schwachstellen sowie die Überprüfung von Kontrollen und knüpft die Frequenz an Ihre eigene Risikobeurteilung und Ihren Risikobehandlungsplan statt an einen festen Kalender. Zertifizierte Organisationen einigen sich meist auf jährliche Tests als vertretbare Baseline, wobei Systeme mit höherem Risiko häufiger getestet werden. Die Zahl müssen Sie selbst begründen, sie wird Ihnen nicht vorgegeben.
Cyberversicherungen hängen vom jeweiligen Versicherer ab. Einige Policen fragen, ob Sie regelmäßig testen, und betrachten „jährlich“ als erwartete Antwort; andere fragen gar nicht danach. Der beste Weg ist, den konkreten Antrag zu lesen, anstatt Mutmaßungen anzustellen. Genau darum geht es in brauche ich einen Pentest für die Cyberversicherung?
Wann einmal im Jahr nicht ausreicht
Jährlich ist eine Untergrenze, und manche Umgebungen entwachsen ihr schnell. Testen Sie häufiger, wenn:
- Sie kontinuierlich Code ausliefern. Wenn sich die Produktion wöchentlich ändert, ist ein jährlicher Test elf Monate des Jahres veraltet. Teams in dieser Lage gehen zu Tests pro Release auf kritischen Pfaden oder zu einem Modell des kontinuierlichen Testens über und behalten den umfassenden jährlichen Test als Anker bei.
- Sie hochsensible Daten verarbeiten. Zahlungsdaten, Gesundheitsdaten und große Mengen personenbezogener Daten erhöhen den Preis von Fehlern, was häufigere Tests der Systeme rechtfertigt, die mit ihnen in Berührung kommen.
- Sie gerade einen Schreckmoment hatten. Nach einem Vorfall, einem Beinahe-Fehltritt oder einer kritischen Schwachstelle in einer Komponente, auf die Sie angewiesen sind, ist ein erneuter Test des betroffenen Bereichs günstiger als die Annahme, dass der Patch sauber war.
Nichts davon ersetzt den jährlichen Test. Es baut darauf auf, denn eine vollständige, klar abgegrenzte Überprüfung durch erfahrene Experten besitzt eine ganz andere Tiefe als ein gezielter Re-Test einer einzelnen Änderung.
Der Fehler: Das Datum als Ergebnis zu betrachten
Der häufigste Fehler bei der Frequenz besteht darin, den Pentest wie ein Zertifikat mit Ablaufdatum zu behandeln, ihn am letzten gültigen Tag durchzuführen und nichts von dem umzusetzen, was man gelernt hat. Ein Test, den Sie nur beauftragen, um ein Häkchen zu setzen, wird tendenziell so eng definiert, dass er bestanden wird, und bleibt so oberflächlich, dass die tatsächlichen Einfallstore eines Angreifers übersehen werden. Das Datum auf dem Bericht stellt den Auditor zufrieden, erschwert aber keinen tatsächlichen Einbruch.
Zwischen den geplanten Tests verändert sich Ihre Angriffsfläche ständig, egal ob Sie hinsehen oder nicht: eine vergessene Subdomain, ein Dienst, der niemals öffentlich hätte sein dürfen, Zugangsdaten in einem Datenleck. Ihre externe Angriffsfläche kontinuierlich zu kennen, ist die kostengünstige Ergänzung zur periodischen Tiefe und unterscheidet sich grundlegend vom Kauf eines Pentests. Wenn Sie noch herausfinden müssen, welchen Dienst Sie überhaupt benötigen, zieht Check, Scan oder vollständiger Pentest? die Grenze.
Wie oft sollten Sie einen Penetrationstest durchführen lassen? Schnelle Antworten
Wie oft sollten Sie einen Penetrationstest durchführen lassen?
Mindestens einmal alle 12 Monate und erneut nach jeder wesentlichen Änderung an den Systemen im Scope. Diese zweiteilige Regel ist die praktische Untergrenze für alle relevanten Standards. Schnelllebige Umgebungen oder solche mit hochsensiblen Daten sollten häufiger testen, bis hin zu Tests pro Release oder kontinuierlich.
Schreibt PCI DSS jährliche Penetrationstests vor?
Ja. PCI DSS v4.0 Anforderung 11.4 verlangt interne und externe Penetrationstests mindestens einmal alle 12 Monate sowie nach jeder wesentlichen Infrastruktur- oder Anwendungsänderung. Wo Segmentierung die Karteninhaber-Datenumgebung isoliert, wird die Segmentierung bei Händlern mindestens alle 12 Monate und bei Dienstanbietern mindestens alle 6 Monate getestet.
Wie oft verlangen SOC 2 und ISO 27001 einen Pentest?
Keines von beiden nennt eine feste Frequenz. Beide sind risikobasiert: SOC 2 überlässt den Nachweis Ihrem Auditor und ISO 27001 knüpft Tests an Ihre Risikobeurteilung. In der Praxis hat sich ein jährlicher Rhythmus als von Auditoren erwarteter Standard etabliert, der zeitlich in den SOC 2 Type 2-Beobachtungszeitraum fällt.
Wann sollten Sie außerhalb des jährlichen Zyklus testen?
Nach jeder wesentlichen Änderung: ein großes Release, ein neuer über das Internet erreichbarer Dienst oder eine neue Subdomain, eine Cloud-Migration, eine Änderung an der Authentifizierung oder beim SSO, eine Netzwerk- oder Segmentierungsänderung oder eine Übernahme. Der letzte Test beschrieb die Umgebung nur so, wie sie an diesem Tag war.
Quellen
- PCI Security Standards Council, PCI DSS v4.0 Anforderung 11.4 (Methodik für Penetrationstests, Frequenz und Segmentierungstests).
- AICPA Trust Services Criteria (SOC 2), formuliert als risikobasierte Ziele ohne feste Testfrequenz.
- ISO/IEC 27001, risikobasiertes Management technischer Schwachstellen und Überprüfung von Kontrollen.
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, zitiert als anerkannte Methodik.
Weiterführende Lektüre
- Erfordert SOC 2 einen Penetrationstest?
- Brauche ich einen Pentest für die Cyberversicherung?
- Wie viel kostet ein Penetrationstest?
Lassen Sie den jährlichen Termin nicht den einzigen Blick sein.
Unser $100-Check zeigt, was ein Angreifer heute von außen sieht, inklusive Nachbesprechung durch einen erfahrenen Operator. Er ist die kostengünstige Ergänzung zu einem periodischen Pentest, kein Ersatz, und wir sagen Ihnen ehrlich, was Sie wirklich benötigen.
Buchen Sie einen $100-Check