PCI DSS penetration testing

Why PCI DSS penetration testing is required before your next assessment

If a QSA, acquirer or payment partner is expecting evidence under requirement 11.4 of PCI DSS v4.0.1, the penetration test must cover the cardholder data environment (CDE) from inside and outside the network, including segmentation and both application-layer and network-layer testing. The result you receive is a written report of what was tested, what was found, how exploitable findings were corrected, and the retest that verified those corrections, all retained for at least 12 months. DeployOpen plans and delivers this testing against a written scope, but it does not issue Reports on Compliance, Attestations of Compliance or certifications. Those decisions rest with your QSA, your acquirer and, where applicable, the card brands. The test exists to find the paths an attacker could use to reach stored, processed or transmitted account data. In practice that means exploitable routes from internet-facing services, from employee workstations and from other networks into systems in scope, along with weak or unverified segmentation that would let an out-of-scope system reach the CDE. It also addresses unmanaged change: requirements 11.4.2 and 11.4.3 call for testing after significant changes, so a new payment service, a migrated cloud account or a changed firewall rule can invalidate the last report. Ask your QSA to confirm which of your recent changes count as significant under your own change process before you set the test date.

Before you commission the work, confirm three things in writing. First, the CDE boundary and its data flows, since the tester can only validate segmentation against a boundary you have defined and can show. Second, the tester's organizational independence and qualifications as described in requirement 11.4.3, which do not require a QSA or ASV, so check your QSA's expectations for evidence of those qualifications. Third, which systems are shared with other entities or hosted by a service provider, because responsibility for testing those components may sit with a different party. Reading the PCI SSC blog announcement for v4.0.1 will confirm which version your assessment references, and that version is the one your scope document should cite.

What belongs in scope for PCI DSS penetration testing

Requirement 11.4.1 expects the methodology to reach the entire cardholder data environment (CDE) perimeter and critical systems, so scope starts with a documented map of what stores, processes or transmits account data and what can affect it. The cards below cover the components and decisions a buyer should agree in writing before a tester begins.

CDE perimeter and critical systems

The perimeter is the boundary between the cardholder data environment and everything else, and the test has to reach both sides of it. Critical systems include anything that can affect the security of the CDE, such as authentication services, logging, time sources and security tooling. Ask for a current data flow diagram and an inventory that names each system in scope and the reason it is there. Gaps in that inventory are where testing usually falls short.

External and internal network exposure

Requirement 11.4.2 and 11.4.3 call for both internal and external tests, so scope has to include public IP ranges, cloud-facing endpoints, and internal network segments reachable from user, server and management zones. Confirm which address ranges belong to the CDE, which are shared hosting or third-party space, and where the tester will start from. Internal testing from a realistic foothold is a separate decision from external testing and should be stated explicitly.

In-scope applications and APIs

Payment pages, checkout flows, payment APIs, card tokenization services and back-office portals that touch account data all belong in scope, along with the authentication and session logic behind them. Application-layer testing under 11.4.1 is expected alongside network-layer testing, so the test cannot stop at the infrastructure. List each application, its environments, and whether production or a production-like copy will be tested. Note any test accounts the tester needs.

Administrative access paths

Jump hosts, bastion services, VPN and remote access gateways, privileged consoles and identity providers are the routes an attacker would use to reach the CDE, so they belong in scope even when they sit outside it. Include the management plane for cloud accounts and container platforms that host CDE workloads. Ask the tester to confirm which of these paths it will attempt to use and which it will only review for configuration.

Segmentation validation boundaries

Segmentation testing under 11.4.5 checks whether out-of-scope networks can reach the CDE, so the scope must name the segments on both sides of each control. Decide the frequency up front: segmentation testing must occur every 12 months and after changes to segmentation controls, and service providers using segmentation as a scope reduction method have a six-month cadence. Ask which segment-to-segment paths will be tested and what evidence the tester will return for each.

Third-party components and rules of engagement

