This Data Processing Agreement (“DPA”) is part of the Terms of Service between Vanerps BV (“Processor”, “we”) and the customer that holds a Tablorix account (“Controller”, “you”).

It applies automatically from the moment you open an account. There is nothing to sign — we would rather every customer be covered from the first booking than have an Article 28 contract sitting unsigned in someone’s inbox. If your own procurement process needs a countersigned copy, write to privacy@tablorix.be and we will provide one.

Where this DPA and the Terms of Service conflict on the processing of personal data, this DPA prevails.

1. Roles

You are the controller of your guests’ personal data. You decide why it is collected and what is done with it, and you are responsible for having a lawful basis and for telling your guests what happens with their data.

We are your processor. We process it only to provide the service to you.

Nothing here makes us a controller of your guests’ data, and nothing here makes you a processor of ours.

2. Scope and duration

We process personal data for as long as your account is open, and afterwards only as clause 10 allows.

The subject matter, nature, purpose, data categories and data subjects are set out in Annex 1.

3. Our instructions come from you

We process personal data only on your documented instructions, including about transfers outside the EEA.

Your instructions are: the Terms of Service, this DPA, and what you and your staff do in the product. Using a feature is an instruction to carry it out.

We will tell you immediately if we believe an instruction breaches the GDPR or another data protection law, and may suspend that instruction until it is resolved. We are not obliged to carry out an unlawful instruction.

If the law requires us to process data beyond your instructions, we will tell you first, unless that law forbids telling you.

We do not use your guests’ data for our own purposes. We do not sell it, do not market to your guests on our own account, and do not use it to train machine-learning models. We produce aggregated statistics that cannot identify any individual or any customer.

4. Confidentiality

Everyone we allow to process personal data is bound by confidentiality — by contract of employment or by a written undertaking — and is trained on their obligations. Access is limited to those who need it to do their job.

5. Security

We implement appropriate technical and organisational measures under Article 32 GDPR. They are described in Annex 2.

We may change them, but not in a way that materially reduces the overall level of security.

6. Sub-processors

You give general written authorisation for us to engage sub-processors.

The current list is published at /subprocessors and forms Annex 3 to this DPA.

Before we add or replace one, we will give you at least 30 days’ notice by email to your account’s administrative contact. If you reasonably object on data protection grounds within that period, we will work with you to find a solution; if we cannot, you may terminate the affected part of the service without penalty and receive a refund of fees paid for the unused period.

Every sub-processor is bound by written terms that are no less protective than this DPA, and we remain fully liable to you for what they do.

7. Helping you answer your guests

If a guest contacts us directly about their data, we will not act on it. We will tell them to contact you, and tell you that they got in touch.

Taking account of the nature of the processing, we will help you meet requests under Chapter III GDPR — access, rectification, erasure, restriction, portability and objection.

In practice, most of this you can do yourself in the product: you can find a guest, see everything held about them, edit it, delete a booking, and erase a guest outright. Where a request needs something the product does not yet offer, write to privacy@tablorix.be and we will carry it out for you within 7 working days, at no charge.

What erasing a guest does. It is on the guest’s own record in the customer book, and it goes wider than deleting the record:

• Their name, contact details and notes are removed from every booking they ever made with you, including the trail a rescheduled booking leaves on the days it moved off. The visit itself stays — its date, time, party size and status — because that is your own record of what you served, and once the guest details are gone it identifies nobody.
• Their guest record and waiting list entries are deleted, as are the emails we sent them about their bookings.
• The comments in their reviews are deleted, because a guest’s own words can name them; the ratings stay, anonymous, so your averages do not move. The review shows that its comments were removed.
• Any marketing consent they gave is withdrawn, and its history is deleted with them — see the third commitment below.
• Their self-service booking and review links stop working, and nothing further is emailed to them.

It is refused while you are still expecting the guest — a booking today or later, or a place on the waiting list — because until the visit has happened their details are still needed for it. Cancel it first if the guest wants to be erased straight away. There is no undo.

It takes effect in the live system immediately. Copies in our backups go with the ordinary backup cycle rather than individually, as described in clause 10.

Three specific commitments, because they are the ones that are easy to get wrong:

