Most organizations preparing for PCI DSS validation treat penetration testing as a finish line. They schedule the test, receive the report, file it away, and consider the requirement satisfied. That assumption causes more validation delays than almost any other misunderstanding in the PCI DSS testing requirements.

Penetration testing is only one component of PCI DSS validation, and it must be performed, documented, and maintained according to PCI DSS requirements. A report showing no critical findings does not, by itself, demonstrate a compliant penetration testing program. This PCI penetration testing guide walks you through how PCI DSS defines penetration testing expectations, and where compliance teams most often misread those expectations.

PCI Penetration Testing Guide: What Requirement 11.4 Necessitates

Penetration testing is addressed in Requirement 11.4, which is one of twelve requirements that make up PCI DSS. Penetration testing is a control that supports validation. It is not a validation activity on its own, and it does not stand apart from the other eleven requirements an organization must meet. Requirement 11.4 breaks into seven sub-requirements. The table below summarizes what each one covers and how often it applies.

A few of these sub-requirements carry qualifiers:

Methodology. PCI DSS requires an industry-accepted penetration testing approach, not a specific one. NIST SP 800-115 is commonly cited as an example, but it is not the only acceptable methodology. What PCI DSS does require is that the approach be documented, cover the entire cardholder data environment perimeter and critical systems, include both internal and external testing, address application-layer and network-layer vulnerabilities, and account for threats identified in the prior 12 months.

Internal and external testing. PCI DSS defines these as distinct activities, and both are required. Internal penetration testing means testing from both inside the cardholder data environment and into it from trusted and untrusted internal networks. External penetration testing means testing the exposed external perimeter and any critical systems accessible from public network infrastructure. Neither satisfies the other. Testers must be qualified and organizationally independent, though PCI DSS does not require them to be a QSA.

Segmentation testing. This is where the most common cadence confusion occurs. Any entity using segmentation to reduce PCI DSS scope must test that segmentation at least once every 12 months under 11.4.5. Service providers carry an additional requirement under 11.4.6 to test segmentation at least once every 6 months. The 6-month cadence is not a general PCI DSS requirement. It applies specifically to service providers, on top of the 12-month requirement that applies to everyone using segmentation.

How Penetration Testing Becomes Validation Evidence

A penetration test report does not validate compliance. It becomes evidence within a Report on Compliance or a Self-Assessment Questionnaire, which is where validation actually occurs.

Not every organization is required to conduct penetration testing under PCI DSS. It applies to all entities validating through a Report on Compliance (ROC), and to organizations using certain Self Assessment Questionnaire (SAQ) types, including SAQ A-EP, SAQ D-Merchant, and SAQ D-Service Provider. Other SAQ types carry different requirements. Organizations should confirm their specific obligation with their QSA or acquirer rather than assume penetration testing applies uniformly across all validation paths.

When a QSA reviews penetration testing as part of a ROC, the review goes well beyond checking whether a report exists. The QSA examines whether the methodology is documented, whether the scope maps to the actual cardholder data environment, whether findings were addressed and retested, and whether the testing distinguishes exploitable vulnerabilities from broader security weaknesses. A vulnerability scan submitted in place of a penetration test does not meet this bar, regardless of how thorough the scan was, because scanning and penetration testing are governed by different requirements with different methods and different intent.

Common Misconceptions

1. Vulnerability scanning and penetration testing are treated as interchangeable. 
   They are separate PCI DSS controls. Vulnerability scanning falls under Requirement 11.3 and is largely automated. Penetration testing falls under Requirement 11.4 and involves human-led exploitation attempts against defined targets. A passing scan does not satisfy 11.4.

2. One test is treated as sufficient for the full validation cycle. 
   Testing is also required after significant infrastructure or application changes, and any findings must be corrected and retested under 11.4.4. A single test performed at the start of the year does not cover changes made in month six.

3. Any report is treated as sufficient. 
   As covered above, a QSA's review looks at methodology, scope, and documentation, not just a list of findings. Reports that lack a documented methodology, or that don't demonstrate coverage of the full cardholder data environment, will not satisfy Requirement 11.4 even if the underlying testing was competent.

4. Passing a penetration test is treated as equivalent to being compliant. 
   Penetration testing is one control among many across all twelve PCI DSS requirements. An organization can pass its penetration test and still fail validation on access control, encryption, or logging.

