Data Processing Agreement
Version 2026-11-14. Last updated 14 November 2026.
1. What this agreement is
This Data Processing Agreement forms part of the Own Dine Terms of Service between you and Own Dine Ltd, a company registered in England and Wales, company number 17493501, whose registered office is Office 10465, 321-323 High Road, Chadwell Heath, Essex RM6 6AX. It applies whenever we process personal data on your behalf. You can contact us about anything in it at hello@owndine.com.
- You are the controller. Your customers' personal data is yours. You decide why it is collected and what happens to it.
- We are your processor. We handle it only to run the Own Dine service for you.
- Where this agreement and the Terms of Service disagree about personal data, this agreement wins.
- Words like "personal data", "processing", "controller" and "processor" have the meanings given in the UK GDPR.
This agreement is version 2026-11-14. Every version carries its date, and when you accept it we record which version you accepted.
2. Our own, separate role
For some things we are the controller, not your processor, and this agreement does not cover them. They are covered by our privacy policy. They are:
- your business's own details, and your staff's accounts and sign-in records;
- billing, invoices and payment records;
- our support records and audit logs about how your account was used;
- anybody who contacts us about becoming an Own Dine customer.
3. What we process and why
Schedule 1 sets out the subject matter and duration of the processing, what we do and why, the types of personal data and the categories of people it is about, as Article 28(3) requires.
4. We act only on your instructions
We process your customers' personal data only to provide Own Dine to you and only on your instructions.
Your instructions are: these terms, this agreement, Schedule 1, and the settings you choose in the Hub. Your settings are instructions — switching on delivery, setting an area, turning on marketing consent, choosing who gets order emails.
We will tell you if we think an instruction of yours breaks data protection law, and we may pause that processing until it is resolved.
We will never:
- market to your customers on our own behalf, or promote Own Dine or another restaurant to them;
- sell, rent or share your customer data with anybody for their own purposes;
- use your customer data to train an artificial-intelligence model;
- combine your customers with another restaurant's.
5. Confidentiality
Everybody who can see your customers' personal data is under a duty of confidence, whether they are employed by us, contracted to us, or helping us run the service.
Own Dine is a small business. Today the people with access are listed in Schedule 3.
6. Security
We take appropriate technical and organisational measures to keep your customers' personal data secure, taking account of the risk. They are described in Schedule 2.
We may change a measure for an equally good or better one. We will not reduce the overall level of protection.
7. Sub-processors
You give us general authorisation to use the sub-processors listed in Schedule 3.
- If we want to add or replace one, we will tell you at least 30 days beforehand.
- If you object on reasonable data protection grounds, tell us within that period and we will try to find another way. If we cannot, you may cancel without penalty — including before any notice period in the Terms of Service would otherwise allow.
- We remain responsible to you for what our sub-processors do with your data, and each is under a written contract imposing obligations equivalent to these.
8. Helping you with your customers' rights
Your customers' rights are yours to honour — you are their controller. We will help you do it.
- If a customer asks us directly, we will not answer for you. We will tell them to contact you and tell you it happened.
- We will give you what you need to answer a request about access, correction, deletion, portability or objection.
- Deletion and a copy of a customer's data are both buttons in the Hub, available to the Owner of the account. Correction is the ordinary editing you already do.
- Every erasure is written to the append-only audit log, so you can show you honoured a request.
- We do not charge you for reasonable help of this kind.
9. Breaches, and other help you are entitled to
- If there is a personal data breach affecting your customers' data, we will tell you without undue delay after becoming aware of it, with what we know and what we are doing.
- Reporting a breach to the ICO, and telling your customers, is yours to decide — you are the controller. We will give you what you need to do it.
- We will help you with a data protection impact assessment or a consultation with the ICO if one is needed.
10. When you leave
When your account ends, you choose: we give you an export of your customers' data, or we delete it. Tell us which within 30 days of your account ending.
If you tell us nothing, we delete it after 90 days.
We may keep personal data for longer where the law requires it — for example the financial record of an order, which we keep for tax purposes with the customer's name, address and phone number removed.
Backups are the exception, honestly stated. Deleting data from Own Dine does not reach into backups already taken. Those are encrypted, and each copy ages out within a year — daily copies are kept for 30 days and monthly copies for 365.
11. Audits and information
You can ask us for the information you need to satisfy yourself we are meeting this agreement, and we will give it to you.
Own Dine is a small business, and we will be straightforward about what that means: we do not hold an ISO 27001 certificate or a SOC 2 report, and we are not going to pretend otherwise. What we can do is answer your questions directly, describe how the system is built, and show you our security measures.
If you need a formal audit, we will agree a reasonable time and scope with you. You cover your own costs, and ours if the audit is more than once a year or goes beyond what is proportionate.
12. Sending data outside the UK
Your customers' personal data is held in the United Kingdom and the European Economic Area: our server is in Germany, and our email and our off-site backup are in the United Kingdom.
The one exception is card payments, which are handled by Stripe. Stripe operates in the UK, the EU and the United States under its own terms.
Where a sub-processor is outside the UK and the EEA, we rely on UK adequacy regulations, the International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses, and we will tell you which on request.
13. Liability
Each of us is responsible for our own breach of this agreement. If we break it, we are liable to you for the loss that follows; if you break it, you are liable to us.
Where a fine or a claim is shared. If a regulator fines us, or somebody brings a claim against us, because of something you did or told us to do, you will cover us for it. If it happens because of something we did, we will cover you. Where both of us contributed, each of us pays the share that reflects our own responsibility.
Your instructions. We are not liable for loss caused by following an instruction of yours, provided we told you if we thought it broke data protection law (§4).
The limit. Our total liability under this agreement is limited to the greater of (a) the subscription fees you paid us in the twelve months before the claim, and (b) £500 — the same limit as §17 of the Terms of Service, and the two share one limit rather than each having its own.
What is not limited. Nothing here limits either of us for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be limited.
One thing worth saying plainly. A serious data breach is the one event that could cost far more than this limit, and you should decide whether that risk is acceptable to you before you sign. We would rather say so than have you discover it in a dispute.
SCHEDULE 1 — What we process
Subject matter. Running the Own Dine ordering and table-booking service for your restaurant.
Duration. For as long as you have an Own Dine account, plus the periods in §10.
Nature and purpose. Taking and showing your customers' orders and table bookings; sending them confirmations; printing kitchen and bag tickets; letting you contact a customer about their order; recording marketing consent; and keeping the financial record of an order.
Types of personal data
| Your customers | Name, phone number, email address, delivery address, order and booking history, what they spent, notes they add to an order (which may include an allergy), the allergy declaration itself, marketing consent and the exact wording they were shown, the fact that they confirmed being 18 or over on an order containing alcohol, the IP address recorded with a consent answer, and copies of the emails we sent them about that order or booking |
|---|---|
| Your staff | Not covered by this agreement — see §2. We are the controller for their accounts |
Categories of data subject. The members of the public who order food from you or book a table with you through Own Dine.
Special category data. We do not ask for any. But a customer may type an allergy or a medical reason into a note on an order, and that can be health data. We treat order notes as capable of containing it. You should not ask customers for health information in a free-text box, and we do not provide a field for it.
Where it is held. On Own Dine's server in a Contabo data centre in Germany, in Contabo's own virtual-machine backups of that server, in the encrypted nightly backup described in §10 — stored in Microsoft's UK data centres — and with the other sub-processors in Schedule 3.
SCHEDULE 2 — Security measures
This schedule describes the measures actually in place, not a list of good practices.
Keeping restaurants apart
- Each restaurant's data is separated in the database itself, not only in application code. Queries run through a tenant wrapper, and a migration enforces it. A bug in a screen cannot show one restaurant another's customers.
- A customer who orders from two Own Dine restaurants exists as two unconnected records.
Access
- Passwords and staff PINs are stored as Argon2id hashes, never in a readable form.
- Session tokens and one-time links (password resets, invitations) are stored only as SHA-256 hashes; the readable value exists only in the email.
- Staff have roles — Owner, Manager, Staff — and see only what their role allows.
- Everything that matters is recorded in an append-only audit log, and the database enforces that: the application's own database user has permission to insert and no permission to update or delete. Nothing in the log can be quietly changed afterwards, including by us.
The service
- All traffic is over HTTPS, with security headers set at both the web server and the application.
- Credentials are never in environment variables or
.envfiles. They are read from a restricted folder on the server. - No third-party fonts, analytics or telemetry. Typefaces are self-hosted and the framework's telemetry is off, specifically so that your customers' IP addresses are not sent to anybody.
- Card details never reach our server. They go directly to the payment provider inside its own secure frame.
Backups
- The database is backed up on the server, and a full encrypted archive is sent off the premises every night, to two UK data centres in different parts of the country.
- The archive is encrypted before it leaves, with a key this server does not hold and cannot produce. Only the ciphertext is ever served.
- A failed backup run fails closed — it keeps yesterday's archive, destroys the working plaintext, and raises an alert.
- Copies age out within a year — daily for 30 days, monthly for 365.
Getting rid of data
- Personal details are removed automatically 24 months after a customer's last order, by a nightly job. It anonymises rather than deletes: the dishes, the dates and the money survive so your VAT records stay complete, and the person disappears from them.
- It reaches the awkward places too, not just the obvious columns — the allergy declaration and notes, free text against a dish, bookings, the IP on a consent record, and copies of emails sent to that diner.
- You can erase one customer on request, at once, from the Hub.
- Every erasure is written to the append-only audit log, so you can show you honoured a request.
- Where the sweep deliberately stops: records of a restaurant accepting these documents are never swept. The email on one is the evidence of who agreed, and a contract record the relying party can quietly alter is worth nothing. The database enforces it — the sweep's own role has no UPDATE on that table.
What we do not do
- The server's disks are not encrypted at rest, and the database has no transparent encryption. Protection rests on physical and operating-system access control, together with the fact that the copy held off the premises is encrypted.
- There has been no penetration test or external security review.
SCHEDULE 3 — Sub-processors
| Who | What they do | Where | Notes |
|---|---|---|---|
| Contabo GmbH | Hosts the server Own Dine runs on, and takes its own virtual-machine backups of it | Germany | Has physical access to the machine. Its backups hold everything the database holds |
| Microsoft (Azure Communication Services) | Sends our emails — order confirmations, password resets and our own messages to you | United Kingdom | Sees the emails it sends, so sees customer name, email address and order contents |
| Microsoft (Azure Storage) | Stores our encrypted nightly archive | United Kingdom — UK South, with a copy in UK West | Holds ciphertext only. The key that opens the archive is not held by Microsoft, and the archive cannot be read without it |
| Stripe | Card payments, into your own Stripe account, and our own billing of you | UK, EU and US under its own terms | Card details go to Stripe and never to us |
| The SMS Works | Text alerts to you when your order board goes offline | UK | Alerts you, not your customers |
| Abacus.AI, with Anthropic or Google models behind it | The menu importer — turning a menu you give us into Hub entries | To be confirmed | Processes your menu, not your customers |
Why the menu importer is listed at all. A menu is not personal data, so this entry may not engage Article 28 — but a shop could upload a document with a name or a phone number in its footer, and "we send your menu to an AI provider" is something you are entitled to know either way.