SOC 2 for E-Commerce Platforms: Controls, Scope & PCI DSS

A SOC 2 report is an independent CPA attestation about controls at a service organization. The AICPA’s SOC suite overview describes SOC engagements as examinations of controls over customer data and related systems. For an e-commerce platform, that system is more than a storefront: it can include the payment page, checkout APIs, order and inventory services, fulfillment integrations, admin tools, cloud infrastructure, and the vendors that keep the service running.

The practical question is not whether an e-commerce platform needs every possible control. It is which customer promises the platform makes, which data and workflows support those promises, and what evidence proves the controls operate. This guide uses that model to scope a SOC 2 report without turning the page into a generic PCI DSS or vendor-management manual.

What does SOC 2 cover for an e-commerce platform?

SOC 2 covers the systems, people, processes, and third parties that support an e-commerce platform’s in-scope service and selected Trust Services Criteria. The boundary should follow the platform’s customer promises and data flows, not the org chart or the product homepage.

An e-commerce platform may host stores for merchants, provide a commerce engine, process orders on a merchant’s behalf, or supply services such as checkout, catalog, inventory, fraud screening, or fulfillment orchestration. Those models create different boundaries. A platform that never receives raw card numbers still needs to secure its payment-page integration, API credentials, webhooks, order state, merchant data, and shopper information.

Which systems belong in the audit boundary?

Start with a data-flow diagram and a short system description. Trace one customer action — from page load to checkout, payment authorization, order creation, fulfillment, refund, and reporting — and name every system that can change the outcome.

The first-pass inventory usually includes:

• Customer-facing surfaces: storefront components, checkout pages, account pages, mobile apps, and merchant admin panels.
• Transaction services: cart, pricing, tax, promotion, payment orchestration, order, refund, and reconciliation services.
• Operational systems: inventory, warehouse, shipping, returns, notification, and customer-support integrations.
• Data stores: shopper PII, merchant sales data, order history, payment tokens, logs, analytics, and backups.
• Engineering and identity systems: cloud accounts, source repositories, CI/CD, identity providers, ticketing, monitoring, and incident-response tooling.
• Third parties: payment processors, tax engines, fraud providers, shipping services, analytics tools, email providers, cloud hosts, and contractors with access to code or production systems.

The boundary is a scoping decision, not a list of every tool the company has ever purchased. A system belongs when it supports the in-scope service, stores or processes in-scope data, administers the environment, or creates a dependency that could affect a stated commitment.

Why does the merchant/platform distinction matter?

The merchant remains responsible for its payment acceptance and PCI DSS validation obligations. The platform owns the service it provides, the integration it operates, and the SOC 2 controls it promises to customers. One organization can therefore have a PCI DSS responsibility, a SOC 2 responsibility, or both — depending on the data flow and service relationship.

That distinction prevents a common scope error: treating a processor’s compliance report as evidence that the e-commerce platform’s own checkout code, scripts, webhooks, order processing, access controls, or availability controls are covered. The processor’s report can be useful third-party evidence. It does not replace the platform’s system description or its own control testing.

Which Trust Services Criteria should an e-commerce platform include?

Every SOC 2 report includes Security, also called the Common Criteria. An e-commerce platform adds Availability, Processing Integrity, Confidentiality, or Privacy when those criteria describe customer commitments, material failure modes, or data-handling promises that buyers need the report to address. The AICPA’s Trust Services Criteria materials define the criteria; your auditor helps translate them into control objectives.

Use this decision aid before choosing scope:

Trust Services Criterion	Include it when the platform…	E-commerce control questions
Security	protects merchant accounts, shopper data, production systems, or integrations from unauthorized access or change.	Are privileged roles limited? Is administrative access strongly authenticated? Are production and code changes traceable?
Availability	makes uptime, recovery, capacity, or service-continuity commitments that affect checkout or merchant operations.	Can the platform detect checkout degradation, recover critical services, and show that recovery procedures were tested?
Processing Integrity	calculates, transforms, routes, reconciles, or updates business-critical data.	Are order totals, tax, discounts, inventory reservations, payment status, refunds, and fulfillment events complete, accurate, timely, and authorized?
Confidentiality	protects non-public merchant information such as sales data, pricing rules, forecasts, or proprietary analytics.	Is confidential merchant data classified, access-restricted, retained, and disclosed according to contractual commitments?
Privacy	collects, uses, retains, discloses, or disposes of shopper or employee personal information under defined privacy commitments.	Can the platform show notice, access, retention, deletion, and incident-handling practices that match its privacy disclosures?

