Privacy Policy

1. Introduction

Ironbite ("we", "us", "our") is a food business based in Coventry, United Kingdom. We prepare food and deliver it with our own riders. This policy covers the personal data we handle across:

• Ordering — orders placed on our own app and website, and orders passed to us by the Uber Eats, Deliveroo and Just Eat marketplaces.
• Ironbite Driver — a mobile application used by our delivery riders to start and end a shift, claim the orders they are delivering, and record collection and delivery.
• Ironbite Dashboard — a web application used by managers to run the day: live orders, riders, shifts and aggregate statistics.

It explains what personal data we hold, why, who else sees it, how long we keep it, and your rights under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

2. Who We Are

The data controller responsible for the personal data described in this policy is:

For orders placed through Uber Eats, Deliveroo or Just Eat, those marketplaces are separate controllers of their own customers' data and have their own privacy policies. We are the controller for the order information they pass to us so that we can deliver the food.

3. Customer Data

3.1 What we receive, and from where

What reaches us depends on how the order was placed.

• Our own app and website. We receive your name, the contact telephone number you gave, the delivery address, what you ordered, the amount, and — if you were signed in — the account identifier our own ordering system issued to you. We do not copy your saved address book or your password; those stay in the ordering platform. What we hold against your account itself is described in 3.4 below.
• Uber Eats, Deliveroo and Just Eat. We receive a first name (usually with an initial in place of a surname), the delivery address, any access or door code, what you ordered, the amount, and a telephone number. That telephone number is a masked proxy line operated by the marketplace: it is a shared number that connects a rider to you without giving us your real one. We do not receive your email address from any marketplace.

3.2 What we use it for

• Delivering your order — routing the rider, getting the right bag to the right door, contacting you if something goes wrong, and taking payment at the door where the order is cash on delivery.
• Keeping the record of the sale, which we are required to retain for tax and company-record purposes.
• Understanding our own service in aggregate — how many orders each platform brings, how many come from someone who has ordered before, which postcode districts we serve, which dishes sell, and how long deliveries take. These are counts and averages used to run the kitchen and staff the rota. They are never used to target, profile or contact an individual.

3.3 Our lawful basis

• Legitimate interests (Article 6(1)(f)) — for operating the delivery service and for the aggregate service analytics described above. We have assessed that our interest in running and improving a delivery operation does not override your rights, because the analytics are aggregate, the identifying fields are not copied into them, access is limited to managers, and nothing derived from them is ever used to contact you.
• Performance of a contract (Article 6(1)(b)) — where you order directly from us, processing your address and contact details is necessary to deliver the order you asked for.
• Legal obligation (Article 6(1)(c)) — retaining the transaction record for tax and company-record purposes.

3.4 The customer key, and why it is pseudonymous

To count repeat orders without building customer profiles, each order is tagged with a customer key:

• For orders placed on our own app while signed in, the key is the account identifier our own ordering system already issued.
• For marketplace orders — where there is no identifier to use and every customer shares one proxy telephone line — the key is a one-way cryptographic hash (SHA-256) of the delivery address line and postcode. It cannot be reversed into an address.

A marketplace customer is identified to us only by their delivery address — we hold no name, telephone number or email address against that key.

An address-based key identifies a household, not a person: everyone behind one front door, including a shared house or a block of flats sharing a delivery point, counts as one. We describe it that way in our own reporting and we do not treat it as an individual.

Stored against an address-derived (marketplace) key are counts and dates only: how many orders, which platforms, when the first and most recent order were, and the outward part of the postcode (for example CV1, never the full postcode). No name, telephone number, email address, address line, access code or marketplace customer identifier is stored against it, and the marketplace's own customer identifier is deliberately not used at all.

For a customer with an account on our own app — the account-identifier key described above — we additionally hold the account's name and contact details (email address and/or telephone number) and the delivery addresses used on their orders, alongside their order history. That is used to run and improve the service — answering a question about an order, or resolving a delivery issue — and it is never used for marketing. It is removed, along with the key, on the same retention clock described in Section 8, which now also clears the stored name and contact details and deletes the stored delivery addresses.

We treat this key as personal data. The Information Commissioner's Office is explicit that pseudonymised data remains personal data in the hands of whoever also holds the information needed to reverse it — and we hold the order records in the same database. Pseudonymisation is a safeguard here, not an exemption, which is why the key also carries the access controls and the retention clock described below.

3.5 Who can see customer data

Access is enforced in the database itself, not only in the applications. Managers can see live and historic orders. Riders see only the orders available to them or already claimed by them, they cannot read orders once those are completed, and their advance planning view is masked — it shows the outward postcode district only, with the name, telephone number, address and access code removed. Our aggregate reporting shows counts, opaque internal identifiers and outward postcode districts, never a customer's details.

