Data Processing Agreement (DPA)

⚠️ This is a draft. The text below describes how processing actually works here and proposes contractual wording — but it is not an offer, it is not signed, and on its own it creates no obligations. To obtain a signable version for your legal entity (and its Russian counterpart — an instruction to process under Federal Law 152-FZ), write to security@ on your brand's domain (for example, security@cenaly.com) or contact support. We reply with the same document carrying your details, the list of modules you use and the current Annex C.

Why this page is useful before anything is signed: it shows what exactly we process, where it is stored, who it is shared with, and what we can and cannot do — with no promises the product does not keep. The technical side of the same question is in Security and data.

1. Parties and roles#

What that means in practice:

• You determine the purposes. You decide whether to collect guest phone numbers, whether to record calls, whether to keep personnel files in the panel, whether to switch on AI features. We supply the tool and carry out the instruction — the set of operations you define through account settings and your own actions in the interface.
• The legal basis is yours too. A guest's consent, a contract with them, your statutory duty (a fiscal receipt, personnel records, hotel guest registration) — all of that is on you. The platform does not and cannot verify whether you had a basis for entering a particular person into a database.
• Notices to data subjects are yours. The storefront privacy policy, the cookie banner, the newsletter consent text are published in your name. We provide the builder, page hosting and the consent log — see Legal documents and Cookies and consent.
• There are areas where we are an independent controller, and they are kept separate honestly: your account and subscription payment data, technical error telemetry from the panel, and your correspondence with support. These are processed under our own policy, not on your instruction.

What stays with you as the operator#

Informing data subjects and collecting the basis · lawfulness of purposes · answering data subject requests (we assist, see §9) · notifying the regulator where the law puts that duty on the operator (in Russia — notifying Roskomnadzor of processing and of an incident) · configuring roles so that staff only see what they need · deciding whether to enable AI features and the transfer of data to foreign models.

2. Subject matter, nature and purposes of processing#

We process data only to run the features you have enabled and to support those features when you ask us to. We do not use the contents of your account for advertising or profiling, we do not train our own models on it, we do not sell it and we do not disclose it to third parties other than the sub-processors in §6 and the recipients you choose yourself.

Nature of processing: collection, recording, organisation, storage, rectification, retrieval, use, anonymisation, restriction and erasure; automated processing in the cloud.

The full "module → data → purpose → term" breakdown is in Annex A.

3. Categories of data subjects and categories of data#

Categories of data subjects: guests and customers · leads · employees · job applicants · account users (the owner and staff with a login) · representatives of counterparties and partners.

Categories of data the product accepts:

Special categories (GDPR Art. 9, 152-FZ Art. 10) are not collected by the platform itself. That said, the product does contain fields where you can enter health data: an employee's medical certificate and sick leave, a hotel guest's health and dietary restrictions. By entering them you accept the heightened requirements for the basis and the safeguards; our part is to keep them hidden by default and not to reveal them without an explicit purpose.

Biometrics are blocked platform-wide. The class is marked as forbidden in the policy registry, and an attempt to store such data is rejected by code rather than by a guideline. There are no fingerprints, face templates or voiceprints in the contour.

We hold no payment card data at all — neither the number nor the CVV: the card is handled by the payment provider and only the outcome of the transaction reaches us.

4. Term, deletion and return of data#

• The term runs with your subscription and your account. While the account is live the data is stored so that the features work.
• Deletion happens within 30 days of your written request or of termination. This covers both deleting the account as a whole and deleting a specific data set on your instruction.
• Taking your data out before deletion is your job and our duty to help with. The export is self-service, no support ticket needed: Data export. A prepared archive lives for 7 days, and secrets are deliberately excluded from it.
• Some terms are set by law, not by your subscription. Fiscal documents, personnel files and hotel guest registration are kept for as long as the country's rules require — and in those cases deletion "on request" is impossible before the term expires. Such records are marked in the product as being under mandatory retention.
• Backups. We do not publish retention periods for internal backups — and therefore do not promise that data "disappears everywhere the same day". The right safeguard is on your side: keep your own copy via export, especially before bulk changes.
• What survives the deletion of an object — disclosed plainly. The account's AI interaction log (the request to a model and its response, including text recognised from your document) is kept for cost accounting and incident investigation, and deleting the source document does not purge it. The answer cache and generated training materials may quote a deleted document until the next rebuild. Full erasure of these traces is available on request to support.
• Content already transmitted to an AI provider while serving your request is subject to that provider's own retention practices and is outside our control.

5. Processor obligations#

