Data Processing Agreement: VivaDialog

Last updated: 25 October 2026

This Data Processing Agreement ("DPA") forms part of the Terms of Service between PT ALCHASOFT DIGITAL TEKNOLOGI (Indonesian limited liability company, NIB 2410260052309, Surabaya, Indonesia; "VivaDialog", "Processor") and the customer that uses VivaDialog for its workspace ("Customer", "Controller"). It applies when VivaDialog processes personal data on the Customer's behalf and that processing is subject to the EU or UK General Data Protection Regulation ("GDPR").

1. Roles and scope

1.1 For Customer Personal Data (Annex 1), the Customer is the controller and VivaDialog is the processor.

1.2 This DPA does not cover data that VivaDialog processes as a controller for its own purposes: the account data of the people who sign up, payment and affiliate records, and the other data described in the Privacy Policy. Paddle processes payment data as Merchant of Record under its own terms.

1.3 The Customer is responsible for having a lawful basis for the processing and for informing the people who write to its connected channels.

2. Instructions

2.1 VivaDialog processes Customer Personal Data only on the Customer's documented instructions, unless the law requires otherwise; in that case VivaDialog tells the Customer first, where the law allows.

2.2 The Customer's instructions are this DPA, the Terms of Service, and what the Customer and its users do in the service: the channels and integrations they connect, their automations, AI settings, Knowledge entries, and the replies they send. If VivaDialog believes an instruction breaks data protection law, it tells the Customer.

3. Confidentiality

Everyone VivaDialog authorizes to process Customer Personal Data is bound by confidentiality, by contract or by law.

4. Security

VivaDialog applies the technical and organizational measures in Annex 2 (Article 32 GDPR) and may update them, provided the overall level of protection does not go down.

5. Sub-processors

5.1 The Customer gives VivaDialog general authorization to use sub-processors. The current list is in Annex 3.

5.2 VivaDialog tells the Customer at least 14 days before adding or replacing a sub-processor, by email to the workspace owner or in the dashboard. The Customer may object on reasonable data protection grounds within that period, and the parties discuss the objection in good faith. If they cannot agree, the Customer may end the affected service. Ending the service on these grounds does not entitle the Customer to a refund; this applies only to an objection under this section and does not change the Refund Policy.

5.3 VivaDialog imposes on each sub-processor data protection obligations that are no less protective than this DPA, and remains responsible to the Customer for its sub-processors. This includes the providers OpenRouter uses to serve the AI models listed in Annex 3.

5.4 The services the Customer connects itself (listed under "Services the Customer connects" below) are not VivaDialog's sub-processors. The Customer chooses and controls them, and they act under their own terms with the Customer.

6. Assisting the Customer

6.1 Data subject requests. Taking into account the nature of the processing, VivaDialog helps the Customer answer requests from people exercising their rights. In the dashboard (Settings → Plan and data → Your data), the Customer can export workspace data, the workspace owner can delete the workspace, and each user can delete their own account. VivaDialog forwards to the Customer any request it receives directly about Customer Personal Data and does not answer it on the Customer's behalf unless the Customer asks.

6.2 Articles 32 to 36 GDPR. VivaDialog helps the Customer with security, personal data breach notification, data protection impact assessments and prior consultation with a supervisory authority, using the information available to VivaDialog.

7. Personal data breaches

VivaDialog notifies the Customer of a personal data breach affecting Customer Personal Data without undue delay, and no later than 72 hours after becoming aware of it, by email to the workspace owner. The notice includes what is known at the time: the nature of the breach, the categories and approximate number of people and records concerned, the likely consequences, and the measures taken or proposed. VivaDialog adds information as it becomes available.

8. Deletion and return at the end of the service

8.1 Before the service ends, the Customer can export workspace data in the dashboard (Settings → Plan and data → Your data).

8.2 When the workspace owner deletes the workspace, its data is deleted at once.

