PCI DSS Penetration Testing
PCI DSS 4.0 penetration testing across Europe: requirement 11.4 coverage, segmentation checks and an attestation letter from OSCP engineers. Fixed quote.
PCI DSS penetration testing is the specific, annual test your acquirer and QSA expect under requirement 11.4: a manual assessment of the cardholder data environment, its segmentation, and the applications that touch card data. We run it to the standard’s own methodology and give you a report and attestation letter built to close the requirement, not just to look busy.
An ASV vulnerability scan is not a penetration test, and treating one as the other is how organisations fail an assessment. PCI DSS 4.0 is explicit: you need a documented methodology, testing from outside and inside the environment, verification that your segmentation actually isolates the cardholder data environment, and a retest of anything you fix. We do exactly that, and we write it up so your QSA can tick the box.
What a PCI DSS penetration test actually covers
The test is scoped around the cardholder data environment, the CDE, and everything that could provide a path into it. That means the systems that store, process or transmit card data, the segmentation controls meant to keep everything else out, and the applications and network services exposed at the boundary.
How we run a PCI DSS penetration test
We follow a documented methodology aligned to requirement 11.4.1, drawing on industry guidance such as the PCI SSC penetration-testing information supplement, OWASP for the application layer, and the PTES for the network layer. Everything maps back to the specific sub-requirement it satisfies, so your evidence file is complete when we hand it over.
Defining and confirming scope
Getting scope right is where PCI compliance penetration testing succeeds or fails. We work with you to identify the CDE, the connected and security-impacting systems, and the segmentation boundary, then confirm that scope before testing so the assessment covers everything the standard requires and nothing that wastes your budget.
External testing (11.4.3)
We test the perimeter from the position of an internet-based attacker: exposed services, web applications, remote access, and anything that could be a route toward card data. This satisfies the external penetration testing requirement and doubles as a genuine security exercise, not a paperwork one.
Internal testing (11.4.2)
From inside the network we test what an attacker who already has a foothold, a malicious insider, or a compromised workstation could do to reach the CDE. Internal testing routinely surfaces the flat networks and forgotten trust relationships that make a breach far worse than it needed to be.
Segmentation testing (11.4.5 and 11.4.6)
If you rely on segmentation to keep systems out of scope, PCI DSS requires you to prove it works: at least annually for merchants, and every six months for service providers. We test from out-of-scope networks toward the CDE and confirm the controls actually block the paths they are supposed to. If they do not, your scope was wrong and so was your assessment.
Remediation and retest (11.4.4)
The standard requires you to correct exploitable findings and verify the fix. Our retest is included and free, and the updated report and attestation letter document that the issues are closed, which is exactly the evidence your QSA needs.
How this differs from an ASV scan
Requirement 11.3 covers vulnerability scanning, including quarterly external scans by an Approved Scanning Vendor. Requirement 11.4 is different work entirely. A scan is automated and looks for known issues; a penetration test is a person actively trying to exploit and chain weaknesses, including business-logic flaws and segmentation gaps a scanner cannot see. You need both, and they are not interchangeable. Many failed assessments come from a team believing a green scan report satisfied the pen-test requirement.
Vulnerabilities we commonly find in scope
The CDE has its own recurring problems, often at the seams between in-scope and out-of-scope systems.
Weak segmentation
A firewall rule that is broader than the diagram claims, a management VLAN that bridges into the CDE, or a jump host reachable from the general corporate network. Segmentation on paper and segmentation in practice are frequently different, and the difference is your scope.
Application flaws on card-handling systems
Injection, broken authentication and access-control issues on the applications that process payments, mapped to the common coding vulnerabilities in requirement 6.2.4. These are the flaws that turn a web app into a card-skimming incident.
Exposed services and default configurations
Management interfaces open to the internet, default or reused credentials, and unpatched services at the perimeter. Unglamorous, common, and exactly what real attackers use against payment environments.
Insecure remote access
VPN and remote-administration paths into the environment without strong authentication or proper restriction. Remote access is a favourite entry point, and it sits squarely in PCI scope.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
Tools and evidence
Testing is manual, supported by Burp Suite Professional at the application layer, nmap for service discovery, and the exploitation tooling appropriate to each finding, with every result confirmed by hand rather than lifted from a scanner. For each finding you get the evidence a QSA expects: the affected system, the CVSS score, reproduction steps, screenshots or output where relevant, the mapping to the PCI requirement, and a clear fix.
What you get
Everything is written to drop straight into your PCI evidence file.
- A documented methodology aligned to requirement 11.4.1.
- An executive summary for management and your QSA, plus a technical report with each finding scored, mapped to its requirement, and given a concrete fix.
- Segmentation test results proving isolation of the CDE.
- A free remediation retest satisfying 11.4.4, and an updated report once fixes are confirmed.
- An attestation letter stating the scope, dates and outcome of the test, which your QSA can rely on.
Compliance and timing
PCI DSS requires the penetration test at least annually and after any significant change to the environment. Service providers face the added segmentation-testing cadence of every six months. If you are working toward an assessment date, tell us the deadline: we scope the engagement to land the report and retest with enough margin before your QSA needs the evidence.
Getting scope right, and why it dominates the cost
More than any other factor, scope decides both the validity and the price of a PCI penetration test. The cardholder data environment is everything that stores, processes or transmits card data, plus the systems connected to it and those that could affect its security. Draw that boundary too small and your assessment misses systems that are genuinely in scope; draw it too large and you pay to test machines that never touch a card.
Segmentation as scope reduction
Good segmentation is how organisations keep the CDE, and the cost, small. If a network segment truly cannot reach the cardholder data environment, it is out of scope. That is precisely why PCI requires you to prove the segmentation works: the whole scope reduction rests on it. We test from the out-of-scope side and confirm the controls block every path they are supposed to, because a segmentation gap silently pulls more systems back into scope.
Working to your assessment date
If you are heading toward a QSA assessment, the retest matters as much as the test. You need time to fix findings and have us verify them before the evidence is due. Tell us the deadline during scoping and we plan the engagement, including the free remediation retest, to land with margin rather than in a scramble the week before.
Why a clean scan is not a clean bill of health
We are regularly called in after a team assumed their green ASV scan report meant they had satisfied the whole of requirement 11. A scanner sees known vulnerabilities on exposed services. It does not try to chain a low-risk information leak into an authentication bypass, abuse a business-logic flaw in a payment page, or discover that a management network quietly bridges into the CDE. Those are the findings that end up in breach reports, and they only come from a person testing with intent.
The findings that matter most
In card environments the highest-impact issues are rarely exotic. They are broad firewall rules, reused administrative passwords, an unpatched perimeter service, and a payment application with an injection flaw. Unglamorous, common, and exactly what real intrusions use, which is why we prioritise them over cosmetic findings in the report. A QSA cares that the exploitable issues are found and fixed, not that a report is padded with low-severity noise, and we write ours the same way.
Pricing
The pci dss penetration testing cost depends on the size of your cardholder data environment, how many external and internal systems are in scope, and whether you need segmentation testing on the service-provider cadence. Every PCI engagement includes an attestation letter.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Focused CDE | Small, well-segmented CDE, external + internal test, one payment application, segmentation check, report, attestation and free retest | 4–6 working days | from €3,000 |
| Standard merchant | Larger CDE, multiple in-scope systems and applications, full 11.4 external, internal and segmentation testing, exec + technical report | 6–10 working days | €5,000–€12,000 |
| Service provider | Complex environment, six-monthly segmentation testing, multiple applications and connected systems, attack-chaining toward the CDE | 10–15 working days | €12,000–€25,000 |
| Segmentation-only retest | Standalone six-monthly segmentation validation for service providers | 2–4 working days | from €1,800 |
| Custom / large estate | Multi-site or multi-entity card environment, scoped to your needs | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call — no hourly surprises, and the remediation retest is included. Get a fixed quote
FAQ
How much does PCI DSS penetration testing cost?
Does a PCI DSS pen test replace our ASV scan?
Which PCI requirement does this satisfy?
How often do we need it?
Do you provide an attestation letter for our QSA?
Can you help scope our cardholder data environment?
Will the test disrupt our payment operations?
What if you find something serious?
Related services
Merchants and service providers who store, process or transmit cardholder data and must satisfy PCI DSS requirement 11.4, organisations preparing for a QSA assessment, and any business whose acquirer has asked for evidence of an annual penetration test. We are a European offensive-security team working with clients EU-wide and remotely.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.