Sites and checkout
The pages that collect orders and payment data, including basket, summary and confirmation pages.
PCI DSS v4.0.1 · Requirement 11.4 · E-commerce · From €490
PCI DSS penetration test for e-commerce and payment applications
Requirement 11.4 of PCI DSS v4.0.1 calls for periodic penetration testing and after significant changes. We provide the external technical verification of the perimeter that handles payments, with a report and a signed letter of attestation to share with your QSA or your acquirer.
What requirement 11.4 asks for
The requirement calls for external and internal penetration tests on the environment that holds cardholder data, with a defined methodology, repeated at least every twelve months and after significant changes to infrastructure or applications. Exploitable vulnerabilities must be corrected and re-tested.
Our service covers the external part of the perimeter: the sites, the checkout, the payment APIs and the applications exposed to the internet. It is a technical piece of evidence, which the QSA assesses together with the rest of the compliance programme.
The payment perimeter: what to include
The most important work is defining the perimeter well. A test on a site that does not handle payments does not demonstrate the requirement, and a perimeter that is too narrow leaves the weak point out.
APIs and connected services
The APIs that manage orders, payments, refunds and customer profiles, when they are exposed to the internet.
Customer area and accounts
Login, password recovery, management of saved payment methods and access control between customers.
Third-party integrations
Scripts and components from third parties that run on the payment page. They belong in scope if they are in the data flow.
What we verify in a payment environment
The tests follow the OWASP Top 10 and the OWASP WSTG, with particular attention to the controls that protect payment data.
Authentication and sessions
Login robustness, token handling, session expiry, and protection against the reuse of stolen or replayed sessions.
Access control
One customer must not be able to read another customer's orders, addresses or payment methods, even by changing an identifier.
Validation and injection
Search fields, filters, basket and checkout parameters, checked against injection and manipulation of prices or quantities.
Configuration and transport
TLS protocols and ciphers, security headers, cookies with the correct attributes, and error messages that do not reveal internal details.
How we work on the payment perimeter
The test follows the phases of a web penetration test, with attention to payment flows. We do not run real payment transactions and we do not ask for customers' card data.
- Written scope: perimeter, flows to test and time windows, signed before the start.
- Test accounts: with different roles, created by the client in the agreed environment.
- Controlled tests: no destructive attacks and no denial of service against payment systems.
- Manual validation: every relevant vulnerability is reproduced before it enters the report.
- Retest: free re-verification within 30 days after the fixes.
What the service does not replace
The full PCI DSS programme requires other activities, which are not part of our external service.
The QSA assessment
Compliance validation is the responsibility of your QSA or your acquirer, who decides which evidence to accept.
The ASV scan
Where it applies, the quarterly external vulnerability scan is a separate activity, run by an accredited ASV.
Internal testing and segmentation
The requirement also asks for internal tests and for verification that segmentation isolates the cardholder data environment. These are separate services, quoted on request.
Policies and training
Many requirements concern processes, roles and documentation, which remain the responsibility of the organisation.
What to prepare before the test
Orderly preparation shortens the timeline and avoids interruptions in the payment environment.
The data-flow diagram
Even a simple sketch of how payment data enters, moves through and leaves the site helps define the scope.
A test environment
We prefer a test environment equivalent to production, with dummy data. Testing in production requires windows and authorization.
Test accounts
At least two test customers and an administrative profile, if the site has a management area.
A technical contact
Someone who answers questions and can intervene if a test affects a live service.
How much it costs
The Single perimeter plan costs €490 one-off, VAT excluded, for one external domain or application with its subdomains. Larger payment environments, internal testing and segmentation are quoted on request. The full price list is on the home page.
Frequently asked questions on PCI DSS and penetration testing
Does a penetration test alone achieve PCI DSS compliance?
No. Validation depends on your QSA or your acquirer. Our report is technical evidence for that assessment, not a certification.
How often must it be done?
PCI DSS v4.0.1 requires penetration testing at least every twelve months and after significant changes to infrastructure or applications, with correction and re-testing of exploitable vulnerabilities.
Is internal testing also needed?
For the full requirement, yes. Internal testing is a separate service with its own perimeter and quote.
Does the test use real payment cards?
No. We do not run real transactions and we do not ask for customers' card data. The test checks the controls of the payment flow in an agreed environment.
How long does the report take?
We deliver the report within 5 working days of the signed authorization, with a free re-verification within 30 days of the fixes.
Need to prove requirement 11.4 to your acquirer?
Send us the payment perimeter: we reply in writing with what is needed and what we would verify.
Request the verification