Who Owns the Data in a Food Co-op? Access Rules, Roles and GDPR Across Four Apps and 40 Producers

Who actually owns shopper data in a food co-op?

The co-operative, as the legal entity running the storefront, is the data controller for shopper accounts and order history. Producers and drivers see only the slices they need to fulfil an order. Under GDPR the shopper does not "own" the data in a property sense, but holds rights over it: access, correction, portability and erasure.

This matters because co-ops are usually member-owned, and members reasonably assume that anything the co-op holds is collectively theirs. It is not. If 40 producers are members of the co-operative, that does not give any one of them a right to browse the customer list. The co-op decides why and how personal data is processed, so the co-op carries the obligations and the liability, and the platform vendor processes that data on the co-op's written instructions.

The practical test is simple. Ask who would receive the complaint if a shopper's address leaked. It would be the co-operative, not the grower who packed the carrots and not the software vendor. That answer tells you where governance has to live: in the co-op's own policies, enforced by the platform's permission model rather than by trust and good intentions.

• Co-operative: data controller for shopper accounts, orders, payments and delivery records
• Platform vendor: data processor, acting on documented instructions under a data processing agreement
• Producer: sees order lines for their own goods, plus whatever the co-op explicitly discloses
• Driver: sees delivery-window details for stops on the assigned route, nothing before or after
• Shopper: data subject, with rights of access, rectification, portability, objection and erasure

What can a producer see, and what must stay hidden?

A producer should see everything about their own goods and money, and nothing about anyone else's. That means their own order lines, stock movements, unit prices, commission deductions and payout statements. It excludes another producer's volumes, margins or payouts, and it usually excludes shopper names and addresses entirely.

Producer-to-producer confidentiality is the rule co-ops most often get wrong, because early on everyone works from one shared spreadsheet and nobody minds. At 40 producers it stops being harmless. A grower who can see that a neighbour sold three times as many courgettes at a better unit price will either undercut them or leave. Aggregate views are fine and useful, such as total co-op sales this month or category-level demand, as long as they cannot be reverse-engineered into a single competitor's figures. If only two producers sell honey, a "honey category total" is not anonymous.

Shopper identity is the second boundary. A producer packing 14 boxes needs a pick list with quantities and box identifiers, not 14 names and street addresses. Some co-ops choose to include a first name on a note card for a personal touch, which is a legitimate choice, but it should be a documented decision with a stated purpose, not an accident of how the pick list was built.

What should a delivery driver see about a customer?

A driver needs the delivery address, a contact name, a phone number for the last 200 metres, access notes such as a gate code or buzzer, and the box identifiers for that stop. They should not see order contents, prices, payment details, past orders or any address outside their assigned route, and access should expire once the route closes.

Driver access is time-boxed rather than permanent, and that distinction does what a privacy policy alone cannot. A driver who left the co-op six months ago should not be able to open the app and pull up a street's worth of addresses. Route-scoped, day-scoped visibility keeps exposure proportionate to the job.

The awkward cases are worth deciding in advance rather than in the van. What happens when a driver takes a photo as proof of delivery and the photo includes a house number, or a child, or an open doorway? What happens when a customer asks the driver to leave the box with a neighbour, creating a record of an address the co-op never collected? Write the rule down: proof-of-delivery photos show the box and the doorstep only, are retained for a defined window tied to dispute resolution, and are deleted after it.

How do the four roles map onto GDPR controller and processor duties?

The co-operative is the controller. The software vendor is a processor bound by a data processing agreement. Producers and drivers are usually acting within the controller's organisation rather than as separate controllers, but a producer who takes a shopper's contact details for their own direct marketing becomes an independent controller for that new purpose and needs their own legal basis.

Getting the lawful basis right for each processing purpose keeps the rest of the governance simple. Fulfilling an order runs on contract necessity, because you cannot deliver a box without an address. Invoicing and food safety records run on legal obligation, which is also what justifies keeping traceability data after a shopper deletes their account. Newsletters and marketing run on consent, which is separate, revocable and must not be bundled into checkout. Fraud checks and platform security typically run on legitimate interest, documented in a balancing assessment.

The distinction becomes concrete during an erasure request. A shopper asking to be forgotten does not erase the invoice a co-op is legally required to keep, nor the batch record linking a crate of lettuce to a grower. What gets deleted is the account, the contact details, the marketing profile and the delivery notes. What survives, in pseudonymised or legally-mandated form, is the accounting and traceability trail. Say this in your privacy notice before anyone has to ask.

Building the access matrix: a practical governance checklist for a co-op

Write down, field by field, which of the four roles can read it, write it and export it. That single table is the backbone of your governance, because it turns vague promises into something you can configure, audit and hand to a member who asks what the co-op knows about them.

