Data Processing Agreement

The data-processing contract covering the leads our customers capture through Emblem Studio.

How this document is built.

Clauses 1 to 10 are the official Standard Contractual Clauses between controllers and processors under Article 28(3) and (4) GDPR, published as the Annex to Commission Implementing Decision (EU) 2021/915 of 4 June 2021. Each clause below is set out in summary with our option selections marked. The official wording of Decision (EU) 2021/915 is what applies, and we will provide the full text on request.

All four Annexes are populated in full, and a US State Law Addendum follows them.

This is the Article 28 processor contract, Decision 2021/915. It is not the international transfer tool, which is Decision 2021/914. The two were adopted on the same day and are often confused. Decision 2021/914 is referenced in Annex III and used with our US sub-processors.

Last updated: 14 August 2026 · Version: 1.2-beta

Parties: the Customer (the account holder) and SERENICHRON S.R.L., a company registered in Romania (acting as processor). Full details in Annex I.

Incorporation: This DPA is incorporated into and forms part of the Terms of Service between the parties. Where it conflicts with the Terms on the processing of personal data, this DPA prevails.

Who the controller is, when you run this for somebody else

Usually the Customer is the controller of the personal data captured through the Service, and the rest of this DPA reads that way.

It is different when an agency, a freelancer, or anyone else runs the Service on behalf of another organisation, such as a client whose website carries the forms. That organisation is the controller. The Customer is its processor, and we are a sub-processor. In that case:

• The Customer confirms it has that organisation's authority to instruct us about its data, and enters this DPA both on its own behalf and on that organisation's behalf.
• The Customer confirms it has a written contract with that organisation meeting Art. 28(3), and that nothing in this DPA contradicts it.
• We act as a sub-processor, and our obligations here are owed to the controller through the Customer.
• Wherever this DPA says "the Customer" in a controller's role, read it as that controller. The Customer stays responsible to us for everything done through its account.

If the Customer does not have that authority, it must not run the Service on that organisation's site.

Clause 1 — Purpose and scope

[OFFICIAL TEXT — 2021/915 Clause 1] These Clauses set out the Art. 28(3)–(4) obligations for the processing described in Annex II. They do not exempt the controller from its own GDPR obligations.

Clause 2 — Invariability of the Clauses

[OFFICIAL TEXT — 2021/915 Clause 2] The Clauses are not to be amended except to add or update Annex information or add optional wording; this does not prevent inclusion in a wider contract.

Clause 3 — Interpretation

[OFFICIAL TEXT — 2021/915 Clause 3] Terms take the meaning of the GDPR; the Clauses prevail over conflicting related-document terms.

Clause 4 — Hierarchy

[OFFICIAL TEXT — 2021/915 Clause 4] In case of contradiction, these Clauses prevail over related agreements.

Clause 5 — Docking clause (optional — included)

[OFFICIAL TEXT — 2021/915 Clause 5] We include the optional docking clause, so additional controllers (e.g. a customer's own group entities) can accede.

Clause 6 — Description of processing

[OFFICIAL TEXT — 2021/915 Clause 6] The details of the processing — categories of data subjects and personal data, nature and purpose, duration — are specified in Annex II (populated below).

Clause 7 — Obligations of the parties

7.1 Instructions

[OFFICIAL TEXT] We process personal data only on the Customer's documented instructions, including on transfers, unless required by EU/Member-State law (in which case we inform the Customer first unless the law forbids it).

Where the documented instructions live, for this product. The Customer's documented instructions are: (a) this DPA and its Annexes; (b) the Terms and the Acceptable Use Policy; and (c) the Customer's own configuration in the product — the forms they build, the fields they declare, the destinations they connect (webhooks, FunnelKit), and any AI features they switch on. A Customer configuring a webhook, connecting a FunnelKit site, or connecting their own AI is itself a documented instruction, including with regard to transfers to a third country (Art. 28(3)(a)).

7.2 Purpose limitation

[OFFICIAL TEXT] We process only for the specific purpose(s) in Annex II, unless further instructed.

7.3 Duration

[OFFICIAL TEXT] We process for the duration in Annex II.

7.4 Security of processing

[OFFICIAL TEXT] We implement the technical and organisational measures in Annex III and ensure persons authorised to process are under confidentiality. We assist per Arts 32–36.

7.5 Sensitive data

[OFFICIAL TEXT] Where the processing involves special-category data, specific restrictions/safeguards apply.

Our position, stated in the contract, not just hoped for. The permitted-data envelope prohibits special-category data, children's data, and financial credentials (Annex II §4 and the AUP). We are not engaged to process special-category data and the Customer must not cause us to. We cannot detect data that becomes sensitive by inference or context (e.g. an ordinary email box on a fertility clinic's site); the AUP places that boundary on the Customer.

