Marketplace GDPR: Controller, Processor, or Joint Controller?

Marketplace GDPR is the question of who decides the purpose of each data flow between you, your sellers, and the buyer, and the answer changes from one flow to the next on exactly the same fields.

This article breaks down:

• Which 5 flows does one marketplace order pass through?
• Which 3 GDPR arrangements can you be in?
• How many order fields does a seller need?
• Who answers an erasure request scattered across sellers?

Key insights

• One delivery address creates two duties in full, yours and the seller's. It does not split in half.
• Ask which flow, never who the controller is. One order passes through five of them and the answer changes four times.
• A seller needs five or six fields to send a parcel. Everything else is on their screen because it was easier to build that way.
• A three-year customer may have bought from forty sellers. When they ask to be erased, the clock runs against you and the data sits elsewhere.
• Your own staff stepping into a seller's account is data processing. It needs limits on what they see, a log, and a log that outlives the argument.

Why does one delivery address create 2 separate duties?

The buyer types in one address. That address lands in your system and in the system of the seller who has to ship the parcel.

Intuition says that if the data is the same, the duty is one and only needs assigning: "ours" or "theirs."

That is not how it works. The duty does not split, it doubles.

You process that address to bring the transaction about, settle it, and handle a dispute. The seller processes it to ship the parcel and to meet duties of their own: documentary, warranty, and tax.

Those are two different purposes, and neither of you sets the other's, while the rules on data protection assign the controller role to whoever decides the purpose.

The practical consequence: one parcel produces two records of processing activities, two legal bases, two retention periods, and two information duties toward the same person.

Two whole ones.

That is why the title asks the wrong question. The useful one reads: for which data flow does who decide the purpose.

Stop looking for a single controller and start mapping flows. The roles change between them on exactly the same fields.

Which 5 flows does one marketplace order pass through?

Take one order and walk it five times, asking only about the purpose.

Fulfilling the order. Usually two separate controllers.

The seller does not act on your instruction. They carry their own duty to issue a document and answer for the goods.

You cannot order them to stop, so they are not processing "on your behalf." This is the position that gets misread most often.

Messages between the seller and the buyer. The channel is yours, the content is theirs.

If you decide that the conversation happens inside your system, which fields are visible, and how long the channel stays open, then you are the one deciding the purpose. The seller is a participant in it.

Returns and complaints. The role follows the decision.

If your team settles the case, then you are the controller of that part. Settling means reading the correspondence, weighing fault, and granting the refund.

If you only pass the case along, the arrangement is different.

The seller's marketing to your customer. A new purpose means a new controller, and it is not you.

A newsletter is not a continuation of shipping a parcel. The test is simple: remove this flow and check whether the order still gets fulfilled.

It does. Guidance from European data protection authorities draws the line explicitly: necessity is assessed objectively, and writing something into a contract does not make it necessary to perform that contract.

Consent you collected is not consent for the seller.

A security incident. This is where roles stop being theory.

Who reports the breach to the supervisory authority is a function of who was the controller of the flow the data leaked from. A processor notifies the controller and stops there.

The controller notifies the authority, and in more serious cases, the people whose data leaked as well. The rules set a short window running from the moment you become aware.

Confirm its length with a lawyer. A map of roles drawn after a leak is late, because the clock is already running.

The same name, address, and phone number went through five flows and changed the owner of the decision four times.

Which 3 GDPR arrangements can a marketplace be in?

A lawyer will name three constructions. What you care about is not the definition but the operational consequence of each.

The most common mistake in this layer is one arrangement for everything. Usually that means a processor agreement with every seller, because that is what is convenient in the paperwork.

A seller who issues their own sales document and answers for the goods themselves is not your contractor in that part, and paper saying otherwise will not change the facts.

Joint control sounds like the safe middle ground, and sometimes it is, but it carries two consequences. It requires an arrangement that splits the responsibilities and names a contact point.

And the heavier one: a joint role is not an equal role, and the customer can still bring a request to either of you. Guidance from the European authorities says so outright.

How many order fields does a marketplace seller need?

Take your order record. Say it carries fourteen fields.

Ask one question of each: will the parcel arrive if I do not pass this field on?