Do not add every optional criterion because a broader report sounds stronger. Add a criterion when a buyer, contract, service-level promise, or material operational risk makes the evidence worth the added control work. For a deeper explanation of Processing Integrity’s five attributes, use the Processing Integrity criteria guide; this page only applies the criterion to e-commerce workflows.

How should Security controls fit an e-commerce platform?

Security controls should cover the paths that could expose shopper or merchant data or change an order outcome: admin accounts, production databases, payment integrations, source code, cloud configuration, support access, and vendor connections.

Common evidence includes role and permission definitions, access approvals, joiner-mover-leaver records, privileged-access reviews, authentication configuration, secret-management records, vulnerability remediation, logging, incident tickets, and approved production changes. MFA is a common design choice for privileged access, but the report should describe the control the platform actually operates rather than claim that one tool or setting is universally required by SOC 2.

When does Availability belong in scope?

Availability belongs in scope when the platform promises reliable service to merchants or when checkout, inventory, or fulfillment downtime creates a material customer impact. Evidence should connect the promise to measurable targets and response procedures.

A useful evidence set includes service-level definitions, monitoring and alert thresholds, capacity or load testing, backup and restoration records, recovery objectives, disaster-recovery exercises, incident reviews, and remediation tracking. A diagram that says “high availability” is not enough; the platform must show what happens when a payment service, order queue, database, or shipping integration is unavailable.

When does Processing Integrity belong in scope?

Processing Integrity deserves attention when customers rely on the platform’s outputs, not just its security. Order totals, tax calculations, discount logic, inventory counts, payment states, refunds, and fulfillment events are all examples of processing that can be incomplete, inaccurate, late, or unauthorized.

Start with the workflows where an error would create a customer dispute, revenue leakage, inventory error, duplicate charge, missed shipment, or manual correction. Define the expected input, transformation, output, timing, and exception path. Then retain the tests, reconciliations, queue alerts, approvals, and correction records that prove the workflow was controlled. The dedicated Processing Integrity criteria guide covers the full five-attribute framework.

When do Confidentiality and Privacy belong in scope?

Confidentiality and Privacy answer different questions. Confidentiality protects information the platform has promised to keep restricted, such as merchant sales data or proprietary pricing. Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of.

For e-commerce platforms, keep a data inventory that distinguishes shopper PII from merchant-confidential information and operational telemetry. Connect each class to access rules, retention periods, deletion or correction workflows, processor contracts, and incident handling. A public privacy notice does not by itself prove that production systems follow the stated practice.

What evidence should an e-commerce platform collect?

The strongest evidence follows a business workflow from input to output. Collect the control description, the system-generated record, the human review or approval, and the exception path together so an auditor can reconstruct what happened without stitching together unrelated screenshots.

This map is a starting point, not a fixed evidence request list:

E-commerce workflow	Primary SOC 2 focus	Control question	Evidence examples
Payment page and processor integration	Security; PCI DSS boundary	Which scripts, keys, headers, APIs, and webhooks can affect payment or order state?	Payment-page script inventory, change approvals, integrity/tamper monitoring, secret-access records, integration configuration, webhook authentication and failure logs
Cart and checkout	Security; Processing Integrity	Are prices, tax, discounts, currency, and authorization rules applied to the right customer and order?	Test cases, approved code changes, release records, validation results, exception tickets, audit logs
Order and inventory state	Processing Integrity; Availability	Are order creation, stock reservation, state transitions, retries, and duplicate events complete and timely?	Queue and job monitoring, idempotency or retry evidence, reconciliation reports, alert reviews, incident and correction records
Fulfillment, returns, and refunds	Processing Integrity; Availability	Are shipment, cancellation, return, and refund events authorized and reconciled across systems?	Integration contracts, workflow tests, approval records, reconciliation outputs, sampled transaction trails, exception disposition
Shopper PII and merchant data	Confidentiality; Privacy	Are data classes, access, retention, disclosure, and deletion practices defined and followed?	Data inventory, access reviews, retention/deletion evidence, privacy-request records, processor agreements, incident-response records
Cloud, code, and vendors	Security; Availability; CC9.2	Are infrastructure, code changes, critical providers, and access dependencies assessed and monitored?	IAM and repository settings, change tickets, vendor inventory, risk assessments, SOC reports, contract terms, review and offboarding records

