11.4 Penetration testing: requirements and evidence

What PCI DSS 11.4 penetration testing requires and why assessors check it

Requirement 11.4 asks you to run penetration tests against your cardholder data environment (CDE) using a documented methodology, covering internal and external attack paths, the segmentation controls that isolate the CDE, and the fixes that follow from what testers find. A QSA reviewing this requirement will ask for the methodology document, the scope and dates of each test, the tester's qualifications and independence, and proof that exploitable issues were corrected and then retested. The scope definition is where most teams struggle: the methodology must cover the whole CDE perimeter and critical systems, so an out-of-date network diagram or an undocumented management path can leave a gap that the assessor finds before your testers do.

The risk behind 11.4 is simple to state. Attackers rarely break in through the front door of a payment system. They move through forgotten services, weak internal trust and flat networks once they have a foothold. Requirement 11.4 therefore expects testing from inside and outside the network, at both the application and network layers, and separate segmentation testing to confirm that out-of-scope systems cannot reach card data. The standard sets a 12-month cycle for most of these tests and requires another run after significant changes. Service providers face a shorter six-month cycle for segmentation testing, so the cadence you commit to in your methodology should match your entity type. Confirm the exact interval for your role against the current standard and your acquirer's expectations.

Tester independence and closing findings cause the most friction in practice. The tester must be qualified and organizationally independent, but it does not have to be a QSA or an ASV, so an internal team can qualify if it can show skill and separation from the systems it tests. Keep records that show who tested, what they tested and how they were separated from the work they assess. Exploitable findings must be corrected according to the risk ranking in Requirement 6.3.1 and then retested, so budget time for remediation and verification, not just the test itself. Also confirm with your acquirer or payment brand which validation requirements apply to you, because the PCI Security Standards Council does not enforce compliance or impose penalties. The payment brands decide who must validate and run any enforcement.

Which systems, teams and third parties fall under 11.4

The scope of 11.4 is set before any tester is hired. The CDE perimeter, connected systems, shared platforms and third parties each change what must be tested, from whom, and how often. Confirm these decisions in writing with your assessor before the test plan is agreed.

The CDE perimeter and critical systems

The methodology must cover the whole cardholder data environment perimeter and the critical systems within it. Start from your current data-flow and network diagrams, then list every system that stores, processes or transmits account data, plus the authentication, logging and administrative systems that protect them. Check that the list matches what the diagrams show, since a gap here becomes a gap in every test that follows.

Connected systems that could affect CDE security

Requirement 11.4 reaches beyond systems that hold card data. Directory services, jump hosts, build pipelines, monitoring servers and management networks can all provide a path into the CDE. Document each connection that could affect CDE security, decide whether it is in the test scope, and record the reason. Auditors commonly ask how these connected systems were chosen, so keep the rationale with the methodology.

Segmentation controls and their test frequency

Segmentation testing under 11.4.5 must run at least every 12 months and after changes to segmentation controls. Service providers have a shorter cycle under 11.4.6, which is every six months. Confirm with your assessor whether your organization is classed as a service provider for this purpose, because that answer sets the calendar. Record the segmentation test results with the date of each change that triggered a retest.

Multi-tenant and shared cloud platforms

If your platform hosts several customers on shared infrastructure, 11.4.7 requires you to support each customer's external penetration testing. Agree the rules of engagement, testing windows and provider limits in writing, and make sure the tests cannot affect other tenants. Ask your cloud provider which penetration testing actions it permits without prior approval, because those permissions set what your testers can attempt.

Third-party providers with CDE access

Outsourced hosting, managed security services, payment gateways and support vendors may be inside your CDE scope or connected to it. Identify which providers hold access, which of their systems touch the CDE, and whose penetration tests cover those systems. Where a provider tests its own environment, obtain the report and confirm it covers the systems and methods your scope requires. Responsibilities should be written into the contract.

Internal and external testing boundaries

Requirement 11.4 asks for internal and external tests, so the boundary must be drawn for both. External tests examine what an attacker outside the network can reach, including public addresses and cloud endpoints. Internal tests start from inside the network with the access an attacker might gain. Confirm that your inventory of public IP addresses, domains and internal segments is current before testing begins, since untracked assets are a common reason tests miss systems.

How a QSA tests penetration testing under 11.4

