PCI DSS penetration testing requirements: what 11.4 asks

What PCI DSS penetration testing requirements ask for under Requirement 11.4

Requirement 11.4 of PCI DSS v4.0.1 asks for a documented penetration testing methodology, internal and external penetration tests at least every 12 months and after significant infrastructure or application change, segmentation testing, and retesting of exploitable findings after they are corrected. If a card brand, acquirer or customer has asked for validation and the penetration test is now on your plan, start by treating these as separate deliverables: a methodology you can show, a test cycle you can date, and proof that fixes were verified. The cost and effort of meeting them depend on the size of the cardholder data environment (CDE), how many connected and security-impacting systems sit around it, how often it changes, and whether your own staff can test it independently or you buy an external tester. Ask any provider for a written scope that lists the systems, the internal and external network ranges, the applications, and the segmentation controls to be tested.

The organization owns the test program, the scope decisions and the retained results. Requirement 11.4.1 expects the methodology to cover the entire CDE perimeter and critical systems, to test from inside and outside the network, and to validate segmentation and scope-reduction controls. Under the SAQ D note to 11.4.1, internal testing covers the CDE from inside and into it from trusted and untrusted internal networks, while external testing covers the exposed perimeter and critical systems reachable from public networks. Testers may be qualified internal staff or a qualified external third party, must be organizationally independent, and do not need to be a QSA or ASV. Confirm with your provider which people will perform the work, how their independence from the systems they test is established, and which evidence they will deliver.

A qualified tester performs the test, but only the QSA assesses it, and only in the Report on Compliance or the SAQ with its Attestation of Compliance. A penetration report alone does not validate compliance. Retain the methodology, test results and remediation records for at least 12 months, and keep a dated log of significant changes so you can show when a test was triggered. Penetration testing is also separate from vulnerability scanning: quarterly internal and ASV external scans under Requirement 11.3 run in addition to the yearly tests. Confirm the exact test intervals and retesting obligations against the current PCI SSC documents before you set your schedule, and ask your QSA early which of your systems they will sample.

How the 11.4 penetration test cycle runs each year

The sequence turns Requirement 11.4 into a repeatable cycle: a documented method, scoped targets, internal, external and segmentation tests, risk-ranked fixes with retests, and retained records that an assessor can trace from start to finish.

Document the penetration testing methodology
The organization, or the party it engages to test, writes a penetration testing methodology under Requirement 11.4.1 that follows an industry-accepted approach. It covers the full CDE perimeter and critical systems, testing from inside and outside the network, application-layer testing for the vulnerabilities listed in Requirement 6.2.4, network-layer testing of components and operating systems, and a review of threats and vulnerabilities from the previous 12 months. The step closes when the approved methodology is on file and names who owns it. An assessor will check that the document exists, matches what was actually tested, and was reviewed before the test window opened.
Define the CDE perimeter and critical systems
Before testing, the scope owner lists the cardholder data environment boundary, the systems that connect to it or affect its security, and the critical systems that sit on either side. This list feeds the methodology and the test plan. The output is a scope document with system names, network ranges, and the internet-facing addresses that count as the external perimeter. Confirm the list against the current network and data-flow diagrams, since a scope list that is out of date will leave in-scope systems untested.
Run internal penetration tests
Qualified internal staff or an independent external tester performs internal testing under Requirement 11.4.2. Internal testing covers attacks from inside the CDE and into it from trusted and untrusted internal networks. Testers must be organizationally independent of the systems they test, but they do not need to be a QSA or ASV. The deliverable is a test report listing each finding, the method used, the systems reached, and a severity assigned under the entity's risk ranking. The step is complete when the report is signed off and every finding has a tracking entry.
Run external penetration tests
The same kind of qualified tester runs external testing under Requirement 11.4.3 against the exposed perimeter and the critical systems reachable from public networks. The report follows the same structure as the internal report, with the external addresses tested and the method used for each. Note that PCI DSS external penetration testing is separate from the quarterly ASV scans required by Requirement 11.3.2, so a passing scan does not replace this step. Completion means a report that maps every exposed address in scope to a test result.
Test segmentation controls
Segmentation testing under Requirement 11.4.5 checks that the controls separating the CDE from other networks actually stop traffic that should be blocked. Service providers test on a six-month cycle under Requirement 11.4.6 rather than the annual cycle. Testers attempt to cross the boundary from out-of-scope networks, and the report records each attempted path and whether it succeeded. The output confirms the scope boundary, and any failed boundary becomes a scope problem as well as a security finding, so the scope document may need updating.
Correct exploitable vulnerabilities by risk ranking
Under Requirement 11.4.4, every exploitable vulnerability found in the tests must be corrected. The entity uses its risk ranking under Requirement 6.3.1 to set the order and deadlines for fixes, and the owner of each affected system records the change. A fix that is not applied, or that is accepted as a risk, needs a documented decision that an assessor can review. The step closes when each finding has a corrective action or a recorded risk decision, with a date and owner attached.
Retest to verify the corrections
Testing is repeated to confirm that each exploitable vulnerability has been corrected, as Requirement 11.4.4 requires. The retest should target the specific findings and the systems that changed, and it should be performed by the same kind of qualified tester who reported the issue. The retest report shows each finding as closed, still open, or reclassified with a reason. An open finding is an unresolved gap, not a closed item, so the cycle does not end until the retest report is clean or the risk decisions are documented.
Retain results and remediation records
The organization keeps the penetration test results, the remediation evidence and the retest reports for at least 12 months, as Requirement 11.4.1 requires. Records should include the methodology version, the scope document, the tester's independence statement, the reports and the change records that tie each fix to a finding. The step is complete when these records are stored in a location that the assessor can access and that is traceable to the specific test cycle. Confirm your retention policy with your assessor, since they will ask for the records that cover the period under review.