3.6 We never use customer data for marketing

We do not use customer data for marketing of any kind, and we do not share, sell, rent or otherwise disclose customer data to any third party for marketing purposes. We send no promotional email, SMS or push message to customers. We do not build advertising audiences, we do not upload customer records to any advertising or analytics network, and we do not export customer records to any external business-intelligence tool. This applies to every channel, and it applies absolutely to contact details reaching us through a marketplace: those were given to the marketplace and not to us, so marketing to them would be unlawful under the Privacy and Electronic Communications Regulations whatever any other agreement said.

4. Delivery Rider Data

4.1 Identity and sign-in

We hold a rider's display name, mobile telephone number and a PIN. The telephone number is the sign-in identity; the PIN is stored only as a secure hash and never in readable form. Where a rider is also on the payroll system, we hold the staff identifier that links the two records. Sign-in attempts are recorded for rate-limiting, with the network address stored only as a salted hash, never in the clear.

4.2 Shift and delivery records

We record clock-in and clock-out times, scheduled shifts imported from the payroll rota, which orders a rider claimed, and the times they collected, arrived and delivered. Every one of those actions is written to an audit trail that records who did what and when. This is used to run the day, to pay riders correctly, and to measure delivery performance. When a rider clocks in or out from the Driver app, that clock event carries the rider's location at the time (see §4.3); the payroll system remains the record of hours worked. There are no "batches": a rider claims individual orders, and any grouping shown in the app is a view over those orders rather than a stored assignment.

4.3 Location

The Driver app records a rider's precise location while they are on shift: from when they clock in until they clock out, or until the shift is closed for them, including while the app is in the background. When a rider clocks in, the app also checks their location once to confirm they are at the shop. While the Driver app is open on a rider's screen it may also take an occasional location reading even before they clock in. Riders see an in-app notice before recording ever starts, a persistent notification (Android) or the system location indicator (iOS) whenever recording is on, and can stop it at any time from the app's menu; a rider who stops it clocks in and out on the shop tablet instead. The location trail is deleted from our systems within 30 days, and the clock-in location checks within 90 days; encrypted database backups that include them are themselves deleted as they are superseded. They are used to confirm deliveries are covered, to confirm a rider is at the shop when they clock in, to measure deliveries and to plan staffing; they are not shared with anyone outside Ironbite and the processors in §7, and are never used for marketing. Delivery addresses are converted to map coordinates when an order arrives — that is a property of the order, not a record of where a rider is.

4.4 Notifications

The current system does not send push notifications and does not store a device push token. If notifications are reintroduced, a token will be registered only after the rider grants permission on their device, will be used solely for work alerts, will never be used for marketing, and this policy will be updated first.

4.5 On the rider's device

The Driver app keeps the signed-in session on the device, encrypted with AES-256; the encryption key is held in the operating system's secure keystore. Signing out removes it. Opening navigation to a delivery hands the destination address to whichever maps application the rider chooses on their own device, which is then governed by that application's own privacy policy.

5. Manager Data

Managers sign in to the Dashboard with an email address and password. We store the email address and a securely hashed password, handled by our authentication provider, and we record manager actions — cancelling an order, marking it ready, releasing a rider, ending a shift — in the same audit trail, so that an operational change can always be traced to the person who made it.

6. Lawful Bases in Summary

• Performance of a contract (Article 6(1)(b)) — delivering an order placed with us; engaging and paying riders.
• Legitimate interests (Article 6(1)(f)) — running a delivery operation safely and on time, aggregate service analytics, securing our systems against abuse, record-keeping, and rider location while on shift and while the Driver app is open (measuring deliveries, planning staffing and confirming a rider is at the shop when they clock in; riders are told before it starts and can stop it, the location trail is deleted within 30 days and the clock-in location checks within 90 days). We balance this against the rights of the people concerned and limit what is held accordingly.
• Legal obligation (Article 6(1)(c)) — tax, company and payroll records.
• Consent (Article 6(1)(a)) — device permissions such as notifications. Any such permission can be withdrawn at any time in device settings, without affecting anything processed before.

7. Who We Share Data With

We do not sell personal data, and we share no personal data with anyone for marketing. We use the following service providers, who process data on our instructions:

