Nimbu Data Processing Agreement (DPA)

This document is a courtesy translation. Only the Dutch version is legally binding; in case of any discrepancy, the Dutch text prevails.

Annex to the Nimbu Hosting and License Agreement

This data processing agreement (the “DPA”) forms an integral part of the Nimbu Hosting and License Agreement (the “Main Agreement”) between the Customer identified therein as Controller and Zenjoy BV, Blijde Inkomststraat 22, 3000 Leuven, KBO BE 0838.367.436, as Processor. Terms from the General Data Protection Regulation (Regulation (EU) 2016/679, the “GDPR”) have the same meaning in this DPA.

Article 1 — Subject matter, roles and instructions

1.1. The Processor processes the personal data described in Annex A exclusively on behalf of and on documented instructions from the Controller, including instructions concerning transfers, and only insofar as necessary to perform the Main Agreement.

1.2. The electronic acceptance of the Main Agreement and this DPA constitutes the initial documented instruction. Configurations, actions and commands carried out by the Controller or by a User authorised by it within the rights granted count as additional instructions. Other instructions shall be given in writing or electronically.

1.3. If the Processor is required to process by Union law or Belgian law, it shall inform the Controller of that legal requirement before processing, unless that law prohibits this on important grounds of public interest.

1.4. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection legislation. The Processor may suspend the performance concerned until the instruction has been clarified or amended.

1.5. Insofar as Zenjoy processes personal data exclusively to perform the hosting, support, error follow-up, backup, restoration, security and other Services requested by the Controller, Zenjoy acts as Processor under this DPA, including where technical logs or customer data are consulted for that purpose.

Zenjoy acts as a separate controller exclusively for clearly delineated purposes of its own, including contract and invoicing management, proof of contract conclusion, the management and security of its own Nimbu account system, the prevention and investigation of fraud and abuse directed against Zenjoy or the Platform, compliance with its own legal obligations and the establishment, exercise or substantiation of legal claims. That processing is covered by the Nimbu Platform Privacy Statement and not by this DPA.

Where the same data are processed for multiple purposes, the role is determined per separate purpose. The qualification always follows from the factual processing and the applicable legislation. Zenjoy limits its processing as a separate controller to the data necessary for the own purpose concerned.

Article 2 — Specification and duration

2.1. The subject matter and duration of the processing, the nature and purposes, the types of personal data, the categories of data subjects and the rights and obligations of the Controller are set out in the Main Agreement and Annex A.

2.2. The processing lasts as long as the Processor processes personal data on behalf of the Controller, including the contractual transition, retrieval and deletion period.

Article 3 — Obligations of the Controller

3.1. The Controller determines the purposes and means of the processing and is responsible for the legal basis, transparency, accuracy, data minimisation, retention periods and the handling of data subjects’ rights.

3.2. The Controller shall ensure that its instructions are lawful, that Users are granted appropriate rights and that personal data are not processed via manifestly unsecured or unsupported features.

3.3. Special categories of personal data within the meaning of Article 9 GDPR, personal data relating to criminal convictions and offences within the meaning of Article 10 GDPR or data subject to a special security regime shall only be processed after a prior written addendum setting out the necessity, instructions and additional measures.

3.4. The Controller warrants that it will not enter or allow the entry of the data referred to in Article 3.3 without an addendum, including via free text fields, forms or uploads, and shall immediately report any identified violation to the Processor. The Processor may, after notification where reasonably possible, block or suspend the processing concerned and delete the data on the Controller’s instruction. Demonstrable additional security, assistance or compliance costs arising from such a violation may be charged at reasonable rates. Article 15.4 applies.

Article 4 — Use and data minimisation

4.1. The Processor shall not use the personal data for its own advertising, profiling or sales purposes and shall not combine them with data of other customers, except for its own processing operations under Article 1.5.

4.2. The Processor shall only make copies that are necessary for production, redundancy, security, logging, backup, restoration and the execution of documented instructions.

4.3. A legally mandatory request for disclosure shall, where legally permitted, be communicated to the Controller before the disclosure. The Processor shall limit the disclosure to what is legally required.

Article 5 — Confidentiality and personnel

