Data processing agreement

Parties: the customer ("Controller") and [LEGAL ENTITY: OPEN] ("Processor", "we"). Incorporated into the Terms of Service. If a customer is itself a processor for its own clients (agencies), these terms apply as sub-processing OPEN.

1. Roles

1.1 The customer is the controller of personal data in its website content and of its visitors' personal data. We process it on its behalf. We are an independent controller of the customer's account, billing and support data, described in the Privacy Policy. 1.2 If the customer supplies its own translation-provider key, that provider acts for the customer; we only transmit text on its instruction. Bring-your-own keys are not implemented today (no caller passes them), so this clause cannot yet be offered. The default is that text goes to whichever engine automatic selection picks among those enabled, and no filter removes personal data first. 1.3 OPEN (counsel): purposes for which we may use customer content beyond instructions: (a) shared translation memory, off by default and opt-in on both sides; (b) abuse and security review of quarantined discover submissions; (c) support access; (d) service improvement (none is planned; do not allow it by default).

2. Subject matter, duration, nature, purpose (Annex I)

• Subject matter: extracting, storing, translating, reviewing, signing and publishing the customer's website text, and serving translated files.
• Duration: the term of the agreement plus the retention in RETENTION_SCHEDULE.md.
• Nature: storage, machine and human translation workflow, publication of static files to storage/CDN, delivery logs.
• Categories of data subjects: visitors of the customer's websites; people named or quoted in the customer's content; the customer's staff using the dashboard (as to the processing in section 1.1 only).
• Types of data: source strings, page URLs (currently with query strings: G2), translations, glossaries, translation memory; for visitors: IP address, user agent, Origin/Referer seen by CDN/storage and API gateway logs; a language choice and cached bundles in the visitor's own browser (stored on the visitor's device, never sent to us).
• Special categories / criminal-conviction data: not intended; the customer must not submit them (AUP). OPEN: how to treat if they appear in content.

3. Instructions (Art. 28(3)(a))

We process only on the customer's documented instructions: the agreement, dashboard and API settings (for example "exclude from machine translation" selectors, do-not-translate glossary, per-tenant "no third-party machine translation" mode where available, auto-publish off by default) and its written instructions. Transfers outside the EEA/UK only as in section 11. We tell the customer if we believe an instruction infringes data-protection law. Status: exclusion selectors/glossary:; a tenant-level "no third-party MT" switch is required by PRIVACY.md section 3 but its presence in code is verify.

4. Confidentiality (Art. 28(3)(b))

Personnel with access are bound by confidentiality [contractual mechanism: OPEN, none is documented]. Operator access is limited to roles Viewer/Support/Admin, requires two-factor and a recorded reason, impersonation is read-only and time-limited, and sessions are visible to the customer.

5. Security (Art. 28(3)(c), Art. 32) — Annex II

| Measure | Evidence | |---|---| | TLS for all traffic; HSTS and strict headers on web surfaces |; headers on the marketing site; production proxy config not yet done (LAUNCH_CHECKLIST.md 4.6) | | Passwords PBKDF2-HMAC-SHA256 600k, min 15 chars, throttling, TOTP two-factor mandatory for Owner/Admin, sessions server-side with idle/absolute limits | | | API keys and licence keys stored as HMAC hashes (pepper), shown once; scopes; rotation | | | Secrets (webhook secrets, two-factor secrets, Shopify tokens) encrypted at rest with key ids and re-wrap | | | Tenant isolation fail-closed on every query; isolation tests |; tests/ResilientLang.Security.Tests | | Bundles signed (Ed25519), loader verifies signature and hashes, refuses rollback and forgery |; key custody option A (app-held, encrypted) for first launch, per-site keys (D29) | | SSRF-guarded crawler, hostile-input limits | | | Hash-chained, tamper-evident audit log with anchors; retention 30-730 days | | | Logging with secret/e-mail redaction | | | Erasure: tenant erasure orchestrator with 11 module hooks, idempotent, throws on a partial result; gaps listed in section 9 | | | Data minimisation by design: the loader sets no cookies, sends no identifier and contacts only configured delivery hosts (browser-tested); IPs in audit and session records are truncated; e-mails and IPs in throttle tables are keyed hashes | | | Backups: encrypted, 35-day roll-off proposed; a restore test is a launch gate | [planned], LAUNCH_CHECKLIST.md 5.1 | | Vulnerability and dependency management, licence policy | | | Encryption at rest of the database and storage | depends on the host/provider; OPEN / verify (not controlled by our code) | | Customers' BYO provider keys encrypted at rest | stated in API.md, not modelled in the data layer (G6) | Honest statement: none of this has run in production or against real SQL Server, R2 or providers (G8). Open security findings are tracked in and may be disclosed to customers on request OPEN.