What the 11.4.1 methodology must cover

Requirement 11.4.1 expects a documented penetration testing methodology before any test runs. The cards below cover what that document must address, the evidence each element produces, and why the organization owns the document while the assessor reviews it.

Industry-accepted testing approach

The methodology must follow an industry-accepted penetration testing approach, and the organization must be able to name the one it uses. Common references include publicly available testing frameworks and guides, but the choice belongs to the organization and must be written down. Check that the document states the phases of a test, the tools and techniques allowed, and how findings are rated. Evidence is the methodology document itself, with a revision history showing it was reviewed and approved.

Entire CDE perimeter and critical systems

The methodology must cover the whole cardholder data environment perimeter and the critical systems inside it, not only the hosts someone remembered to list. Scope should trace back to the current network and data-flow diagrams and the system inventory. Ask who maintains that list and how new systems enter it. Evidence is a scope statement mapped to the CDE inventory, with the date it was last confirmed.

Testing from inside and outside the network

The methodology must describe testing from inside the network and from outside it, because the threats differ. Internal tests cover access into and out of the CDE from trusted and untrusted internal networks. External tests cover the exposed perimeter and critical systems reachable from public networks. Evidence is a separate test plan for each direction, with the source addresses, accounts or access level used for each.

Application-layer testing and 6.2.4 vulnerabilities

The methodology must include application-layer testing that covers at least the attack types listed in Requirement 6.2.4, the secure coding requirement for software. Testers should check authentication, session handling, input validation and access control in each in-scope application. Confirm that the test scripts or checklists map to 6.2.4 item by item. Evidence is a test case list per application, linked to the findings and retest records.

Network-layer testing of supporting components

The methodology must cover network-layer testing of the components that support network functions, along with the operating systems those components run. This includes firewalls, routers, load balancers, DNS, management interfaces and the hosts beneath them. Check that the plan lists each device class and its test depth. Evidence is an asset-level test record showing which components were tested, the operating system version tested, and the findings raised.

Review of threats from the last 12 months

The methodology must include a review of threats and vulnerabilities seen in the previous 12 months, so the test reflects current attacker behavior and not last year's plan. Sources can include vulnerability advisories, incident records, threat intelligence and changes to the environment. Ask the team to show how each threat changed the test plan. Evidence is a dated threat review that feeds into the scope and test cases for the cycle.

When internal, external and segmentation tests apply

Internal penetration testing covers the cardholder data environment from the inside. Under the SAQ D note on Requirement 11.4.1, internal testing means testing from inside the CDE and into it from both trusted and untrusted internal networks. That second part matters: a test that starts from a corporate user segment, a guest network or a partner VLAN that can reach the CDE is in scope even though it never touches the internet. External testing is the mirror image. It covers the exposed external perimeter and any critical system reachable from public networks. Confirm your network diagrams and data-flow diagrams list every path into the CDE, because those paths define which internal starting points and which external targets your tester must cover.