5. Segmentation is treated as something to assert rather than prove. 
   A failed segmentation test does not just generate a finding. It expands the scope of the cardholder data environment to include the systems that were assumed to be isolated, which can significantly increase the scope of the entire assessment.

Why a Passing Test Isn't the Same as a Sound Program

Requirement 11.4 doesn't only require correcting exploitable vulnerabilities. It requires correcting exploitable vulnerabilities and security weaknesses, and under 11.4.4, that correction must follow the risk assessment approach defined in Requirement 6.3.1.

This matters because a finding doesn't have to be immediately exploitable to require attention. A security weakness that isn't yet exploitable in the current environment can still represent a gap the organization is expected to identify, assess, and remediate. A report that shows zero exploitable findings can still reflect an incomplete program if it stops there and never accounts for weaknesses that don't rise to the level of an active exploit.

This is the distinction between passing a test and running a program that PCI DSS actually expects. A test is a point-in-time activity with a defined scope and a pass or fail outcome. A program is the ongoing methodology, risk assessment process, remediation tracking, and retesting discipline that PCI DSS requires around that test. An organization can produce a clean report and still be unable to demonstrate the program behind it when a QSA asks to see the methodology, the risk assessment, and the remediation history.

Achieving PCI DSS Validation with Securisea

Securisea's QSA team helps organizations align penetration testing activity with the validation requirements outlined in this PCI penetration testing guide that it is meant to support, so the testing that gets done actually holds up during assessment. Because QSA independence rules require separation between assessment and advisory work, Securisea maintains that separation internally, which allows the firm to speak to both testing requirements and validation outcomes without a conflict of interest.

Learn more about Securisea's PCI DSS services or contact us to start the conversation.

Most organizations don't choose one cloud security compliance standard. They end up managing several at once, driven by customer contracts, industry regulation, or the scope of data they handle. SOC 2, ISO/IEC 27001:2022, PCI DSS, and GovRAMP each address a different question about an organization's security posture, and each carries its own authority, processes, and outcomes. This piece doesn't walk through what each standard means in isolation. It compares how they function, where their underlying controls overlap, and how organizations decide which to pursue, in what order, and how to manage them together rather than as separate, disconnected obligations.

How Comparing These Standards Actually Works

Before comparing cloud security compliance standards side by side, it helps to be clear about what "comparable" means here. SOC 2, ISO 27001, PCI DSS, and GovRAMP aren't four tiers of the same process; they are four different types of instruments, each governed differently and each producing a different kind of outcome. Comparing them well means comparing their category, their underlying controls, and how they fit an organization's business needs, not ranking them against one another as if they were interchangeable. The table below outlines how each is governed, what it covers, and how it's validated.

Cloud Security Compliance Standards Compared

How Cloud Security Compliance Standards Compare on Underlying Controls

Cloud security compliance standards look separate on paper. Underneath, many of them draw on the same core security practices, which is why organizations rarely start from zero when adding a second or third cloud compliance framework.

SOC 2 and ISO 27001 share substantial control overlap. AICPA's own mapping spreadsheet puts the overlap at approximately 80 percent, though estimates across industry sources range from roughly 60 to 96 percent depending on scope. Shared ground includes:

• Access control and user authentication
• Risk assessment and monitoring
• Incident detection and response
• Information security policy requirements

GovRAMP and FedRAMP share a common technical foundation. Both are built on NIST SP 800-53 Rev. 5 control baselines, so an organization progressing through GovRAMP verification is working from largely the same control catalog it would need for FedRAMP authorization, adjusted for impact level and government customer type.

PCI DSS overlaps at the control level, not the framework level. Requirements like access control, logging, and vulnerability management echo similar controls in SOC 2 and ISO 27001. But PCI DSS applies only to the cardholder data environment, so this overlap reduces duplicate work within that scope; it doesn't extend PCI DSS coverage to the rest of the organization.

What this overlap does, and doesn't, mean:

• It means a control built once, like a logical access policy, can often produce evidence usable across two or three frameworks.
• It does not mean the frameworks become interchangeable, or that satisfying one reduces the scope, authority, or outcome of another.
• Each framework still requires its own independent assessment, certification, or attestation, performed on its own cycle, by the entity qualified to perform it.

Overlap reduces duplicate work. It doesn't reduce the number of assessments an organization needs to complete.