The exercise takes an afternoon and surfaces disagreements that would otherwise appear during a dispute. Most co-ops discover two or three fields where nobody agrees, typically shopper phone numbers, producer unit prices and delivery photos. Settle those in a members' meeting and record the decision. Then check that the platform can actually enforce it, because a governance policy that relies on people not clicking the wrong export button is not a control.

Retention is the other half. Decide how long each category lives: order and delivery records for the period your accounting rules require, traceability records for the shelf-life-plus-margin window your food safety regime requires, marketing consents until withdrawn, driver location data for days rather than years. Then run one deletion job on a schedule rather than promising to tidy up later.

• List every data field the platform holds, grouped by shopper, producer, order, delivery and payment
• Assign read, write and export permissions per role for each field, and note the lawful basis
• Define retention periods per category, plus what survives an erasure request and why
• Sign a data processing agreement with the platform vendor, and list any sub-processors such as payment or mapping providers
• Decide the breach procedure: who is notified, who assesses, and who files with the supervisory authority within 72 hours
• Review the matrix annually and whenever a new role, integration or export feature is added

Where governance breaks in practice, and how software prevents it

Most co-op data incidents are not hacks. They are spreadsheet exports emailed to a producer, a shared admin login used by four volunteers, a WhatsApp group with customer phone numbers in it, and an ex-driver whose account was never disabled. Role-based accounts, scoped views and audit logs remove the need for those workarounds.

The pattern is consistent: people export data because the system will not show them what they need in the shape they need it. A producer asks for the customer list because they want to know which villages to grow for, when what they actually need is an anonymised demand-by-postcode view. An administrator mails a spreadsheet because generating a per-producer payout statement is easier in Excel than in the tool. Fix the underlying view and the risky export stops happening on its own.

An audit trail closes the loop. Knowing who viewed which shopper record, who changed a price, and who exported what, with timestamps, converts an argument into a lookup. That is also the evidence a supervisory authority will ask for if something goes wrong. Plodie's four-role architecture is built around exactly these boundaries, with administrators, shoppers, producers and drivers each working from the same underlying data model but seeing only the fields their job requires.

Key Takeaways

• The co-operative is the GDPR data controller for shopper data; the platform vendor is a processor, and producers and drivers only see scoped slices of it.
• Producer-to-producer confidentiality is the boundary co-ops break first: nobody should see another grower's volumes, prices or payouts.
• Driver access should be route-scoped and time-boxed, covering address, contact and access notes, never order contents or payment data.
• Erasure requests delete accounts and contact details, but accounting and food traceability records survive under legal obligation. Say so in the privacy notice.
• Build a field-by-field access matrix with retention periods, then enforce it in software rather than through trust and manual restraint.

For the interface side of these same role boundaries, see how we design four apps that feel like one, covering the shared data model behind the administrator, shopper, producer and delivery views.

Frequently Asked Questions

Does a small food co-op really need a GDPR data processing agreement with its software provider?

Yes. If a vendor stores or handles personal data on your behalf, GDPR requires a written processing agreement regardless of how small the co-op is. There is no volume threshold that exempts you. The agreement should name sub-processors such as payment gateways, mapping services and email providers, and state where data is hosted.

Can producers in a co-op contact customers directly to sell to them?

Only if the customer has given consent for that specific purpose, and the producer then becomes an independent data controller with their own obligations. Passing a co-op customer list to a producer for direct marketing without consent is a common and serious breach. A safer route is co-op-branded messaging where shoppers opt in to hear from named producers.

What happens to co-op data if a producer leaves or the platform contract ends?

Producers should be able to export their own product, order and payout history in a machine-readable format, and their access to co-op data should be revoked on the leaving date. On contract exit, the processing agreement should oblige the vendor to return or delete all personal data within an agreed window and to confirm deletion in writing.

Do we need a Data Protection Officer for a 40-producer food co-op?

Usually no. A DPO is mandatory only for public authorities or organisations whose core activity involves large-scale systematic monitoring or large-scale processing of special category data. A typical local food co-op meets none of those tests, but you should still name one person as the accountable point of contact for data requests and breaches.

How long should a food co-op keep delivery photos and driver location data?

Keep proof-of-delivery photos only as long as your dispute window requires, commonly a few weeks to a couple of months, then delete them automatically. Driver location data used for live routing should be measured in days, not years. Anything retained longer needs a documented purpose, because "it might be useful" is not a lawful basis.

Sources

• pmc.ncbi.nlm.nih.gov
• commission.europa.eu
• dataprotection.ie
• accountablehq.com
• trustarc.com