PCI DSS Requirement 11.3 asks for penetration testing that is methodical, scoped to the cardholder data environment, and repeated when things change. We meet that requirement to the letter and then keep going, because a test that clears an assessor but misses an exploitable path has protected the audit and not the cards. Every finding is exploited, proven and written for QSA review.
Requirement 11.3 testing
We run the annual and post change testing the standard mandates, scoped to the cardholder data environment and its connected systems, so your assessment rests on real coverage rather than a partial sweep.
- Annual testing across the full cardholder data environment as Requirement 11.3 defines it
- Post change testing after significant infrastructure or application changes, on the schedule the standard requires
- A documented methodology aligned to 11.3, so your QSA can trace scope, coverage and rigour
Network and application layer testing
Requirement 11.3 covers both layers, and so do we. We test the perimeter and internal network paths into the environment, and the applications that handle cardholder data, because attackers do not respect the boundary between the two.
- Network layer testing of external and internal exposure into the cardholder data environment
- Application layer testing of authentication, authorization, business logic and data handling
- Chained attack paths that cross from network exposure to application compromise, proven end to end
Segmentation controls validation
If segmentation is what keeps systems out of scope, it has to actually hold. We test the controls that separate the cardholder data environment from the rest of your network and prove whether the isolation your scope depends on is real.
- Segmentation testing that confirms out of scope systems cannot reach the cardholder data environment
- Verification of the controls your scope reduction relies on, with proof for your QSA
- Clear evidence where a supposed boundary can be crossed, before an assessor or an attacker finds it
Remediation verification and retesting
The standard expects exploitable findings to be corrected and confirmed. We track each result to a verified fix and retest to prove closure, so your assessment shows resolved risk rather than an open list.
- Remediation guidance your engineers can ship, not a generic reference link
- Free retest and verified closure of every exploitable finding
- A closure record your QSA can rely on during assessment
Audit ready reports
The report is structured for QSA review from the first page. Scope, methodology, findings and closure are laid out the way an assessor reads them, so the document supports your assessment instead of generating questions.
- Reporting structured for QSA review, mapped to Requirement 11.3
- Exploitable risk ranked by impact, with reproducible proof
- Scope, methodology and closure evidence an assessor can attach as is
FAQ
Does this meet Requirement 11.3?
Yes. We deliver the annual and post change testing 11.3 requires, across the network and application layers, with segmentation validation and a methodology your QSA can trace.
Do you test segmentation for scope reduction?
Yes. We validate that out of scope systems cannot reach the cardholder data environment, and we give your QSA proof of whether the isolation holds.
Is retesting included?
Yes. Free retest and verified closure of every exploitable finding are part of the engagement, recorded for your assessment.