The subject matter of the processing is the operation of the Service: consent-based, on-page co-browsing between the Controller’s support agents and visitors of the Controller’s websites, including the optional callback queue and browser voice calls.

This DPA applies for as long as the Processor processes personal data on behalf of the Controller under the service agreement, and ends automatically when the Controller’s workspace is deleted and all associated data has been erased in accordance with Section 10.

The Service is deliberately built so that the content of a co-browsing session — the visitor’s page, everything the visitor sees, types, or does, and the audio of a voice call — travels peer-to-peer between the visitor’s and the agent’s browsers over an end-to-end DTLS-encrypted WebRTC channel. This content is never transmitted to, stored on, or readable by the Processor’s systems.

The Processor’s backend processes only what is technically required to broker and manage sessions:

• connection brokering (“signaling”): short-lived WebRTC handshake metadata (session descriptions, network candidates) — never page content;
• session management data: support codes, session status records, and the configuration of the Controller’s workspace, apps, and permission ceilings;
• callback requests: the phone number and optional name a visitor submits to be called back;
• agent account data: e-mail address, display name, optional profile photo, and availability status of the Controller’s team members;
• relay fallback: where a direct peer-to-peer connection cannot be established, the encrypted stream is relayed through a TURN server. The relay forwards encrypted packets and cannot decrypt them; no content is stored.

The purpose of the processing is exclusively the provision of the Service to the Controller. The Processor does not process personal data of the Controller’s visitors or agents for its own purposes, and does not sell or advertise on such data.

Data subjects:

• visitors of the Controller’s websites who actively request or consent to a co-browsing session, callback, or voice call;
• the Controller’s staff (agents, administrators, owners) using the dashboard.

Categories of personal data processed on the Processor’s systems:

• for visitors: IP address and connection metadata (transient, for signaling and relay), phone number and optional name (only if a callback is requested), browser language, and the page URL a request was made from;
• for staff: e-mail address, display name, optional profile photo, authentication identifiers, availability status, and session activity records (which agent ran which session, when).

Session content (the mirrored page, form inputs, pointer activity, annotations, and call audio) is exchanged directly between the browsers of the data subjects involved and is not processed on the Processor’s systems. Password fields are always excluded from mirroring at the source; the Controller can exclude any further element via the provided masking attributes.

The Service is not intended for processing special categories of personal data (Art. 9 GDPR). Whether such data appears within a co-browsed page is under the Controller’s control (through masking and the permission ceiling).

The Processor processes personal data only on documented instructions from the Controller (Art. 28(3)(a) GDPR). The functionality of the Service, as configured by the Controller in its workspace (permission ceilings, masking, widget features, service hours, retention defaults), constitutes the Controller’s general instruction. Individual instructions may be given in text form to the contact address in the legal notice.

The Processor shall inform the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other applicable data protection provisions.

The Processor ensures that all persons authorised to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3)(b) GDPR), and that they process such data only on instruction.

The Processor implements and maintains the technical and organisational measures described in Annex 1. The parties agree that the Service’s core architectural guarantee — session content never reaching the Processor’s systems — is itself the primary technical measure, complemented by encryption, access control, tenant isolation, and automatic data expiry.

The Processor may update the measures as technology develops, provided the level of protection does not fall below that of Annex 1.

The Controller grants a general authorisation (Art. 28(2) GDPR) for the engagement of the sub-processors listed in Annex 2. The Processor shall inform the Controller of any intended addition or replacement of sub-processors at least 30 days in advance (by e-mail to the workspace owner), giving the Controller the opportunity to object on reasonable data protection grounds. If an objection cannot be resolved, the Controller may terminate the affected service.

The Processor imposes on every sub-processor, by way of contract, the same data protection obligations as set out in this DPA, and remains fully liable to the Controller for the performance of the sub-processor’s obligations.

Taking into account the nature of the processing, the Processor assists the Controller with appropriate technical and organisational measures in fulfilling the Controller’s obligations to respond to data subject requests (Art. 12–23 GDPR) — noting that, by architecture, the Processor holds very little personal data that could be the subject of such requests — and in ensuring compliance with the obligations under Art. 32–36 GDPR (security, breach notification, data protection impact assessments, prior consultation), insofar as information available to the Processor is required.

The Processor shall notify the Controller without undue delay after becoming aware of a personal data breach affecting personal data processed on behalf of the Controller. The notification shall contain the information required under Art. 33(3) GDPR to the extent available, and the Processor shall reasonably cooperate in the investigation and mitigation.