Internal testing under 11.4.2 and external testing under 11.4.3 each must run at least once every 12 months and again after any significant infrastructure or application upgrade or change. The annual clock alone is not enough. A firewall rule change that opens a new path, a new payment application release or a migration to a different cloud account can each trigger a retest, so the change management process should flag these events for the security team. Segmentation has its own triggers. Under 11.4.5, segmentation controls must be penetration tested at least every 12 months and after changes. Service providers face a shorter cycle under 11.4.6, where the interval is every six months. If your segmentation is what keeps out-of-scope systems out of the CDE, a failed segmentation test changes your scope, not just your findings list.

Multi-tenant service providers carry an extra duty under 11.4.7. Since 31 March 2025, they must support their customers' external penetration testing, either by providing evidence of testing on the infrastructure a customer subscribes to, or by giving customers prompt access to test. Providers should decide which option they will offer and document it before a customer asks. Penetration testing is also separate from scanning. Requirement 11.3 requires quarterly internal and ASV external vulnerability scans in addition to the yearly tests in 11.4, so a clean quarterly scan does not satisfy the penetration testing obligation. Confirm with your assessor which test types and dates they expect to see in your evidence set.

Who can perform the test: internal staff or an external firm

Your own security or engineering staff can perform internal and external penetration tests if they are qualified and organizationally independent from the teams that build and run the systems being tested. The standard does not require a QSA or ASV credential for testers, and it does not require any PCI SSC certification of individuals. What matters is that the person can demonstrate skill in penetration testing and that their reporting line does not let the system owner shape the results.

Independence in practice: The tester should not administer the CDE, approve its changes, or report to the manager accountable for the systems under test.
Demonstrable skill: Keep training records, prior testing experience, and certifications your organization values, and be ready to explain them to the assessor.
Documented methodology: Internal testers must follow the same methodology required by 11.4.1 as any external firm would.
Results and retention: Keep reports, evidence of exploitation, and remediation records for at least 12 months.
Tooling and access: Confirm that the team has authorized access to segmentation boundaries and the tools to test them.

Fits best when your team has a dedicated offensive security function with a clear reporting line separate from operations. Ask your assessor to confirm early how they will judge independence, because the answer depends on your org chart and not only on job titles.

What a penetration test program costs and who is paid

This table compares the cost components of a PCI DSS penetration test program, showing who is paid, whether each cost is one-time or recurring, and what drives it up. No official cost figure exists for PCI DSS penetration testing, so use the table to structure written scope quotes and to see which costs stay with your own team.

Cost component	Who is paid	One-time or recurring, and what drives it
Internal tester time	Your own staff (salary allocation) or a qualified internal team member	Recurring each cycle. Driven by CDE size, number of segments, and how many retests are needed after significant change
External penetration testing firm	Third-party tester or testing firm you engage	Recurring at least every 12 months and after significant change. Driven by number of exposed hosts, applications, APIs, and whether segmentation testing is included
Segmentation testing	Internal team or the external testing firm	Recurring every 12 months and after changes, or every six months for service providers. Driven by number of segmentation controls and the scope-reduction claims you rely on
Tooling and licenses	Tool vendors and open-source maintainers (support contracts)	Mostly recurring for commercial licenses and support. Driven by the number of testers, platforms covered, and whether tooling is open source
Retesting after remediation	External firm (if contracted) or your internal testers	Recurring per finding cycle. Driven by the number of exploitable vulnerabilities and how many fixes need verification under Requirement 11.4.4
QSA time reviewing test evidence	Qualified Security Assessor (paid by you)	Recurring at each assessment. Driven by how complete your methodology, scope and results records are before the assessor starts
Remediation engineering	Your engineers, or a partner you engage for fixes	Often the largest variable cost. Driven by the number and severity of findings, and by the risk ranking applied under Requirement 6.3.1
Documentation and methodology upkeep	Your security team or a consulting partner	Recurring annually and after changes. Driven by how often the testing methodology and scope change

How exploitable findings must be fixed and retested

Requirement 11.4 does not end when the tester writes the report. Exploitable findings must be corrected, the correction must be verified by retesting, and the evidence must be kept. The cards below follow that chain from risk ranking through retention, including what to do when a fix cannot land quickly.

Rank findings before fixing them

