PCI DSS testing requirements

Artifacts a PCI DSS assessor requests

For software and testing requirements, a Qualified Security Assessor (QSA) typically requests:

• scope documentation and data flow diagrams for authorisation, capture, settlement, chargebacks, and refunds (12.5.2);
• the inventory of bespoke and custom software and third-party components (6.3.2);
• the payment page script inventory with a written justification for each script (6.4.3);
• code review records for changes released to production (6.2.3);
• the penetration testing methodology (11.4.1);
• internal and external penetration test reports from the last 12 months, and the retest evidence for each exploitable finding (11.4.2 to 11.4.4);
• segmentation test results (11.4.5, and 11.4.6 for service providers);
• ASV scan reports from the last 12 months with passing results, as testing procedure 11.3.2.a and 11.3.2.b describe;
• internal vulnerability scan results and rescans (11.3.1);
• the role and permission matrix for systems in scope (7.2.2);
• from each third-party service provider, its compliance status and responsibility split (12.9.2).

A QSA documents the assessment in a Report on Compliance (ROC). An entity that is eligible to self-assess uses a Self-Assessment Questionnaire (SAQ). Both routes end with an Attestation of Compliance (AOC).

Common PCI DSS findings in payment software

• Card verification code in application logs. Request-body logging on the payment API writes the full card object, including the verification code, to the log platform. The defect breaks 3.3.1.
• Full PAN in webhook and error payloads. A processor error response echoes the PAN, and the service stores the response in a clear-text event table. The defect breaks 3.5.1.
• Full PAN visible to every support role. The support tool masks the PAN in the list view and shows it in full on the detail view. The defect breaks 3.4.1 and 7.2.2.
• Refund on another merchant's payment. The refund endpoint accepts any payment ID and does not check that the payment belongs to the caller. Money leaves through a refund that the payment owner never requested. The defect is a business logic attack that 6.2.4 names.
• Unlisted script on the checkout page. A tag manager adds a marketing script to the payment page outside the script inventory, and no alert fires. The defect breaks 6.4.3 and 11.6.1.
• Production snapshot in staging. A team restores a production database with live PANs into staging to reproduce a settlement defect. The defect breaks 6.5.5.
• Sandbox credentials in production. A release ships with a test merchant account or a test API key enabled. The defect breaks 6.5.6.
• Penetration test older than the checkout rebuild. The last penetration test predates a new payment flow or processor integration. The gap breaks the "after any significant change" condition of 11.4.2 and 11.4.3.
• Finding closed without a retest. A ticket for an exploitable finding moves to "done" after the fix, with no repeated test. The gap breaks 11.4.4.
• Refund and chargeback flows missing from scope. The data flow diagram covers authorisation and capture but omits a third-party dispute tool that receives the PAN. The gap breaks 12.5.2.