A QSA testing 11.4 starts by reading paperwork before looking at any test result. The assessor expects a documented penetration testing methodology that covers the whole CDE perimeter and critical systems, describes testing from inside and outside the network, and addresses segmentation and both application and network layer tests. The assessor checks that the methodology is current, that the people who run tests follow it, and that results are retained for at least 12 months. Next, the assessor compares the defined scope with the current network and data-flow diagrams and asks whether any system added since the last test sits outside the scope. A gap between the diagrams and the test scope is one of the most common reasons an assessment stalls, so confirm the match before the assessor arrives. For tester qualifications, the assessor asks who performed each test and how that person is independent of the team that builds or runs the system under test. The standard requires organizational independence and qualified testers, but it does not require a QSA or ASV to perform the work. Ask for résumés, certifications or training records, and a written statement of independence for each internal tester. For frequency, the assessor compares the dates of internal and external tests against the 12-month cycle and checks whether a test followed each significant upgrade or change to the CDE. Segmentation testing gets the same date review, and a service provider needs evidence of tests every six months, not every 12. Missing dates are usually the fastest way to a finding, so build a calendar that ties each test to the change records that triggered it.

The assessor then separates two questions that teams often merge. Reviewing results confirms that the test happened, covered the agreed scope, and reported what it found, including whether segmentation controls held. Checking under 11.4.4 goes further: the assessor selects exploitable vulnerabilities from the report, traces each to a remediation record, confirms the fix matched the risk ranking under 6.3.1, and finds a retest that proves the vulnerability no longer works. A clean report with no matching retest evidence will not satisfy this check. For each finding in the sample, prepare the ticket, the change record, the retest output and the date the fix went live. If a finding was accepted as a risk rather than fixed, expect the assessor to ask for the documented justification and to confirm that the retest still happened, since the requirement asks for corrections and verification, not for a clean report.

What an assessor requests and where tests commonly fail

This table compares each part of Requirement 11.4, from the 11.4.1 methodology to the 11.4.7 customer testing duty, against what the assessor tests, the evidence usually requested and the gaps that most often surface. Read it as a pre-assessment checklist: if a row describes a gap you cannot close with a document, fix the process before the assessor arrives.

Requirement	Assessor test approach	Evidence requested	Common findings
11.4.1 Methodology	Confirms a documented penetration testing methodology exists and covers the whole CDE perimeter, critical systems, internal and external testing, segmentation, and application and network layers.	Methodology document, scope statement, retained results from at least the last 12 months.	Methodology is generic and does not name the CDE perimeter or critical systems, or results older than 12 months are missing.
11.4.2 Internal tests	Samples the internal test reports and checks the 12-month cadence and the tests run after significant changes.	Internal test reports with dates, scope, tester identity and the change records that triggered extra tests.	No internal test after a significant infrastructure or application upgrade, or the report does not state what was tested.
11.4.3 External tests	Checks external tests cover internet-facing CDE components and that they occur at least every 12 months and after significant changes.	External test reports, asset list of public endpoints, change tickets linked to each test.	Public IP ranges or new cloud endpoints were added after the last test and never tested.
11.4.2 and 11.4.3 Tester independence	Confirms the tester is qualified and organizationally independent from the teams that run the systems under test. A QSA or ASV is not required.	Tester qualifications, job roles or a statement of independence, and the reporting line of internal testers.	The system administrator who manages the firewall also performs the test and signs the report, with no independence evidence.
11.4.4 Remediation and retest	Traces exploitable findings to their remediation and checks the retest that verifies each fix against the risk ranking in 6.3.1.	Findings register, risk ranking used, remediation tickets, retest results showing closure.	Findings are closed by the owner without a retest, or the retest does not reference the original finding IDs.
11.4.5 Segmentation tests	Checks that segmentation controls were tested at least every 12 months and after any change to those controls, and that the tests prove isolation.	Segmentation test scope, network diagrams, test results showing blocked paths, and the change records for segmentation rules.	Firewall rule changes were made after the last test, or the segmentation test only checks one side of the boundary.
11.4.6 Segmentation tests for service providers	Confirms the 6-month cadence applies to service providers and that the schedule is followed in practice.	Test calendar, six-month segmentation reports, and evidence that the scope matches the current CDE.	The service provider runs segmentation tests annually because its team treats the 12-month cycle as the rule.
11.4.7 Multi-tenant support	For multi-tenant service providers, checks that customers can run external penetration tests and that the provider supports this process.	Customer testing procedure, rules of engagement, and records of supported customer tests.	The provider has no written process for customer-led tests and responds to requests ad hoc, or the procedure excludes external testing.

