PCI DSS PENETRATION TESTING

If your organisation stores, processes, or transmits payment card data, PCI DSS is not optional — and neither is the testing it demands. 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 be quietly broken today, and the standard's answer is to keep proving it — on a schedule, with evidence. The practical problem most organisations face is not understanding that they must test, but producing testing that their QSA (Qualified Security Assessor) will actually 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 generic pentest 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 is built to avoid exactly that: we perform the testing Requirement 11 calls for and deliver the evidence in the shape your QSA needs.

To be clear about roles: Incognito Lab is your penetration testing partner. We are not a QSA and we do not issue your Report on Compliance — your assessor does that. What we do is make their job, and yours, straightforward: 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 authorized and unauthorized (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) — see the next section for how we support that — while 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. This matters commercially as well as technically: 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 — untested surface is agreed up front, not discovered at the assessment.

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, and we will not pretend the distinction away. What we do is take the friction out of the process around it:

• 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 real exposure from noise, 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.

The result: the scan itself is executed by an ASV as the standard requires, and everything around it — scoping, scheduling, remediation, evidence — is handled with you rather than left as homework.

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:

1. 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 no open-ended billing.
2. 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, but every reported issue is validated by hand — no raw scanner output ever reaches the report.
3. Reporting — Findings are written up with reproduction steps, risk ratings, and remediation guidance, framed against the requirement each one affects — so it is obvious not just what is broken, but what it means for your assessment.
4. 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 this step is not a courtesy — 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, not just a technical report that happens to mention PCI. 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, requests, and evidence that reproduce the issue; your engineers should never have to guess how we did it.
• Remediation guidance — practical fixes for your environment, not scanner boilerplate.
• 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

Testing is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination, not multiple-choice exams. See the full list of certifications the team holds.

Standards

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. Penetration testing is one requirement among twelve, though — 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. Testing proves the controls hold today; the programme keeps them holding between assessments.