Exploitable vulnerabilities are corrected according to the entity's own risk ranking under Requirement 6.3.1, not in the order a tester lists them. Confirm that your penetration test reports state exploitability, affected components and the system's position relative to the CDE, because those facts drive the ranking. A finding on a system that stores or transmits account data normally sits higher than the same flaw on an isolated test host. Check that the ranking method is documented and that the person assigning severity is not the same person who approved the fix.

Retest to confirm the fix

Requirement 11.4.4 expects the testing to be repeated to verify that exploitable vulnerabilities were corrected. A retest should target the same attack path the original tester used, not only a rescan of the affected host. Ask the tester to record the date, the scope retested and the result for each finding. A finding marked fixed without a retest result is an open item in an assessor's eyes.

Document each remediation step

Keep a remediation record for every finding that links the original report, the change ticket, the owner, the fix applied and the retest result. Auditors test whether remediation is traceable from the test finding to the change in production. Where a fix was made in code, link the commit or release. Where a configuration changed, link the change record. Gaps in this chain are the most common reason evidence is questioned during a QSA review.

Retain penetration test evidence

Penetration testing results and remediation results must be retained for at least 12 months. Store the report, the scope statement, the methodology, the retest output and the change records together so they can be produced as one set. Confirm where the archive lives, who can access it and whether it survives a change in the systems that produced it. Evidence kept only in a tester's portal or a departed employee's mailbox may not be available when the assessor asks.

Plan for fixes that take longer

Some exploitable findings cannot be corrected quickly, for example when a vendor patch is unavailable or a legacy system must stay in service. Record the risk, the interim controls such as network restriction or monitoring, the approver and the planned correction date. Interim controls are a temporary position, not a substitute for the fix. Ask your QSA how they will evaluate the documented position before the assessment begins.

Assessors evaluate alternative approaches

If an organization meets an objective through a compensating control or a customized approach rather than the defined approach, the QSA assesses whether that alternative meets the stated objective. Your team does not decide that on its own. Prepare the targeted risk analysis, the control design and the evidence of operation before the assessment, and expect the QSA to test them. Consultants can help document an alternative, but the QSA issues the conclusion.

How to plan the first penetration test for a PCI DSS assessment

The sequence moves from agreed scope and methodology through testing, reporting, remediation and retest to evidence that the QSA or an SAQ submission can rely on. Each phase closes with a defined output, so the organization knows when it can move on.

Confirm the cardholder data environment and segmentation scope
Before any tester is engaged, the organization confirms what sits inside the CDE, which systems connect to it or could affect its security, and where segmentation controls separate the two. Requirement 11.4.1 expects the methodology to cover the entire CDE perimeter and critical systems, so an incomplete scope produces a test that assessors will reject. The output is a written scope statement with network diagrams and a list of in-scope IP ranges, applications and segmentation controls. The step is done when the CDE owner and the assessor agree that the scope matches the data-flow diagrams.
Select a qualified and independent tester
The organization chooses between qualified internal staff and an external third party. Under Requirements 11.4.2 and 11.4.3, the tester must be organizationally independent and qualified, but does not need to be a QSA or ASV. Ask the provider to describe the testers' experience, the methodology they use and how they separate testing from any remediation or consulting work they perform for you. The output is a signed engagement letter that names the tester, the scope and the rules of engagement. Confirm the timing and fees in the written scope, not in a verbal estimate.
Sign off the penetration testing methodology
Requirement 11.4.1 expects a documented methodology based on an industry-accepted approach. The methodology must include application-layer testing for at least the vulnerabilities in Requirement 6.2.4, network-layer testing of components that support network functions and operating systems, and a review of threats and vulnerabilities from the previous 12 months. The output is a methodology document that the tester and the organization both approve, with each test type mapped to the systems in scope. The step is done when the QSA or internal assessor can trace each requirement element to a test activity.
Execute internal and external tests from both sides of the boundary
Testing runs in two directions. Internal testing covers the CDE from inside, and into it from trusted and untrusted internal networks, under Requirement 11.4.2. External testing covers the exposed perimeter and critical systems reachable from public networks under Requirement 11.4.3. Segmentation testing under Requirements 11.4.5 and 11.4.6 checks that the controls isolating the CDE hold. The output is a set of raw findings, tool logs and tester notes, each tied to a system and a date. Keep the logs, since they are part of the evidence.
Produce the penetration test report
The tester writes a report that states the scope, methodology, dates, testers, findings and the exploitability of each vulnerability. The organization reviews the report for accuracy against the agreed scope, not to change the findings. The output is a final report with a risk ranking for each finding, aligned with the entity's risk ranking under Requirement 6.3.1 where that ranking applies. The step is done when the report has been accepted in writing by the security owner.
Correct exploitable vulnerabilities and track remediation
Requirement 11.4.4 requires exploitable vulnerabilities to be corrected according to the entity's risk ranking, and the organization owns that work. Each finding gets an owner, a target and a change record. Where a fix is not possible, the organization documents the compensating control or customized approach under its own rules and expects the QSA to assess it. The output is a remediation register that links each finding to the change or control that closed it. Ask your engagement team to confirm which remediation work, if any, they will do and how that work stays separate from the independent test.
Retest to verify the corrections
Requirement 11.4.4 requires the testing to be repeated to verify that the corrections worked. The retest focuses on the findings that were closed, plus any system changed during remediation. The output is a retest report that shows each finding as resolved or still open, with the evidence. Open findings return to remediation, and the cycle repeats until the register is closed or formally accepted.
File the evidence for the QSA or the SAQ submission
Penetration testing and remediation results must be retained for at least 12 months under Requirement 11.4.1. The organization files the scope statement, methodology, tester qualification evidence, reports, retest results and remediation register in a single evidence folder with a clear index. For a ROC, the QSA samples this material during the assessment. For an SAQ, the organization keeps the same material available to support its attestation. The step is complete when someone outside the test team can follow the trail from scope to closed finding.