Hosted payment services, managed firewalls, cloud providers and integrated SaaS tools can sit inside the testing boundary even when another company operates them, and each provider's testing permissions may differ. Write down the accounts and roles the tester will use, the testing windows, the stop conditions, and the contacts who can halt a test. Agree the rules of engagement in writing before work begins, and confirm the tester holds approval from each third party whose infrastructure is touched.

How the penetration test runs from scoping to retest

The sequence turns a documented cardholder data environment into a tested, evidenced and retested set of results that a QSA or an acquirer can check against requirement 11.4. Each phase produces an artifact the next phase depends on, so gaps in scoping show up as gaps in the final report.

Confirm the cardholder data environment scope
Before testing starts, the client confirms the cardholder data environment (CDE) boundary, the in-scope systems, the data flows that touch account data and the segmentation controls that separate the CDE from other networks. DeployOpen reviews the network diagrams, data flow documentation and asset inventory against what is actually reachable, then records the agreed scope in writing. The step is complete when the client signs off a scope document that lists every in-scope IP range, application and segmentation boundary, and the assumptions behind them. Items that are unclear or undocumented are flagged here, because they cannot be tested as if they were known.
Define the test methodology and rules of engagement
The tester documents a penetration testing methodology that covers the full CDE perimeter and critical systems, with application-layer and network-layer testing from both inside and outside the network. The methodology also sets segmentation validation, the review of threats from the last 12 months, testing windows, authorized accounts, escalation contacts and stop conditions. The client approves the rules of engagement in writing. The step closes when the methodology and rules are attached to the statement of work and the client's named contacts know how to halt testing if production is affected.
Test from outside and inside the network
External testing examines the CDE perimeter as an outside attacker would see it, including public services, remote access points and exposed applications. Internal testing starts from positions the client agrees to, such as a standard user segment or a system in an adjacent network, to assess what an attacker with a foothold could reach. Segmentation testing checks whether the controls separating the CDE from other networks actually hold. Testers record each finding with evidence, affected asset and the conditions needed to reproduce the issue for the client, without publishing exploit code or step-by-step attack sequences in the report.
Classify findings by severity and exploitability
Each confirmed weakness is rated on severity and on whether it can be exploited in the client's environment, with the reasoning written next to the rating. Testers separate confirmed exploitable issues from configuration observations and theoretical weaknesses, so that requirement 11.4.4 work is focused on what actually opens a path to the CDE. The client reviews draft ratings with the tester to correct context, such as compensating controls that were not visible during testing. The step is complete when every finding has an evidence reference, a rating and a plain statement of its exploitability.
Deliver the report and remediation plan
The final report states the scope tested, the methodology applied, the testing dates, the tester's qualifications and the organizational independence of the testing team from the systems owner. It lists each finding with its rating, evidence, affected components and recommended correction. The client receives the report and a remediation plan that assigns owners and targets for exploitable findings. The step is complete when the client accepts the report and the remediation plan is recorded in the client's own tracking system, where it will be retained with the test records.
Remediate exploitable findings
The client's engineering and operations teams correct the exploitable findings and document each change, including configuration updates, patches, code fixes or segmentation changes. DeployOpen can advise on fixes or support the client's teams, but remediation work that implements or operates a control remains the client's responsibility, which keeps the test independent of the controls it checks. The step is complete when each exploitable finding has a recorded correction, a date and the name of the person who approved it, ready for verification.
Retest to verify the corrections
Under requirement 11.4.4, exploitable findings must be corrected and the testing repeated to verify the corrections. The retest covers the specific findings and the surrounding controls that might be affected by the fix, using the same methodology and scope as the original test. Testers record whether each finding is closed, partially closed or still open, with evidence for each status. The step is complete when the retest report and the closed findings list are issued, and both go into the 12-month record retention set alongside the original report and the remediation records.
Retain records for assessment and reassessment
Requirement 11.4.1 expects results and remediation records to be retained for at least 12 months. The client stores the scope document, methodology, rules of engagement, report, remediation records and retest report in a location its assessor can access during the next assessment. The client confirms with its QSA or acquirer which format they accept and whether a summary letter or the full report is requested. The step is complete when the record set is indexed and the client knows when the next internal and external tests fall due under requirement 11.4.2 and 11.4.3, along with any test triggered by a significant change.

