PCI Penetration Testing Requirements
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. PCI DSS requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.
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 on your systems. A qualified security professional or team attempts to exploit vulnerabilities, discover weaknesses in controls, or find architectural gaps that could allow access to cardholder data or systems that process it. Unlike vulnerability scanning, which runs automated tools and reports findings, penetration testing is manual and adaptive. 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 requires both external and internal penetration tests, and they test different attack scenarios. 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.
Defining Your Cardholder Data Environment and Scope
The critical decision before any penetration test is scope definition. 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 requires annual penetration testing. 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. Or you could test mid-year if that aligns with your operational calendar. 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 doesn't necessarily mean zero findings. It means that no critical findings allow access to cardholder data. 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
This is often overlooked but critical: retesting after remediation isn't optional or nice-to-have. It's required for compliance. 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. Vulnerability scanning identifies known weaknesses that exist in your configuration and patch level. Penetration testing verifies whether those weaknesses and other control gaps allow actual compromise of cardholder data. You need both for comprehensive verification.
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.
Real-World Consequences of Test Failures
When a penetration test finds a critical path to cardholder data, you're non-compliant until that path is closed. This isn't theoretical. Your acquirer will require evidence of remediation. Your compliance status depends on it. If a test finds that an attacker could bypass authentication and access card data, that's a test failure that requires immediate remediation and retesting.
Some organizations discover during penetration testing that their architecture has fundamental flaws—network segmentation isn't working, systems can't be patched easily, or legacy applications can't be secured without replacement. These discoveries are uncomfortable but valuable. You'd rather find them during a controlled test than during an actual breach. The remediation might be expensive or time-consuming, but it's a one-time cost compared to the ongoing risk of unresolved vulnerabilities.
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.
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.