• Name, street, postal code, city, country. Yes. Without these, there is no shipment.
• Phone number. Usually yes, but to the courier and not to the seller. It can travel onto the label and into the carrier's system without ever landing in the panel as a field to copy.
• Email address. Almost never in its real form. This is where the whole game is.
• Company name and identification number. Only on a business order, and only because the seller has to issue a document. On a consumer order, the field is surplus.
• Age or an identity document. Only in categories where the law requires an entitlement to be confirmed. "Restricted and Prohibited Products on a Marketplace: The 3 Gates" covers how those get gated.
• Order history with other sellers, and the data on the remaining cart lines. Never. This is the quietest leak there is: a record built once, for the operator, and then shown to the seller "because it was already there."

In practice, the seller needs five fields, maybe six. The rest sits in the interface not because anyone justified it, but because that was the simpler thing to build.

Masking the contact channel is a separate decision. Instead of the real address, the seller gets a relay address that forwards messages and goes dark once the order closes.

Sixty days after delivery, say. The buyer is not left with a private address sitting in a stranger's database, and you keep the conversation history on your side.

Two things it does not solve. Masking protects the address, and the content travels anyway.

A seller can ask for direct contact or drop in a link to their own store, and plenty of platforms have no validator on outgoing content, so enforcement is reactive. The chapter on sellers pulling customers off the platform describes the phenomenon.

Such channels are often built on ordinary email underneath, which makes them fragile. Changing your sending address without agreeing it with the vendor can take out order communication altogether.

Who answers an erasure request when sellers hold the data?

The customer comes to you, because you are where they bought. The clock runs against you, and the data sits in systems you do not control.

Someone shopping with you for three years may have touched forty sellers. Over email, that is forty threads and no proof that all of them replied.

A register of disclosures at the level of the order. You have to be able to say who received this person's data, which fields, and when.

Not "seller X has access to the panel" but "seller X downloaded order record such and such on that day at that hour."

A machine path for passing the request on and collecting the confirmations. It runs through the interface, with a response time and a status.

The guidance from the European authorities is uncomfortably clear here: a controller has to search all its own systems and pull data back from the entities processing on its instruction, and scattered data is not an excuse. Where the seller is a separate controller, you do not pull data from them, but you do have to pass the request on effectively and show that you did.

Selective erasure, one field at a time. The right to erasure is not absolute.

Some of the data stays, held in place by your own record-keeping duties. You will not settle the scope from this article, but the system has to erase a part and not only everything.

A platform that wipes the whole order record has just broken your books. One that cannot erase anything hands the problem back to you.

Four things go from this into the contract: a seller response time shorter than your own, a duty to confirm it was done, a ban on passing the data further without your knowledge, and erasure once the relationship ends. "Marketplace Seller Agreement and Terms: Which Documents Do You Need?" covers the documents themselves.

What does an operator stepping into a seller's panel require?

An operator stepping into a seller's account to click something through for them is data processing in its own right. You do need the capability.

The assumption that an integrator will do everything for the seller does not survive the first return. It comes with three requirements.

1. Limits per field

Inside a seller's panel, your employee should not see the seller's bank account number or any data not needed for the action they came in to do. A "step in and see everything" mode is not supported.

It is full access under a different name.

2. An audit event for the act of stepping in

Who entered, when, into whose account, and against which case. This is a class of problem where platforms fail notoriously: the permission to enter someone else's account exists, and the entry leaves no trace.

Or the trace stays with the vendor and the operator never gets it. So the question is not "do you log this" but "show me the entry from yesterday's session."

3. Log retention longer than the horizon of a dispute

Arguments about who saw what get settled a year later and later still. A trace kept for a few months, which is what real retention often looks like, is useless by then: you will prove neither that somebody looked nor that nobody did.

Technical isolation of data between sellers belongs to the chapter on security, and the scope of the audit trail to the chapter on audit.

What changes when a marketplace seller sits outside the EU?

The question arises when you take on your first seller established outside the Union. Sending a buyer's data outside the Union needs a basis of its own and contractual safeguards.

The European Commission publishes ready-made model clauses, separate ones for a controller-to-controller arrangement and a controller-to-processor one. The same question returns with your own vendors: hosting, the email tool, the data warehouse.

What does marketplace GDPR change about your data model?

1. The flow map is a design artifact

It is built together with the data model, because it settles which fields travel to the seller and where the masking sits. Ordered after launch, it is only a description of the state you are already in.

2. Seller data is a set separate from buyer data

A different basis, a different retention period, a different circle of recipients. "Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions" describes seller verification, and the two sets should not be mixed.