Internal, external, segmentation and application tests explained

PCI DSS v4.x requirement 11.4 separates penetration testing into test types, and each one must appear in your defined methodology under 11.4.1. Internal testing (11.4.2) examines the cardholder data environment (CDE) from inside the network, starting from positions an attacker could plausibly reach, such as a compromised workstation on a corporate segment. External testing (11.4.3) examines the same environment from outside, against the internet-facing addresses, services and cloud endpoints that expose the CDE. Both must run at least once every 12 months and after significant changes. Your methodology should name the in-scope systems for each test, the vantage points used, and how the team decides which assets are tested from where. Confirm the asset list with your assessor before testing starts, so the test covers the full CDE perimeter and critical systems.

Segmentation validation is a separate test, and its frequency depends on how you isolate the CDE. The requirement sets the cadence at every 12 months for service providers and every six months where segmentation controls are used to reduce scope, so confirm the exact wording for your entity type in the standard before you set the calendar. The test checks whether systems outside the CDE can reach it through firewall rules, network paths, shared identity services or management planes, and it should be repeated after any change to those controls. Application-layer testing sits in the same methodology, covering the payment and authentication flows that handle cardholder data, not only the network stack. Ask the tester to list which application functions, roles and APIs were covered, because that list is what an assessor will check.

Testers must be qualified and organizationally independent, but they do not need to be a QSA or an ASV. An internal team can perform the test if it reports independently of the teams that run the systems under test, and an external firm can perform it without being your QSA. Ask for evidence of tester qualifications and of the reporting line, since assessors will review both. A significant change triggers a retest outside the annual cycle. Illustrative examples include a new payment connection, a change to segmentation controls or a major platform upgrade. Define what counts as significant in your change management policy so the trigger is settled before a change ships, not debated afterward.

Weakness categories a PCI penetration test looks for

This table maps the weakness categories a PCI penetration test examines to the cardholder data environment (CDE), showing what each looks like in that target and why it matters to cardholder data. Read each row as a question the test must answer for the CDE boundary, the segmentation controls and the payment flows. The main takeaway is that a test covering only external addresses misses most of the paths an attacker would use to reach stored card data.

Weakness category	What it looks like in the CDE	Why it matters to cardholder data
Exposed external services	Internet-facing hosts, VPN endpoints, remote management interfaces or forgotten services that resolve to the CDE or its supporting systems	Each exposed service is an entry point into the environment that holds or transmits account data, and the external test must cover the full CDE perimeter
Weak segmentation between the CDE and corporate networks	Firewall rules or network paths that allow traffic from corporate, development or vendor networks into CDE subnets that were meant to be isolated	If segmentation fails, systems outside the CDE fall into PCI scope, and an attacker on a corporate host may reach card data directly; segmentation testing confirms the boundary works as designed
Misconfigured administrative access	Management consoles, jump hosts or database admin interfaces reachable from broad networks, or default and shared administrative accounts left in place	Administrative paths often carry the broadest rights to card data and logs, so a misconfiguration here can expose the whole environment at once
Flawed authentication and payment flows in web and API applications	Weak session handling, broken access checks between merchant and cardholder functions, or input handling flaws in checkout, tokenization and payment APIs	These flows handle cardholder data in transit and at rest, so a flaw can expose primary account numbers or allow transactions to be altered, and application-layer testing is required under the standard
Weak credentials or privilege paths in internal networks	Reused passwords, service accounts with excessive rights, or trust relationships that let a low-privilege foothold move toward CDE systems	Internal testing shows whether a compromised workstation or vendor account can escalate to systems that store or process card data, which external testing alone cannot show
Unpatched or outdated components	Known vulnerable versions of operating systems, databases, payment middleware or web frameworks inside the CDE	Known weaknesses in CDE components are a common route to data access, and the test should confirm which findings are exploitable in this environment rather than only listing scanner output
Gaps in logging and detection during testing	Tester activity that goes unrecorded or unalerted, or monitoring that does not cover CDE segments	Testers must be able to show what was tested and what was detected, because the results feed remediation records and the 12-month retention evidence the standard requires