7.6 Documentation and compliance

[OFFICIAL TEXT] We make available information necessary to demonstrate compliance, allow and contribute to audits (Clause 7.6), and correct/delete or return data as instructed.

7.7 Use of sub-processors

[OFFICIAL TEXT — 2021/915 Clause 7.7, Option 2: general written authorisation] We select Option 2: general written authorisation. The Customer authorises the sub-processors in Annex IV. We will inform the Customer of any intended addition or replacement 30 days in advance, giving the Customer time to object. We impose the same data-protection obligations on each sub-processor by contract and remain fully liable for them.

7.8 International transfers

[OFFICIAL TEXT] Any transfer to a third country is done only on the Customer's instructions and in compliance with Chapter V — see Annex III on the 2021/914 SCCs used with our US sub-processors.

Clause 8 — Assistance to the controller

[OFFICIAL TEXT] We assist the Customer in responding to data-subject requests and in meeting Arts 32–36 obligations (security, breach notification, DPIAs, prior consultation), taking account of the nature of processing.

How this works in the product. Data-subject requests about a lead are the Customer's to answer as controller; we give the Customer the tools to do it — export and per-lead deletion in the dashboard, and full erasure on request. For a person who never contracted with us, we are processor throughout and the response duty sits with the Customer.

Clause 9 — Notification of a personal data breach

[OFFICIAL TEXT]

9.1 Breach concerning data processed by the controller — we assist.

9.2 Breach concerning data processed by us (the processor)

[OFFICIAL TEXT] We notify the Customer without undue delay after becoming aware, with the Art. 33(3) information as it becomes available.

Clause 10 — Non-compliance and termination

[OFFICIAL TEXT] The Customer may terminate where we cannot or will not comply; on end of processing we, at the Customer's choice, delete or return the data and delete existing copies unless law requires retention.

ANNEX I — List of Parties

Controller (the Customer)

Processor (us)

ANNEX II — Description of the Processing

(This is the annex generators cannot produce and blank annexes fail on. Populated from the data map.)

1. Categories of data subjects

