DRAFT FOR COUNSEL REVIEW — NOT LEGAL ADVICE, NOT YET IN EFFECT. A data-processing addendum template prepared 2026-07-03 by the engineering team, describing what the system actually does (verified at commit 3b50d5d; gaps in MISMATCHES.md). Counsel must supply the operative legal framework (GDPR Art. 28 clauses, SCCs where relevant, CCPA service- provider terms). Placeholders [BRACKETED].

Data Processing Addendum (template)

Between [CUSTOMER LEGAL NAME] ("Customer", the controller) and [COMPANY LEGAL NAME] operating Sonder ("Processor"). This DPA is part of the Terms of Service.

1. Subject matter and roles

Processor provides UX-friction analytics: the Customer installs Processor's SDK in Customer's product; Processor ingests masked behavioral events, derives tracked UX issues, and reports on them. Customer is the controller of end-user personal data so processed; Processor acts only on Customer's documented instructions (this DPA, the Terms, and configuration the Customer sets in the product).

2. Categories of data subjects and data

• Data subjects: end users of Customer's product.
• Data categories (deliberately narrow):
  • pseudonymous session identifiers (random, per browser tab);
  • a Customer-supplied person identifier, only if Customer calls identify();
  • masked semantic interaction events (element labels, roles, selectors, section headings, parametrized routes, timestamps, counts);
  • masked friction-time state probes (visible error text, empty/loading/ disabled indicators);
  • masked traits or event properties the Customer chooses to send.
• Not processed by design: form input values, screenshots, session recordings, raw HTML/DOM, precise geolocation, mouse-movement streams.
• Special categories (GDPR Art. 9): not intended and not knowingly processed. Customer agrees not to configure the product to send them (Terms §4). Masking at edge and server reduces residual risk; it does not make intentional collection acceptable.

3. Duration, retention, deletion

Processing lasts for the agreement term. Raw events are retained for the Customer-configured window (default 90 days; configurable 1–730 days — [see MISMATCHES.md #2: >90-day raw retention is not currently honored; cap the contractual range at 90 days until fixed]), enforced by a scheduled purge job that writes an audit record. On termination or on Customer instruction, Processor deletes Customer workspace data. Delete-by-person: on Customer request via the API/dashboard, derived per-person records are deleted immediately and an auditable deletion record is written; residual raw masked events referencing the person identifier are removed by the retention purge, i.e. within the configured retention window (at most 90 days) [see MISMATCHES.md #1; counsel should confirm this satisfies the intended Art. 17 / CCPA deletion commitment or require an engineering fix first].

4. Subprocessors

Customer authorizes the subprocessors listed in the Privacy Policy §3 (GCP, ClickHouse Cloud, Supabase, DeepSeek, Stripe, Slack, Resend — the latter three only when the corresponding feature is enabled). Processor will provide [30] days' notice of additions via [email to workspace owners], with a right to object.

DeepSeek is flagged explicitly: masked, aggregated behavioral ribbons are sent to the DeepSeek API for issue diagnosis. Payloads contain no input values, screenshots, or raw PII (masking runs twice before diagnosis), but the person identifier the Customer supplies may appear in cohort references. [COUNSEL + CUSTOMER: assess DeepSeek's retention/training terms and cross-border posture; consider requiring the "bring your own model endpoint" configuration (DEEPSEEK_BASE_URL is already configurable) for sensitive customers.]

5. Data residency and transfers

All storage and processing in the United States during beta. EU residency is roadmapped, not available. [COUNSEL: if Customer has EEA/UK end users, attach SCCs/IDTA and a transfer impact assessment covering the US stores and the DeepSeek API; otherwise restrict the agreement to non-EEA data.]

6. Security measures (Annex II summary)

As described in the Security Overview: TLS 1.2+ in transit; provider-managed encryption at rest; PII masking in the SDK and again at ingest; write-only public ingest keys; hashed, scoped API keys; per- workspace row-level security on the control plane and workspace-scoped queries on the event store; role-based access (owner/admin/member/viewer); secrets in GCP Secret Manager; structured logs without PII; audited retention purges and deletion records. No replay video; no autonomous outbound contact with data subjects.

7. Assistance, audits, incidents

Processor will: assist Customer with data-subject requests via the tooling in §3; notify Customer without undue delay (target [72 hours]) after becoming aware of a personal-data breach affecting Customer data; make available information reasonably necessary to demonstrate compliance, and allow audits [COUNSEL: scope — questionnaire-first, on-site only where legally required; note there is no SOC 2 report yet, see Security Overview].

8. Return and deletion on termination

On termination, Customer may export issue and configuration data via the API before deletion. Processor deletes workspace data within [30] days, subject to the raw-event retention mechanics in §3 and legally required backups [COUNSEL: verify backup posture claim against docs/RUNBOOK.md before signing].