8.3 When access ends without the workspace being deleted, VivaDialog deletes the workspace data automatically. Today this happens 30 days after a trial or paid period ends without a new one. After the subscription terms take effect, as announced, a workspace that has paid before becomes dormant instead of being deleted, and conversations in it with no activity for 12 months are deleted, as described in section 5 of the Privacy Policy.

8.4 Copies in database backups are deleted when the backup is deleted, within 30 days.

8.5 VivaDialog keeps Customer Personal Data longer only where the law requires it, and confirms deletion on request.

9. Information and audits

VivaDialog makes available the information needed to show that it meets this DPA, and allows audits by the Customer or an auditor the Customer appoints. Audits are carried out first through documents and written answers; an on-site audit takes place only where those are not enough, with reasonable notice, during business hours, under confidentiality, and at the Customer's cost.

10. International transfers

10.1 VivaDialog is based in Indonesia. The servers that store Customer Personal Data are in the United States, except media files the Customer uploads for scheduled posts, which are stored in Cloudflare R2 in Asia-Pacific (Annex 3). Customer Personal Data from the European Economic Area, the United Kingdom or Switzerland is therefore transferred outside those areas.

10.2 Where Customer Personal Data from the European Economic Area or Switzerland is transferred to a country without an adequacy decision, the Standard Contractual Clauses adopted by the European Commission in Implementing Decision (EU) 2021/914, Module Two (controller to processor), are incorporated into this DPA by reference, with the Customer as data exporter and VivaDialog as data importer, and with these choices: the optional docking clause (Clause 7) applies; under Clause 9(a), Option 2 (general written authorization) applies, with the notice period in section 5.2; the optional wording in Clause 11 does not apply; under Clause 17, Option 2 applies: the Clauses are governed by the law of the EU Member State in which the data exporter is established, or, where that law does not allow for third-party beneficiary rights, by the law of Ireland; under Clause 18, disputes are resolved by the courts of the EU Member State in which the data exporter is established; and under Clause 13, the competent supervisory authority is that of the data exporter. Annexes 1 to 3 of this DPA complete the Annexes of the Clauses. For transfers from the United Kingdom, the International Data Transfer Addendum issued by the UK Information Commissioner (version B1.0) applies in addition to those Clauses. Its Tables 1 to 3 are completed with the details in this DPA and its Annexes, and under Table 4 both the importer and the exporter may end the Addendum as allowed by its Section 19. If this DPA conflicts with the Clauses, the Clauses prevail.

10.3 VivaDialog has not appointed a representative in the European Union or the United Kingdom under Article 27 GDPR.

10.4 For transfers subject to the Swiss Federal Act on Data Protection (FADP), the Clauses in section 10.2 apply with these adaptations: references to the GDPR are read as references to the FADP; the Swiss Federal Data Protection and Information Commissioner (FDPIC) is the competent supervisory authority; and the term "Member State" is not interpreted so as to exclude data subjects in Switzerland from bringing claims for their rights in their place of habitual residence.

11. Term and precedence

This DPA applies as long as VivaDialog processes Customer Personal Data. If it conflicts with the Terms of Service on data protection, this DPA prevails.

Annex 1: Details of processing