What must be in place before the test starts

A penetration test under Requirement 11.4 is only as useful as its starting point. The items below fix the scope, the method, the tester's standing and the rules for testing live systems, so the results can be traced to a defined cardholder data environment and reused as evidence later.

Current CDE and segmentation diagrams

Start with diagrams that show where cardholder data is stored, processed and transmitted, and which systems connect to the cardholder data environment (CDE). The segmentation controls that separate the CDE from other networks must be drawn too, because Requirement 11.4.1 expects the methodology to cover the CDE perimeter and validate segmentation. Check that the diagrams match the live environment, not last year's design. A tester who finds an unlisted path into the CDE will report it, and the gap will land in your assessment.

Significant changes since the last test

Prepare a dated list of significant infrastructure and application changes made since the previous test, such as new network paths, platform upgrades, new payment flows or changed firewall rules. Requirements 11.4.2 and 11.4.3 require testing after any significant upgrade or change, so this list decides whether an out-of-cycle test is needed before the next annual date. Record who approved each change and where the change record lives, so an assessor can match each change to the testing that followed it.

Signed penetration testing methodology

Document the penetration testing methodology before work begins. Requirement 11.4.1 expects an industry-accepted approach that covers application-layer testing for the vulnerabilities listed in Requirement 6.2.4, network-layer testing of components that support network functions and operating systems, and a review of threats and vulnerabilities from the last 12 months. Have the owner approve it in writing, and confirm that the tester will follow it and that the methodology defines how exploitable findings are rated.

Tester independence confirmation

Obtain written confirmation that the testers are qualified and organizationally independent from the teams that build, run or secure the systems under test. Internal staff and external firms both qualify under Requirements 11.4.2 and 11.4.3, and a QSA or ASV credential is not required for the penetration test itself. Keep the qualification records and the independence statement on file, since an assessor will ask for them. Confirm that the same party is not also remediating the findings it reports.

Rules of engagement

Agree rules of engagement in writing before any testing starts. They should name the in-scope targets, the test windows, the permitted techniques, the points of contact, the process for stopping a test, and how sensitive data encountered during testing is handled. Testing inside the CDE needs particular care, because a successful exploit can expose real cardholder data. Confirm that the agreed scope matches the diagrams and the change list above, and that any system left out is recorded with a reason.

Findings and retest register

Set up a register before the first finding arrives. Each entry should record the finding, its risk ranking under Requirement 6.3.1, the owner, the fix date, the retest result and the retest date. Requirement 11.4.4 requires exploitable vulnerabilities to be corrected and the testing repeated to verify the corrections. Retain penetration test and remediation results for at least 12 months, so the register can answer an assessor's questions from the previous cycle.

Penetration testing questions buyers ask before hiring help

Can our own security staff perform the PCI DSS penetration test?

