PCI DSS Audit: Requirements, Penetration Testing, and How to Pass Your Compliance Assessment

Your organisation processes credit card payments. That means PCI DSS applies. At some point, an auditor (either your Qualified Security Assessor or your internal team conducting a Self-Assessment Questionnaire) will evaluate whether your environment meets every applicable PCI DSS requirement. If it doesn't, you face remediation timelines, potential fines from card brands, and in extreme cases, loss of the ability to process card payments.

The PCI DSS audit process examines twelve requirement categories covering everything from firewall configuration to employee security training. But the requirement that catches most organisations off guard is Requirement 11: "Test Security of Systems and Networks Regularly." Specifically, Requirement 11.3 mandates penetration testing, and Requirement 11.2 mandates vulnerability scanning, on defined schedules with specific scope requirements.

Penetration testing isn't optional under PCI DSS. It isn't a best practice recommendation. It's a defined requirement with specific scope, frequency, and methodology expectations that QSAs validate during every audit. Organisations that skip it, scope it incorrectly, or conduct it with insufficient depth face audit findings that delay certification and create compliance gaps.

This guide covers the complete PCI DSS audit process, breaks down every requirement category, explains exactly what Requirement 11 mandates for penetration testing and vulnerability scanning, provides a practical audit checklist, and outlines how to prepare for and pass your PCI DSS compliance assessment.

PCI DSS Overview: What the Standard Requires

PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards maintained by the PCI Security Standards Council (PCI SSC) designed to protect cardholder data. PCI DSS applies to every organisation that stores, processes, or transmits cardholder data, regardless of size or transaction volume.

PCI DSS 4.0: The Current Standard

PCI DSS 4.0 became mandatory on March 31, 2024, replacing version 3.2.1. PCI DSS 4.0 introduced a "customised approach" allowing organisations to meet security objectives through alternative controls alongside the traditional "defined approach." Future-dated requirements under PCI DSS 4.0 become mandatory on March 31, 2025.

The 12 PCI DSS Requirement Categories

PCI DSS organises requirements into six goals and twelve categories.

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls. Firewalls, security groups, and network controls protecting the cardholder data environment (CDE). Firewall rules must restrict traffic to and from the CDE to only what's necessary for card processing.

Requirement 2: Apply Secure Configurations to All System Components. Default passwords changed. Unnecessary services disabled. System configurations hardened against CIS benchmarks or vendor guidelines. No default vendor credentials on any system.

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data. Cardholder data stored only when necessary. PAN (Primary Account Number) masked or encrypted. Encryption keys managed securely. Data retention policies enforced.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission. Cardholder data encrypted during transmission over open, public networks. TLS 1.2+ required. No SSL or early TLS.

Goal 3: Maintain a Vulnerability Management Programme

Requirement 5: Protect All Systems and Networks from Malicious Software. Anti-malware deployed on all systems commonly affected by malware. Definitions current. Periodic scans or real-time monitoring.

Requirement 6: Develop and Maintain Secure Systems and Software. Secure development practices. Known vulnerabilities addressed. Security patches applied within defined timelines. Web application protection (WAF or code review).

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know. Role-based access control. Least privilege principle. Access granted only to individuals whose job requires it.

Requirement 8: Identify Users and Authenticate Access to System Components. Unique user IDs for every user. Multi-factor authentication for administrative access. Password policies enforced. Shared accounts prohibited.

Requirement 9: Restrict Physical Access to Cardholder Data. Physical security controls for data centres and areas processing cardholder data. Visitor management. Media handling procedures.

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data. Audit trails for all access to cardholder data and system components. Log integrity. Centralised log management. Daily log review. Log retention (12 months minimum, 3 months immediately accessible).

Requirement 11: Test Security of Systems and Networks Regularly. Vulnerability scanning. Penetration testing. Wireless analysis. Change-detection mechanisms. This is the requirement most directly requiring penetration testing.

Goal 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Organisational Policies and Programmes. Security policy documented and maintained. Security awareness training. Incident response plan. Third-party service provider management.