The table is a workflow map grounded in the AICPA SOC/TSC model and PCI SSC’s e-commerce payment-page guidance. The exact population, sample, and retention period depend on the platform’s system description and the report type. Do not create evidence only for the auditor: these records should be the normal output of checkout, engineering, operations, and support work.

How should an e-commerce platform separate SOC 2 from PCI DSS scope?

SOC 2 and PCI DSS address overlapping security work but answer different questions. SOC 2 is a CPA attestation about selected Trust Services Criteria; PCI DSS is a payment-card standard whose scope follows cardholder-data flows. Using a processor can reduce PCI exposure without removing the platform’s SOC 2 responsibilities.

The PCI DSS reference card and the site’s SOC 2 vs. PCI DSS comparison cover the full framework distinction. For an e-commerce platform, the payment architecture is the practical first decision:

Payment architecture	What the platform should confirm	SOC 2 implication
Redirect or fully outsourced payment page	The platform does not receive raw card data, but the merchant must confirm the correct PCI DSS validation path with its acquirer or payment brand. PCI SSC says the SAQ A script-attack eligibility criterion does not apply to pages that redirect customers or fully outsource payment functions.	Secure the redirect, return URL, tokens, webhooks, order state, shopper data, and operational availability. Processor evidence does not cover the platform’s entire service.
Embedded payment form or iframe	The merchant’s page still renders a payment form. Under PCI SSC’s February 28, 2025 FAQ, the merchant’s SAQ A eligibility requires confirming that the page is not susceptible to script attacks, using applicable techniques or confirmation from the compliant payment provider when implemented as instructed.	Treat the page, scripts, headers, integration changes, and provider dependency as in-scope evidence for the platform’s own control environment.
Direct card-data capture	The platform stores, processes, or transmits raw cardholder data. Expect a broader PCI DSS assessment path and confirm the exact validation requirements with the acquirer, payment brands, and a qualified assessor.	Add payment-data access, key management, logging, change control, and transaction-processing evidence to the SOC 2 system description and test plan.

This table does not determine a merchant’s PCI DSS questionnaire or validation outcome. PCI SSC explicitly directs organizations to work with their acquirer or relevant payment brands. The platform should document the architecture, the provider’s role, the data it receives, and the controls it operates rather than label the integration “PCI compliant” by assumption.

What changed under PCI DSS v4.0.1 for payment pages?

On May 6, 2026, PCI SSC published supplemental guidance for payment-page security and e-skimming. The guidance discusses PCI DSS v4.x Requirements 6.4.3 and 11.6.1, which address authorization and integrity of payment-page scripts and monitoring for tampering or unauthorized changes to the page and relevant security-impacting headers. Read the PCI SSC payment-page and e-skimming guidance before finalizing the payment-page control design.

For a platform team, that turns a vague “use a PCI-compliant processor” statement into concrete operating questions:

1. Which scripts run on the payment page, and who approved each one?
2. What prevents an unauthorized script or header change from reaching a customer’s browser?
3. How does the team detect and investigate tampering?
4. Which controls belong to the platform, and which are supplied by the payment provider?

Keep the date in the control review. Payment-page guidance and provider implementations change faster than the core SOC 2 page, so review this subsection at least quarterly and whenever the checkout architecture changes.

Which e-commerce controls should be tested before fieldwork?