All session-scoped data carries an automatic expiry and is hard-deleted on schedule (see Annex 3) — deletion is the default, not a request. Upon termination of the Service, or upon deletion of the Controller’s workspace by the Controller, the Processor deletes all remaining personal data processed on behalf of the Controller without undue delay, unless storage is required by Union or Member State law. Because session content is never stored, there is no session content to return or delete.

The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR — in particular this DPA, the public technical documentation of the architecture, and the current list of sub-processors — and allows for and contributes to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller. Audits shall be announced with reasonable notice, conducted during business hours, and no more than once per year unless a personal data breach or a supervisory authority gives specific cause.

The Processor stores backend data (Section 2) in data centres in the European Union. Where a sub-processor’s parent entity is established outside the EU/EEA, or where a technically transient transfer occurs (e.g. the globally routed TURN relay fallback), the transfer is safeguarded by an adequacy decision pursuant to Art. 45 GDPR (including the EU–US Data Privacy Framework, where certified) and/or the European Commission’s Standard Contractual Clauses pursuant to Art. 46(2)(c) GDPR, as listed per sub-processor in Annex 2.

This DPA is concluded electronically via the Controller’s workspace dashboard (Art. 28(9) GDPR permits electronic form). The signature recorded in the signature block below — the full name of an authorised representative of the Controller, together with a timestamp and the signing account — constitutes the Controller’s binding acceptance. The Processor accepts by making the signing flow available; the countersigned record is available to the Controller’s workspace at any time.

Liability follows the statutory rules of Art. 82 GDPR and the liability provisions of the service agreement. Should individual provisions of this DPA be invalid, the validity of the remaining provisions remains unaffected.

• Data minimisation by architecture: session content (mirrored DOM, inputs, annotations, call audio) is exchanged peer-to-peer between the participating browsers over WebRTC and never transits or rests on the Processor’s backend.
• Encryption in transit: all WebRTC channels are end-to-end encrypted (DTLS for data, DTLS-SRTP for audio); all backend communication uses TLS; the TURN relay fallback forwards encrypted packets it cannot decrypt.
• Encryption at rest: all backend data is stored on managed infrastructure with encryption at rest enabled by default.
• Consent and control at the source: no mirroring starts before the visitor’s explicit consent; the visitor sees who is connected, can move the agent’s presence indicator, and can end the session at any time.
• Capability enforcement on the visitor’s side: what an agent may do (see, point, scroll, type, click) is capped by a per-app permission ceiling enforced in the visitor’s browser — a capability that is switched off is technically impossible, not merely forbidden.
• Input masking: password fields are always excluded from mirroring; any element can be excluded via a masking attribute or CSS class.
• Automatic data expiry: every session-scoped record carries a time-to-live and is hard-deleted on schedule (Annex 3).
• Tenant isolation: workspaces are strictly isolated by server-side security rules; access requires authenticated membership in the workspace.
• Access control: dashboard access uses passwordless authentication (verified e-mail magic link or Google sign-in); roles (owner, admin, agent, viewer) restrict administrative functions; short-lived, per-session relay credentials are minted server-side.
• Serverless, managed infrastructure: no self-operated long-running servers; patching and physical security are provided by the certified providers in Annex 2 (ISO 27001, SOC 2).

• Google Cloud EMEA Ltd. / Google LLC (Firebase: Firestore, Authentication) — database and authentication for signaling metadata, workspace configuration, and session management data; data location: EU region (europe-west); safeguards: EU–US Data Privacy Framework, SCCs.
• Vercel Inc. — hosting of the web application, the embeddable snippet, and the serverless API endpoints; processes transient request metadata (IP addresses); safeguards: EU–US Data Privacy Framework, SCCs.
• Cloudflare, Inc. — TURN relay fallback for WebRTC connections that cannot be established directly; forwards end-to-end-encrypted packets only, globally routed; safeguards: EU–US Data Privacy Framework, SCCs.

The current list is also published on the technical FAQ page. Changes are announced per Section 7.

• WebRTC signaling messages: deleted within 1 hour of writing;
• support codes: expire after 5 minutes, records swept within ~15 minutes;
• agent availability heartbeats: deleted 24 hours after the last update;
• callback requests (contain a phone number): deleted after 30 days;
• voice call records (metadata only): deleted after 7 days;
• session records (metadata only — participants, timing, status): deleted after 90 days;
• session content: never stored — nothing to retain or delete.