PCI-DSS Penetrationstest: Requirement 11.3 und 11.4 für die Cardholder Data Environment

PCI-DSS v4.0 (gültig ab 31. März 2024) verschärft die Penetrationstest-Anforderungen für alle Unternehmen, die Kreditkartendaten verarbeiten, speichern oder übertragen. Requirement 11.3 verlangt jährliche Penetrationstests der Cardholder Data Environment (CDE) sowie Tests nach wesentlichen Infrastrukturänderungen. Requirement 11.4 regelt externe Schwachstellenscans durch zugelassene ASVs (Approved Scanning Vendors). Dieser Leitfaden erklärt, was PCI-DSS v4.0 konkret fordert, wie die CDE-Scoping funktioniert und welcher Pentest-Ansatz QSA-anerkannt ist.

PCI-DSS-Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

PCI-DSS v4.0: Was sich für Penetrationstests geändert hat

PCI-DSS v4.0 (März 2022, verbindlich ab 31. März 2024) hat die Penetrationstest-Anforderungen gegenüber v3.2.1 an mehreren Punkten verschärft. Requirement 11.3.1 verlangt nun explizit, dass Penetrationstests 'einen umfassenden Ansatz verfolgen, der Schwachstellen in der Netzwerk-Schicht und der Anwendungsschicht prüft' — ein Hinweis, dass reine Netzwerk-Scans nicht mehr ausreichen. Requirement 11.3.1.1 (neu in v4.0) verlangt zudem den Test der Netzwerk-Segmentierung — also den Nachweis, dass die CDE tatsächlich von anderen Umgebungen isoliert ist und ein Angreifer nicht aus dem Nicht-CDE-Netz in das CDE eindringen kann. Requirement 11.3.2 macht explizit, dass externe Penetrationstests von einem qualifizierten internen oder externen Tester durchgeführt werden müssen, der von der getesteten Umgebung unabhängig ist. Für Händler und Service-Provider mit hohem Transaktionsvolumen (Stufe 1) verlangt PCI-DSS außerdem, dass Penetrationstests durch einen QSA (Qualified Security Assessor) oder einen internen ISA (Internal Security Assessor) begleitet werden.

PCI-DSS Requirement 11.3.1: Jährlicher Penetrationstest der CDE — sowohl externe als auch interne Angriffsvektoren. Tests müssen beide Schichten abdecken: Netzwerk-Infrastruktur und Anwendungsebene.
PCI-DSS Requirement 11.3.1.1 (neu v4.0): Penetrationstest der Netzwerk-Segmentierung mindestens alle 6 Monate sowie nach Änderungen an Segmentierungskontrollen — Nachweis dass CDE-Segmentierung 'holds'.
PCI-DSS Requirement 11.3.2: Nach wesentlichen Infrastruktur- oder Anwendungsänderungen in der CDE ist ein erneuter Penetrationstest erforderlich — nicht nur der jährliche Zyklus.
PCI-DSS Requirement 11.4: Quartalsweiser externer ASV-Scan (Approved Scanning Vendor — PCI SSC-zugelassener Scanner, kein interner Tool-Scan) für alle externen IP-Adressen und Domains in der CDE.
Scope-Reduktion als Strategie: Echte CDE-Minimierung (Tokenisierung, Point-to-Point-Encryption P2PE) reduziert den Pentest-Aufwand erheblich. Händler, die P2PE-validierte Lösungen nutzen, können auf eine minimale CDE-Scope reduzieren.
Qualifikation der Tester (Req. 11.3.2): 'Qualified internal resource or external third party' — in der Praxis OSCP/OSWE-zertifizierte Tester, Unabhängigkeit von der getesteten Umgebung, kein Self-Assessment.
PCI-DSS SAQ D (Service Provider): Service-Provider müssen zusätzlich halbjährliche interne Penetrationstests durchführen (SAQ D Service Provider, Req. 11.3.1 Anmerkung) — nicht nur jährlich.

Was ein PCI-DSS-konformer Penetrationstest umfasst

