Service

PCI-DSS
Penetration Testing

> nmap -sV -p 80,443,8443 --script=http-card-* merchant.co.uk_

PCI-DSS compliance isn't a box-ticking exercise — it's the difference between keeping and losing the ability to accept card payments. Non-compliance doesn't just risk fines; it risks your merchant account. We make sure you pass — properly.

The cost of compliance is small. The cost of losing card payments is everything.

Here's the asymmetry that should keep every CFO awake: a PCI-DSS penetration test costs a fraction of a single day's card revenue. Losing your merchant account costs you every card transaction, indefinitely. That's not a risk calculation — it's a conclusion. The only rational move is compliance.

The Payment Card Industry Data Security Standard exists because card data is the most liquid asset a criminal can steal. Unlike intellectual property or personal data, stolen card numbers are monetised within hours. PCI-DSS is the industry's answer — a set of requirements designed to ensure that merchants and service providers handle card data with the rigour it demands.

Penetration testing is a core requirement of PCI-DSS — not a nice-to-have, not a recommendation, but a mandatory control. Requirement 11.3 specifically mandates regular penetration testing of the cardholder data environment. Our testing is designed to satisfy your QSA, your acquirer, and — most importantly — to actually find the vulnerabilities that put card data at risk.

The Behavioural Economics of PCI

People systematically underweight low-probability, high-impact events. That's why businesses under-invest in PCI compliance until the acquirer sends a warning letter. But here's what loss aversion teaches us: the pain of losing card processing is orders of magnitude greater than the cost of maintaining it. A PCI penetration test doesn't cost money — it prevents the loss of your entire card revenue stream. Reframe the cost and the decision becomes trivially obvious.


Twelve requirements, one that needs us.

PCI-DSS v4.0 comprises twelve high-level requirements grouped into six control objectives. Penetration testing sits within Requirement 11 — "Test Security of Systems and Networks Regularly" — but touches several others. Here's the landscape:

Control Objective Requirements Pen Test Relevance
Build & Maintain Secure Network Req 1: Network security controls
Req 2: Secure configurations
Directly tested — firewall rules, default credentials, network segmentation.
Protect Account Data Req 3: Protect stored account data
Req 4: Encrypt transmission
We verify encryption implementations and test for data exposure in transit and at rest.
Maintain a Vulnerability Management Programme Req 5: Malware protection
Req 6: Secure systems & software
Application-layer testing validates secure development practices and patching.
Implement Strong Access Control Req 7: Restrict access
Req 8: Identify users
Req 9: Physical access
Authentication testing, privilege escalation, and access control bypass attempts.
Monitor & Test Networks Req 10: Log & monitor
Req 11: Test security regularly
This is us. Requirement 11.3 mandates penetration testing of the CDE.
Maintain a Security Policy Req 12: Organisational policies Our reporting supports your policy evidence and risk assessment documentation.

The requirement that demands a qualified tester.

PCI-DSS Requirement 11.3 (v4.0: 11.4) is specific and unambiguous. It requires penetration testing of the cardholder data environment at least annually, and after any significant infrastructure or application change. The testing must be performed by a qualified internal resource or qualified external third party. We are that third party.

The requirement mandates that penetration testing must cover the entire CDE perimeter and critical systems, test both from inside and outside the network, validate network segmentation controls, and include application-layer testing. It's not enough to run a scanner — the PCI Council explicitly requires manual testing techniques.

PCI-DSS 11.3 / 11.4 Requirements
11.4.1 # Pen test methodology defined, documented, implemented
11.4.2 # Internal pen testing performed per methodology
11.4.3 # External pen testing performed per methodology
11.4.4 # Exploitable vulns found in testing are corrected & retested
11.4.5 # Segmentation controls tested every 6 months (service providers)
11.4.6 # Testing repeated after significant changes

Every angle the QSA will ask about.

Our PCI-DSS penetration testing covers every component the standard demands — and several it doesn't but should. We test your CDE as an attacker would target it, not as an auditor would describe it.

External Testing
Internet-facing systems in the CDE perimeter — web servers, payment gateways, APIs, VPN endpoints, and any system reachable from outside your network. We test for vulnerabilities that would allow an external attacker to breach the CDE and access cardholder data.
Internal Testing
Testing from inside your network — simulating a compromised workstation, rogue insider, or attacker who has breached the perimeter. We attempt to reach the CDE from non-CDE network segments, escalate privileges, and access cardholder data from within.
Segmentation Validation
If you use network segmentation to reduce your CDE scope, PCI-DSS requires that segmentation controls are tested to confirm they actually work. We verify that out-of-scope networks genuinely cannot reach CDE systems — because a segmentation failure means your entire network is in scope.
Wireless Assessment
Rogue access point detection, wireless encryption assessment, WPA2/WPA3 configuration review, and testing whether wireless networks can reach the CDE. A single misconfigured access point can bridge an air gap that your entire segmentation strategy depends on.
Application Layer
Payment pages, checkout flows, tokenisation implementations, and any application that processes, stores, or transmits cardholder data. We test against the OWASP Top 10 and PCI-specific application controls to ensure your code doesn't undermine your infrastructure security.
Authentication & Access Controls
Multi-factor authentication testing, password policy validation, session management review, and privilege escalation attempts. PCI-DSS requires strong access controls around the CDE — we verify they hold up under adversarial pressure, not just compliance review.

Reports your assessor will actually accept.

We've seen organisations spend thousands on penetration tests only to have their QSA reject the report because it didn't meet PCI-DSS documentation requirements. Our reports are built specifically to satisfy QSA expectations — because a test that doesn't satisfy the assessor is a test you'll have to pay for twice.

Report Contents
EXECUTIVE_SUMMARY # Business-level risk overview for leadership
SCOPE_DEFINITION # CDE boundary, in-scope systems, IP ranges
METHODOLOGY # Testing approach mapped to PCI-DSS requirements
FINDINGS # CVSS-scored vulnerabilities with evidence
SEGMENTATION_RESULTS # Pass/fail for each segmentation control tested
REMEDIATION_GUIDANCE # Prioritised fix recommendations per finding
RETEST_CONFIRMATION # Verification that critical/high findings are resolved
ATTESTATION # Formal statement of testing completeness

For continuous monitoring between annual PCI-DSS assessments, see our SOCinaBox managed SOC service — 24/7 monitoring of your CDE for suspicious activity, ensuring you maintain compliance posture year-round, not just on assessment day.

Continuous PCI Compliance

PCI-DSS Requirement 10 demands continuous log monitoring. Combine your annual penetration test with SOCinaBox to satisfy both requirements with a single relationship. The pen test validates your controls. The SOC ensures they keep working 365 days a year. Your QSA will appreciate the joined-up approach.


Explore more.


Your next PCI assessment is coming. Are you ready?

Every engagement starts with a free scoping call. We'll review your CDE, define the testing scope, and provide a clear quote aligned to your PCI-DSS level. Don't wait for the QSA to find the gaps — let us find them first.