GDPR in a Food Co-op: Who Owns the Producer's Sales Data, the Shopper's Address and the Driver's Location Trail

Who is the controller and who is the processor in a food co-op?

In almost every short food supply chain, the co-operative or food hub is the data controller for shoppers, and the software platform is the processor acting on written instructions. Producers are usually neither: they are recipients of a narrow slice of co-op data, or separate controllers only for their own customer relationships.

This matters because the roles decide who answers a subject access request, who notifies the regulator after a breach, and who signs what. If a shopper emails asking for a copy of their data, the co-op answers it. The platform's job is to make that answer producible in minutes rather than by exporting three spreadsheets and hoping nothing was missed. The co-op needs a data processing agreement with the platform under Article 28, and a much shorter, plainer agreement with each producer that spells out what producer users may see and what they may not do with it.

The tricky case is the delivery driver. If the driver is co-op staff, they are simply an authorised user under the co-op's control. If the driver is a self-employed contractor or a third-party courier, they become a separate controller for their own business records and a recipient of shopper addresses for the duration of a route. That distinction changes the contract, not the software, but the software has to make the difference visible: contractor accounts should see less, and for less time.

Co-op as controller: shopper accounts, orders, addresses, payment references, complaints, delivery outcomes.
Platform as processor: hosting, backups, support access, subprocessors, breach notification to the co-op.
Producer as recipient: their own sales lines, their own stock, aggregate demand for their categories, delivery-relevant notes.
Producer as separate controller: only where they collect customer data themselves, for example on-farm sales or their own newsletter.

What can a producer actually see about a shopper?

A producer should see what they need to fulfil and get paid: quantities sold, product mix, timing, and settlement lines. They should not see shopper names, addresses, phone numbers or purchase histories across other producers. The lawful basis for showing more than that rarely exists, and the operational need almost never does.

Producers ask for names for understandable reasons. They want to know who bought the goat cheese so they can thank them, upsell them, or invite them to the farm. In a co-op model the customer relationship belongs to the co-op, and the shopper agreed to buy from the co-op, not to be added to eleven separate farm mailing lists. The clean answer is to keep identity behind the co-op and offer producers what they actually need: unit-level sales, repeat-purchase rates in aggregate, and an opt-in channel where a shopper can choose to follow a specific producer.

There are two exceptions worth designing for. First, direct pickup at the farm: if the shopper collects from the producer, the producer needs a name and an order reference to hand over the right box, and nothing else. Second, quality issues: when a complaint concerns a specific batch, the producer needs the batch and the problem, not the complainant's address. Both are solvable with field-level permissions rather than a blanket "producers can see orders" switch.

Who owns the producer's sales data when they leave the co-op?

Ownership is the wrong word legally, but the practical rule is simple and should be written down before anyone leaves: the producer can export their own sales history, price lists, product descriptions and photos at any time; the co-op keeps the transaction records it needs for accounting and food safety law; and neither party takes the shopper list.

Departure is when unwritten assumptions turn into disputes. A grower who spent three seasons building a following expects to leave with something. A co-op that funded the storefront, the deliveries and the customer acquisition expects the customer base to stay. Both are partly right, which is why the exit clause needs to be in the producer agreement on day one, not negotiated in a bad mood on the way out. Spell out the export format, the notice period, and what happens to product photos the co-op paid a photographer to shoot.

Retention runs on a different clock from goodwill. Invoices and settlement records are typically kept for the statutory accounting period in the relevant member state, often five to eleven years. Traceability records for batch and lot data follow food law, not GDPR minimisation, and cannot simply be deleted because a producer left. A shopper's erasure request does not erase the invoice; it erases the marketing profile, the saved address book and the account, while the financial record survives in a pseudonymised or legally required form.

Producer keeps: their sales lines, their catalogue content, their own uploaded media, their payout history.
Co-op keeps: invoices, settlement runs, VAT records, batch traceability, complaint logs.
Nobody takes: the shopper list, shopper addresses, or the co-op's aggregated demand data.
Written before onboarding: export format, notice period, media licensing, and who pays for the export.

