PCI compliance and AI are colliding faster than most compliance programs have caught up to. The available evidence on AI governance suggests many organizations are still working out where AI fits in an already-scoped cardholder data environment. The PCI Security Standards Council began to address it in a September 2025 PCI Perspectives blog post, ‘AI Principles: Securing the Use of AI in Payment Environments,’ which offers high-level, non-binding principles to consider when deploying AI systems. These guiding principles included that AI must be deployed and managed in compliance with applicable PCI SSC requirements, and that use of AI does not remove or bypass the need to meet the requirements of any applicable PCI SSC standard.

Generative AI doesn't sit outside PCI DSS scope simply because it's new. The requirements that already govern cardholder data (how it's stored, processed, transmitted, and who can access it) apply as soon as an AI system stores, processes, or transmits that data, or is connected to or could impact the security of the environment that does.

Where PCI DSS Actually Stands on AI Right Now

PCI DSS v4.0.1, the current version of the standard, contains no AI-specific requirements. It was a limited revision with no new or deleted requirements, and nothing in the standard itself was written with AI in mind. What exists instead is guidance from the PCI Security Standards Council, layered on top of the requirements already in place.

The second document matters if your organization works with assessors that uses AI tools during an assessment. The first is the one that matters if your organization is adopting AI internally, and it's the one the rest of this piece focuses on.

Can Cardholder Data Go Into an AI Tool?

For most organizations, no, and the reason has nothing to do with AI being new or unproven. It comes down to what PCI DSS already requires of cardholder data, regardless of where that data ends up.

A prompt is a transmission. Requirement 4 governs how cardholder data must be protected when it travels across open, public networks, and a prompt sent to an AI tool doesn't get an exception because the destination is a chatbot instead of a payment processor.

A retained prompt is stored data. If the AI tool keeps a record of the conversation, that data is now stored somewhere outside the organization's cardholder data environment, which brings Requirement 3 into play.

Sensitive authentication data has almost no exceptions, anywhere. Full track data, the card verification code (CVV/CVC/CID), and PIN data may never be stored after authorization by a merchant or service provider, in any system. AI tools included. OpenAI's help center, for one, instructs customers not to enter cardholder data into ChatGPT at all, and other major providers publish similar guidance against entering sensitive or financial information.

Enterprise tiers help, but they don't solve this. A paid or enterprise AI subscription may offer stronger contracts and broader security certifications than a free consumer account. That's a better starting point for a vendor relationship, not a substitute for the scoping and vendor management work PCI DSS actually requires.

Any AI Tool You Let Handle Cardholder Data Is a Vendor Relationship

If your organization adopts an AI tool to store, process, or transmit cardholder data, that vendor is a third-party service provider, and it must be managed under Requirement 12.8, the same way you manage any other third-party service provider. It doesn't need to be built for payments to qualify.

That means treating the AI vendor the same way a payment processor or a cloud host would be treated:

• Maintaining it on your list of service providers
• Getting a written agreement that acknowledges their responsibility for the data 
• Performing due diligence before you engage them
• Monitoring their PCI DSS compliance status at least once every 12 months
• Documenting which requirements they manage, which you manage, and which are shared

The harder problem is the tool you never engaged at all. When an employee pastes a card number into a consumer AI account, or uploads a document or screenshot that contains one, there's no vendor relationship to manage, no agreement, and often no record it happened. That isn't a 12.8 problem, it's a shadow-IT and data-leakage problem, and PCI DSS addresses it through a different set of requirements: 

• Acceptable use policies for end-user technologies
• Keeping your data-flow and scope documentation current wherever account data actually travels 
• Protecting that data at rest and in transit
• Responding when it leaks

Both risks exist and can be consequential. One is a vendor you chose and have to manage. The other is a vendor you didn't choose, showing up in your environment without anyone signing off. A compliance program has to account for both.

Common Misconceptions About PCI Compliance and AI

While not exhaustive, this is a brief list of common misconceptions surrounding PCI and AI:

"The vendor has a SOC 2 or ISO 27001 certification, so it's compliant." A SOC 2 attestation report and an ISO 27001 certification are real, valuable independent assessments, but neither one is a PCI DSS validation. They cover different scopes, different frameworks, and different questions. A vendor can hold both and still not be appropriate for a workflow that touches cardholder data.

"It's an internal AI deployment, so PCI scope doesn't apply." Scope isn't determined by whether a tool is public or internal. It's determined by whether the tool handles cardholder data, connects to, or could affect the security of, systems that do. An internal model that directly ingests that data is part of the cardholder data environment, regardless of who built it.

"We mask the data before it goes into the AI tool, so we're covered." Hiding data on screen and actually removing it aren't the same thing. Data that's only masked in the display can still exist beneath the surface, in the document or in the metadata the AI system actually reads. If the goal is to keep cardholder data out of an AI tool, the data needs to be removed before ingestion, through truncation or deletion, not just hidden from view.

"Employees using AI for customer support isn't really a PCI issue." It is, and it's one of the more common ways cardholder data ends up somewhere it shouldn't. An employee troubleshooting a customer issue who pastes a transaction record containing a full card number into an AI tool has just transmitted cardholder data to a third party, whether or not anyone intended for that to happen.

What Compliance Teams Are Doing About This

Generative AI adoption isn't slowing down, and neither will its impact on cybersecurity and security compliance at large. In October 2023, Gartner predicted that by 2026, more than 80 percent of enterprises will have used generative AI APIs or models, and/or deployed generative AI-enabled applications in production environments, up from less than 5 percent in 2023. Compliance programs that wait for a clear signal to act are already behind.

A workable set of governance practices looks like this:

• Audit where AI is actually being used, including tools nobody formally approved. Unsanctioned AI use is common, and it's often the biggest blind spot.
• Remove cardholder data before it reaches an AI tool, rather than relying on policy alone to prevent it. Truncation or tokenization has to happen upstream of the AI tool, not as an afterthought.
• Put a real acceptable-use policy in place. Name the tools that are approved, and state plainly which categories of data can never go into any of them.
• Treat every new AI tool like a new vendor or integration. That means a scope review before adoption, not a cleanup effort after someone realizes what the tool has access to.

None of this requires waiting on a new PCI DSS requirement written specifically for AI. The requirements already in place, applied with the same rigor as any other vendor or data-handling decision, cover most of what generative AI adoption actually demands.

Balancing PCI Compliance and AI Adoption

Getting PCI compliance and AI right isn't about slowing down adoption. It's about knowing, before a tool goes live, where cardholder data can and can't go. That principle doesn't ask compliance teams to treat AI as a special case or to throw out their functioning readiness checklists and habits. It asks them to apply the same scoping discipline, vendor management, and data-handling standards they'd apply to any other new system, and to do so before the tool is already embedded in how the business runs.

Securisea works with organizations navigating questions where a new technology decision runs into an existing compliance obligation. These discussions often extend beyond PCI DSS and can involve related frameworks such as SOC examinations, ISO 27001 certification, GovRAMP assessment, and HITRUST. requirements at the same time, not just one framework in isolation.

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

‍

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.