Is your app part of the cardholder data environment? We run the application-layer penetration test that requirement 11.4 calls for, on your app and its API, as an organizationally independent team.
For entities whose mobile app or its API is part of the cardholder data environment.
PCI DSS v4.0 requires penetration testing of the systems in scope, including the application layer:
The test does not have to be run by a QSA, only by a qualified, organizationally independent tester. We are an external, independent team, and our report is the penetration test your file and your QSA rely on for requirement 11.4.
We check whether an attacker can reach cardholder data through your app or its API. Depending on the agreed scope, testing can cover:
States the scope, the build and the interfaces tested, and the result, written so it supports your requirement 11.4 evidence. Every finding includes evidence, reproduction steps, impact, a CVSS score and vector, CWE and, where they apply, OWASP MASWE references, and how to fix it.
Covers the scope and build tested, the results and the priorities, for management and non-technical readers.
If you include the retest, we send a new version of the report with the status of each finding on the new build.
Requirement 11.4 asks for a qualified resource that is independent of the team that built the app. We are an external, independent team, and the report sets out the scope, the tests and the results, so your QSA and your file can rely on it.
Our team comes from security certification laboratories, with experience in mobile payment standards such as EMVCo SBMP and in Common Criteria. We contribute to OWASP Mobile Application Security, and OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Chameleon gives us deep visibility into what your app does inside the operating system, which makes the analysis faster and more thorough. The controls that usually slow testing down, such as root, pinning and anti-instrumentation checks, are handled at the OS level by default, so our time goes into finding issues in your app instead of getting past them.
Meet the teamNo. Requirement 11.4 asks for a qualified resource that is organizationally independent of the team that developed the app, which we are. The overall PCI DSS attestation (the Report on Compliance) is signed by a QSA; we are not a QSA, and our penetration test is the testing evidence your QSA and your file rely on.
Requirement 6.2.3 is a separate development control: bespoke and custom code must be reviewed before release, by manual or automated code review. That is distinct from the 11.4 penetration test, which is method-agnostic, so black-box testing satisfies 11.4. If you also need the 6.2.3 code review, we can review the source code.
They can be, and we generally recommend it: much of a mobile app's risk lies in the APIs it uses. We decide it with you case by case, depending on the type of app and what its backend exposes.
For the 11.4 penetration test, no: by default, testing is black-box, with the same build you release to your users. For the 6.2.3 code review, we review the source code. If you share the code for the pentest too, we use it.
Yes. Download our sample report, a real deliverable from a full assessment of a deliberately vulnerable app.
When needed. On Android we mainly work with Chameleon, our analysis environment: it gives us deep visibility into what the app does in the operating system, and handles root, pinning and anti-instrumentation checks at the OS level by default. If we hit a limitation that matters for your app, we use physical devices. On iOS we use physical devices.
This service is the application-layer penetration test for requirement 11.4. If you accept card payments on phones and need a listing, that is a different standard: our PCI MPoC vulnerability assessment and penetration testing covers requirements 1A-1.3 and 4A-3.1 before the laboratory evaluation.
It depends on the number of apps and platforms, the complexity of your app and the backend interfaces in scope. We send you a proposal with a fixed price and the schedule. It usually takes one to two weeks per platform, report included. We can usually start the same week you accept the proposal; the start date depends on our team's workload and is stated in the proposal.
Retesting is quoted separately at a reduced rate. In the proposal we give you two options, testing only or testing with one retest round, so you know the total cost from the start.
You receive one report per platform, with every finding detailed. If you also want to use them in your own tools, we provide them as CSV or JSON too.
English by default. If you need it in Spanish, just tell us.
We agree confidentiality terms before you share builds or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Tell us about your app and its place in the cardholder data environment. We reply within one business day to arrange a scoping call.
Talk to our team