E-commerce platforms and SOC2 - when PCI DSS isn't enough

E-commerce platforms and SOC2 - when PCI DSS isn't enough

For e-commerce platforms, PCI DSS is mandatory, but it is not a complete security story. The standard focuses narrowly on protecting payment card data and the environments that process it. Meanwhile, a modern online store is far more than a checkout page. It is a complex operating platform that processes customer data, connects to dozens of third-party services, runs in the cloud, and must remain reliably available at all times. As a result, many organizations are beginning to question whether PCI DSS compliance alone truly meets today’s security expectations.

In practice, the answer is not always. PCI DSS secures a critical but limited slice of risk. At the same time, business partners, enterprise customers, and procurement teams increasingly expect assurance that the entire e-commerce platform is managed in a secure, controlled, and predictable manner. This is where SOC 2 naturally enters the conversation.

Why this issue matters now?

As of 31 March 2025, the future-dated requirements in PCI DSS v4.x become effective. This update is not merely an expansion of technical controls. Instead, it represents a clear shift toward continuous security management, moving away from the idea of compliance as a once-a-year exercise. This change is particularly evident in cloud environments, where infrastructure and configurations evolve constantly.

PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision that clarifies intent and guidance without adding or removing requirements. Rather than prescribing specific technical safeguards, the standard now emphasizes a risk-based approach. For many organizations, this was a clear signal that responsibility for checkout security has not been reduced. Instead, it now demands greater operational maturity and accountability.

What PCI DSS really covers in e-commerce?

PCI DSS is a global security standard that applies to organizations that store, process, or transmit payment card data. It is not statutory law, but a contractual obligation enforced by card schemes and payment processors. Failure to comply may lead to financial penalties, increased transaction fees, or, in extreme cases, the loss of card-acceptance privileges.

A central concept within PCI DSS is the Cardholder Data Environment (CDE). This includes all systems, processes, and personnel that directly or indirectly affect the security of cardholder data. The larger the CDE, the broader the audit scope, the higher the cost of compliance, and the greater the exposure to risk. Consequently, reducing CDE scope is one of the most important architectural goals in e-commerce security programs.

Payment page scripts and the shift introduced by PCI DSS 4.0.1

One of the most persistent challenges in e-commerce security involves scripts running on payment pages. Digital skimming attacks, commonly known as Magecart attacks, inject malicious JavaScript into a site to capture sensitive data directly in the customer’s browser.

Earlier versions of PCI DSS 4.0 introduced explicit technical requirements to address this threat. For SAQ A e-commerce merchants, PCI SSC introduced an updated eligibility criterion in SAQ A r1 (effective 1 April 2025): the merchant must confirm its site is not susceptible to script-based attacks affecting the merchant’s e-commerce system(s). FAQ 1588 clarifies that this confirmation can be supported either by implementing protections aligned with Requirements 6.4.3 and 11.6.1, or by obtaining confirmation from the PCI DSS compliant TPSP/payment processor that its embedded payment solution includes protections against script attacks when implemented as instructed. Instead of mandating specific controls, organizations are now required to demonstrate that their payment pages are not vulnerable to script-based attacks that could compromise transaction security.

Importantly, this change does not reduce accountability. Rather, it shifts responsibility from checklist compliance to deliberate, evidence-based risk management. In practical terms, accountability shifts from ticking a predefined control list to demonstrating (and evidencing) that script-based attack paths are effectively mitigated—either through merchant-implemented controls or TPSP-provided protections that are confirmed and properly implemented.

Payment models and responsibility boundaries

Responsibility for payment page security depends heavily on how payments are implemented:

• In an iframe model, the merchant is responsible for scripts on the parent checkout page, while the payment service provider is responsible for scripts running inside the iframe.

• This SAQ A eligibility criterion does not apply to merchants that redirect customers from the merchant page to a TPSP/payment processor (including HTTP 30x, meta redirects, or JavaScript redirects) or to merchants that fully outsource payment functions to a TPSP/payment processor.

• In a fully outsourced payment model, responsibility for the payment page rests entirely with the provider.

In practice, this means that simply using an external payment gateway does not automatically eliminate merchant responsibility. Any marketing, analytics, testing, or third-party scripts loaded on the checkout page can still influence risk and compliance scope.

SAQ A versus SAQ A-EP: a difference that changes everything

Misclassifying the payment environment can have serious consequences. Moving from SAQ A to SAQ A-EP increases the number of required controls from 27 to 131. This is not a minor adjustment. It fundamentally changes how security, testing, and documentation must be managed.

At this stage, many organizations realize that investments in monitoring, governance, and risk management extend well beyond PCI DSS requirements. As a result, the need arises for a framework that demonstrates overall organizational security maturity, not just compliance within a single technical domain.

Cloud environments and the illusion of inherited compliance

Most modern e-commerce platforms operate in public cloud environments. This has given rise to a costly misconception: if the cloud provider is PCI DSS compliant, then the platform must be compliant as well.

The shared responsibility model clearly defines boundaries. Cloud providers secure the underlying infrastructure and foundational services. However, configuration, identity and access management, data protection, application security, and integrations remain the customer’s responsibility. In reality, misconfigurations on the customer side are the most common cause of security incidents in cloud-based e-commerce platforms.

What PCI DSS 4.0 actually changes for e-commerce teams?

The latest version of the standard introduces several changes with direct operational impact:

• Mandatory multi-factor authentication for all access to the CDE, not just remote access.

• A minimum password length of 12 characters, requiring updates to access policies.

• Authenticated internal vulnerability scanning, increasing both visibility and remediation effort.

• A strong emphasis on continuous control effectiveness, rather than periodic compliance checks.

Each of these requirements demands documented processes, tooling, and demonstrable evidence. At this point, PCI DSS naturally begins to overlap with governance areas typically addressed by SOC 2.

Why PCI DSS alone is not a sufficient trust signal?

PCI DSS answers a specific question: are payment card details adequately protected? It does not, however, address the broader questions commonly raised by partners and customers:

• Is the platform resilient and supported by business continuity plans?

• Are orders processed accurately and with integrity?

• Is access to systems governed consistently and repeatably?

• Are vendors and integrations managed securely?

These considerations fall outside the formal scope of PCI DSS, yet they are central to assessing operational and business risk.

SOC 2 as a natural complement to PCI DSS

SOC 2 is built around the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Rather than prescribing a fixed set of technical controls, it requires organizations to demonstrate that effective, operating controls are in place and aligned with their risk profile.

For e-commerce platforms, this makes it possible to show that security extends beyond the checkout. It covers the full order lifecycle, access governance, incident response, and vendor management, areas that increasingly define customer trust.

How to combine PCI DSS and SOC 2 effectively?

A sound approach begins with accurate scoping. Organizations must clearly identify which systems interact with cardholder data and which do not. From there, they should aggressively reduce CDE scope through techniques such as tokenization and environment segmentation.

At the same time, payment page scripts should be treated as a high-risk area, regardless of simplified SAQ classifications. Structured testing, monitoring, and evidence collection support both PCI DSS compliance and SOC 2 assurance objectives.

Conclusion

PCI DSS remains essential for e-commerce platforms that accept card payments. However, on its own, it no longer provides a complete picture of platform security. As platforms scale, integrations multiply, and stakeholder expectations rise, SOC 2 becomes a logical and increasingly expected complement.

For mature e-commerce organizations, the question is no longer whether PCI DSS is enough. The real question is how quickly security stops being a regulatory obligation and becomes a source of measurable business advantage.