Requirement 11: Why Penetration Testing Is Mandatory

Requirement 11 is the most technically demanding PCI DSS requirement and the one most directly relevant to penetration testing.

Requirement 11.2: Vulnerability Scanning

11.2.1: Internal vulnerability scanning. Quarterly internal vulnerability scans performed. Rescans performed until all high-risk vulnerabilities (CVSS 4.0+) are resolved.

11.2.2: External vulnerability scanning. Quarterly external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV). Rescans performed until passing results are achieved (no vulnerabilities scoring CVSS 4.0+ that PCI DSS considers a failure).

What QSAs check: Evidence of quarterly scan execution. Scan reports from ASV for external scans. Remediation evidence for identified vulnerabilities. Rescan results confirming resolution.

Requirement 11.3: Penetration Testing

11.3.1: External penetration testing. Annual external penetration testing of the CDE perimeter. Testing must cover the complete external attack surface of the CDE including all internet-facing systems within scope.

11.3.1.1: Internal penetration testing. Annual internal penetration testing of the CDE and critical systems. Testing must cover internal network segmentation, Active Directory (where applicable), and lateral movement paths to cardholder data.

11.3.1.2: Penetration testing after significant changes. Penetration testing must be repeated after any significant infrastructure or application change to the CDE. "Significant changes" include new system components, network topology changes, firewall rule modifications, and product upgrades.

11.3.2: Segmentation testing. If network segmentation is used to reduce PCI DSS scope, penetration testing must validate that segmentation effectively isolates the CDE from out-of-scope networks. This is one of the most critical PCI DSS penetration testing requirements because segmentation is how most organisations limit their PCI scope.

What PCI DSS Penetration Testing Must Cover

PCI DSS prescribes specific penetration testing methodology requirements.

Testing must include:

Network-layer testing of the CDE perimeter and internal network. Application-layer testing of web applications and APIs that process cardholder data. Validation that segmentation controls isolate the CDE (if segmentation is used). Testing from both outside (external) and inside (internal) the network.

Testing methodology must:

Follow an industry-accepted approach (NIST SP 800-115, OWASP Testing Guide, PTES). Include testing for OWASP Top 10 vulnerabilities for web applications. Cover all in-scope system components. Document the scope and methodology used.

Tester qualifications:

PCI DSS requires that penetration testing is performed by a "qualified internal resource or qualified external third party." The tester must be organisationally independent of the area being tested. PCI SSC doesn't mandate specific certifications but industry practice expects testers with OSCP, CREST, or equivalent credentials demonstrating practical exploitation skills. See our guide on choosing penetration testing companies for evaluation criteria.

Requirement 11.4: Network Intrusion Detection

11.4.1: Intrusion detection/prevention. Intrusion detection and/or prevention techniques deployed to detect and/or prevent intrusions into the network. IDS/IPS covering all traffic at the CDE perimeter and critical points within the CDE.

Requirement 11.5: Change-Detection Mechanisms

11.5.1: Change detection. Mechanisms deployed to alert personnel to unauthorised modification of critical system files, configuration files, or content files. File integrity monitoring covering critical CDE systems.

Requirement 11.6: Wireless Analysis (PCI DSS 4.0)

11.6.1: Unauthorised wireless detection. Quarterly testing for the presence of unauthorised wireless access points. This applies whether or not the organisation uses wireless technology, because rogue wireless access points can be placed by attackers or unauthorised employees.

The PCI DSS Audit Process

Determining Your Assessment Type

Self-Assessment Questionnaire (SAQ). For smaller merchants and service providers based on transaction volume and how they process payments. Multiple SAQ types exist (SAQ A, SAQ A-EP, SAQ B, SAQ C, SAQ D) based on payment processing method. SAQ D is the most comprehensive, requiring all applicable PCI DSS requirements.

Report on Compliance (ROC). For Level 1 merchants (over 6 million transactions annually) and Level 1 service providers. ROC assessments are conducted by Qualified Security Assessors (QSAs) and involve on-site evaluation.

Attestation of Compliance (AOC). Declaration that the organisation has completed assessment (SAQ or ROC) and met all applicable requirements.