Business and Operational Factors That Drive Framework Selection

Framework selection rarely starts with the standard itself. It starts with who's asking for it, and why.

Customer and Contractual Pressure 

Enterprise buyers in North America frequently require a SOC 2 report before signing. International buyers, particularly in Europe, more often expect ISO 27001 certification. Any organization handling cardholder data is contractually bound to PCI DSS regardless of what its customers request. State, local, and education government customers increasingly require GovRAMP status as a condition of procurement.

Risk Profile and Data Sensitivity

The kind of data an organization handles, and what happens if it's exposed, shapes which frameworks are relevant in the first place. A payments platform has no choice about PCI DSS. A SaaS company holding sensitive customer data across regions may need both SOC 2 and ISO 27001 to satisfy different parts of its customer base.

Market and Vertical 

Where an organization sells determines a lot. A vendor selling into federal or SLED government markets is working toward FedRAMP or GovRAMP regardless of its private-sector customers' preferences. A vendor focused solely on US commercial buyers may never need ISO 27001.

Long-term Compliance Trajectory 

Framework decisions made for a single customer or deal tend to compound as the organization grows. Choosing a framework based only on the immediate ask, without considering where the customer base or regulatory environment is heading, often means revisiting the decision sooner than expected.

None of these factors point to a single "correct" framework. They point to a combination that is layered based on who an organization serves today and who it intends to serve next.

The Challenge of Managing Multiple Frameworks Simultaneously

Adopting a second or third framework rarely means starting over. It does mean managing new friction points that a single-framework program doesn't have.

Duplicate Evidence Requests

Auditors and assessors for different frameworks often ask for similar evidence, like access logs or vulnerability scan results, but in different formats, on different schedules, and referencing different control numbers. Without coordination, teams end up producing the same underlying proof multiple times.

Overlapping but Misaligned Audit Calendars

A SOC 2 Type II period, an ISO 27001 surveillance audit, and a PCI DSS annual validation rarely line up. Preparing for one while mid-cycle on another is common, and can strain the same internal owners across simultaneous deadlines.

Inconsistent Terminology for the Same Control

What SOC 2 calls a "control activity," ISO 27001 may address under a specific Annex A control, and PCI DSS may fold into a numbered requirement. Teams managing multiple frameworks need to track these as the same underlying practice, not three separate obligations, or they risk solving the same problem three different ways.

Unclear Ownership As Programs Scale

As frameworks are added, it's easy to lose track of who owns which control across which program, especially when responsibility sits across security, IT, and compliance teams that weren't built to coordinate from the start.

None of this means multiple frameworks are unmanageable. It means the operational challenge shifts from meeting the requirements of a single framework to coordinating evidence, calendars, and ownership across all of them at once.

How Organizations Approach Multi-Framework Compliance

Organizations that manage multiple cloud security compliance standards effectively tend to work from a shared foundation rather than treating each framework as a separate project.

Building a Control Set Once, Mapping It Many Times

Rather than designing separate controls for SOC 2, ISO 27001, PCI DSS, and GovRAMP, mature programs build a single underlying set of security practices and map it to each framework's specific requirements. The control is built once; the mapping determines which frameworks it satisfies and where gaps remain.

Sequencing Based on Demand, Not Preference

Organizations typically pursue frameworks in an order shaped by who's asking. A vendor with North American enterprise customers moving into government contracts might pursue SOC 2 first, then layer in GovRAMP as SLED opportunities materialize. One driven primarily by international expansion may prioritize ISO 27001 earlier than a US-only peer would.

Separating Readiness Work From the Formal Assessment

Preparing for a framework, closing control gaps, organizing documentation, and building evidence are distinct activities from the independent assessment, certification, or attestation that follows. Each of these programs requires that separation as a structural safeguard: the CPA firm issuing a SOC 2 report, the certification body issuing an ISO 27001 certificate, the QSA validating PCI DSS, and the 3PAO assessing FedRAMP or GovRAMP status must each maintain independence from any advisory work performed on the same engagement.

For organizations managing several frameworks at once, this means the same partner can reasonably support readiness across all of them, while the assessments, certifications, and attestations themselves are carried out independently, by the appropriately qualified and separated function, for each standard.

Coordinating Compliance with Securisea

