# Data Processing Agreement (GDPR Art. 28)

**DRAFT — not legal advice — review by counsel required.**

This agreement is between the Customer (the controller) and [legal entity] ("Demander", the processor). It forms part of the [Terms of Service](terms-of-service.md). Where the Customer is itself a processor (for example an agency acting for clients), Demander is its sub-processor and the obligations below flow down.

## 1. Subject matter and instructions

1. **What Demander processes.** Demander processes Customer Data only to provide the service described in the Terms. The details are in Annex 1.
2. **Instructions.** The Customer's documented instructions are these Terms, the settings and approvals made in the app, API calls made with the Customer's tokens, and written instructions agreed with Demander.
   - Demander tells the Customer if it believes an instruction infringes data protection law.
   - Demander processes outside those instructions only where Union or Member State law requires it, and informs the Customer unless that law prohibits it.
3. **The Customer's responsibilities.** The Customer is responsible for the lawfulness of the processing:
   - a lawful basis for each contact;
   - the legitimate-interest assessment ([lia-template.md](lia-template.md));
   - the notices to data subjects ([art14-notice.md](art14-notice.md), [cookie-notice.md](cookie-notice.md));
   - consent where required;
   - the prospected-seeds attestation ([prospected-seeds-attestation.md](prospected-seeds-attestation.md));
   - compliance with each connected platform's terms.

## 2. Demander's obligations

1. **Confidentiality.** People authorised to process Customer Data are bound by confidentiality.
2. **Security.** Demander implements the technical and organisational measures in Annex 2.
3. **Sub-processors.** Demander uses only the sub-processors in Annex 3, Part A. The Customer gives general authorisation to them.
   - Demander gives at least [30] days' notice of a new or replaced sub-processor, by e-mail to account owners and on [URL].
   - The Customer may object on reasonable data-protection grounds. If the parties cannot resolve the objection, the Customer may terminate the affected service.
   - Demander imposes Art. 28(3) obligations on each sub-processor and remains liable for them.
4. **Data subject requests.** Demander assists the Customer with these:
   - the app and the API export one person's data (JSON) and every contact (CSV or JSON), and erase a person (a contact, an e-mail address, or someone who only wrote in on a messaging channel) or the website visits of one browser; an erased person's e-mail address is kept only as a SHA-256 hash on the suppression list, so that they are not contacted again;
   - suppression lists record objections and opt-outs, by e-mail address and by domain;
   - an opt-out is honoured in outreach and in audiences Demander uploaded.
5. **Other assistance.** Demander assists with Art. 32–36 obligations (security, breach notification, DPIAs, prior consultation), taking into account the information available to it.
6. **Breaches.** Demander notifies the Customer of a personal data breach without undue delay, and in any case within [48] hours of becoming aware of it, with the information Art. 33(3) requires as it becomes available.
7. **Deletion and return.**
   - **Return.** At any time the Customer can export its data through the app and the API.
   - **Deletion.** Deleting a workspace or organisation deletes its Customer Data immediately. Backups containing it are pruned within the backup retention period (14 days by default).
   - **What is retained.** Demander keeps only a minimal deletion record (ids and counts, no names or e-mail addresses) and AI-usage cost records, where Union or Member State law or legitimate accountability needs require it. See §4 for what deletion does **not** remove.
8. **Audits.** Demander makes available the information needed to demonstrate compliance with Art. 28: this agreement, Annex 2 and [security summary / certifications]. It allows audits by the Customer or an auditor it mandates, with [30] days' notice, at most once a year unless there is a breach, during business hours and under confidentiality.

## 3. International transfers

Demander hosts Customer Data in the EU (Hetzner Online GmbH, Germany [recommended in docs/DEPLOY.md — confirm before signing]). Where a sub-processor processes data outside the EEA (Annex 3), transfers rely on:

- an adequacy decision (including the EU–US Data Privacy Framework for certified recipients); or
- the Standard Contractual Clauses (Module 3), with transfer impact assessments.

[Counsel: confirm per sub-processor.]

## 4. Connected platforms, suspension and deletion

1. **Platforms are recipients the Customer chooses.** When the Customer connects a platform and approves an action, Demander transfers Customer Data to the Customer's own account on that platform. Examples:
   - an audience upload of hashed e-mails;
   - offline conversions;
   - a CRM sync;
   - a message sent from the Customer's mailbox.

   These platforms are **not Demander's sub-processors**. Each acts under its terms with the Customer, mostly as an independent controller or as the Customer's processor. They are listed in Annex 3, Part B, for transparency.
2. **During a payment-lapse suspension** (Terms §7), Demander continues only the processing listed in Terms §7.3:
   - opt-out removals from uploaded audiences and seeds;
   - inbound reply handling;
   - hand-off of conversations to a person;
   - tracking and consent;
   - reading metrics;
   - token refresh.

   It makes no other changes on platforms.
