U.S. PCI Pen Testing: Prepare Evidence, Pass Annual Segmentation Tests

PCI DSS requires penetration testing for any environment that stores, processes, or transmits cardholder data, and it requires separate testing to prove that network segmentation actually isolates that environment. If your organization uses segmentation to shrink the scope of its assessment, that claim has to be verified at least annually, per PCI SSC segmentation guidance. Your next move is simple: confirm your cardholder data environment boundaries and get a test scheduled or documented before your assessment window closes.

TL;DR:

• PCI DSS mandates annual testing to verify that network segmentation effectively isolates cardholder data environments.
• Penetration testing requires active exploitation attempts, while vulnerability scans only identify known weaknesses, making the former more comprehensive.
• Organizations must accurately map their dataflow and validate segmentation controls through real testing, not just configuration reviews.
• Testing scope and frequency should adapt to network changes, new integrations, or major system updates, not only on a fixed yearly schedule.
• Qualified testers with relevant experience and independence are essential for meaningful results, as automated scans alone do not satisfy PCI requirements.

Table of Contents

• What counts as PCI penetration testing versus a vulnerability scan
• Defining your cardholder data environment and why segmentation isn’t automatic
• When to run PCI pen tests and what triggers a retest
• Who is qualified to run the test and why independence matters
• A step-by-step methodology from pre-engagement to final report
• Rules of engagement, authorization, and staying safe during testing
• What a PCI-acceptable report includes and how remediation gets tracked
• Getting ready for your PCI assessment: a working checklist
• An experienced view on where U.S. businesses fall short
• Why PCI pen testing matters beyond passing the audit
• How Tatem Web Design supports your PCI compliance work
• Primary authoritative documents and guidance
• Sources
• FAQ

What counts as PCI penetration testing versus a vulnerability scan

A lot of confusion in PCI compliance starts with people treating a vulnerability scan and a penetration test as the same activity. They are not. A vulnerability scan, typically run by an Approved Scanning Vendor (ASV) for external-facing systems, automatically identifies known weaknesses and misconfigurations. A penetration test goes further: a person actively attempts to exploit those weaknesses, chain them together, and demonstrate real business impact, following the methodology laid out in PCI SSC’s penetration testing guidance.

PCI DSS Requirement 11.3 covers the penetration testing methodology itself, while 11.3.4 addresses the specific obligation to test segmentation controls when they are used to reduce scope. These requirements exist because a scanner can tell you a door is unlocked, but only a tester can tell you whether someone can walk through it, take the cardholder data, and walk back out unnoticed.

Not every merchant needs the same depth of testing. Your obligations shift depending on how you accept payments and which Self-Assessment Questionnaire (SAQ) applies to your business:

• Merchants using fully outsourced payment pages (SAQ A eligible) often carry a lighter testing burden since cardholder data rarely touches their own systems.
• Merchants with a directly connected CDE (SAQ D or a full Report on Compliance) generally need comprehensive network and application-layer penetration testing.
• Service providers handling cardholder data on behalf of others almost always fall into the higher-scrutiny category, regardless of transaction volume.

Getting the SAQ classification right matters because it determines whether you’re mapping a data flow for a hosted checkout form or defending a full internal network. Our breakdown of SAQ A versus SAQ D walks through how that mapping decision plays out for U.S. ecommerce businesses.

Defining your cardholder data environment and why segmentation isn’t automatic

Before anyone can test anything, you need an honest picture of where cardholder data actually lives, moves, and rests. That means building a dataflow diagram that traces every system that stores, processes, or transmits card data, plus every system connected to those systems. Skipping this step is the single most common reason PCI assessments stall: teams assume their CDE is smaller than it is, then discover during testing that an unmonitored file share or a forgotten backup server has a path into scope.

Segmentation is often treated like a light switch: either a system is “in scope” or it’s walled off and safe. In reality, segmentation is a claim your organization makes, and PCI DSS treats it as exactly that: a claim that has to be proven, not assumed. According to PCI SSC’s scoping and segmentation guidance, segmentation controls used to reduce assessment scope must be penetration tested at least once a year to confirm that out-of-scope systems genuinely cannot reach the CDE.

A practical path through this looks like:

1. Map every system that touches cardholder data, directly or indirectly, including third-party integrations and cloud services.
2. Document the controls meant to isolate the CDE, such as firewalls, VLANs, or access control lists.
3. Have testers actively attempt to cross the boundary rather than simply reviewing firewall rules on paper.
4. Escalate to a full network penetration test if the segmentation controls fail, since a failed boundary usually means the “CDE” is actually larger than assumed.