How to implement 11.4 from methodology to closed findings

This sequence takes penetration testing from a written methodology to tested, corrected and retained evidence that an assessor can follow from scope to closure. Each step produces an artifact that the next step depends on, so gaps surface early rather than at assessment time.

Write the penetration testing methodology
Your security or compliance lead documents a penetration testing methodology that covers the whole cardholder data environment perimeter and critical systems, testing from inside and outside the network, segmentation testing, and both application and network layer tests. The methodology names the test types, the entry points and the reporting format. It is done when it is approved by the owner of the CDE and version-controlled, so an assessor can compare the executed tests against the written method.
Define test scope from diagrams
Using current data-flow and network diagrams, the team lists every system, network segment, external address range, application and access path that is in the CDE or could affect it. Scope is reviewed against the asset inventory so that undocumented hosts are caught before testing starts. The output is a signed scope document with explicit inclusions and exclusions and a rationale for each exclusion, which the tester will receive as its boundary.
Select qualified internal or external testers
The organization chooses an internal team or an external firm, or a mix of both, and confirms that testers are qualified and organizationally independent from the systems they test. The standard does not require a QSA or ASV for penetration testing, so confirm skills and independence in writing. Ask for named testers, their methods and evidence of prior work, and record the selection rationale. The output is an approved tester register kept with the assessment evidence.
Run internal and external penetration tests
Testers run internal tests from inside the network and external tests from outside it, covering both application and network layers within the defined scope. Test rules of engagement, testing windows and escalation contacts are agreed before work starts. Findings are logged with evidence such as request and response captures, affected hosts and proof of exploitation. The step is complete when the tester delivers a report that maps each finding to the scope and the methodology.
Test segmentation controls
Testers attempt to reach the CDE from out-of-scope networks to confirm that segmentation controls work as the diagrams claim. The test covers each segmentation boundary defined in scope, and the results show which paths were blocked, which were reachable and why. Segmentation testing is also repeated after changes to segmentation controls. Service providers have a shorter testing cycle, so confirm the cadence that applies to your organization. The output is a segmentation report that ties each boundary to a pass or fail result.
Rank and correct exploitable findings
The security team ranks each exploitable vulnerability using the risk ranking in Requirement 6.3.1 and assigns an owner and a remediation target. Fixes are tracked in a ticketing or findings system, and any compensating action is documented with its approval. Open items are reviewed at a set governance forum. The step closes when every exploitable finding has either a verified correction or an approved, documented risk decision.
Retest fixes and retain results
Testers repeat the relevant tests to confirm that each correction works and that the vulnerability cannot be exploited through the same path. Retest evidence is attached to the original finding, and the finding is closed only after the retest passes. All methodology versions, scope documents, reports, retest results and approvals are retained for at least 12 months. The output is a closed findings register and an evidence folder that an assessor can sample without help from the team that produced it.

Evidence that satisfies 11.4 and how to keep it current

An assessor testing 11.4 looks for a connected set of records: the method, the scope, who tested, what was found, how it was fixed and whether the fix held. Each card below covers one artifact in that chain and the check that keeps it current between assessments.

Documented penetration testing methodology

This is the written method the testing team follows, and 11.4.1 requires it to cover the whole CDE perimeter and critical systems, testing from inside and outside the network, segmentation testing, and both application and network layer tests. Check that it names the tests performed, the tools and techniques used, how exploitability is judged and how results are retained. Review it at least annually and whenever the environment changes materially, so the document still describes what the team actually does.

Scope and segmentation diagrams

Penetration test reports are only as credible as the scope they describe. Keep current network and data-flow diagrams that show the CDE boundary, every segmentation control and the systems on each side of it. Each test report should list the in-scope IP ranges, applications and segmentation controls tested, so an assessor can match the test to the boundary. Any change to a segmentation control is a trigger for a segmentation test, so diagram updates and change tickets should be linked.

Tester qualification and independence records

11.4.2 and 11.4.3 require testers with appropriate skills and organizational independence, but do not require a QSA or ASV. Keep a record for each tester or firm showing relevant experience, certifications where held, and the reporting line that separates the tester from the team that runs the systems. Ask the independent assessor which qualification evidence it expects, because acceptance criteria are applied during the assessment, not by the standard itself.

