So beauftragen Sie einen rechtskonformen Penetrationstest: Schritt für Schritt für PCI-DSS und ISO 27001

Nicht jeder Penetrationstest ist ein Compliance-Penetrationstest

Viele Unternehmen bestellen einen Compliance-Penetrationstest wie einen Routineauftrag. Dann kommt das Audit, der Bericht wird nicht anerkannt, und die Überraschung ist groß. Der Grund ist fast immer derselbe: PCI-DSS Requirement 11.4 und ISO 27001 stellen konkrete Anforderungen an Prüfumfang, Methodik, Berichtsinhalt und Nachtest, die ein allgemeiner Schwachstellenscan schlicht nicht erfüllt. Dieser Artikel gibt Ihnen die sachliche Grundlage, um Anbieter gezielt zu vergleichen, ein belastbares Briefing zu formulieren und die Beauftragung sauber aufzusetzen.

Was die beiden Regelwerke jeweils verlangen

• •PCI-DSS, Prüfumfang: die gesamte Karteninhaberdatenumgebung, exponierte Programmierschnittstellen, Webanwendungen und alle Systeme, die die Umgebung beeinflussen können. Mindestens jährlich und nach jeder wesentlichen Infrastrukturänderung.
• •PCI-DSS, Segmentierung: Wird Netzwerksegmentierung zur Reduzierung des Prüfumfangs eingesetzt, müssen die Segmentierungskontrollen separat geprüft werden. Das ist ein eigener Prüfschritt, kein Nebenprodukt.
• •PCI-DSS, Abgrenzung: Der ASV-Scan ist eine eigenständige Pflicht und ersetzt den Penetrationstest nicht. Der QSA führt den Test nicht zwingend selbst durch, beurteilt aber, ob Methodik, Unabhängigkeit und Berichtsinhalt konform sind.
• •ISO 27001, Herleitung: Der Test muss konkreten Assets, Risiken und ausgewählten Maßnahmen zugeordnet sein. Ohne diese Zuordnung fehlt dem Auditor die Grundlage, den Bericht als Nachweis zu werten.
• •ISO 27001, Testansatz: Die Wahl zwischen Blind-, Graukasten- und Weißkasten-Verfahren muss risikobegründet und nachvollziehbar dokumentiert sein. Eine Abstimmung mit der Zertifizierungsstelle vor dem Test ist empfehlenswert.
• •Beide, Nachtest: PCI-DSS verlangt nach Behebung ausnutzbarer Schwachstellen einen dokumentierten Nachtest. ISO-27001-Auditoren erwarten ebenfalls die Bestätigung, dass Befunde behandelt wurden. Der Status muss je Befund eigenständig erscheinen: behoben, teilweise behoben oder offen.

Manueller Test oder automatisierter Scan

Das ist das häufigste Missverständnis beim Anbietervergleich, und es entscheidet über die Auditfähigkeit des Ergebnisses. Automatisierte Scanner erkennen bekannte Schwachstellen und Fehlkonfigurationen. Was sie nicht können: Fehler in der Geschäftslogik aufdecken, Rechteausweitungen im Active Directory nachvollziehen oder verkettete Angriffspfade abbilden. Manuelle Tests erzeugen dagegen reproduzierbare Machbarkeitsnachweise - einen Zugang über eine Schnittstellenschwachstelle, eine Rechteausweitung, einen Datenzugriff auf die geschützte Umgebung. Diese Nachweise sind für Auditoren deutlich belastbarer als Scanner-Ausgaben, und die Zusammenfassung für die Leitungsebene erlaubt es der Geschäftsführung, Risiken zu verstehen und Maßnahmen zu priorisieren. Für die meisten Compliance-Prüfungen ist der Graukasten-Ansatz der pragmatische Standard: realistische Angreiferperspektive bei vertretbarer Abdeckung. Seine Eignung muss allerdings risikobasiert begründet werden, eine pauschale Akzeptanz durch QSA oder Auditor ist nicht garantiert.

Anbieter prüfen und den Auftrag sauber aufsetzen

Die meisten Fehler passieren nicht beim Test, sondern bei der Vergabe. Bei den Qualifikationen zählt die Kompetenz der tatsächlich eingesetzten Tester, nicht das Firmenbriefpapier: OSCP, OSWE, CREST CRT oder vergleichbare praktische Nachweise sind aussagekräftig, eine Akkreditierung auf Unternehmensebene wiegt schwerer als ein einzelnes Mitarbeiterzertifikat. ASV- und QSA-Status sind dagegen keine Indikatoren für Pentest-Kompetenz - das sind separate Rollen im PCI-Gefüge. Fragen Sie im Erstgespräch direkt nach manuellen Angriffsketten und nach der Dokumentation der Machbarkeitsnachweise.

Was der Bericht enthalten muss

Ein auditfähiger Bericht trägt vier Pflichtbestandteile: eine Zusammenfassung für die Leitungsebene mit Gesamtbewertung, kritischen Befunden, Geschäftsrisiken und priorisierten Maßnahmen; einen Abschnitt zu Prüfumfang und Methodik mit getesteten Assets, Zeitraum, Einschränkungen und den verwendeten Standards wie PTES und dem OWASP Web Security Testing Guide; einen technischen Anhang, der je Befund Beschreibung, Ursache, CVSS-Bewertung, Screenshots, Anfragen, Protokollauszüge und Handlungsempfehlung dokumentiert; und Reproduktionsschritte mit Befehlen, Nutzlasten und Voraussetzungen - ohne sie ist ein Machbarkeitsnachweis kein verwertbarer Beweis. Für PCI-DSS kommen hinzu: der Nachweis interner und externer Tests einschließlich Segmentierungsprüfung, der ausdrückliche Bezug auf Requirement 11.4, der Nachtest-Status je Befund und eine Aussage zur organisatorischen Unabhängigkeit der Tester von Entwicklung und Administration der geprüften Systeme. Hinweise dazu veröffentlicht das PCI Security Standards Council. ISO-27001-Auditoren prüfen zusätzlich die Zuordnung zu Risiken, ISMS-Geltungsbereich und Maßnahmen aus der Anwendbarkeitserklärung - samt Begründung, welche Assets nicht geprüft wurden.

Die Grundfragen bleiben immer dieselben: Wer testet konkret? Welche Methodik kommt zum Einsatz? Was enthält der Bericht? Und ist der Nachtest inklusive? Bei Sodu Secure testen OSCP-, OSWE- und CEH-zertifizierte Prüfer manuell, jeder Bericht enthält eine Zusammenfassung für die Leitungsebene auf Deutsch und Englisch, reproduzierbare Machbarkeitsnachweise und einen eigenen Nachtest-Status je Befund; nach der Behebung wird jeder Befund kostenfrei erneut verifiziert. Abgedeckt sind PCI-DSS, ISO 27001, NIS2, DORA, TISAX und DSGVO. Stellen Sie Ihren Prüfumfang online zusammen - ein verbindliches Angebot folgt innerhalb von 24 Stunden.