ISO 27001 nennt einen Penetrationstest nirgendwo wörtlich als Pflicht. Aber zwei Annex-A-Controls der Fassung 2022 — A.8.8 (Management technischer Schwachstellen) und A.8.29 (Sicherheitstests in Entwicklung und Abnahme) — plus die Erwartung der Auditierenden machen den Pentest zum De-facto-Standard-Nachweis. Bei DeepMantis beginnt ein solcher Test ab 890 €, und der Report ist audit-tauglich aufgebaut: jedes Finding mit reproduzierbarem Proof of Concept, kein Scanner-Output. Dieser Artikel sagt genau, was die Norm verlangt — und was nicht.
Verlangt ISO 27001 einen Penetrationstest?
Die ehrliche Antwort: nein, nicht wörtlich. Der Normtext von ISO/IEC 27001:2022 und der zugehörige Maßnahmenkatalog ISO/IEC 27002:2022 enthalten den Begriff „Penetrationstest" nicht als verpflichtende Anforderung. Wer dir etwas anderes erzählt, hat die Norm nicht gelesen.
Trotzdem führt fast jeder ISMS-Weg zum Pentest — über zwei Controls aus Annex A:2022. A.8.8 verlangt das Management technischer Schwachstellen, A.8.29 verlangt Sicherheitstests in Entwicklung und Abnahme. Die Umsetzungsleitlinien dazu stehen in ISO 27002:2022; eine gut aufbereitete Darstellung des Controls A.8.29 findest du bei ISMS.online. Beide Controls beschreiben sinngemäß das, was ein Pentest liefert — ohne das Wort zu benutzen.
Die Folge: Auditierende fragen nicht „Habt ihr einen Pentest gemacht?", sondern „Wie weist ihr nach, dass ihr technische Schwachstellen aktiv findet und sicherheitsrelevante Releases prüft?". Auf diese Frage ist ein signierter Pentest-Report die belastbarste Antwort. Seit der Übergangsfrist auf ISO 27001:2022 — für Neuzertifizierungen seit 2024 maßgeblich — gilt der aktualisierte Annex A mit genau diesen Control-IDs.
Welche Controls machen den Pentest zum Nachweis?
Zwei Controls aus Annex A:2022 sind hier relevant. Die folgende Tabelle bildet ab, was sie sinngemäß verlangen, was Auditierende dafür sehen wollen und wie ein Pentest das erfüllt. Die Control-Wortlaute sind paraphrasiert — der Normtext selbst ist kostenpflichtig; die offizielle Bezugsquelle ist die ISO-Seite zu 27001.
| Control (Annex A:2022) | Was es sinngemäß verlangt | Was Auditierende sehen wollen | Wie ein Pentest das erfüllt |
|---|---|---|---|
| A.8.8 — Management technischer Schwachstellen | Schwachstellen in eingesetzten Systemen zeitnah identifizieren, bewerten und behandeln | Nachweis, dass du Schwachstellen aktiv suchst — nicht nur abwartest | Ein Pentest belegt mit Exploit pro Finding, dass du aktiv suchst statt nur einen Scanner laufen zu lassen |
| A.8.29 — Sicherheitstests in Entwicklung und Abnahme | Sicherheitsanforderungen während Entwicklung und vor Abnahme testen | Signierte Testberichte für größere Releases und Architekturänderungen | Ein Pentest pro Major-Release liefert genau diesen dokumentierten Abnahme-Nachweis |
A.8.29 ist in der Fassung 2022 eine Konsolidierung: Die alten Controls A.14.2.8 (Sicherheitstests von Systemen) und A.14.2.9 (Systemabnahmetests) aus ISO 27001:2013 wurden zu einem Control zusammengeführt. Die Aufbereitung bei ISMS.online beschreibt, dass Sicherheitstests in den gesamten Entwicklungszyklus integriert und vor der Abnahme dokumentiert sein müssen. In der Praxis heißt das: Wer ein sicherheitsrelevantes Release oder eine Architekturänderung ausliefert, sollte einen Testbericht vorlegen können.
A.8.8 zielt auf den laufenden Betrieb. Hier ist der Unterschied zwischen einem Scan und einem Pentest entscheidend — dazu gleich mehr.
Was akzeptieren Auditierende tatsächlich?
Nicht jeder Sicherheitstest zählt als Nachweis. Auditierende prüfen drei Eigenschaften, bevor ein Report als Evidenz für A.8.8 oder A.8.29 durchgeht: Ist der Test unabhängig durchgeführt? Wird jedes Finding belegt, nicht nur gemeldet? Liegt ein signierter, datierter Bericht vor?
Ein reiner Schwachstellen-Scan erfüllt diese Kriterien nicht. Ein Scanner findet bekannte Muster und produziert eine Liste potenzieller Schwachstellen — ohne zu verifizieren, ob sie tatsächlich ausnutzbar sind. Genau diese Verifikation ist aber der Kern der Nachweisführung. Ein Finding ohne Exploit-Beleg ist ein Alert, kein bestätigtes Risiko.
Was im Audit zählt, lässt sich auf drei Punkte verdichten:
- Unabhängigkeit: Der Test wird von einer Stelle durchgeführt, die nicht am Aufbau oder Betrieb des Systems beteiligt war — extern oder klar getrennt intern.
- Proof of Concept pro Finding: Jede gemeldete Schwachstelle ist reproduzierbar belegt, nicht nur aus einem Scan abgeleitet.
- Signierter, datierter Report: Der Bericht nennt Scope, Methodik, Findings und Zeitpunkt — und ist als Dokument vorlegbar.
DeepMantis liefert genau dieses Profil: einen audit-tauglichen PDF-Report mit reproduzierbarem Proof of Concept pro Finding, durchgeführt als externer, unabhängiger Test. Die Verifikation läuft in isolierten Browser-Instanzen pro Finding — der Bericht enthält den Nachweis, nicht nur die Behauptung.
Wie oft musst du für ISO 27001 testen?
Eine feste Frequenz schreibt die Norm nicht vor. Aus A.8.8 und A.8.29 ergibt sich aber ein klares Muster: testen bei größeren Releases und Architekturänderungen — und mindestens einmal jährlich, um den laufenden Betrieb abzudecken. Auditierende erwarten, dass dein ISMS nicht auf einem zwei Jahre alten Testbericht ruht.
Zwei Auslöser solltest du fest einplanen:
- Ereignisbasiert: vor der Abnahme jedes sicherheitsrelevanten Major-Release oder nach einer Architekturänderung — das ist die direkte Umsetzung von A.8.29.
- Periodisch: mindestens jährlich für die produktiven Systeme — das deckt A.8.8 im laufenden Betrieb ab.
Wenn deine Organisation zusätzlich NIS2-reguliert ist, überlappen sich die Anforderungen. NIS2 verlangt regelmäßige Bewertung der Wirksamkeit technischer Maßnahmen; ein Pentest-Zyklus erfüllt beide Regelwerke gleichzeitig. Die Details dazu stehen im Schwesterartikel zur NIS2-Pentest-Pflicht — ein gemeinsamer Testplan spart Aufwand, wenn beide Normen gelten.
Für Teams, die wöchentlich shippen, ist ein jährlicher Snapshot zu grob. Kontinuierliches Testen hält den Nachweis aktuell, ohne pro Durchlauf neue Personentage zu kosten.
Was kostet ein ISO-27001-tauglicher Pentest?
Die Preise unterscheiden sich nicht von anderen Pentests — entscheidend ist, dass der Report audit-tauglich ist. Eine vollständige Aufschlüsselung der Marktspannen und Tagessätze findest du im Artikel zu Pentest-Kosten; hier nur die Einordnung für ISO 27001.
Manuelle Anbieter berechnen einen audit-tauglichen Report oft als 1–3 zusätzliche Personentage obendrauf. Bei DeepMantis ist der audit-taugliche Report in jedem Tier enthalten — kein Aufpreis für die Form, die das Audit verlangt. Die öffentliche Preisliste beginnt bei 890 € für eine Single-Surface-Anwendung und reicht bis 7.500 € für ein verteiltes System mit regulierten Daten. Jedes Tier liefert den Proof of Concept pro Finding, der A.8.8 und A.8.29 als Evidenz erst tragfähig macht.
Wichtig für die Scope-Planung: DeepMantis testet Webanwendungen und APIs. Binary Exploitation, Mobile-Pentests, Social Engineering und physische Zugangstests führt die Plattform bewusst nicht durch. Wenn dein ISMS-Scope diese Bereiche umfasst, brauchst du dafür einen ergänzenden manuellen Test.
Häufige Fragen zu ISO 27001 und Pentest
Reicht ein Schwachstellen-Scan für ISO 27001?
Nein. Ein Scan listet potenzielle Schwachstellen, verifiziert aber nicht, ob sie ausnutzbar sind. A.8.8 verlangt aktives Schwachstellenmanagement, und Auditierende wollen den Nachweis sehen, dass du Schwachstellen findest und bewertest — nicht nur einen Scanner-Report ablegst. Der Exploit-Beleg pro Finding ist der Unterschied zwischen einem Alert und einem bestätigten Risiko.
Ist ein Pentest für die ISO-27001-Zertifizierung zwingend?
Wörtlich nein, faktisch fast immer ja. Die Norm nennt keinen Pentest, aber A.8.8 und A.8.29 lassen sich ohne dokumentierte Sicherheitstests kaum belegen. Theoretisch könntest du andere Nachweise führen — in der Praxis ist ein signierter Pentest-Report der Weg des geringsten Widerstands im Audit.
Welche ISO-27001-Controls betreffen Penetrationstests?
A.8.8 (Management technischer Schwachstellen) und A.8.29 (Sicherheitstests in Entwicklung und Abnahme) aus Annex A:2022. A.8.29 konsolidiert die früheren Controls A.14.2.8 und A.14.2.9 aus der Fassung 2013. Die Umsetzungsleitlinien stehen in ISO 27002:2022.
Genügt ein interner Pentest als Nachweis?
Möglich, aber riskant. Auditierende werten Unabhängigkeit als Qualitätskriterium — die testende Stelle sollte nicht am Aufbau oder Betrieb des geprüften Systems beteiligt gewesen sein. Ein externer, unabhängiger Test — manuell oder autonom — liefert verwertbarere Evidenz als eine interne Prüfung durch dasselbe Team, das das System gebaut hat.
Stand Juni 2026. Control-IDs und Wortlaute paraphrasiert nach ISO/IEC 27001:2022 Annex A und den Umsetzungsleitlinien von ISO/IEC 27002:2022; der offizielle Normtext ist kostenpflichtig. Methodik und Scope-Grenzen von DeepMantis sind auf der Security-Seite dokumentiert.
