Draft Data Processing Agreement

Draft Data Processing Agreement

Draft updated: September 8, 2026

Draft awaiting completed annexes and acceptance: the clauses below define the parties’ proposed obligations. They are not evidence that a contract has been accepted or that every operational requirement is deployed. The open fields in Annexes A–D must be completed and the applicable measures verified before relying on this document as an executed DPA.

Customer: [Legal name and address; controller or authorised processor as recorded in Annex A]
Processor: MAIKO BOSSUYT, Entrepreneur individuel (EI), SIREN 834180911, operating le_dns, 8 Rue Vasco de Gama, 77700 Serris, France
Service: managed primary and secondary authoritative DNS

1. Scope

Subject to the customer’s documented instructions, le_dns stores, retrieves, modifies, signs, serves, returns and deletes personal data needed for the managed primary and secondary DNS service described in Annex A. Instructions to publish DNS records make their content available through the public DNS; the customer remains responsible for the content and lawfulness of those instructions.

Processing lasts for the contracted service and the return/deletion operations in Section 7 and Annex D. A service renewal, payment failure or billing downgrade does not, by itself, instruct le_dns to delete the customer’s zones. This DPA does not change the commercial cancellation or DNS-continuity policy.

2. Data and people

The service may process domain names, DNS records, primary-server addresses, configuration and version history, TSIG and other service credentials, administrator contact and access metadata, and customer-scoped operational data. Annex A identifies which categories are processed on the customer’s behalf and the relevant people. A datum’s presence in this list does not assign every use of that datum to the processor role.

Data subjects can include customer administrators, domain contacts and people identified in customer-provided DNS records. The service is not intended for special-category data. The customer must not place special-category data in DNS records unless separately agreed and lawfully instructed.

3. Roles and instructions

The customer determines the purpose and content of its zones as controller or, if acting as a processor, confirms that its controller has authorised the instructions and appointment of le_dns. The applicable role and authorisation are recorded in Annex A. le_dns acts as processor or subprocessor only for the processing entrusted to it. Its separate controller purposes, including its own account security, fraud prevention, resolver analytics and billing, are described separately in the Privacy Policy; they do not authorise reuse of entrusted zone data for unrelated purposes.

The customer is responsible for the lawful basis, notices and authority needed for its instructions. It may issue and update instructions through authorised portal/API actions or a written request using the verified contacts in Annex A. le_dns records written instructions and provides a traceable account of their execution. An API request is an instruction only within the authenticated user’s authority; it does not expand the customer’s legal rights.

le_dns processes entrusted personal data only on documented instructions, including for transfers outside the EEA. If Union or Member-State law requires other processing, le_dns informs the customer of the requirement before processing unless the law prohibits that disclosure on important public-interest grounds. If le_dns considers an instruction contrary to applicable data-protection law, it immediately informs the customer and refrains from executing the disputed instruction pending lawful clarification. It cooperates on a lawful alternative without silently changing the purpose.

le_dns limits access to persons whose duties require it and ensures that they are bound by confidentiality commitments or an appropriate legal duty. Such persons receive instructions appropriate to their role and may process the data only under the authorised instructions. Confidentiality continues after their access ends.

4. Security measures

le_dns implements the technical and organisational measures required by GDPR Article 32, taking account of the processing, risks, available technology and implementation costs. This includes appropriate confidentiality, integrity, availability and resilience, restoration capability, and regular assessment of the effectiveness of the measures. Annex B records the actual measures and evidence for the contracted deployment; changes must maintain a level of protection appropriate to the risks.

The inspected v2 code provides the following controls; their presence is not proof of deployment or a certification:

• Secure, HttpOnly, SameSite=Strict portal sessions with an eight-hour default lifetime;
• SHA-256 hashes for API tokens, with raw tokens shown once;
• role and plan checks enforced by server-side middleware;
• TSIG-authenticated zone transfer and dynamic-update paths;
• separate control, DNS-serving and signing boundaries;
• SoftHSM-backed non-extractable RSA/SHA-256 or ECDSA P-256 signing keys;
• restricted DDNS and administrative audit data; and
• an operational-log retention threshold configured at 31 days, with asynchronous deletion.