How PCI DSS penetration testing relates to ASV scans, SAQ and ROC

The Self-Assessment Questionnaire D for Service Providers is the route many smaller or lower-volume service providers use to validate compliance themselves. The questionnaire asks whether penetration testing is performed and how it is scoped, and the answers must be supported by records. A penetration test report is the usual evidence behind those answers, so the test should be scoped to the cardholder data environment (CDE) and its connected systems as the questionnaire describes them. PCI DSS v4.0.1, published on 11 June 2024, replaced v4.0, which was retired on 31 December 2024, so the questionnaire version in use should match the current standard.

Questionnaire version: Confirm you are completing the SAQ version that matches PCI DSS v4.0.1, not a version tied to the retired v4.0.
Answers backed by records: Each yes answer on testing needs a report, scope statement or remediation record that a reviewer can trace.
Scope alignment: The CDE boundary in the questionnaire should match the scope in the penetration test statement of work.
Acquirer expectations: Some acquirers request the report itself, while others accept a signed summary. Ask which they require.
Signatory responsibility: The person who signs the attestation is accountable for the accuracy of testing answers, so they should review the report before signing.

Before signing, check with your acquirer which evidence they accept for testing and whether they expect a specific format.

What you receive and whether your QSA will accept it

A PCI DSS penetration test is only useful if the report answers the questions a QSA asks under Requirement 11.4. The cards below cover what the report should contain, how findings and retests close out, and how the records are kept. Confirm the format with your QSA before the engagement starts.

Scope and methodology statement

The report should state which systems, networks and applications were in the test, which parts of the cardholder data environment (CDE) they belong to, and the methodology followed. Under Requirement 11.4.1 the methodology must be defined and cover the entire CDE perimeter and critical systems. Check that the report ties each in-scope asset to the CDE boundary your QSA has documented, and that it lists any excluded items with the reason.

Tester qualifications and independence

Requirements 11.4.2 and 11.4.3 call for a qualified tester with organizational independence, though the tester does not need to be a QSA or ASV. The report should include a statement of who performed the work, their relevant experience, and their independence from the team that builds or operates the systems under test. Ask your QSA whether they want that statement as a standalone letter or inside the report.

Findings with severity and exploitability

Each finding should describe the weakness category, the affected component, the evidence that it was confirmed, and whether it could be exploited to reach the CDE. Severity should be explained against a stated scale rather than asserted. Requirement 11.4.4 focuses on exploitable findings, so the report should separate those from informational items. Ask the provider to show how exploitability was judged.

Segmentation test results

When segmentation controls are used to reduce scope, the report needs a separate section showing what was tested, from which network positions, and what was reachable. Results should state whether segmentation was validated and which out-of-scope networks were confirmed isolated from the CDE. Because segmentation testing frequency depends on the scope reduction method, confirm with your QSA which segmentation controls they expect to see covered.

Remediation guidance and retest results

Remediation guidance should give a practical fix for each exploitable finding, not only a rating. Requirement 11.4.4 requires the corrections to be verified by repeating the testing, so the report should record the retest date, the result for each finding, and any residual risk accepted by the owner. A retest summary that marks each item as closed or open is often the evidence a QSA looks for first.

Records kept for at least 12 months

Requirement 11.4.1 requires results and remediation records to be retained for at least 12 months. Store the final report, the scope document, tester evidence, retest records and the remediation tickets together in one location with access control. Confirm with your QSA the format they accept, whether signed PDF or another form, and how long they expect the records to be available during assessment.

How the test changes for cloud, on-premises and hybrid cardholder environments

When the cardholder data environment (CDE) runs in facilities you own or lease, you control the hardware, the network, the change windows and the monitoring. That control makes scoping simpler, because the organization can list every segment, firewall and jump host and assign an owner to each. The tester can usually reach internal segments directly, so the internal test under requirement 11.4.2 can cover the CDE and the systems that could affect it. Your own team still needs to agree the rules of engagement in writing.

