Who pays when a third‑party seller exposes customer data or botches payments? The platform pays if it controlled the data or the payment flow. If the seller held data and had clear indemnity plus insurance, the seller normally pays. Customers and regulators may still pursue the platform, so expect mixed legal and financial exposure.
Marketplaces must know how liability splits between platform and third parties. They must also know how insurance responds. This guide gives clear answers on likely responsibility after breaches. It lists common policy gaps such as seller account takeovers and PCI failures. It shows what cover to seek in the UK. It gives practical steps marketplaces and sellers can take to cut costs and claims.
How marketplaces and third‑party sellers increase cyber risk
Marketplaces raise exposure when sellers touch customer data, payments or listings. This growth increases both the technical attack surface and legal routes for claims.
Attackers go for the weakest account, not the biggest brand. A seller account takeover often leads to fraud, data exposure or extortion. These harms hit the platform and customers.
The legal picture shifts when the marketplace issues API keys, holds PII or manages payments. Those control points make the platform more likely to face claims and regulatory checks.
A single missing control can change who regulators target.
How does control change legal responsibility?
Control over credentials, API scopes or payment flow usually makes the platform face vicarious or direct liability. Contract alone does not remove statutory duties under UK GDPR.
A clear control point often decides who defends claims and who pays fines.
What insurer questions follow from seller access?
Insurers ask who issued keys, what logs exist and whether MFA was enforced. They also ask whether sellers had the required insurance.
Underwriters expect documented seller checks and prompt incident cooperation.
Insurers will probe onboarding records closely.
Seller roles: data hosting, payments and APIs
If a seller stores customer data on its own systems, liability often rests with the seller. If the platform stores or processes data, the platform bears primary exposure.
The practical split depends on technical control and contractual wording. Evidence of segregation helps insurers decide who pays.
When payments run through the platform, fraud and chargebacks can cause business interruption and reputational loss for the marketplace. Payment processors and PSPs affect insurers' view of loss causation.
APIs that allow broad read or write scopes multiply risk. One compromised API key can enable data scraping or unauthorised orders. Those orders can affect thousands of buyers.
A lack of rate limits or scopes makes incidents much worse.
When is the seller clearly responsible?
Seller responsibility is clear when the seller alone collects and stores PII on its systems. The contract must require the seller to keep security and insurance.
Evidence of segregation and signed insurance certificates supports insurer recovery.
When is the marketplace clearly responsible?
The marketplace is responsible when it issues credentials, holds payment data or failed to require basic controls at onboarding. Those facts increase the chance the marketplace must respond to claims or ICO enquiries.
Failure to enforce simple controls often shifts liability to the platform.
Technical onboarding and integration controls for sellers
Marketplaces that want to reduce risk and underwriting friction should codify a technical onboarding sequence. Do not rely on ad‑hoc checks.
Practical steps include a two‑stage identity and entity check using GOV.UK company numbers or similar documents. Add automated AML and name screening.
Require pre‑go‑live security attestations for integrations. Use risk banding so higher revenue sellers face extra checks.
On the API side require per‑seller API keys with least‑privilege scopes. Set short TTLs and enforce regular key rotation. Apply strict rate limits and signed webhooks.
Store secrets in an HSM or vault. These measures reduce single points of failure.
For payments insist on PSP tokenisation so cardholder data never passes platform systems. Require signed PSP SLAs that explain chargeback handling and freeze mechanisms.
Enable real‑time logging and SIEM or EDR feeds with retained audit logs of 30–90 days. These logs show incidents were investigated.
These technical controls change loss causation stories with insurers and regulators. They show segregation of duties and repeatable governance.
A brief extra reminder for busy teams: keep these measures documented and evidence available.
Choosing cover and common underwriting traps
Map who stores data, who runs payments and what controls exist before choosing cover. A combined approach usually fits marketplaces that touch payments or data directly.
Third‑party cover alone may leave gaps.
The error most frequent here is assuming a platform policy covers losses caused by sellers. Many platforms find exclusions for contractor or vendor acts unless a vendor endorsement exists.
What most guides omit is that insurers expect contractual risk transfer and proof of enforcement at underwriting. Brokers often accept vague promises. Underwriters want COIs, indemnities and evidence of controls.
Which cover suits a marketplace that stores PII or card data?
If the platform stores PII or card data, buy first‑party incident response, business interruption and extortion cover. Ensure third‑party liability covers defence and damages.
Name the platform as an interested party on seller COIs where possible.
What wording traps cause claim denial?
Narrow definitions of "unauthorised access" and retroactive date gaps commonly stop payment. Check contractual liability exclusions closely.
Also look for sub‑limits on vendor‑caused incidents and prior acts exclusions.
This approach works well in practice: insist on a named vendor endorsement when sellers connect via APIs. Require seller COIs before any live listing.
This reduces insurer resistance and can lower premiums. It does not work when sellers are independent processors regulated separately. In those cases risk transfer by indemnity and insurance proof is the main defence.
Indicative premium ranges and key pricing drivers
Premiums depend on turnover, transaction volume, data held, PSP usage and controls. These factors give a starting point for budgeting.
- Micro sellers (turnover under £100k): roughly £200–£1,000 per year for basic cyber and PI cover.
- Small sellers (£100k–£1m): around £800–£5,000 per year.
- Medium sellers (£1m–£10m): commonly £2,500–£15,000 per year.
- Marketplaces: often face larger premiums, from £3,000 to £50,000+ per year.
These are 2024 market indications to help budgeting.
For budgeting, expect a 10–30% premium uplift if marketplaces cannot prove seller MFA and indemnities (2024 underwriter practice).
What drives the price most?
Underwriters weigh the number of sellers, transaction volume and whether PSPs isolate card data. They also check for Cyber Essentials or ISO 27001.
Prior incidents or breaches push premiums up significantly.
Can premiums be reduced?
Yes. Require multi‑factor authentication, segregated API keys and annual COI checks. Ask for Cyber Essentials attestation.
Underwriting discounts usually appear after documented controls exist and three years of clean history.
A short practical note for brokers and teams: maintain records of controls and COIs for underwriting reviews.
Case studies: three UK seller‑caused claims
Real outcomes depend on contracts and insurer interpretation. These anonymised examples show how liability and recovery played out in England.
Case A shows how an account takeover can cause denial of large BI claims when the marketplace lacks seller indemnities. Case B shows API key misuse leading to ICO notification. Case C shows partial insurer recovery after subrogation and seller cooperation.
These studies show the need for seller COIs, clear indemnities and fast incident cooperation to preserve claim recoverability.
What happened in case A: account takeover and BI
A seller account was hijacked and used to place thousands of fraudulent orders. The marketplace suffered payment reversals and business interruption from processing disruption.
Outcome: incident response costs were covered. A large BI claim faced partial denial because the insurer found weak contractual risk transfer to the seller.
What happened in case B: exposed API keys and PII
An API key with broad access allowed scraping of customer names and emails. The ICO opened an inquiry under UK GDPR and the Data Protection Act 2018.
Outcome: regulatory defence costs were paid by the platform policy. Fines may have been outside cover unless the policy allowed regulatory penalties. The seller PI policy was too small to cover the loss.
What happened in case C: fraud, counterfeit goods
A compromised seller account listed counterfeit goods and threatened to release customer data unless paid. The marketplace paid extortion and PR costs.
Outcome: partial recovery from the seller insurer occurred after proving contractual indemnity and seller cooperation with the claims adjuster.
These cases provide a single clear line for incident response teams.
Practical templates: checklist, clause and runbook
Marketplaces should embed these clauses and tools into onboarding and incident processes. Copy and paste the templates below into contracts and operational playbooks.
Seller security checklist
Seller Security Checklist
- Company name: [SELLER NAME]
- Turnover band: [£...]
- KYC verified: Yes / No (document: [ID])
- MFA enforced on seller portal: Yes / No
- API keys segregated per seller: Yes / No
- Payment method: PSP / Direct (name: [PSP])
- PCI DSS scope: In / Out of scope (evidence: [certificate])
- Cyber insurance: Insurer [name], policy number [#], coverage limits [£...], retroactive date [dd/mm/yyyy]
- Annual security attestation: Yes / No (last attestation date: [dd/mm/yyyy])
- Incident notification clause accepted: Yes / No
Model indemnity clause
Indemnity and Insurance
The Seller indemnifies and holds harmless the Marketplace from all losses, claims, damages, fines and expenses arising from the Seller's processing of personal data, security failures, fraudulent acts, counterfeit goods and breaches of statutory obligations. The Seller shall maintain cyber insurance with minimum limits of £[amount] per claim, maintain PI/PD cover and name the Marketplace as an interested party on the certificate of insurance.
The Seller shall notify the Marketplace of any incident within 48 hours and cooperate with investigations and insurers.
Incident response runbook for seller
Incident runbook:
- Initial containment: suspend the seller's access and isolate affected systems.
- Preserve evidence: retain logs, API traces and transaction records.
- Notify internal incident lead and insurers within policy timeframes.
- Communicate to affected customers and regulators as required.
- Cooperate with the seller and insurers during investigation and subrogation.
A quick reminder to keep templates up to date.
Questions marketplaces ask about seller incidents
Does a seller’s insurance protect the marketplace?
Not automatically. The seller's policy may cover the seller's liabilities. The marketplace can still face direct claims or regulatory action if it exercised control or failed to supervise.
Insurers expect contractual indemnities and may require the marketplace to be named as an interested party on the seller's COI.
No. Statutory duties under UK GDPR and consumer law cannot be fully contracted away. Contractual indemnities help commercial recovery and insurer subrogation. They do not remove the platform's immediate exposure to claims or ICO action.
Demand evidence that cardholder data is out of scope for the platform. Ask for tokenisation or PSP handling. Require signed SLAs on fraud handling and quick freeze mechanisms for suspicious payouts.
These items directly influence underwriting decisions and premium levels.
Notify the insurer as soon as possible and within any policy timeframe. The typical timeframe is 48 to 72 hours.
Late notification can prejudice cover and lead to disputes with insurers.
The action plan to reduce seller risk
Start with three firm steps: require seller COIs naming minimum cover and a 48‑hour incident notification term. Enforce MFA and per‑seller API keys. Add a vendor endorsement or named vendor clause in your policy where sellers connect to platform systems.
These steps reduce immediate exposure and improve insurer acceptance.
The error most frequent at this stage is assuming a verbal promise counts. Document every requirement and automate checks at onboarding and annually. Evidence matters at underwriting and on claim.
Keep the seller checklist, the indemnity clause and the runbook ready. Review them with your broker before major expansion.
Who pays if a seller causes a customer data leak?
The platform can be liable if it held the data or controlled access. If the seller held data but contractually indemnified the platform and had adequate insurance, the seller normally pays.
Customers and regulators may still pursue the platform. Insurers decide claims on contract wording, control points and evidence of onboarding.
Not always. The ICO looks at whether the platform took reasonable steps to protect data and vet sellers. The ICO considers control, purpose and safeguards when deciding enforcement under the Data Protection Act 2018 and UK GDPR.
Decision makers should ensure controls, indemnities and insurance are in place before expansion.
