PCI Penetration Testing Requirements
Reviewed by Raymond Dantes, PCI QSA
PCI DSS requires annual penetration testing of your cardholder data environment by a qualified external tester, covering both external and internal attack scenarios. The test verifies that your security controls actually prevent real-world attacks — not just that they exist on paper. Findings that allow access to cardholder data must be remediated and retested before you achieve compliance, with typical engagement costs ranging from $3,000 to $15,000 depending on scope.
PCI DSS requires penetration testing to verify your security controls. You need to understand what scope you're testing, how often it has to happen, and what counts as actually passing. Penetration testing sounds more intimidating than vulnerability scanning, and in some ways it is — but the concept is straightforward once you see what you're actually trying to accomplish. The goal is verification that even with known vulnerabilities fixed and basic security controls in place, an attacker still can't realistically access cardholder data. Understanding what the test covers and what you're actually proving prevents you from either overspending on unnecessary testing or underselling your scope and missing critical gaps.
What Penetration Testing Actually Is
A penetration test is an authorized simulated attack where a qualified security professional attempts to exploit vulnerabilities and find architectural gaps that could allow access to cardholder data.
The tester discovers a vulnerability, attempts to exploit it, moves deeper into your network if the exploit succeeds, looks for sensitive data, and documents the entire path they took. The final report describes what they found, how they found it, what it means for your security, and recommendations for remediation.
A successful penetration test proves that your security controls aren't just theoretically sound on paper — they actually prevent real attacks in practice. A failed penetration test means that the tester was able to chain together vulnerabilities and weak controls to access something they shouldn't have. The distinction matters: you can have perfect configurations and still have architectural weaknesses that allow compromise. Penetration testing forces that reality check.
What makes penetration testing fundamentally different from vulnerability scanning is the human intelligence component. A scanner checks for known patterns. A penetration tester sees a vulnerability and thinks, "How could I use this to get deeper?" They discover things scanners miss because they're looking for attack chains, not just individual weaknesses. They might find that a vulnerability that seems minor on its own could be combined with another control weakness to create a serious problem. They test assumptions that configurations rely on. That manual adaptation and real-world attack thinking is what makes penetration testing valuable beyond just compliance.
Internal and External Tests: Different Threats, Both Required
PCI DSS requires both external and internal penetration tests because each simulates a different attacker profile — perimeter intruders and malicious insiders, respectively.
An external penetration test simulates an attacker from the internet trying to compromise your systems. The tester starts outside your network perimeter and attempts to find a way in. They're testing perimeter security: exposed web applications, unpatched internet-facing services, weak authentication mechanisms, social engineering, and similar external attack vectors. A successful external test proves an attacker could breach your perimeter.
An internal penetration test simulates an attacker who's already inside your network, either because they're a malicious insider, a contractor with network access, or because they compromised one system and are now moving deeper. The tester starts from inside your network and attempts to access cardholder data systems. Internal tests verify that your network segmentation actually works and that compromising one system doesn't automatically grant access to everything else. They test access controls, lateral movement possibilities, and whether sensitive data is protected even from internal attackers.
PCI allows you to combine these into a single engagement where the tester starts external and works inward, as long as the scope covers both external and internal scenarios comprehensively. Some organizations prefer separate external and internal tests so each one can focus deeply on its specific threat model. Either approach is acceptable as long as the final report covers both scenarios.
The practical difference is significant. An organization with good perimeter security but weak internal network segmentation might pass an external test but fail an internal one. An organization with excellent internal controls but a poorly configured firewall might fail external testing. Both are required because both attack paths are real threats. The Verizon 2024 DBIR found that system intrusion — which includes both external and internal attack paths — remains one of the top breach patterns across industries.
Defining Your Cardholder Data Environment and Scope
Accurate scope definition before the test is critical — too narrow and you miss real attack paths, too broad and you're paying for testing of irrelevant systems.
The cardholder data environment (CDE) is the collection of systems, networks, and infrastructure that handle, process, or store cardholder data. PCI requires testing of your CDE and systems that could impact the security of the CDE. This sounds straightforward until you start mapping your actual environment.
If your web application accepts credit cards, the web server is obviously in scope. The application server that processes the transactions is in scope. The database that stores card tokens is in scope. But what about the office email server? It's on the same network, but it can't access the CDE. If a tester compromises email and uses it as a pivot point to reach the CDE, email is actually in scope because it impacts CDE security. What about the accounting server that only stores invoice data? If it's on a completely separate network with no connections to the CDE, it might not be in scope. But if the accounting server shares the same network segment as the CDE database, segmentation has failed and the accounting server becomes relevant.
Defining scope clearly before the test prevents surprises and prevents either over-testing or under-testing. Some organizations define scope too narrowly to save money, testing only the payment server and missing systems that connect to it. This leads to a passing test that doesn't actually prove security because the tester didn't test all the ways an attacker could reach sensitive data. Other organizations define scope too broadly and pay for testing of systems that don't actually impact cardholder data security. The conversation about scope with your penetration tester is worth having carefully. A good tester will help you define scope correctly based on your actual architecture.
Document your scope definition in writing before the test starts. "We're testing this list of IP addresses, these network segments, and these applications" is clear. "We're testing payment-related systems" is not. The documented scope becomes part of your compliance evidence, so it needs to be precise.
The Annual Testing Requirement and When to Test
PCI DSS requires penetration testing at least annually and after any significant infrastructure or application changes to the cardholder data environment.
The "annual" part means once per calendar year or once every twelve months — you choose the interpretation that works for your situation. Some acquiring banks or stricter compliance frameworks require testing whenever significant system changes occur. A major application upgrade, new payment processor integration, network architecture changes, or infrastructure redesign might trigger a requirement for new testing even if your last test was only six months ago.
The annual timeline gives you flexibility in planning. You could test early in your fiscal year to identify findings and have the rest of the year to remediate them before your next compliance assessment. Or you could test late in the year to verify everything's working before year-end audit. The only requirement is that you have a passing test within a rolling twelve-month window.
The timing choice matters for remediation planning. If a test finds critical findings late in your compliance year, you're in a rush to fix them before your auditor reviews your compliance status. If you test early, you have more time for methodical remediation and verification. Most organizations benefit from testing in the first or second quarter of their fiscal year to allow time for remediation before the pressure of year-end audit.
What Counts as Passing a Penetration Test
A passing penetration test means no exploitable path to cardholder data was found — not necessarily that zero findings exist.
The tester documented vulnerabilities and weak controls they discovered, but none of those vulnerabilities could be chained together to actually reach sensitive data. Alternatively, a pass means that findings exist but they've been remediated and verified before the test report is finalized.
Here's the typical scenario: a tester finds that your external firewall has a rule that's too permissive, allowing traffic that shouldn't be allowed. That's a finding. But because of network segmentation downstream, even with that firewall rule, the tester can't actually reach the CDE. The finding still needs to be documented and remediated, but it doesn't cause a test failure. Compare that to a scenario where the firewall misconfiguration allows direct access to the cardholder database. That's a critical finding that causes test failure. You don't pass compliance until that vulnerability is fixed and retesting confirms it's remediated.
Some organizations get test reports with significant findings, immediately remediate them, and request focused retesting to validate the fixes. That's entirely normal and acceptable. You can get a test report today, fix the findings over the next week, request a retest the following week, and have a passing test result. The timeline is flexible. What's not flexible is that findings allowing access to cardholder data must be remediated and verified before you're compliant.
Retesting After Remediation Is Your Proof That Fixes Actually Work
Retesting after remediation is required for PCI compliance — your auditor and acquiring bank need verified evidence, not your word that a vulnerability was fixed.
If your initial penetration test finds a critical vulnerability — say, default credentials on a server in your CDE that allows the tester to access card data — you fix those credentials and request a retest. The retest proves that the vulnerability is actually fixed and can't be exploited the same way again.
Acquirers and auditors want evidence of remediation, not just your word that you fixed something. Written descriptions of how you fixed an issue are part of the story. But actual verification through retesting is the proof that matters. A retest after remediation doesn't need to be a complete penetration test of your entire scope. It can be focused testing of the specific vulnerabilities that were found and fixed. But it's required to close out the finding.
The cost of retesting is typically much less than the cost of the initial test because it's narrower in scope. You're verifying specific fixes rather than conducting a full assessment. This is why organizations often find that the total cost of a penetration test including remediation and retesting is higher than the initial test cost, but the retesting portion is usually manageable.
How Penetration Testing Fits With Vulnerability Scanning
Penetration testing and vulnerability scanning are complementary but different — scanning identifies known weaknesses, while penetration testing verifies whether those weaknesses allow actual compromise.
A vulnerability scan might find that you're running an outdated web server with a known vulnerability. Penetration testing would reveal whether that vulnerability is actually exploitable in your environment and whether exploiting it would grant access to cardholder data. Alternatively, a penetration test might find that even though you've patched all known vulnerabilities, weak network segmentation allows an attacker who compromises one system to move to another system that handles card data.
PCI's requirement for both scanning and testing ensures coverage of both known vulnerabilities and architectural weaknesses. Scanning catches hygiene issues. Testing catches design problems.
Why You Can't Skip This or Substitute It
You'll occasionally hear someone suggest that a vulnerability scan is sufficient and penetration testing is unnecessary. That argument fails when you think about what each test verifies. A scan confirms patches are applied. A penetration test confirms that the patched system is actually secure and that you don't have architectural weaknesses that bypass good hygiene. They're not interchangeable.
You also can't have your internal IT team conduct your penetration test and call it compliant. PCI requires an external, qualified penetration tester. This isn't arbitrary. An external tester brings objectivity and expertise your internal team might not have. They're not constrained by assumptions about how your systems work. They have no incentive to overlook findings. This independence is the point.
You now understand that penetration testing is rigorous verification that your security controls actually prevent attackers from accessing cardholder data. The test covers your cardholder data environment and systems that could impact it. It happens annually and requires both external and internal testing. After findings are identified, you remediate them and request retesting to verify fixes work. It's more expensive than vulnerability scanning — typically ranging from $3,000 to $15,000 depending on scope and environment complexity — but much more valuable because it tests real attack chains, not just individual vulnerabilities. A passing test proves your controls work in practice.
Frequently Asked Questions
Can our internal IT team perform the PCI penetration test?
No. PCI DSS requires an external, qualified penetration tester who is independent from the systems being tested. Internal teams can conduct their own security assessments for operational purposes, but the compliance-qualifying penetration test must be performed by an outside professional who brings objectivity, specialized expertise, and no incentive to overlook findings.
How much does a PCI penetration test typically cost?
Costs range from $3,000 to $15,000 depending on the size of your cardholder data environment, the number of IP addresses and applications in scope, and whether you need combined external and internal testing. Retesting after remediation adds to the total but is typically a fraction of the initial engagement cost. Organizations with very large or complex environments may pay more.
What triggers a requirement for penetration testing outside the annual cycle?
PCI DSS 4.0 requires penetration testing after any significant change to your cardholder data environment. This includes major application upgrades, new payment processor integrations, network architecture redesigns, migration to new infrastructure, and significant changes to segmentation controls. Your QSA or acquiring bank may define "significant change" more specifically based on your environment.
What is the difference between a penetration test and a vulnerability scan for PCI?
Vulnerability scanning is automated, runs quarterly, and identifies known weaknesses in your configuration and patch level. Penetration testing is manual, runs annually, and involves a qualified tester actively trying to exploit vulnerabilities and chain them together to reach cardholder data. Scanning finds individual issues; penetration testing finds whether those issues — combined with architectural weaknesses — allow actual compromise. PCI requires both.
What happens if we fail a penetration test?
Failure means the tester found an exploitable path to cardholder data. You remediate the findings, then request a focused retest to verify the fixes work. This remediation-retest cycle is standard practice and expected. You are non-compliant until the retested results confirm cardholder data is no longer accessible through the identified attack path.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about PCI DSS penetration testing as of its publication date. PCI DSS requirements, testing standards, and expectations evolve — consult a qualified compliance professional and your acquiring bank for guidance specific to your organization.