• Subject matter and purpose: providing the unified inbox and automation service: receiving, storing, showing and answering comments and direct messages from the channels the Customer connects and from the Customer's website chat widget; contacts, tags, notes and stages; automations and flows; AI replies, the AI Agent with the Customer's Knowledge entries, and AI summaries; scheduled posts; the weekly email; the Public API, MCP and outgoing webhooks; and the integrations the Customer turns on.
• Nature of the processing: collection through the platforms' APIs, storage, organization, display, search, sending replies, AI processing of message text, export and deletion.
• Duration: while the Customer uses the service, plus the deletion periods in section 8.
• Categories of data subjects:
• people who comment on or send messages to the Customer's connected channels (Facebook Pages, Instagram, Threads, Telegram bots, email mailboxes) and people who comment on the Customer's YouTube videos;
• visitors to the Customer's website who write through the VivaDialog chat widget;
• the Customer's own customers whose payments reach the service through the Customer's Stripe integration;
• the users of the Customer's workspace (team members).
• Categories of personal data:
• names, usernames and handles, and platform ids (for example Facebook and Instagram ids, Telegram user ids, YouTube channel ids);
• email addresses of people who write to a connected mailbox;
• message and comment content, subjects of emails, attachment names, types and sizes (not the files), timestamps and conversation history;
• what the Customer's team adds: tags, notes, stages, assignments, Knowledge entries;
• from Stripe events: customer id, email, name, phone, amount, currency and payment status;
• contact details a person gives in answer to a flow question: email address, phone number, or another detail the Customer asks for;
• for website chat visitors: a random ID, a hash of their session token, when they were created and last seen, their messages and the replies to them, a contact without a name and a conversation, and any detail they enter when a flow asks for it. Their IP address and browser details (User-Agent) are not stored; the IP address is used for at most 10 minutes to limit abuse;
• for team members: name, email, role, sessions and two-step login status.
• Special categories: none intended. Message content may contain them if a person chooses to write them.
• Frequency: continuous.

Annex 2: Technical and organizational measures

• Encryption in transit: HTTPS for the dashboard and API; certificates issued and renewed automatically by Caddy (Let's Encrypt).
• Encryption at rest of credentials: OAuth tokens, Telegram bot tokens, mailbox app passwords and Stripe webhook signing secrets are encrypted with AES-256-GCM before they are stored, and never sent to the browser.
• Tenant separation: every workspace's data is scoped to that workspace; members only reach the workspaces they belong to.
• Roles: each workspace user is an owner, admin or operator, and the server checks the role before changes to settings and data.
• API keys: stored only as a hash; the full value is shown only once, when the key is created.
• Login security: two-step login with an authenticator app (TOTP), an email when a wrong code is entered, and a list of active sessions that users can sign out.
• Abuse limits: rate limits on Redis for public endpoints.
• Logging: email sending and the weekly summary log ids and counts, not addresses or message text.
• AI: message text goes to the AI provider without tools for the model, and the output is filtered before it is sent. For the weekly AI summary, links, email addresses and phone numbers are masked first. Message content is not used to train AI models.
• Backups: a database backup is taken before every deploy, backups are deleted after 30 days and a script exists to test restoring a backup.
• Retention and deletion: self-service export and deletion; automatic deletion after access ends; YouTube data deleted 30 days after it is stored.
• Server access: deploys and operations on the server run under one dedicated account; secrets are set with a script and never sent in chat.
• Code checks: secret scanning (Gitleaks), static analysis (Semgrep) and dependency scanning (OSV-Scanner) run in CI.

Annex 3: Sub-processors

OpenRouter chooses the provider that serves each model from providers that, under OpenRouter's provider data policies, do not store prompts beyond processing the request and do not use them for training. Locations are where the servers are today; this annex is updated when the service moves to a new server. If a Customer uses its own AI key (BYOK), message text goes to the AI provider the Customer chose instead, under that provider's terms. Changes to this list are announced as described in section 5.2.

Services the Customer connects (not sub-processors)

These services are connected and controlled by the Customer. VivaDialog exchanges data with them on the Customer's instruction, and they process it under their own terms with the Customer:

• Meta (Facebook Pages, Instagram, Threads): reading and sending comments and messages for the accounts the Customer connects.
• Telegram: receiving and sending messages for the bot the Customer connects.
• The Customer's email provider: reading the INBOX and sending replies for the mailbox the Customer connects (IMAP and SMTP).
• YouTube (YouTube API Services): reading the videos and comments of the channel the Customer connects.
• Google Sheets: adding rows to the spreadsheet the Customer chooses.
• Stripe: Stripe sends events from the Customer's own Stripe account to VivaDialog. VivaDialog sends nothing to Stripe.