Guide To PCI Compliance Testing

PCI compliance testing runs on fixed intervals, applies to a defined scope, and carries specific rules about who is qualified to perform each test. If you can get even just those three right, then you have a calendar you can defend to an assessor. 

We’re going to show you the cadence for every recurring test, the tester qualification attached to it, and the fastest way to shrink what you have to test at all. Let’s go! 

What is PCI compliance testing? 

PCI compliance testing is the set of recurring scans, penetration tests, and monitoring checks that verify your cardholder data environment still meets PCI DSS. Documentation shows an assessor what you intended to build, and then testing shows them what is actually running.

That’s why the future-dated requirements apply to every assessment now. The standard moved toward continuous verification, and testing is how it gets done. You can’t satisfy Requirement 11 or the intent behind it by just scrambling once a year. 

You’ll also find that testing is not optional for entities in scope. 

Requirement 11 breaks into six sections, and four of them carry the recurring work: 11.2 for wireless access points, 11.3 for vulnerability scanning, 11.4 for penetration testing, and 11.6 for payment page monitoring.

Each sets its minimum interval in the requirement text itself, and an assessor examines the reports covering the previous 12 months to confirm those intervals were met. If you miss a quarter, that’s something that you need to mark as a finding instead of just a scheduling note.

Who needs to do PCI compliance testing

Every merchant that accepts payment cards falls under PCI DSS, which applies to any entity that stores, processes, or transmits cardholder data. Volume determines which validation program you land in, and your acquirer can require more than the brand minimum. 

But the questionnaire you complete is set by how you accept payments, not by how much you process, so a small merchant handling card data directly can owe more than a large one on a hosted page.

A provider handling your checkout is the biggest single cut you can make to what you test. It doesn't get you to zero. The card data stays off your servers, but the page that loads the payment form is still yours, and so is everything connected to it.

The PCI SSC's PCI merchant resources cover how validation differs by acceptance channel, and our guide to ecommerce PCI compliance covers the platform side.

You should note that nobody is legally required to follow PCI DSS. The payment brands wrote it, and you agreed to it when you signed up to accept cards. Your bank is the one who asks for proof, sets your deadline, and decides what counts as evidence.

But if you don't, your bank has options, and they range from fines passed down to you to losing the ability to accept cards at all.

Five obligations set your testing calendar

The PCI DSS testing requirements are grouped into five recurring obligations. Each one carries a minimum interval, a trigger for retesting after significant change, and a rule about who is qualified to perform it.

Internal scans run every three months and after every significant change

Requirement 11.3.1 sets internal vulnerability scanning at least once every three months. High-risk and critical vulnerabilities have to be resolved, and a rescan has to confirm the fix. The scan tool needs current vulnerability data, and the person running it needs organizational independence from the systems being scanned.

Internal scans have to be authenticated wherever a system accepts credentials, with privileges deep enough to find what a remote scan cannot see (11.3.1.2). Systems that can’t accept credentials have to be documented rather than skipped. 

Also, vulnerabilities below the high-risk and critical thresholds still need a defined treatment plan under 11.3.1.1, driven by your targeted risk analysis.

External scans need an Approved Scanning Vendor

Requirement 11.3.2 is the one place in the testing calendar where the standard names the vendor category. External vulnerability scans have to be performed by a PCI SSC Approved Scanning Vendor. The ASV scan frequency is the same three-month interval that governs internal scanning, and vulnerabilities have to be resolved to the ASV Program Guide definition of a passing scan, with rescans as needed.

This requirement is also not eligible for the customized approach, so there is no alternative control path. You’ll need to budget for it as a fixed line item.

Penetration testing runs annually and after significant change

PCI penetration testing splits into two obligations. Requirements 11.4.2 and 11.4.3 set internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. Both have to follow the methodology you defined under 11.4.1, and both require organizational independence in the tester.

The tester does not have to be a QSA or an ASV. The standard states this explicitly for internal testing, external testing, and segmentation testing. A qualified internal resource satisfies the requirement as long as organizational independence holds, which gives you a real choice about where the work goes.

Exploitable vulnerabilities and security weaknesses found during testing have to be corrected and the testing repeated to verify the correction (11.4.4). A report with open critical findings and no retest does not close the loop.

Segmentation testing confirms your CDE stays isolated