Testers validating segmentation don’t just check configuration screenshots. As one analysis of PCI DSS v4.0 segmentation requirements points out, the test has to involve genuine attempts to traverse the boundary from an out-of-scope system toward the CDE. If that attempt succeeds even once, the segmentation claim fails and the true scope of the assessment grows.

Pro Tip: Keep your dataflow diagram current year-round instead of recreating it right before an assessment. Networks change constantly, and a diagram built in a rush tends to miss the exact shadow connection a tester would find first.

When to run PCI pen tests and what triggers a retest

PCI DSS sets a baseline: penetration testing happens at least annually, and segmentation testing follows the same annual cadence when segmentation is used to reduce scope. But the calendar isn’t the only trigger. Any significant change to your network or applications, a new payment integration, a data center migration, a major application rewrite, resets the clock and calls for fresh testing before the change goes live in production.

Service providers and businesses running multi-tenant environments face tighter expectations. If your infrastructure serves multiple clients or business units, segmentation between those tenants needs its own verification, since a failure there can expose more than a single organization’s data.

A few scheduling habits keep this manageable instead of chaotic:

• Align pen testing with your ASV scan calendar so vulnerabilities identified by scanning can be cross-checked against exploitation attempts in the same testing window.
• Build in buffer time before your assessor’s deadline so remediation and retesting can happen without rushing the final report.
• Treat major change windows as testing triggers, not just annual dates on a compliance spreadsheet.
• Coordinate with cloud or hosting providers early, since some testing windows require advance provider notice.

Waiting until 30 days before an assessment to schedule a pentest is one of the most common ways organizations end up scrambling. Qualified testers often have multi-week lead times, and remediation takes real hours, not a weekend.

Who is qualified to run the test and why independence matters

PCI DSS does not require a Qualified Security Assessor (QSA) to personally conduct your penetration test. A QSA’s job is to validate your overall PCI DSS compliance and sign off on your Report on Compliance. The penetration test itself can be performed by qualified internal staff or an independent third-party firm, provided the tester has real skill and no conflict of interest, a distinction confirmed in PCI SSC community guidance on assessment documentation.

That said, “qualified” carries weight. Look for testers with recognized credentials such as OSCP, GPEN, or CREST, and a documented history of testing environments similar in complexity to yours. A tester who has spent years scanning websites for SQL injection but has never assessed a segmented payment network is not the right fit for a CDE engagement.

Independence is the part organizations most often overlook. If the same team that configured your firewalls also tests those firewalls, the report tends to reflect assumptions rather than adversarial reality. PCI guidance expects a degree of separation between the people who build your defenses and the people who try to break them.

Testing requires human judgment, not just automated tools. PCI SSC’s penetration testing guidance makes clear that scanners and automated frameworks are aids, not substitutes for a skilled tester who interprets results, chains findings, and demonstrates actual impact on the CDE. A report generated entirely by an automated tool, with no manual verification, will not satisfy an assessor.

A few things to check before signing an engagement letter:

• Certifications and specialization: does the firm or individual have documented experience with payment environments specifically, not just general IT networks?
• Independence from your infrastructure team: has this tester (or firm) had any hand in designing the systems being tested?
• Reporting track record: can they show you a sample report structure before you commit, so you know it will meet assessor expectations?

Our guide on choosing a compliance consultant covers similar vetting questions that apply just as well to selecting a PCI penetration tester.

A step-by-step methodology from pre-engagement to final report

A PCI-acceptable penetration test follows a structured lifecycle, echoing the process NIST SP 800-115 outlines for technical security testing: planning and authorization first, hands-on testing second, and analysis and reporting last. Skipping any of these three phases tends to produce a test that looks thorough but leaves gaps an assessor will catch.

Pre-engagement is where most of the future report’s credibility gets decided:

1. Define scope precisely, listing every system, IP range, and application in or connected to the CDE.
2. Draft Rules of Engagement (ROE) that authorize the test, set boundaries, and name emergency contacts.
3. Secure any required third-party approvals, particularly from cloud hosting providers whose shared infrastructure might be affected.
4. Agree on testing windows that avoid peak transaction periods, especially for retailers near holiday seasons.

Engagement is the hands-on phase, and it should mirror how a real attacker would approach your environment: reconnaissance, vulnerability identification, exploitation attempts, and, where segmentation is in scope, active attempts to cross network boundaries. Application and API testing typically follows recognized frameworks like the OWASP Application Security Verification Standard, which gives testers a consistent way to score severity across web-facing payment interfaces. Social engineering, if included, needs its own explicit authorization since phishing employees or attempting physical access carries legal and HR implications beyond a standard technical test.

Post-engagement is where the test actually becomes usable compliance evidence:

