Peak Security
Book a call
Back to home
Compliance / PCI DSS

PCI DSS penetration testing for the apps that touch card data.

Requirement 11.4 asks for a penetration test at least every 12 months and after significant changes, plus a retest of what you fix. We test your payment-facing web apps and APIs and give your assessor the evidence.

Book a 30-minute callSee a sample report

What PCI DSS asks for.

PCI DSS v4 is specific: a defined methodology, internal and external testing, application-layer coverage, and retesting.

12 mo

Requirement 11.4: test at least once every 12 months and after any significant change.

11.4.4

Exploitable vulnerabilities must be corrected and the fix verified by retesting.

6 mo

How often service providers must test segmentation controls under 11.4.6.

Requirement 11.4.1 says the methodology must cover the application layer and the network layer. Testing must come from a qualified tester who is organizationally independent. Requirement 6.4 adds protection for public-facing web applications.

We cover the application layer: the checkout, account, and API paths where card data and payment authority live. If your scope also needs network-layer or segmentation testing, we will say so on the scoping call and plan for it.

PCI DSSWhat we testEvidence
11.4.1Documented, industry-accepted methodologycovered
11.4.3External test of internet-facing appscovered
6.4.1Public-facing web app assessmentcovered
11.4.2Internal testing from inside the CDEscoped
11.4.5Segmentation control testingscoped
11.4.4Exploitable findings fixed and retestedretest

What we test.

We focus on the application layer, where most real breaches of customer data start: accounts, permissions, and the APIs behind the interface.

Payment flows

Checkout, saved cards, refunds, and payouts. Can a user act on a payment or card that is not theirs?

Account takeover paths

Password reset, session handling, and MFA, where one weak step leads to a customer's stored payment methods.

APIs and integrations

Payment APIs, webhooks, and admin endpoints that trust IDs or callers they should not.

Data exposure

Responses, exports, and logs that return card or customer data beyond what the screen shows.

From scoping call to evidence file.

One engagement produces the report your auditor reads and the retest that shows the fixes worked.

  1. 01
    Scope

    We map the systems in your audit scope to what we test, and agree on accounts, limits, and dates.

    30-minute call
  2. 02
    Test

    Agents and researchers work the agreed apps and APIs. A human reproduces every finding.

    Test accounts only
  3. 03
    Report

    Methodology, scope, dates, and per-finding evidence with a fix your engineers can apply.

    Auditor-ready
  4. 04
    Retest

    After you fix, we retest the same paths and record the result for your evidence file.

    Closes the loop

Questions teams ask first.

Is this a full PCI DSS penetration test?
We cover the application layer of Requirement 11.4: the web apps and APIs in or connected to your cardholder data environment. Network-layer and segmentation testing depend on your environment, and we confirm on the scoping call whether your test needs them.
Are you a QSA?
No. A penetration test does not have to come from a QSA. It must come from a qualified, organizationally independent tester. Your QSA reviews our report as part of your assessment.
What counts as a significant change?
New payment features, infrastructure moves, new third-party integrations, and authentication changes usually do. Your QSA makes the final call. We can test just the changed area between annual tests.
Will you touch real card data?
No. We use test accounts and test cards in an agreed environment, and we avoid live cardholder data.

Get your test on the calendar.

Tell us your audit window and what is in scope. We will tell you what to test first and what the report needs to show.

Book a 30-minute callHow to prepare