Privacy Notice
How i-table handles personal data — both as a controller for its own business customers and website, and as a processor acting for the restaurants that use the platform.
Last updated
i-table is a reservation platform for restaurants. Restaurants use it to publish availability, take bookings, collect deposits and keep their own guest records. Guests use it to book a table at a particular restaurant.
That structure matters for privacy law, because it means personal data flows through i-table in two very different capacities. This notice explains both, and it is written so you can tell which one applies to you. If you only want the short version: the restaurant you booked with, not i-table, decides what happens to your reservation.
1.Who we are
This notice is issued by the operator of the i-table platform (“i-table”, “we”, “us”):
- Legal name
- [LEGAL COMPANY NAME]
- Legal form and registered seat
- [LEGAL FORM], [REGISTERED ADDRESS]
- General Commercial Registry (Γ.Ε.ΜΗ.) number
- [GEMI NUMBER]
- VAT number (Α.Φ.Μ.) and tax office (Δ.Ο.Υ.)
- [VAT NUMBER], [TAX OFFICE]
- General contact
- [CONTACT EMAIL]
- Privacy contact
- [PRIVACY EMAIL]
- Data Protection Officer
- [DPO DETAILS IF APPLICABLE]
2.What this notice covers
This notice applies to:
- the i-table website, including the demo and contact forms;
- the restaurant-facing administration dashboard;
- the public booking pages and the embeddable booking widget that restaurants place on their own websites, and the QR codes that link to them;
- the reservation confirmation pages and calendar files that a guest receives after booking; and
- the emails and text messages sent in connection with a reservation.
It does not cover what an individual restaurant does with your data outside i-table — for example in its own till system, loyalty scheme, or marketing lists. Nor does it cover other websites we link to. Each restaurant is responsible for its own privacy information, and you should read that too.
3.The two roles i-table has, and why the difference matters
Under the GDPR, a controller decides why and how personal data is processed. A processor processes it on the controller's instructions. The obligations, and the person you go to with a request, differ depending on which is which. i-table is both, for different data.
(a) Where i-table is the controller
We decide the purposes and means for data about the businesses that buy or evaluate our software, and about visitors to our own website. That includes restaurant owners and staff who hold dashboard accounts, people who ask for a demo or contact support, and billing contacts. Sections 8 and 12 describe that processing.
(b) Where i-table is a processor for the restaurant
When you book a table, you are booking with a restaurant. That restaurant decides that it wants reservations, what information it asks for, what notes it keeps about you, how long it keeps them and whether it contacts you again. It is the controller of that data. i-table supplies the software that stores and moves it, and acts on the restaurant's instructions as its processor under Article 28 GDPR. Section 9 sets this out in full.
(c) Where i-table is a controller even for reservation data — and we do not pretend otherwise
It would be convenient, and wrong, to say that i-table is *only* a processor for everything a guest submits. There are narrow purposes for which we determine the means and purpose ourselves, and for those we are a controller with our own responsibility:
- Keeping the platform secure and available — protecting against abuse, fraud, and attacks on the service as a whole, and investigating incidents that cross more than one restaurant.
- Billing restaurants — the platform fee is calculated from reservation volume, so we process counts and aggregates derived from reservations for our own invoicing and accounting purposes.
- Complying with our own legal obligations — for example responding lawfully to a competent authority, or retaining accounting records.
- Maintaining and improving the service — diagnosing faults and keeping technical records of what the system did.
4.Definitions
- Personal data
- Any information relating to an identified or identifiable natural person (Article 4(1) GDPR).
- Processing
- Any operation performed on personal data — collection, storage, use, disclosure, erasure and so on (Article 4(2) GDPR).
- Controller / Υπεύθυνος Επεξεργασίας
- The party that determines the purposes and means of processing (Article 4(7) GDPR).
- Processor / Εκτελών την Επεξεργασία
- The party that processes personal data on behalf of the controller (Article 4(8) GDPR).
- Data subject / Υποκείμενο των Δεδομένων
- The living individual the personal data relates to.
- Special categories of personal data
- Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric data, health data, or data concerning sex life or sexual orientation (Article 9(1) GDPR). See section 10.
- Restaurant
- A business that holds an i-table account and takes bookings through the platform. In this notice, the controller of reservation data.
- Guest
- An individual who books, or is booked into, a table at a Restaurant through i-table.
- Sub-processor
- A third party engaged by i-table to process personal data on a Restaurant's behalf — for example our hosting or messaging providers.
5.Whose data is processed
- Guests who make a reservation, and any other person a guest names in a booking (for example when a booking is made on someone else's behalf).
- Restaurant personnel — owners and staff who hold dashboard accounts.
- Business contacts — people who request a demo, contact us, or are named as a billing or operational contact for a restaurant.
- Website visitors who browse the i-table site or a restaurant's booking page.
6.What personal data is processed
Guest and reservation data (restaurant is controller)
| Category | Fields | Required? |
|---|---|---|
| Guest identity | First name; last name; telephone number; email address | First name and telephone number are mandatory; last name and email are optional |
| Reservation details | Date, time, party size, seating area, selected extras, reservation status, booking reference, hold and expiry timestamps, and the channel the booking came through (website, embedded widget, QR code, or entered by staff) | Mandatory |
| Guest-supplied free text | Occasion; dietary information; notes to the restaurant | Optional — see section 10 |
| Restaurant-supplied free text | Internal notes kept by staff about a guest, and a “VIP” marker | Optional, entered by the restaurant |
| Language | Whether the booking was made in Greek or English, so confirmations are sent in the right language | Automatic |
| Deposit and payment reference | Deposit amount and, where a card payment is used, the identifier of the payment session held by our payment provider. No card number, expiry date or security code is ever received or stored by i-table — see section 11 | Only where the restaurant requires a deposit |
Restaurant account data (i-table is controller)
- Account credentials — the email address and password of each dashboard user. Authentication is handled by our infrastructure provider's authentication service; i-table's own database stores only the account identifier and the person's role (owner or staff), not their password.
- Business contact details — restaurant name, address, telephone number and billing email address.
- Administrative records — an append-only log of significant actions taken in the dashboard, recording which account performed the action, which restaurant it concerned, and a short description. This is used for accountability and troubleshooting.
- Commercial records — invoices and the reservation counts they are calculated from.
Enquiry and website data (i-table is controller)
Information you send us when you request a demo or contact us — typically your name, restaurant, email address, telephone number and whatever you write in your message.
Technical data
Our hosting and infrastructure providers process technical information inherent in serving any website — including IP addresses and request logs — for security, abuse prevention and fault diagnosis. i-table's own application database does not contain a field for IP addresses or device identifiers, and we do not build behavioural profiles.
7.How we obtain personal data
- Directly from you — when you complete a booking, create an account, or contact us.
- From a restaurant — when its staff enter or amend a booking on your behalf (for example a reservation taken over the telephone), or add notes to your guest record.
- From another guest — when somebody books a table and names you.
- Automatically — technical data generated when your browser requests a page, as described above.
- From our payment provider — confirmation that a deposit has been paid or has failed, where card payments are enabled.
8.Purposes and lawful bases where i-table is the controller
Each purpose below has its own lawful basis under Article 6(1) GDPR.
| Purpose | Lawful basis |
|---|---|
| Creating and administering a restaurant's account, providing the dashboard, and supporting users | Article 6(1)(b) — performance of the contract with the restaurant. Where the individual user is not personally the contracting party, Article 6(1)(f) — our legitimate interest in operating the service our customer has engaged us to provide |
| Authenticating dashboard users and keeping accounts secure | Article 6(1)(b) and Article 6(1)(f) — our legitimate interest in preventing unauthorised access |
| Responding to a demo request, sales enquiry or support request | Article 6(1)(b) — steps taken at your request prior to entering a contract; otherwise Article 6(1)(f) — our legitimate interest in answering people who approach us |
| Invoicing restaurants and keeping accounting records | Article 6(1)(b) for the invoice itself, and Article 6(1)(c) — compliance with tax and accounting obligations under Greek law |
| Keeping the platform secure, preventing abuse and fraud, and investigating incidents | Article 6(1)(f) — our legitimate interest, and that of every restaurant and guest, in a service that is not abused |
| Maintaining administrative logs of dashboard actions for accountability | Article 6(1)(f) — our legitimate interest in being able to establish who changed what, which also supports our accountability obligation under Article 5(2) |
| Diagnosing faults and improving the service | Article 6(1)(f) — our legitimate interest in a service that works |
| Establishing, exercising or defending legal claims | Article 6(1)(f) — our legitimate interest in protecting our legal position |
| Complying with a legal obligation, including a lawful request from a competent authority | Article 6(1)(c) |
9.Reservation data: the restaurant is the controller, i-table is the processor
This section is the one that matters most to guests, so it is stated plainly.
When you book through i-table, the restaurant you selected decides why your data is collected and what is done with it. It is the controller. i-table stores and transmits that data so the booking works, strictly on the restaurant's instructions and under a written contract that meets Article 28(3) GDPR. Within that role, we do not use your reservation data for our own purposes, we do not sell it, and we do not use it to market anything to you.
What this means in practice
- The restaurant answers for the booking. Its lawful basis for processing your reservation will usually be Article 6(1)(b) — performing the reservation you asked for — together with Article 6(1)(f) or 6(1)(c) for its own records. That is the restaurant's assessment to make and to explain to you, not ours.
- Your guest record belongs to that restaurant alone. Records are kept separately for each restaurant. Booking at two i-table restaurants creates two unconnected records; neither restaurant can see the other's.
- Requests about your reservation usually go to the restaurant. If you want your booking history deleted, your notes corrected, or a copy of what is held about you, the restaurant is the party that decides. If you contact us instead, we will tell you promptly and, where we can identify the restaurant, pass your request on or point you to it. We will not simply ignore you.
- We assist the restaurant. Article 28(3)(e) and (f) require us to help the restaurant respond to your rights requests, keep the data secure, notify breaches, and delete or return the data at the end of the contract. We do that.
- We do not use “we are only a processor” to avoid responsibility. As a processor we remain directly liable under Articles 28, 32 and 82 GDPR, and where we determine a purpose ourselves we are a controller for it and say so — see section 3.
The Data Processing Agreement
Article 28(3) GDPR requires a written contract between each restaurant and i-table. The terms of that agreement are set out in a separate Data Processing Agreement rather than in this notice, because it is a contract between two businesses and not a transparency document for individuals. Restaurants can find the requirement in section the Terms of Service and should request the DPA before going live.
10.Allergies, dietary needs and free-text notes — Article 9 GDPR
The booking form has optional free-text fields for the occasion, dietary information and notes to the restaurant. Restaurant staff can also write internal notes on a guest record. These fields are genuinely useful — and they are the single most sensitive thing the platform holds, so they are treated carefully rather than casually.
Why they are sensitive
Free text invites people to explain themselves. “Severe nut allergy”, “coeliac”, “diabetic — needs an early sitting” are health data. “No pork” or “halal” may reveal religious belief. “Wheelchair access needed” concerns health. All of these fall within Article 9(1) GDPR, which prohibits processing special categories of personal data unless one of the exceptions in Article 9(2) applies. The fact that the guest typed it voluntarily into a box does not, by itself, make the processing lawful.
How this is addressed
- Please share only what the restaurant needs. If you have an allergy, tell the restaurant the allergy. You do not need to give a diagnosis, a medical history, or details about anyone else at the table.
- The restaurant, as controller, must have an Article 9(2) condition. In practice this is normally the guest's explicit consent under Article 9(2)(a) — given by choosing to enter the information for the purpose of being served safely. The restaurant is responsible for making that clear and for not using the information for anything else.
- Restaurants should not record sensitive information they do not need. Internal notes should describe service preferences, not a guest's medical or religious life, and should be reviewed and removed when no longer necessary.
- i-table does not read, mine, analyse or profile these fields. They are stored so the restaurant can see them, transmitted in the booking confirmation flow, and nothing else. There is no automated interpretation of their content.
- Access is restricted to the restaurant that received the booking and to the limited i-table personnel described in section 16.
11.Deposits and payment information
Some restaurants require a deposit or prepayment to confirm a booking. Where they do:
- i-table never receives your card details. You are taken to a payment page hosted by our payment provider, and you enter your card details there, on their systems. Your card number, expiry date and security code are never transmitted to, processed by, or stored on i-table's systems. There is no field for them anywhere in our database.
- What we store is a reference. We keep the deposit amount and an identifier for the payment session, so the booking can be matched to the payment and so refunds and disputes can be traced.
- What the provider receives. To create the payment page, the provider is sent the amount, the currency, a reference to the reservation and — so it can send you a receipt — your email address. The provider is a controller in its own right for the payment transaction, and its own privacy notice applies to what it does with that data.
- The deposit is the restaurant's money, not ours. i-table's own fees are charged to the restaurant, separately. See the Terms of Service for how the two are kept apart.
Lawful basis: Article 6(1)(b) — the deposit is part of the reservation contract between you and the restaurant — and Article 6(1)(c) for the transaction records that tax law requires the restaurant and the provider to keep.
12.Marketing communications
From i-table to businesses
We may send information about the platform to restaurant contacts and to people who have asked us about it. Under Article 11 of Greek Law 3471/2006, unsolicited electronic marketing generally requires prior consent; the exception is that where we obtained your email address in the context of a sale or a negotiation for a similar product, we may use it for our own similar products provided you were given a clear and free opportunity to object at the point of collection and in every message. We will always include an unsubscribe mechanism, and honouring it costs you nothing.
Lawful basis: Article 6(1)(a) consent where consent is required, otherwise Article 6(1)(f) legitimate interest in direct marketing to existing business customers within the limits of Law 3471/2006.
From restaurants to guests
If a restaurant markets to you — offers, events, newsletters — that is the restaurant acting as controller, on its own basis, and any consent you give is given to it. i-table does not send marketing to guests and does not use guest data to advertise anything.
13.Who receives personal data
Personal data is disclosed to:
- The restaurant you booked with — it receives the booking and holds the guest record.
- Our infrastructure and hosting providers — who host the application and the database on our behalf, as sub-processors.
- Our messaging providers — who deliver confirmation emails and text messages, where those are enabled.
- Our payment provider — as described in section 11.
- Professional advisers — lawyers and accountants, bound by professional confidentiality, where necessary.
- Competent authorities — where we are legally obliged to disclose, and only to the extent of that obligation.
- An acquirer — if the business is sold or reorganised, subject to this notice continuing to apply.
We do not sell personal data, and we do not disclose it to advertising networks or data brokers.
14.International transfers
Our intention is that personal data is stored within the European Union or the European Economic Area.
Where any transfer to a country outside the EEA does occur — including remote access by a provider's support personnel — it will take place only under a transfer mechanism permitted by Chapter V GDPR, which in practice means an adequacy decision under Article 45, or the European Commission's Standard Contractual Clauses under Article 46(2)(c) together with a transfer impact assessment and any supplementary measures that assessment identifies. You may request a copy of the relevant safeguards from [PRIVACY EMAIL].
15.How long data is kept
Article 5(1)(e) GDPR requires that personal data is kept in an identifiable form no longer than is necessary. The criteria that determine retention here are:
- Reservation and guest records
- Set by the restaurant, as controller, according to how long it needs a guest history and any legal obligation it has. i-table's role is to apply the restaurant's instruction and to delete or return the data when the restaurant's contract with us ends.
- Unconfirmed bookings
- A booking that is never confirmed holds the table only for a short window and is then cancelled automatically. Cancelling changes the booking's status; it does not by itself erase the record.
- Restaurant account data
- For the duration of the contract, then for as long as needed to conclude the relationship and defend potential claims.
- Invoices and accounting records
- For the period required by Greek tax and accounting legislation, which is longer than the commercial relationship.
- Administrative logs
- For as long as needed for accountability and security investigation.
- Enquiries and support correspondence
- For as long as needed to deal with the matter and, where relevant, to evidence what was agreed.
16.Security
We take technical and organisational measures appropriate to the risk, as Article 32 GDPR requires. At a level of detail that does not itself create a vulnerability, these include:
- Encryption in transit for all connections to the platform, and encryption at rest as provided by our infrastructure providers.
- Tenant isolation enforced in the database itself. Access rules are applied at the row level by the database, not merely by application code, so a restaurant's staff can only reach that restaurant's data. Sensitive commercial fields are further restricted at column level.
- Role-based access. Dashboard users hold either an owner or a staff role, and administrative functions are restricted to owners. Platform administration is a separate, separately authenticated surface.
- Least privilege for internal access. Access to production data by i-table personnel is limited to what is necessary to operate and support the service.
- Administrative logging of significant changes made through the dashboard.
- Managed authentication with password handling, session expiry and token rotation provided by a specialist authentication service; i-table does not store passwords.
- Segregation of card data, which never enters our systems at all.
No system is perfectly secure. If a personal data breach occurs, we will notify the competent supervisory authority and affected individuals in accordance with Articles 33 and 34 GDPR, and — where we act as processor — notify the affected restaurants without undue delay so they can meet their own obligations.
17.Your rights
Subject to the conditions and exceptions in the GDPR itself, you have the following rights. They are described here with their real limits, because a notice that promises more than the law gives is misleading.
- Access — Article 15
- To be told whether we process your data and, if so, to receive a copy together with the information listed in Article 15(1). The copy must not adversely affect the rights and freedoms of others, so material about other people may be redacted.
- Rectification — Article 16
- To have inaccurate data corrected and incomplete data completed. This applies to facts; it does not extend to requiring a restaurant to change an opinion recorded about a service interaction, although you may add a statement of your own.
- Erasure — Article 17
- To have data erased where one of the grounds in Article 17(1) applies — for example the data is no longer necessary, or you withdraw the consent it relied on. The right does not apply where processing is necessary for compliance with a legal obligation, or for the establishment, exercise or defence of legal claims (Article 17(3)). A deposit already paid, or an invoice already issued, will normally have to be retained for tax purposes.
- Restriction — Article 18
- To have processing restricted while an accuracy dispute or an objection is being resolved, or instead of erasure where you need the data for legal claims. Restricted data may still be stored.
- Portability — Article 20
- To receive data you provided, in a structured, commonly used, machine-readable format, where processing is based on consent or contract and is carried out by automated means. It does not extend to data that we or a restaurant inferred or generated, such as internal staff notes.
- Objection — Article 21
- To object to processing based on legitimate interests, on grounds relating to your particular situation; we must then stop unless we demonstrate compelling legitimate grounds that override your interests, or the processing is for legal claims. Where you object to direct marketing, the objection is absolute and we stop immediately, with no balancing exercise.
- Withdrawal of consent — Article 7(3)
- Where processing is based on consent, to withdraw it at any time, as easily as it was given. Withdrawal does not affect the lawfulness of processing carried out before it.
- Not to be subject to automated decisions — Article 22
- See section 20: we do not carry out such decision-making, so this right does not arise in practice.
Greek law adds a further layer: Article 33 of Law 4624/2019 restricts the rights to erasure and objection in specific circumstances, and Articles 30 to 34 of that Law provide for other national limitations. Where such a restriction applies to a request, we will say so and explain why.
18.How to exercise your rights
- If your request concerns a reservation or a guest record, address it to the restaurant you booked with — it is the controller and it decides. Its contact details are on its booking page and on your confirmation.
- If your request concerns i-table's own processing — an account, an enquiry, our website — write to [PRIVACY EMAIL].
- If you are not sure, write to us anyway. We will tell you which it is and, where we can identify the restaurant, forward your request or tell you who to contact.
We respond without undue delay and in any event within one month of receiving the request. That period may be extended by up to two further months where the request is complex or where several requests have been made, in which case we will tell you within the first month and explain why (Article 12(3) GDPR).
There is no charge. Where a request is manifestly unfounded or excessive, in particular because it is repetitive, we may charge a reasonable fee or refuse to act, and we will explain our reasoning (Article 12(5) GDPR). Where we have reasonable doubts about your identity we may ask for information to confirm it (Article 12(6) GDPR); we will ask only for what is necessary and will not use it for anything else.
19.Complaints
If you are unhappy with how your personal data has been handled, please tell us first at [PRIVACY EMAIL] — most issues are quicker to fix directly. You also have the right under Article 77 GDPR to lodge a complaint with a supervisory authority, in the Member State of your habitual residence, place of work, or the place of the alleged infringement.
The competent authority in Greece is the Hellenic Data Protection Authority (Αρχή Προστασίας Δεδομένων Προσωπικού Χαρακτήρα):
- Address
- Kifissias 1–3, 115 23 Athens, Greece
- Telephone
- +30 210 6475600
- contact@dpa.gr
- Website
- www.dpa.gr
You also have the right to an effective judicial remedy under Articles 78 and 79 GDPR.
20.Automated decision-making and profiling
We do not carry out automated decision-making, including profiling, that produces legal effects concerning you or similarly significantly affects you, within the meaning of Article 22(1) GDPR.
The platform does apply straightforward, rule-based automation — checking whether a table of the right size is free at the requested time, releasing a table when an unconfirmed booking expires, and preventing two bookings from overlapping on the same table. These are deterministic availability rules rather than an evaluation of you as a person, and they have no bearing on your rights. Any marker such as “VIP” on a guest record is set manually by restaurant staff, not computed by the platform.
21.Children
i-table is not directed at children and we do not knowingly collect personal data from children. A reservation is expected to be made by an adult, who may of course include children in the party.
Where an information society service is offered directly to a child on the basis of consent, Article 21 of Greek Law 4624/2019 sets the age at 15 — below that age, consent must be given or authorised by the holder of parental responsibility. Greece has exercised the Article 8(1) GDPR option to lower the default of 16 to 15.
If you believe a child has provided us with personal data, contact [PRIVACY EMAIL] and we will delete it unless we are required to keep it.
23.Changes to this notice
We may update this notice to reflect changes to the platform or to the law. The date at the top shows when it was last changed. Where a change materially affects how your personal data is used, we will take reasonable steps to bring it to your attention — for example by notice in the dashboard for restaurant users — before it takes effect. Continuing to use the platform after a change takes effect does not, on its own, constitute consent to processing that requires consent.
24.Contact
- Privacy enquiries and rights requests
- [PRIVACY EMAIL]
- General enquiries
- [CONTACT EMAIL]
- Postal address
- [LEGAL COMPANY NAME], [REGISTERED ADDRESS]
- Data Protection Officer
- [DPO DETAILS IF APPLICABLE]
See also our Terms of Service.