1. Capture and preserve exploitation evidence, including screenshots or logs showing the specific steps taken.
2. Deliver a report that maps findings to business risk, not just technical severity scores.
3. Verify remediation through retesting, confirming that fixes actually closed the identified gaps.
4. File the final report and retest confirmation where your assessor or QSA can review them during the audit.

Pro Tip: Ask your tester for a mid-engagement status call rather than waiting for the final report. Critical findings, like an open path straight into the CDE, deserve immediate attention instead of sitting in a document for two weeks while remediation clocks tick.

Our overview of network penetration testing services walks through how this lifecycle plays out for Florida-based businesses working through their first or fifth PCI cycle.

Rules of engagement, authorization, and staying safe during testing

Rules of Engagement are not paperwork for paperwork’s sake. NIST describes ROE as the mechanism that gives testers formal authority to act and protects your operations from unintended damage during testing, a definition worth internalizing before any test begins, per NIST’s glossary entry on rules of engagement.

A solid ROE document should include:

• Written authorization signed by someone with the authority to approve testing against production systems.
• Explicit scope boundaries, naming exactly which systems are in bounds and which are off-limits.
• Prohibited actions, such as denial-of-service techniques that could take payment systems offline.
• Stop conditions and emergency contacts, so testing halts immediately if something unexpected breaks.
• Evidence handling requirements, specifying how testers must secure, and ultimately delete or return, any cardholder data they encounter.

Cloud-hosted environments add another layer. If your infrastructure runs on shared or multi-tenant cloud services, testing against that infrastructure without the provider’s written approval can violate the provider’s terms of service and, in some cases, invalidate the test entirely if the provider intervenes mid-engagement. Get that approval in writing before the test window opens, not after a provider’s security team notices unusual traffic.

If a tester encounters live, unprotected cardholder data during the engagement, that discovery itself becomes a finding requiring immediate notification, not just a footnote in the final report. The ROE should spell out exactly who gets called and how quickly.

What a PCI-acceptable report includes and how remediation gets tracked

An assessor reviewing your pentest report is looking for specific components, not just a list of vulnerabilities. According to PCI SSC’s penetration testing guidance, a compliant report should include a clear methodology summary, detailed findings with exploitation evidence, an assessment of business impact, and concrete remediation recommendations.

A report an assessor will actually accept typically contains:

• Finding descriptions written clearly enough for both technical staff and management to understand the risk.
• Exploitation evidence, showing the specific steps taken to demonstrate impact, not just a scanner output.
• Impact assessment, connecting each finding to what it would mean for cardholder data if exploited by a real attacker.
• Remediation recommendations, specific enough that your team knows what to fix and roughly how.
• Retest criteria, defining what “fixed” looks like so retesting has a clear pass or fail line.

Once findings land on your desk, prioritization matters more than trying to fix everything simultaneously. Critical findings that expose a direct path to cardholder data need attention before lower-severity issues like outdated software banners that carry no real exploitation path. Where a fix isn’t immediately possible, compensating controls, additional monitoring, tighter access restrictions, temporary segmentation, can bridge the gap until a permanent fix ships, but that reasoning needs to be documented for your assessor, not just assumed.

Retesting confirms the fix actually worked rather than just looking resolved on a ticket. Keep pentest reports, remediation evidence, and retest confirmations on file for at least the period your acquirer or QSA expects, generally covering your current assessment cycle plus the prior year, so an assessor reviewing your Report on Compliance has a clear paper trail from finding to fix to verification.

Getting ready for your PCI assessment: a working checklist

The weeks before an assessment go a lot smoother when the groundwork is already sitting in a folder instead of being assembled the night before a QSA call. A practical sequence looks like this:

1. Build or refresh your dataflow diagrams, covering every system, endpoint, and third-party integration touching cardholder data.
2. Gather prior vulnerability scans and pentest reports, along with documentation showing any prior findings were remediated and retested.
3. Pull change logs covering the past year, since your assessor will want to know what changed and whether those changes triggered new testing.
4. Assemble segmentation testing evidence, showing the specific method used to verify boundaries and the date of the most recent test.
5. Confirm access control documentation, proving that only authorized personnel and systems can reach the CDE.

Coordination matters as much as documentation. Notify your acquirer or QSA of your testing schedule early, confirm any cloud provider approvals are in writing, and have a backup plan if a critical finding surfaces mid-test and pushes your timeline. Store all of this evidence somewhere your compliance team can retrieve quickly, since a scramble to find a six-month-old segmentation report rarely ends well under audit pressure.

Smaller businesses working toward SAQ A eligibility can streamline much of this by first confirming their actual eligibility. Our guide on reaching SAQ A status walks through how that classification narrows the evidence you actually need to collect.