Test reports and exploitable findings log

Each internal and external test should produce a report that records the method used, the systems tested, the findings with evidence of exploitation and the risk ranking. Store reports with a consistent naming scheme and link them to the scope version they tested. Findings can be tracked in a vulnerability management platform such as DefectDojo, which imports reports from many tools and deduplicates findings, so the history of each issue stays in one place.

Remediation tickets and retest results

11.4.4 requires exploitable vulnerabilities to be corrected according to the risk ranking in 6.3.1, and the test repeated to confirm the correction. Keep one ticket per finding that records the risk rating, owner, fix date, change reference and the retest outcome with its date. Tickets closed without a retest record are a common gap, so set the closure rule so that a finding cannot be closed until the retest evidence is attached.

Twelve-month evidence set and review calendar

Assemble the artifacts above into one dated evidence set for each test cycle, and keep it for at least 12 months. Maintain a calendar that schedules the internal and external tests, segmentation tests, and the tests triggered by significant changes, so a missed cycle is visible before the assessment. Ask your assessor which period it will sample and whether any test performed outside the normal cycle needs a separate explanation.

How self-hosted open source supports 11.4 evidence

Requirement 11.4 asks for penetration tests, but a tester needs an accurate picture of what runs on the systems in scope. Endpoint-level detection tools help the security team maintain that picture between tests and show how known vulnerabilities were tracked over time. Wazuh (GPL-2.0-only) and Fleet (MIT) both collect software inventories from managed hosts and match them against vulnerability sources.

Wazuh vulnerability detection: each agent's software inventory is correlated with the Wazuh CTI vulnerability repository, or a locally hosted offline copy, which suits air-gapped environments.
Fleet host software matching: installed software on enrolled hosts is matched against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.
Scope evidence: inventory exports show which systems and applications existed in the CDE at a given date, supporting the tester's scope and the methodology's coverage of the perimeter.
Retest support: a before-and-after inventory helps verify that exploitable vulnerabilities were corrected before retesting under 11.4.4.
Limits: these tools detect known vulnerabilities from software metadata. They do not chain weaknesses, test application logic or confirm exploitability, so they do not replace a qualified penetration test.

Confirm with your team which vulnerability sources are updated in your offline environment and how often inventory data is retained for your 12-month evidence window.

What meeting 11.4 costs in money and effort

Meeting 11.4 costs money in several separate places, and most of them recur. The largest visible line is usually the external penetration test, which an outside firm performs and invoices against a written scope. Behind it sit costs that are easy to miss in a first budget: internal tester time, engineering effort to fix exploitable findings under the risk ranking in 6.3.1, retest effort to prove those fixes work, and the segmentation test that must follow any change to segmentation controls. Your team also pays for the assessor's time when the assessor samples test reports, scope documents and remediation tickets during the annual assessment. Ask each provider to price these items as separate lines so you can see which ones move when your environment changes.

Separate one-time setup from recurring annual testing. Setup includes writing the documented methodology that 11.4.1 expects, defining the CDE perimeter and critical systems it covers, agreeing how internal and external testers are selected and kept organizationally independent, and building a process that records results and retains them for at least 12 months. These tasks take effort once and should be re-checked only when the method changes. Recurring costs come from the 12-month internal and external tests, retests after significant upgrades, and segmentation tests. Service providers face a shorter segmentation cycle under 11.4.6, so their recurring cost is higher and should be priced separately. Costs rise with the number of in-scope IP addresses, applications, network segments, third-party components and the frequency of significant changes. A stable, well-documented environment with fewer segments costs less to test each year.

No price is given here because a quote depends on your written scope, environment and assessor expectations, and DeployOpen does not publish a price list. When you request quotes, ask for: the methodology and the tester's qualifications and independence statement; the defined scope by network range, application and segment; the number of test cycles per year and the trigger criteria for retests and segmentation tests; the remediation support included or excluded; the retest method and its cost; the report format and how long results are retained; and whether assessor sampling support is included. Confirm with your acquiring bank or the relevant payment brand which timelines and report formats they accept, since the PCI SSC does not enforce compliance and the brands set those expectations. Compare quotes on the same scope, not on headline day rates.

Who does what: your team, a partner and the assessor

Your organization owns the penetration testing program and every control it supports. Requirement 11.4 is your obligation, so the methodology, the testing schedule, the decision to fix or accept a finding, and the retention of results all sit with your security leadership. Your team also decides what is in scope, because only the organization knows where cardholder data flows and which systems are critical.

