
Over 42,000 CRA Accounts Breached: What to Know
More than 42,000 Canadian taxpayer accounts have been breached since 2020. Learn more about the data breach class-action lawsuit involving CRA accounts.
May 20, 2026 - Blog
Authored By Packetlabs

Organizations that process, store, or transmit payment card data continue to face increasing cyber threats in 2026. Threat actors are consistently targeting payment environments through ransomware, phishing, web application attacks, credential theft, cloud vulnerabilities, and supply chain compromises.
To reduce these risks, the Payment Card Industry Data Security Standard (PCI DSS) establishes mandatory security controls that organizations must follow.
While PCI DSS includes hundreds of technical and administrative requirements, testing remains one of the most important aspects of maintaining compliance. Security controls must be validated regularly to ensure they function as intended.
This PCI DSS testing requirements checklist explains the testing expectations under PCI DSS v4.0.1, outlines when organizations should perform assessments, and highlights best practices that strengthen both compliance and real-world security.
PCI DSS is the global security standard developed by the Payment Card Industry Security Standards Council (PCI SSC). It applies to any organization that stores, processes, or transmits cardholder data, regardless of size or industry.
PCI DSS v4.0.1 became the current version after replacing earlier versions and places increased emphasis on continuous security validation rather than annual checkbox compliance.
Testing plays a critical role because organizations must prove that security controls are operating effectively over time.
Many organizations mistakenly believe passing an annual assessment is sufficient. However, cybercriminals attack continuously, not once per year.
Regular PCI penetration testing helps organizations:
• Detect vulnerabilities before attackers do • Verify security controls continue working after infrastructure changes • Validate network segmentation • Reduce breach risk • Maintain compliance throughout the year • Demonstrate due diligence during audits • Improve incident preparedness
Organizations that continuously validate their environments are significantly better positioned to identify emerging threats before they become reportable security incidents.
Most PCI DSS testing activities fall under Requirement 11, which focuses on regularly testing security systems and processes.
Requirement 11 includes:
• Vulnerability scanning • Penetration testing • Wireless security testing • Intrusion detection validation • File integrity monitoring • Segmentation testing • Detection of unauthorized devices • Continuous monitoring
However, testing also appears throughout many other PCI DSS requirements.
The following checklist summarizes the primary testing expectations organizations should include in their compliance program.
Internal vulnerability scans identify weaknesses inside the cardholder data environment (CDE).
These scans typically identify:
• Missing security patches • Unsupported operating systems • Weak configurations • Insecure services • Default credentials • Misconfigured servers
Internal scans should be performed:
• At least quarterly • After significant infrastructure changes • Following major software deployments • After network modifications
Organizations should remediate identified vulnerabilities according to their risk level before rescanning.
Organizations with internet-facing systems handling payment data must complete external vulnerability scans using an Approved Scanning Vendor (ASV).
External scans evaluate publicly accessible assets including:
• Firewalls • VPN gateways • Web servers • APIs • Remote access portals • Cloud-hosted applications
PCI DSS requires passing external scans every quarter and after significant changes affecting internet-facing infrastructure.
Penetration testing goes beyond vulnerability scanning by actively attempting to exploit weaknesses.
Internal penetration testing evaluates:
• Privilege escalation • Lateral movement • Active Directory security • Internal network segmentation • Weak authentication • Credential compromise • Misconfigured access controls
Unlike automated scanners, penetration testing demonstrates how multiple vulnerabilities can combine into a successful attack path.
External penetration tests simulate attacks originating from the internet.
Testers attempt to compromise systems using realistic techniques such as:
• Web application attacks • Authentication bypass • API exploitation • Remote code execution • Business logic flaws • Credential attacks • Cloud misconfigurations
Testing should include every internet-facing asset connected to the cardholder data environment.
Many organizations reduce PCI scope by segmenting payment systems from the rest of the corporate network.
However, segmentation cannot simply be assumed.
PCI DSS requires organizations to validate that segmentation controls effectively isolate the CDE.
Testing evaluates whether attackers can bypass:
• Firewalls • VLAN boundaries • ACLs • Cloud security groups • Network routing controls • Zero Trust policies
If segmentation fails, additional systems may unexpectedly fall into PCI scope.
Since payment applications frequently face internet exposure, organizations should routinely evaluate web application security.
Web Application Penetration Testing typically includes:
• SQL injection • Cross-site scripting (XSS) • Broken authentication • Authorization flaws • Cross-site request forgery • File upload vulnerabilities • Server-side request forgery • Business logic testing
Modern assessments frequently align testing with the OWASP Top 10.
Wireless networks continue to present risk if improperly secured.
Organizations should test for:
• Unauthorized wireless access points • Rogue devices • Weak encryption • Insecure guest networks • Misconfigured wireless segmentation
Wireless assessments help prevent attackers from bypassing perimeter security through nearby wireless access.
PCI DSS requires organizations to monitor critical system files for unauthorized changes.
Testing should verify that monitoring solutions detect:
• Unauthorized executable changes • Configuration modifications • Privilege escalation attempts • Malware installation • Registry changes • Critical file deletions
Organizations should periodically validate that alerts function correctly.
Organizations using IDS or IPS technologies should verify:
• Alert generation • Signature updates • Event logging • Notification workflows • Threat detection effectiveness • Sensor coverage
Detection systems that generate excessive false positives may hide genuine attacks.
Security logging supports both compliance and incident response.
Testing should confirm:
• Critical systems generate logs • Logs reach centralized storage • Time synchronization functions correctly • Security events trigger alerts • Retention policies meet PCI requirements
Organizations increasingly integrate SIEM platforms to improve visibility.
PCI DSS v4 places significant emphasis on strong authentication.
Organizations should verify:
• MFA enforcement • Authentication resilience • Token functionality • Administrative account protection • Remote access security
Testing should also evaluate whether MFA can be bypassed through misconfigurations.
Security teams should regularly exercise incident response plans.
Testing may include:
• Tabletop exercises • Ransomware simulations • Data breach scenarios • Communication procedures • Evidence preservation • Recovery processes
Organizations often discover documentation gaps during simulated incidents rather than actual emergencies.
A simplified schedule includes:
Quarterly: • Internal vulnerability scans • External ASV scans
Annually: • Internal penetration testing • External penetration testing • Segmentation testing • Incident response exercises
After Significant Changes: • Penetration testing • Vulnerability scanning • Segmentation validation • Configuration verification
Continuous: • Log monitoring • File integrity monitoring • Intrusion detection • Security monitoring
Organizations operating highly dynamic cloud environments often perform testing more frequently than the minimum requirements.
PCI DSS requires additional testing after significant changes.
Examples include:
• Firewall replacements • Cloud migrations • New payment applications • Infrastructure redesigns • Active Directory changes • Major operating system upgrades • Network segmentation modifications • New payment gateways • New authentication systems • Third-party integrations
Waiting until the next annual assessment could leave critical vulnerabilities exposed.
Many organizations encounter similar issues during assessments.
Common mistakes include:
Testing only once per year.
Annual testing leaves lengthy periods where vulnerabilities remain undiscovered.
Assuming vulnerability scans replace penetration tests.
Automated scanners cannot replicate attacker behavior or identify chained exploits.
Ignoring cloud assets.
Cloud-hosted payment environments remain fully subject to PCI DSS requirements.
Poor documentation.
Testing must produce clear evidence demonstrating compliance.
Incomplete scope.
Organizations frequently overlook APIs, cloud services, mobile applications, or supporting infrastructure.
Unvalidated segmentation.
Network diagrams do not prove segmentation effectiveness.
Failure to remediate findings.
Identifying vulnerabilities without correcting them creates unnecessary compliance risk.
Organizations achieving the strongest security posture typically adopt continuous validation rather than annual compliance projects.
Recommended practices include:
Integrate vulnerability scanning into regular operations.
Perform penetration testing using experienced security professionals.
Continuously monitor critical systems.
Prioritize remediation based on business risk.
Include cloud infrastructure within testing scope.
Validate segmentation after infrastructure changes.
Test APIs alongside traditional web applications.
Automate evidence collection whenever possible.
Maintain detailed documentation for every assessment.
Review security controls throughout the year instead of preparing only for audits.
Selecting an experienced security partner improves both compliance outcomes and security maturity.
Look for providers that offer:
PCI DSS expertise
CREST-certified or similarly qualified penetration testers
Manual penetration testing
Cloud security expertise
Web application testing
API security assessments
Executive reporting
Technical remediation guidance
Retesting services
Clear documentation suitable for PCI audits
An experienced testing provider should focus not only on identifying vulnerabilities but also on helping organizations prioritize remediation efforts that reduce measurable business risk.
PCI DSS testing requirements continue to evolve alongside the threat landscape. In 2026, organizations must demonstrate that security controls operate effectively throughout the year—not simply during an annual assessment.
By implementing routine vulnerability scanning, comprehensive penetration testing, segmentation validation, continuous monitoring, and thorough documentation, organizations can satisfy PCI DSS requirements while significantly improving their overall cybersecurity posture.
Rather than viewing PCI DSS testing as a compliance obligation, organizations should treat it as an opportunity to proactively identify weaknesses before attackers exploit them. Continuous security validation ultimately protects payment card data, reduces breach risk, strengthens customer trust, and supports long-term business resilience.
Yes. PCI DSS requires both internal and external penetration testing at least annually and after significant infrastructure changes. Organizations using network segmentation must also perform segmentation penetration testing to verify the effectiveness of isolation controls.
Vulnerability scanning uses automated tools to identify known weaknesses, while penetration testing involves security professionals actively attempting to exploit vulnerabilities to demonstrate real-world attack paths. Both are required components of a mature PCI DSS testing program.
Internal vulnerability scans should be performed at least quarterly and after significant changes. External scans must be completed quarterly using an Approved Scanning Vendor (ASV) for internet-facing systems that fall within PCI scope.
Yes. Organizations using cloud infrastructure remain responsible for ensuring PCI DSS compliance. This includes testing cloud-hosted systems, applications, APIs, storage, identity controls, and network segmentation where applicable.
If segmentation testing shows that the cardholder data environment is not properly isolated, additional systems may fall within PCI DSS scope. Organizations must remediate segmentation weaknesses and retest before relying on reduced compliance scope.