5.1. The Processor shall ensure that persons authorised to process personal data have committed themselves contractually to confidentiality or are bound by an appropriate statutory obligation of confidentiality. This obligation continues to apply after the end of their access.

5.2. Access is limited to persons who need it for their tasks. The Processor shall provide appropriate awareness and instructions on data protection and information security.

Article 6 — Sub-processors

6.1. The Controller grants general written authorisation for the sub-processors listed at https://www.nimbu.io/sub-processors.

6.2. The current list states at least the identity, function, principal location and the applicable transfer mechanism. The Processor shall give notice of an intended addition or replacement at least fifteen (15) days in advance by e-mail or via the admin environment.

The notice period applies insofar as reasonably practicable. In the event of an urgent replacement due to a security risk, a legal obligation, insolvency, a serious breach or an unexpected termination by an existing sub-processor, the Processor may immediately engage an appropriate replacement; it shall inform the Controller thereof without undue delay and shall apply the other safeguards of this article in full.

6.3. The Controller may object within that period on stated grounds. An objection must be specific, substantiated and limited to material data protection risks of the sub-processor concerned. The Parties shall seek a reasonable solution. If no equivalent solution is available and the sub-processor is necessary, the Processor may, at its own discretion, still replace the sub-processor or disable the affected feature, and the Controller may terminate only the materially and directly affected Service before the engagement without any termination fee. A termination right does not apply to unaffected Services. Prepaid amounts for the period not provided shall be refunded pro rata.

6.4. The Processor shall impose on the sub-processor, by way of a written agreement, in essence the same data protection obligations, with appropriate guarantees for technical and organisational measures. The Processor remains liable towards the Controller for the sub-processor’s performance.

6.5. Where the Customer activates or configures an optional integration with a third-party service, the data protection role is determined by the factual processing and not solely by the account or credentials used. Insofar as the Customer engages the third party directly under its own agreement and the Processor merely establishes a technical connection on documented instruction, that third party is not a sub-processor of the Processor and the Customer itself is responsible for the applicable agreement, legal basis and any transfer safeguards. If, by contrast, the Processor itself engages the third party to process personal data on the Customer’s behalf, that third party qualifies as a sub-processor and this article applies, irrespective of whose credentials are technically used.

Article 7 — Security

7.1. Taking into account the state of the art, the costs of implementation, the nature, scope, context, purposes and risks, the Processor shall implement appropriate technical and organisational measures in accordance with Article 32 GDPR. The current standard measures are set out in Annex B.

7.2. The Processor may replace measures with materially equivalent or better measures, provided the overall level of security is not reduced. A material reduction shall be communicated in advance and treated as an amendment to this DPA.

7.3. The Controller and its Users remain responsible for their endpoints, correct roles, confidential authentication credentials, the activation of available security options and the timely revocation of access.

Article 8 — Personal data breaches

8.1. The Processor shall notify a personal data breach without undue delay to the contact point registered by the Controller after the Processor, on the basis of the information reasonably available, has obtained a reasonable degree of certainty that a security incident has affected personal data of the Controller. Internal escalation or team procedures do not defer that moment. The Processor aims to provide an initial notification within forty-eight (48) hours after obtaining that certainty.

An initial notification may be phased and incomplete if not all information is yet available. A security signal not yet confirmed, a vulnerability or an incident without reasonable indication that personal data of the Controller have been affected does not constitute awareness of a personal data breach. This article does not limit the Processor’s statutory notification obligation under Article 33(2) GDPR.

8.2. The notification shall contain, insofar as known: the nature of the breach; categories and an approximation of the number of data subjects and records; the contact point; likely consequences; and measures taken or proposed. The Processor shall provide supplements as soon as they become available.

8.3. The Processor shall provide reasonable assistance with investigation, mitigation, remediation and the assessment of whether notification to a supervisory authority or data subject is required. The Controller decides on its notifications under Articles 33 and 34 GDPR, unless the law provides otherwise.

8.4. Each Party bears the reasonable incident and assistance costs in proportion to the cause for which it is responsible. The Controller shall reimburse the additional reasonable costs of the Processor insofar as an incident was caused by the Controller’s systems, Users, credentials, integrations, instructions or failures and not by a failure of the Processor.

