Pen-Test-Pflicht nach ISO/IEC 27001:2022 Annex A: Was wirklich gefordert ist
ISO/IEC 27001:2022 nennt den Penetrationstest nicht wörtlich, fordert ihn aber über Annex A 8.8, 8.29 und 5.36 mittelbar. Wir zeigen, welche Belege ein Auditor erwartet und wie die Pflicht operativ umsetzbar wird.
ISO/IEC 27001:2022 wurde am 25. Oktober 2022 veröffentlicht; die Übergangsfrist endet am 31. Oktober 2026 (IAF MD 26). Der Standard erwähnt den Begriff Penetrationstest im normativen Teil nicht, verlangt aber über Annex A 8.8 (Verwaltung technischer Schwachstellen), 8.29 (Sicherheitstests in Entwicklung und Abnahme) und 5.36 (Konformität mit Richtlinien) eine technische Wirksamkeitsprüfung. Auditoren erwarten dafür in der Praxis einen Pen-Test, Vulnerability-Scan oder Red-Team-Übung.
Wer mit ISMS-Erstzertifizierung oder Re-Audit konfrontiert ist, steht vor einer konkreten Beweispflicht: Welcher Test, in welcher Tiefe, in welchem Turnus, mit welchem Bericht? Dieser Beitrag klärt die rechtliche Lage, ordnet die einschlägigen Controls, zeigt die Mindesterwartung an Reports und beschreibt, wie CIVAC als Compliance-Plattform und Officer-as-a-Service Schwachstellenmanagement und Audit-Nachweise zusammenführt. Bestellurkunde, unterschrieben, abgelegt, belegbar.
Auf einen Blick
- ISO/IEC 27001:2022 verlangt keinen Pen-Test wörtlich, aber Annex A 8.8, 8.29 und 5.36 machen ihn faktisch zur Nachweisgrundlage.
- Auditoren erwarten Bericht, Scope-Dokument, Risikobewertung und nachverfolgte Maßnahmen, nicht nur das PDF des Dienstleisters.
- CIVAC hinterlegt Pen-Test-Berichte, CVE-Bewertung und Maßnahmenplan im Workspace, sodass Annex A 8.8 und 8.29 belegbar bleiben.
Was ISO/IEC 27001:2022 zum Pen-Test wirklich sagt
Der normative Teil der ISO/IEC 27001:2022 nennt keine Pen-Test-Pflicht, sondern verlangt in Klausel 9.1 die Überwachung und Messung der Informationssicherheitsleistung. Daraus leitet sich die Pflicht ab, die Wirksamkeit technischer Maßnahmen objektiv nachzuweisen. Ein dokumentierter Penetrationstest ist hierfür der branchenübliche Beleg.
Annex A der 27001:2022 wurde gegenüber der Fassung 2013 von 114 auf 93 Controls verschlankt. Drei Controls sind für die Pen-Test-Diskussion zentral: 8.8 (Management technischer Schwachstellen), 8.29 (Sicherheitstests in Entwicklung und Abnahme) und 5.36 (Konformität mit Sicherheitsrichtlinien, Regeln und Standards). Alle drei verlangen geprüfte Wirksamkeit, nicht nur dokumentierte Absicht.
Die zugehörige Implementierungsanleitung ISO/IEC 27002:2022 wird hier deutlicher und benennt Penetrationstests explizit als anerkannte Methode. Auditoren ziehen die 27002 als Auslegungsmaßstab heran, auch wenn sie selbst nicht zertifizierungspflichtig ist.
In der Praxis bedeutet das: Ohne strukturierten Schwachstellen-Scan plus regelmäßigen Pen-Test bleibt der Nachweis lückenhaft. Ein reiner Dienstleisterbericht ohne Risikobewertung und Maßnahmenverfolgung im ISMS genügt nicht.
Die Pflicht ist damit mittelbar, aber operativ bindend. Wer als Informationssicherheitsbeauftragter die Annex-A-Erklärung der Anwendbarkeit (SoA) unterschreibt, übernimmt die Beweislast gegenüber dem Zertifizierer und der eigenen Geschäftsleitung.
Audit-fest, dokumentiert, Annex-A-fest. Mehr ist es technisch nicht. Weniger reicht nicht.
Annex A 8.8, 8.29 und 5.36 im Klartext
Control 8.8 (Management of Technical Vulnerabilities) verlangt einen geregelten Prozess zur Identifikation, Bewertung und Behandlung technischer Schwachstellen. Vulnerability-Scanning ist Grundlage, Pen-Test die vertiefende Wirksamkeitsprüfung. Der Zyklus muss dokumentiert sein, inklusive CVSS-Bewertung, Verantwortlicher und Reaktionsfrist.
Control 8.29 (Security Testing in Development and Acceptance) richtet sich an Eigenentwicklungen und gekaufte Systeme vor Produktivsetzung. Pen-Tests in Staging-Umgebungen, statische und dynamische Code-Analyse sowie Abnahmekriterien gehören hierher. Wer Software ohne Sicherheitstest live nimmt, verstößt unmittelbar.
Control 5.36 (Compliance with Policies, Rules and Standards) verlangt die regelmäßige Überprüfung der Einhaltung interner und externer Vorgaben. Ein Pen-Test ist hier ein zentraler Mechanismus, weil er die tatsächliche Härtung gegen die deklarierte Sicherheitsleitlinie spiegelt.
Daneben wirken Controls 8.16 (Monitoring), 8.23 (Web-Filtering) und 8.28 (Secure Coding) flankierend. Auditoren prüfen, ob die Pen-Test-Findings in die Risikobehandlungsplanung nach Klausel 6.1.3 zurückfließen und nicht im Anhang eines E-Mail-Verkehrs verschwinden.
Wichtig ist die Konsistenz mit dem Statement of Applicability: Wer Control 8.8 als anwendbar erklärt, muss den Prozess auch belegen. Eine ausgeschlossene Anwendbarkeit (Exclusion) ist nur mit nachvollziehbarer Begründung möglich.
Praktisch heißt das, der Bericht des Dienstleisters ist nur ein Baustein. Ergänzend braucht es Scope, Genehmigung, Risikoanalyse, Behandlungsplan und Nachprüfung.
Welche Tests in welcher Tiefe gelten als ausreichend
Der Markt unterscheidet drei Tiefenstufen. Vulnerability-Scans (automatisiert, breit, oberflächlich) liefern eine Bestandsaufnahme bekannter CVE und sind monatlich bis vierteljährlich vorgesehen. Pen-Tests (manuell, fokussiert, exploit-orientiert) prüfen Angriffspfade und werden mindestens jährlich oder bei wesentlichen Änderungen erwartet.
Red-Team-Übungen (Szenario-basiert, mehrwöchig, gegen ein Schutzziel) sind die anspruchsvollste Form und für regulierte Sektoren wie Finanzdienstleister oder KRITIS-Betreiber relevant. Die TIBER-DE-Methodik der Bundesbank gilt hier als anerkannter Referenzrahmen.
Für ISO/IEC 27001:2022 reicht in den meisten Branchen die Kombination aus regelmäßigem Scan und mindestens jährlichem externem Pen-Test der schutzbedürftigen Systeme. Welche Systeme schutzbedürftig sind, ergibt sich aus der Risikoanalyse, nicht aus dem Budget.
Auditoren bewerten neben dem Test die Reaktion: Wurden kritische Findings innerhalb der definierten SLA geschlossen? Sind Restrisiken durch das Management akzeptiert? Liegt ein Re-Test der behobenen Schwachstellen vor?
Der Zyklus muss in der Sicherheitsleitlinie verankert sein. Häufige Praxis: Scan monatlich, externer Pen-Test jährlich, Re-Test nach Major-Release. Wer NIS-2-betroffen ist, sollte den Zyklus an die NIS-2-Pflichten in Deutschland koppeln.
Ein dünner einseitiger Bericht ohne Methodik genügt nicht. Erwartet wird OWASP-Top-10-Abdeckung, OSSTMM- oder PTES-Methodik und nachvollziehbare Schwere-Einstufung.
Was der Pen-Test-Bericht enthalten muss
Ein audit-fester Pen-Test-Bericht beginnt mit dem Scope-Dokument: Welche IP-Bereiche, Anwendungen, Schnittstellen, Cloud-Konten? Welche Tests sind erlaubt, welche ausgeschlossen? Diese Rules of Engagement müssen vom Auftraggeber unterzeichnet sein, idealerweise mit Bezug auf § 202c StGB und § 303a/b StGB.
Es folgt die Methodik. Üblich sind Black-Box, Grey-Box oder White-Box, kombiniert mit OWASP-Web-Security-Testing-Guide für Webanwendungen und PTES für Infrastruktur. Der Bericht muss die gewählte Methodik benennen und begründen, warum sie für den Scope angemessen ist.
Findings werden mit CVSS 3.1 oder 4.0 bewertet, jeweils mit Base-, Temporal- und Environmental-Score. Eine reine Ampel ohne CVSS reicht nicht für die Risikobehandlung nach Klausel 6.1.3 der 27001:2022.
Jedes Finding braucht eine technische Beschreibung, einen Proof-of-Concept, eine Empfehlung und eine geschätzte Restrisiko-Bewertung nach Behebung. Screenshots sind hilfreich, dürfen aber keine Echtdaten enthalten, andernfalls drohen Konflikte mit Art. 32 DSGVO.
Der Management-Summary muss für Nicht-Techniker lesbar sein, weil die Geschäftsleitung Restrisiken akzeptieren muss. Ein abschließender Maßnahmenplan mit Verantwortlichen, Fristen und Re-Test-Datum gehört in das ISMS, nicht in den Postausgang.
Der Prüfer ruft an, der Nachweis liegt bereit. Vollständig, methodisch, mit Re-Test.
Wer beauftragt, wer haftet, wer dokumentiert
Auftraggeber ist die Geschäftsleitung, faktisch beauftragt wird durch den ISB oder CISO. Die Bestellurkunde des ISB sollte die Befugnis zur Beauftragung externer Sicherheitstests ausdrücklich umfassen, sonst entsteht eine Lücke zwischen Verantwortung und Mandat.
Haftung trifft im Außenverhältnis das Unternehmen, im Innenverhältnis können Geschäftsführer nach § 43 GmbHG persönlich in die Pflicht genommen werden, wenn fahrlässig auf wesentliche Tests verzichtet wurde. Für NIS-2-betroffene Unternehmen verschärft § 38 NIS2UmsuCG-E diese Linie zusätzlich.
Der Dienstleister haftet vertraglich nach BGB-Werkvertragsrecht, in der Regel begrenzt auf das Auftragsvolumen. Wer einen Pen-Test als reine Compliance-Übung beauftragt, kauft sich kein Sicherheitsniveau, sondern eine Momentaufnahme.
Die Datenschutzfolgenabschätzung nach Art. 35 DSGVO ist zu prüfen, sobald personenbezogene Daten im Test-Scope liegen. Ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ist Standard. Wer in der Cloud testet, braucht zusätzlich die Genehmigung des Hyperscalers (AWS, Azure, GCP).
Dokumentationspflichtig sind Beauftragung, Genehmigung, Bericht, Risikoakzeptanz, Re-Test und das Update des Statement of Applicability. Lückenhafte Dokumentation ist im Audit der häufigste Befund, nicht fehlende Tests.
CIVAC hält diese Kette in einem Workspace zusammen, sodass externer Datenschutzbeauftragter und ISB dieselben Belege referenzieren.
Schnittstellen zu NIS-2, DORA und BSI-Grundschutz
Die NIS-2-Richtlinie (Art. 21 Abs. 2 lit. f) verlangt explizit Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen. Penetrationstests sind die naheliegende Methode. Wer ISO/IEC 27001:2022 und NIS-2 parallel umsetzt, kann denselben Test für beide Nachweise nutzen, sofern Scope und Tiefe abgestimmt sind.
DORA (Verordnung 2022/2554) verschärft die Anforderung für den Finanzsektor: Threat-Led Penetration Tests (TLPT) sind ab 2026 für bedeutende Institute verpflichtend und an die TIBER-EU-Methodik gekoppelt. Frequenz: mindestens alle drei Jahre, plus zusätzliche Tests bei wesentlichen Änderungen.
BSI IT-Grundschutz adressiert Pen-Tests in den Bausteinen DER.1 (Detektion) und OPS.1.1.6 (Software-Tests). Wer nach Grundschutz arbeitet, findet hier konkretere Prüftiefen als in ISO/IEC 27001:2022. Eine kombinierte Zertifizierung ist möglich, erfordert aber sorgfältige Abbildung der Anforderungen.
KRITIS-Betreiber nach § 8a BSIG müssen die Wirksamkeit ihrer Sicherheitsmaßnahmen alle zwei Jahre nachweisen. Pen-Tests fließen regelmäßig in diesen Nachweis ein, ergänzt durch organisatorische Audits.
Branchenstandards wie B3S Krankenhaus, BAIT, VAIT und KAIT verschärfen die Anforderung für ihre Sektoren weiter. Wer in mehreren Regimen liegt, sollte Scope, Methodik und Berichtsformat so wählen, dass ein Test mehrere Nachweise bedient.
Doppelarbeit kostet Geld, mehr aber Vertrauen. Mehrfachnutzung ist erlaubt und erwünscht, wenn dokumentiert.
Häufige Audit-Befunde rund um Pen-Tests
Der häufigste Befund ist ein nicht erneuerter Test älter als 24 Monate. Auditoren erwarten in der Regel einen Test im laufenden Zertifizierungszyklus, also alle drei Jahre mindestens einmal, in der Praxis aber jährlich. Ein Test aus dem Erstzertifizierungsaudit ohne Folgetest ist ein klarer Befund.
Zweithäufig ist der Scope-Mismatch: Getestet wurde nur die Marketing-Website, zertifiziert ist aber das Kernsystem. Hier fehlt die Verknüpfung zwischen Risikoanalyse und Testumfang. Auditoren bestehen auf einer nachvollziehbaren Begründung des Scopes.
Drittens fehlende Maßnahmenverfolgung: Findings wurden gemeldet, aber nicht im ISMS-Maßnahmenplan eingetragen. Damit ist die Wirksamkeitsschleife unterbrochen, was Klausel 10.1 (Kontinuierliche Verbesserung) direkt berührt.
Viertens unklare Risikoakzeptanz. Wenn das Management ein Restrisiko trägt, muss diese Akzeptanz schriftlich, mit Datum und Unterschrift, im ISMS abgelegt sein. Eine mündliche Zusage genügt nicht.
Fünftens fehlende Re-Tests: Wurde eine kritische Schwachstelle als geschlossen markiert, ohne dass ein Re-Test stattfand, gilt sie für den Auditor weiterhin als offen. Re-Test-Berichte müssen Teil des Maßnahmen-Tickets sein.
CIVAC verknüpft Test-Bericht, Risikoakzeptanz, Maßnahmenplan und Re-Test in einer Berichtslinie, sodass der ISO 27001:2022-Übergang ohne offene Punkte gelingt.
Praktische Umsetzung in 6 Schritten
Schritt 1: Scope definieren. Ableitung aus der Risikoanalyse nach Klausel 6.1.2 der 27001:2022. Welche Systeme sind kritisch, welche personenbezogenen Daten verarbeitet, welche Schnittstellen extern erreichbar?
Schritt 2: Dienstleister auswählen. Kriterien sind OSCP/OSEP-zertifizierte Tester, Branchenerfahrung, deutschsprachige Berichte und Hosting der Befunddaten in der EU. Referenzen sollten geprüft werden, nicht nur Logos.
Schritt 3: Rules of Engagement schriftlich fixieren. Test-Zeitfenster, Eskalationsweg, erlaubte und verbotene Techniken, Notabbruch-Verfahren. Diese Vereinbarung schützt beide Seiten strafrechtlich.
Schritt 4: Durchführung und Begleitung. Der ISB sollte als zentraler Ansprechpartner verfügbar sein, um Eskalationen, False-Positives und Echtangriff-Verwechslungen schnell zu klären.
Schritt 5: Bericht entgegennehmen, Findings bewerten, Maßnahmenplan erstellen. Die Bewertung muss in das ISMS einfließen, mit Verantwortlichen, Fristen und CVSS-Score.
Schritt 6: Re-Test der behobenen Schwachstellen und Update des Statement of Applicability. Ohne diesen Schritt bleibt der Kreislauf unvollständig. Lizenzieren Sie den Workspace für Ihre internen Beauftragten, oder lassen Sie unsere Beauftragten bestellen. So entstehen 490 einsatzbereite Audit-Vorlagen, 93 Controls und ein dokumentierter Pen-Test-Zyklus in einer Hand.
Aus dem Lesen einen Auftrag machen
Pen-Test-Pflicht nach ISO/IEC 27001:2022 ist keine isolierte Aufgabe, sondern ein wiederkehrender Prozess aus Scope, Test, Bewertung, Behandlung und Re-Test. Wer diesen Prozess in Excel-Listen und E-Mail-Anhängen führt, verliert beim Re-Audit Zeit, im Ernstfall Geld.
CIVAC ist Compliance-Plattform und Officer-as-a-Service. Der Workspace hält Bestellurkunde, Berichtslinie, 93 Controls nach ISO/IEC 27001:2022, 490 Audit-Vorlagen und das Schwachstellenmanagement-Modul in einer EU-gehosteten Umgebung zusammen. Pen-Test-Berichte, Risikoakzeptanzen und Maßnahmenpläne liegen revisionssicher abgelegt.
Lizenzieren Sie den Workspace für Ihre internen Beauftragten, oder lassen Sie unsere Beauftragten bestellen. Im zweiten Modell übernehmen erfahrene Informationssicherheitsbeauftragte mit CIVAC-SLA von zwei Werktagen die Bestellung, die laufende Berichtslinie und die Audit-Begleitung.
Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software. Die Konsequenz: Bei der Auditfrage nach dem Pen-Test sind Bericht, Maßnahmen und Re-Test mit zwei Klicks erreichbar, nicht in einem Postfach-Archiv vergraben.
Schreiben Sie an info@civac.de oder nutzen Sie das Kontaktformular auf civac.de. Im Erstgespräch klären wir den Reifegrad Ihres ISMS, die offene Annex-A-Lücke und ob Lizenz oder Mandat besser passt.
Aus dem Lesen einen Auftrag machen.
FAQ
Verlangt ISO/IEC 27001:2022 wörtlich einen Penetrationstest?
Nein, der normative Teil nennt den Begriff nicht. Annex A 8.8, 8.29 und 5.36 verlangen aber die Wirksamkeitsprüfung technischer Maßnahmen, und ISO/IEC 27002:2022 benennt Pen-Tests als anerkannte Methode. In der Audit-Praxis ist ein dokumentierter Test damit faktisch erwartet.
Wie oft muss ein Pen-Test stattfinden?
Der Standard nennt keine feste Frequenz. Branchenüblich ist ein externer Pen-Test mindestens jährlich plus nach wesentlichen Änderungen. Vulnerability-Scans laufen monatlich bis vierteljährlich. Bei DORA-pflichtigen Finanzinstituten gelten TLPT mindestens alle drei Jahre.
Genügt ein automatisierter Schwachstellen-Scan?
Nein. Scans liefern eine Bestandsaufnahme bekannter CVE, ersetzen aber keinen manuellen Pen-Test. Auditoren erwarten beides: Scan als Grundlage, Pen-Test als vertiefte Wirksamkeitsprüfung mit nachvollziehbarer OWASP- oder PTES-Methodik.
Wer haftet, wenn der Pen-Test einen Schaden verursacht?
Der Dienstleister haftet im Rahmen des Werkvertrags nach BGB, meist begrenzt auf das Auftragsvolumen. Unterschriebene Rules of Engagement schützen beide Seiten strafrechtlich nach § 202c StGB. Eigenhaftung der Geschäftsleitung nach § 43 GmbHG bleibt bei fahrlässiger Beauftragung möglich.
Können wir den Pen-Test für ISO 27001 und NIS-2 gleichzeitig nutzen?
Ja, sofern Scope und Tiefe abgestimmt sind. NIS-2 Art. 21 Abs. 2 lit. f und ISO Annex A 8.8 verlangen vergleichbare Nachweise. Ein gemeinsamer Bericht spart Aufwand, muss aber beide Frameworks adressieren und im jeweiligen ISMS dokumentiert sein.
Wie unterstützt CIVAC bei der Pen-Test-Dokumentation?
CIVAC führt Scope, Bericht, Risikoakzeptanz, Maßnahmenplan und Re-Test in einer Berichtslinie. 37 Audit-Vorlagen decken Rules of Engagement, Risikoakzeptanz und Statement of Applicability ab. Lizenz für interne ISB oder externer ISB als Officer-as-a-Service, beide Modelle möglich.
Klingt nach viel Arbeit?
Beauftragten-Pflichten, Fristen, Nachweise — genau das nehmen wir dir ab. Sag kurz Hallo, wir zeigen dir wie.
Aus dem Beitrag ein Mandat machen.
Wir übernehmen die operative Last: externer Beauftragter, Vorlagen und Dokumentation in einem Workspace. Unverbindlich.