5.1 Processing only on your instructions. The instruction consists of your account settings, your actions in the interface and any separate written instruction. If in our view an instruction infringes data protection law, we will tell you and may suspend performance.

5.2 Staff confidentiality. Access to account data is limited to a restricted group of our employees and contractors bound by confidentiality obligations; access is granted on a need-to-perform basis and withdrawn when the work is finished.

5.3 Security measures — the full list is in Annex B. In short: transport only over TLS; objects in storage are encrypted on the service side; a separate personal data contour with encrypted records and a closed read path; access separation by role, section level and location scope; account isolation by storage prefix; irreversible hashes for passwords and PINs.

5.4 Support access only with your explicit permission. A support agent cannot enter your account at will: it requires the toggle in Settings → Support access (/settings/support-access), the scope ("view only" or "view and edit") is chosen by you, every session is logged (who, when, at what scope), and withdrawing consent terminates even a live session. An implementation partner can only sign in on a request approved by the owner, for a limited time and with a banner in the interface; money, HR, data export and integrations are blocked for them by the server in any mode.

5.5 Logging. We keep: the log of the owner's support-access consent and the log of support sessions themselves, the partner sign-in log, the account's AI interaction log, and the access log of the personal data contour. The last one enforces an audit barrier: no log record — no plaintext value returned.

5.6 Assistance with data subject requests — see §9.

5.7 Incident notification. We notify you of a personal data breach affecting your account no later than 72 hours after discovery, without undue delay, and pass on what we know at that point: the nature of the incident, the categories of data and data subjects affected (as far as established), the likely consequences, the measures taken and planned, and a contact for follow-up. If the picture is incomplete by then we send a partial notification and supplement it as the investigation proceeds — staying silent "until everything is clear" is not an option. ⚠️ Notifying the regulator and the data subjects is the operator's duty, i.e. yours: in Russia that is 24 hours to report the fact and 72 hours to report the outcome of the internal investigation; in the EEA it is 72 hours to notify the supervisory authority. That is exactly why our deadline is set so that you can meet yours.

5.8 Assistance with impact assessments (DPIA). On request we provide a description of the processing, the measures and the sub-processors to the extent set out in this document and its annexes — which is normally sufficient for your assessment.

5.9 Deletion or return at the end of the engagement — see §4.

6. Sub-processors#

We do engage sub-processors — a cloud product cannot exist otherwise. The full list with purpose, place of processing and the data transferred is in Annex C. The rules we propose to put in writing:

• a sub-processor is engaged under a written contract with protections no lower than those accepted in this agreement;
• it is given the minimum data needed for its function;
• for a new or replacement sub-processor we give notice by email to the account owner and by updating Annex C at least 30 days before the transfer begins; within that period you may object with reasons, and we will either offer an alternative or you may decline the affected feature or terminate the contract in the part that does not work without it;
• we remain responsible to you for the acts of our sub-processors;
• foreign AI models are enabled only by your decision — that consent is requested separately, not bundled with a general tick-box; on the Russian contour the model-decision step is deliberately disabled (the catalogue holds no model with confirmed 152-FZ compliance).

Separately: recipients you choose yourself — the payment provider, the SIP number carrier, messengers, delivery aggregators, marketplaces, the fiscal data operator and government systems. They receive data because you decided to connect that channel, and in most cases they act as independent controllers rather than as our sub-processors. You accept their terms directly.

7. Residency and international transfers#

The contour is determined by the brand you registered through. It is not an account setting, it does not change on the fly, and an account cannot be "moved" from one contour to another.

Consequences worth spelling out:

• Storage is shared per contour, not per brand. Data of different brands on the same contour sits in a shared storage system separated logically — by account prefix and permissions. We cannot promise you a dedicated bucket.
• Static assets are served worldwide through a CDN — these are the public storefront files (menu, photos, published documents) that a guest's browser reads without authentication anyway.
• The Russian contour is an instruction to process under 152-FZ: recording, organisation, storage and retrieval are carried out in databases located in Russia (Art. 18(5)). AI processing there is done by a Russian provider. At the same time we do not declare certified cryptographic means or formal ISPDn boundaries: if your business is legally required to have them, raise it before you sign up.
• Localisation in Kazakhstan and Uzbekistan. We have no contour in Kazakhstan, and the Kazakh operator profile is honestly marked as "residency unavailable". For Uzbekistan only biometric data, genetic data and telecom subscriber data are subject to mandatory localisation — we do not accept biometrics at all, so storage in the international contour is permissible where the cross-border transfer conditions of the law are met; the basis itself (Standard Contractual Clauses or a standard from the official list) is arranged by you as the operator.

