SOC 2 by industry
SOC 2 for e-commerce: staying up on the busiest day, staying out of the card flow.
This guide is for companies that sell software to merchants: storefront platforms, checkout tools, order and inventory systems, marketplaces. Your customers' customers are shoppers, so your report is read for two things: whether the platform holds up on its heaviest day, and how cleanly payment data is kept away from systems that do not need it.
Back to SOC 2 services01 · Who asks
Who asks e-commerce companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| Enterprise retailers and brands | A Type 2 with Availability, evidence of load testing and a clear statement of what the platform's incident communication looks like. |
| Marketplace operators | How sellers' accounts are isolated from each other and how payouts are protected. |
| Payment and fraud partners | How you integrate, what card data you touch and how webhooks and API keys are secured. |
| Agencies and system integrators | A report they can hand to their own retail clients when recommending your platform. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- Storefront and checkout services
- The pages and APIs that render catalogues, carts and checkout, and the scripts they load.
- Order, inventory and fulfilment systems
- Where orders are created, stock is adjusted and shipments are triggered.
- Merchant admin and API keys
- The console merchants use, staff accounts within it and the keys their integrations hold.
- Shopper personal data
- Names, addresses, order histories and marketing preferences held on behalf of merchants.
- Payout and settlement records
- For marketplaces, the records of what each seller is owed and when it is paid.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Core | Always included. Merchant account takeover and script tampering on checkout pages are the threats reviewers think about. |
| Availability | Core | Downtime during a sale is lost revenue for every merchant at once. Capacity planning and failover are read closely. |
| Confidentiality | Common | Merchant sales data, pricing and supplier details are commercially sensitive. |
| Privacy | Situational | Mostly where you deal with shoppers under your own notice, for example a marketplace with shopper accounts. |
| Processing Integrity | Situational | Fits order management, tax calculation or marketplace payouts, where merchants rely on the numbers without rechecking. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- Payment service provider
- Carved out. Its hosted fields or redirect keep card numbers in its environment, and your description should say exactly that.
- CDN and edge platform
- Carved out, but central to Availability and to how checkout pages are served. Its CSOCs belong in the description.
- Fraud screening service
- A subservice organization if orders are accepted or declined on its score.
- Email and messaging providers
- Send order and shipping notices containing shopper data. Reviewed as vendors holding personal information.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Peak readiness is reviewed before planned eventsBefore a known sales peak, capacity, autoscaling limits and on-call cover are reviewed and signed off.
- S.2Checkout page scripts are inventoriedEvery script loaded on payment pages is listed, justified, and checked for unexpected change.
- S.3Merchant admin requires multi-factor sign-inEnforced or strongly defaulted for merchant staff, with staff-account changes logged for the merchant.
- S.4Payout destination changes need verificationChanging a seller's bank details triggers re-verification and a hold before funds move.
- S.5Webhooks are signed and verifiedInbound notifications from the payment provider are rejected unless their signature checks out.
- S.6Load tests run on a scheduleLoad tests are performed against a defined target, and the results feed capacity planning.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Assuming the PSP takes all card risk away. Hosted fields reduce your exposure, but the page that loads them is yours. A tampered script on it is still your problem.
- Availability chosen with no capacity evidence. Uptime dashboards alone do not show capacity planning (A1.1). Keep the planning record, not just the graph.
- Merchant-built apps and themes left undescribed. If merchants can install third-party apps, the description should state where your responsibility ends and theirs begins as a CUEC.
- Shopper data copied into analytics freely. Order exports end up in spreadsheets and BI tools. Those copies are part of the confidentiality story.
- Peak-day changes that skip review. Emergency fixes during a sale are understandable. Without after-the-fact approval they become change-management exceptions.
07 · Payment-flow scoping
Drawing the line around the payment flow
How you collect card data decides how much of checkout sits in your SOC 2, and how much PCI DSS work you owe.
| Integration pattern | Card data touches you? | What your SOC 2 should describe |
|---|---|---|
| Full redirect to the provider's page | No | The redirect itself, its integrity and the order confirmation return path |
| Embedded hosted fields (iframe) | No, but your page hosts the frame | Control over the parent page and its scripts, plus the provider as a carved-out vendor |
| Provider's JavaScript on your page | In the browser, on your page | Script integrity, change control on checkout and how the provider's library is loaded |
| Direct API with card numbers | Yes | Card data enters your system: expect full PCI DSS obligations alongside the SOC 2 |
Illustrative. Your acquirer and payment provider decide which PCI DSS validation applies to you. The SOC 2 describes your controls; it does not set your PCI level.
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- Capacity plans and the peak-readiness review for any planned event in the period
- Load test results against their targets
- The checkout script inventory and its change records
- Uptime records and incident communications to merchants
- Payout-destination change logs with verification
- The payment provider's assurance reports and your review of them
PCI DSS is a separate obligation
Anyone who stores, processes or transmits cardholder data, or can affect its security, falls under the PCI Data Security Standard. Version 4 added requirements on managing scripts in payment pages. Your SOC 2 report may touch on controls that relate to card handling, yet it is no PCI assessment and cannot stand in for the validation your acquirer requires.
Sources: AICPA Trust Services Criteria (TSP section 100), Availability criteria A1.1 to A1.3; AICPA Description Criteria (DC section 200); PCI Security Standards Council, PCI DSS version 4.
More about SOC 2 for e-commerce
Our payment provider holds a PCI attestation. Can we put that in our SOC 2?
You can name it. You cannot borrow it.
Your description can say that card data is processed by a provider that is PCI DSS validated, and treat the provider as a carved-out vendor. The SOC 2 opinion still covers only your controls.
We have a quiet season. Can we time the observation period to avoid the holiday peak?
You can, but buyers notice.
A Type 2 period that never includes your heaviest traffic tells a retailer little about how Availability controls behave under load. If the period misses peak, keep peak-readiness evidence anyway; some buyers will ask for it directly.
Are merchants' own staff accounts our responsibility?
Partly. Name the split as CUECs.
You provide the controls, such as multi-factor sign-in and role settings. Merchants decide who gets access and when to remove it. That second part belongs in the report as a Complementary User Entity Control.
Does a marketplace need Processing Integrity for payouts?
Often worth considering.
If sellers rely on you to calculate fees, refunds and payouts correctly, that is a processing commitment. Adding Processing Integrity lets the report test it. If payouts are handled entirely by a payment provider's platform, the case is weaker.
Scope your e-commerce SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.