• The Customer's website visitors who submit one of the Customer's forms, popups, ribbons, or slide-ins (the Customer's leads).
• The Customer's website visitors whose interactions generate anonymous analytics events.

2. Categories of personal data

Data we always process (fixed):

• Lead email address.

Data we process if the Customer's form asks for it (illustrative, non-exhaustive, bounded by §4):

• Name, phone number, and other fields the Customer's form declares by name. Only declared fields are stored; anything else submitted is discarded (field allowlist).

Analytics data (derived, low-identifiability):

• A masked IP address (last IPv4 octet zeroed / IPv6 truncated to /48) — never the raw IP for genuine events.
• A pseudonymous per-browser identifier (random id in a first-party cookie), for counting unique and new-vs-returning visitors.
• Browser user-agent string; page path (no query string); interaction type.

Security exception:

• The raw IP address of a submission that trips the honeypot (bot-only), retained to let the Customer see and block attacks.

3. Nature and purpose of the processing

Storing the Customer's leads; delivering them to the destinations the Customer connects; producing the Customer's own analytics; spam/bot filtering; and, where the Customer enables it, AI-assisted editing (see §6). We process per-Customer, on instruction; we do not pool Customer data for our own purposes.

4. The permitted-data envelope (express negative boundary)

The Customer must not use the service to collect, and must not instruct us to process:

• special-category data (Art. 9 — health, racial/ethnic origin, political/religious/philosophical beliefs, trade-union membership, genetic, biometric, sex life or orientation), including data that becomes special by inference or context;
• data relating to criminal convictions (Art. 10);
• personal data of children, or data collected through child-directed sites/forms;
• financial account credentials (payment card numbers, bank logins);
• data from purchased, rented, or scraped lists.

We cannot technically detect much of this; the boundary is enforced by the AUP and rests on the Customer. If special-category or children's data is nonetheless submitted, that is the Customer's breach of instruction, and we follow a documented internal process for it, starting with written notice to the Customer and a deadline to respond.

5. Duration of the processing

For the life of the Customer's account. On account deletion, retained 135 days then permanently deleted. Honeypot/bot leads: 90 days. Analytics events: for the life of the account. On-request erasure at any time. The periods above are the contractual commitment. Enforcing them automatically on a timer is still being built, so until then we apply them on request and on account deletion.

6. AI-assisted processing — the two doors (novel; no template has this)

• Strategist MCP (Door 1 — BYO-AI). The Customer connects their own AI (e.g. Claude) under their own subscription. Lead and asset data may reach that AI through tool responses, under the Customer's own relationship with the AI provider. That AI provider is the Customer's processor, not ours; we are not party to it and cannot contract it. The Customer is responsible for all access performed through their connected AI whether or not authorized, intended, automated, or initiated (covering a mis-behaving or prompt-injected agent). We provide confirmation gates on destructive tools (e.g. two-step confirmation before clearing stats or activating/trashing an asset) as a safeguard.
• In-app AI chat (Door 2). If the Customer uses it and if we have enabled it, we send the asset being edited (HTML/CSS + design-system CSS) and the Customer's prompts to Anthropic, which acts as our sub-processor for that feature (Annex IV). It is off unless enabled.

7. Instructed transfers by the Customer

Delivery to FunnelKit on the Customer's own WordPress (intra-Customer transfer to Customer-controlled infrastructure) and to customer-configured webhooks are the Customer's instructed transfers to recipients the Customer selects. These recipients are not our sub-processors; the recipient is defined out of scope at the moment of delivery.

8. Mirroring — connecting a WordPress site

When the Customer connects a WordPress site to the Service, we copy that site's existing leads and analytics events into our systems, not only ones submitted after the connection — a retroactive, one-time-then-ongoing sync (LeadImporter, StatsImporter), matched by the source row's WordPress id so a reconnection does not duplicate it. The copied data is the same shape as data we receive natively (Annex II §§1–2); nothing new is collected, only the route by which it reaches us differs.

Legal basis: the Customer's, as controller. Connecting the site is the documented instruction under Clause 7.1/Art. 28(3)(a), on the same footing as configuring a webhook (§7 above). This is an informed instruction: the connect flow states plainly, before the Customer confirms, that connecting copies the site's existing leads, subscribers and stats into the Service and keeps them in sync going forward, and the Customer must actively acknowledge this before the connection completes.

ANNEX III — Technical and Organisational Measures

(Art. 32. Real measures from the codebase — not a restated article.)

Access control and least privilege

• No standing human access to Customer assets or leads. Staff access requires the Customer's explicit, time-boxed, per-request grant, tied to a support conversation and logged where the Customer can see it; break-glass is named and logged, never silent. This grant-and-log mechanism is still being built.
• Per-tenant isolation (CurrentScope) constrains every dashboard read/write to the accounts/sites the caller may see.
• Role separation for team members. Role enforcement at the content level is still being built: a viewer can currently still edit.

Encryption

• TLS in transit for all endpoints.
• Secrets encrypted at rest (e.g. connected-site application passwords are stored encrypted; tokens hidden from API payloads).
• Disk and database encryption at rest: to be added.

Data minimisation by design

• Field allowlist: only fields the Customer's form declares are stored; arbitrary submitted fields are discarded.
• Visitor IPs are masked for analytics and not stored for genuine leads (one honeypot exception).
• No session replay, keystroke capture, or mouse-movement recording — by policy and by design.
• Shadow DOM isolates the embed's styling from the host page.

Abuse and integrity

• Honeypot + IP-based bot filtering on ingestion, characterised as security/fraud prevention.
• Webhook delivery is HMAC-signed and SSRF-guarded.
• Public ingestion endpoints are rate-throttled.

Confidentiality

• Persons authorised to process are bound by confidentiality.

Resilience and backup

• Hosted on Cloudron with database backups.
• Backup retention, and how long deleted data survives inside a backup: to be added.

Breach detection and response

• To be added.

International transfers

• For sub-processors outside the EU (currently WorkOS and Anthropic in the US), the Commission Standard Contractual Clauses (Decision 2021/914) are executed with each, independently of the EU–US Data Privacy Framework's status.

ANNEX IV — Authorised Sub-processors

Under Clause 7.7 Option 2 (general authorisation). The always-current version of this list is published at Sub-processors and Cookies.

Expressly not sub-processors (Customer-directed or Customer's own): FunnelKit on the Customer's own WordPress; customer-configured webhook endpoints; the Customer's own AI provider used through the Strategist MCP (Door 1).

US STATE LAW ADDENDUM

Applies where the Customer or its data subjects are covered by US state privacy laws (California CCPA/CPRA and equivalent laws in Virginia, Colorado, Connecticut, Utah, and others). It converts the GDPR DPA into a compliant "service provider / processor" contract so that the Customer's disclosure to us is not a "sale" or "share."

US-1. Roles

For CCPA/CPRA purposes the Customer is the Business and we are a Service Provider. For other state laws the Customer is the Controller and we are the Processor.

US-2. No-sale / no-share covenant

We will not sell and will not share (as those terms are defined by the CCPA/CPRA) the personal information we process for the Customer. We will not retain, use, or disclose it for any purpose other than the specific business purposes below, and not for any commercial purpose of our own. We will not combine it with personal information from other sources except as permitted for a service provider.

US-3. Specific, non-generic business purposes

We process the Customer's personal information solely to:

1. store and manage the leads the Customer's forms collect;
2. deliver those leads to the destinations the Customer connects (their CRM/FunnelKit, their webhooks);
3. produce the Customer's own analytics and reporting;
4. filter bots and abuse from the Customer's forms;
5. provide AI-assisted editing where the Customer enables it;
6. provide support, security, and maintenance of the service.

(These are enumerated specifically because generic descriptions are expressly disallowed for a service provider.)

US-4. Same-level-of-protection covenant

We will provide the same level of privacy protection as required of the Business by the CCPA/CPRA, and we grant the Customer the right to take reasonable and appropriate steps to ensure we use the personal information consistently with the Business's obligations, and to stop and remediate unauthorised use.

US-5. Self-notification

We will notify the Customer if we determine we can no longer meet our obligations under applicable US state law, without undue delay.

US-6. Sub-processors (service providers/contractors)

Our sub-processors (Annex IV) are engaged under contracts imposing the same restrictions. The no-sale/no-share and same-level-of-protection covenants flow down.

US-7. Deletion and access requests

We assist the Customer in responding to consumer requests (know, delete, correct, opt-out) as the data map and Clause 8 describe, using the export and deletion tools in the product.

US-8. Deidentified data

Any deidentified data we may derive (e.g. aggregate benchmarks) will be maintained and used only in deidentified form; we will not attempt to reidentify it and will contractually prohibit recipients from doing so. We do not produce such benchmarks today.

UK ADDENDUM

Applies where the Customer is established in the United Kingdom, or where data subjects whose personal data we process under this DPA are located in the United Kingdom. The UK left the EU's data protection system after Brexit and runs its own separate, near-identical regime — UK GDPR and the Data Protection Act 2018, enforced by the Information Commissioner's Office (ICO), not any EU authority.

UK-1. UK GDPR applies in parallel, not instead of, EU GDPR

Where this Clause applies, "GDPR" throughout the operative Clauses (1–10) and Annexes above means UK GDPR in addition to EU GDPR, read with the necessary changes (e.g. "Member State" includes the UK, "supervisory authority" includes the ICO). This does not replace anything already agreed for EU data subjects — both regimes apply, each to their own data subjects.

UK-2. International transfers — the mechanism, not the EU one

Any transfer of personal data governed by UK GDPR (i.e. relating to UK data subjects, or transfers out of the UK) is not covered by the EU Standard Contractual Clauses referenced in Annex III — the UK requires its own instrument. We use the UK Addendum to the EU Commission's Standard Contractual Clauses (issued by the ICO under s.119A Data Protection Act 2018), since we already use the underlying EU SCCs — this avoids maintaining two unrelated transfer agreements.

The Addendum is not yet attached. This section states the mechanism we will use. The ICO's "International Data Transfer Addendum to the EU Commission Standard Contractual Clauses" will be attached in full as Annex V before this DPA is relied on for an actual UK transfer.

UK-3. UK representative (Art. 27 UK GDPR)

Not appointed. We are not established in the UK. Where we regularly offer the Service to UK individuals or process personal data of UK data subjects other than occasionally, Art. 27 UK GDPR requires us to name a representative established in the UK, as a point of contact for the ICO and for UK data subjects. This is ordinarily a paid third-party service. To be appointed and named here (name, address, contact) once a UK customer is live — an occasional/low-risk exemption is unlikely to hold once that happens, and regulators read the exemption narrowly.

UK-4. The ICO data protection fee

Separately from appointing a representative, a company caught by UK GDPR — regardless of where it is established — must also pay the ICO's own annual data protection fee, unless exempt. The same event triggers both: offering the Service to UK individuals other than occasionally. Not yet paid or self-assessed. We will complete the ICO's self-assessment and register once a UK customer is live. The fee is tiered by organisation size, roughly £40 to £2,900 a year, and a company our size is expected to fall in the lowest tier.

UK-5. Cookies and direct marketing (PECR)

The UK's Privacy and Electronic Communications Regulations (PECR) govern cookies and similar technologies, alongside UK GDPR, in the same way the ePrivacy Directive does in the EU. Our cookie practices (/legal/cookies) are built to the more cautious EU-ePrivacy-first standard, which meets or exceeds PECR's requirements — including the narrower consent-exempt categories PECR added from February 2026. No separate UK cookie practice is needed; the EU-standard one already covers it.

Signature

Accepted by the Customer on acceptance of the Terms of Service; a versioned copy is emailed to the Customer (durable medium). Signed on our behalf by: to be added.