8. Audit and assurance#

• On request we complete your security questionnaire and provide a description of measures and sub-processors to the extent set out in this document and its annexes.
• An on-site audit, or an audit by your auditor, is available by arrangement: with advance notice, during business hours, no more than once a year (more often in case of an incident or at a regulator's demand), under a confidentiality obligation, with no access to other customers' data and none to systems where such access is technically unavoidable. Costs beyond the reasonable are borne by the requesting party.
• ⚠️ Honestly about what does not exist: we have no ISO/IEC 27001 certification, no SOC 2 report, no PCI DSS attestation (we do not process cards at all) and no ISPDn attestation. If your compliance process requires a ready-made independent auditor's report, we cannot supply one today — and we prefer to say so before signing rather than after.
• Our cloud sub-processors and the payment provider do hold certifications; we will not present theirs as ours.

Data protection contact#

Data protection questions, signable-DPA requests and vulnerability reports go to security@ on your brand's domain; ordinary requests go through support. We do not have a separately appointed DPO or an EU representative — another point we state plainly rather than implying otherwise.

9. Data subject rights and assistance#

Data subject requests are addressed to you as the operator — you answer, we assist. What is genuinely available today:

Honest limits worth knowing in advance:

• There is no DSAR console in the panel — such requests are handled manually, through export and the "Customers" and "Employees" sections.
• The "My data" screen on the storefront clears the guest's device, not the server-side order history: the guest sees and erases what is stored in their browser. If they ask you to delete their orders and contacts from your database, you do that.
• There is no "which of my employees opened what" log. Logs are kept for support and partner sign-ins and for access to the personal data contour — so we cannot answer "who on our team looked at this guest's card" today.

10. Liability, term, governing law#

• The agreement is in force while your subscription is in force and while we process data on your instruction; the provisions on confidentiality, deletion and assistance survive its termination to the extent needed to perform them.
• Liability is governed by the main contract (the Terms of Service) and by law; this agreement does not expand it.
• The governing law and jurisdiction depend on the brand and the legal entity providing the service to you; the specific details are inserted into the signed version. The Russian contour is governed by Russian law and 152-FZ terminology; the international contour by the Terms of Service of the relevant brand and by GDPR/UK GDPR where they apply to you.
• If this page and a signed document disagree, the signed document prevails.

Annex A — description of processing#

The "Term" column states what sets the term. "Proposed" means the period is built into the product as a sensible default but has not been legally approved and is finalised in the signed version.

Annex B — security measures#

Transport and storage

• All traffic to the panel, the storefront and the API runs over HTTPS/TLS; public addresses are served behind a CDN.
• Objects in storage are encrypted on the service side (on AWS — SSE-S3, AES-256; a customer-managed KMS key is not used by default). Records in the dedicated personal data contour are encrypted separately — AES-256-GCM, with a data encryption key created per "account × data class" pair and wrapped in the cloud's KMS.
• Call recordings live in a separate cold archive of the brand, inside the same contour, and remain available by link without any "restore" delay.

Access separation

• Staff roles with a choice of sections, access level and location scope; access to a section is not access to the whole account.
• Account isolation by storage prefix, plus server-side denial of browser writes to service prefixes.
• Passwords are 8+ characters with composition requirements; a cashier's PIN is stored only as an irreversible hash; an API key is shown once at creation; signing out closes the session in every tab.
• Dismissing an employee removes their panel login and revokes their phone extension across every location at once.
• Device codes grant access to a single target page (a monitor, a kitchen screen), not to the account.
• Reading the dedicated personal data contour is only possible through a service interface that checks the principal, the account, the scope, a proven business relation, the class and purpose, the field set and the region — and only with a record written to the audit log.

Our access to your data

• Support access — by the owner's toggle, at the chosen scope, with a session log, and with a live session terminated when consent is withdrawn.
• Partner access — on a request approved by the owner, for a limited time, one session at a time, with a banner in the interface, and with server-side blocks on subscription and payments, owner data, staff permissions, data export, integrations, communications, counterparties and the partner programme.
• Forbidden data classes: biometrics are rejected by code. There is no payment card data at all.

What does not exist — stated plainly

• No ISO/IEC 27001 certification, no SOC 2 report, no ISPDn attestation and no certified cryptographic means.
• There is no two-factor sign-in to the panel yet — it is being prepared; today the login is protected by a long password, separate staff logins and device codes with a PIN.
• No log of your employees' actions, no DSAR console and no point-in-time account restore.
• The dedicated personal data contour does not yet cover every section: it has been rolled out for hotel guests (migration of existing accounts is under way), while other sections still keep personal data in ordinary account documents. It advances section by section, and we promise no dates.
• On the Russian contour there is no support session log, no partner sign-in and no cookie scanner.

Annex C — sub-processors#

Infrastructure#

Artificial intelligence#

International contour: requests go through the polza.ai model aggregator rather than straight to the vendor. The available vendors are OpenAI, Google, xAI and DeepSeek; which one is in use is visible and switchable in the "AI models" section. Some features call a vendor directly: knowledge base search and answers go to OpenAI (embeddings, answers, text recognition in images), and the guest-facing AI menu concierge goes to Google Gemini (an excerpt of your knowledge base of up to 4,000 characters is included in the prompt together with the menu and the guest's question).

Russian contour: Yandex Cloud Foundation Models (embeddings, answers, re-ranking, summaries) and Yandex Vision OCR (text recognition in images), with request logging disabled where the provider offers that setting. We do not apply an equivalent setting with foreign providers and rely on their standard API terms, under which API data is not used to train their models.

You may connect your own OpenAI-compatible endpoint — in that case you choose the provider, and it becomes your recipient rather than our sub-processor.

Speech recognition#

What is transmitted is the recording of the call or the uploaded file; what comes back is the transcript.

Email and notifications#

Amazon SES — outbound email: staff invitations, order and reservation notifications, digests, emails to guests. The recipient address and the message contents are transmitted. SES is not used on the Russian contour — some email scenarios there work differently or not at all.

Recipients you connect yourself#

The payment provider (for example, Stripe) · the SIP number and telephony carrier · messengers (Telegram, WhatsApp) · delivery aggregators · marketplaces · the fiscal data operator and government systems (in Russia — OFD, Chestny ZNAK, EGAIS) · analytics counters you installed on your site. What is transmitted to them is determined by the feature you connected; you accept their processing terms directly.

FAQ#

Can we sign this document as it stands? No. It is a draft and a description of the actual state of affairs: it carries no party details, no list of your modules and no date. Request the signable version at security@ on your brand's domain or through support — you will receive the same text with your details filled in.

Do you have ISO 27001 or SOC 2? No. We hold neither a certification nor an auditor's report, and we will not pass off our cloud providers' certificates as our own. We do complete security questionnaires and provide a description of our measures.

Who is the operator of our guests' personal data — you or us? You are. You decide what to collect and why, you inform your guests and collect their consents. We process that data on your instruction and do not use it for our own purposes.

How quickly will you delete our data if we leave? Within 30 days of the request or of termination. We do not publish retention periods for internal backups — take your own copy via export before deletion.

Where is the data physically stored, and can we choose the region? The brand sets the region: the international contour is in the United States, the Turkish brands are in Germany, cenaly.ru is in Russia. You cannot pick a region within one brand; moving means a new account in a different contour.

Data goes to the United States — how do we cover that as an EEA controller? The bases are performance of the contract and Standard Contractual Clauses, and for AI features your explicit consent is requested separately. If a transfer to a third country is unacceptable for you, the Turkish brands run in eu-central-1 (Germany) — but that is a different brand, not a setting.

Do you train your models on our data? No. Account content is not used to train our models, for advertising or for profiling, and it is not sold. With the AI providers we engage we rely on their standard API terms, under which API data is not used for training by default.

Can your support staff look at our data without asking? No. The "Support access" toggle must be on, you choose the scope, sessions are logged, and withdrawing consent terminates even a live session.

A guest demands deletion of their data — what do we do? Delete their card in Customers. The "My data" button on the storefront clears only the guest's own device. For deep cleaning of residual traces (AI interaction logs, caches) ask us — we act within the same 30 days.

What about call recordings — those are sensitive? Recordings and transcripts live in your brand's cold archive, inside the same contour, and access to the "Calls" section is configured separately, down to named individuals. Warning participants that a call is recorded is your duty as the operator, and in a number of countries recording without it is unlawful.

Related topics#

• Security and data — where data lives, who has access, what to do after an incident
• Account and sign-in — passwords, device codes, support access
• Data export — take everything out before deletion
• Getting help — requesting a signed DPA and the security@ channel
• Subscription and plans — the term of the contract
• Legal documents — privacy policy and terms for your guests
• Cookies and consent — the banner and the consent log as evidence
• Customers — deleting a specific guest's data
• Employees and shifts — roles and location scope