Article 9 — Assistance

9.1. Taking into account the nature of the processing, the Processor shall assist the Controller, insofar as possible with appropriate technical and organisational means, with requests from data subjects under Articles 12 to 23 GDPR. The Processor shall not respond to such a request independently, except on instruction or legal obligation.

9.2. Taking into account the nature of the processing and the information available, the Processor shall assist with compliance with Articles 32 to 36 GDPR, including security, data breaches, data protection impact assessments and prior consultation.

9.3. Standard assistance within normal operations is included. Extraordinary, customer-specific assistance may be charged after a prior estimate, provided it does not result from a failure of the Processor and the statutory duty of assistance is not thereby rendered illusory.

Article 10 — Location and international transfers

10.1. Primary hosting, databases and primary backups are located within the EEA with OVHcloud. Encrypted offsite backups are located within the EEA with Hetzner. Transactional e-mail is processed within the EEA by Scaleway. AI-based spam detection on form submissions is processed within the EEA by Mistral AI, with zero data retention.

10.2. For CDN services, Bunny.net may process website content, technical request data and IP addresses via global edge locations. As a result, a transfer outside the EEA may take place.

10.3. A transfer to a third country or international organisation shall only take place on documented instruction or via an authorised sub-processor and with a valid mechanism under Chapter V GDPR, such as an adequacy decision or the applicable modules of the standard contractual clauses of Implementing Decision (EU) 2021/914. Where required, the Processor shall assess the transfer and adopt supplementary technical, organisational or contractual measures.

10.4. The Processor shall inform the Controller of a material change in the transfer mechanism via the sub-processor procedure.

Article 11 — Transparency towards data subjects

11.1. The Controller shall provide the information under Articles 13 and 14 GDPR for its own website, application, form, customer, member, shop and other processing operations. The Processor shall provide reasonable technical support where this must be done via the Platform.

11.2. Zenjoy itself provides information for its own processing under Article 1.5 via the Nimbu Platform Privacy Statement.

Article 12 — Access restriction

12.1. The Processor uses physical data centres of professional infrastructure providers and restricts logical administrative access on a need-to-know basis, with strong authentication, central access management and logging as described in Annex B.

12.2. The Controller may receive information about the relevant access categories and control measures. Names of individual staff members shall only be provided where this is necessary and lawful.

Article 13 — Documentation and demonstrability

13.1. The Processor shall maintain appropriate internal documentation on security, sub-processors, incidents, access management and the performance of this DPA.

13.2. The Processor shall make available the information reasonably necessary to demonstrate compliance with Article 28 GDPR, while protecting confidential information, other customers and the security of the Platform.

Article 14 — Audit

14.1. The Controller may conduct an audit itself or through an independent, non-competing auditor bound by confidentiality. In principle, this shall take place at most once every twelve months, with at least thirty days’ prior notice, during office hours and without unnecessary disruption.

14.2. The frequency and notice restrictions do not apply after a relevant breach, upon reasonable request of a supervisory authority or where concrete indications of material non-compliance exist.

14.3. The Parties shall first use available reports, questionnaires and supporting documents where these reasonably suffice. The Controller bears its own audit costs. If a material failure of the Processor is established, the Processor shall bear its own reasonable cooperation costs and shall remedy the failure without undue delay.

14.4. An audit shall in principle be conducted on the basis of documentation and remotely. It does not grant access to source code, secrets or credentials, environments or data of other customers or data centres of sub-processors, and does not include a penetration test, vulnerability scan or load test without separate prior written agreement. The Parties shall make maximum use of existing certifications, audit reports and the Processor’s standard information package. The Processor may charge the reasonable time exceeding that standard package at reasonable rates, except where the audit demonstrates a material failure of the Processor.

Article 15 — Liability

15.1. Article 82 GDPR and the rights of data subjects and supervisory authorities are not limited. A Processor is liable towards a data subject under the conditions of Article 82(2) GDPR; the internal apportionment of liability follows Article 82(5) GDPR.