If you use segmentation to keep the cardholder data environment separate from the rest of your network, that segmentation gets penetration tested on its own. Merchants test at least once every 12 months and after any change to segmentation controls. Service providers test at least once every six months (11.4.6).

The test has to cover every segmentation method in use and confirm the CDE is isolated from all out-of-scope systems. Segmentation is what keeps your scope small, so this is the test that protects the rest of your compliance economics.

Payment page monitoring catches script tampering

Requirement 11.6.1 asks for a change and tamper detection mechanism on payment pages, watching the security-impacting HTTP headers and script contents as the consumer browser receives them. It runs at least weekly, or on an interval you justify through a targeted risk analysis under 12.3.1.

This is the requirement that addresses ecommerce skimming, where an attacker modifies a script on a checkout page rather than breaching a server. Requirement 6.4.3 is its companion, covering authorization, integrity assurance, and inventory for every script loaded on a payment page.

[IMAGE 2: Payment page script flow. See design brief.]

Your validation path decides which tests apply

Not every test in that table applies to every merchant. What you owe depends on how much you process, how you accept payments, and what your acquirer asks for, and those three inputs will put you on one of two validation paths.

PCI merchant levels come from the payment brands, not the Council

Merchant levels are set by each payment brand and enforced by your acquirer, which is why the thresholds differ slightly depending on which brand's program you are looking at. Level 1 covers merchants above roughly six million annual transactions, Level 2 covers one million to six million, Level 3 covers 20,000 to one million ecommerce transactions, and Level 4 covers the rest.

The level determines the validation instrument, not the underlying controls. Level 1 merchants validate through an assessment performed by a Qualified Security Assessor and document it in a Report on Compliance. Merchants below Level 1 typically validate with a self-assessment questionnaire. Requirement 11 applies either way for whatever remains in scope. Our PCI compliance checklist walks the full control set behind the validation path.

SAQ A eligibility carries its own testing obligation

Merchants who fully outsource their ecommerce payment page get the shortest validation path, and that path shifted. The Council removed Requirements 6.4.3 and 11.6.1 from SAQ A and replaced them with an eligibility criterion: the merchant confirms that their site is not susceptible to attacks from scripts that could affect their ecommerce systems. The Council's guidance on SAQ A eligibility clarifies that techniques such as those in 6.4.3 and 11.6.1 are one accepted way to confirm it.

Read that as a relocation rather than a removal. Both requirements remain in PCI DSS, and they remain line items in SAQ A-EP, SAQ D, and the ROC template. A merchant who cannot honestly make the eligibility confirmation does not qualify for SAQ A at all, which expands the applicable requirement set considerably.

Merchants completing a Report on Compliance should confirm the applicability question with their compliance-accepting entity, meaning the acquirer or payment brand running their compliance program, rather than settling it with their assessor alone. The current text lives in the PCI SSC FAQs under FAQ 1331, and it is worth reading directly before a scoping conversation.

Shrink the surface before you schedule the tests

Every test above scales with the systems in scope. The most effective testing strategy is to reduce what falls inside the cardholder data environment in the first place, because a smaller environment means fewer systems to scan, less infrastructure to penetration test, and a narrower segmentation boundary to defend.

Routing card data into a Level 1 compliant vault instead of your own infrastructure is the clearest version of that. The Spreedly Vault holds the payment method so the primary account number never lands in your systems, which keeps your servers out of the environment you would otherwise have to test. 

That’s only true if you own the tokens. Payment data security that leaves them locked to a single gateway trades PCI scope for vendor lock-in.

Scope reduction doesn’t erase your obligations. Requirement 12.8.5 requires you to document which PCI DSS requirements each third-party service provider manages and which ones you retain, so the responsibility matrix matters as much as the vault does. Reading an attestation of compliance correctly is part of the same discipline.

Fraud and authentication controls sit adjacent to this work. Fraud and authentication tooling embedded in the payment flow keeps decisioning inside a compliant environment rather than adding another system to your scope. 

Build the calendar, then defend the scope

Put the five obligations on a calendar with a named owner, an evidence location, and a rescan step for each one. Quarterly scans, annual penetration tests, segmentation validation, and weekly payment page monitoring are all predictable, which makes them straightforward to operationalize once someone owns them.

Then work on the other side of the equation. Every system you can move out of the cardholder data environment is a system you never have to scan, patch on a compliance clock, or explain to an assessor.

Talk to us about reducing what you have to test, or see a demo of how the vault keeps card data off your infrastructure.