• Erasure sticks. If you delete a booking that came from an import, or erase the guest behind one, a later re-run of that import will not bring either back. This is enforced in the software, not by a convention we might forget.
• Withdrawing marketing consent does not erase the proof. Withdrawal adds a new record rather than deleting the old one, because the record of what someone agreed to, and when, is what demonstrates your lawful basis. It is kept for that purpose and used for nothing else.
• Erasing a guest withdraws their consent, and the record of it goes with them. This is the one case where that record is deleted, and it follows from what consent was: permission to send marketing to that person. Erase the person and the permission ends with them — there is nobody left to mail, and nobody the record could demonstrate a lawful basis against. Keeping their email address on file to prove they once agreed would defeat the erasure you were asked to carry out. If they book with you again they arrive with no consent, and have to be asked afresh.

8. Helping you with security, breaches and assessments

Taking account of the nature of the processing and what we know, we will help you comply with Articles 32 to 36 GDPR.

If we become aware of a personal data breach affecting your data, we will tell you without undue delay and in any event within 48 hours. We will tell you what happened, which categories and roughly how many people and records are affected, the likely consequences, and what we are doing about it — and we will keep you updated as we learn more.

We will not notify your supervisory authority or your guests on your behalf unless you ask us to in writing. That notification is the controller’s to make.

We will give you the information you reasonably need for a data protection impact assessment or a prior consultation.

9. Audits

We will make available the information needed to demonstrate we comply with Article 28, and allow and contribute to audits and inspections by you or an auditor you appoint.

Practically: ask us in writing, give us 30 days’ notice, no more than once a year unless a breach or a supervisory authority makes another one necessary, during business hours, without disrupting our operations, and under confidentiality. You bear your own costs; we bear ours, unless the audit finds a material breach by us, in which case we bear both.

Where a recognised third-party certification or audit report answers your question, we may offer it first.

10. Return and deletion

While your account is open, you can export your data yourself at any time — from the dashboard, or over the API with a key you create there. The export is a ZIP archive of JSON files, one per kind of record (venues, services, schedules, tables, bookings, guests, reviews, waiting list, team) plus a manifest: a structured, commonly used, machine-readable format, at no charge. That is the format we provide it in.

When the agreement ends, we delete your personal data.

Deletion in the product is a two-stage process, on purpose:

1. Deleting an organisation, a venue or a booking marks it as deleted and hides it from everything — lists, availability, exports and the booking widget — immediately.
2. 30 days later it is permanently erased, along with everything under it.

The 30-day window is so that an accidental deletion can be undone. If you want your data erased sooner than that, ask us and we will do it.

Backups are kept for 7 days and are overwritten on a rolling basis; data in a backup is erased by that cycle rather than individually, and stays subject to this DPA until it is.

Guests who stop coming. Your guests’ details are also kept no longer than they are useful to you, without anyone having to delete anything. A guest whose last contact with you — a booking in any status, a waiting-list entry, a marketing consent, or an edit of their record by your staff — is more than 3 years ago is erased automatically, in exactly the way clause 7 describes an erasure on request: their guest record and consent history go, their name, contact details and notes are removed from every booking they made, and the visits stay, anonymised, as your own record. A booking taken without an email address or phone number has no guest record; it is anonymised the same way 3 years after its date. The trail a rescheduled booking leaves on the day it moved off is deleted after the same 3 years. A guest who books again starts afresh. Bookings you import from a previous platform are covered in the same way as the ones taken here.

You can shorten this period, never lengthen it: your organisation’s owner can choose a whole number of years below 3 under Organization → Data in the product. The shorter period then applies to all of your guests, bookings without a guest record and rescheduling trails, from the next automatic clean-up (within a few hours). That setting is your documented instruction to us; we record who set it and when. Guests already erased under a shorter period are not restored if you lengthen it again.

Notes on a booking. The free-text notes on a booking serve that visit, and are where health data such as allergies usually sits (Annex 1). They are erased automatically 1 year after the booking’s date, whether or not the guest still comes, and the booking records that they were. Notes on a guest record stay with the guest and follow the paragraphs above. Imported bookings are covered the same way: a later import does not bring back a note already past that year.

We retain personal data past that point only where EU or Member State law requires it, and only for as long and for the purpose that law requires.

11. International transfers

We process personal data in the European Union.

