PCI DSS penetration-testing planning starts with the cardholder data environment, connected systems, segmentation and the organisation’s validated scope—not with a generic list of payment pages. Web and API components can affect account data even when they do not store it directly.

The buyer should use the current PCI DSS requirements and applicable assessment guidance with its Qualified Security Assessor or internal assessment owner. Penetration testing supplies technical evidence; it does not by itself determine compliance or replace the full assessment.

Bring the assessor, CDE owner, application teams and network or cloud owners into scope reconciliation early. Their shared map should explain how account data and security authority move through browser, API, identity, administrative and service paths. That alignment prevents a technically detailed application test from missing segmentation or system components that matter to the entity’s assessed PCI DSS boundary.

Confirm the current PCI DSS basis

Identify the PCI DSS version, merchant or service-provider context, assessment method, reporting period and responsible assessor. Use official source documents rather than an old checklist.

Clarify which penetration-testing requirements and guidance apply to the entity. The buyer and assessor own interpretation for the assessment.

  • Applicable PCI DSS version.
  • Merchant or service-provider role.
  • SAQ, ROC or other assessment path.
  • QSA or internal assessment owner.

Start from the validated CDE scope

Document systems that store, process or transmit account data and systems connected to or able to affect their security. Include administrative and security services.

Keep data flows, inventories and network diagrams aligned. A public payment interface may rely on APIs, identity, keys and logging outside its visible page.

  • Account-data flows.
  • Web, API and mobile clients.
  • Administrative and support systems.
  • Security-impacting dependencies.

Identify segmentation controls

Where segmentation reduces scope, define boundaries, permitted paths, filtering and representative source and destination networks.

Plan segmentation testing from out-of-scope to in-scope networks and applicable internal positions, following authorised rules and current PCI guidance.

  • Network and cloud boundaries.
  • Management and shared-service paths.
  • Allowed and denied connectivity.
  • Evidence of isolation effectiveness.

Scope web application functions

Inventory payment, account, administration, support, reporting, file and configuration routes that can affect account data or CDE security.

Include authentication, recovery, session and privileged functions. Page count does not represent application authority.

  • Customer payment journeys.
  • Merchant and operator portals.
  • Administration and support.
  • Exports, files and reports.

Scope APIs by operation and identity

List methods, paths, versions, GraphQL operations, callbacks and service routes. Map customer, merchant, administrator and workload identities.

Provide owned, peer and cross-tenant objects for authorization testing. Include direct APIs behind web and mobile clients.

  • Public and internal operations.
  • Roles and tenants.
  • Tokens and service credentials.
  • Object and function authorization.

Follow complete payment workflows

Map authorization, capture, tokenization, refund, void, settlement, dispute and administrative adjustment relevant to the environment.

Test amount, beneficiary, state, replay, idempotency and callback binding safely. Follow effects to authoritative records.

  • Approved value and currency.
  • Provider and internal identifiers.
  • Retry and concurrency.
  • Refund and exception paths.

Include authentication and cryptographic boundaries

Document MFA, SSO, API authentication, key management interfaces, TLS termination and token services that influence CDE access.

Application testers should coordinate with network, cloud and cryptographic reviews without claiming to replace them. Assign ownership for every boundary.

  • Privileged authentication.
  • API token lifecycle.
  • Gateway and TLS termination.
  • Secrets and key-service access.

Plan internal and external perspectives

Define authorised internet-facing and internal test positions, networks, credentials and restrictions. Application and network work may be coordinated but need distinct coverage records.

Testing through only one edge path can miss internal trust and segmentation issues. Conversely, unrestricted internal access must not be assumed from external authority.

  • External attack surface.
  • Internal CDE-relevant position.
  • Authenticated application roles.
  • Gateway and direct service routes.

Address significant changes

Define how major application releases, new payment flows, cloud migration, segmentation changes and identity redesign trigger assessment under the organisation’s PCI process.

Record the pre- and post-change baseline. Targeted testing should match the changed risk while preserving required periodic activities.

  • New or changed payment channel.
  • CDE or segmentation change.
  • Authentication or authorization redesign.
  • New provider or integration.

Validate tester independence and competence

Confirm relevant web, API, payment and infrastructure experience and sufficient organisational independence for the requirement and evidence purpose.

Document conflicts, prior implementation, subcontractors, review and protected reporting. Coordinate expectations with the assessor.

  • Assigned technical team.
  • Relevant platform and payment depth.
  • Independence safeguards.
  • Quality review.

Set safe rules of engagement

Use written authorization, test accounts and values, rate limits, third-party approvals, production monitoring and emergency stop contacts.

Avoid unnecessary account data in evidence. Define encrypted storage, access, retention and deletion for notes, payloads and reports.

  • Approved test instruments.
  • Financial and operational ceilings.
  • Critical escalation.
  • Evidence minimization and protection.

Retain defensible evidence

Keep methodology, scope, target and version baseline, tester details, dates, coverage, limitations, findings, severity rationale and management response.

Link evidence to the relevant PCI DSS requirement and internal control without expanding the conclusion beyond what was tested.

  • SOW and rules.
  • Coverage and segregation results.
  • Final reports.
  • Finding and remediation records.

Remediate and retest findings

Assign owners, fix root causes and deploy the intended production-equivalent release. Preserve exceptions and compensating decisions through the proper process.

Retest confirmed issues and representative systemic variants. Record fixed, partial, not fixed or cannot verify and retain original history.

  1. Confirm corrected target and environment.
  2. Repeat the authorised proof safely.
  3. Check related operations or boundaries.
  4. Issue closure evidence for assessor review.

Use the current official documents in the PCI Security Standards Council document library and coordinate scope and evidence with the organisation’s QSA or assessment owner. Use the OWASP Web Security Testing Guide and OWASP API Security Top 10 for application-risk context, not as substitutes for PCI DSS.

Make technical evidence match the CDE boundary

PCI DSS testing is most useful when the CDE, segmentation, application authority and payment workflows are reconciled into one controlled evidence plan.

WIMD connects web, API and business-logic coverage to safe execution, remediation and retest while preserving the assessor’s role in compliance determination.