Cybersecurity · Security Testing
Your assessor will check four things: the methodology, the scope, the tester's independence, and whether findings were corrected. Unlike SOC 2 or HIPAA, PCI DSS names the penetration test outright: Requirement 11.4 requires external and internal testing at least annually and after significant changes, on a documented, industry-accepted methodology. This is testing to a specification, the specification is public, and we test to it.
Independent quality engineering & cybersecurity since 2020, with 100+ security & quality engineers, delivering on platforms we build and run ourselves.
A pentest that doesn't meet the requirement is money spent twice. A vulnerability scan submitted as a penetration test, an undocumented methodology, or a tester who isn't independent of the systems under test can each send you back for another engagement, on the assessor's timeline.
See a redacted sample report
The structure, depth, and remediation detail your team will receive, with client identity and evidence removed. No form, no email: the download is open.
Requirement 11.4 calls for penetration testing from outside and inside the network at least annually and after any significant infrastructure or application change. We scope both perspectives against your cardholder data environment and run on your change cadence as well as the calendar.
PCI DSS v4.x requires your penetration-testing methodology to be defined and documented, based on industry-accepted approaches. The PCI Council's own guidance lists NIST SP 800-115, the OWASP Testing Guide, and PTES among them. Those are the methodologies our testing is already aligned to.
If segmentation isolates your cardholder data environment and shrinks your PCI scope, those controls must be tested to prove they hold. Under v4.x, multi-tenant service providers must confirm the logical separation of customer environments via penetration testing at least once every six months.
PCI DSS expects penetration-test findings to be corrected in line with your assessment of the risk they pose, and the fix verified. Retest is included as standard here, and each corrected finding is closed out as verified in the final report your assessor reads.
01
The cardholder data environment, segmentation boundaries, and both testing perspectives agreed in writing with the testers.
02
External and internal assessment on the documented methodology 11.4.1 expects, with daily contact for critical findings.
03
Findings ranked by exploitability, with methodology and tester independence documented for your assessor.
04
Corrections verified in line with 11.4.4 and the report updated before it reaches the QSA.
Engagement
Buy it as a scoped project, embed it in your team, or run it as a managed service. The engineers and the governance stay the same, whichever shape fits.
One scoped assessment with a full report and one retest: for a release gate, a customer or audit requirement, or an annual baseline.
Recurring cycles matched to your release cadence, each closed by a retest, so the newest report is never far behind the newest release.
A new application, API, or environment joins the existing program without re-contracting; scoping starts in days.
PCI DSS treats them as different exercises with different requirements and frequencies. The Council's own penetration-testing guidance draws the line: a vulnerability scan identifies, ranks, and reports vulnerabilities, while a penetration test attempts to exploit them to show what an attacker could reach. Requirement 11.4 asks for the penetration test; scanning is a separate obligation.
PCI DSS allows a qualified internal resource or a qualified external third party, provided the tester is organizationally independent of the management of the systems being tested. As an independent testing partner we sit cleanly on the right side of that line, and the report documents tester qualifications and independence, which assessors check.
Yes, where segmentation is part of your scope. If segmentation controls isolate the cardholder data environment, testing verifies they actually hold from an attacker's position, and for multi-tenant service providers, v4.x expects logical separation of customer environments to be confirmed via penetration testing at least once every six months.
Remediation of reported findings is verified and the report updated to 'remediated and retested', the wording auditors expect. Retest scope and window are set in the engagement agreement.
Engagements run under NDA, and engineers who handle client data undergo background checks. Findings and reports are shared through channels agreed at scoping and are not retained beyond the period needed to deliver and support the engagement. Data-handling specifics (storage, encryption, retention, and destruction) are documented in your service agreement; see the Trust page for our posture.
This is one stage of a single assurance loop: findings become regression tests, and their indicators become live detections, so a problem, once fixed, can’t quietly come back. A stack of separate vendors has no way to close that loop. See how the loop connects →
Bring your assessment timeline and your cardholder-data-environment boundaries. Testing runs on the documented methodology your QSA will check for, with corrections verified on retest.