Data processing agreement (DPA)

1. Status, parties and incorporation

Version dated 9 November 2026. The following clauses are proposed contractual obligations, not an audit or a certification of existing operations.

Incorporated into the accepted Magnetly service contract, this DPA binds the professional customer identified in that contract (the “Customer”) and Jynhold, SAS with share capital of €1,000, RCS Paris 992 428 581, 50 avenue des Champs-Élysées, 75008 Paris, France (“Jynhold”). Jynhold operates the Magnetly product.

The Customer ordinarily acts as controller of the personal data it collects through Magnetly. Jynhold acts as its processor. If the Customer is itself a processor, it warrants that it is authorised by its controller to appoint Jynhold as subprocessor, and the parties must document the resulting instructions and contractual chain.

2. Scope, definitions and precedence

“Personal Data”, “processing”, “controller”, “processor”, “personal data breach” and “supervisory authority” have the meanings given in Regulation (EU) 2016/679 (GDPR). This DPA covers Personal Data processed by Jynhold on the Customer’s behalf through the service, including the processing described in Schedule 1 below.

It does not replace Jynhold’s separate privacy notice for information that it processes as controller for its own account administration, business relationship, billing or security purposes.

For covered Personal Data, this DPA prevails over conflicting service terms. Any applicable mandatory international-transfer clauses prevail over conflicting provisions of this DPA. No clause limits the rights of data subjects or the powers of competent authorities.

3. Schedule 1 — processing description

The Customer’s configuration and subsequent documented instructions supplement this schedule without authorising unlawful processing.

4. Documented instructions and AI boundaries

Jynhold shall process covered Personal Data only on documented instructions from the Customer, including instructions concerning international transfers. The accepted contract, this DPA, authorised configuration and documented support requests constitute instructions within their scope. Additional processing requires further documented instructions.

If Jynhold is legally required to process data otherwise, it shall inform the Customer before the processing unless the law prohibits that information. It shall immediately inform the Customer if, in its opinion, an instruction infringes applicable data-protection law, and seek a lawful instruction before proceeding with the disputed operation.

Lead contact fields are never included in AI requests. Free text, imported content and prompts may nevertheless contain personal information; they are sent to the AI providers in Schedule 2 through OpenRouter, only to providers that retain no data and exclude its collection. The Customer shall avoid unnecessary personal information in AI inputs. Merely labelling a route ZDR does not remove the requirements of this DPA.

Jynhold shall not sell covered Personal Data, use it for unrelated advertising or use it to train its own general-purpose models outside the Customer’s instructions. No broader third-party training guarantee is given beyond what Schedule 2 describes.

5. Customer responsibilities

The Customer determines its purposes, questions, required fields, recipients and lawful basis. It shall provide appropriate notices, collect consent where required, respect data minimisation, and supply lawful instructions. It remains responsible for the accuracy and legality of data and content that it provides and for managing its authorised users.

The Customer shall not intentionally introduce data outside the agreed scope or use Magnetly for prohibited processing. Any significant change of purpose, sensitive-data use or solely automated decision with legal or similarly significant effects requires an appropriate assessment and, where relevant, a written amendment. These responsibilities do not relieve Jynhold of its own processor obligations.

6. Confidentiality and personnel

Jynhold shall ensure that persons authorised to process covered Personal Data are bound by an appropriate confidentiality obligation, receive instructions relevant to their duties, and access information only to the extent needed. Access authorisations shall be managed and withdrawn when no longer necessary.

Confidentiality obligations continue after the relevant person’s involvement or the service relationship ends. Disclosures required by law remain subject to the applicable information and minimisation obligations.

7. Security obligations and Schedule 3

Jynhold shall implement technical and organisational measures appropriate to the risk under Article 32 GDPR, taking account of the state of the art, implementation costs, the processing and the risks to individuals. Schedule 3 describes the measures actually applied to the covered service.

Those measures shall address, where appropriate, confidentiality, integrity, availability, resilience, restoration and regular evaluation of effectiveness. Jynhold shall not materially reduce the overall level of protection during the processing without appropriate equivalent safeguards.

General obligations in this clause are not proof of certifications, encryption algorithms, testing frequency or recovery objectives that Schedule 3 does not state.

8. Authorisation and changes of subprocessors

On acceptance of the DPA, the Customer gives general written authorisation for the subprocessors identified in Schedule 2. Jynhold shall appoint further subprocessors only under a written contract imposing data-protection duties equivalent to the relevant duties in this DPA. Jynhold remains responsible to the Customer for their performance.

