Cybersecurity · Security Testing
Unlike SOC 2 or HIPAA, PCI DSS is explicit: Requirement 11.4 requires external and internal penetration testing at least annually and after significant changes, on a documented, industry-accepted methodology. Your QSA will check the methodology, the scope, the tester's independence, and whether findings were corrected — this is testing to a specification, and the specification is public.
Independent quality engineering & cybersecurity since 2020 — 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, not yours.
See a redacted sample report
The structure, depth, and remediation detail your team will receive — client identity and evidence removed.
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, not just a 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: the final report your assessor sees says 'remediated and retested.'
01
A scoping call with the testers themselves — targets, rules of engagement, and what evidence you need out.
02
Manual assessment aligned to OWASP, PTES, and NIST SP 800-115, with daily contact for critical findings.
03
Findings ranked by exploitability and impact, each with reproduction and remediation guidance.
04
Verification of fixes and an updated report — the cycle then repeats on your release cadence.
Engagement
Buy it as a scoped project, embed it in your team, or run it as a managed service — same engineers, same governance, whichever shape fits.
A scoped, one-time assessment with a full report and one retest — for a release gate, a customer or audit requirement, or an annual baseline.
Recurring assessment cycles aligned to your release cadence, with retesting each cycle so the evidence stays current across surveillance audits.
Add an application, API, or environment to an existing program without re-contracting — scoped and started in days, not procurement cycles.
No — 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 actually 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.
Yes. 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. That’s what you get from one integrated partner that a stack of separate vendors can’t. See how the loop connects →
A 30-minute call with the engineers who will do the testing — not a sales gate.