PCI-DSS testing means verifying that every system that stores, processes, or transmits cardholder data meets the twelve requirements of the Payment Card Industry Data Security Standard — through a mix of automated scanning, manual penetration testing, and configuration review, most of it repeated quarterly or after any significant change.
Here’s the checklist we actually run against payment platforms, not the theoretical version in the PCI-SSC documentation.
Why this isn’t optional for anyone touching card data?
If your platform stores, processes, or transmits cardholder data — or even just tokenizes it through a third-party processor — you’re in scope for PCI-DSS, whether you’re a Level 1 merchant processing millions of transactions a year or a Level 4 startup doing a few hundred. Non-compliance isn’t a warning letter; it’s fines from your acquiring bank, increased transaction fees, and in the worst cases, losing the ability to accept card payments at all.
PCI-DSS v4.0 became the mandatory baseline in 2025, replacing v3.2.1. It tightened requirements around authentication, encryption, and — critically for this checklist — testing frequency and scope. Several controls that were “best practice” under v3.2.1 are now mandatory, including more frequent penetration testing and expanded scope for scripts running on payment pages.
The testing checklist, by requirement area
Network segmentation testing — Confirm your cardholder data environment (CDE) is actually isolated from the rest of your network, not just documented as isolated. Segmentation testing (Requirement 11.4.5) is required at least every six months and after any change to segmentation controls. This is the single most common gap we find: architecture diagrams show segmentation that the live firewall rules don’t enforce.
External and internal penetration testing — Both are required at least annually and after any significant infrastructure or application change (Requirement 11.4). External testing simulates an attacker from the internet; internal testing simulates an attacker who’s already inside your network, including a malicious insider. Under v4.0, this now must be performed by a qualified resource with organizational independence from the system being tested.
Vulnerability scanning, internal and external — External scans must be run quarterly by an Approved Scanning Vendor (ASV); internal scans run quarterly too, using authenticated scanning where feasible. A clean scan isn’t the same as a low-risk system — it means known signatures weren’t matched, not that no vulnerability exists.
Application-layer testing — Any public-facing web application in the CDE needs testing against common attack vectors (injection, broken authentication, cross-site scripting) at least annually and after changes, either through manual penetration testing or an automated application vulnerability security assessment tool, paired with a web application firewall.
Script and payment-page integrity monitoring — New in v4.0, and one of the most under-implemented controls we see: Requirement 6.4.3 requires monitoring and managing all scripts loaded and executed on payment pages, with a method to confirm each script is authorized and its integrity hasn’t been tampered with. This closes the gap that enabled widespread Magecart-style skimming attacks, where a compromised third-party script silently captured card data.
Authentication and access control testing — Multi-factor authentication is now required for all access into the CDE, not just remote or administrative access. Test that MFA is actually enforced at every entry point, not just the primary login screen — API access, admin panels, and backup consoles are common gaps.
Encryption verification — Confirm cardholder data is encrypted both in transit (strong cryptography over open, public networks) and at rest, and that encryption keys are managed correctly — rotated, access-restricted, and never stored alongside the data they protect.
Where payment platforms actually fail
The failures we see repeatedly aren’t exotic vulnerabilities — they’re process and configuration gaps:
- Segmentation that looks correct on a network diagram but has a forgotten firewall rule or a flat VLAN somewhere allowing lateral movement into the CDE
- Third-party scripts on checkout pages (chat widgets, analytics tags, A/B testing tools) with no integrity monitoring — exactly the Requirement 6.4.3 gap
- Penetration testing treated as an annual compliance checkbox rather than run after the significant changes that actually introduce new risk — a new payment integration, a re-architected checkout flow
- MFA enforced on the primary admin console but not on API keys, service accounts, or backup access paths
- Vulnerability scans that pass because the scanning tool wasn’t authenticated, so it never saw what an attacker with any foothold would see
- Log review and monitoring (Requirement 10) configured to collect data but never actually reviewed, so a genuine incident sits undetected for weeks
None of these require exotic tooling to fix. They require testing that specifically targets the gap between what’s documented and what’s actually configured — which is exactly where compliance programs tend to drift after the initial certification push.
What a practical testing cadence looks like?
Rather than treating PCI-DSS testing as one annual event, the requirements map to a cadence:
- Quarterly: external and internal vulnerability scans, ASV scans, segmentation review for any environment relying on segmentation to reduce scope
- Semi-annually: formal segmentation penetration testing (Requirement 11.4.5)
- Annually, and after significant changes: external and internal penetration testing, application-layer testing, full risk assessment
- Continuously: script and payment-page integrity monitoring, log review, file integrity monitoring on critical systems
“Significant change” is doing a lot of work in the standard, and it’s worth defining internally before your assessor does it for you: a new payment gateway integration, a checkout redesign, new third-party scripts on payment pages, or infrastructure moves into or out of the CDE should all trigger a fresh round of testing rather than waiting for the next scheduled cycle.
Getting testing embedded rather than bolted on
The platforms that pass their assessments with the fewest findings are the ones where PCI-DSS testing isn’t a separate annual exercise — it’s part of the same security testing discipline applied to every release. New payment flows get tested against the same requirements before they ship, not discovered as gaps during the next audit cycle.
For teams running continuous delivery against a CDE, that means automated scanning and segmentation checks in the pipeline, with manual penetration testing scheduled around major releases rather than a fixed calendar date. Our AppAtlas integration is built for exactly this — mapping test coverage against the systems actually in scope for PCI-DSS, so segmentation and access-control testing don’t quietly fall out of scope as the platform evolves.
The practical starting point
If your last full assessment feels more like paperwork than proof: start with a segmentation test to confirm your CDE boundary is real, then an authenticated internal vulnerability scan to see what’s actually reachable from inside your own network. Those two alone surface most of the gaps in this checklist, and both are far cheaper to run now than to explain to your acquiring bank after a breach.
Need a PCI-DSS readiness review that goes beyond the checkbox scan? We test against the requirements that actually get flagged in a real assessment. Get in touch.