Notice: Jynhold shall notify the owner of the Customer’s workspace by email, at their account address, at least 30 calendar days before adding or replacing a subprocessor that will process covered Personal Data, identifying the service, data and relevant locations/safeguards. The Customer may object during that period on reasonable, documented data-protection grounds.

The parties shall seek a suitable alternative or protective measure. If no resolution is possible before the change, the Customer may instruct suspension of the affected processing or end the affected service under the agreed contract. An objection is not waived merely because the register was published on a website. Each Schedule 2 provider publishes the list of its own subprocessors and announces changes to it under its contract; those lists are linked in Schedule 2. The Customer sends any objection in writing to [email protected].

9. Transfers outside the EEA

Jynhold shall make a covered transfer outside the EEA only in accordance with the Customer’s documented instructions and Chapter V GDPR. Schedule 2 identifies, for each provider, the contracting entity, country, role, data and applicable transfer safeguard.

The standard contractual clauses used are those of Commission Implementing Decision (EU) 2021/914, in the modules stated in Schedule 2, incorporated in the providers’ contracts. This Article 28 DPA is not itself an international-transfer mechanism. Jynhold shall make relevant information and safeguards available to the Customer and assist with the required transfer assessment.

Processing locations: application and marketing website in Amsterdam (Railway, EU West), database in Frankfurt (Neon, AWS eu-central-1), files on Cloudflare R2 under EU jurisdiction, emails from the eu-west-1 region (Resend), error reports and the import environment in EU regions (Sentry, Modal). AI requests are processed by OpenRouter, the model providers and Exa, established in the United States. The model providers and Exa are engaged by OpenRouter, not by Jynhold, and are not certified under the Data Privacy Framework; requests go only to providers that OpenRouter classes as retaining no data, never with lead contact details, and Jynhold has asked OpenRouter for the contractual chain with these providers (Article 28(4) GDPR) and the basis of their transfers. A recipient not certified under the Data Privacy Framework is not presented as covered by the adequacy decision.

10. Requests from individuals

Taking account of the nature of the processing, Jynhold shall assist the Customer through appropriate technical and organisational measures in responding to GDPR rights requests. If Jynhold receives a request concerning covered data directly, it shall promptly inform the Customer and not respond substantively on the Customer’s behalf unless instructed or legally required.

The parties shall cooperate to identify and provide, correct, restrict, export or delete relevant data as lawfully requested. Assistance must enable the Customer to meet its legal deadlines; Jynhold handles each of the Customer’s assistance requests within 30 days at most. Any genuinely additional service or fee must be agreed transparently in advance and must not prevent Jynhold from fulfilling mandatory obligations.

11. Personal data breaches

Jynhold shall notify the Customer of any personal data breach affecting covered data without undue delay and at the latest within 48 hours of becoming aware of it. Notifications shall be sent to the Customer’s designated security/account contact; Jynhold’s contact is [email protected].

As information becomes available, Jynhold shall describe the nature of the breach, affected data and people, likely consequences, measures taken or proposed, and a contact for follow-up. It shall provide updates, preserve relevant evidence, and reasonably assist investigation, containment and the Customer’s notification duties.

Jynhold shall not wait for a complete investigation before sending the initial notification. The controller’s statutory 72-hour authority-notification period, where applicable, is not a substitute for Jynhold’s obligation to notify without undue delay. The Customer determines notifications to individuals and authorities, unless law requires Jynhold to act directly.

12. Assistance, authorities and assessments

Taking account of the processing and information available to it, Jynhold shall assist the Customer with its obligations under Articles 32–36 GDPR, including security, breach assessment, data-protection impact assessments and prior consultation where required. The parties shall cooperate with competent supervisory authorities.

Jynhold shall make information needed to assess the service’s relevant processing and safeguards available to the Customer, subject to proportionate protection of confidential information. The Customer remains responsible for the assessment of its own purposes and intended use.

13. Return, deletion and backups

At the end of the processing service, Jynhold shall, at the Customer’s choice, return or delete covered Personal Data and delete existing copies unless EU or Member State law requires retention. The rules below set out the export method, its format, the deletion timetable and the confirmation process.

Data retained solely because of a legal obligation shall be limited, isolated from ordinary use and processed only for that obligation. Backup copies shall follow the documented deletion cycle, remain protected and unavailable for ordinary use, and any restoration shall preserve the applicable deletion instructions.

