Data processing agreement

Last updated 17 October 2026 · part of the terms of service

This agreement applies when a company (the client, the controller) uses Restado AI and Restado AI (operating company to be confirmed) (the processor) processes personal data on the client's behalf. It meets Article 28 of the EU General Data Protection Regulation (GDPR) and the UK GDPR. If it conflicts with the terms of service on data protection, this agreement wins.

1. What is processed

2. Instructions

The processor processes personal data only on the client's documented instructions — these terms, the client's settings in the dashboard (retention periods, features switched on, messaging mode, connected systems) and written requests — unless the law requires otherwise, in which case it tells the client first where the law allows. The processor tells the client if it believes an instruction breaks data-protection law.

3. Confidentiality

Everyone at the processor with access to personal data is bound by confidentiality and has access only as far as their role needs.

4. Security

The processor keeps the technical and organisational measures in the annex below, and may improve them; it will not lower their overall level.

5. Sub-processors

The client authorises the sub-processors on the sub-processors page. The processor gives at least 30 days' notice (in the dashboard and by email to the owner) before adding or replacing one; the client may object on reasonable data-protection grounds, and if no solution is found may end the affected service without penalty. Each sub-processor is bound by data-protection terms no weaker than these, and the processor remains responsible for them.

6. International transfers

The database and file storage are in the European Union. Where a sub-processor processes data outside the EEA or the UK, the transfer relies on an adequacy decision (including the EU–US Data Privacy Framework where the provider is certified) or on the European Commission's Standard Contractual Clauses (and the UK addendum), with supplementary measures where needed.

7. Helping the client

• Requests from people: the dashboard lets the client export a person's data and erase it in one step (recordings including the telephony provider's copy, transcripts, summaries, messages, preferences and contact details); the processor forwards any request it receives directly and helps the client answer.
• Impact assessments and consultations: the processor provides the information it has, including the data-processing record.

8. Personal-data breaches

The processor tells the client without undue delay and within 48 hours of becoming aware of a breach affecting the client's data, with what is known (what happened, which data and people, likely consequences, measures taken), and updates it as more is learned.

9. End of the service

The client can export its data at any time. When the service ends, the processor deletes the client's personal data within 30 days (database backups roll off within a further 7 days), unless the law requires keeping it, and confirms the deletion on request.

10. Audits

The processor makes available the information needed to show compliance with this agreement — this agreement, the data-processing record, the measures below and summaries of security tests — and allows audits by the client or an auditor it appoints, on 30 days' notice, at most once a year unless a breach or an authority requires more, under confidentiality, and without access to other clients' data.

Annex — technical and organisational measures

• Separation of clients: every record carries its client; every query is bound to the caller's client in the application and enforced again by row-level security in the database; an automatic test walks every route with one client's account and fails on any sight of another client's data.
• Access: roles (owner, admin, manager, staff, viewer) and per-property limits; door codes and guest contact details hidden from staff and viewers; two-factor sign-in available and enforceable for owners and admins; sessions can be revoked; rate limits per person and per address.
• Access details: door codes and smart-lock codes are given to a caller only after a PIN sent to the booking's contact is entered (a recognised phone number is not enough); never in messages; every release is logged.
• Encryption: TLS in transit; encryption at rest by the hosting providers; connected-system credentials and lock codes additionally encrypted per record (AES-256-GCM); API keys stored as hashes only.
• Accountability: an audit trail of every administrative action and every access-details release, kept with phone numbers hashed after 90 days; an automatic check fails the build if a route that changes data does not record it.
• Minimisation and retention: retention periods per data type (recordings and transcripts 90 days by default), applied daily and automatically; erasure in one step; error reports scrubbed of names, contact details, codes and message text before they leave the servers.
• Resilience: database backups; background work is queued durably and retried; calls are forwarded to the client's fallback number if the voice system fails; billing never stops a guest call.
• Outbound safety: webhooks to the client's systems are signed and only sent to public addresses; incoming webhooks are authenticated (signatures or secrets checked in constant time).
• People and change: least-privilege access for staff of the processor; administrator actions on a client's account ("view as client") are read-only by default, time-limited, require a reason and appear in the client's own audit log; every change passes the full automated test suite before release.