CDE-Scoping und Asset-Discovery: Vollständige Kartierung aller Systeme in der Cardholder Data Environment — PAN (Primary Account Number)-Flows, Speicher, Übertragungspfade, Verarbeitungssysteme.
Requirement 11.3.1 Netzwerk-Layer: Netzwerk-Scan aller CDE-Komponenten (Nmap, Masscan), Dienst-Identifikation, Prüfung auf bekannte CVEs in Netzwerk-Komponenten, VLAN-Hopping-Tests.
Requirement 11.3.1.1 Segmentierungs-Test: Nachweis dass Nicht-CDE-Systeme keinen unautorisierten Zugriff auf CDE-Systeme haben — Firewall-Bypass-Tests, VLAN-Traversal, Router-ACL-Analyse.
Anwendungsebene (Req. 11.3.1 Application Layer): OWASP Top 10 für alle CDE-Webanwendungen — Payment-Formulare, Checkout-Flows, Backoffice-Systeme für Transaktionsmanagement.
Authentifizierung und Zugangssteuerung (Req. 7 und 8): Minimale Privilegien für CDE-Zugang, MFA für alle Nicht-Konsolen-Administratorzugänge (Req. 8.4.2), Account-Sharing-Verbote, Default-Credentials.
Verschlüsselung von Kartendaten (Req. 3 und 4): TLS für alle Übertragungen (kein TLS 1.0/1.1), Prüfung ob PANs maskiert werden (nur 6+4 Stellen sichtbar), sichere Schlüsselspeicherung (HSM), keine Klartextdaten in Logs.
Logging und Monitoring (Req. 10): Verifikation dass sicherheitsrelevante Ereignisse geloggt werden, Log-Manipulations-Resistenz, SIEM-Integration, Anomalie-Erkennung für ungewöhnliche CDE-Zugriffe.
Patch-Management (Req. 6.3): Verifikation dass alle CDE-Systeme aktuelle Sicherheitspatches eingespielt haben — Scan gegen NVD für alle installierten Software-Versionen.
Web Application Firewall (Req. 6.4 — v4.0 Best Practice): WAF-Bypass-Tests, Verifikation der WAF-Regeln gegen OWASP Top 10, False-Positive-Rate-Analyse.
Malware-Schutz und Anti-Virus (Req. 5): Verifikation der AV-Abdeckung aller CDE-Systeme, Test ob bekannte Malware-Samples detektiert werden, EDR-Detektionsqualität.

Beispiel-Befund

Kritisch

PAN-Daten im Klartext in Web-Server-Zugriffsprotokollen (PCI-DSS Req. 3.3-Verstoß)

Der Checkout-Endpunkt /api/checkout/process sendet die vollständige PAN (Primary Account Number, 16-stellige Kreditkartennummer) als URL-Parameter: POST /api/checkout/process?cardNumber=4111111111111111&cvv=123&expiry=12/26. Da URL-Parameter vollständig in den Apache-Access-Logs geloggt werden, sind alle Kartennummern aller verarbeiteten Transaktionen im Klartext in /var/log/apache2/access.log gespeichert. Die Logs sind seit 3 Jahren nicht rotiert worden und enthalten über 2,3 Millionen vollständige PANs. Dieses Vorgehen verstößt gegen PCI-DSS Requirement 3.3 (keine Speicherung von Sensitive Authentication Data nach Autorisierung), Req. 4.2.1 (Verschlüsselung bei Übertragung) und Req. 10.2 (sichere Log-Verwaltung).

Behebung: Kartendaten niemals als URL-Parameter senden — POST-Body verwenden, und auch dort PANs nur als Referenz (Token) nach Tokenisierung. Bestehende Log-Dateien mit PANs sofort löschen oder sicher vernichten (PCI-DSS Req. 3.2 Secure Deletion). PAN-Tokenisierung implementieren (z.B. Stripe.js, Braintree.js, Adyen Client-Side Encryption) — Merchant-Systeme empfangen nur Token, nie die PAN selbst (Out-of-Scope-Strategie). Apache-Logging-Konfiguration überprüfen: sensible Parameter via 'SetEnvIf' aus Logs ausschließen. QSA informieren und Incident-Response einleiten (mögliches PCI-DSS Breach-Reporting erforderlich).

Referenz: PCI-DSS v4.0 Requirement 3.3 (Do not retain SAD after authorization) · Req. 4.2.1 (Strong cryptography for PAN transmission) · Req. 10.2 (Implement audit logs) · CWE-312 Cleartext Storage of Sensitive Information · CVSSv3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N = 9.6

PCI-DSS Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

PCI-DSS-konforme Pentest-Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Häufige Fragen zum PCI-DSS Penetrationstest

Wer muss PCI-DSS Penetrationstests durchführen?

Alle Unternehmen, die Kreditkartendaten (PAN, CVV, Magnetstreifen-Daten) verarbeiten, speichern oder übertragen — unabhängig von Größe oder Transaktionsvolumen. Das umfasst: Online-Händler (E-Commerce), stationäre Händler mit POS-Terminals, Zahlungsabwickler, Payment Service Provider (PSPs), Acquirer. Die Tiefe der Prüfpflichten variiert nach Level (1–4, basierend auf Transaktionsvolumen): Level 1 Händler (>6 Mio. Transaktionen/Jahr) benötigen einen QSA-begleiteten Pentest.

Was ist der Unterschied zwischen PCI-DSS v3.2.1 und v4.0 für Penetrationstests?