15.2. To the extent permitted by law and exclusively in the internal relationship between the Parties, each Party is liable for its own attributable failure. The total internal liability of the Processor towards the Controller for any claim arising from or relating to the processing of personal data under this DPA, irrespective of the contractual, non-contractual, statutory or other legal basis and including a recourse claim under Article 82(5) GDPR, is subject to the increased liability cap of Article 9.6 of the Main Agreement, save for the non-limitable cases of Article 9.9 of the Main Agreement. This cap does not limit any direct right of a data subject, any power or fine of a supervisory authority, or any other liability for which a contractual limitation is prohibited by mandatory law. The liability of the Controller towards the Processor is not limited by this article.

15.3. A Party that has paid more than the share for which it is responsible in accordance with Article 82(4) GDPR may exercise recourse against the other parties involved in accordance with Article 82(5) GDPR in proportion to their share. To the extent permitted by law, any internal recourse of the Controller against the Processor remains subject to Article 15.2.

15.4. Zenjoy’s liability cap does not limit the Controller’s obligation to indemnify or hold Zenjoy harmless for claims of third parties or data subjects, investigations by supervisory authorities, reasonable external defence costs and, insofar as legally recoverable, sanctions or compensation arising from: (a) an unlawful or incomplete instruction; (b) the absence of a valid legal basis or required transparency; (c) the processing of data not permitted under Article 3.3; (d) a failure in the security of endpoints, accounts, roles, authentication credentials or customer integrations; (e) the actions of Users or third parties engaged by the Controller; or (f) any other violation by the Controller of the GDPR or this DPA, in each case exclusively to the extent that the claim or damage is attributable to the Controller. The responsibility of the Parties shall be assessed according to their respective share in accordance with Article 82(5) GDPR, it being understood that any internal recourse against the Processor remains, to the extent permitted by law, subject to Article 15.2.

Article 16 — Rights to data

16.1. As between the Parties, the Controller retains its rights to customer data. This DPA does not transfer any intellectual property rights.

16.2. The Data Act export rights and the delineation of transferable digital assets are governed by Article 10.2 of the Main Agreement.

Article 17 — End, return and deletion

17.1. After the end of the processing services, the Processor shall make the personal data and transferable customer data available in accordance with the switching process of the Main Agreement. The standard retrieval period is at least thirty (30) calendar days after the transition period.

17.2. At the choice of the Controller, the Processor shall return the personal data and delete them in accordance with the procedure in Articles 17.3 and 17.4, or shall delete them without return, unless Union law or Belgian law requires storage. The choice may be communicated via the switching or termination request.

17.3. After the retrieval period, the Processor shall delete the personal data from the active production systems. Residual copies may then only exist in backups made before that deletion. They shall be deleted or overwritten in accordance with the documented cycles in Annex B and at the latest twelve (12) months after the end of the retrieval period. Where technically applicable, the Processor may render residual copies irrevocably inaccessible earlier by destroying the associated encryption keys. Until then, they remain encrypted, logically isolated and blocked from operational or other processing, except where access is strictly necessary for disaster recovery. Deleted active data shall not be included in new backups.

17.4. Where a backup is restored before the final deletion, the Processor shall re-apply all deletions carried out since its creation before the restored environment is used operationally or backed up again. As long as a copy subject to statutory retention exists, it remains isolated, secured and blocked from processing other than the statutory retention. The Processor shall inform the Controller upon request of the legal basis and period.

17.5. Upon request, the Processor shall confirm the deletion from the active systems and, after the expiry of the applicable backup cycle, the final deletion of the residual copies. The confidentiality, security and liability provisions continue to apply as long as the Processor still holds personal data.

Article 18 — Final provisions

18.1. In the event of conflict, this DPA prevails for the processing of personal data on behalf of the Controller. For prices, general service provision and Data Act switching, the Main Agreement prevails, insofar as this does not limit Article 28 GDPR.

18.2. Amendments to this DPA follow Article 16 of the Main Agreement and may not reduce the level of protection required by Article 28 GDPR.

18.3. Belgian law applies. The competent court is determined in accordance with Article 17 of the Main Agreement.

