Data Processing Addendum

Product: Sufflera — web application and Chrome extension Effective date: September 12, 2026 Version: 1.0

1. Parties and relationship to the other agreements

This Data Processing Addendum (“DPA”) is between the Sufflera Team (“we”, “us”, “Processor”) and the customer entity that holds a Sufflera account (“you”, “Customer”, “Controller”). It supplements the TERMS_OF_SERVICE.md under which you use the product (the “Agreement”) and applies automatically to any processing of personal data described in §3, without a separate signature, for any Customer that requests one at privacy@sufflera.com — the same mechanism PRIVACY_POLICY.md §3 and §9 already point to. If this DPA conflicts with the Agreement on data protection terms, this DPA controls.

Capitalised terms not defined here have the meaning given in the Agreement or in applicable data protection law (GDPR, UK GDPR, and — where applicable — the CCPA/CPRA).

2. Roles: who is the controller of what

PRIVACY_POLICY.md §3 draws this line for the whole product, and it is the one this DPA governs:

Category of data	Controller	Processor
Your account, users, billing, referrals, product telemetry	You provide it to us as our own customer — we are the Controller for this category (see `PRIVACY_POLICY.md` §4.1, §4.5–§4.7)	—
Creator personas, CRM records, conversation history, and everything about the people you message (“Fan Data”)	You — you decide which conversations to bring in, what to record, and how long to keep it	We are the Processor, acting only on your instructions

This DPA governs the second row only: our processing of Fan Data on your behalf. It does not change our own role as Controller of your account and billing data, which PRIVACY_POLICY.md already covers directly.

You warrant that you have a lawful basis to process the Fan Data you bring into the product, and that you have given any notices and obtained any consents the people you correspond with are owed under applicable law. We have no visibility into, and no way to verify, the lawfulness of a given conversation on your side — see TERMS_OF_SERVICE.md §9 (Acceptable Use) and TERMS.md §2.3.

3. Subject matter, nature, purpose and duration of processing

Subject matter: provision of the Sufflera service — an AI drafting assistant and CRM for people who message paid-content-platform fans on the Customer’s behalf.
Nature and purpose: storing, displaying, searching and analysing Fan Data you enter or collect through the browser extension; assembling it into prompts sent to an AI inference provider to generate a single draft reply per request (PRIVACY_POLICY.md §7); computing derived fields (mood, lifetime value, funnel stage) used only to serve you the product.
Duration: for as long as your account exists and you retain the relevant Fan Data, per PRIVACY_POLICY.md §11 (reproduced in Annex 1) — there is no automatic expiry of CRM records; you delete what you no longer need.
Categories of data subjects and categories of data: Annex 1.

4. Your instructions

We process Fan Data only:

to provide the Service in accordance with the Agreement and this DPA (storage, search, draft generation, the analytics you see in the product);
on your other documented instructions, given through the product’s own controls (what you type, upload, tag, or configure) or in writing; and
where required by law that applies to us — in which case we tell you before processing, unless the law prohibits telling you.

We will tell you if we reasonably believe an instruction violates applicable data protection law, rather than carrying it out silently.

5. Confidentiality

Anyone we let access Fan Data — our own personnel, or a sub-processor under §7 — is bound by a duty of confidentiality (contractual or statutory) and only has access to the extent needed to provide the Service. PRIVACY_POLICY.md §13 already states this is enforced technically, not just by policy: strict per-tenant data isolation (a request for another tenant’s record returns “not found”, not a permission error) and role-based access control, both checked server-side regardless of what the interface hides.

6. Security measures

We implement the technical and organisational measures listed in Annex 3, which is the same list PRIVACY_POLICY.md §13 gives your users directly — one set of measures, not two documents that can drift apart. Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purpose of the processing, these are designed to ensure a level of security appropriate to the risk, including protection against accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Fan Data.

7. Sub-processors

You authorise us to engage the sub-processors listed in Annex 2 — the same list PRIVACY_POLICY.md §9 discloses to your own users, so there is one inventory, not a second one that could go stale independently. Before we add a new sub-processor with access to Fan Data, we give notice as described in PRIVACY_POLICY.md §14 (by email to account owners, at least 30 days before the change takes effect). If you object on reasonable data-protection grounds, tell us within that window and we will work with you on a resolution — including, if none is found, letting you terminate the affected part of the Service without penalty.

We remain liable for each sub-processor’s performance of its data protection obligations, and we impose data protection terms on every sub-processor that are no less protective than this DPA, to the extent relevant to what they do.

8. Assisting with data subject rights

Where a person you correspond with exercises a right against you directly (access, rectification, erasure, and so on), you can typically fulfil it yourself through the product — PRIVACY_POLICY.md §12 lists the in-product controls (export or delete a single fan record; export or delete the whole account). Where you need our help beyond what self-service already gives you, we will provide reasonable assistance, at your cost if the assistance is material.

If such a person contacts us directly, PRIVACY_POLICY.md §12 already commits us to forward the request to you without delay, since you — not us — are the controller who can identify and act on it.

9. Personal data breach notification

