PCI Penetration Testing Services (DSS v4.0.1)
Real skill leaves evidence. Your PCI report is full of it: where the CDE broke under a real attack, and proof the fix holds.
CDE & Segmentation Validation
Real lateral movement from out-of-scope networks toward the CDE. We prove your segmentation works, not that it looks right on a network map.
Built Around Requirement 11.4
Documented methodology, exploitation evidence, prioritized remediation, and retesting your security team and QSA can stand behind.
Payment App, API & E-Commerce Testing
Hands-on testing of gateways, tokenization, carts, and integrations. The systems that move card data, not just the network perimeter.
| PCI area | Description | How Raxis supports it |
|---|---|---|
| 11.4.1 | Maintain a penetration testing methodology | Documented rules of engagement, scope, approach, tools, exclusions, and evidence, aligned with the standards above. |
| 11.4.2 | Internal penetration testing | Manual exploitation across in-scope internal CDE networks and systems. |
| 11.4.3 | External penetration testing | Internet-facing testing against CDE-connected assets, exposed services, and attack paths. |
| 11.4.4 | Remediation and retesting | Findings include fix guidance, and retesting verifies corrective actions. |
| 11.4.5 | Segmentation testing where segmentation is used to reduce scope | Attempts to bypass segmentation and validate CDE isolation from out-of-scope networks. |
| 11.4.6 | Service provider segmentation testing every six months | Six-month segmentation testing for service providers, validating CDE isolation. |
| 11.4.7 | Multi-tenant service provider support for customer external testing | Support for customer external penetration testing under 11.4.3 and 11.4.4. |
Qualified Means Credentials Your QSA Recognizes
Qualified means demonstrable penetration testing experience and credentials your QSA will recognize. Raxis testers hold certifications including OSCP, OSWE, OSCE, OSEP, GPEN, and CISSP, and every PCI engagement is led by a senior U.S.-based tester. See our team certifications for the full list.
Organizational Independence Required
Independence is where internal teams usually fall short. Even a capable in-house security team often manages or influences the controls under test, which a QSA can flag. A third-party test removes the question entirely and gives your QSA evidence with no asterisk on it.
No QSA or ASV Required
PCI DSS does not require your penetration test to come from a QSA or an ASV. Those designations apply to assessors and scanning vendors, not pen testers. What Requirement 11.4 does require is that the tester be qualified and organizationally independent from the team that manages the systems being tested. Your network admin cannot pentest their own firewall rules.
11.3, Vulnerability Scanning
Quarterly internal and external scans (11.3.1 and 11.3.2) sit alongside pen testing. We validate which scan findings an attacker can actually exploit, so you fix what matters first.
11.6, Payment Page Change Detection
PCI v4.0.1 targets e-skimming and Magecart-style attacks on payment pages. We test the client-side scripts, redirects, and third-party JavaScript that put cardholder data at risk in the browser.
6.4, Application-Layer Testing
Public-facing apps and APIs in the payment path must be evaluated annually and after significant change. Our web app and API testing surfaces the logic flaws and authorization gaps scanners walk past.
Merchants
Internal and external penetration testing at least annually, plus after any significant change to the environment. Segmentation testing at least annually where segmentation reduces scope.
Service Providers
Same annual internal and external testing, but segmentation testing every six months and after any change to segmentation controls.
Significant Changes Reset the Clock
New infrastructure, a major app release, network re-architecture, or moving the CDE all trigger a fresh test regardless of when the last one ran.
| SAQ Type | Who Uses It | Pentesting Required |
|---|---|---|
| SAQ A | E-commerce fully outsourced to a validated third party; no card data touches your systems | None. But 11.6.1 payment page monitoring and 6.4.3 script controls now apply |
| SAQ A-EP | E-commerce sites that don’t store card data but affect transaction security | External pen test (11.4.3), plus segmentation testing (11.4.5) where segmentation is used |
| SAQ B / B-IP | Imprint machines or standalone dial-out / IP-connected terminals | No internal or external pen test. B-IP: segmentation testing (11.4.5) where segmentation reduces scope |
| SAQ C | POS or payment application systems connected to the internet; no electronic storage | No internal or external pen test. Segmentation testing (11.4.5) where segmentation reduces scope |
| SAQ C-VT | Web-based virtual terminals, one transaction at a time | None |
| SAQ P2PE | Validated point-to-point encryption solution only | None |
| SAQ D (Merchant) | Everyone else, including anyone storing cardholder data electronically | Full 11.4: internal (11.4.2), external (11.4.3), remediation retesting (11.4.4), annual segmentation testing (11.4.5) |
| SAQ D (Service Provider) | Service providers eligible for self-assessment | Full 11.4, with segmentation testing every six months (11.4.6) and multi-tenant support obligations (11.4.7) |
| ROC (Level 1) | Merchants over 6M transactions/year and service providers assessed by a QSA | Full 11.4, same as SAQ D for your entity type |
Scanner Output Dressed Up as a Pentest
Scans are useful. They are not manual exploitation, business logic testing, or attack-path validation. You can tell when it’s real, and so can a QSA.
Segmentation That Only Works on Paper
If segmentation reduces your scope, it has to hold under attack. We run real paths from out-of-scope networks toward the CDE and document what gets through.
Payment Flows Nobody Tested
Gateways, tokenization, carts, client-side JavaScript, APIs, redirects, and third-party integrations all shape PCI risk. We test the whole flow.
Remediation Without Proof
A ticket marked “fixed” does not prove the risk is gone. We retest corrective actions and document what changed.
Segmentation Gaps
Firewall, ACL, VLAN, and routing misconfigurations that let out-of-scope systems talk to the CDE. The exact paths 11.4.5 exists to catch.
Payment API & Gateway Flaws
Broken authentication, IDOR, injection, and weak session handling in the APIs and gateways moving card data.
Privilege Escalation Inside the CDE
Low-privilege accounts climbing to admin through patch gaps, weak RBAC, and configuration flaws once inside the boundary.
Exposed and Insecure Services
Non-essential services running on CDE-connected hosts that hand an attacker a foothold.
Client-Side Skimming Exposure
Third-party scripts and tag managers on payment pages that can be abused to lift card data straight from the browser.
Why Raxis for PCI Penetration Testing
The tester on your scope call is the one breaking into the CDE. And the one retesting your fix.
Human-led exploitation
Senior testers validate attack paths by hand. Several ran retail cybersecurity before Raxis, so they test the way someone who has defended these systems would attack them.
CDE and segmentation expertise
We test whether your CDE boundary holds under real lateral movement, not whether it passes a config review.
Fortune 500 Experience
We have pulled cardholder data, intercepted live transactions, and gained administrator access at Fortune 500 retailers.
QSA-ready reporting
Every report includes scope, methodology, evidence, impact, remediation, and retest status, written by the engineer who did the work. Built for a QSA to review and accept.
Secure delivery
Reports and evidence land in Raxis One, with Trust Center documentation for controls, SOC 2 status, insurance, and data handling.
Upgrade to Continuous PTaaS
Raxis Attack PTaaS delivers continuous, AI-augmented PCI testing with real-time results and unlimited retesting, so you are not flying blind for 11 months between engagements.
Scope
Live system count, the size of in-scope apps and APIs, and how much sits inside the CDE versus connected to it.
Segmentation Complexity
The number of distinct segmentation methods and out-of-scope zones we test paths from. More boundaries, more validation.
Test Type
Black box, grey box, or white box. Deeper access means deeper coverage and more tester hours.
Add-Ons
Wireless, social engineering, payment app testing, and physical testing layered onto the core PCI scope.
FAQ: PCI Penetration Testing
Does PCI DSS v4.0.1 require penetration testing?
Yes. Requirement 11.4 covers your testing methodology, internal and external testing, remediation validation, and segmentation testing where segmentation reduces PCI scope.
What changed for penetration testing between PCI DSS 3.2.1 and 4.0/4.0.1?
The pentesting requirements moved from 11.3 to 11.4 and became more prescriptive. The methodology must now be defined, documented, and implemented per 11.4.1, including retention of results and remediation records for at least 12 months. Internal vulnerability scans must now be authenticated (11.3.1.2). New requirements 6.4.3 and 11.6.1 target payment page scripts and e-skimming, and 11.4.7 adds obligations for multi-tenant service providers to support customer external testing. If your last pentest report references 11.3, it was written against a retired standard.
How often is PCI penetration testing required?
Merchants test internally and externally at least annually and after significant changes, with segmentation testing at least annually where used. Service providers test segmentation every six months.
How much does a PCI penetration test cost?
Most PCI engagements run from roughly $8,000 for a tight CDE to $100,000 or more for large, multi-segment environments. Scope, segmentation complexity, test type, and add-ons set your number. We give you a fixed quote before testing starts.
How long does a PCI penetration test take?
Most PCI penetration tests run one to three weeks of active testing, depending on the size of the CDE, the number of segmentation boundaries, and how many applications and APIs are in scope. A segmentation-only test for a service provider is usually days, not weeks. Plan backwards from your QSA assessment date and leave room for remediation and retesting, which is its own pass.
Is vulnerability scanning enough for PCI DSS?
No. Scanning falls under 11.3 and pen testing under 11.4. Both are required, and they do different jobs. A scan lists what might be wrong. A pentest proves what an attacker can actually do with it.
Do you test PCI segmentation?
Yes. When segmentation isolates the CDE, we test whether out-of-scope systems can reach or affect in-scope CDE systems, the way 11.4.5 requires.
Do you test payment applications and APIs?
Yes. We test payment apps, APIs, e-commerce workflows, authentication, authorization, business logic, and the integrations that shape cardholder data risk.
Will the report work for my QSA?
Yes. Reports include scope, methodology, evidence, findings, severity, remediation guidance, and retest status, so your QSA can see exactly what was tested and validated.
How long do you keep our test records?
PCI expects results and remediation records held for at least 12 months. Your full history and retest evidence stay in Raxis One for as long as you need them.
Will testing disrupt our payment processing?
No. We work inside strict contractual boundaries with clear rules of engagement. The goal is to expose vulnerabilities without downtime, data loss, or interruption to live transactions.
Who can perform a PCI penetration test? Does it have to be a QSA or ASV?
No. QSA and ASV designations apply to compliance assessors and scanning vendors, not penetration testers. PCI DSS 11.4 requires a qualified tester who is organizationally independent of the systems under test. That can be a third party like Raxis or, in theory, an independent internal team, though in-house teams often fail the independence requirement because they manage the controls being tested. Raxis testers hold OSCP, OSWE, OSCE, OSEP, GPEN, and CISSP certifications.