The Audit Timeline

Pre-audit preparation (3 to 6 months before). Conduct gap analysis against PCI DSS requirements. Remediate identified gaps. Complete vulnerability scanning and penetration testing. Gather evidence documentation.

Audit execution (2 to 4 weeks for ROC). QSA reviews documentation, interviews personnel, examines system configurations, reviews scan and pentest results, observes processes, and validates controls.

Remediation (if needed). Address any findings or gaps identified during the audit. Provide evidence of remediation to the QSA.

Certification. QSA issues ROC/AOC. Organisation submits to acquiring bank and card brands.

What QSAs Evaluate for Requirement 11

During the PCI DSS audit, QSAs specifically examine the following for Requirement 11.

Vulnerability scanning evidence:

• Quarterly internal scan reports for the past year
• Quarterly external ASV scan reports for the past year
• Evidence of remediation for identified vulnerabilities
• Rescan results confirming resolution

Penetration testing evidence:

• Annual external penetration test report
• Annual internal penetration test report
• Segmentation validation testing results (if applicable)
• Evidence of testing after significant changes
• Testing methodology documentation
• Tester qualifications
• Scope confirmation covering the complete CDE
• Remediation evidence for identified vulnerabilities
• Retesting confirmation

Wireless testing evidence:

• Quarterly wireless scan results
• Evidence of rogue AP detection and response

What fails the audit:

• Missing quarterly scans (any quarter without documented scanning)
• Penetration test scope not covering the entire CDE
• Segmentation testing not performed when segmentation reduces scope
• Penetration testing not repeated after significant changes
• Unresolved high-severity findings without documented remediation or compensating controls
• Testing performed by the team responsible for the tested environment (independence requirement)

PCI DSS Audit Checklist

Requirement 1: Network Security Controls

• Firewall rules restrict CDE traffic to business-justified flows only
• All firewall rules documented with business justification
• Rules reviewed semi-annually
• No "any-any" rules for CDE traffic
• Inbound and outbound traffic restricted to minimum necessary

Requirement 2: Secure Configurations

• All default passwords changed on all system components
• Unnecessary services and protocols disabled
• System configurations documented and hardened
• Only one primary function per server (no co-mingling)

Requirement 3: Protect Stored Data

• PAN masked when displayed (first 6 and last 4 digits maximum)
• PAN encrypted when stored (or use truncation, tokenisation, hashing)
• Encryption key management procedures documented and followed
• Sensitive authentication data (CVV, PIN) not stored after authorisation
• Data retention policy enforced (data deleted when no longer needed)

Requirement 4: Encrypt Transmission

• TLS 1.2+ on all connections transmitting cardholder data
• No SSL or early TLS
• Strong cipher suites configured
• Certificates valid and properly managed

Requirement 5: Anti-Malware

• Anti-malware on all systems commonly affected
• Definitions updated regularly
• Periodic scans or continuous real-time monitoring

Requirement 6: Secure Development

• Security patches applied within defined timelines (critical within 30 days)
• Secure coding practices followed for custom applications
• OWASP Top 10 addressed for web applications
• WAF deployed for public-facing web applications (or code review)
• Change management procedures followed for CDE changes

Requirement 7: Access Control

• Access restricted to need-to-know basis
• Role-based access implemented
• Access granted based on job classification and function

Requirement 8: Authentication

• Unique ID for every user
• MFA for all administrative access to CDE
• MFA for all remote access to the network
• Password policy enforced (minimum length, complexity, rotation)
• Shared and generic accounts prohibited

Requirement 9: Physical Security

• Physical access to CDE restricted
• Visitor management procedures implemented
• Media handling and destruction documented

Requirement 10: Logging and Monitoring

• Audit trails for all access to cardholder data
• Logs for all system components in the CDE
• Logs reviewed daily
• Logs retained 12 months (3 months immediately accessible)
• Log integrity validated (tamper detection)
• Time synchronisation across all systems

Requirement 11: Testing

