Last updated 24 September 2026 · applies to getresto.app and the Resto scheduling app
These terms are written to be genuinely readable, not to bury anything in boilerplate — but they are not a substitute for your own legal advice, especially once you're relying on Resto for real employees' data. If anything here is unclear, email us (contact details at the bottom) before you rely on it.
Mykyta Hreshnov, trading as Resto App ("Resto", "we", "us") provides the Resto staff-scheduling application at getresto.app. Resto is currently operated as a UK sole trader, not (yet) a registered company — if that changes we'll update this page and tell venues using the service at the time.
Registered/business address available on request — email us (section 16) and we'll provide it.
Resto helps a hospitality venue ("you", "the venue") build staff rotas: it tracks your team, zones, shift templates and events, generates draft schedules, and lets staff submit and track holiday/time-off requests. You control what goes into it and who on your team can see or change it.
During the free pilot, each venue's manager (the person who registers the venue) is the Owner and can invite other managers. All managers have equivalent access to the venue's schedule, team and settings unless stated otherwise.
For your team's personal data (names, emails, shift assignments, holiday requests, and similar), you (the venue) are the data controller — you decide why and how that data is processed, and you're responsible for having a lawful basis to process it and for meeting your own obligations to your staff (informing them, honouring their rights, and so on).
Resto is the data processor — we process that data only to provide the service, following your instructions (using the app the way it's designed to be used), and under the terms of this section (which functions as our Data Processing Agreement — see also sections 4–10).
Separately, for the account details a manager gives us directly when registering (name, email), Resto is the controller — that's our own direct relationship with you as a user of the service, not something we process on a venue's instructions.
| Category | Examples |
|---|---|
| Manager/staff account data | Name, email address, role (manager/staff), login credentials (handled entirely by our authentication provider — we never see or store passwords in plain text) |
| Scheduling data | Shift assignments, zones, shift templates, working patterns, events |
| Tasks | What a manager asked a team member to do, who it was for, when it was taken, done and confirmed, and an optional comment. Kept for 90 days after the due date. Please do not write anything about health or private life in a task or a comment. |
| API keys | Keys the Owner makes so an outside tool can read the venue's published rota, timesheets and wage tracker hours (team members' names, roles, shifts, clock times, hours against the hours budget and, for the wage tracker, draft shifts and the names on them — never pay, pounds, contact details, sick days or location). We keep only a fingerprint of each key and a log of calls (time, endpoint, result, number of rows; no addresses), kept for 90 days. The Owner decides which tools get a key and is responsible for that tool's use of the data; a key can be revoked at any time. |
| Time-off & holiday data | Requests (holiday, day off), approval status, holiday balance calculations, leaving date if a team member exits |
| Venue configuration | Venue name, timezone, rota rules (e.g. minimum rest between shifts), zone definitions |
| Payroll data (only if your venue uses Resto Payroll; visible to managers only) | Clock-in and clock-out times, hourly rate, date of birth, address, National Insurance number, tax code, National Insurance category, student-loan and pension status, bank sort code and account number, absence dates (holiday and sickness), pay runs, payslips and the audit trail of who changed what |
We deliberately don't ask for a reason when someone requests time off — a free-text "why" field can accidentally capture health information (e.g. a note explaining a sickness absence), which is a special category of data under GDPR. Keep any such detail out of Resto and handle it through your normal HR process instead. If you use Resto Payroll, a sickness absence is recorded only as dates and a yes/no confirmation that Statutory Sick Pay is due; do not type the illness or any medical detail into any field.
We use a small number of specialist infrastructure providers to run Resto. We won't add a new one that processes your data without telling you first (email to the address on file for your venue's Owner, at least 14 days before the change takes effect where practical).
| Provider | Purpose | Location |
|---|---|---|
| Supabase | Database, authentication, backend | EU (Ireland — eu-west-1) |
| Vercel | Hosting the web application (static files only — no personal data stored there) | Global CDN |
| Resend | Transactional email (invites, password resets) | EU/US, per Resend's own infrastructure |
Your venue's data is hosted in the EU (Ireland). Depending on where your venue is, using Resto can mean your team's data crosses a border to get there:
No additional safeguard is needed — the UK and EU/EEA are mutually recognised as providing an adequate level of data protection (the European Commission's UK adequacy decision was renewed in December 2025, valid to December 2031).
We ask for this explicitly because the position isn't fully settled everywhere: for example, under Ukraine's current data protection law, the UK isn't automatically treated as an adequate destination for personal data leaving Ukraine, so an independent legal basis (such as the informed consent above) is the safer footing. If you're a venue outside the UK/EEA and want more detail on this before registering, email us — we're happy to talk it through.
If one of your team members wants to exercise their data protection rights (access, correction, deletion, and so on), that request should normally go to you (the venue), since you're the controller. We'll help you fulfil it — most of this can already be done directly in the app (editing or removing a team member's record deletes their account too), and for anything else, email us and we'll assist within a reasonable time.
We keep a team member's data for as long as their record exists in your venue's Resto account. Removing a team member through the app deletes their account, rota data and clock-in records, including their login access — this is immediate and not reversible by us.
Payroll records are the exception. If your venue uses Resto Payroll, the payroll records for a team member (their payroll details, absences, approved pay runs and the audit trail) are kept separately and are not deleted when you remove the team member from your rota, because UK law makes you keep them: HMRC requires PAYE records for at least 3 years after the end of the tax year they relate to, and National Minimum Wage, holiday and pension records must be kept for 6 years. These records are visible only to your venue's managers. We erase them only on your instruction once the retention period has passed, or where a court or regulator requires it.
If you close your venue's account entirely, email us and we'll delete the venue's data within 30 days, except where we're required to keep something longer by law, and except for payroll records still inside the legal retention period, which we keep until you tell us they can be erased.
If we become aware of a security incident affecting your venue's data, we'll notify you without undue delay, and in any case within 72 hours of becoming aware of it, with what we know at the time and what we're doing about it.
Resto includes features that help you respect rules like minimum rest between shifts. These are a helpful tool, not a guarantee of legal compliance. You remain solely responsible for complying with the labour law that applies to your venue — including (depending where you operate) the UK Working Time Regulations, the EU Working Time Directive, Ukrainian labour law, or any other applicable rules. If a schedule Resto helps you build turns out not to comply with the law that applies to you, that responsibility sits with you as the employer, not with Resto.
Payroll. Resto Payroll calculates pay, tax, National Insurance, pension, loan, sick-pay and holiday-pay figures from the details you enter and produces files and payslips from them. It does not file anything with HMRC, make any payment, or check your inputs against the facts: the employer remains responsible for the accuracy of the details entered, for checking every pay run before approving it, for giving each worker a payslip on or before payday, for filing on time with HMRC (through your accountant or payroll software) and for paying the right amounts to workers and to HMRC. We recommend you have your accountant review the first runs.
Resto is provided "as is", free of charge, during the pilot phase described in section 2. To the fullest extent permitted by law, we aren't liable for indirect or consequential losses arising from your use of Resto, or for losses arising from your own failure to meet your obligations as a data controller or employer (sections 11–12). Nothing in these terms limits liability where the law doesn't allow it to be limited (for example, liability for fraud).
We may update these terms as the product changes — particularly once paid subscriptions are introduced (section 2). We'll update the date at the top of this page, and for any material change, we'll email the Owner of each venue using Resto at the time.
These terms are governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction over any dispute arising from them — without prejudice to any mandatory local law that applies to you regardless (including, where relevant, protections under EU/UK GDPR or Ukrainian data protection law).
Questions about these terms, your data, or anything else: mykytahreshnovresto@gmail.com
(This is a temporary contact address for the pilot phase — it will move to a dedicated address at getresto.app once that's set up, and this page will be updated when it does.)