Segmentation boundaries: Confirm each segmentation control that separates the CDE from other networks, and plan segmentation testing against those exact controls.
Internal access: Decide whether testers connect from a network tap, a standard workstation segment or an assumed-breach position, and document it.
Production safety: Agree which systems may be stressed, which are fragile legacy devices, and which hours are acceptable.
Change and retest timing: Tie the test to significant changes such as a new firewall ruleset or a new payment application, as required by 11.4.2 and 11.4.3.
Evidence ownership: Assign who keeps the scope document, the findings and the retest results for at least 12 months.

Confirm with your facilities and network teams that the scope list matches the actual cabling, VLANs and firewall rules in production.

What your team should prepare before testing starts

Start by assembling the inputs the tester needs to define the cardholder data environment (CDE) boundary before any testing begins. The most useful item is a current CDE and segmentation diagram that shows every path into and out of the cardholder data environment, including payment pages, payment APIs, administrative jumpboxes, and connections to processors and service providers. Pair it with an asset inventory that lists hosts, IP ranges, domains, cloud accounts, and third-party components in scope, and flag which systems you believe are out of scope and why. Segmentation claims are the first place scope creep starts, so the diagram should match what the network actually enforces, not what the design document says it should enforce. Confirm with your internal team whether the segmentation controls were changed since the last test.

Next, prepare access and people. Provide test accounts for each role the application or platform supports, such as a customer, a merchant administrator, a support agent, and a read-only reviewer, with credentials handled through your normal secrets process. Name a technical contact who can answer architecture questions within the testing window, a remediation owner, and an escalation contact with authority to pause testing. Agree a change freeze window so that configuration changes do not invalidate findings mid-test, and document an emergency stop procedure that states who can halt activity, how the tester reaches them, and what counts as a service-impacting condition. Ask the tester to confirm in writing how they will handle production data they may encounter, since cardholder data should not be copied or retained beyond what the agreed scope requires.

Finally, collect evidence of prior remediation and the previous test report, if one exists. A clear list of past findings, the fixes applied, and the retest results gives the tester a baseline and helps you show that corrected exploitable findings were verified under the retesting expectation in requirement 11.4.4. Ask your provider to define in the scope what counts as a retest, whether it covers only the findings or the whole test, and how many retest rounds are included. Incomplete inputs usually cost more than the test itself, because they lead to mid-engagement scope changes and repeat retesting. Confirm each item against the written scope before testing starts, and keep the signed inputs with the test records you retain for at least 12 months as the standard requires.

What to check when choosing a PCI penetration testing provider

A PCI penetration test is only as useful as the method, people and paperwork behind it. The cards below cover what to verify before you sign, so the report can be used as Requirement 11.4 evidence by your assessor and your acquirer. Ask every provider for the same written answers so you can compare them directly.

Methodology mapped to 11.4.1

Ask for the provider's written penetration testing methodology and a mapping showing how each element answers Requirement 11.4.1. It should cover the full CDE perimeter and critical systems, testing from inside and outside the network, segmentation validation, application-layer and network-layer work, and a review of threats from the last 12 months. A generic checklist with no mapping makes it hard for your assessor to accept the results. Confirm the methodology is documented before testing starts, not written afterward.

Tester independence from controls

Requirement 11.4.2 and 11.4.3 call for a qualified tester with organizational independence. Ask who will do the work, what certifications or hands-on experience they hold, and whether they report to or operate any of the controls under test. Testers who also run your firewalls, segmentation or patching cannot objectively test those same controls. Ask the provider to confirm this in writing for the named team.

Written scope and rules of engagement

Scope should name the CDE systems, IP ranges, applications, segmentation boundaries and out-of-scope items, with the reason for each. Rules of engagement should set testing windows, permitted techniques, stop conditions, emergency contacts and how sensitive data encountered during testing is handled. Ask how the provider will confirm scope with you before testing begins, and what happens if a system turns out to be in scope but was not listed.

Sample report and evidence format