• Quarterly internal vulnerability scans completed
• Quarterly external ASV scans completed with passing results
• Annual external penetration test completed
• Annual internal penetration test completed
• Segmentation validation testing completed (if applicable)
• Testing after significant changes completed
• Quarterly wireless scans completed
• IDS/IPS deployed and monitoring CDE traffic
• File integrity monitoring on critical CDE systems
• All scan and test findings remediated and retested

Requirement 12: Security Policies

• Information security policy documented and reviewed annually
• Security awareness training for all personnel
• Incident response plan documented and tested
• Third-party service providers managed (BAAs, compliance validation)

How to Prepare for a PCI DSS Audit

6 Months Before the Audit

Conduct a gap analysis. Compare your current state against every applicable PCI DSS requirement. Identify gaps requiring remediation. The gap analysis is your roadmap for audit preparation.

Define CDE scope. Document exactly which systems store, process, or transmit cardholder data. Map data flows. Identify all connected systems. Validate that segmentation (if used) correctly isolates the CDE. Incorrect scoping is the most common cause of audit failure.

Schedule penetration testing. Engage a qualified penetration testing provider for annual testing. Allow time for remediation and retesting before the audit. Testing six to eight weeks before the audit provides time to address findings. See our PCI DSS penetration testing guide for scope and methodology requirements.

3 Months Before the Audit

Remediate gaps. Address findings from the gap analysis. Implement missing controls. Update configurations. Deploy required security measures.

Ensure quarterly scan compliance. Verify that you have four consecutive quarters of internal and external vulnerability scans. Missing even one quarter creates an audit finding. Schedule any overdue scans immediately.

Gather documentation. Compile policies, procedures, network diagrams, data flow diagrams, system inventories, scan reports, pentest reports, training records, and incident response plans. QSAs will request all of these.

1 Month Before the Audit

Conduct a pre-audit review. Walk through the QSA's evaluation criteria against your evidence. Identify any remaining gaps. Ensure documentation is complete and current.

Verify pentest and scan results. Confirm that all critical and high findings from penetration testing and vulnerability scanning are remediated with retesting evidence. Unresolved findings require documented compensating controls or risk acceptance.

Prepare personnel. Brief staff who will interact with the QSA. Ensure they understand their responsibilities and can explain security controls in their domain.

Common PCI DSS Audit Failures Related to Testing

Failure 1: Penetration Test Scope Doesn't Cover the Entire CDE

The pentest covered the payment application but excluded the database server, internal network, or supporting systems within the CDE boundary. QSAs compare pentest scope against the CDE scope diagram. Any gap between them creates a finding.

Prevention: Provide your CDE scope documentation to your pentest provider during scoping. Verify that testing covers every system component within the CDE boundary.

Failure 2: No Segmentation Validation

The organisation uses network segmentation to reduce PCI DSS scope but never tested whether segmentation actually works. Requirement 11.3.2 mandates that segmentation effectiveness is validated through penetration testing.

Prevention: Include segmentation testing in every PCI DSS penetration test. Testers must attempt to cross from out-of-scope networks into the CDE, validating that segmentation controls prevent access.

Failure 3: Missing Quarterly Scans

The organisation has three quarters of scan results instead of four. Or external ASV scans have a failing quarter without documented rescan.

Prevention: Automate scan scheduling. Calendar quarterly scan deadlines. Track scan results and ensure remediation and rescanning occur within the quarter.

Failure 4: Testing Not Repeated After Significant Changes

The CDE underwent infrastructure changes (new servers, network modifications, application upgrades) without follow-up penetration testing.

Prevention: Define "significant change" criteria in your change management process. Require penetration testing for changes meeting the criteria. Track changes against testing schedules.

Failure 5: Pentest Report Lacks Methodology Documentation

The penetration test report doesn't document the methodology, scope, or tester qualifications. QSAs need to verify that testing followed an industry-accepted approach and was conducted by qualified, independent testers.

Prevention: Require your pentest provider to document methodology (referencing NIST SP 800-115, OWASP, or PTES), scope (confirming CDE coverage), and tester qualifications in every report. See our penetration testing reports guide.