Before an auditor starts testing, run a readiness review against the platform’s highest-consequence workflows. The goal is to find mismatches between policy, production behavior, and retained evidence while the team can still change the process.

Can the team trace a checkout from page load to order?

Select representative checkout paths and trace them through page rendering, cart calculation, payment authorization, order creation, inventory reservation, fulfillment handoff, and customer notification. Record where the flow crosses a third-party boundary and how failures, retries, duplicates, and refunds are handled.

The output should be a control-and-evidence map, not a screenshot collection. For each step, name the owner, system, expected result, monitoring signal, exception record, and retention location.

Can the team prove that production changes are controlled?

Review changes to checkout code, payment integrations, tax logic, inventory services, webhooks, and page scripts. A defensible path connects a change request to review, testing, approval, deployment, and post-deployment verification.

Emergency changes need their own documented path. If the policy says every production change is approved in advance but the operating practice uses an emergency procedure, write and test the emergency procedure before fieldwork instead of leaving the exception in chat.

Can the team show how it monitors vendors?

Create one inventory for payment, tax, fraud, shipping, analytics, cloud, identity, and other providers that can affect the service. Record the data or system access, business criticality, owner, review date, contract terms, and relevant provider report.

The SOC 2 vendor management requirements guide owns the full CC9.2 lifecycle. On this page, the e-commerce-specific question is narrower: if a payment, tax, inventory, or fulfillment provider fails or changes its controls, how will the platform detect the impact and keep the service or customer commitments defensible?

How long and how much should an e-commerce SOC 2 audit take?

There is no reliable universal e-commerce price or duration. Scope, report type, control maturity, system complexity, evidence quality, and auditor fit shape the total. Budget for the auditor, internal staff time, remediation, tooling, security testing, and the cost of operating controls throughout the review period.

A first-time plan usually has four workstreams:

1. Scope and readiness: draw the data flows, choose the criteria, define owners, and identify control gaps.
2. Remediation and stabilization: fix access, payment integration, change management, monitoring, recovery, data handling, and vendor gaps.
3. Operating period: for Type 2, run the controls consistently and retain evidence across the defined observation period.
4. Fieldwork and reporting: give the auditor the system description and evidence, answer sample requests, resolve exceptions, and review the final report.

Type 1 assesses control design at a point in time. Type 2 assesses design and operating effectiveness over a defined period. Many enterprise buyers ask for Type 2, but the right choice depends on the buyer requirement and the maturity of the controls. Use the SOC 2 Type 2 audit guide and SOC 2 timeline guide for the report-type and duration decisions, and the SOC 2 audit cost guide for current pricing methodology.

When interviewing auditors, ask how they will test payment-page changes, order and refund processing, inventory or fulfillment reconciliations, third-party dependencies, and the exact evidence populations the platform can produce. A firm that understands e-commerce transactions will ask about system behavior and exception handling, not only policy documents.

What should an e-commerce platform do after the SOC 2 report is issued?

A SOC 2 report covers a defined system description, scope, criteria, and report period; it is not a permanent certification. Maintain the controls after issuance, track the next review period, and be ready to explain any gap between the report period end and the date a buyer requests the report.

The maintenance cycle should include:

• recurring privileged-access and vendor reviews;
• change, deployment, and payment-page script records;
• checkout, order, fulfillment, refund, and reconciliation monitoring;
• backup and recovery tests;
• privacy, retention, and deletion evidence;
• incident and exception reviews; and
• a written process for answering customer requests about the report, bridge letters, scope, and complementary user entity controls.

Do not describe the report as “valid for only 12 months.” That wording confuses a report’s defined period with a certificate expiration date. Buyers may expect a current report or a bridge letter, but the platform’s real obligation is to keep the control environment operating and the evidence trail continuous. The SOC 2 audit renewal playbook covers the renewal-specific planning work.

---

If you are selecting an auditor for an e-commerce platform, compare SOC 2 audit firms by scope, industry experience, timeline, and pricing approach. The right match is a CPA firm that can test the platform’s real payment, order, data, and vendor dependencies — not just review a policy binder.