6. Sub-processors (Art. 28(2), (4))

6.1 The customer gives [general / specific: OPEN] written authorisation to the sub-processors in SUBPROCESSORS.md. 6.2 Changes are announced [30 days: practice proposal in PRIVACY.md section 3, OPEN] in advance; the customer may object on reasonable grounds; if unresolved the customer may terminate the affected service. 6.3 We impose equivalent obligations on sub-processors and remain liable for them. We list a translation engine only after its API terms are checked for no training on API data and short retention (verify per provider, PRIVACY.md section 3).

7. Data-subject requests (Art. 28(3)(e))

We forward requests we receive about customer content to the customer and do not answer them ourselves unless instructed. We provide the tooling described in DSAR_PROCEDURE.md: search/delete of a string and its translations by text or key within a site, and full export. Gap G1: tenant erasure exists (section 9) but search or erasure of one person's data across a tenant, and "export everything about me", are not built.

8. Assistance and breach notification (Arts. 28(3)(f), 33, 34)

We assist with security, impact assessments and consultations given the information we hold. We notify the customer of a personal-data breach affecting its data without undue delay [fixed number of hours: OPEN, see Questions] with the information in BREACH_RESPONSE_PLAN.md. The controller's own 72-hour authority-notification clock under GDPR Art. 33 (verify) starts under its own analysis of awareness.

9. Deletion or return (Art. 28(3)(g))

At the customer's choice, on termination: export (formats in the Terms) then deletion. Proposed timings: 30 days read-only for export after cancellation, deletion within a further 30 days, backups roll off within 35 days, CDN copies deleted at termination (PRIVACY.md section 4: OPEN). Files already downloaded or placed on the customer's own site remain under its control. Exceptions where law requires retention: OPEN. An operator-run tenant erasure orchestrator with hooks for all 11 data modules exists (DSAR_PROCEDURE.md 3A); it has not run in production or on SQL Server. Retained after tenant erasure under the draft defaults (counsel to decide, verify): invoices and payment records minus Stripe ids/links and usage rollups collapsed to monthly totals (RetainFinancialRecords); the tenant audit trail, with actor e-mail, truncated IP and metadata unless RedactRetainedAuditPersonalData is on (and ActorId/TargetId never redacted); terms-acceptance proof with the IP hash removed; Identity audit rows that carry no tenant id; operator audit and support-grant rows; billing tombstone and processed-event ids; the Bundles signing-key tables; published bundles and their CDN and edge-cache copies (UnpublishBundles=false); Shopify tables unless shop/redact ran. Never reached: Stripe (live subscription and customer record), the e-mail provider's copy of messages, delivery-host logs, translation providers, backups. Many other tables have no purge at all.

10. Audit and information (Art. 28(3)(h))

We provide information to demonstrate compliance and allow audits with notice [scope, frequency, cost, remote/on-site: OPEN]. Independent certifications: none (no SOC 2/ISO 27001 planned or in progress: OPEN).

11. International transfers (Annex III) — OPEN

• Hosting/database location is not chosen; the current default host is SmarterASP.NET (location verify).
• Cloudflare R2 offers EU jurisdiction buckets chosen at creation, immutable afterwards, with Logpush unsupported for jurisdictional buckets (per Cloudflare docs as recorded in; verify). The second CDN is not chosen, so an EU-only delivery set is not guaranteed.
• Translation engines: Google, DeepL, Anthropic, Cloudflare Workers AI (m2m100) may process outside the EEA/UK (verify each provider's regions and contracts).
• Transfer tool for restricted transfers: [adequacy decision / standard contractual clauses modules / UK addendum / Swiss addendum: OPEN, verify current instruments]. Transfer impact assessment: OPEN.
• Operator access from outside the EEA is a transfer to be restricted and documented.

12. Region question (EU vs US)

Per-tenant region chosen at signup, immutable, with EU-jurisdiction storage and database and EU-only engines for EU tenants, is proposed in but is not decided (OWNER_DECISIONS 20: "not yet; decide with counsel") and not implemented (G5). Options for counsel/owner: (A) launch single-region with transparent transfer terms; (B) EU-first for everything; (C) true two-region platform. Impact: schema (a tenant Region attribute), storage target selection, engine allow-lists, support access, pricing.

13. Liability, order of precedence, term

OPEN (counsel): liability allocation (cap relative to the Terms, treatment of sub-processor failures), precedence between the Terms and this DPA, governing law.

14. Annex IV — contact points

Customer contact for incident notice: [collected at signup? OPEN — no field exists in the signup form]. Our contact: [OPEN].