Failure 6: Unresolved Findings Without Compensating Controls

The penetration test found critical or high vulnerabilities that remain unresolved at audit time. No compensating controls are documented. No risk acceptance is formalised.

Prevention: Remediate all critical and high penetration test findings before the audit. For findings requiring extended timelines, document compensating controls that reduce risk while permanent remediation is completed. All compensating controls require QSA validation.

PCI DSS Penetration Testing vs Other Compliance Frameworks

Organisations often maintain PCI DSS alongside other compliance frameworks. Penetration testing can serve overlapping requirements.

PCI DSS + SOC 2. SOC 2 Trust Services Criteria expect penetration testing evidence. A single pentest covering CDE scope (PCI DSS) and in-scope systems (SOC 2) with dual-framework mapping satisfies both. See how SOC 2 pentests support compliance.

PCI DSS + ISO 27001. ISO 27001 Annex A controls require security testing. Testing mapped to both PCI DSS requirements and ISO 27001 Annex A serves dual certification.

PCI DSS + HIPAA. Healthcare organisations processing patient payments face both frameworks. Testing covering CDE (PCI DSS) and ePHI systems (HIPAA) in one engagement satisfies dual requirements. See our healthcare penetration testing guide.

PCI DSS + GDPR. Organisations processing EU cardholder data face both PCI DSS and GDPR. Testing covering payment systems satisfies PCI DSS Requirement 11 and demonstrates GDPR Article 32 "appropriate measures." See our GDPR penetration testing guide.

For comprehensive compliance alignment, see our penetration testing compliance guide.

How AppSecure Delivers PCI DSS Penetration Testing

AppSecure provides PCI DSS penetration testing designed specifically for audit success.

CDE-Scoped Testing

Every PCI DSS engagement scopes testing to cover the complete cardholder data environment: payment applications, databases storing cardholder data, internal network paths to CDE systems, external perimeter protecting CDE, and cloud infrastructure hosting payment workloads. No gaps between test scope and CDE boundary.

Segmentation Validation

When segmentation reduces PCI DSS scope, AppSecure validates segmentation effectiveness through actual lateral movement testing between out-of-scope networks and the CDE. Segmentation testing satisfies Requirement 11.3.2 with exploitation-based evidence.

OWASP Top 10 for Payment Applications

Web applications and APIs processing payments receive comprehensive testing covering OWASP Top 10 and beyond, including business logic testing of payment workflows, authorisation validation, and transaction integrity.

QSA-Ready Reports

Reports document methodology (referencing NIST SP 800-115 and OWASP), scope (confirming CDE coverage), tester qualifications (OSCP, GXPN, CREST), and findings with PCI DSS requirement mapping. Reports satisfy QSA evidence requirements without additional documentation effort.

Zero False Positives

Every finding is manually validated through exploitation. QSA review of your pentest report confirms genuine, validated findings rather than unverified scanner output.

3-Week Delivery

Standard PCI DSS penetration testing engagements deliver within three weeks, allowing time for remediation and retesting before audit dates. 90-day remediation support and complimentary retesting ensure findings are resolved before QSA review.

Flexible Models

Annual PCI DSS assessments, continuous penetration testing for ongoing CDE validation, and PTaaS for testing after significant changes. Application security assessment provides comprehensive coverage.

Ready for PCI DSS penetration testing designed for audit success?

Contact AppSecure:

• Schedule PCI DSS Penetration Testing
• PCI DSS Penetration Testing Guide
• Application Security Assessment

Frequently Asked Questions

1. What is a PCI DSS audit?

A PCI DSS audit is a compliance assessment evaluating whether an organisation meets PCI DSS requirements for protecting cardholder data. Audits are conducted through Self-Assessment Questionnaires (SAQ) for smaller merchants or Reports on Compliance (ROC) by Qualified Security Assessors (QSAs) for Level 1 merchants and service providers. The audit examines twelve requirement categories covering network security, data protection, access control, monitoring, testing, and security policies. Passing the audit results in an Attestation of Compliance (AOC) certifying PCI DSS compliance.