These standards aren't interchangeable, but they aren't isolated either. Where SOC 2, ISO 27001, PCI DSS, and GovRAMP align, access management, monitoring, and incident response help organizations reduce duplicate work as they take on more than one at a time. Coordinating across frameworks, rather than managing each in isolation, helps keep pace with customer requirements and long-term compliance goals without starting from scratch at every step.

Securisea supports organizations with readiness and ongoing compliance across multiple cloud security compliance standards, with assessments, certifications, and attestations for each framework carried out independently, in line with each framework's requirements. 

Contact Securisea's team to talk through how your organization's compliance obligations fit together.

The most expensive problems in a PCI DSS validation are rarely the ones organizations did not know about. They are the ones organizations assumed were resolved, such as scope that was never fully confirmed, documentation that was not updated after an infrastructure change, or controls that were configured but never tested at the required cadence. 

With 51 formerly future-dated v4.0.1 requirements now mandatory as of 31 March 2025, programs that have not revisited their compliance posture recently are likely carrying more exposure than they realize. A PCI DSS readiness assessment is designed to find that exposure before a formal assessor does. The following sections cover the categories of findings that surface most consistently, and why each one matters for validation outcomes.

8 Places PCI DSS Programs Break Down Before Validation

The following patterns appear with enough regularity across readiness engagements to function as a predictive checklist.

Scoping and Segmentation Errors

Scope is where most readiness engagements surface their first (and most consequential) finding. The problem is rarely that scope is undocumented. It is that it has not been updated to reflect how the environment has actually changed.

Systems commonly found outside the documented scope that should be in it:

• Backup servers
• SIEM and logging platforms
• Identity providers
• Cloud services
• Development or staging environments processing production account data

When these fall outside the documented CDE, every control gap associated with them becomes a validation finding.

What the standard requires: Requirement 12.5.2 obligates entities to confirm PCI DSS scope at least once every 12 months and upon significant change. Service providers must do so at least every six months under Requirement 12.5.2.1. This is the entity's internal obligation, meaning it is separate from the scope validation a QSA performs during formal assessment.

Documentation and Data-Flow Gaps

Current, accurate documentation is a prerequisite for assessor review. Without it, scope cannot be validated, and findings accumulate across multiple requirements simultaneously.

The two most common documentation gaps:

• Network diagrams: Missing or not updated to reflect infrastructure changes since the last assessment cycle (Requirements 1.2.3, 1.2.4)
• Account data flow diagrams: Absent or incomplete; Requirement 1.2.4 requires diagrams that show all account data flows across systems and networks

A note on terminology: Under v4.0.1, "account data" is the correct umbrella term. It covers cardholder data (CHD), primary account number, cardholder name, expiration date, and service code, and sensitive authentication data (SAD), which includes full track data, card verification codes, and PINs. Flow documentation that conflates the two or accounts only for CHD will not satisfy assessor review.

Unresolved Vulnerabilities and ASV Scan Gaps

Open vulnerabilities and lapsed scan cycles are among the most avoidable validation findings and among the most common. They surface not because organizations lack a vulnerability management program, but because cadence breaks down between assessment cycles when ownership is unclear.

What readiness review consistently finds:

• Missed ASV scan cycles: Requirement 11.3.2 requires external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor; gaps in that cadence disqualify prior results
• Unresolved high and critical findings: Open at the time validation begins, with no documented remediation timeline
• Patch cadence gaps: Requirement 6.3.3 requires critical patches within one month of release; other security patches within an entity-defined timeframe; neither is consistently tracked between cycles

Why this compounds: ASV scan gaps cannot be retroactively closed. An organization that discovers a lapsed cycle 60 days before scheduled validation does not have enough time to complete a full compliant cycle before the assessment begins.

Evidence and Continuous-Compliance Gaps

V4.0.1 expects evidence of controls operating continuously, not a compliance snapshot assembled in the weeks before an assessment begins. Organizations that maintain controls throughout the year but do not retain or organize evidence in a reviewable form are just as exposed as those with control gaps.

Common evidence failures:

• Log review cycles: Not maintained at the required cadence or not documented in a way that demonstrates ongoing practice
• Change management records: Incomplete or not retained across the full review period
• Periodic security testing results: Gaps in cadence that cannot be reconstructed before validation begins