3. **After deletion** (Terms §11.3), data already transferred to the Customer's platform accounts stays there, under the Customer's control. Examples are audiences, conversion events and CRM records. **The Customer is responsible for it, including honouring opt-outs in audiences Demander uploaded.** Demander revokes its platform access where the platform allows it, and stops all processing.

## 5. Term

This agreement lasts as long as Demander processes Customer Data for the Customer.

---

## Annex 1 — Details of processing

| | |
|---|---|
| **Categories of data subjects** | (a) The Customer's business contacts and prospects (employees of target companies). (b) Visitors to the Customer's websites with the tracking snippet. (c) People who message the Customer's Pages and accounts (Messenger, Instagram, WhatsApp, X, Telegram). (d) The Customer's users. (e) The Customer's customers, where the Customer uploads them as audiences. |
| **Categories of personal data** | **Contacts:** name, business e-mail, job title, seniority, department, buying role, LinkedIn URL, country, company, lawful basis, consent status and source, suppression status, data source and source page (Art. 14(2)(f)), CRM id. **Visitors:** a random first-party id (only after analytics consent, or in "off" mode); a daily-rotating salted hash of the IP address (`ipHash`, not reversible); country; pages viewed, referrer, UTM parameters; ad click ids (only with marketing consent); company identification; an e-mail entered in a form (only if form capture is enabled and marketing consent is given). **Learned company IP prefixes:** a /24 (IPv4) or /48 (IPv6) prefix with the company domain and the contact ids that backed it, deleted after 180 days without new evidence. **Messages:** outreach e-mails sent, inbound replies (via the reply subdomain), conversation messages, opt-outs. **Audiences and conversions:** SHA-256-hashed e-mails and click ids sent to ad platforms. **Users:** name, e-mail, role, audit log. |
| **Special categories** | None intended. The Customer must not upload special-category data. |
| **Nature and purpose** | Hosting and organising Customer Data. Scoring companies and contacts. Planning, launching and optimising campaigns on the Customer's platforms. Sending the Customer's approved outreach and messages. Building and maintaining audiences and lookalike seeds within eligibility rules. Identifying companies visiting the Customer's website. Attributing pipeline to campaigns. Reporting. |
| **Duration** | For the term of the agreement. Customer Data is deleted when the workspace or organisation is deleted (immediately), except as stated in §2.7. |
| **Retention inside the service** | Learned IP prefixes: 180 days without new evidence. Meta webhook queue: 7 days after processing. OAuth connection states: 10 minutes, purged after a day. Erased people: a SHA-256 hash of the e-mail address on the suppression list, until the Customer removes it or the workspace. Everything else: until the Customer deletes it (a person, a visitor, or the workspace). |

## Annex 2 — Technical and organisational measures

- **Hosting.** EU data centre (Hetzner Online GmbH, Germany [confirm]). Network isolation; managed Postgres with encryption at rest [confirm].
- **Encryption.**
  - TLS for all traffic.
  - Integration secrets (OAuth tokens, API keys) are encrypted with AES-256-GCM under `ENCRYPTION_KEY`. They are never shown again after entry and never logged.
- **Credentials.**
  - Passwords are hashed with scrypt.
  - API tokens, invitation links, reset links and verification links are stored only as hashes.
  - Sessions can be revoked all at once.
- **Access control.**
  - Roles: owner, admin, marketer, sales, viewer.
  - Connecting platforms needs owner/admin rights and a verified e-mail address.
  - API tokens are scoped (read, write, approve) and expire (at most 365 days).
  - Personal API tokens cannot manage integrations or OAuth.
- **Change control.** Live changes go through proposals, approvals, guardrails (budget caps, anomaly pausing) and an audit log with before and after values, and can be reverted.
- **Data minimisation in the code.**
  - Full IP addresses are not stored. The IP hash rotates daily; learned prefixes are truncated.
  - Ad click ids, identify() calls and form e-mails require marketing consent. GPC and DNT always mean no marketing consent.
  - Prospected contacts are never used as ad seeds for EU/EEA/UK/CH residents, and never on Google.
  - The AI provider receives product and company information, not individual contact records.
- **Outbound safety.** Requests to Customer-supplied URLs go through an SSRF guard that blocks private and loopback networks.
- **Opt-outs.**
  - Every outreach e-mail has a one-click unsubscribe (List-Unsubscribe).
  - Suppression lists hold opt-outs by e-mail and by domain.
  - Opt-outs are removed from uploaded audiences.
- **Resilience.** Database dumps with a checksum (`scripts/backup.sh`), optionally copied off-site to S3-compatible storage with server-side encryption and object lock. They are pruned after `BACKUP_RETENTION_DAYS` (default 14). Restores are tested [frequency] (`docs/OPERATIONS.md`).
- **Logs and error reports.** Logs are JSON lines on stdout. Secrets in URLs are masked. Logs contain workspace and contact ids and are kept [30] days.
  Error reports (optional) are scrubbed before they leave:
  - no request bodies, cookies or query strings;
  - e-mail addresses, tokens and IP addresses are masked;
  - the user is reported by id only.
