Data Processing Agreement

The full Data Processing Agreement

1. Parties and scope

1.1 This Data Processing Agreement ("DPA") is between the customer that accepted the mlivechat Terms of Service ("Customer") and mlivechat ("Processor", "we"). It forms part of the Terms and applies whenever we process Customer Personal Data.

1.2 If this DPA conflicts with the Terms on data protection, this DPA prevails. If it conflicts with the Standard Contractual Clauses, the Standard Contractual Clauses prevail.

2. Definitions

• "Applicable Data Protection Law": every law on personal data that applies to the processing under this DPA, including Singapore's Personal Data Protection Act 2012 ("PDPA") and its regulations; Regulation (EU) 2016/679 ("GDPR") and the UK GDPR where they apply; and the Philippines' Data Privacy Act of 2012 (RA 10173) where it applies.
• "Customer Personal Data": personal data within Customer Data (as defined in the Terms) that we process on the Customer's behalf.
• "Controller", "Processor", "Data Subject", "Personal Data Breach", "Processing": as defined in the GDPR. Under the PDPA, the Customer is the "organisation" and we are its "data intermediary"; references to Controller and Processor include those roles.
• "Sub-processor": a third party we engage to process Customer Personal Data.
• "SCCs": the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914.

3. Roles

3.1 The Customer is the Controller of Customer Personal Data. We are its Processor.

