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. 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.
3. Demander tells the Customer if it believes an instruction infringes data protection law.
4. Demander processes outside those instructions only where Union or Member State law requires it, and informs the Customer unless that law prohibits it.
5. The Customer's responsibilities. The Customer is responsible for the lawfulness of the processing:
6. a lawful basis for each contact;
7. the legitimate-interest assessment (lia-template.md);
8. the notices to data subjects (art14-notice.md, cookie-notice.md);
9. consent where required;
10. the prospected-seeds attestation (prospected-seeds-attestation.md);
11. 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.
4. Demander gives at least [30] days' notice of a new or replaced sub-processor, by e-mail to account owners and on [URL].
5. The Customer may object on reasonable data-protection grounds. If the parties cannot resolve the objection, the Customer may terminate the affected service.
6. Demander imposes Art. 28(3) obligations on each sub-processor and remains liable for them.
7. Data subject requests. Demander assists the Customer with these:
8. 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;
9. suppression lists record objections and opt-outs, by e-mail address and by domain;
10. an opt-out is honoured in outreach and in audiences Demander uploaded.
11. Other assistance. Demander assists with Art. 32–36 obligations (security, breach notification, DPIAs, prior consultation), taking into account the information available to it.
12. 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.
13. Deletion and return.
14. Return. At any time the Customer can export its data through the app and the API.
15. 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).
16. 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.
17. 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:
2. an audience upload of hashed e-mails;
3. offline conversions;
4. a CRM sync;
5. 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.

1. During a payment-lapse suspension (Terms §7), Demander continues only the processing listed in Terms §7.3:
2. opt-out removals from uploaded audiences and seeds;
3. inbound reply handling;
4. hand-off of conversations to a person;
5. tracking and consent;
6. reading metrics;
7. token refresh.

It makes no other changes on platforms.

1. 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

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

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

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

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).