ESSENTIAL GUIDANCE · BUYER GUIDE · 3 min read
Part of Validate insights →PCI DSS penetration testing scope and evidence
Plan payment-security testing around the cardholder-data boundary, segmentation, change and assessor-ready evidence.
Plan payment-security testing around the cardholder-data boundary, segmentation, change and assessor-ready evidence.
Need an acronym translated?Open the cyber glossary →Confirm the applicable payment-security assessment
Start with the payment flows, the organisation's responsibilities and the current applicable PCI DSS documents. Confirm the validation route and assessment expectations with the appropriate payment-assurance stakeholders. A penetration test is one form of security evidence; it does not replace the complete PCI DSS assessment or award compliance. Keep the test engagement and the compliance determination separate.
Map the cardholder-data environment and dependencies
Document systems that store, process or transmit payment account data, alongside systems that can affect their security. Include relevant administration, identity, connectivity and supplier arrangements. Do not assume the assessment boundary is simply the public checkout URL. A scope discussion should explain the relationship between the internet-facing application, internal services and the payment environment.
Distinguish scanning testing and segmentation assurance
Vulnerability scanning and penetration testing answer different questions and should not be treated as interchangeable report labels. Where segmentation is relied upon, identify the separation that needs to be demonstrated and the relevant starting positions. Document which interfaces, network paths and roles are covered. Ask the assessor how the evidence relates to the applicable requirements rather than assuming one generic report satisfies every testing obligation.
Plan the timing and follow-up evidence
Use the applicable standard and assessor's interpretation to establish the relevant recurring, change-related and remediation checks. Record what changed between assessments and whether the previous scope still represents the environment. Resolve material findings and retain the appropriate retest evidence. A report date alone does not explain whether an important new component or a revised segmentation design was included.
Make the report traceable to the scope
Keep the approved boundary, methods, test period, limitations, findings and follow-up together. The reader should be able to identify which requirement or assurance question each piece of evidence addresses. Use current PCI SSC resources when confirming requirements. Avoid presenting a general infrastructure test, a scan or an outsourced payment integration as automatic evidence that the entire organisation is compliant.
This guide covers the essentials. Continue into our technical analysis for a firmer position, practical implications and recommended action.
Read “Modern penetration testing should create decisions, not just findings” →