3.2 The Customer is responsible for the lawfulness of its instructions and of the collection of Customer Personal Data, including giving Visitors notice, obtaining any required consent (including for the storage the widget uses on the Customer's website), and responding to Data Subjects.

3.3 For Account Data used to administer the account (for example the owner's email address for billing and notices), we act as an independent controller under our Privacy Policy.

4. Processing details

The subject matter, duration, nature and purpose of processing, and the types of data and Data Subjects, are set out in Annex 1.

5. Our obligations (GDPR Art. 28(3); PDPA s.24, 25 and 26C)

5.1 Documented instructions (Art. 28(3)(a)). We process Customer Personal Data only on the Customer's documented instructions, including on transfers to third countries, unless the law requires otherwise (in which case we will inform the Customer first unless the law forbids it). The Terms, this DPA, and the Customer's configuration and use of the Service (for example its settings, webhooks, bots and data-deletion actions) are the Customer's complete instructions. We will tell the Customer at once if we believe an instruction infringes Applicable Data Protection Law.

5.2 Confidentiality (Art. 28(3)(b)). We ensure that everyone we authorise to process Customer Personal Data is bound by confidentiality, and that access is limited to those who need it to provide, secure or support the Service.

5.3 Security (Art. 28(3)(c), Art. 32; PDPA s.24). We implement and maintain the technical and organisational measures in Annex 2. We may update them, provided the overall level of protection is not reduced.

5.4 Sub-processors (Art. 28(2) and (4)). See section 6.

5.5 Data Subject requests (Art. 28(3)(e)). Taking into account the nature of the processing, we assist the Customer by appropriate technical and organisational measures in responding to requests to exercise Data Subject rights. The Service lets the Customer's agents read and correct customer records and lets the owner delete a Visitor's data or all chats. If we receive a request directly, we will forward it to the Customer without undue delay and will not respond ourselves except to direct the Data Subject to the Customer.

5.6 Assistance (Art. 28(3)(f)). We assist the Customer, taking into account the information available to us, with its obligations on security, breach notification, data protection impact assessments and prior consultation (GDPR Art. 32–36). This assistance is free of charge where the self-serve tools in the console do not cover it, unless it takes substantial time, in which case we agree a reasonable fee with the Customer in advance.

5.7 Personal Data Breach (Art. 33(2); PDPA s.26C(3)). We will notify the Customer without undue delay, and in any case within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data (under the PDPA: after having credible grounds to believe a data breach has occurred). The notice will describe, as far as known, the nature of the breach, the categories and approximate number of Data Subjects and records, the likely consequences, and the measures taken or proposed. We will provide further information as it becomes available and take reasonable steps to contain the breach. Notifying the Customer is not an admission of fault. The Customer is responsible for notifying regulators and Data Subjects (PDPC within 3 calendar days of assessing a breach as notifiable; GDPR supervisory authority within 72 hours; Philippines NPC within 72 hours where the Data Privacy Act applies).

5.8 Deletion or return (Art. 28(3)(g); PDPA s.25). During the subscription the Customer can delete Customer Personal Data itself (section 8 of the Terms). On termination, we delete Customer Personal Data within 30 days, and from backups within 14 days, unless the law requires us to keep it. Before deletion, the Customer may retrieve its data by reading its chats, archives and customers through the API, or by asking us for a machine-readable (JSON) copy of its chats. We stop retaining Customer Personal Data once retention no longer serves the purposes in Annex 1 or a legal purpose.

5.9 Information and audits (Art. 28(3)(h)). We make available to the Customer the information necessary to demonstrate compliance with this DPA, including this DPA's annexes and written answers to reasonable security questionnaires, no more than once per year unless a breach or a regulator requires more. If that information is not sufficient, the Customer (or an independent auditor bound by confidentiality, not a competitor of ours) may audit our compliance on at least 30 days' notice, during business hours, at the Customer's cost, in a way that does not compromise other customers' data or our security. We do not hold third-party certifications or audit reports, and none is offered in place of an audit.

5.10 Records. We maintain records of processing activities carried out on behalf of the Customer as GDPR Art. 30(2) requires.

6. Sub-processors

6.1 The Customer gives general authorisation for us to engage Sub-processors. The current list is in Annex 3.

6.2 We will notify the Customer of any intended addition or replacement at least 30 days in advance, by email to the organisation owner and on https://mlive.chat/legal/dpa/ (Annex 3). The Customer may object on reasonable data-protection grounds within that period. We will then discuss the objection in good faith; if we cannot resolve it, the Customer may terminate the affected Service and receive a pro-rata refund of prepaid fees.

6.3 We impose on each Sub-processor, by written contract, data protection obligations that offer at least the same protection as this DPA, and we remain liable to the Customer for each Sub-processor's performance.

7. International transfers

7.1 Hosting location. Customer Personal Data is stored and processed primarily in Huawei Cloud's AP-Singapore region. We will not change the primary hosting region without notice under section 6.2.

7.2 Transfers out of Singapore (PDPA s.26). Where Customer Personal Data is transferred outside Singapore (see Annex 3), we will ensure the recipient is bound by legally enforceable obligations, such as contractual clauses meeting regulation 10(2) of the Personal Data Protection Regulations 2021, to provide a standard of protection comparable to the PDPA.

7.3 Transfers from the EEA, UK or Switzerland. Singapore is not covered by an EU adequacy decision. To the extent the Customer (or its Visitors' data) is subject to GDPR and the processing involves a restricted transfer to us, the SCCs apply as set out in Annex 4, and are incorporated into this DPA by reference.

7.4 Onward transfers. We transfer Customer Personal Data onward only to Sub-processors listed in Annex 3 and under safeguards that satisfy Applicable Data Protection Law.

8. Government access requests

If a public authority requests access to Customer Personal Data, we will (unless the law forbids it) notify the Customer promptly, challenge requests we reasonably consider unlawful, and disclose only the minimum required.

9. Liability

Each party's liability under this DPA is subject to the limitations in the Terms, except where Applicable Data Protection Law or the SCCs forbid such limitation.

10. Term

This DPA lasts as long as we process Customer Personal Data, and survives termination of the Terms until deletion under section 5.8 is complete.

11. Governing law

This DPA is governed by the law governing the Terms (the laws of Singapore), except that the SCCs are governed by the law stated in Annex 4.

---

Annex 1: Description of processing

Item	Description
Subject matter	Provision of the mlivechat live-chat service to the Customer
Duration	The term of the subscription plus the deletion period in section 5.8
Nature of processing	Collection through the widget, storage, retrieval, display to agents, real-time transmission, routing to agents and bots, aggregation into reports, delivery to the Customer's webhooks and bots, sending notification emails, deletion
Purpose	Enabling the Customer to chat with visitors to its websites, manage its team, and review chat history and reports
Categories of Data Subjects	(a) Visitors to the Customer's websites who load or use the chat widget; (b) the Customer's agents, administrators and owners
Categories of personal data: Visitors	Chat messages; files sent in chat (up to 10 MB, executables refused); name and email address if provided; pre-chat and offline form answers; pages visited while the widget is loaded (URL, title, time) and referrer; IP address; browser and operating system (from the user-agent string); city and time zone only if sent by the Customer's site as session fields (no IP geolocation); other session fields set by the Customer's site (up to 50 values); chat ratings, tags, timestamps, online status; ban status; a hashed visitor identity token
Categories of personal data: Agents	Name, email address, role, job title, avatar, groups and priorities, routing status history, chat assignments, messages and internal notes written in chats, sign-in session records (hashed)
Special categories	None intended. The Customer must not instruct Visitors to send special-category data (Terms 5.3). Free-text chat may contain whatever a Visitor chooses to type.
Frequency	Continuous
Retention	Until the Customer deletes it or the subscription ends (section 5.8); uploaded but unsent files 24 hours; completed background jobs 1 hour; sessions 30 days sliding; visitor identity token 2 years (stored as a hash on our side)

Annex 2: Technical and organisational measures

These are the measures implemented in the Service as of 13 November 2026, as documented in the internal security review dated 11 November 2026 (updated 12 November 2026).

Tenant isolation

• Every customer table in the database enforces row-level security (enabled and forced); the application's database role cannot bypass it, and a query without an organisation context fails closed.
• Real-time messages are published on per-organisation channels derived from the authenticated session, never from user input.
• Stored files are keyed by organisation and chat; downloads check that the requester may see that chat.

Authentication and access control

• Passwords are hashed with argon2id (RFC 9106 parameters); unknown emails take the same time.
• Session, invite, reset, bot and visitor tokens are 32 random bytes, stored only as SHA-256 hashes; one-time tokens are single-use.
• Email addresses must be confirmed before an account is created or joins an organisation.
• Console sessions use an HttpOnly, Secure, SameSite=Lax cookie with cross-site request forgery protection; sessions expire after 30 days of inactivity and are revoked on password reset.
• Role-based access control is checked on every API operation (owner, vice-owner, administrator, agent, bot, visitor); agents see only chats of their groups or assigned to them.
• Email invites expire after 7 days; bot tokens can be rotated, which revokes earlier tokens immediately.
• Only the organisation owner can bulk-delete data, behind a typed confirmation.

Transmission and storage

• Traffic is served over HTTPS; API responses send HSTS, a restrictive Content-Security-Policy, X-Frame-Options DENY, nosniff, a Referrer-Policy and no-store.
• Files are kept in a private object-storage bucket; access is through presigned links that expire after 5 minutes, and the signed upload size is enforced by storage.
• Webhook signing secrets and queued email contents are encrypted with AES-256-GCM.
• Encryption at rest of the database and object storage: the database disk is encrypted with a dedicated key in Huawei Cloud Key Management Service, and object storage uses server-side encryption with KMS keys.

Abuse resistance

• Rate limits are applied per IP address (IPv6 per /64), per email address and per organisation, shared across servers.
• Webhook destinations must be public HTTPS addresses, re-checked at every delivery, to prevent server-side request forgery.
• Message, frame and request body sizes are bounded; executable file types are refused.

Data minimisation and logging

• Request logs never include query strings (which can carry tokens). Mail logs record recipient and subject only.
• Background jobs that carry message content are removed 1 hour after completion.
• No IP geolocation, maps or third-party tracking run in the widget or console.

Deletion

• Owner-initiated deletion is a hard delete of the database records; stored files are removed from object storage after the deletion.

Engineering practice

• Each security fix is backed by an automated test; the codebase is checked by static security analysis and a known-vulnerability scan of called dependencies.

Organisational

• Access to production systems is limited to the named engineers who operate the Service, through individual accounts with only the rights their work needs; access is removed when they leave.
• Backups: a full encrypted database backup every night (02:00 Singapore time), with changes recorded continuously in between, kept in the AP-Singapore region for 14 days.
• Monitoring and incident response: automated alerts on errors, slow responses, failed health checks, connection load and database load; an engineer investigates each alert, contains and records any incident, and notifies affected Customers as section 5.7 requires.
• Two-step sign-in (authenticator app codes with one-time recovery codes) is available to every user; a customer can require it for all of its users. Changing a password or two-step setting ends the account's other sessions.

Annex 3: Sub-processors

Sub-processor	Service	Data processed	Location	Transfer safeguard
Huawei Cloud (AP-Singapore region, ap-southeast-3)	Compute, managed database and cache, object storage (OBS), content delivery network	All Customer Personal Data	Singapore (AP-Singapore region); CDN edge locations may cache public widget files outside Singapore	Data stored in Singapore; Huawei Cloud's data processing terms accepted with the cloud account
Resend	Transactional email (account confirmation, invites, password resets, offline-message and data-deletion notices)	Agent email addresses and names; for offline-message notices, the Visitor's name, email and message as sent to the Customer's admins	United States; mail is sent from its Tokyo, Japan region	Resend's Data Processing Agreement (PDPA reg. 10 contract clauses; SCCs where GDPR applies)
Cloudflare	DNS for our domains; Turnstile bot checks on the console sign-in and on our website's contact form	No chat content: the IP address and browser signals of the person signing in or sending the form	Global network (Cloudflare, Inc., United States)	Cloudflare's Data Processing Addendum (SCCs where GDPR applies)

Annex 4: Standard Contractual Clauses (EU and UK)

Where section 7.3 applies:

1. Modules. Module Two (controller to processor) applies where the Customer is a controller; Module Three (processor to processor) applies where the Customer is itself a processor for its own client.
2. Clause 7 (docking clause): applies.
3. Clause 9 (sub-processors): Option 2, general written authorisation, with the notice period in section 6.2.
4. Clause 11 (redress): the optional language does not apply.
5. Clause 13 (supervision): the supervisory authority of the Customer's EU establishment, or of its EU representative, or otherwise the Data Protection Commission of Ireland.
6. Clause 17 (governing law): the law of Ireland (an EU member state).
7. Clause 18 (forum): the courts of Ireland.
8. Annex I of the SCCs is completed by Annex 1 of this DPA (parties: the Customer as data exporter, mlivechat as data importer); Annex II by Annex 2; Annex III by Annex 3.
9. UK: for transfers subject to the UK GDPR, the UK International Data Transfer Addendum to the EU SCCs (version B1.0) applies, with Table 1 to 3 completed from this DPA, and either party may end it as Section 19 of the Addendum allows.
10. Switzerland: references to the GDPR are read as references to the Swiss Federal Act on Data Protection where it applies, and the Swiss FDPIC is the competent authority.

---

Signed for the Customer: __________________ Name: __________ Title: __________ Date: ______

Signed for mlivechat: __________________ Name: __________ Title: __________ Date: ______