Data Processing Agreement (GDPR Article 28)

This agreement is part of the Terms of Service and needs no separate signature, but a signed copy is available on request.

Parties:

• The Customer: the business with a Signal account, acting as controller.
• The Processor: We Do Dev Work Co., Ltd., 219/22 Sukhumvit 21 Road, Khlong Toei Nuea, Watthana, Bangkok 10110, Thailand, company registration and tax ID 0105568022029, acting as processor.

1. Subject

The Processor provides Signal ("the Service"), and in doing so processes personal data of the visitors to the Customer's website on the Customer's behalf. Annex 1 describes the processing.

2. Instructions

• The Processor processes personal data only on the Customer's documented instructions. These are: the Terms, this agreement, and the Customer's settings and configuration in the Service.
• The only exception is where EU or Member State law requires otherwise; the Processor then informs the Customer first, unless that law forbids it.
• The Processor tells the Customer if it believes an instruction breaks data protection law.

3. Confidentiality

People authorised to process the personal data are bound to confidentiality.

4. Security

The Processor takes the technical and organisational measures in Annex 2, and keeps them up to date.

5. Sub-processors

• The Customer gives general authorisation for the sub-processors in Annex 3.
• The Processor announces new or replacement sub-processors at least 30 days in advance, by email and on the sub-processor list. The Customer may object on reasonable grounds within that period. If the parties can't agree, the Customer may end the affected part of the Service and get a refund of fees paid for the time after the end.
• The Processor imposes the same data protection obligations on each sub-processor, and remains liable for them.

6. Helping the Customer

The Processor helps the Customer, as far as reasonable:

• to answer data subjects' requests: any project member can export a visitor's data and a project owner can delete it, in the dashboard or through the API
• with data protection impact assessments
• with prior consultations
• with the Customer's own security obligations

7. Personal data breaches

The Processor notifies the Customer without undue delay, and within 48 hours of becoming aware of a breach that affects the Customer's personal data. The notice includes the information the Customer needs for its own notification (GDPR art. 33).

8. End of the Service

When the Service ends, the Processor deletes the personal data within 30 days, unless law requires storage. The Customer can also delete a project or its account at any time in the dashboard, which removes the data at once. Before that, the Customer can export visitors' data through the dashboard.

9. Audits

The Processor makes available the information needed to show compliance with this agreement. The Customer may have an audit done by an independent auditor bound to confidentiality:

• once a year, with 30 days' notice
• at the Customer's cost, unless the audit finds a material breach

10. Transfers outside the EU/EEA

Only under GDPR Chapter V: an adequacy decision, or the EU standard contractual clauses (module 3 with sub-processors), with a transfer assessment where required.

11. Liability and order of precedence

Liability follows the Terms. On data protection, this agreement takes precedence over the Terms.

Annex 1: Description of the processing

• Data subjects: visitors to the Customer's website(s) where the Customer installed Signal, including people who become the Customer's leads.
• Categories of personal data:
  • random visitor and session IDs (stored in the visitor's browser: session storage by default for EU/UK projects, local storage elsewhere, or as the Customer's consent settings choose)
  • pages viewed, engagement and tracked events
  • where the visit came from (referrer host, UTM tags)
  • approximate location (country, region, city; the IP address is used for the lookup and not written to the database or logs)
  • answers to questions and forms, including free-text messages
  • facts ("traits") from answers or sent by the Customer's website
  • estimates Signal makes (for example interest and readiness), with copies of each request to the judgment model
  • contact details and consents the visitor gives (for example name, email, phone, company, fields the Customer defines)
  • outcomes (for example booked, won, value)
  • emails sent to the visitor, and their status (opened, clicked, bounced)
  • calls the visitor books in the Customer's team calendars (time, with whom, the Meet link), when the Customer connects Google Calendar
  • team alerts sent to the Customer about the visitor
• Special categories: none. The Customer must not collect them through Signal.
• Purpose: to recognise which visitors are ready to buy, ask short questions, offer ways to get in touch, alert the Customer's team, send what visitors ask for, and report to the Customer.
• Nature: collection, storage, analysis (including automated estimates by an AI model, which don't produce legal or similarly significant effects), sending emails and webhooks, creating calendar events in the Customer's own calendars, deletion.
• Duration: while the Service runs. Within it, the Customer's retention settings apply:
  • events and judgment-model runs: default 3 months
  • contact details and outcomes: default 24 months
  • a visitor who hasn't been seen for visitorMonths (default 24) is deleted with all their data The Customer can also delete a visitor or the whole project at any time.

Annex 2: Technical and organisational measures

Data handling

• Data minimisation:
  • IP addresses aren't written to the database or logs; rate limits keep them in memory for up to an hour.
  • The judgment model never receives the names, email addresses or phone numbers Signal collects.
  • The text model receives no visitor data for wording questions and offers, and refuses those requests if they contain the visitor's name, email or company. It receives a visitor's own words only to match them to the Customer's options: a typed "Something else…" answer, and, if the Customer turns on the quick answer pick, a chat message; both with email addresses and phone numbers masked, and for the pick also the visitor's known name, email and company.
• Encryption:
  • in transit: TLS (HTTPS) up to the load balancer, HSTS in production
  • at rest: database encryption at Supabase (AES-256); integration secrets additionally encrypted with AES-256-GCM under a key held outside the database
• Retention: automatic deletion per the Customer's settings, run daily: events and judgment-model runs, contact details, outcomes, and whole visitors once inactive.

Access

• Access control:
  • dashboard access by role (owner/member)
  • passwords stored with scrypt; sessions and email links stored only as hashes
  • a CSRF header is required on every state-changing request
  • rate limits on sign-in, password reset and invitations
• Production access: limited to the people at We Do Dev Work who run the Service, with access logged by AWS and Supabase.

Application security

• Application: a Content-Security-Policy that restricts the dashboard to its own origin, and security headers on every response.
• Logging: request logs keep only the method, path (no query string) and host. Unhandled errors are logged with the error. Error reports, when turned on, strip request data and mask contact details.

Continuity and people

• Resilience: managed database with automated daily backups.
• Staff: confidentiality commitments, least-privilege access.

Annex 3: Sub-processors

See the sub-processor list, kept up to date at try-signal.com/subprocessors.

Last updated: 1 November 2026