Methodology and scope: Own the documented penetration testing methodology and confirm it covers the whole CDE perimeter, critical systems and segmentation controls.
Scheduling and triggers: Track the 12-month cycle and every significant upgrade or change that should trigger a new test.
Remediation decisions: Assign owners for exploitable findings and set target dates based on the risk ranking in 6.3.1.
Retesting and closure: Confirm that corrections were verified by retesting and that the results are retained for at least 12 months.
Vendor oversight: Review the tester's statement of work, rules of engagement and findings before accepting them into your evidence file.

Before your next test, check that a named internal owner can explain the methodology and the scope boundary without notes.

Where organizations fall short on 11.4 and how to close each gap

Most penetration testing findings in assessments trace back to a few recurring gaps: the test scope is unclear, segmentation drifts after changes, and the evidence trail is incomplete. Each card names one gap and the action that closes it before the assessor arrives.

Unclear test scope

Requirement 11.4.1 expects a documented methodology that covers the whole cardholder data environment perimeter and critical systems. Many organizations test the public web application but miss internal hosts, cloud management consoles or payment connections to third parties. Before each test, confirm the scope against the current network and data-flow diagrams, and record which systems are in and out of scope with the reason for each.

Segmentation not tested after changes

Requirement 11.4.5 requires segmentation controls to be tested at least every 12 months and after changes to them, and 11.4.6 shortens that interval to every six months for service providers. Firewall rule edits, new VLANs or cloud security group changes often alter isolation without anyone triggering a test. Tie segmentation testing to the change management process so that any change to a segmentation control creates a test ticket.

Tester independence not documented

Requirement 11.4.3 requires the tester to be qualified and organizationally independent. The tester does not need to be a QSA or ASV, but the assessor will still ask who performed the test and whether they reported to the people who run the systems. Keep a short record of the tester's qualifications and reporting line, and confirm that an internal team does not test its own configuration without that separation documented.

Exploitable findings not corrected

Requirement 11.4.4 requires exploitable vulnerabilities found in penetration tests to be corrected according to the risk ranking in 6.3.1, followed by a repeat test that verifies the fix. Teams often close tickets on the developer's word without a retest. Track each finding from discovery to a verified fix, and attach the retest result to the ticket. Open-source platforms such as DefectDojo can hold this lifecycle in one place.

Results not retained for 12 months

Requirement 11.4.1 expects penetration test results to be kept for at least 12 months, so an assessor can see the test history across the assessment period. Reports stored only in a consultant's email or a shared drive are hard to produce on request. Set a retention location with access controls, store the methodology, scope, report and retest evidence together, and confirm the retention period with your assessor before the test cycle begins.

Methodology not documented

Requirement 11.4.1 asks for a documented penetration testing methodology that covers testing from inside and outside the network, application and network layer tests, and segmentation tests. When the methodology exists only as habit, testers and assessors read it differently. Write it down as a controlled document, name the owner, review it on a fixed schedule, and check that each test report references the methodology version it followed.

Questions buyers ask about 11.4 cost, time and staffing

How much does a PCI DSS 11.4 penetration test cost?

No supplied source gives a price for a requirement 11.4 test, so treat any figure you see online with caution. Cost depends on the size and number of in-scope systems, the number of applications and network segments, how many external IP addresses and internal subnets are tested, and whether the work is internal, external or both. Segmentation testing, retesting after fixes and the evidence needed for your assessor add effort. Ask each provider for a written scope that lists targets, test types, the methodology used, retest rounds and deliverables, then compare quotes on that basis. Most of the cost is a recurring annual activity, since the requirement repeats every 12 months and after significant changes.

How long does it take to plan a penetration test?

Planning usually takes longer than the testing itself, and no supplied source gives a duration, so confirm timing with your provider. Planning covers agreeing the rules of engagement, test windows, named contacts, data handling limits, and the systems that must not be disrupted. Your team also has to confirm the cardholder data environment boundary and the network and data-flow diagrams, because the methodology under requirement 11.4.1 must cover the whole CDE perimeter and critical systems. Start planning early enough to fit the 12-month cycle and any significant change that triggers a test, and schedule retesting of corrected findings before the assessment window opens.

Can our internal staff perform the PCI DSS penetration test?