Rules applied: a deleted tool is no longer served at once, and its sessions, responses, leads, events, versions, catalogue and files are erased 30 days later; when its owner deletes a workspace, its members lose access at once and its data is erased under the same rule; stored files no data refers to any more are erased after 24 hours; the database restore history covers 7 days, after which erased data no longer remains in it. Before the service ends, the Customer exports its tools’ responses and its workspace’s leads as CSV; a fuller export or the deletion of a single lead is requested at [email protected]. The AI-call record and payment events, without lead contact details, are kept detached for billing. The contract ends when the Customer deletes the workspace, or the account that owns it, or when that account is deleted after 3 years without a sign-in; covered Personal Data is then deleted within 30 days. A workspace whose subscription or trial has ended stays read-only, with its data kept, until one of those events. Jynhold handles export and deletion requests within 30 days and confirms in writing, to the address that made the request, once done. Legal archives: Jynhold’s accounting records and invoices are kept for 10 years (article L123-22 of the French Commercial Code); they do not contain the data of the Customer’s forms. Commercial credit expiry does not establish a data-retention period.

14. Demonstrating compliance and audits

Jynhold shall provide the information needed to demonstrate compliance with Article 28 GDPR and allow and contribute to audits, including inspections, by the Customer or an authorised independent auditor. The parties may agree reasonable notice, confidentiality, security and coordination arrangements that do not make the statutory audit right ineffective.

Existing relevant reports and documentation may be used first where sufficient; they do not exclude a necessary audit or inspection. Evidence of a serious incident, a substantiated compliance concern or an authority’s requirement must be addressed without an unreasonable routine-notice delay. Each party shall protect other customers’ information and confidential security details during the process.

15. Schedule 2 — provider register

Separate roles: Stripe, through Stripe Payments Europe, Limited (Ireland) under the Stripe agreement, with Stripe, LLC (United States, certified under the Data Privacy Framework) and the standard contractual clauses of Stripe’s Data Transfer Addendum, handles payments; as Jynhold understands it, under Stripe Managed Payments, Link (Sold through Link, LLC) is merchant of record and acts as an independent controller of buyers’ payment data. Google provides optional sign-in with a Google account, as independent controller of that account: it is a third-party service, not a subprocessor. Their own processing is outside the processing mandate given to Jynhold and receives no data from the Customer’s forms.

This register is the authorisation schedule of clause 8. Each provider announces changes to its own subprocessors under its contract, in the public list linked above; Jynhold’s 30-day notice (clause 8) applies to any change to this register.

16. Schedule 3 — security measures, contacts and acceptance

Measures in place at the date of this version, each verifiable in the service and its documentation:

• Encryption in transit: all traffic over HTTPS (TLS), HSTS in production and security headers on every response of the application (nosniff, no framing, permissions policy); the application reachable only through Cloudflare; the database reachable only over TLS with certificate verification.
• Authentication: passwordless sign-in, with a one-time code sent by email or with Google; sessions stored on the server, valid for 7 days.
• Workspace separation: every route of the application checks that the user is a member of the workspace concerned; this control is covered by integration tests.
• Privileged access: for support, a Jynhold administrator accesses an account only by signing in as the user, logged (start and end), limited to 24 hours and never billed to the Customer.
• Abuse limits: rate limits on the application’s routes, the tools’ public runtime, sign-in and the MCP server.
• Secrets: keys and secrets kept in the host’s environment, never in the code.
• Encryption at rest: provided by the storage providers, Neon for the database and Cloudflare R2 for files, under their own measures.
• Backups: point-in-time restore of the database over a 7-day window (Neon), tested on 9 November 2026.
• Execution isolation: catalogue-import code runs in an isolated environment (Modal, EU region), limited in memory and time, destroyed at the end of the import, that reaches only public internet addresses, excluding Jynhold’s infrastructure.
• Outbound requests: pages and files the server reads on the internet go through a check that refuses any non-public address (protection against server-side request forgery).
• Logging: error reports (Sentry, EU region) without IP address, cookie, header, request body or identity; the host’s runtime logs.
• AI: requests routed only to providers that retain no data, never with leads’ contact details.
• Development: an automated test suite (unit, integration and end-to-end) run before each change is merged.
• Deletion: daily tasks that erase tools deleted more than 30 days ago, files no data refers to any more and expired rate-limit counters.

Jynhold holds no security certification (ISO 27001, SOC 2 or other) and sets no quantified recovery objective. Incidents: application errors are reported to Sentry and the host’s logs can be consulted; in the event of a personal data breach, Jynhold notifies the Customer without undue delay and at the latest within 48 hours of becoming aware of it (clause 11).

Contacts: Jynhold’s notices (breaches, subprocessor changes) are sent to the owner of the Customer’s workspace, at their account email address, or to another contact the Customer designates in writing to [email protected]. That Jynhold contact receives instructions, privacy questions and incident reports.

Acceptance: the DPA applies in the version published on the date the Customer accepts the service contract. Later material changes are documented and communicated under the applicable contract.