• Supabase Inc. — the database and authentication behind everything described here. Customer order records, rider records and shift records are stored there.
• Our application hosting platform — runs the Dashboard and the two small services that read marketplace orders. Order data passes through it in the course of being received and displayed.
• Google Maps Platform — used to turn a delivery address into map coordinates, to estimate travel times from those coordinates, and to draw maps in the Dashboard. The full delivery address is sent to Google for geocoding. Customer names, telephone numbers and order contents are not.
• Expo / EAS — builds and distributes the Driver app. It does not receive customer data.
• Our own ordering platform — the app and website customers order from directly. It is the record of a customer's account; we read from it and never write to it.
• Uber Eats, Deliveroo and Just Eat — separate controllers who pass us the order information needed to deliver. Data flows from them to us. We do not send customer data back to them, and we do not merge their customer identifiers with anything.
• Our payroll system — rider names, staff identifiers and rota shifts are read from it so the app knows who is working. Worked-hours records are designed to be written back to it for payroll; that path is currently switched off. No customer data is sent to it.
• Uptime monitoring — a service that receives a signal when a scheduled job succeeds or fails. It receives no personal data.

We will also disclose personal data where we are legally required to, for example in response to a valid request from a law enforcement authority.

8. How Long We Keep Data

• Order records — kept for six years from the end of the relevant accounting period, because the record of a sale is a company and tax record we are required to retain.
• The customer key — anonymised a set number of months after the most recent order for that key, after which the key is replaced with a random value and the counts survive only as statistics that lead back to nobody. For a customer with an account on our own app, the same anonymisation clears the stored name, email address and telephone number, and deletes the delivery addresses we keep against the account to run the service, in the same step. That period is a configurable setting and is currently 12 months. The transaction record above is unaffected; this clock is only on the identity.
• Rider shift and delivery records — kept for the duration of the rider's engagement plus up to 24 months, for payroll, tax and dispute resolution.
• Rider location records — the location trail is deleted from our systems within 30 days, and the location checks taken when a rider clocks in are deleted within 90 days (see §4.3).
• Rider and manager account details — kept while the account is active; removed within 30 days of the account being deleted, except where a payroll or tax record requires otherwise.
• Sign-in attempt records — short-lived, held only to rate-limit abuse.
• Raw messages received from ordering platforms — these are retained while the integrations are being stabilised so that an order can be reconstructed if it fails to arrive correctly. A retention limit for them is being implemented.

9. International Data Transfers

Some of our service providers are based outside the United Kingdom. Where personal data is transferred internationally we rely on the UK adequacy regulations where they apply, and otherwise on the UK International Data Transfer Agreement or the UK Addendum to the Standard Contractual Clauses, together with the transfer risk assessment those require. We only use providers who maintain appropriate technical and organisational security measures.

10. Security

• Row-level security is enforced in the database, so who can read which rows is decided by the database and not only by the application. Riders cannot read completed orders, and their planning view has the identifying fields stripped out.
• Statistics and reporting leave the database only as aggregates, through a small number of manager-only functions.
• Rider PINs are stored as secure hashes. Manager passwords are handled by our authentication provider and never stored by us in readable form.
• The Driver app encrypts the stored session with AES-256, with the key held in the device's secure keystore.
• All data in transit is protected with HTTPS/TLS.
• Every change to an order or a shift is written to an audit trail recording the actor and the time.

11. Your Rights, and How to Use Them

Under the UK GDPR you have the right of access, to rectification, to erasure, to restrict processing, to data portability, to object to processing based on legitimate interests, and to withdraw consent where processing relies on it.

To make a request, email ironbite2023@gmail.com with "Data protection request" in the subject line and tell us what you want. We will respond within one month, as the UK GDPR requires. There is no charge. If a request is complex we may extend that by up to two further months, and we will tell you within the first month if we need to.

So that we can find your records, please include:

• If you ordered on our own app — the email address or telephone number on the account, and roughly when you ordered.
• If you ordered through Uber Eats, Deliveroo or Just Eat — the delivery address and roughly when you ordered. We hold no identifier for you beyond the order itself, so the address is how we locate it. We recompute the same one-way hash from the address you give us to find any customer key derived from it. Note that the marketplace holds its own separate record of you, which only the marketplace can act on.

Erasure. Where you ask us to erase your data we will delete or anonymise the identifying fields we hold — name, telephone number, delivery address and any customer key derived from it. We must keep the underlying record of the transaction itself for the tax and company-record period described in Section 8, but after erasure that record no longer identifies you. We will confirm in writing what was removed and what had to be kept, and why.

We may ask for enough information to be satisfied of your identity before acting on a request, so that we do not disclose one person's data to another.

12. Complaints

If you are unhappy with how we have handled your personal data, please tell us first at ironbite2023@gmail.com so we can put it right. You also have the right to complain to the UK supervisory authority at any time:

13. Changes to This Policy

We update this policy when what we actually do changes — not only when the law does. Material changes affecting riders will be communicated to them before they take effect. The "Last updated" date at the top of this page is the date of the most recent revision.

14. Contact Us

Questions about this policy or about how we handle personal data: