Data Processing Agreement (DPA)

Data Processing Agreement (DPA) — Creator ↔ Emansy. Version: 2026-07-20 · GDPR (EU 2016/679), Article 28.

In case of discrepancy, the French version prevails — version française.

1. Parties

• Controller ("the Creator"): the professional holding an Emansy account, as identified in their account / the Main Agreement.
• Processor ("Emansy"): Fanny Bronner, sole trader (entrepreneur individuel / micro-entreprise), operating the Emansy platform — SIRET 531 280 162 00029, registered office: 19 Quai Saint Vincent, 69001 Lyon, France. Data-protection contact: privacy@emansy.fr.

Together "the Parties". This Agreement supplements the Terms and Conditions of use and sale ("Main Agreement"). In case of conflict on data protection, this Agreement prevails.

2. Subject matter

Sets out the terms under which Emansy processes personal data on behalf of the Creator in providing the Emansy service (bookings, calendar, payments, gift vouchers, multi-platform import, storefront). Entered into pursuant to Article 28 GDPR.

3. Roles

The Creator is the controller of their end-customers' data. Emansy acts as processor, solely on the Creator's documented instructions. Emansy remains a controller for its own purposes (Creator account management, billing, security) — covered by its privacy policy, outside this Agreement.

4. Description of processing (Annex 1)

Nature, purpose, duration, categories of data and data subjects are set out in Annex 1.

5. Emansy's obligations (processor) — Art. 28(3)

Emansy shall:

1. (a) Process personal data only on the Creator's documented instructions (including for non-EU transfers), unless required by law (with prior notice to the Creator unless legally prohibited). Use of the service constitutes the Creator's documented instructions; further instructions shall be in writing.
2. (b) Ensure persons authorised to process the data are under a confidentiality obligation.
3. (c) Implement the Art. 32 security measures (Annex 3).
4. (d) Comply with the conditions for engaging a sub-processor (clause 7).
5. (e) Assist the Creator, by appropriate technical and organisational measures, in responding to data-subject rights requests (access, rectification, erasure, objection, portability, restriction).
6. (f) Assist the Creator in ensuring compliance with Art. 32–36 (security, breach notification, impact assessments, prior consultation), taking into account the nature of processing and information available to Emansy.
7. (g) At the Creator's choice, delete or return all personal data at the end of the service and delete existing copies, unless storage is legally required (clause 10).
8. (h) Make available to the Creator the information necessary to demonstrate compliance with Art. 28 and allow for audits (clause 9).

6. Instructions

Emansy shall immediately inform the Creator if, in its opinion, an instruction infringes the GDPR or other applicable data-protection law.

7. Sub-processors — Art. 28(2)(4)

• The Creator gives general authorisation for Emansy to engage the sub-processors listed in Annex 2.
• Emansy shall inform the Creator of any intended addition or replacement with at least 30 days' prior notice, giving the Creator the opportunity to object on legitimate data-protection grounds.
• Emansy imposes on each sub-processor, by contract, data-protection obligations equivalent to this Agreement, and remains liable to the Creator for their performance.

8. International transfers

Data is hosted in the EU (AWS eu-west-3, Paris). Where a sub-processor involves a transfer outside the EU/EEA (see Annex 2), Emansy ensures a valid mechanism (adequacy decision or EU Standard Contractual Clauses, with supplementary measures where needed).

9. Audit — Art. 28(3)(h)

Emansy shall provide, on reasonable request, the information and evidence needed: (i) as evidence of infrastructure security, the public AWS SOC 3 report and, subject to applicable confidentiality terms (a confidentiality agreement where required), the AWS SOC 2 report; (ii) a summary of Emansy's own technical and organisational measures; (iii) security questionnaire responses. An on-site audit is possible with at least 60 days' written prior notice, at the Creator's cost, without disrupting operations and respecting other customers' confidentiality.

10. Deletion / return — Art. 28(3)(g)

At the end of the service, Emansy shall delete or return the data at the Creator's choice within 30 days, certifying deletion on request, save for legal retention obligations (e.g. accounting/tax). Data held in backups is deleted at the end of the backup rotation cycle and remains isolated from any active processing until then.

11. Personal data breach — Art. 33

Emansy shall notify the Creator without undue delay after becoming aware of a breach affecting data processed on the Creator's behalf, as soon as possible (target: 72 hours), with the information needed for the Creator to meet its own notification obligations.

12. Security

Technical and organisational measures set out in Annex 3 (Art. 32).

13. Liability

Liability under this Agreement is governed by the limitation-of-liability clause of the Main Agreement (indirect damages excluded; capped at amounts paid for the subscription over the prior 12 months). This cap governs only the allocation of liability between the Parties and does not limit data subjects' rights under Article 82 GDPR. Each Party bears the penalties/fines arising from its own breaches.

14. Term

This Agreement applies for the term of the Main Agreement and as long as Emansy processes data on the Creator's behalf.

15. Governing law

French law; competent supervisory authority: the CNIL.

Annex 1 — Description of processing

• Subject matter: provision of the Emansy service to the Creator.
• Nature & purposes: booking and calendar management; payment collection (via payment providers); gift vouchers; multi-platform booking import via email (Gmail), including import reliability (temporary retention of source messages for reprocessing — see Annex 3); transactional communications to the Creator's customers; temporary archive of outbound transactional emails (confirmations, notifications, reminders) for deliverability quality control and incident diagnostics (see Annex 3); follow-up of non-completed bookings ("abandoned carts"): temporary retention of the contact details entered in the widget when payment does not complete, so the Creator can help the customer finalize the booking they initiated — never used for marketing/prospecting; (upcoming) hosted storefront.
• Duration: term of the Main Agreement (see clause 10). Imported source messages are retained for a maximum of 90 days, then automatically purged (see Annex 3); extracted booking data is retained for the term of the Main Agreement. Archived outbound transactional emails (body copy + delivery statuses) are retained for a maximum of 30 days, then automatically purged (DynamoDB TTL + S3 lifecycle), with no early-deletion mechanism available to the Creator beyond this purge (see Annex 3). Contact details of non-completed bookings are retained for a maximum of 90 days, then automatically purged (TTL).
• Categories of data subjects: the Creator's end-customers (participants/buyers); prospects where applicable. Minors may be involved (workshops aimed at children): where applicable, obtaining parental consent (Art. 8 GDPR) is the Creator's responsibility.
• Sources of imported data: third-party booking platforms whose emails are imported — Wecandoo, Funbooker, GetYourGuide (and other platforms added under clause 7).
• Categories of data: identity (name), contact details (email, phone), booking data (workshop, date, seats, amount, platform reference), payment history (reference — card data is handled directly by the payment providers). No special categories intentionally collected; sensitive data may appear incidentally (e.g. allergies/workshop content) — to be minimised.

Annex 2 — Authorised sub-processors

Providers contracted by the Creator: payment providers the Creator contracts directly and connects with their own credentials (e.g. Stancer) are not Emansy sub-processors — Emansy transmits data to them on the Creator's documented instructions (clause 5.a). Audience measurement of the emansy.fr website (Cloudflare) serves Emansy's own purposes and is covered by its privacy policy, outside this Agreement.

Anticipated integrations (not yet active): OAuth/import connections with other booking platforms (e.g. Airbnb Experiences, Viator/GetYourGuide). These will be added to this Annex under the clause 7 procedure (notice + right to object) before going live.

Annex 3 — Security measures (Art. 32)

• EU hosting (AWS eu-west-3); encryption at rest (DynamoDB SSE) and in transit (TLS).
• Application-level encryption of sensitive secrets (e.g. Gmail OAuth tokens encrypted with AES-256-GCM).
• Creator authentication via Cognito; least-privilege access; segregated IAM roles.
• Logging and monitoring (CloudWatch); alerting.
• Email-import minimisation: fetch restricted to platform senders; parsing to structured fields. The source message is retained in encrypted form (application-level AES-256-GCM with a data key dedicated to each Creator, itself encrypted under a master key; stored on encrypted-at-rest S3) for a maximum of 90 days, solely for import reliability (reprocessing after an extraction error) and diagnostics, then automatically purged. Destroying the Creator's key renders all their messages permanently unreadable (cryptographic erasure) — the mechanism used for clause 10 deletion and upon Gmail disconnection. Diagnostic metadata (sender, subject — may contain names) is kept in the database under the same 90-day maximum.
• Temporary archive of outbound transactional emails (booking confirmations, notifications, reminders): body copy stored on S3 for 30 days, server-side encryption (SSE-S3, AWS-managed) — unlike the application-level, per-Creator key encryption used for the inbound source-message archive; metadata indexed in plaintext in DynamoDB (query/pagination). Access restricted to the admin console (Cognito platform-admin group) and to IAM roles scoped to the outbound/ prefix. Automatic dual purge after 30 days (DynamoDB TTL + S3 lifecycle); no targeted cryptographic deletion is available for this archive (unlike the inbound message archive). Delivery statuses (delivered/opened/bounced/complaint) are relayed via an SES Configuration Set through an SNS topic encrypted at rest (KMS). Open tracking relies on a pixel — an unreliable signal (false positives from Apple Mail Privacy Protection, false negatives if images are blocked); this is disclosed in the privacy policy.
• Backups and resilience managed by AWS.
• Being formalised (complementary organisational measures, not presented as a firm contractual commitment until in place): documented access-management policy, periodic access review, formal incident-response plan.