Pentesting for PCI DSS 4.0: what the auditor actually expects from your report

The problem: a pentest that does not survive the audit

Every week we talk to security teams that bought a pentest, received a 40-page PDF and, at audit time, heard from the QSA or internal auditor that it "doesn’t meet the requirement". Not because the test was bad — because the report does not prove what the standard asks for.

Under PCI DSS 4.0 (and SOC 2, ISO 27001 and most regulator expectations) the pentest stopped being an annual formality. It needs a methodology-defined scope, evidence of exploitation, and documented remediation and retest. Without that, the company pays twice.

What PCI DSS 4.0 asks for (requirement 11.4)

Requirement 11.4 is explicit about points many teams overlook:

• A documented, industry-accepted methodology (NIST SP 800-115, PTES or OWASP WSTG are the usual references). The report has to say which one was used, not just list findings.
• Coverage of the whole CDE surface — perimeter and critical components, application layer and network layer. An external Nessus scan is not a pentest.
• Segmentation testing: if you isolate the cardholder environment with VLANs and firewalls, the pentest must prove that segmentation holds. It is one of the most frequently failed items.
• Frequency: at least annually and after any significant change to infrastructure or applications.
• Remediation and retest: exploitable vulnerabilities must be fixed and the retest documented. A report without a retest section leaves the requirement open.

Version 4.0 also requires the tester to have organizational independence and demonstrable qualification — another reason for the report to identify the team and its certifications.

What SOC 2 and ISO 27001 auditors look for

Neither framework prescribes a methodology, but both ask the same three questions: how often do you test, how do you handle what you find, and how do you prove it. Companies pass when they have a pentest calendar by criticality, reports with PoC and risk rating, a treatment plan with deadlines, and retest evidence. The same package works for customer due diligence and vendor security questionnaires.

Anatomy of a report that passes

1. One-page executive summary: scope, dates, methodology, overall risk, findings by severity, post-retest status.
2. Scope and rules of engagement: URLs, IPs, credentials used (black/grey/white-box), exclusions and windows.
3. Named methodology with the phases executed.
4. Findings with: description, CVSS and business risk, reproducible evidence (request/response, screenshots, steps), remediation guidance with references (OWASP, CWE).
5. Segmentation tests (when applicable) with an explicit result.
6. Retest with date, fixed, pending and accepted findings.
7. Signed attestation identifying the team and certifications.

Mistakes that fail audits

• Scanner output with a consultancy logo.
• Findings without evidence ("possible SQL injection").
• Scope that does not match the network diagram handed to the auditor.
• Retest performed but not documented.
• A 2023 pentest presented in 2026 after two cloud migrations.

How Pentest Machine tests this

Our reports follow the structure above by default, with a named methodology (OWASP WSTG, PTES, NIST 800-115), a PoC for every finding, segmentation testing when the scope is PCI, and the retest included in the price. If your audit is on the calendar, the time to align scope is before the test — not after the report.