3. A product recall reaches into order data for a new purpose

That purpose was not in the original flow. "GPSR for Marketplaces: Product Safety, Traceability, and Recalls" carries that thread.

4. The information duty at checkout names the seller

The same piece of information settles liability in "Marketplace Liability: Are You an Intermediary or a Seller?" and consumer rights in "Marketplace Consumer Rights: Who Delivers Them?". If the buyer does not know where their data is going, no arrangement about roles will help.

How do you check marketplace GDPR with a lawyer and a vendor?

1. Questions for your lawyer

Ask with the flow map in hand:

1. For each of the five flows: who is the controller, and where do we have a processor arrangement or joint control? And do our documents reflect that?
2. Which fields from the order record must we pass to the seller, and which are we passing over and above that?
3. Who reports a breach in each arrangement, and what do we require from the seller contractually so that we can make it in time?

2. Questions for your platform vendor

Ask to be shown on screen:

1. Show me the set of fields a seller sees on an order, and the same in the API. What can be turned off without a code change?
2. Is the buyer's email address masked, and what happens when we change our sending domain?
3. Show me a log entry from an operator stepping into a seller's account, and tell me how many months you keep it.
4. What does an erasure and export request look like for a buyer whose orders were handled by forty sellers? And what is left after the erasure?

Which mistakes do operators make about marketplace GDPR?

1. A processor agreement with every seller

Convenient on paper, untrue in fact. The consequence surfaces at the first leak on a seller's side, when it turns out somebody else was supposed to file the report.

2. An order record built once, for the operator, and then shown to the seller

The quietest of these mistakes, because nothing breaks. Nothing breaks until somebody asks why a seller needs a customer's purchase history with their competitors.

3. Marketing consent collected by you and used by the seller

That is processing with no basis on their side, and the complaint lands with you, because your brand is the one in the email.

4. Erasing a customer carried out as deleting their orders

One request and you have a hole in your settlements. The reverse is just as bad: a platform that cannot erase anything leaves you with manual work.

5. Stepping into a seller's account with no trace and no limits on fields

Until the first dispute, it looks like efficient service. In the dispute, you have nothing to show who saw what, and that burden falls on you.

What do you still have to settle yourself about marketplace GDPR?

This guide is a map of mechanisms and data. It carries no legal bases, no deadlines, and no judgment about whether a given duty applies to you.

That depends on the country, the model, and the flow. Confirm it with a data protection lawyer, based on the flow map.

The families of regulation that come up in that conversation:

• The EU rules on the protection of personal data, known in practice as GDPR: roles, legal bases, people's rights, breach notification, and retention.
• The rules on transferring data outside the Union, including standard contractual clauses and the assessment of the legal order in the recipient's country.
• The rules on marketing communication and on tracking users. Separate ones, with a logic of consent all their own.
• The regulations on digital services, known in practice as the DSA, in the part on traceability of sellers.
• National rules on keeping records. They set the floor under everything you are not allowed to erase.

Our claim is narrower than any of those answers and independent of them: a role can be changed with an addendum, and a data flow once designed cannot. If your system sends the seller the buyer's real address and does not know who received what, no contract will fix that.

Summary: What settles your GDPR role on a marketplace?

The flow map, built with the data model rather than after it. It decides which fields reach the seller, where the masking sits, what the register of disclosures records, and who reports a breach.

A role can be changed with an addendum; a data flow once designed cannot.

Ask what an erasure request looks like for a buyer whose orders went through forty sellers. Building a marketplace that has to know which seller received which field, and when? Talk to us about the build.

Frequently asked questions on marketplace GDPR

Is a marketplace a data controller or a processor?

Both, depending on the flow, and the question is which flow rather than which label. Fulfilling an order usually makes you and the seller two separate controllers, because the seller acts on their own duties and not on your instruction.

The message channel is yours. The seller's marketing to your customer is theirs alone.

What customer data can a marketplace send to a seller?

Whatever the parcel needs, and little else. Name and address yes; phone usually to the carrier rather than the seller; email almost never in its real form; company details only on a business order.

Order history with other sellers never travels, and it is the field that most often does.

Who handles an erasure request on a marketplace?

You do, because you are where the customer bought, and the clock runs against you. That means a register of disclosures at the order level, a machine path to pass the request on and collect confirmations, and selective erasure, because record-keeping duties hold parts of the data in place.