Yes, the requirements allow internal testers, provided they are qualified and organizationally independent. Requirements 11.4.2 and 11.4.3 require the tester to be independent of the team that runs the systems and does not require a QSA or ASV. Ask whether your staff can show current, relevant testing skills, a documented methodology, and independence from the people who build and operate the tested systems. Your assessor will decide whether the evidence is sufficient. Many organizations combine internal testers for recurring work with an outside firm for periodic independent testing, but the split is your decision and should be written into your testing procedures.

How often must segmentation testing run for service providers?

Service providers must test segmentation controls every six months, while other entities test every 12 months. Requirement 11.4.5 sets the 12-month interval for segmentation tests and requirement 11.4.6 shortens it to every six months for service providers. Both also require a retest after changes to segmentation controls. Segmentation testing should confirm that systems outside the CDE cannot reach it, and your evidence should show the test scope, method, results and any corrections. Service providers should also check whether any multi-tenant platform obligations under requirement 11.4.7 apply to their customers' external tests.

What does our team need to provide for a penetration test?

Your team supplies the information and access that make the test accurate and safe. Typical inputs include an up-to-date asset inventory, network and data-flow diagrams, the CDE boundary, IP ranges and application URLs, test accounts for authenticated application tests, and a named contact for emergencies. You also need to agree test windows with operations, arrange change approval, and decide who receives findings. After the report, your team owns remediation of exploitable vulnerabilities according to the risk ranking in requirement 6.3.1, then arranges retesting. Ask your provider to list these inputs in the written scope so gaps are found before testing starts.

Who owns the penetration test results and the evidence?

Your organization owns the results and the evidence, and it is responsible for keeping them. Requirement 11.4.1 requires retention of penetration testing results for at least 12 months, so store the methodology, scope, raw findings where appropriate, remediation records and retest reports in a location your assessor can access. An implementation partner can help structure this evidence, but only your qualified security assessor reviews it for the assessment. Ask providers how they deliver reports, how sensitive data is handled, and how findings are tracked to closure.

Do we need a QSA or an ASV to run the penetration test?

No, the requirement for penetration testers does not require a QSA or an ASV. Requirement 11.4.2 and 11.4.3 require a qualified tester with organizational independence, and an internal or external firm can meet that test. ASVs apply to the quarterly external vulnerability scans under requirement 11.3, not to penetration testing. A QSA performs the assessment and issues the Report on Compliance, so QSA involvement is about validation, not about who may perform the test. Confirm early with your assessor which evidence they expect to see for the tester's qualifications.

Can open-source tools reduce the effort of penetration testing?

Open-source tools can support the work, but they do not replace a qualified tester's methodology. Tools such as DefectDojo can import findings from many scanner formats and deduplicate them, which helps track exploitable vulnerabilities through to retesting. Vulnerability detection tools like Wazuh and Greenbone cover related inventory and scanning work, though their output is not a penetration test on its own. Describe in your methodology which tools support which steps and who reviews the results. DeployOpen can plan, implement and integrate such tooling inside your own infrastructure, but the testing and its validation remain with your testers and your assessor.

How DeployOpen prepares 11.4 penetration testing evidence

DeployOpen plans, implements and documents the self-hosted open-source platforms that support penetration testing inside your own infrastructure. We prepare the systems, scope documentation and evidence an independent tester and your assessor will review, while your organization owns the testing decisions and the control.

How we scope

Written scope agreed before work starts, naming the CDE perimeter, critical systems and in-scope segmentation controls.
Documented methodology drafted to cover internal and external testing, application and network layer tests, and segmentation tests.
Clear boundaries stating which tests your independent tester performs and which parts DeployOpen prepares for them.

How we build

Self-hosted platforms deployed in your cloud accounts, data centers or air-gapped networks, so test data stays under your control.
Vulnerability tracking connected to findings from tests, including deduplication and retesting records for corrected exploitable issues.
Logging and access controls configured so test activity and results can be retained for at least 12 months.

How we hand over

Documentation covering the methodology, scope, test schedule and the process for repeating tests after significant changes.
Evidence packages organized by requirement sub-item so your tester and QSA can trace each claim to its source.
Runbooks for retesting corrected findings and for running segmentation tests every 12 months or six months where applicable.

How we support

Fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing available as a retainer for tracking changes that trigger new tests.
Quotes follow from the written scope. Confirm with us which parts of 11.4 testing fall inside the agreed engagement.