Request a redacted sample report before you commit. Look for an executive summary, a defined test method for each finding, severity with the basis for rating, affected components, reproducible evidence described at a defensive level, and clear remediation guidance. Confirm the report records the testing dates, the tester's qualifications and the scope tested, since these are the items an assessor will check first.

Retest terms under 11.4.4

Requirement 11.4.4 requires exploitable findings to be corrected and testing repeated to verify the fixes. Ask whether retesting is included in the fixed price, how many retest rounds are covered, how long you have to submit fixes, and whether the retest report is issued separately. Also confirm the provider will not perform the remediation itself if that would compromise their independence.

Compliance attestation boundaries

Ask the provider to confirm in writing that it does not issue PCI DSS attestations and is not a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV). DeployOpen is not a QSA or ASV, so it prepares testing and evidence for your assessor but does not validate compliance. Your QSA decides whether the test meets Requirement 11.4, and ASV scans are a separate service. Ask any provider which assessor they have worked with and how they coordinate with yours.

Common questions about PCI DSS penetration testing cost, time and effort

What drives the cost of a PCI DSS penetration test?

The cost is driven mainly by the size and complexity of the cardholder data environment (CDE) that falls within the agreed scope, not by the PCI DSS requirement itself. Requirement 11.4.1 requires a defined methodology covering the entire CDE perimeter and critical systems, so the number of in-scope IP ranges, applications, APIs, segments and payment flows shapes the effort. Other factors include whether you need both internal and external tests, how many segmentation checks are required, and whether application-layer testing is included. DeployOpen does not publish a price list. Ask any provider for a written scope listing systems, test types, tester roles and deliverables, and ask which parts are one-time and which recur at each 12-month cycle.

How long does preparation take before a PCI DSS pentest starts?

Preparation time depends on how well your CDE is documented, not on a fixed duration in the standard. Before testing, you will need an agreed scope, network diagrams, a list of in-scope systems, access arrangements, and a rules of engagement document that names test windows and emergency contacts. Teams with current data flow diagrams and a maintained asset inventory usually move faster. PCI DSS does not set a preparation duration, so confirm the expected lead time with the provider in writing and plan around your own change freezes and the timing of your 12-month cycle.

Can our internal security team run the PCI DSS penetration test?

Internal staff can perform the test only if they meet the qualification and independence conditions in requirements 11.4.2 and 11.4.3. The tester must be qualified and organizationally independent, meaning they should not be responsible for the systems under test or for the controls they are checking. The standard does not require a QSA or ASV to perform the test. Confirm with your assessor how they will evaluate independence and tester competence, document the tester's qualifications, and keep the methodology and results as evidence. Many organizations use an external provider for independence and a consistent methodology.

Does one penetration test cover both internal and external requirements?

No single test type satisfies both, because PCI DSS requirements 11.4.2 and 11.4.3 call for internal and external penetration tests, each at least once every 12 months and after significant changes. Requirement 11.4.1 expects testing from inside and outside the network. An engagement can cover both within one project and one report, but the report must clearly show the internal and external methodology, the scope of each, and the dates. Ask the provider to structure deliverables so each requirement can be traced to its evidence.

When is a retest required after significant changes?

A retest is required when exploitable findings are identified, under requirement 11.4.4, which asks for corrections and repeated testing to verify those corrections. Separately, requirements 11.4.2 and 11.4.3 require testing after significant changes to the environment, in addition to the annual cycle. The standard does not define a significant change in numeric terms, so define it in your change management policy and agree the trigger with your assessor and provider. Typical triggers include new payment flows, major infrastructure or segmentation changes, and new internet-facing applications.

Does the penetration test report alone satisfy the QSA?

The report alone does not satisfy the QSA. A penetration test report is evidence that supports your assessment, but the QSA evaluates the full set of controls against the applicable validation method, whether a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ). The QSA will look for the defined methodology, scope and segmentation validation, dated results, remediation records, and retest evidence, all retained for at least 12 months under requirement 11.4.1. Confirm with your QSA which evidence they will accept and how the report maps to each requirement. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or attestations.

How does a penetration test relate to ASV scans?

