External Network
Internet-facing systems, payment services, remote access, exposed administration, perimeter controls, and exploitable external attack paths.
Payment Security
PCI DSS penetration testing built around the cardholder data environment.
TruSec tests external and internal attack paths, applications, and segmentation controls to determine whether systems affecting payment data can be reached or compromised within the authorized scope.
Service Overview
Validate the controls that protect and isolate payment systems.
PCI DSS penetration testing is not simply a scan of Internet-facing systems.
The assessment should reflect the cardholder data environment, connected systems, segmentation controls, access pathways, applications, and the ways an attacker could move from lower-trust systems toward payment data or security-impacting components.
TruSec works with the client and, when applicable, its Qualified Security Assessor to define the environment, in-scope systems, segmentation boundaries, application coverage, testing methods, and evidence required for the engagement.
Common PCI testing needs
- Annual or significant-change PCI DSS penetration testing
- External and internal network testing of the CDE
- Segmentation validation for out-of-scope networks
- Payment application or administrative interface testing
- Retesting after remediation or major environment changes
Assessment Coverage
Coverage tied to the CDE and its connected attack paths.
The final scope is based on the payment architecture, segmentation model, applicable PCI DSS requirements, and coordination with the organization’s compliance stakeholders.
Internal Network
Systems within or connected to the CDE, credential paths, insecure services, lateral movement, privilege escalation, and access to payment-related resources.
Segmentation Validation
Testing from representative out-of-scope networks to determine whether the CDE and security-impacting systems are effectively isolated.
Application Testing
Payment applications, administrative functions, authentication, authorization, input handling, session security, data exposure, and business logic.
Authentication and Access
Remote access, multifactor controls, service accounts, administrative access, password weaknesses, and opportunities for unauthorized privilege.
Retesting
Validation that failed tests and material findings have been corrected and that the original attack path is no longer effective.
How the Engagement Works
Testing coordinated with the PCI compliance process.
Confirm CDE scope
Review architecture, data flows, connected systems, segmentation, applications, access pathways, and required test perspectives.
Define test cases
Map external, internal, application, authentication, and segmentation scenarios to the approved environment.
Execute and validate
Perform manual testing and controlled exploitation to determine whether payment systems or boundaries can be compromised.
Report and retest
Document results, failed controls, evidence, corrective actions, and remediation validation required for closure.
Deliverables
Clear evidence for remediation and compliance stakeholders.
Reporting identifies the tested perspectives, affected systems, attack paths, risk, and outcome of segmentation or remediation validation.
PCI DSSExternal TestingInternal TestingSegmentationApplicationsRetesting
- Executive summary and overall test outcome
- Scope, CDE context, methodology, and test perspectives
- External and internal penetration test results
- Application and API findings when included
- Segmentation validation results and tested source networks
- Risk-rated findings with evidence and affected systems
- Practical remediation recommendations
- Retest status and closure evidence
The organization and its QSA remain responsible for confirming final PCI DSS scope and compliance interpretation. TruSec provides independent testing evidence within the approved engagement.
Common Questions
PCI DSS penetration testing questions
Does PCI penetration testing include both external and internal testing?
PCI DSS penetration testing commonly requires relevant external and internal perspectives. The exact scope depends on the cardholder data environment, connected systems, segmentation, applications, and applicable compliance interpretation.
What is segmentation testing?
Segmentation testing attempts to reach the cardholder data environment or security-impacting systems from representative networks intended to remain out of scope. The goal is to validate that isolation controls are effective.
Can TruSec coordinate with our QSA?
Yes. Coordination can help align scope, test perspectives, evidence, reporting, and retesting expectations before work begins.
Is retesting included?
Retesting can be included in the statement of work and is typically needed to verify failed tests or remediated findings before closure.
Does an ASV vulnerability scan replace PCI DSS penetration testing?
No. Approved Scanning Vendor vulnerability scans and penetration testing are separate activities. An ASV scan identifies externally visible vulnerabilities, while penetration testing uses manual analysis and controlled exploitation to evaluate whether weaknesses and attack paths can compromise systems affecting the cardholder data environment.
What information is needed to scope a PCI DSS penetration test?
Useful scoping information includes a cardholder data environment overview, network and data-flow diagrams, external and internal targets, segmentation boundaries, payment applications and APIs, remote-access methods, representative source networks, recent significant changes, QSA involvement, and the required completion date.
How are representative segmentation-testing locations selected?
Representative source networks are selected with the client and, when applicable, the QSA based on the segmentation design, network types, access paths, locations, technologies, and controls used to isolate the cardholder data environment. The goal is to test meaningful perspectives rather than selecting sources arbitrarily.
Can web applications and APIs be included in the same PCI engagement?
Yes. Payment applications, administrative interfaces, web services, and APIs can be included when they are within scope or can affect the security of payment data. Application coverage is defined separately so user roles, endpoints, authentication flows, and business functions are tested appropriately.
Can TruSec test systems that can affect the security of the CDE?
Yes. The scope can include connected-to and security-impacting systems such as identity services, administrative workstations, jump hosts, remote-access systems, security tools, virtualization platforms, and other components that could provide a path to or affect the security of the cardholder data environment.
Will the report provide evidence for our PCI compliance process?
Yes. Reporting documents the approved scope, methodology, tested perspectives, affected systems, findings, segmentation outcomes, evidence, remediation guidance, and retest status. The organization and its QSA remain responsible for final PCI DSS scope and compliance determinations.
When is penetration testing required after a significant change?
PCI DSS calls for penetration testing after significant infrastructure or application upgrades or changes that could affect the cardholder data environment or its security. Examples may include major network redesigns, new segmentation controls, significant application releases, new payment channels, or material authentication and remote-access changes. The organization and its QSA should confirm whether a specific change triggers testing.
Related Services
Build coverage around the full attack path.
Planning PCI DSS penetration or segmentation testing?
Share the CDE overview, external and internal targets, segmentation model, applications, representative source networks, QSA involvement, and target completion date.