By business type

Privacy Policy Generator for marketplaces

Written for two-sided platforms: joint controllership, seller data, DSA duties and payouts.

Generate your privacy policy Read the privacy policy guide

A marketplace privacy policy has to explain a three-way relationship in a way a buyer can follow: what you hold, what the seller receives, and who is responsible for what afterwards. Getting the role allocation right is the whole document.

Marketplaces have a role problem that single-sided businesses do not. For your own account and platform data you are a controller. For data flowing between buyer and seller you may be a joint controller, a processor, or an independent controller depending on the specific flow - and Article 26 requires joint controllers to have an arrangement and to make its essence available to individuals.

The Digital Services Act added a substantial layer for marketplaces serving the EU: trader traceability, notice-and-action, statements of reasons for removals, internal complaint handling, and a ban on dark patterns in interface design. These are platform obligations, not seller obligations, and they cannot be delegated.

Payouts introduce a third dimension. Splitting payments between platform and seller usually means identity verification on sellers, tax reporting obligations, and a payments partner who becomes a significant party in the data chain.

What a privacy policy for an online marketplace has to cover

Your role per data flow - controller, joint controller or processor - stated explicitly
What buyer data is shared with sellers, and that sellers become controllers for fulfilment
The essence of any Article 26 joint controller arrangement
Seller verification data, payouts and tax reporting
On-platform messaging, moderation records and their retention

How an online marketplace actually moves personal data

Buyer data shared with sellers

Name, delivery address and order contents passed to a seller who then becomes a controller in their own right for fulfilment.

Seller onboarding and verification

Identity documents, bank details and tax identifiers collected for verification and reporting.

Messaging between users

On-platform messages are personal data you host, with moderation, retention and disclosure questions attached.

Reviews and ratings

Published personal data about identifiable sellers and buyers, with rights to object and correct.

Payouts and tax reporting

Seller earnings data reported to tax authorities under marketplace reporting rules.

Moderation and enforcement records

Evidence of removals and suspensions, retained to support the statements of reasons the DSA requires.

Third parties the draft will ask you about

Stripe Connect or Adyen for Platforms · identity verification vendors · AWS or Google Cloud · Zendesk · trust and safety tooling · tax reporting providers

The rules that apply

GDPR Article 26 joint controllership

Where you and sellers jointly determine purposes and means, you need an arrangement and must make its essence available to data subjects.

Digital Services Act

Trader traceability, notice-and-action, statements of reasons, internal complaints, and interface design rules for marketplaces serving the EU.

Seller identity and tax reporting

Marketplace reporting rules require collection and reporting of seller identity and income data in many jurisdictions.

Consumer law allocation

Who the consumer contracts with - platform or seller - determines who owes cancellation rights and remedies.

Payments and KYC on sellers

Split payments usually trigger identity verification duties through the payments partner.

What the generated privacy policy contains

Identity and contact details of the controller
Your legal entity, trading name, registered address and a working contact route - plus a representative or DPO where one is required.
Categories of personal data and their sources
What you collect directly, what you observe automatically, and what you receive from third parties such as payment providers or ad platforms.
Purposes and lawful basis, purpose by purpose
A table that pairs each processing purpose with its lawful basis rather than listing all six bases and hoping one fits.
Recipients and sub-processors
The categories of recipient, and for the ones that matter to users - payment, hosting, analytics, support - the named provider.
International transfers and their safeguards
Where data leaves its home jurisdiction, and the mechanism relied on: adequacy, standard contractual clauses, the UK addendum or IDTA.
Retention periods per data category
Concrete periods or the criteria used to set them, which is what regulators ask for first when a complaint lands.
Rights and how to exercise them
Access, rectification, erasure, portability, objection and restriction, with the actual route to make a request and the deadline you work to.
Complaints and supervisory authority
The regulator a user can escalate to, named, with a link - not a generic "your local authority".

The marketplace document set

Map each data flow to a role
Controller, joint controller or processor - per flow, not per relationship.
Put an Article 26 arrangement in the seller terms
And publish its essence where buyers can find it.
Build DSA notice-and-action
Reporting route, statements of reasons, internal complaints, and record-keeping.
Separate buyer terms from seller terms
Two audiences, two sets of obligations, two documents.
Minimise what sellers receive
And say what they receive in the buyer-facing policy.
Document the payouts and reporting chain
Including the payments partner’s own role and the tax reporting obligation.

Where this usually goes wrong

No Article 26 arrangement with sellers

Where joint controllership genuinely exists, the arrangement is mandatory and its essence has to be available to users.

Treating sellers as processors when they are controllers

A seller fulfilling an order decides its own purposes. Calling them a processor misdescribes the relationship and the contract.

Missing DSA notice-and-action machinery

It is a platform obligation with its own procedural requirements, including statements of reasons and internal appeals.

Dark patterns in the interface

Explicitly prohibited by the DSA for marketplaces, and separately actionable under consumer law.

Buyer data over-shared with sellers

Sellers need what fulfilment requires, not the full customer record.

Unclear contracting party

If a consumer cannot tell whether they contracted with you or a seller, the cancellation and remedy obligations land on you.

Frequently asked questions

Is a marketplace a controller or a processor?

Usually a controller for platform data and, for some flows, a joint controller with sellers. Sellers are typically independent controllers for fulfilment. The right answer is per data flow rather than per relationship.

What does the DSA require of marketplaces?

Trader traceability, a notice-and-action mechanism, statements of reasons for moderation decisions, an internal complaint-handling system, and interface design free of dark patterns.

Do I need separate terms for buyers and sellers?

Yes. They have different obligations, different rights and different commercial terms, and merging them produces a document that is unclear to both.

How much buyer data should sellers receive?

What fulfilment requires and no more. Over-sharing is a minimisation failure and increases your exposure when a seller mishandles it.

Is a privacy policy legally required?

If you process personal data, in almost every market yes. GDPR and UK GDPR require the disclosure at the point of collection, CCPA/CPRA requires a notice at collection plus an annually reviewed policy, and app stores and payment processors require a public policy URL before they will list or onboard you.

Can I copy another company’s privacy policy?

It is both a copyright problem and a compliance problem. A copied policy describes someone else’s data flows, processors and retention periods, so it is inaccurate the moment you publish it - and an inaccurate transparency notice is itself a breach of GDPR Article 13.

How often does a privacy policy need updating?

Whenever your processing changes - a new analytics tool, a new payment provider, a new market - and as a backstop, review it annually. CPRA makes the twelve-month review explicit.

Does PolicifyAI give legal advice?

No. PolicifyAI is a technology provider, not a law firm. The output is a structured, jurisdiction-aware draft that a qualified adviser should review before you rely on it.