2. Is penetration testing required for PCI DSS?

Yes. PCI DSS Requirement 11.3 mandates annual external and internal penetration testing of the cardholder data environment. If network segmentation reduces PCI DSS scope, segmentation validation through penetration testing is also required (Requirement 11.3.2). Penetration testing must also be repeated after significant changes to the CDE. This is not a recommendation. It is a defined requirement that QSAs validate during every audit.

3. What does PCI DSS Requirement 11 cover?

Requirement 11 covers security testing: quarterly internal and external vulnerability scanning (11.2), annual external and internal penetration testing (11.3), segmentation validation testing (11.3.2), testing after significant changes (11.3.1.2), intrusion detection/prevention (11.4), file integrity monitoring (11.5), and quarterly wireless scanning (11.6). Requirement 11 is the most technically demanding PCI DSS requirement and the one most directly requiring penetration testing evidence.

4. What must PCI DSS penetration testing cover?

PCI DSS penetration testing must cover the complete cardholder data environment including network-layer testing (external perimeter and internal network), application-layer testing (web applications and APIs processing cardholder data), and segmentation validation (if segmentation reduces scope). Testing must follow an industry-accepted methodology (NIST SP 800-115, OWASP, PTES), be performed by qualified independent testers, and address OWASP Top 10 for web applications.

5. How often does PCI DSS require penetration testing?

PCI DSS requires annual penetration testing of the CDE at minimum. Additional testing is required after significant infrastructure or application changes to the CDE. Quarterly vulnerability scanning (both internal and external ASV) is required separately. Segmentation testing must accompany each penetration test. Some organisations conduct semi-annual or quarterly penetration testing for more rigorous security validation.

6. What is PCI DSS segmentation validation?

Segmentation validation tests whether network segmentation effectively isolates the CDE from out-of-scope networks. If your organisation uses segmentation to reduce PCI DSS scope (testing only CDE systems rather than the entire network), Requirement 11.3.2 requires penetration testing specifically validating that out-of-scope systems cannot reach the CDE. Testers attempt to traverse from out-of-scope networks into the CDE. If they succeed, segmentation has failed and PCI DSS scope expands.

7. What causes PCI DSS audit failures related to testing?

Common testing-related audit failures include penetration test scope not covering the entire CDE, missing segmentation validation when segmentation reduces scope, missing quarterly vulnerability scans (any quarter without documented scanning), testing not repeated after significant CDE changes, penetration test reports lacking methodology documentation and tester qualifications, and unresolved critical or high findings without compensating controls at audit time.

8. How should I prepare for a PCI DSS audit?

Start preparation six months before. Conduct a gap analysis against all applicable requirements. Define and document CDE scope. Schedule penetration testing six to eight weeks before the audit (allowing remediation and retesting time). Ensure four consecutive quarters of vulnerability scans. Remediate all gaps identified in the analysis. Gather documentation (policies, network diagrams, data flows, scan reports, pentest reports, training records). Conduct a pre-audit review one month before. Brief personnel who will interact with the QSA.

9. Can one penetration test satisfy PCI DSS and other frameworks?

Yes. A well-scoped penetration test with multi-framework reporting can satisfy PCI DSS Requirement 11.3 alongside SOC 2 Trust Services Criteria, ISO 27001 Annex A testing requirements, HIPAA risk assessment, and GDPR Article 32 obligations simultaneously. The key is ensuring testing scope covers systems relevant to each framework and that reporting maps findings to each framework's specific requirements. Multi-framework mapping from a single engagement significantly reduces compliance cost.

10. What qualifications should PCI DSS penetration testers have?

PCI DSS requires testing by "qualified internal resources or qualified external third parties" who are organisationally independent from the tested environment. While PCI SSC doesn't mandate specific certifications, industry practice expects testers with OSCP (practical exploitation exam), CREST CRT/CCT (practical testing examination), or GXPN (advanced exploitation certification). Testers should have experience with PCI DSS scope validation and segmentation testing specifically. QSAs may ask about tester qualifications during audit review.