PCI DSS PENETRATION TESTING
Requirement 11 network, application, and segmentation testing plus ASV scan support, with deliverables built for your QSA.
If your organisation stores, processes, or transmits payment card data, PCI DSS applies to you, and so does the testing it requires. Requirement 11 of the standard, "Regularly test security systems and processes", exists because the environment around cardholder data never stands still: new systems are deployed, firewall rules change, wireless networks appear, and vulnerabilities are published daily. A control that was effective at last year's assessment may have broken since, so the standard requires testing on a schedule, with evidence. Most organisations know they must test; the harder part is producing testing that their QSA (Qualified Security Assessor) will accept: correctly scoped to the cardholder data environment (CDE), performed with a recognised methodology, and documented in a form that maps cleanly to the requirement. A report that never mentions segmentation, ignores the CDE boundary, or arrives without retest evidence sends you back for another round, on the assessor's clock, close to your compliance deadline. Our PCI DSS penetration test performs the testing Requirement 11 calls for and delivers the evidence in the shape your QSA needs.
Incognito Lab is your penetration testing partner, not a QSA, and we do not issue your Report on Compliance; your assessor does that. We provide testing scoped the way the standard expects, findings your team can fix, and deliverables an assessor can take at face value. For a plain-language walkthrough of how the standard is structured and who the parties are, our team wrote a primer: an introduction to PCI DSS.
What Requirement 11 asks for
Under the current PCI DSS v4.0.1 standard, Requirement 11 drives four distinct testing activities, each with its own cadence. Our service covers all four:
Wireless access point testing
Testing for the presence of both authorised and unauthorised (rogue) wireless access points, on a quarterly basis. A rogue access point plugged into a CDE-connected network is a direct bridge past your perimeter, which is why the standard insists on looking for them regularly rather than assuming the inventory is accurate.
Network vulnerability scans
Internal and external network vulnerability scans, at least quarterly and after any significant change. The external quarterly scan must be performed by a PCI-approved Approved Scanning Vendor (ASV); the next section covers how we support that. Internal scans verify that the systems inside your environment are patched and configured as the standard requires.
Penetration testing
External penetration testing and internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification. This is where a human tester goes beyond what a scanner reports: chaining weaknesses, validating exploitability, and testing the applications and networks that touch cardholder data the way a real attacker would.
Segmentation testing
Where segmentation is used to isolate the CDE from other networks, the segmentation controls themselves must be penetration tested at least annually and after any change to them. The goal is to verify the segmentation is operational and effective: that systems you have declared out of scope genuinely cannot reach the CDE. Your entire scope-reduction argument, and the assessment cost that follows from it, rests on segmentation actually holding.
If you are unsure which of these applies to your environment, or on what schedule, that is a scoping conversation we have with you before any proposal is written, and anything left out of scope is agreed at that stage.
ASV scan support
The external quarterly vulnerability scan occupies a special position in the standard: it must be run by an Approved Scanning Vendor, a company certified by the PCI Security Standards Council to operate that specific scan. Incognito Lab is not an ASV. We support the process around the scan:
Coordination
We help you set up and schedule the ASV scans, define the external scope correctly, and manage the quarterly cadence so a missed window does not surface at assessment time.
Remediation
ASV scan results arrive as raw findings; a failing scan blocks your compliance. We interpret the results, separate genuine exposure from false positives, guide your team through the fixes, and support the rescan until you have a passing attestation.
Alignment
The ASV scan, the internal scans, and the penetration testing all describe the same environment. We make sure they tell one consistent story, because inconsistencies between them are exactly what an assessor will probe.
How we work
Under the PCI-specific framing, the underlying tests are the same engagements we run every day: our infrastructure penetration test covers the internal and external network testing, and our web application penetration test covers the applications that store, process, or transmit cardholder data, both scoped to the CDE and its connected systems. Every engagement runs through the same phases:
Scoping
We map the CDE with you: which systems store, process, or transmit cardholder data, which systems connect to them, where the segmentation boundaries sit, and which of the four Requirement 11 activities the engagement must cover. This is also where we align with your assessment timeline, so testing and retest both land before your QSA needs the evidence.
You get a proposal with a fixed timeline and price.
Testing
External and internal penetration testing against the agreed scope, wireless access point testing across your facilities, and segmentation testing that actively attempts to cross from out-of-scope networks into the CDE.
Automated tooling assists with coverage, and every finding in the report has been validated by hand.
Reporting
Findings are written up with reproduction steps, risk ratings, and remediation guidance, framed against the requirement each one affects, so it is clear what is broken and what it means for your assessment.
Remediation support & retest
Your team fixes the findings; we answer questions along the way, then retest and update the report to show what has been closed.
For PCI, evidence that identified issues were corrected and re-verified is part of what your assessor expects to see.
What you get
Deliverables are developed to address what the QSA needs: evidence an assessor can accept for the assessment. Every report contains, at minimum:
Executive summary
The business-level risk picture, suitable for management and your assessor.
Findings by Risk Level
Each issue rated Critical, High, Medium, or Low so remediation can be prioritised objectively.
POC for every finding
The exact steps to reproduce each finding, with requests and evidence.
Remediation guidance
Practical fixes for your environment.
Retest verification
Findings are re-checked after your fixes and the report is updated to reflect closed items, giving your assessor the corrected-and-verified trail the standard expects.
Segmentation test evidence
Where segmentation is in scope, explicit documentation that the controls were tested and that out-of-scope systems could not reach the CDE.
Team credentials
- OSCP
- OSCE
- CREST CRT
- CREST CPSA
- GIAC GREM
Testing is performed by our in-house team, with certifications earned through hands-on practical examination. See the full list of certifications the team holds.
Our methodology follows NIST SP800-115 (Technical Guide to Information Security Testing and Assessment), with scope, cadence, and reporting aligned to PCI DSS Requirement 11 under the current v4.0.1 standard.
Related services
Infrastructure penetration test
Covers the internal and external network testing.
Web application penetration test
Covers the applications that store, process, or transmit cardholder data, scoped to the CDE and its connected systems.
Consulting
Penetration testing is one requirement among twelve. If you are earlier in the journey, still defining your CDE, or building the broader security programme the standard sits inside (policies, ISMS, ISO/IEC 27001), that work is handled by our consulting team.
Last reviewed: 12 Oct 2026
PCI DSS Penetration Test
Tell us which Requirement 11 activities apply to your environment. We map the CDE with you and propose a plan with a fixed timeline and price.
Frequently asked questions
Do you help us define our CDE scope?
Yes, scoping is where a PCI engagement is won or lost. We map the cardholder data environment (CDE) with you: which systems store, process, or transmit cardholder data, which connect to them, where the segmentation boundaries sit, and which of the four Requirement 11 activities the engagement must cover. We align with your assessment timeline too, so testing and retest both land before your QSA needs the evidence.
What does PCI DSS Requirement 11 require you to test?
Under PCI DSS v4.0.1, Requirement 11 drives four testing activities, each on its own cadence: wireless access point (rogue AP) testing quarterly; internal and external network vulnerability scans at least quarterly and after significant change; external and internal penetration testing at least annually and after significant change; and segmentation testing at least annually (every six months for service providers) where segmentation isolates the CDE. Our service covers all four, with the external quarterly scan executed by an approved ASV that we coordinate.
Will the deliverables be accepted by our QSA?
Deliverables are developed to address what the QSA needs: evidence an assessor can accept. Findings are framed against the requirement each one affects, and retest evidence shows that identified issues were corrected and re-verified, which is part of what your assessor expects to see.
Related articles

ARTICLES/19 May 2025
มหาวิทยาลัยทักษิณ เดินหน้าสู่ ISO/IEC 27001:2022
อินค็อกนิโตแล็บร่วมโครงการพัฒนาระบบบริหารจัดการความมั่นคงปลอดภัยสารสนเทศของมหาวิทยาลัยทักษิณ ตามมาตรฐาน ISO/IEC 27001:2022 พร้อมงาน Cyber Drill และ Pentest

ARTICLES/12 Nov 2012
PCI DSS คืออะไร มาตรฐานความปลอดภัยข้อมูลบัตรชำระเงิน และข้อมูลที่เข้าข่าย
PCI DSS คือมาตรฐานความปลอดภัยข้อมูลบัตรชำระเงินที่เริ่มในปี 2006 โดยห้าค่ายบัตรใหญ่ บทความอธิบายที่มา ระบบแบบไหนเข้าข่าย และข้อมูลบัตรที่มาตรฐานนี้คุ้มครอง
Tell us about your cardholder data environment
We map the CDE with you and propose a plan with a fixed timeline and price.