For service providers specifically: Requirements 12.4.2 and 12.4.2.1 require documented quarterly reviews confirming that personnel are performing their responsibilities in accordance with security policies and operational procedures. Point-in-time assembly of those records does not satisfy this obligation.

Access Management and MFA Gaps

MFA coverage gaps are one of the most frequently underprepared findings in v4.0.1 readiness work, largely because the requirement changed materially from the prior version of the standard, and many programs have not caught up.

What the standard now requires:

• Requirement 8.4.2: MFA must be implemented for all access into the CDE, mandatory as of 31 March 2025. Under v3.2.1, MFA was required only for remote access and administrative CDE access. The expansion to all CDE access represents a significant increase in coverage for most programs.
• Requirement 7.3.1: An access control system must restrict access based on “need to know” and cover all system components

Common findings:

• MFA configured for administrator accounts but not for all personnel with CDE access
• Shared accounts and service accounts excluded from MFA coverage
• Access creep across privileged roles not reviewed or remediated since the last assessment cycle

Organizations that have not revisited access coverage since the 31 March 2025 effective date are particularly likely to carry unaddressed 8.4.2 gaps into validation.

Payment-Page Script Management

Requirements 6.4.3 and 11.6.1 were added to the standard in direct response to the rise in e-skimming attacks targeting consumer-facing payment pages. Both became mandatory on 31 March 2025. They are among the most consistently underprepared findings in v4.0.1 readiness work because many organizations have never inventoried what is running on their payment pages.

What the requirements cover:

• Requirement 6.4.3: All scripts on the consumer-facing payment page must be authorized, their integrity must be ensured, and an inventory must be maintained with a written justification for each
• Requirement 11.6.1: A change- and tamper-detection mechanism must be deployed and reviewed at least every seven days

Common findings:

• Scripts are present and functional, but never inventoried
• No written justification maintained for third-party scripts
• No tamper-detection mechanism in place or not reviewed at the required frequency

A note on ownership: In environments where a TPSP hosts the payment page, responsibility is split. The merchant is responsible for scripts and headers outside the TPSP's iframe; the TPSP is responsible for what runs inside it. That boundary is often undefined when readiness work begins.

TPSP Management Gaps

Incomplete TPSP management is a reliable source of multi-requirement findings during validation, not because organizations have no TPSP relationships documented, but because the documentation does not meet what v4.0.1 requires.

What the standard requires:

• Requirement 12.8.1: A maintained list of all TPSPs with which account data is shared or that could affect its security, including a description of services provided
• Requirement 12.8.2: Written agreements with each TPSP that include acknowledgment of their responsibility for the security of account data in their possession
• Requirement 12.8.5: Documented information about which PCI DSS requirements are managed by the TPSP, which are managed by the entity, and which are shared between them

Common findings:

• TPSP inventory exists, but is not current or does not include all qualifying relationships
• Written agreements exist, but do not address compliance responsibility
• No documentation exists that maps PCI DSS requirements to the responsible party

Remediation Bottlenecks

Finding gaps is only half the work. Organizations that complete readiness activity 6–12 months before planned validation have materially more runway to act on what they find. Those who begin 60–90 days out frequently discover that the time required to remediate outpaces the time available.

Where bottlenecks consistently form:

• Unclear ownership: Findings identified but not assigned to a responsible party with a tracked timeline
• Procurement dependencies: Hardware, software, or ASV vendor changes that carry lead times not accounted for in the remediation plan
• Interdependencies between findings: Scope corrections that require documentation updates, which require evidence collection, which cannot begin until the prior step is complete
• Targeted risk analysis gaps: Requirement 12.3.1 requires a targeted risk analysis to support entity-defined activity frequencies; undocumented risk decisions surface as findings in their own right

Remediation bottlenecks are the category most within an organization's control and the one most often underestimated until it is too late to address before validation begins.

Prepare For Validation with a PCI Readiness Assessment 

The eight categories covered here recur because they reflect how PCI DSS programs are maintained between assessment cycles, not one-time oversights. For organizations preparing for v4.0.1 validation, a PCI DSS readiness assessment gives you a clear picture of where your program stands before a formal assessor does.

Securisea’s advisory team supports readiness and gap engagements as a first step. Formal QSA validation is conducted by our independent assessment team. One partner, two separate tracks.

Learn more about Securisea's PCI DSS services or contact us to start the conversation.

‍