Pro Tip: Create a single shared folder structure for scans, pentest reports, remediation tickets, and retest confirmations, organized by assessment year. Assessors move faster, and ask fewer follow-up questions, when evidence is already organized instead of scattered across email threads.

An experienced view on where U.S. businesses fall short

After more than 26 years supporting Florida businesses across industries from healthcare to marine services, Tatem Web Design has watched the same compliance gaps surface again and again in small and midsize organizations. The most common one: businesses assume outsourcing their payment page removes them entirely from PCI scope, then discover a connected system, an old POS terminal, an unmonitored admin panel, that quietly pulls them back into a larger CDE than they planned for.

Tatem Web Design’s cybersecurity compliance consulting, including PCI compliance work alongside CMMC and HIPAA services, typically starts with an honest scope assessment before any testing begins. From there, the process moves into a remediation plan built around what a business can realistically fix on its own timeline, followed by retest coordination once fixes are in place. That sequencing, assess first, remediate second, retest last, tends to prevent the costly cycle of failed audits and repeated engagements.

Why PCI pen testing matters beyond passing the audit

A penetration test’s real value isn’t the report you hand your assessor. It’s proof that your controls hold up against someone actively trying to break them, not just controls that look correct in a configuration file. Paper compliance and operational security are not the same thing, and the gap between them is exactly where breaches happen.

Small, untested gaps rarely stay small. A single unpatched service or a segmentation rule that quietly stopped working can be the entire path an attacker needs into a payment network. The businesses that treat testing as a once-a-year checkbox tend to find this out the hard way.

The right approach scales testing depth and frequency to actual risk and business impact, not to the minimum the standard allows. A payment processor handling millions of transactions warrants more scrutiny than a small retailer with a single hosted checkout page, and treating both the same wastes resources in one direction and leaves exposure in the other.

— Matt

How Tatem Web Design supports your PCI compliance work

Running a full penetration testing program alongside daily business operations stretches most small and midsize teams thin, and that’s exactly where an outside partner earns its keep. Tatem Web Design’s cybersecurity services cover the full arc of PCI readiness, from scope assessment through remediation planning to retest coordination, so your internal team isn’t trying to become penetration testing experts on top of their regular workload.

A typical engagement starts with a scope and segmentation review, moves into a documented remediation plan built around your actual infrastructure, and closes with retesting to confirm fixes hold before your assessment deadline arrives. Services relevant to PCI compliance work include compliance consulting, pen-test coordination and remediation planning, and managed hosting through various plans that give businesses a secured infrastructure base to build compliance on.

If your business handles cardholder data and you’re not confident your current segmentation or testing schedule would hold up under an assessor’s questions, reach out through our cybersecurity services page or call 772-224-8118 to talk through where your organization actually stands.

Primary authoritative documents and guidance

For readers who want the source documents directly: PCI SSC’s penetration testing guidance, PCI SSC’s scoping and segmentation guidance, NIST’s rules of engagement definition, and the PCI SSC announcement on PCI DSS v4.0.1 cover the current standards and testing lifecycle referenced throughout this guide.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

• Penetration Testing Guidance (PCI SSC)
• Guidance for PCI DSS Scoping and Segmentation (PCI SSC)
• Rules of Engagement (NIST/CSRC glossary)

FAQ

Does PCI require pen testing?

Yes. PCI DSS Requirement 11.3 requires penetration testing for environments in scope for cardholder data, and Requirement 11.3.4 specifically requires testing of segmentation controls when they’re used to reduce assessment scope. The exact depth of testing depends on your SAQ category or Report on Compliance requirements.

What companies do pen testing?

Penetration testing can be performed by qualified internal staff or independent third-party security firms, provided the tester has appropriate skill and no conflict of interest with the systems being tested. A Qualified Security Assessor validates your overall PCI DSS compliance but is not required to personally conduct the test itself, per PCI SSC assessment guidance.

What are the PCI compliance requirements for 2026?

PCI DSS v4.0.1, published with clarifications and updated SAQ documents following PCI SSC’s 2024 announcement, remains the current standard organizations should reference. Requirements around annual penetration testing and segmentation validation under Requirement 11.3 continue to apply, and businesses should check the PCI SSC document library for the latest SAQ updates before their next assessment cycle.

How hard is the CPent exam?

The CPENT is a hands-on offensive security certification exam and difficulty details are not addressed in this guide’s sources. Organizations evaluating a penetration tester’s qualifications should focus less on any single certification’s difficulty and more on documented experience testing payment environments similar in complexity to their own.

Recommended

• Cut PCI Work to a Few Hours: Reach SAQ A for Small Businesses
• Avoid a QSA Audit: Prove PCI SAQ A for U.S. Ecommerce (FAQ 1588)
• One Script Can Move You to SAQ D: Map Payment Form and Data Flow First