How long should you keep a driver's location trail?

Keep raw GPS breadcrumbs for days, not years. A defensible pattern is high-resolution location for the length of the route plus a short dispute window of roughly 7 to 30 days, then reduce to the facts that matter: delivery timestamps, stop outcomes, and distance totals. Continuous tracking outside working hours has no lawful basis.

Location data on a delivery app is genuinely useful. It answers "where is my box", it settles the argument about whether the van reached the address, and it makes route planning honest. It is also employee monitoring, which in most EU member states triggers additional national employment rules and, where applicable, works council or union consultation. Legitimate interest can support route-level tracking with a documented balancing test. It does not support keeping a year of second-by-second traces just because storage is cheap.

The practical controls are unglamorous and effective: tracking starts when the driver begins a shift and stops when the shift ends, with a visible indicator in the app so the driver always knows the state. Proof-of-delivery photos should frame the doorstep, not the customer, and should expire on the same clock as the location trail. Aggregated route efficiency figures can persist indefinitely because they no longer identify anyone, which is exactly why they are the right thing to keep.

Data minimisation in practice: what a co-op should stop collecting

Most co-ops collect fields nobody uses. The fastest privacy win is a column audit: take every field in the shopper, producer and delivery records, name the person who reads it and the decision it drives, and delete the ones with no answer. Fewer fields means less to secure, less to export, and less to lose.

Common offenders in local food operations include date of birth collected "for verification", full delivery instructions retained forever rather than per order, free-text notes fields that accumulate sensitive detail such as "leave at the back, resident has mobility problems", and phone numbers copied into a driver's personal messaging app where the co-op has no control at all. That last one is the most common informal breach in short food supply chains, and it happens because the software did not offer a masked call or in-app message.

Special categories deserve particular care. Allergy and dietary information looks like a nice product feature and is health data under Article 9. If you collect it, collect it with explicit consent, keep it attached to the order rather than the profile where possible, and never expose it to a producer who only needs to know that a box excludes gluten. Similarly, a note that a shopper is a religious-holiday customer or a member of a charity food scheme can reveal beliefs or social status. If the operation does not need it to deliver food, it should not be in the database.

Audit each field: who reads it, which decision it drives, how long it needs to live.
Replace stored phone numbers in driver chats with in-app masked contact.
Attach delivery instructions to the order, not permanently to the shopper profile.
Treat allergy and dietary data as Article 9 health data with explicit consent and tight access.
Set a retention period per record type and enforce it automatically, not by an annual cleanup someone forgets.

The ethical limits of aggregated demand data and AI features

Aggregated demand data is the co-op's most valuable asset and its easiest ethical mistake. Anonymised category trends can fairly guide planting advice, route planning and range decisions. Using the same data to undercut a producer's price, to clone a top seller under a co-op label, or to score individual shoppers for pricing crosses from analytics into extraction.

The reason to draw the line explicitly is that a co-op holds a structural information advantage. It sees all demand; each producer sees only their own sales. That asymmetry is fine when it is used to help the whole chain plan, and corrosive when it is used to bargain harder against the weakest party at the table. A short written policy helps: state which aggregates producers get to see for free, state that the co-op will not use producer-level margin data to source a competing supplier for the same product without telling the producer, and state what happens if the co-op ever launches its own label.

AI features raise the same question with a new surface. Demand forecasting, box recommendations and automatic reordering are legitimate uses of historical data and mostly do not require personal data at all once aggregated. Individual profiling is different. Automated decisions that materially affect a person, such as refusing a delivery slot or applying different prices based on behavioural scoring, engage Article 22 and need human involvement plus an explanation. Under the EU AI Act, most co-op use cases sit in the minimal-risk band, but transparency obligations still apply when a shopper is talking to a chatbot rather than a person. The safe default is to build forecasting on anonymised aggregates, keep humans in charge of anything that affects an individual, and tell people plainly which is which.