Yes, if they are qualified and organizationally independent. Requirements 11.4.2 and 11.4.3 allow either qualified internal staff or a qualified external third party to perform internal and external penetration testing. Independence means the testers are not responsible for building or operating the systems they test, so the people who run the firewall or write the application code should not be the only people judging it. Your assessor will ask how you established both qualifications and independence, so document the testers' experience, training and reporting line before the test starts. Internal staff can still need an outside firm for specialist depth, a second opinion or independence, and that choice is yours to make. Ask any partner to explain how their testers stay independent of the systems they assess.

Does a QSA have to perform our penetration test?

No. The supplied requirements do not require a Qualified Security Assessor to perform penetration testing, and testers do not need to be a QSA or an ASV. The QSA's role is to assess your evidence during the validation, so the QSA reviews the test methodology, reports and remediation records rather than running the test. Some organizations use the same firm for both, but that choice has consequences for independence and cost, so check with your QSA before combining the roles. Whoever performs the test, the organization owns the testing program and its results. An implementation partner can prepare the environment and evidence, but only the independent assessor issues the Report on Compliance or the Attestation of Compliance.

How often must penetration testing happen and what triggers a retest?

Internal and external penetration testing must run at least once every 12 months and after any significant infrastructure or application upgrade or change. A significant change is one you define in your change process, so write down the criteria, such as a new payment flow, a new hosting platform, a changed firewall ruleset or a major application release. Segmentation testing has its own schedule, covered in the next question. Retain penetration test and remediation results for at least 12 months. A useful practice is to link the change management ticket to a test decision, so the assessor can see why a change did or did not trigger retesting.

What does the penetration testing work require from our team?

The work requires a documented methodology, access, scope definition and someone to act on the findings. Requirement 11.4.1 expects an industry-accepted methodology covering the full CDE perimeter and critical systems, tested from inside and outside the network, and it must include application-layer testing for the Requirement 6.2.4 vulnerabilities and network-layer testing of components and operating systems. Your team must supply an accurate network and data-flow diagram, asset inventory, test accounts, change records and a named owner for each finding. Plan for remediation: exploitable vulnerabilities must be corrected according to your risk ranking under 6.3.1 and the test repeated to verify the fix. Ask any provider to confirm which of these inputs they expect from you and how long they need before the test window opens.

How does segmentation penetration testing differ from the standard test?

Segmentation testing checks whether the controls that separate the CDE from other networks actually work, which is a separate test from the general perimeter and internal tests. Requirement 11.4.5 requires segmentation testing at least every 12 months and after changes, while Requirement 11.4.6 requires it every six months for service providers. If you rely on segmentation to reduce scope, the test must show that systems outside the segment cannot reach the CDE. Plan this test with the people who own your firewalls and network design, and include the connection paths you believe are blocked, not only the ones you expect to be open. Confirm with your assessor whether the segmentation results will be reviewed alongside your scope definition.

How do we check tester independence and what does the partner not provide?

Ask the provider to show, in writing, who will test, what qualifications they hold, and how they are organizationally separate from the teams that built or operate your systems. Keep that statement in your evidence file along with the engagement letter and the test report. An implementation partner or testing firm does not issue the report or the Attestation of Compliance. The organization owns the controls and the results, the testing firm performs and documents the test, and only the independent assessor or the applicable reporting process confirms compliance. Also confirm that penetration testing is separate from quarterly vulnerability scanning under Requirement 11.3, because scan reports will not replace the yearly test. Confirm the exact deliverables, retesting scope and retention period in the written scope before work begins.

How to choose a penetration tester for PCI DSS

Requirement 11.4 leaves the choice of tester to you, but the evidence you hand an assessor depends on who did the work and how it was documented. The cards below cover the checks that separate a usable penetration test from one a QSA will question. A QSA reviews the results independently, so a clean report does not replace that review.

Documented methodology aligned to 11.4.1

Ask for the tester's written methodology before signing. It should cover the entire CDE perimeter and critical systems, testing from inside and outside the network, application-layer testing for the vulnerabilities in Requirement 6.2.4, network-layer testing of supporting components and operating systems, and a review of threats from the last 12 months. Confirm the document names an industry-accepted approach and how segmentation validation is performed. A methodology that omits any 11.4.1 element will need rework before the QSA sees it.

Organizational independence from the CDE team

Testers may be qualified internal staff or an external third party, but they must be organizationally independent. Internal testers should not report to the people who build or run the cardholder data environment, and an external firm should not also operate the systems it tests. Ask who the tester reports to, whether anyone involved in the environment reviews the findings, and how conflicts are handled. Independence is a requirement you must be able to explain, not a courtesy.