A penetration test and an Approved Scanning Vendor (ASV) scan answer different questions and do not replace each other. An ASV scan is a quarterly external vulnerability scan performed by an ASV, while a penetration test is a manual, objective-driven test of exploitability that requirement 11.4 governs separately. The ASV scan does not need to be performed by the same provider as the penetration test. Confirm the scan frequency and scope with your ASV and your QSA, and keep both sets of results as separate evidence.

What should we confirm about the PCI DSS version before buying the test?

Confirm that the test is planned against the current version of PCI DSS in force for your assessment. PCI DSS v4.0.1 was published on 11 June 2024 and replaced v4.0, which was retired on 31 December 2024. It added or deleted no requirements, and future-dated requirements took effect on 31 March 2025. Ask the provider to reference v4.0.1 requirement numbers in the methodology and report, and ask your QSA whether any transition or interpretation affects your assessment cycle.

How retesting under 11.4.4 closes findings

Requirement 11.4.4 means every exploitable finding from the penetration test must be corrected, and the testing must then be repeated to verify the correction. The retest is not a fresh full test. Its scope comes from the original report. Start by filtering the findings to those the tester classed as exploitable, then list each affected component, host, application endpoint or segmentation control by name. Add any changed system that the correction touched, because a fix to one component can alter a neighbouring control. Ask the tester to confirm in writing which findings are in retest scope, which are accepted as risk, and which are withdrawn because they were false positives. Agree that list before remediation work starts, so the retest is not renegotiated after the fixes are in.

Each finding closes on evidence that the specific weakness is no longer reproducible in the same environment. For a network or segmentation finding, that usually means the tester re-runs the original test path against the changed configuration and records the new result. For an application finding, it means the retest repeats the exploitation path against the patched build, not only a version check. Ask the tester to record, per finding, the original reference, the change made, the date of the retest, the method used and the outcome. A change ticket or configuration diff alone does not close a finding under the requirement, because the requirement asks for verification by testing. Where a finding is accepted as risk rather than fixed, the record should show who approved it and the compensating control, and the reader should check with their QSA or acquirer how that is treated in their assessment.

Retest results belong in the same evidence set that requirement 11.4.1 asks you to retain for at least 12 months: the methodology, the original report, the remediation records and the retest report. Keep them together and index them by finding, so an assessor can trace a finding from discovery to verified closure without reconstructing the sequence. Confirm with your assessor how they expect retest evidence to be presented in a Report on Compliance or a Self-Assessment Questionnaire, and whether they want the full retest report or a summary. Set a retention owner and a storage location now, since the retest may finish after the original test's report has been circulated internally.

How DeployOpen scopes, tests, reports and retests PCI penetration tests

DeployOpen approaches PCI DSS penetration testing as a fixed-scope engagement agreed in writing before work starts. We define the cardholder data environment boundary, test it from inside and outside the network, and hand over documented findings and retest evidence that your team and your assessor can review.

How we scope

Written scope defines the cardholder data environment perimeter, critical systems and in-scope network segments before testing begins.
Segmentation boundaries are agreed explicitly, so you can see which controls the segmentation test is meant to validate.
Scope records the internal and external test targets, application-layer and network-layer coverage, and the threat review period.

How we build

Testing follows a defined methodology covering internal and external tests, with both application-layer and network-layer work.
Testers are organizationally independent from the teams that operate the in-scope systems, as the requirement expects.
Exploitable findings are described by weakness category and business impact, with testing approach explained rather than step-by-step exploitation detail.

How we hand over

The report documents scope, methodology, findings, severity, affected systems and recommended corrections for each finding.
Results and remediation records are organized so you can retain them for at least 12 months, as the requirement sets.
Deliverables are scoped in writing, so you know which evidence your QSA or internal assessor will receive.

How we support

Retesting after corrections verifies that exploitable findings are fixed, and the retest report is issued alongside the original.
Ongoing support, upgrades and continuous testing are available as a retainer for environments that change between annual tests.
Ask us to confirm in your quote how retests, scope changes after significant changes and ASV scan coordination are handled.