PCI DSS
PCI DSS Penetration Testing
Requirement 11.4 testing of your cardholder data environment - application, network, and segmentation, delivered to QSA-acceptable standards.
UK-based testers · Methodology designed for QSA review · Documented testing approach aligned to NIST SP 800-115
Why this matters
Why PCI DSS mandates penetration testing.
Unlike ISO 27001 or SOC 2, PCI DSS is explicit. Requirement 11.4 mandates penetration testing - and v4.0 (mandatory from 31 March 2025) made the requirements stricter. You must test:
- External and internal penetration testing at least annually and after any significant change (11.4.2, 11.4.3)
- Application-layer testing for vulnerabilities listed in Requirement 6.2.4 (11.4.3)
- Segmentation controls at least every 12 months (every 6 months for service providers) to verify the cardholder data environment (CDE) is properly isolated from out-of-scope networks (11.4.5, 11.4.6)
- Testing methodology must be documented and based on industry-accepted approaches such as NIST SP 800-115 (11.4.1)
The testing has to be performed by qualified personnel - internal or external, but with organisational independence from the team that manages the systems. For most organisations, that means an external firm.
A QSA will look for: defined scope, documented methodology, qualified testers, full report including findings and remediation, and evidence of re-testing where exploitable findings were identified.
What gets tested - and which Pentiq service covers it.
PCI DSS v4.0 is explicit about what testing is required and how often. Here's how Requirement 11 maps to our services.
| Control area | What's assessed | Pentiq service |
|---|---|---|
| 11.4.2 - Internal penetration testing | Annual + after significant changes | Internal Infrastructure Testing |
| 11.4.3 - External penetration testing | Annual + after significant changes | External Infrastructure Testing |
| 11.4.3 - Application-layer testing | All public-facing apps, and at the application layer for the CDE | Web Application & API Testing |
| 11.4.5 - Segmentation testing (merchants) | Annually, validates CDE isolation | Segmentation Testing within Internal Infrastructure Test |
| 11.4.6 - Segmentation testing (service providers) | Every 6 months | Segmentation Testing within Internal Infrastructure Test |
| 11.3.1 - Internal vulnerability scanning | At least every 3 months, after significant changes | Vulnerability Scanning Subscription |
| 11.3.2 - External vulnerability scanning (ASV) | Quarterly, by an Approved Scanning Vendor | Introduction to a PCI-approved ASV - we don't perform ASV scans |
Requirement 11.3.2's external quarterly scans must be performed by a PCI-approved ASV. We're not an ASV, but we can introduce you to several PCI-approved ASVs. The pentest covered under Requirement 11.4 is separate, and we perform it directly.
Scope my test
Get a tailored PCI DSS test scope.
Tell us about your CDE and we'll come back with a scoped engagement covering Requirement 11.4 - usually within one working day.
What's in scope?
Select everything you'd like tested. Pick more than one if it applies.
Prefer to talk first? Book a 20-minute scoping call ->
Engagement
What a Pentiq PCI DSS engagement looks like.
Scoping
A short call with your technical contact to confirm scope, agree the test plan, and book delivery dates against your PCI DSS timeline.
Testing
Testing runs against the agreed scope. Findings appear in your Pentiq portal in real time, so your team can start triaging without waiting for a final report.
Reporting & remediation
Final report delivered through the portal: executive summary, technical findings mapped to PCI DSS control areas, and remediation guidance for each issue.
Optional re-test
We re-test fixed findings before your PCI DSS assessment so you walk in clean.
Engagement length depends entirely on scope - we confirm a realistic timeline during the scoping call.
Common questions
Frequently asked questions.
What changed in PCI DSS v4.0 for penetration testing?
The biggest changes: a documented methodology is now explicitly required (11.4.1), testers must have organisational independence, and segmentation testing for service providers moved from annually to every 6 months. The scope of "significant change" was also clarified - and it's broader than many organisations realise.
What counts as a "significant change"?
Changes that could affect CDE security: new applications in scope, infrastructure changes, network architecture changes, upgrades to underlying platforms. If in doubt, document the assessment of whether it's significant - your QSA will ask.
Are you a QSA?
No. We're a penetration testing firm. Your QSA performs the audit; we perform the pentest that evidences Requirement 11.4. The two roles are deliberately separated for independence - a QSA can't audit their own pentest work.
Can you reduce our PCI scope?
Yes - that's often the most valuable conversation. Tokenisation, network segmentation, and removing systems from the CDE can dramatically reduce both audit cost and pentest scope. We can advise on segmentation design as part of scoping.
What about SAQ-A merchants - do we still need a pentest?
SAQ-A (e-commerce merchants who fully outsource card processing) doesn't require Requirement 11.4 testing in the same way. But SAQ-A-EP (where your site touches payment data) does. Scope clarification matters here - happy to walk through which SAQ applies during scoping.
Does segmentation testing have to be a pentest, or is a scan sufficient?
PCI v4.0 specifies segmentation testing must be performed using penetration testing methods, not just scans. Active attempts to traverse the segmentation boundary are required.
Can the same engagement cover internal pentest, external pentest, and segmentation testing?
Yes, and it's the efficient way to do it. We deliver these as a combined annual engagement, with segmentation testing repeated at 6 months for service providers.