18.4. The electronic acceptance constitutes a valid written agreement in electronic form and is recorded in accordance with Article 1 of the Main Agreement.

Annex A — Specification of the processing

Element	Specification
Controller	The Customer as identified in the Main Agreement and the admin environment.
Processor	Zenjoy BV, Blijde Inkomststraat 22, 3000 Leuven, KBO BE 0838.367.436.
Subject matter	Hosting, storage, making available, backup, technical management, security, support, export and deletion in the Nimbu platform.
Nature of the processing	Receiving, recording, structuring, storing, consulting on instruction, technically transmitting, securing, backing up, restoring, exporting and deleting.
Purposes	Delivery and security of the websites, web applications, forms, databases, shops, apps and associated Nimbu functions configured by the Customer.
Duration	The duration of the Main Agreement plus the transition, retrieval and technically necessary deletion period of Article 17.
Categories of data subjects	At the Customer’s choice, including website visitors, prospects, customers, members, donors, suppliers, contact persons, employees, job applicants and end users of the Customer.
Types of personal data	At the Customer’s choice, including identification and contact data, account and authentication data, communication and form data, customer and member data, transaction, order, payment-status and delivery data, content, technical identifiers and usage data. Full payment card data is not to be stored in Nimbu where a payment provider has been designated for that purpose.
Special categories of data	Not permitted without the addendum of Article 3.3.
Frequency	Continuous, according to the use by the Customer and its end users.
Storage location	Primary production and primary backup within the EEA at OVHcloud; encrypted offsite backup within the EEA at Hetzner; other locations in accordance with Article 10 and the sub-processor list.
Rights and obligations of the Customer	Determines purposes and lawful instructions; manages Users and retention periods; provides transparency; handles data subjects’ rights; receives information, assistance, export and audit rights in accordance with this DPA.

Annex B — Technical and organisational measures

The measures below are the standard measures as at 27 July 2026. This Annex describes the binding categories and minimum objectives of the technical and organisational measures applied by Zenjoy. Products, suppliers, tools, architecture examples and implementation details mentioned are indicative and may be replaced in accordance with Article 7.2 without amending this DPA, provided that Zenjoy maintains a materially equivalent or higher overall level of security.

Frequencies and cadences mentioned describe Zenjoy’s standard configuration and operational objectives. They do not constitute a separate SLA and do not imply any guarantee that every individually scheduled backup, review, scan or test run will be completed without interruption or error. An incidental deviation does not in itself constitute a breach where Zenjoy applies appropriate alternative measures and the overall level of security is not materially reduced. Only a period expressly designated in this Annex as a contractual minimum or contractual maximum applies as such. The maximum retention period of twelve (12) months for restore points and residual copies and the associated deletion obligations apply as a contractual maximum.

This Annex does not constitute an SLA and does not create any guaranteed availability, recovery time, recovery point objective, archiving service or guarantee that every individual restore point will always be usable. Specific RPO, RTO or recovery obligations apply only if they have been expressly agreed in a separate SLA.

1. Architecture and tenant isolation

Production and staging run in separate, logically segregated Kubernetes clusters on virtual machines, with dedicated VLANs, redundant routers and firewalls and a default-deny perimeter policy. The underlying virtualisation infrastructure may share physical hosts.
Customer data within the SaaS platform is isolated per tenant at application level through mandatory tenant scoping of data access.
Management interfaces and cluster access are not directly publicly reachable.

2. Identity and access management

Infrastructure access first requires a per-person authenticated VPN connection via Tailscale/Headscale and the central identity provider with enforced two-factor authentication.
Cluster access additionally runs through Teleport with GitHub SSO and WebAuthn. Management interfaces use Authentik SSO and admit only organisation accounts secured with 2FA.
Infrastructure permissions are managed centrally through organisation-bound accounts and a central GitHub team. Offboarding at the identity layer revokes the linked infrastructure access.
Memberships and elevated access rights are formally reviewed periodically, with an operational target cadence of once per quarter, and the review is recorded.
Nimbu provides roles and permissions for customer administrators. The Customer manages its own Users and revokes access that is no longer necessary.

3. Encryption and key management