A one-page governance checklist for a co-op with four apps

If you run admin, shopper, producer and delivery apps on one data model, governance means writing down, per role, what each app can read, what it can write, and how long the data lives. That single table is more useful than a long policy document, because it is the thing developers and administrators actually implement and audit.

Build it in that order, then test it by trying to answer three questions with a stopwatch: can you produce everything you hold on one shopper in under an hour, can you delete an account without breaking the settlement history, and can you tell a producer exactly what the co-op sees that they do not. If any answer is no, the gap is in the data model, not in the paperwork.

A record of processing activities listing every category of data, purpose, lawful basis and retention period.
A data processing agreement with the platform, plus a current list of subprocessors and hosting locations.
A short producer data agreement covering visibility, export on exit, and use of catalogue content.
Role-based field-level permissions, with contractor drivers on a tighter profile than staff.
Automated retention jobs per record type, including location trails and proof-of-delivery photos.
A tested subject access and erasure procedure that preserves statutory invoice and traceability records.
A breach playbook with named roles, a 72-hour clock, and a template notification to the co-op's members.
A plain-language privacy notice a shopper can read in two minutes, published where they place the order.

Key Takeaways

The co-op is the controller for shopper data, the platform is the processor, and producers are usually recipients of a narrow slice rather than joint controllers.
Producers need quantities, timing and settlement lines, not shopper names and addresses. Identity stays behind the co-op unless the shopper opts in or collects at the farm.
Write the exit rules before onboarding: producers export their own sales and catalogue, the co-op keeps invoices and traceability, nobody takes the shopper list.
Driver location trails should live for a short dispute window and then reduce to timestamps and distances. Tracking outside shift hours has no lawful basis.
Aggregated demand data is fair game for planning and unfair when used to undercut producers or price individual shoppers. Keep AI features on anonymised aggregates and humans on decisions that affect people.

The permission boundaries described here are the same ones we work through when designing four apps that feel like one, where admin, shopper, producer and delivery roles share a data model without sharing a view of it.

Frequently Asked Questions

Does a small food co-op really need a DPO under GDPR?

Usually not. A designated data protection officer is mandatory only for public authorities, for large-scale systematic monitoring, or for large-scale processing of special category data. A co-op selling vegetable boxes to a few thousand households normally falls outside those triggers, but it still needs a named person accountable for privacy, a record of processing activities and a working response procedure. If you collect detailed allergy or health data at scale, reassess.

Can a food co-op share shopper data with producers if the shopper agrees?

Yes, if the consent is genuinely specific, freely given and separable from placing the order. That means a shopper can tick a box to follow a specific producer or receive their updates without losing access to the shop. Bundling producer data-sharing into the checkout terms is not valid consent, and consent has to be as easy to withdraw as it was to give.

What should a co-op do in the first 24 hours after a data breach?

Contain the access, record the time you became aware, and assess what data and how many people are affected. If there is a risk to individuals' rights and freedoms, notify the supervisory authority within 72 hours of becoming aware, even if the assessment is incomplete. If the risk is high, notify the affected shoppers directly in plain language, telling them what happened and what to do about it.

Is WhatsApp acceptable for coordinating drivers and producers in a co-op?

It is common and it is a governance problem. Shopper names, addresses and phone numbers pasted into a consumer messaging app leave the co-op's control, sit on personal devices, and cannot be deleted, exported or audited when someone makes a subject access request. If group chat is unavoidable, keep personal data out of it and move the actual delivery details into a system with roles, logs and retention rules.

How long does a food co-op have to keep traceability records, and does erasure override that?

Food traceability records follow food law rather than GDPR, and general EU rules point to keeping one-step-back, one-step-forward records for a period tied to the product's shelf life, with member state specifics on top. A shopper's erasure request does not delete those records or the statutory invoice. It removes the account, marketing profile and unnecessary personal detail while the legally required record stays, ideally pseudonymised.