TSIG authenticates standard AXFR/IXFR traffic; it does not encrypt it. SoftHSM is software, not a certified hardware HSM. No claim of encrypted server volumes or encrypted backups is made without deployment evidence. Security measures must be revalidated after production cutover. Unverified measures in Annex B remain requirements to resolve before acceptance, not exceptions to Article 32.

5. Subprocessors and recipients

In the production snapshot inspected on 2026-08-29, IaaS providers were OVHcloud and Scaleway, with processing in France, Germany and Poland. Reverify the deployed inventory and executed contracts before treating that as current. Paddle is the intended reseller for new v2 sales and acts as controller for its own commercial and financial purposes, as described in its privacy notice. It is not thereby a subprocessor of customer DNS-zone content. The deployed integration remains to be verified; live sales remain closed during this preparation. Any external email-delivery provider must be added before use.

le_dns appoints a subprocessor only after obtaining the customer’s prior written specific or general authorisation. Annex C records the authorised providers, their tasks and locations, the authorisation mode and supporting contracts. A provider named in a historical inventory is not automatically authorised by this draft.

Under general authorisation, le_dns informs the customer of an intended addition or replacement sufficiently in advance for a meaningful data-protection objection before that provider processes the entrusted data. The notification route and advance period must be completed in Annex C. The parties seek an appropriate alternative when an objection cannot be resolved; the affected processing must not begin without a valid authorisation. This clause grants no new fee, automatic consent by silence or unilateral commercial termination right.

le_dns binds each authorised subprocessor to data-protection obligations equivalent to those applying to the entrusted activity under this DPA, verifies sufficient guarantees and remains responsible to the customer for that subprocessor’s performance. le_dns supplies the information needed to demonstrate these safeguards, with proportionate redaction to protect unrelated confidential information.

6. Data-subject requests

Taking account of the processing, le_dns assists the customer through appropriate technical and organisational measures, as far as possible, with requests under GDPR Chapter III. This covers locating entrusted data, providing it securely, correcting, restricting or erasing it, and supporting portability and objections where applicable. le_dns promptly forwards requests it receives concerning processing on the customer’s behalf and does not answer substantively on the customer’s behalf unless instructed or legally required.

The customer determines the response and verifies the requester’s rights; le_dns cooperates with necessary identity and authority checks without collecting excessive identification data. The parties use Annex A contacts to identify the applicable deadline and coordinate assistance in time for the customer’s legal obligations. The lack of a self-service button does not suspend those obligations or make assistance conditional on purchasing an optional feature.

The inspected API can download a retained zone-history snapshot. That is not a complete return of all entrusted personal data. The complete return scope and operational procedure are specified in Annex D; no seven-day automated return guarantee is asserted by the inspected code.

7. Retention and deletion

At the end of the entrusted processing, the customer chooses return followed by deletion, or deletion without return. le_dns implements that choice for the entrusted personal data and removes remaining copies, including copies held by subprocessors, unless Union or Member-State law requires retention. Annex D specifies the secure return format, deadline, active-store and backup deletion schedule and evidence of completion. le_dns does not retain entrusted data indefinitely merely because its software archives it.

Where law requires retention, le_dns identifies the legal requirement, affected categories and period to the customer unless disclosure is prohibited; it isolates the retained data and limits use to that obligation. Independently controlled billing records must be distinguished from entrusted zone data and do not justify retaining DNS secrets or all customer content.

During an agreed backup-expiry interval, retained copies remain protected and unavailable for ordinary use. A recovery procedure must reapply valid deletion instructions before restored data returns to ordinary service. le_dns provides a written completion record identifying the stores addressed, deletion dates and any lawful remaining retention; it must not certify deletion it has not verified.