Experience with payment environments

Ask for named testers with hands-on work against cardholder data environments, including segmentation testing, payment applications and cloud-hosted CDEs. Request sample scope descriptions from comparable engagements, with client names removed. Qualifications such as industry certifications are not a PCI DSS requirement, so verify them directly with the issuing body rather than accepting a logo. Confirm who performs the work, not only who sells it.

Written scope and rules of engagement

Before testing starts, agree in writing on the systems in scope, IP ranges, application entry points, testing windows, permitted techniques and exclusions such as production data handling. Include escalation contacts and the process for stopping a test that disrupts service. Ask how the tester will confirm that out-of-scope systems were not touched. The scope document is the first thing a QSA compares against your network and data-flow diagrams.

Retest terms and remediation verification

Requirement 11.4.4 requires exploitable vulnerabilities to be corrected by risk ranking and the testing repeated to verify the fix. Confirm in the contract whether retesting is included, how many rounds are covered, how long after the report it must happen, and whether retests use the same methodology. Ask for retest results to be recorded separately so they can be retained with the original findings for at least 12 months.

Evidence package delivered

Agree the deliverables before testing begins. A usable package usually includes the methodology used, scope and exclusions, testing dates, tester names and qualifications, findings with reproduction steps and risk ratings, and retest evidence. Confirm the report separates internal and external testing, since 11.4.2 and 11.4.3 are assessed separately. Ask whether the tester will answer assessor questions during the QSA review, and who pays for that time.

Who owns the test, who performs it and who assesses it

The organization owns its penetration testing obligation, its scope and its results. Requirement 11.4 applies to the entity being assessed, so the entity must define the cardholder data environment perimeter, decide which critical systems are in the test, approve the methodology, track findings to remediation and keep the results and remediation records for at least 12 months. An implementation partner can plan the work, run the tests and write up the findings, but it cannot take over the accountability that stays with the entity's own leadership and its assessor.

Testers may be qualified internal staff or a qualified external third party. Either way, the tester must be organizationally independent of the systems being tested and of the team that administers them. Under the standard, the tester does not need to be a QSA or an ASV, so a penetration testing firm can perform 11.4 work without holding either credential. Before you engage anyone, ask the provider to show its testers' qualifications, explain how independence is maintained (for example, who approves the test plan and who receives the report), and confirm that its methodology covers application-layer, network-layer and segmentation testing as described in your methodology document.

Only the independent assessor decides whether the requirement is met. If you validate with a Report on Compliance, a Qualified Security Assessor completes the ROC and signs the Attestation of Compliance. If you validate with a Self-Assessment Questionnaire, the entity itself completes the questionnaire and signs the Attestation of Compliance, and the penetration test evidence still has to exist and be accurate. DeployOpen runs security testing and prepares evidence for assessments, but it does not issue reports or certificates, and engaging it does not guarantee a passing result. Agree in writing with your assessor which test evidence they will accept before the test begins, so that the report you commission can be used directly in the assessment.

How DeployOpen scopes and runs penetration testing for PCI DSS

DeployOpen works on PCI DSS penetration testing requirements by preparing the systems, methodology and evidence that an in-house or independent tester needs to run Requirement 11.4 tests. Testing itself is performed by qualified testers who are organizationally independent of the systems being tested, and the organization keeps ownership of its controls and results.

How we scope

Written scope lists the cardholder data environment perimeter, critical systems and segmentation controls to be tested.
Scope notes separate internal testing from external testing, so each Requirement 11.4 test has a defined boundary.
Scope, deliverables and timelines are agreed in writing before any work starts, and most engagements are fixed-scope.

How we build

We help document a penetration testing methodology covering application-layer, network-layer and segmentation testing.
We prepare test environments, accounts and access so testers can work inside and outside the network as scoped.
We set up tracking for findings, risk rankings and retesting so corrections can be verified against the original issue.

How we hand over

You receive documented methodology, scope records, test plans and the raw evidence needed for assessor review.
Remediation records show each exploitable finding, its correction and the retest that confirmed it was fixed.
Retained results cover the required 12-month period, with an index that maps each artifact to its Requirement 11.4 sub-requirement.

How we support

Ongoing support is available as a retainer for repeat tests every 12 months and after significant changes.
We can help update scope and methodology when infrastructure or applications change between annual cycles.
Ask your assessor or independent tester to confirm which artifacts they will accept before your first test begins.