A compliant test should already be substantive

A PCI DSS penetration test is not intended to confirm only that controls exist. The guidance accompanying Requirement 11.4.1 describes active testing, manual analysis, and the possibility of chaining weaknesses. Replacing that work with a scanner export weakens the test; it does not represent the standard’s intended baseline.

The practical gap is often between the questions an organization needs answered and the work it actually commissions. A report may leave an important question unresolved because access was unavailable, a dependency was misunderstood, or an exclusion was never revisited. Make those limits visible before relying on the result.

Reference: PCI DSS v4.0.1 — Requirement 11.4.1 and guidance

Agree the boundary before agreeing the price

Start the scoping discussion with current data flows, system inventories, network boundaries, and the services that can affect the cardholder data environment (CDE). Ask the testing team and assessment team to resolve uncertain dependencies together. Do not use a penetration test contract to declare a system out of PCI scope.

For example, a remote administration service might be absent from an old asset list but still manage payment systems. Treat that as a scope question to resolve, not as permission to test an unapproved service. The engagement should identify authorized targets and explain how relevant dependencies will be covered.

Write down practical constraints too: maintenance windows, test accounts, third-party permissions, emergency contacts, and what happens when testing reveals a path beyond the agreed boundary. Unrecorded constraints can turn into misleading conclusions at reporting time.

Ask for evidence that answers specific questions

A useful statement of work should make the following questions answerable:

  • Which internal and external starting points will be used, and why do they cover the environment under review?
  • How will the tester investigate application behavior and network exposure beyond automated scan results?
  • If segmentation reduces scope, which boundaries and source networks will be tested, and what evidence will establish the result?
  • Which limitations will be disclosed in the report, including systems that could not be tested?
  • Who owns each corrective action, and how will the follow-up test distinguish a verified fix from a closed ticket?

Reference: NIST SP 800-115 — planning, testing, and reporting guidance

Define independence accurately

PCI DSS allows qualified internal testers or qualified external third parties, with organizational independence. The tester is not required to be a QSA or ASV. A blanket claim that the QSA company can never provide testing is too broad; assess the actual responsibilities and conflicts.

Separately, PCI SSC explains that an assessor who designed or implemented a control cannot assess that same control. Its FAQ describes documented separation of duties within a QSA company. Establish the applicable independence arrangements before the engagement rather than relying on a company label.

Reference: PCI SSC FAQ 1562 — assessor conflicts and separation of duties

Use the result for both remediation and assessment

Give engineers enough context to reproduce and correct a finding safely. Give assessment reviewers a clear record of scope, timing, methodology, limitations, and follow-up evidence. These audiences need different levels of detail, but they should be reading the same underlying facts.

The QSA remains responsible for evaluating the relevance and adequacy of evidence used in the assessment. A penetration test supports that decision; neither an impressive report nor a clean result guarantees compliance or future security.

Reference: PCI SSC FAQ 1566 — responsibility for assessment evidence