Where a sub-processor involves a transfer outside the EEA, it is covered by an adequacy decision or by the European Commission’s Standard Contractual Clauses, together with any additional measures the transfer needs. The sub-processor page records the position for each one.

You instruct us to make those transfers by using the service.

12. Liability

Liability under this DPA is subject to the limits in the Terms of Service — except that those limits do not apply to an administrative fine or a claim under Article 82 GDPR to the extent it results from our own breach of this DPA, where the law does not permit such a limit.

---

Annex 1: Details of the processing

Subject matter. Providing table-booking software to you.

Duration. For as long as your account is open, plus the deletion periods in clause 10; within that, a guest’s details for 3 years after the guest’s last contact with you, or the shorter period you set (clause 10).

Nature and purpose. Collecting, storing, organising, retrieving, using, transmitting and erasing personal data so that you can take and manage table reservations, communicate with your guests about them, recognise returning guests, run a waiting list, invite reviews, obtain and record marketing consent, and migrate from a previous booking platform.

Categories of data subjects

• Your guests, and people who enquire about a booking
• People on your waiting list
• Your own staff and the people you invite to your account

Categories of personal data

Category	What it covers
Identity	Name
Contact	Email address, phone number
Booking	Date, time, party size, seating area and preference, status, source, language, the terms accepted and when
Guest record	The above, plus staff notes and visit history for a recognised returning guest
Waiting list	Requested date, time and party size, contact details, and the offers made
Marketing consent	Channel, whether given or withdrawn, the exact wording shown and its language, time, IP address, user-agent string, and the staff member or source that recorded it
Reviews	Ratings and free-text comments
Communications	Transactional emails sent about a booking, and their delivery status
Free text	Notes on a booking or a guest record
Staff accounts	Name, email address, role, interface language

Special categories. Booking and guest notes are free text and are commonly used for allergies and dietary requirements, which is health data under Article 9 GDPR. Where you migrate from another platform, allergy information from that platform is carried into this field. Booking notes are erased 1 year after the booking’s date (clause 10).

You instruct us to store it. You are responsible for collecting it only where strictly necessary and with the explicit consent of the guest, and for telling your guests that you do. We apply the same security measures to it as to everything else, and we do not use it for anything other than showing it back to you.

Automated decision-making. None with legal or similarly significant effects. Table assignment and availability are rule-based scheduling that allocates a table to a booking; it makes no decision about a person.

---

Annex 2: Security measures

Access control

• Individual accounts, no shared logins; sessions expire after 7 days
• Role-based access within your organisation, controlled by you
• Every request is checked against the venue it concerns, so one customer’s data cannot be reached from another’s account
• Production access limited to the staff who need it
• API keys are created by the organisation’s owner only, shown once and stored as a hash, expire or are revoked on request, and reach the data export alone

Authentication

• Passwords stored only as salted hashes, never in plain text
• Optional two-factor authentication with an authenticator app (TOTP), per user; the secret and backup codes are stored encrypted, and a trusted device skips the code for 30 days at most
• Optional sign-in with Google, so we never hold a password at all
• Links emailed to guests use unguessable single-purpose tokens, each scoped to one booking and one action

Encryption

• TLS in transit for every connection
• Encryption at rest for the database and backups

Network and infrastructure

• The database is not reachable from the public internet; it sits on a private network with only the application able to reach it
• Firewalled hosts with a minimal exposed surface
• Secrets held in a managed secret store, not in configuration files or images

Resilience

• Daily database backups with 7-day retention, and a documented restore procedure
• Connection limits and rate limiting so a flood degrades rather than fails
• Proof-of-work checks on public endpoints that would otherwise be abusable

Monitoring

• Application error monitoring, with personal data filtered out of reports before they are sent
• Request logging that records the route and outcome, never request bodies or authentication headers

Data minimisation by design

• Public booking endpoints return only what the widget needs to show
• Where we relay a request to another booking platform on your behalf, the credential travels with the request and is never stored by us
• Guest data imported from another platform arrives only attached to bookings; we do not bulk-pull a platform’s customer database

Organisational

• Confidentiality undertakings for everyone with access
• Changes reviewed before reaching production, with an automated test suite
• Segregated development, test and production environments; production personal data is not used for development

---

Annex 3: Sub-processors

The current list is maintained at /subprocessors and is incorporated here by reference. Clause 6 governs changes to it.