Primary Ceph RBD block storage is encrypted per volume with LUKS/AES-256. Keys are managed outside the infrastructure in a separate secrets manager.
Kubernetes secrets are encrypted in etcd. Secrets in configuration management are encrypted with SOPS/age.
Database backups are encrypted. MongoDB backups use SSE-C AES-256 with Zenjoy managing the key; PostgreSQL backups use server-side AES-256 encryption. Offsite backups are stored encrypted.
Passwords are not stored in readable form but are processed with an appropriate one-way function and salt.

4. Transport security

Public endpoints are reachable exclusively via HTTPS with automatically managed and rotated TLS certificates via Let’s Encrypt and cert-manager.
Supported PostgreSQL and MongoDB connections run over TLS.
The Kubernetes API and etcd use mutual TLS for the cluster control plane.

5. Backup, retention and recovery

Primary backups are held at OVHcloud; geographically separated, encrypted offsite copies are held at Hetzner.
MongoDB has continuous point-in-time recovery with ten-minute granularity, supplemented by a maximum of 60 daily, 12 weekly and 12 monthly restore points. No restore point is retained longer than twelve (12) months (contractual maximum), so that all documented backup cycles expire within twelve months.
PostgreSQL receives physical base backups twice a day with approximately ninety days of retention.
MySQL dumps are made every four hours with ten to fourteen days of retention.
Kubernetes volumes are backed up daily via Velero with seven days of retention and weekly with fourteen days of retention. In addition, nightly VM-level backups exist.
Restore and point-in-time recovery are operational. Zenjoy periodically performs a documented restore exercise to a non-production environment, with an operational target cadence of at least once every six months.
The periods above apply to the operational continuity of active accounts. After termination, customer data is deleted from the active systems after the transition and retrieval period. Residual copies can then only remain in backups made before that deletion. They are deleted or overwritten upon expiry of their documented cycle and no later than twelve (12) months after the end of the retrieval period (contractual maximum).
Residual copies of deleted customer data remain encrypted, logically isolated and blocked from operational use. Access is permitted exclusively for necessary emergency recovery. Zenjoy keeps deletion instructions available for the applicable backup cycle. The recovery procedure requires those instructions to be reapplied before a restored environment is used operationally or backed up again.

6. Logging, monitoring and detection

Application and system logs are sent centrally via TLS to the OVH Logs Data Platform. They remain hot and searchable for thirty days and thereafter cold/archived for a maximum of one year.
Metrics remain available at full resolution for fourteen days and are retained downsampled for a maximum of two years.
Continuous monitoring and alerting run via Prometheus and Alertmanager to the operations team, with an external heartbeat as a dead-man’s switch.
Errors are followed up in a GlitchTip environment self-hosted within the OVH infrastructure.

7. Updates and vulnerability management

Container images, infrastructure code and relevant dependencies are regularly checked for updates and known vulnerabilities using automated tools such as Renovate and GitHub Dependabot. Security updates are assessed on a risk basis, tested and rolled out within a period appropriate to the severity, exposure and operational impact.
Minor and patch updates are applied automatically where appropriate. OS and Kubernetes upgrades follow a planned rolling-upgrade procedure with health checks per node.
Dependency security alerts, Renovate, Docker Scout and gitleaks support the continuous follow-up of vulnerabilities and secrets.
Security updates are rolled out through the update process according to risk and urgency.

8. Development and change management

Changes are managed through version control, automated checks and separate staging and production environments.
Development and review take account of relevant web security risks, including the OWASP Top 10.
Access to production data for support or maintenance is limited to necessary cases, authorised persons and appropriate logging.

9. Incident response and continuity

The engineering team triages security incidents on the basis of monitoring, alerts and error follow-up. The customer contact point is help@zenjoy.be.
Zenjoy maintains a concise documented incident response procedure with roles, escalation, preservation of evidence, customer communication and post-incident evaluation.
Personal data incidents are handled in accordance with Article 8 of this DPA.

10. Suppliers and evaluation

Sub-processors are selected and contractually bound in accordance with Article 6.
Zenjoy assesses the effectiveness of the measures periodically and after relevant incidents or material architecture changes.