Annex D identifies implementation limits observed during this review. They must be resolved for the agreed processing before acceptance; they do not qualify away the customer’s return/deletion choice.

8. Incidents

le_dns will notify the customer without undue delay after becoming aware of a personal-data breach affecting customer-controlled data and will provide the information reasonably available for the customer’s GDPR duties. This does not wait for an exhaustive investigation. A fixed 24-hour commitment requires demonstrated operational capability and agreement before inclusion.

The initial notice includes, as available, the nature of the breach, categories and approximate numbers of people and records concerned, a contact for follow-up, likely consequences and measures taken or proposed to contain and mitigate it. Missing information is supplied in phases without undue further delay. le_dns preserves necessary incident evidence, cooperates on containment and remediation, and assists the customer with notifications under Articles 33 and 34. The controller’s conditional supervisory-authority deadline is not a waiting period for the processor.

9. Audit and assistance

le_dns makes available the information needed to demonstrate compliance with its Article 28 obligations and permits and contributes to audits, including inspections, by the customer or its mandated auditor. The parties coordinate proportionate scope, safe access and protection of other customers’ information. These arrangements must not prevent an effective audit or delay legally urgent checks; a summary report does not automatically replace an inspection that is necessary.

Taking account of the processing and information available to it, le_dns also assists with security assessments, data-protection impact assessments and prior consultation under Articles 32–36. It supplies relevant processing, risk and control information, cooperates with competent supervisory authorities and identifies any gap that could affect the customer’s compliance. No independent certification or completed audit is represented unless its report actually exists and applies to the deployment.

10. International transfers

le_dns transfers entrusted personal data to a third country or international organisation only on documented instructions or the legal basis for compelled processing in Section 3, and with an applicable GDPR Chapter V mechanism. Annex C records destination countries, access locations, the mechanism and how the customer can obtain its safeguards. Subprocessor authorisation alone does not establish a lawful international transfer.

The historical infrastructure inventory does not establish that every current recipient or remote access is within the EEA. No blanket no-transfer guarantee is made while Annex C is incomplete. This DPA is not itself a set of international-transfer standard contractual clauses.

11. Return, deletion and termination

Return and deletion follow Section 7 and Annex D. The obligations protecting any lawfully retained data continue after service termination. The parties document instructions, responsibilities and dependencies for a safe DNSSEC withdrawal and return; those dependencies do not authorise indefinite retention. Billing downgrade does not rewrite, park or monetize DNS answers.

12. Precedence and law

GDPR and other mandatory law take precedence. For entrusted personal-data processing, the accepted DPA prevails over conflicting service terms. It does not alter price, renewal, resale or notice policies. French law is intended to govern, subject to mandatory jurisdiction and consumer-protection rules. Amendments to the accepted DPA or its instructions must be documented; editing this public draft does not change an existing agreement by itself.

13. Signatures

This draft creates no agreement until completed and accepted by authorized representatives of both parties.

The written or electronic acceptance record must identify both parties, their authority, the document version, completed annexes and effective date. A signature area, account creation or payment event is not evidence that this acceptance has occurred. If a party cannot perform an obligation, it must resolve the gap before the relevant processing is entrusted; leaving an annex open does not waive GDPR duties.

Customer: ____________________
le_dns: ____________________
Date: ____________________

Annex A — Parties, processing and instructions

Annex B — Security measures and operational evidence

Annex C — Subprocessors and international transfers

The following is an inventory to complete, not an authorised list. For each actual provider record its legal entity, task, personal-data categories, countries including remote access, applicable contract, authorisation and any transfer safeguard.

Paddle’s own sales and payment processing belongs in the privacy and commercial documents; it is not an authorised recipient of DNS-zone content by virtue of appearing there. Historical evidence for the former provider is retained separately.

Annex D — Return, retention and deletion

Legal reference: GDPR Articles 28, 32–36, as published by the CNIL.