- **People.** Confidentiality undertakings, least-privilege production access, MFA on infrastructure accounts.

## Annex 3 — Sub-processors and recipients

### Part A — Sub-processors engaged by Demander

| Sub-processor | Service | Personal data it receives | Location / transfer basis |
|---|---|---|---|
| Hetzner Online GmbH [confirm] | Hosting, database | All Customer Data | EU (Germany) |
| Brevo (Sendinblue SAS) [confirm] (`SYSTEM_SMTP_URL`) | Platform e-mail: verification, password reset, invitations, security notices, integration alerts, billing notices (trial, payment failure, suspension with the list of running campaigns), deletion confirmations | Users' names and e-mail addresses, invitees' e-mail addresses, the notice text | [location / basis] |
| Anthropic PBC | AI drafting (product profile, personas, narrative, messages, creative variants, account briefs) | Product website text, company names, domains, firmographics and company-level activity summaries. No individual contact records are sent (by design of the AI tasks). | USA; [DPF/SCCs — confirm]; [zero-retention terms — confirm] |
| Stripe Payments Europe Ltd / Stripe, Inc. | Subscription billing, Checkout, Customer Portal, invoices, metered spend fee | Billing contact name and e-mail, company name, address and VAT number, payment method (collected by Stripe), subscription and usage amounts | Ireland / USA; [basis] |
| OpenStreetMap Foundation (Nominatim), LocationIQ, Mapbox, Google Geocoding (whichever is configured) | Geocoding company office addresses for geofences | Company addresses (normally not personal data) | [locations] |
| rdap.org and the regional internet registries (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) | Looking up the holder of an IP range, for company identification of website visitors where lawful | The visitor's IP address in the lookup request; nothing is stored beyond the company result | Global; [basis — counsel: recipient vs sub-processor] |

Operational services, only if the deployment configures them (`docs/DEPLOY.md`):

| Sub-processor | Service | Personal data it receives | Location / transfer basis |
|---|---|---|---|
| Hetzner Online GmbH, Object Storage [confirm] (`BACKUP_S3_URI`) | Off-site encrypted database backups, pruned after 14 days by default | All Customer Data (encrypted at rest) | EU (Finland) |
| Functional Software, Inc. (Sentry) (`SENTRY_DSN`) | Error reporting for the API and worker | Scrubbed error events: route pattern, user id, workspace and queue tags, stack traces. E-mail addresses, IP addresses, tokens, bodies and query strings are filtered out. | [EU or US region; basis] |
| Slack Technologies [confirm] (`ALERT_WEBHOOK_URL`) | Operational alerts | Alert text: kind, workspace or mailbox identifier, provider name. No contact data. | USA; EU–US Data Privacy Framework / SCCs [confirm] |

Demander's own API keys, where the Customer uses them instead of its own:

| Sub-processor | Service | Personal data it receives |
|---|---|---|
| Hunter.io, People Data Labs | Finding and verifying business contacts at target companies (prospecting) | Company domains and names; returns names, titles and business e-mail addresses. [Counsel: joint-controller analysis.] |
| IPinfo, Dealfront (Leadfeeder) | Reverse-IP company identification | Visitor IP address |
| OpenAI (Images), Google (Imagen / Veo) | Generating ad images and video | Creative prompts (no personal data intended) |

### Part B — Platforms the Customer connects (recipients, not sub-processors)

Data goes to the Customer's own accounts on the Customer's instruction (§4.1).

| Platform | What Demander sends there |
|---|---|
| Google Ads, Google Data Manager API | Campaigns; SHA-256-hashed e-mails for Customer Match (eligible first-party contacts only); offline conversions (gclid, hashed e-mail) |
| Meta (Facebook, Instagram, Messenger, WhatsApp) | Campaigns; custom audiences and lookalike seeds (hashed identifiers); Page and Instagram posts; replies in conversations people started |
| LinkedIn | Campaigns, Message and Conversation Ads; DMP segments (company lists; hashed contact e-mails); conversions; Company Page posts |
| Microsoft Advertising, Microsoft 365 | Campaigns; offline conversions; e-mails sent from the Customer's mailbox (`Mail.Send`) |
| TikTok, Reddit, X, Sklik (Seznam.cz) | Campaigns; custom audiences (hashed identifiers); conversion events; posts and direct-message replies (X) |
| Gmail / Google Workspace, Customer SMTP servers | Outreach e-mails sent from the Customer's mailbox |
| HubSpot, Pipedrive, Salesforce | Companies, contacts and deals synced to the Customer's CRM |
| Telegram | Bot replies in conversations people started |
| Public company registers (ARES, Companies House, CVR, Bolagsverket, PRH, Brønnøysund, GLEIF, Wikidata and others) | Queries by company name or registration number. These are sources, not recipients of personal data. |

---
Source: https://demander.to/legal/dpa/