Die wesentlichen Änderungen in v4.0 (verbindlich ab 31.03.2024): (1) Req. 11.3.1.1 NEU: Segmentierungs-Test alle 6 Monate (war: jährlich). (2) Req. 11.3.1 präzisiert: explizit beide Schichten (Netzwerk + Anwendung). (3) Stärkere Anforderungen an Tester-Unabhängigkeit. (4) Req. 6.4 (WAF) wird ab 31.03.2025 Pflicht statt Best Practice. (5) Multi-Faktor-Authentifizierung (MFA) für alle CDE-Zugänge wird verpflichtend (Req. 8.4.2). Wer noch nach v3.2.1 arbeitet, muss spätestens ab 01.04.2024 auf v4.0 umgestellt sein.

Was ist ein ASV-Scan und unterscheidet er sich vom Penetrationstest?

Ein ASV-Scan (Approved Scanning Vendor) ist ein automatisierter Schwachstellenscan durch einen vom PCI SSC zugelassenen Anbieter — quartalsweise Pflicht für alle externen IP-Adressen in der CDE. Ein Penetrationstest geht tiefer: Er nutzt die ASV-Scan-Ergebnisse als Startpunkt, verifiziert Schwachstellen mit Proof-of-Exploit und testet Logik-, Konfigurations- und Autorisierungsfehler, die ein ASV-Scan nicht findet. Beide sind separate PCI-DSS-Pflichten und ersetzen sich nicht gegenseitig.

Was ist CDE-Scoping und warum ist es für den Pentest relevant?

Das CDE-Scoping (Cardholder Data Environment) definiert, welche Systeme in den Penetrationstest einbezogen werden müssen. Alle Systeme, die PANs verarbeiten, speichern oder übertragen — sowie alle Systeme, die mit diesen verbunden sind ('connected-to' Systeme) — sind in-scope. Effektives Scoping (via Tokenisierung, P2PE, Segmentierung) kann die CDE erheblich reduzieren und damit den Pentest-Aufwand und -Kosten senken. Ein zu kleiner Scope ist ein häufiger QSA-Audit-Finding.

Wie oft muss nach PCI-DSS ein Penetrationstest durchgeführt werden?

Minimum: jährlich (Req. 11.3.1) + nach wesentlichen Infrastrukturänderungen (Req. 11.3.2) + Segmentierungs-Test alle 6 Monate (Req. 11.3.1.1, neu v4.0). Für Service-Provider (SAQ D): halbjährlich. Empfehlung: kontinuierliche Tests (z.B. via Matproof Sentinel) zwischen den formalen Jahres-Pentests, um Regressionen nach Deployments sofort zu erkennen.

Was passiert, wenn ein PCI-DSS-Penetrationstest kritische Findings zeigt?

Kritische Findings müssen dokumentiert, priorisiert und behoben werden — ein Re-Test nach Behebung ist von PCI-DSS gefordert (Req. 11.3.2.1). Wenn ein laufender QSA-Audit stattfindet: QSA muss informiert werden, Findings werden im Report-on-Compliance (RoC) vermerkt, Behebungsfristen werden vereinbart. Bei aktiven Datenlecks (Kompromittierung von PANs): Payment-Brand (Visa, Mastercard) und Acquirer müssen informiert werden — Breach-Notification-Prozess.

Kann ein Händler den PCI-DSS-Penetrationstest selbst durchführen?

Grundsätzlich ja (interne Tester, Req. 11.3.2) — aber: Die interne Ressource muss von der getesteten Umgebung unabhängig sein und ausreichende Qualifikation haben (OSCP, OSWE oder gleichwertig). Level 1 Händler und Service-Provider benötigen einen QSA-begleiteten Prozess. In der Praxis empfehlen die meisten QSAs externe Tester für den jährlichen CDE-Pentest, um Unabhängigkeit und Objektivität zu gewährleisten.

Wie hoch sind die Strafen bei PCI-DSS-Verstößen?

PCI-DSS ist kein Gesetz, sondern ein vertraglich vereinbarter Standard zwischen Händlern/Service-Providern und den Kartenorganisationen (Visa, Mastercard etc.). Strafen: Bußgelder von $5.000–$100.000/Monat von Acquirern, erhöhte Transaktionsgebühren, Verlust der Kartenakzeptanzerlaubnis (gravierendste Strafe für E-Commerce), Haftung für Fraud-Schäden nach einem Breach. In Deutschland kommen bei Datenlecks mit personenbezogenen Daten zusätzlich DSGVO-Bußgelder hinzu.

Vertiefen — verwandte Artikel aus unserem Blog

PCI-DSS-konformen Pentest für Ihre CDE starten

Erfüllen Sie PCI-DSS v4.0 Requirement 11.3 mit einem audit-bereiten Penetrationstest-Bericht — inklusive Segmentierungs-Test (Req. 11.3.1.1) und explizitem PCI-DSS-Mapping. QSA-taugliche Dokumentation, erste Ergebnisse in 3 Minuten.