If we become aware of a personal data breach affecting Fan Data, we notify you without undue delay and, in any case, within the timeframe needed for you to meet your own regulatory notification deadlines — consistent with PRIVACY_POLICY.md §13’s commitment to notify the competent supervisory authority within 72 hours of becoming aware, where the breach is likely to result in a risk to individuals. The notice describes, to the extent then known: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed.

10. Deletion or return of data

On termination of your account, or earlier on your request, we delete your Fan Data in line with PRIVACY_POLICY.md §11: CRM records, fan data, personas and generated drafts are permanently purged, with the same two exceptions that policy already states — strictly financial records kept up to 7 years for tax and accounting law, and the fact (not the content) of consent records kept on the same legal-claims basis. Backups are overwritten on their normal cycle, typically within fourteen (14) days. Export before deletion is available through the in-product tools in §8 above.

11. Audits

You may request evidence of our compliance with this DPA — for example, a summary of the measures in Annex 3, or confirmation of a specific sub-processor’s status — by writing to privacy@sufflera.com. We will provide such information as is reasonably necessary to demonstrate compliance, subject to confidentiality and to not undermining the security of the multi-tenant system that protects every customer, including you.

12. International transfers

Where Fan Data is transferred outside the country or region it was collected in — including to us, or from us to a sub-processor in Annex 2 — we rely on an appropriate transfer mechanism (such as the UK/EU Standard Contractual Clauses, or a sub-processor’s own adequacy or certification) as required by applicable law, on the same basis PRIVACY_POLICY.md §10 states for our own processing generally.

13. Liability

Each party’s liability arising out of or in connection with this DPA, including liability under the Standard Contractual Clauses where incorporated, is subject to the limitations and exclusions of liability set out in the Agreement.

14. Term

This DPA takes effect on the date you first process Fan Data through the Service and continues for as long as we process Fan Data on your behalf, notwithstanding termination of the Agreement to the extent processing continues (for example, during an export-and-delete window).

Annex 1 — Details of processing

Categories of data subjects: the people the Customer messages through the Service — referred to throughout as “fans” — and, incidentally, individuals named or described within conversation content or notes the Customer records about them.

Categories of Fan Data, per PRIVACY_POLICY.md §4.3–§4.4:

identifying details as read from the platform or entered by the Customer: display name, platform handle, tags, free-text notes, funnel stage, spend/ purchase history;
conversation content: inbound and outbound message text, translations, timestamps, media references;
data the Customer records about the fan’s preferences, relationship history, and follow-up reminders;
AI-generated drafts, ratings, and safety/integrity outcome codes tied to a given fan’s conversation.

Retention — reproduced from PRIVACY_POLICY.md §11:

Data	Retained
CRM records and conversation history	until the Customer deletes them — no automatic expiry
Messages no longer visible on the platform	flagged as disappeared and excluded from prompts, but kept in the record unless deleted
Draft text and AI diagnostics	configurable per account (`DRAFT_RETENTION_DAYS`); disabled (no expiry) by default
Safety and integrity events	retained as codes only, no message text

Frequency of transfer: continuous, for as long as the Customer’s account is active.

Annex 2 — Sub-processors

Reproduced from PRIVACY_POLICY.md §9 — one inventory for both documents:

Sub-processor	Purpose	Fan Data involved
AI inference provider — currently OpenRouter (routing to upstream model providers), or a self-hosted server under the Customer’s own inference configuration	generate the requested draft, translation, mood and summary calls	prompt content: persona, conversation excerpt, CRM context
Hetzner Online GmbH — servers in Germany (EU)	run the application and database	all stored data, at rest
Transactional email provider — servers in the European Union	verification, password reset, invitations, account notifications	recipient address and message content — Fan Data itself is not sent by email
Sentry	server error monitoring	error traces, request metadata; may incidentally include identifiers, not conversation content

Payment processing has no sub-processor: payments settle on public blockchains to a payment node the Processor operates itself. The blockchain RPC provider used to observe incoming payments is listed in PRIVACY_POLICY.md §9 and is not a Fan Data sub-processor: it never receives conversation content or account data, only invoice addresses and their on-chain transactions.

A current, itemised version of this list — with named entities and locations, once finalised — is available at privacy@sufflera.com.

Annex 3 — Technical and organisational measures

Reproduced from PRIVACY_POLICY.md §13 — the same measures stated to end users, not a separate claim:

passwords hashed with Argon2id; plaintext passwords are never stored;
short-lived access tokens with rotating refresh tokens, server-side session revocation, and signing-key rotation support;
strict tenant isolation — every query is scoped to the account, and a request for another tenant’s record returns “not found” rather than revealing that the record exists;
role-based access control enforced on the server, with per-creator assignment for restricted roles; hiding a control in the interface is never the only protection;
AES-256-GCM encryption for sensitive stored secrets;
TLS in transit; security headers, request rate limits, request size limits and strict schema validation of all input;
append-only audit and consent journals;
financial operations executed under serializable transactions to prevent double-charging;
safety and integrity checks that record issue codes without storing the offending text;
breach notification to the competent supervisory authority within 72 hours of becoming aware, where required.